FHEM und UNICODE, first aid

Begonnen von herrmannj, 08 Februar 2022, 19:28:02

Vorheriges Thema - Nächstes Thema

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

############# 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 Ä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 Ärzte : NEU: Noise</dc:title>......
2021.11.11 00:20:33 4: DLNAController:  dom structure: <?xml version="1.0"?>
<Event xmlns=....
<dc:title>Die Ärzte : NEU: Noise</dc:title>
2021.11.11 00:20:33 4: DLNAController:  LastChange xml event with root <Event xmlns=...<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>...
2021.11.11 00:20:33 4: DLNAController:  node ...<dc:title>Die Ä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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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
Zitat$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.
ZitatIch gehe davon aus, dass
- bei dem vorherigen Log "attr global encoding unicode" gesetzt war
Nein, das gehört zu den nicht verstandenen 30%.  :-[ ;D
Ist das
Zitat- 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

ZitatNein, 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

Zitat von: Adimarantis am 23 Februar 2022, 20:43:27
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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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)
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

rudolfkoenig

Danke fuer den Hinweis, habs gefixt.