FHEM und UNICODE, first aid

[betateilchen]

Hallo Rudi,

danke für die Beschreibung der konkreten Maßnahmen.

Umgestellt und kurz getestet habe ich:

- FileRead/FileWrite in fhem.pl

Für mein Verständnis gibt es in configDB keine ToDos, solange ich davon ausgehen kann, dass diese beiden Funktionen korrekt arbeiten.
Alle Daten, die von Modulen in die Datenbank geschrieben oder daraus gelesen werden, benutzen dazu den Weg über FileWrite() und FileRead().
configDB selbst nimmt keine Verbindungen zur Außenwelt auf und führt auch keine Konvertierungen durch.

[rudolfkoenig]

Für mein Verständnis gibt es in configDB keine ToDos, solange ich davon ausgehen kann, dass diese beiden Funktionen korrekt arbeiten.

Diese Funktionen arbeiten leider nur "korrekt" fuer Dateien, der Aufruf von cfgDB_FileRead / cfgDB_FileWrite wird nicht behandelt.

[Adimarantis]

Ich habe hier noch ein paar Probleme. Wenn ich unter encoding=Unicode Umlaute etc. im Attribut "stateFormat" verwende, bekomme ich sowas

Code Auswählen Erweitern

(Rücklauf): 30.4°
auch wenn ich das Attribut nochmal neu editiere und speichere.
Schalte ich zurück auf "bytestream" schaut es wieder richtig aus.

Edit: Und FTUI (alte Version) ist unter Unicode komplett hinüber - identifiziert Icon Namen nicht mehr uvm

[rudolfkoenig]

Ich habe hier noch ein paar Probleme.

Das sollte bitte keinen ueberraschen, ich habe nicht umsonst EXPERIMENTELL geschrieben.
Und wenn sich daran was aendern soll, dann sollten die Probleme nachstellbar beschrieben werden, da ich es noch nicht kann:

Code Auswählen Erweitern

fhem> l global encoding
global                   unicode

fhem> define d dummy
fhem> attr d stateFormat reading1 Rücklauf
fhem> l d STATE
d                        reading1 Rücklauf

fhem> setreading d reading1 Küche
fhem> l d STATE
d                        Küche Rücklauf

Die FHEMWEB Ansicht schaut auch ok aus.
Ich tippe auf noch nicht angepasste FHEM-Module.

[Adimarantis]

Ich habe bei deinem Beispiel in beiden Fällen "kaputte" Umlaute und wenn ich auf bytestream zurückgehe ist alles ok.
Kann das noch mit Einstellungen auf Linux Ebene zusammehängen (LC_ALL?)

Jörg

[rudolfkoenig]

Danke fuer die Idee.

LC_ALL wurde noch nie beachtet (mW uebertraegt telnet/etc keine Umgebungsvariablen an dem Server), das muss man "schon immer" fuer FHEM mit "encoding utf8" oder "encoding latin1" einstellen.

Ich habe es in einem latin1 Terminal getestet, und ich hatte tatsaechlich trotz "encoding latin1" Probleme.
Ich habe das jetzt in telnet.pm gefixt.

Ich gehe davon aus, dass die Terminals seit eltichen Jahren per UTF-8 Voreinstellung konfiguriert sind.
Man kriegt es leicht raus mit echo ä | wc.
3 ist utf-8, 2 ist latin1 oder Vergleichbares.

[justme1968]

telnet könnte das schon, das problem damals war das fhem telnet modul eigentlich die komplette kommunikation dir zwischen client und server bidirektional möglich wäre garnicht richtig unterstützt und eher reine socket kommunikation wie netcat macht.

deshalb hatte ich das damals aufgegeben und auch die idee die cursortasten und cmdline history noch einzubauen aufgegeben

es war halt mit dem manuellen konfigurieren gut genug.

[Adimarantis]

Da hab ich dich jetzt vielleicht auf die falsche Fährte gebracht. Ich hab das Problem unter FHEMWEB

Code Auswählen Erweitern

attr global encoding unicode
defmod xxx dummy
attr xxx stateFormat abc öüÄ
setstate xxx Küche äüö

schaut dann so aus wie im Bild, wenn ich auf zurück auf bytestream schalte, alles wie gewollt.
Selbiges auch wenn ich Emojis copy&paste - im Editor schauts erst gut aus, aber nach dem Speichern alles in 8-Bit
Browser ist Chrome unter Windows

[Benni]

Alle Daten, die von Modulen in die Datenbank geschrieben oder daraus gelesen werden, benutzen dazu den Weg über FileWrite() und FileRead().
configDB selbst nimmt keine Verbindungen zur Außenwelt auf und führt auch keine Konvertierungen durch.

Damit ist dann auch das statefile berücksichtigt?
Die States werden, so weit ich weiß, in einer separaten Tabelle gespeichert

gb#.

[rudolfkoenig]

@Adimarantis: Danke fuer das Beispiel, habs gefixt (URL war noch nicht dekodiert).
@Benni: Dateibasiert sollte es funktionieren. configDB muss noch angepasst werden.

Weiterhin:
- Unterstuetzung fuer MQTT2_SERVER, MQTT_CLIENT, FHEM2FHEM und FileLog eingebaut.
- da eventTypes, holiday und SVG FileRead/FileWrite verwendet, war hier keine Aenderung notwendig. Dafuer war FileLog extra aufwendig, bin nicht sicher, dass ich alles gefunden habe.
- die Umlaute werden in telnet mit inform auch auf latin1 Terminals richtig dargestellt. Vermutlich nur mit "encoding unicode"
- aendern des encoding Attributes bewirkt ein sofortiges save und shutdown restart
- das Attribut ist jetzt dokumentiert.

Eine Liste der Module, die noch umgestellt werden muessen, waere hilfreich.


Ich habe vor bei der naechsten Noetigung laenger Widerstand zu leisten.

[herrmannj]

Ich habe gerade gesehen dass du mqtt2 Client nachgezogen hast. Das betrifft dort topic und value. Topic ist korrekt weil so standardisiert. Value kann alles sein, auch binary. Daher darf dort nicht automatisch konvertiert werden. Falls der payload json ist, wird der json Decoder zuständig, der wendet das an.

[Adimarantis]

Das mit dem "save" nach Attribut Änderung klappt nicht. (aktuelle Version vom svn)
Dachte gerade ich hätte einen Fehler gefunden, dabei hat er mein encoding=unicode nie genommen, da es nach dem automatischen shutdown immer weg war.
Sonst schauts schon viel besser aus

[xenos1984]

An welcher Stelle muss ein Modul das implementieren, dass 1. DevIO mit WebSocket, 2. HttpUtils_NonblockingGet benutzt, um mit dem Gerät zu kommunizieren? Bei den Daten handelt es sich, rein wie raus, um JSON (meines Wissens nach UTF8). Übersetzt werden die Daten, ebenfalls wieder in beide Richtungen, mit encode_json und decode_json. Die beiden Funktionen können wohl auch mit Unicode-Strings arbeiten statt mit UTF8. Ich vermute mal, alles, was von DevIO bzw. HttpUtils_NonblockingGet an Daten kommt oder dorthin geht, muss konvertiert werden. Wie ist es mit der URL - muss die auch konvertiert werden?

[rudolfkoenig]

@hermannj:
Stimmt, value kann auch binary sein.
Das macht mich aber ratlos, da mAn die Konvertierung im JSON-Parser falsch ist: woher soll mein Parser wissen, woher die Daten kommen? Sie koennen intern erzeugt sein oder ueber HTTP/HTML kommen, wo die Kodierung festgelegt  und durchgefuehrt ist.
Ich bin auch sicher, dass etliche Gadgets in "einfachen" MQTT-Values (nicht Json-kodiert) UTF-8 verschicken.
Faellt Dir eine generische Loesung fuer die Konvertierung in MQTT ein?
Ich bin zunehmend von meiner urpruenglichen "bytestream" Loesung begeistert.

@Adimarantis:
verwendest Du configDB?
Wenn ja: das funktioniert noch nicht.
Wenn nicht: kannst Du mir was zum Nachstellen zeigen?
Ich habe save gestern eigentlich getestet. Meine ich jedenfalls

@xenos1984
Ich gehe davon aus, dass websocket nicht auf UTF-8 festgelegt ist. Wenn das stimmt, dann muss man nach DevIo_SimpleRead ein Encode::decode ausfuehren, und vor DevIo_SimpleWrite ein Encode::encode. Wenn die Konvertierung durch encode_json und decode_json erfolgt, dann musst man nichts unternehmen.
Wenn websocket per Definition auf UTF-8 festegelegt sein sollte, oder die Konvertierung sonstwie rauszukriegen ist, dann baue ich die Umwandlung in DevIo.pm ein => Bitte zeigt mir die Spezifikation.

HttpUtils_NonblockingGet ist anders, da HTTP und Html Direktiven fuers Encoding haben.
Aus diesem Grund uebernimmt HttpUtils das Encoding selbst.

Beim URL kenne ich die Spezifikation nicht, aber im vorherigen Beispiel von Adimarantis kamen die Daten im URL erst URL-encoded, und dann UTF8-encoded. Die UTF-8 Dekodierung habe ich gestern in FHEMWEB / Digest_CGI() eingebaut, seitdem funktioniert sein Beispiel.

[justme1968]

der websocket standard sagt das text frames (0x1) utf-8 codiert sind. binary frames (0x2) sind uncodiert.