FHEM und UNICODE, first aid

[KölnSolar]

Ich versteh ja nur 75% von Eurer Diskussion. Und hab natürlich genau dieses Problem. Obwohl ich noch nicht einmal die Hardware besitze.

Hier mein FHEM-Log

Code: [Auswählen]

############# das Logging findet in meinem logischen Modul statt
2021.11.11 00:20:33 5: DLNAController:  process property LastChange, xml-event <Event xmlns=....<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title> .....
############# Ich jage die message durch den parser XML::LibXML->load_xml...
2021.11.11 00:20:33 4: DLNAController:  parsing did enter load_xml call: <Event xmlns=....<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title>......
2021.11.11 00:20:33 4: DLNAController:  dom structure: <?xml version="1.0"?>
<Event xmlns=....
<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title>
2021.11.11 00:20:33 4: DLNAController:  LastChange xml event with root <Event xmlns=...<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title>.....
2021.11.11 00:20:33 5: DLNAController:  node ...<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title>...
2021.11.11 00:20:33 4: DLNAController:  node ...<dc:title>Die &#xC4;rzte : NEU: Noise</dc:title>.....

############# nun mache ich ein  decode_entities(....); Und (immerhin) nur noch 1 Zeichen
2021.11.11 00:20:33 4: DLNAController:  parsing did enter metadata: <?xml version="1.0"?> ...<dc:title>Die �rzte : NEU: Noise</dc:title>...
############# und den parser-Aufruf $dom = XML::LibXML->load_xml... und ein Wunder: das Ä ist da
2021.11.11 00:20:33 4: DLNAController:  process metadata <?xml version="1.0"?>
...<dc:title>Die Ärzte : NEU: Noise</dc:title>
############# und mit dem Funktions-Aufruf $dom->documentElement()  ist das Ä auch schon wieder weg
2021.11.11 00:20:33 5: DLNAController:  root ...<dc:title>Die �rzte : NEU: Noise</dc:title>...
2021.11.11 00:20:33 5: DLNAController:  node <dc:title>Die �rzte : NEU: Noise</dc:title>, node-name: dc:title node-type: 1 node value:  aber text: Die �rzte : NEU: Noise
Ist da jetzt was im Parser falsch ? Oder hätte ich irgendwo etwas anderes tun müssen ? Oder sonst was falsch gemacht ? (XML::LibXML kennen vermutlich nicht viele)

Grüße Markus

[rudolfkoenig]

Ich gehe davon aus, dass
- bei dem vorherigen Log "attr global encoding unicode" gesetzt war
- dein Modul ohne dieses Attribut mit Ulauten umgehen kann.

Wenn ja, dann muss man hier die

$buf = Encode::decode('UTF-8', $buf) if($unicodeEncoding);

Zeile vor dem Uebernehmen der Daten in die FHEM-Variablen (bzw. FHEM-Framework-Funktionsufrufen) durchfuehren.

[KölnSolar]

Hi Rudi,
danke fürs Feedback.

Ich gehe davon aus, dass
- bei dem vorherigen Log "attr global encoding unicode" gesetzt war

Nein, das gehört zu den nicht verstandenen 30%. 
Ist das

- dein Modul ohne dieses Attribut mit Ulauten umgehen kann.

jetzt alternativ gemeint oder besteht wie geschrieben ein Zusammenhang ?

Wichtig: Das Log ist ja schon recht alt. Macht es Sinn den User mal zu bitten mit einem aktuellen FHEM und mal mit und mal ohne Attribut ein Log zur Verfügung zu stellen ?

Grüße Markus

[rudolfkoenig]

Nein, das gehört zu den nicht verstandenen 30%

Wenn Du Glueck hast, dann kann _dieses_ Problem mit "attr global encoding unicode" geloest werden, weil die Bibliothek automatisch unicode macht, und die Konvertierung zu dem FHEM-Standard utf-8 bytestream nicht durchgefuehrt wurde.

Ansonsten wird es kompliziert, und sollte nicht in diesem Thema diskutiert werden.
Aber bitte nur nach einem FHEM-update und erneuten Tests.

[zap]

Für HMCCU & Co kann ich dich beruhigen. Hab schon gut eine Woche umgestellt und kann bisher keine Probleme erkennen. Selbst ein Device mit Umlaut im Namen schaut korrekt aus.

Erstaunlich. Eigentlich müsste die CCU und ihre Schnittstellen iso-8859-1 verwenden. Ich hatte verstanden, dass in diesem Fall das Modul die Daten nach UTF-8 konvertieren muss.

[Adimarantis]

Mit der plotAsPng() Funktion habe ich noch den Effekt, dass bei encoding=unicode alle Linien (und deren Legende) in schwarz dargestellt werden. Davon abgesehen schauen die pngs ok aus.
Die normale Darstellung in FHEMWEB ist nicht betroffen.

[rudolfkoenig]

Bist du ganz sicher, dass das an dem unicode Wert liegt?

Erstens sollten SVG-Farben wenig mit Sonderzeichen zu tun haben, zweitens gibt es ein bekanntes Problem,  mit dem gleichen Symptom: https://forum.fhem.de/index.php?topic=116138

[Adimarantis]

Du hast recht. Das Phänomen tauchte zwar auffällig zeitnah mit der Umstellung nach unicode auf, aber lasst sich durch das Attribut plotAsPngFix beheben. Muss wohl ein libsvg update unter Raspberry "buster" gewesen sein (librsvg-2.so.2.44.10) auf meinem "bytestream"-Testsystem unter "bullseye" funktioniert es auch ohne fix-attribut (librsvg-2.so.2.47.0)

[Adimarantis]

@Rudi: Da ich nicht weiss ob du in dem Riesen FTUI3 Thread mitliest:
https://forum.fhem.de/index.php/topic,115259.msg1245354.html#msg1245354

Da geht es darum, dass JsonList2 im unicode Modus "<BINARY>" liefert wenn FTUI Strings mit Umlauten in Readings anfordert.

[rudolfkoenig]

Danke fuer den Hinweis, habs gefixt.