Umlaute werden nicht korrekt angezeigt

[mbhomie007]

Describe the issue you are experiencing

Umlaute werden nicht korrekt angezeigt seit Version RaspberryMatic 3.63.8.20220330

Describe the behavior you expected

Umlaute werden korrekt übersetzt.

Steps to reproduce the issue

1. Klick auf "Direkte Verknüpfungen"
2. Klick auf "Programme"
3. Klick auf "Programme bearbeiten"

What is the version this bug report is based on?

3.63.8.20220330

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

-

Additional information

[roe1974]

Ist auch unter Status/Programme und Programme und Zentralverknüpfungen. Siehe:

[Baxxy13]

Bei den DV's lässt sich zumindest die "Verknüpfungsbeschreibung" leicht durch "umbenennen", also ersetzen der kryptischen Zeichen durch z.B. das "ü" korrigieren.

Bei den Programmen habe ich das noch nicht gesehen, wie sollte der Text heißen?
Bei mir werden da "ö" und "ü" korrekt dargestellt.

Schon interessant... im Forum wurde auch schon von Umlaut-Problemen beim Mail und hm_pdetect - AddOn berichtet.

[mbhomie007]

Bei den DV's lässt sich zumindest die "Verknüpfungsbeschreibung" leicht durch "umbenennen", also ersetzen der kryptischen Zeichen durch z.B. das "ü" korrigieren.

Ist eine Möglichkeit, aber irgendwie schon nervig bei so vielen Verknüpfungen das manuell zu korrigieren...

Schon interessant... im Forum wurde auch schon von Umlaut-Problemen beim Mail und hm_pdetect - AddOn berichtet.

Komisch das es jetzt plötzlich an so vielen Stellen zu Problemen kommt...

[roe1974]

@Baxxy13 .... bei den Programmen kommt es durch eine spezielle Zeichenkette die ich mitschicke für Telegram. Siehe:

[roe1974]

PS: Auch in den Direktverknüpfungen stimmt das "ü" nur in einigen Spalten nicht, in der ersten Spalte passt das "ü". Siehe:

[jens-maus]

Nur kurze Zwischeninfo: Das Problem wird vmtl. aus dem Update von tclsh 8.2.x zu 8.6.x das ja in der aktuellen RaspberryMatic mit umgesetzt wurde resultieren. Interessant ist, das es wohl nur an ausgewählten Stellen der WebUI auftritt. Müsste mal überprüft werden ob (wenn man da die Umlaute nochmal eingibt) am schluss in der ReGa/regadom bzw den entsprechenden Objectdaten fälschlicherweise UTF8 kodierter Text nun landet.

Auch werden die aktuellen Probleme mit falscher Umlautdarstellung aus dem gleichen Problem heraus bzw. der aktuelleren tclsh version resultieren für die mal vllt das character encoding auf latin1 irgendwie fixieren müsste oder an den jeweiligen Stellen in den addons bzw der webui dann fixes erarbeiten müsste.

Auch müsste mal überprüft werden was jetzt passiert wenn man mit der aktuellen Version die falschen Umlaute anpasst und dann zurück zu einer älteren Version geht ob da dann die Neu gesetzten Umlaute bei alten Versionen dann falsch angezeigt werden.

[Baxxy13]

Die Texte für HmIP-Direktverknüpfungen stehen in...
/usr/local/etc/config/crRFD/data/linkData.conf

Beispiel:
"name":"HmIP-RCV-50 HmIP-RCV-1:6 mit HmIP-SMI55 5A4:4 - Bewegungserkennung unterdrücken","description":"Standardverknüpfung Taster - Unterdrückung Bewegungserkennung"

Für HM DV's habe ich noch nichts gefunden, auch nicht in der regadom.

[Baxxy13]

Auch müsste mal überprüft werden was jetzt passiert wenn man mit der aktuellen Version die falschen Umlaute anpasst und dann zurück zu einer älteren Version geht ob da dann die Neu gesetzten Umlaute bei alten Versionen dann falsch angezeigt werden.

Zurück auf die 3.61.7.20220226 sind die händisch korrigierten Umlaute in der DV-Übersicht weiterhin korrekt.

Mal sehen was passiert wenn ich dann wieder auf 3.63.8.20220330 hochgehe.

[Baxxy13]

Wieder auf der 3.63.8.20220330 sieht alles weiterhin normal aus.

[jens-maus]

Und wie sieht es in der linkData nach der Änderung mit der 3.63.8 aus? Gibt es einen unterschied daran im vergleich zur älteren version? Und was ist mit BidCos vs HmIP Direktverknüpfungen? Beide haben probleme mit umlauten in der 3.63.8?

[roe1974]

Ich habe nur BidCos und wie oben im Screenshot ersichtlich ebenfalls die Probleme mit Umlauten.

[Baxxy13]

Es reiht sich übrigens ein mir unbekanntes "LG-TV addon" in die Umlaut-Problematik ein.

Nachdem ich die /usr/local/etc/config/crRFD/data/linkData.conf in der 3.63.8.20220330 händisch korrigiert hatte blieb diese beim Ausflug nach 3.61.7.20220226 so, und ist nun auch so beim neuerlichen Update auf 3.63.8.20220330 so (korrekt) geblieben.

[Baxxy13]

eine spezielle Zeichenkette die ich mitschicke für Telegram

Darf ich das mal für ungültig erklären? ;-)

Hab's mit der 3.61.7.20220226 "nachgebaut" ...

Das sieht nicht besser aus. Die WebUI ist für sowas einfach nicht gemacht.

[jens-maus]

Es reiht sich übrigens ein mir unbekanntes "LG-TV addon" in die Umlaut-Problematik ein.

Nachdem ich die /usr/local/etc/config/crRFD/data/linkData.conf in der 3.63.8.20220330 händisch korrigiert hatte blieb diese beim Ausflug nach 3.61.7.20220226 so, und ist nun auch so beim neuerlichen Update auf 3.63.8.20220330 so (korrekt) geblieben.

D.h. Sie ist md5 checksummen technisch exakt gleich egal ob mit der neuen oder alten RaspberryMatic die umlaute gesetzt werden? Wenn ja, dann wird vmtl dieser text noch irgendwo anders in der regadom z.b. hinterlegt?!?

[Baxxy13]

Puhh... ich habe nur drübergeschaut.
Mann müsste mal ein Szenario erstellen mit dem man das leicht nachstellen kann, idealerweise ohne Geräte.

In der regadom hatte ich nix gefunden.

[roe1974]

@Baxxy13 ... darfst du ;-)
Dann ist das schon länger so ... sorry und danke :-)

[MichaelN0815]

Ich kann diesen Bug nicht nachvollziehen. Auch unter 3.63.8.20220330 sind bei mir noch alle Umlaute korrekt. Wobei ich prinzipiell Umlaute eher vermeide. Es muss also mehr als nur "Umlaut in Programmbeschreibung" zutreffen.

[Baxxy13]

Black hat davor gewarnt spezielle Funktionen des SDV (die TCL nutzen) zu benutzen. Also Vorsicht!

[mbhomie007]

Puhh, also betrifft es jetzt sämtliche Addons wie: pdetect, E-Mail, LG-TV; die WEB-UI selbst und Blacks SDV...

[jens-maus]

Habe nun in e187501 Änderungen in RaspberryMatic bzw. tcl 8.6 eingebaut die das Zeichensatz Encoding verhalten wieder in der vorherigen 8.2 Art&Weise von tcl stattfinden lassen sollte (Nutzung des 'identity' encodings als Standard). Das ganze ist leider ein ziemliches internes Durcheinander zwischen tcl, der WebUI, externen APIs, usw. und eigentlich stellen IMHO diese Änderungen zurück zum alten tcl 8.2 Verhalten nur einen Workaround für ein Problem dar das wir bzw. die CCU schon immer durch die alte 8.2 Version mitgeschleppt hat. Im Grunde wäre es eigentlich besser jetzt alle Addons, externen Apps, etc. auf das neue Verhalten der tcl 8.6 anzupassen um das Problem zu beseitigen. Das würde aber auch bedeuten, das jetzt eben alle Addons+Apps die tcl verwenden angefasst werden müssten um das auch in einer rückwärtskompatiblen Art&Weise umzusetzen damit dieser auch mit alten tcl Versionen noch lauffähig ist.

Lange Rede, kurzer Sinn: Ich bitte darum mit dem morgigen nightly snapshot nochmal alle möglichen intensiven Tests mit Umlauten in der WebUI, Addons, externen Apps, etc. durchzuführen und auch das downgrade auf vorherige Versionen zu testen damit wir sichergehen können das mit der nächsten Version wirklich alle diese Umlautprobleme beseitigt sind und man wie mit vorherigen RaspberryMatic Versionen zumindest an gewissen Stellen Umlaute wieder korrekt verwenden kann.

[Baxxy13]

Die WebUI mit einer .ova zu testen ist ja recht leicht...
Einfach in der 3.61.7.20220226 eine DV virt.Taste <--> Schaltaktor anlegen und dann auf 3.63.8.20220330 updaten.

Damit hat man den aktuellen Stand (falscher Umlaut in der DV Beschreibung) reproduziert.

Aber wie weiter?
A: mit falschem Umlaut
von 3.63.8.20220330 auf Nightly von morgen

B: mit händisch korrigiertem Umlaut
von 3.63.8.20220330 auf Nightly von morgen

Wie sieht der ideale Testfahrplan aus?

[jens-maus]

Ich würde beides machen. D.h. Drei DVs anlegen mit der 3.61.7., dann updaten auf offizielles 3.63.8 release, dort eine DV anpassen, dann auf nightly build wechseln und dort die zweite DV anpassen und die anderen kontrollieren. Dann zurück auf die 3.61.7 und schauen ob noch alles i.o. Und dann am schluss nochmal auf die nightly build und nochmal kontrollieren.

Achja, und mit dem nightly snapshot dann exzessiv überall mal mit umlauten arbeiten/testen ob damit alles geht usw.

[Baxxy13]

So, die Tests für die Umlautprobleme bei den DV's sind durch (nur HM getestet).

A: RM_DV_Ausgangslage_3.61.7.20220226:

B-1: RM_DV_Ausgangslage_3.63.8.20220330 (direkt nach Update von A)

B-2: RM_DV_DV1_manuell_korrigiert_3.63.8.20220330

C: RM_DV_Ausgangslage_3.63.8.20220405 (nach Update von B-2)

D: RM_DV_zurueck_zu_3.61.7.20220226 (nach downgrade von C)

E: RM_DV_Ausgangslage2_3.63.8.20220330 (nach Update von D)

F: RM_DV_von_3.61.7.20220226_auf_3.63.8.20220405

Sieht zumindest in diesem Bereich erstmal gut aus würde ich sagen.

[jens-maus]

Sieht zumindest in diesem Bereich erstmal gut aus würde ich sagen.

Danke! Auch meine Tests bzgl. hm_pdetect Addon usw. scheinen soweit nun zu passen wie ich das testen konnte. Ich denke daher, das man das Issue hier schließen kann.

Eine kleine Ungereimtheit ist mir jedoch in der jetzt in den in der WebUI korrekt angezeigten Umlaute bei Direktverknüpfungen noch aufgefallen: Wirft man z.B. einen Blick in die /etc/config/crRFD/data/linkData.conf Datei mittels folgendem Kommando zur Ausgabe der Datei als hexadezimal Werte:

# hexdump -C /etc/config/crRFD/data/linkData.conf | grep pfung | tail -10
00006120  6e c3 83 c2 bc 70 66 75  6e 67 20 42 65 77 65 67  |n....pfung Beweg|
00006300  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000063c0  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000065a0  c2 bc 70 66 75 6e 67 20  45 69 6e 67 61 6e 67 73  |..pfung Eingangs|
000066b0  65 72 6b 6e c3 83 c2 bc  70 66 75 6e 67 20 54 61  |erkn....pfung Ta|
00006880  6b 6e c3 83 c2 bc 70 66  75 6e 67 20 54 61 73 74  |kn....pfung Tast|
000069f0  83 c2 bc 70 66 75 6e 67  20 54 61 73 74 65 72 20  |...pfung Taster |
00006aa0  83 c2 bc 70 66 75 6e 67  20 45 69 6e 67 61 6e 67  |...pfung Eingang|
00006be0  72 6b 6e c3 83 c2 bc 70  66 75 6e 67 20 45 69 6e  |rkn....pfung Ein|
00006ca0  72 6b 6e c3 83 c2 bc 70  66 75 6e 67 20 54 61 73  |rkn....pfung Tas|

Dann fällt auf das die Umlaute hier in der *.conf Datei falsch utf-8 kodiert abgelegt werden. Das ü von "Standardverknüpfung" sollte hier lediglich mit einer 2-byte c3 bc Zeichenfolge kodiert werden. Jedoch sieht man das hier offensichtlich die 4-byte Hexwerte c3 83 c2 bc verwendet werden was wiederum der eigentlich falschen ü Zeichnkette entspricht.

Das erklärt meines Erachtens auch, dass in der 3.63.8.20220330 mit der ungepatchten tcl 8.6 version die Umlaute in der WebUI falsch dargestellt wurden - eben weil sie im Grunde falsch in der conf Datei falsch abgelegt werden und folglich auch via XMLRPC getLinks dann auch falsch ausgeliefert werden. Die WebUI mit der zurückgepatchten tcl 8.6 version (die standardmäßig wieder die 'identity' Zeichenkodierungserkennung verwendet) konvertiert dann diese zwar falsch abgelegten Zeichen jedoch für die WebUI wieder (vmtl. zufälligerweise) in korrekt lesbare Umlaut-Zeichen. Aber im Grunde liegen wie gesagt die Umlaute falsch in der linkData.conf Datei und sollten entweder korrekt als 2-byte utf8 Zeichen abgelegt werden oder als iso8859-1 Zeichen.
Denn ich bin mir relativ sicher, das wenn man sich jetzt via XMLRPC getLinks Kommando die Daten der Direktverknüpfungen inkl. Description ausgeben lassen würde, dann bekommt man sicherlich auch diese falschen Umlautkodierungen zurück und muss die irgendwie anders behandeln bzw. genauso verkurkst zurückkonvertieren wie die WebUI. Nur gibt es eben bisher meines Wissens keine externe App (ausser vllt. Homematic Manager) der die Direktverknüpfungen inkl. Description anzeigt/auswertet und daher ist das bis dato noch nicht wirklich aufgefallen.

[Baxxy13]

Hmm, 1:1 identisch (3.61.7.20220226 <-> 3.63.8.20220405-d2a744) ist das Encoding Verhalten aber noch nicht.
Zumindest nicht im Systemprotokoll.

Ich nutze ein "Mini-Addon" aus dem Forum >Link< um das Systemprotokoll im separaten Browserfenster dauerhaft anzuzeigen.
(sehr praktisch, sollten wir vielleicht optimieren und assimileren ;-)

Damit klappt die Umlaut-Anzeige mit der 3.61.7.20220226 und der 3.63.8.20220330 problemlos.
Mit dem heutigen Nightly aber nicht mehr, da gibts nur Zeichensalat.

[jens-maus]

Hmm, 1:1 identisch (3.61.7.20220226 <-> 3.63.8.20220405-d2a744) ist das Encoding Verhalten aber noch nicht. Zumindest nicht im Systemprotokoll.

Also in der WebUI selbst kann ich da keinerlei Fehlverhalten feststellen. Du?

Ich nutze ein "Mini-Addon" aus dem Forum >Link< um das Systemprotokoll im separaten Browserfenster dauerhaft anzuzeigen. (sehr praktisch, sollten wir vielleicht optimieren und assimileren ;-)

Öhhmm, reusper. Hab mir das "Addon" gerade mal schnell angeschaut. Das ist ziemlicher Salat und nicht wirklich IMHO ausgegoren und wie es die History ausliest ist auch ziemlich von "hinten durch die Brust ins Auge". Aber sei's drum. Der Grund wieso die Umlaute dort nicht korrekt dargestellt werden ist recht einfach erklärt. Der Autor hat vergessen ganz oben beim übergeben des Content-Type: auch den charset: als utf-8 mit anzugeben.

Einfach die Zeile wie folgt abändern und dann sollte es gehen:

puts "Content-type: text/html; charset=utf-8\n\n<!DOCTYPE html>"

Probier mal dein Glück.

[Baxxy13]

Die WebUI-Anzeige des Systemprotokoll's passt in allen 3 Versionen.

Das das "AddOn" ziemlich mit der heißen Nadel gestrickt ist habe ich trotz mangelnder tcl / html Kenntnisse auch bemerkt.
Aber Hauptsache funktioniert...
Und das tut's mit der korrigierten Zeile nun auch mit dem heutigen Nightly.
Danke!

[schmidhorst]

Zumindest bei der RM 3.63.8.20220330 musste ich für korrekte Anzeige der Umlaute
puts "Content-type: text/html; charset=iso-8859-1\n\n<!DOCTYPE html>"
in die cgi-Datei des Mini-Addons eintragen.

Mir war in den letzten Tagen bei der Raspberry-Matic aufgefallen, dass das €-Symbol (z.B. als Einheit bei einer Systemvariablen) zunächst funktionierte, und dann aber plötzlich zu einem %u20AC wurde. Habe die SysVar incl. Unit per Skript angelegt und das Skript mal direkt in RM, mal über den SDV ausgeführt. Ich habe aber nicht untersucht, ob's am hin- und her-kopieren zwischen SDV und RM lag oder an der aktuellen RM-Version.