Zeichenketten mit Umlauten an KNX senden UTF8 <-> ISO-8859

[ChefSache]

Vielleicht etwas @chefkoch009 :

Als Anwendung habe ich die "MDT Glastaster Smart II", denen ich Textmeldungen vom ioBroker aus senden möchte.
Um Umlaute erfolgreich darstellen zu können ist ein "iconv" erforderlich (ansonsten erscheinen am Glastaster die üblichen UTF8-Hieroglyphen, weil die Zeichenkette als ISO8859-1 erwartet wird - Das Senden von Umlauten via ETS funktioniert):

    var iconv = require('iconv-lite');
    var output = iconv.encode("Küche", "ISO-8859-1");
    setStateDelayed('knx.0.Hauptgruppe.System.Textmeldung', output, false, 0, false);

Dieses Code-Snippet funktioniert gut, aber produziert folgende Warnung im Log:

Das Objekt wurde vom KNX-Adapter als String angelegt - ioBroker mag dort aber nicht das iconv-Ergebnis reinschreiben, weil dieses Ergebnis vom Typ Object ist.
(Zusätzlich habe ich mal den resultierenden SendMail aus dem Log gescreenshotet, weil man hier schön das iconv-Ergebnis als ASCII-Charnummern in Arrayform erkennt.)

Wo ist nun nachzusteuern?

• Kann mein Code geändert werden, um die Warnung zu vermeiden?
  (Das Aufbauen des Strings mit String.fromCharCode(252) führt genauso wie ein output.toString() zu dem Senden eines UTF8-Strings und somit zu den ungewollten Hieroglyphen.)
• Sollte ioBroker die Typ-Konvertierung künftig ohne Warnung hinnehmen?
• Sollte der KNX-Adapter String-s lieber als Object unter den Objekten anlegen?

Der letzte Punkt bietet natürlich eine funktionierende händische Lösung: Wenn ich nach dem KNX-Import einfach den Datentyp auf Object ändere funktioniert es ohne Warnung - Nur ist dieses händische "Umbiegen" eher unschön.

[ChefSache]

Nach reiflicher Überlegung möchte ich noch einen Lösungsvorschlag unterbreiten:

In der ETS gibt es ja zwei verschiedene Datentypen, die als Zeichenkette anwählbar sind:

Wenn ich so drüber nachdenke, macht es durchaus Sinn, dass der Datentyp 16.000 in ioBroker weiterhin ganz normal als Objekt von Typ String angelegt wird - Bei diesem Datentyp sind eh nur die grundlegenden ASCII-Codes von 0..127 erlaubt, die man aus ioBroker ja ganz normal handhaben kann ... Da macht es keinen Sinn, den Benutzer dazu zu zwingen mit nicht-String-s zu arbeiten.

Wenn man am KNX-Bus aber auch mit Sonderzeichen arbeiten will, muss man dann auf den Datentypen 16.001 wechseln (nur dann erlaubt die ETS-Software auch das Werte-Schreiben mit Umlauten).
Dann (bei Konfiguration 16.00.1) handelt es sich also explizit um einen Datentypen, der nicht kompatibel zu einem ioBroker-UTF8-String ist.

Entsprechend geht mein Vorschlag @chefkoch009 dahin, dass der Import des Datentyps 16.001 automatisch zu Typ Object im ioBroker führt, weil dieser Wert nur so sinnvoll befüllbar ist.

[chefkoch009]

@chefsache Darauf habe ich auch schon intensiv rumgedacht, aber per Konvention sind das String typen.....ich bin hin und her gerissen

VG
chefkoch009

[ChefSache]

@chefkoch009
Tja, ich sehe ein, dass das nicht so einfach zu entscheiden ist - Von ETS-Seite aus sind es auf definitiv immer simple Strings, weswegen Deine Umsetzung auf jeden Fall ohne Frage Sinn macht.

Andererseits ist der KNX-Adapter ja auch ein Konvertierungstool in eine andere Welt (nämlich in die ioBroker-Welt) - Und bei so einer Konvertierung kann man durchaus ganz legitim zur Entscheidung kommen, dass gewisse Datentypen konvertiert werden müssen, um in der Ziel-Welt richtig verstanden zu werden.

Und wenn Du mich fragst: ioBroker sieht Strings in ISO-8859-1-Codierung nun mal als Object an - Das muss man zugegebener Weise nicht unbedingt so machen, wird aber von dieser "Ziel-Welt" so erwartet, weswegen ich zu dem Object-Ansatz tendiere.

Will sagen: Ich versuche Dich mal weiter hin- und herzureißen

[stefan1]

@chefsache Hast du eine Lösung gefunden ohne die KNX Konfig anzupassen oder eine Warnung zu erzeugen?

Ich habe versucht die Warnung zu unterdrücken in dem ich nach der Konvertierung wieder zum String caste. Aber da wird wohl implizit wieder zu UTF8 konvertiert.

var iconv = require('iconv-lite');
var output = iconv.encode("Küche", "ISO-8859-1");
setState(ADDRESS, String(output));

[ChefSache]

@chefkoch009 Das Problem wird schlimmer - Mein o.g. iConv-WorkAround funktioniert seit den letzten ioBroker-Updates nicht mehr!

Die ioBroker-Loggings warnten ja bereits "you are assigning a object to [...] string. [...] This warning might become an error in future versions." (siehe mein Screenshot im ersten Post zu diesem Thema)

Nun hat sich das ioBroker-Verhalten (wie im Logging angedroht) geändert: Schreibe ich das Wort "Küche" mittles iConv als Object in den String, dann wird ein JSON-Ausdruck im String gespeichert, der das Object umschreibt. Tatsächlich wird dann folgende Zeichenkette zugewiesen: {"type":"Buffer","data":[75,252,99,104,101]}

Nach den Updates können folglich nur noch "echte" Zeichenketten in einem String gespeichert werden. Somit gibt es >keine< Möglichkeit mehr den Datentypen 16.001 über den ioBroker zu füttern.

Ich möchte noch einmal vorschlagen, dass der Datentyp 16.001 vom KNX-Adapter als Object importiert wird - Als Object kann man dann auch Umlaute zuweisen, die der KNX-Adapter dann richtig als ISO 8895-1 auf den Bus schreiben kann.