[07.02.22 ERLEDIGT] fhemweb macht umlautfehler beim floorplan

[the ratman]

hiho,

seit dem heutigen update bekomme ich defekte umlaute im floorplan.
spiele ich das alte 01_fhemweb zurück, sind meine umlaute wieder da.

[rudolfkoenig]

Das FLOORPLAN Modul ist seit Jahren verwaist.

Kannst Du was zum Nachstellen basteln?
Oder wenigstens ein Screenshot und die problematischen Konfigurationsteile?

[Violinux]

das Gleiche bei mir mit den Umlauten beim Wettermodul.

[rudolfkoenig]

Solche Meldungen ohne Details bzw. was zum Nachstellen erhoehen nur das Widerwillen zum helfen.

[betateilchen]

Viele Details kann ich auch nicht liefern, aber zumindest in meinen weather-devices (DarkSky-API) ist mit den Umlauten alles in Ordnung. Floorplan nutze ich nicht.

[rudolfkoenig]

Wenn es OK ist, dann brauche ich nichts zum Nachstellen, das kann ich selber

[the ratman]

kann auch nix liefern - keine warnings oder so im log. alles rennt, wie es soll in fhem.
ich kann also wirklich nur sagen, dass es mit der alten version sonderzeichen gibt, mit der neuen nicht.
wenn du da mehr infos brauchst: bitte konkret sagen welche und vor allem wie ich daran komme.

und ne dumme frage: wenn der floorplan verwaist ist - was ich übrigens extrem schade finde, weil der einfach so herrlich problemlos macht was ich will, warum hauts ihn dann nicht aus fhem raus? leichen im keller tragen nur zur allgemeinen verwirrung bei, denk ich mal.
oder, was mir lieber wäre: es findet sich einer, der den auf aktuell bürstet.

[MiKn]

habe eben auch ein Update gemacht und beim Anlegen eines neuen Gerätes ist mir das nun smit den Umlauten auch aufgefallen.
Auch beim manuellen ändern des Alias bleiben die Umlaute so "verbogen".

Bei Umlauten im Floorplan bzw in den dazu verwendeten readingsGroup habe ich das nicht. Bild 3

[betateilchen]

wenn du da mehr infos brauchst: bitte konkret sagen welche und vor allem wie ich daran komme.

Mach doch mal zumindest einen Screenshot, auf dem man den Fehler sieht.
Und vielleicht ein list des entsprechenden devices, von dessen readings die falschen Umlaute stammen.

und ne dumme frage:

Die Frage ist nicht dumm, und die Antwort ist ziemlich simpel.

wenn der floorplan verwaist ist - was ich übrigens extrem schade finde, weil der einfach so herrlich problemlos macht was ich will

Genau deshalb: Floorplan läuft herrlich problemlos und wird laut Statistik in fast 900 Installationen vorwendet.

[digairau.caethe]

Selbes Problem mit "normalen" FHEMWEB.

Code Auswählen Erweitern


# grep Signal.*WZ /opt/fhem/fhem.cfg
attr HUESensor65562 alias Signalverstärker WZ
# grep Signal.*WZ /opt/fhem/fhem.cfg  | file -i -
/dev/stdin: text/plain; charset=utf-8
# grep Signal.*WZ /opt/fhem/fhem.cfg  | hexdump -cx
0000000   a   t   t   r       H   U   E   S   e   n   s   o   r   6   5
0000000    7461    7274    4820    4555    6553    736e    726f    3536
0000010   5   6   2       a   l   i   a   s       S   i   g   n   a   l
0000010    3635    2032    6c61    6169    2073    6953    6e67    6c61
0000020   v   e   r   s   t   ?   ?   r   k   e   r       W   Z  \n   
0000020    6576    7372    c374    72a4    656b    2072    5a57    000a
000002f


Wird im Web Interface als

Code Auswählen Erweitern


Signalverstärker WZ

angezeigt.

[rudolfkoenig]

Selbes Problem mit "normalen" FHEMWEB.

Danke fuers Beispiel.
Leider kann ich es nicht nachstellen (s.u), und habe noch keine Ahnung, wo es schiefgeht.

Cfg:

Code Auswählen Erweitern

attr global statefile log/fhem.state.test
define w FHEMWEB 8083 global
define t telnet 7072
define ac autocreate
define d dummy
attr d alias Verstärker


file -i cfg/fhem.cfg.test

Code Auswählen Erweitern

cfg/fhem.cfg.test: text/plain; charset=utf-8


hexdump -cx cfg/fhem.cfg.test

Code Auswählen Erweitern

0000000   a   t   t   r       g   l   o   b   a   l       s   t   a   t
0000000    7461    7274    6720    6f6c    6162    206c    7473    7461
0000010   e   f   i   l   e       l   o   g   /   f   h   e   m   .   s
0000010    6665    6c69    2065    6f6c    2f67    6866    6d65    732e
0000020   t   a   t   e   .   t   e   s   t  \n  \n   d   e   f   i   n
0000020    6174    6574    742e    7365    0a74    640a    6665    6e69
0000030   e       w       F   H   E   M   W   E   B       8   0   8   3
0000030    2065    2077    4846    4d45    4557    2042    3038    3338
0000040       g   l   o   b   a   l  \n  \n   d   e   f   i   n   e   
0000040    6720    6f6c    6162    0a6c    640a    6665    6e69    2065
0000050   t       t   e   l   n   e   t       7   0   7   2  \n   d   e
0000050    2074    6574    6e6c    7465    3720    3730    0a32    6564
0000060   f   i   n   e       a   c       a   u   t   o   c   r   e   a
0000060    6966    656e    6120    2063    7561    6f74    7263    6165
0000070   t   e  \n  \n   d   e   f   i   n   e       d       d   u   m
0000070    6574    0a0a    6564    6966    656e    6420    6420    6d75
0000080   m   y  \n   a   t   t   r       d       a   l   i   a   s   
0000080    796d    610a    7474    2072    2064    6c61    6169    2073
0000090   V   e   r   s   t 303 244   r   k   e   r  \n               
0000090    6556    7372    c374    72a4    656b    0a72               
000009c


Darstellung siehe Anhang.

[digairau.caethe]

Gut die cfg ist gleich kodiert. "c3 a4" für den Umlaut.
Interessant ist, dass es im Edit-Feld richtig angezeigt wird. Siehe Anhang (oben falsch, unten richtig).

Ich kann noch ein paar Basisdaten liefern:

Bei mir läuft das auf einem RaspberryPi4

• ARMv7 Processor rev 3 (v7l) @ 270 bMips, 4 cores
• Raspbian Linux 10
• Linux 5.10.63-v7l+ on armv7l
• This is perl 5, version 28, subversion 1 (v5.28.1) built for arm-linux-gnueabihf-thread-multi-64int

und definitiv besteht das Problem erst seit dem Update.

[rudolfkoenig]

Kannst Du bitte die Ausgabe von

Code Auswählen Erweitern

{ utf8::is_utf8($defs{HUESensor65562}{name}) }

zeigen?

[digairau.caethe]

Der Unterschied zwischen den Version ist, dass im Webinterface alte Version folgendes HTML kommt:

Code Auswählen Erweitern


                                    <div class="col1">
                                        <a href="/fhem?detail=deCONZ_HUEDevice14">
[..]
                                            &nbsp;Signalverstärker_AZ
                                        </a>
                                    </div>


In der neuen Version kommt:

Code Auswählen Erweitern


                                    <div class="col1">
                                        <a href="/fhem?detail=deCONZ_HUEDevice14">
[..]
                                            &nbsp;Signalverstärker_AZ
                                        </a>
                                    </div>
                                </td>


Entfernt wurde jeweils der SVG Teil. Sieht aus als ob der UFT8-String als ISO-String behandelt und so reingeschieben wird.

Zu deiner Frage (neue Version):

Code Auswählen Erweitern

fhem> { utf8::is_utf8($defs{HUESensor65562}{name}) }
1

[rudolfkoenig]

fhem> { utf8::is_utf8($defs{HUESensor65562}{name}) }
1

Seufz.

FHEM-Intern sollten alle Strings als utf-8 Bytefolge gespeichert werden.
Ob das klug ist oder geaendert werden soll und wenn ja wie, ist Gegenstand einer aktuellen Diskussion, sie bitte nicht hier fuehren.

Offensichtlich wurde $defs{...}[name} mit dem perl-internen unicode-bit "infiziert", obwohl es schon als utf-8 Bytefolge vorlag.
Um websocket Probleme zu vermeiden wird seit kurzem alles, was mit so einem bit infiziert ist, per utf8_encode nach utf-8 konvertiert.

Offensichtlich gibt es etliche Module, die mit "infizierten" utf-8 Bytecodes herumlaufen.
Andere Module enthalten "echte" Unicode Strings mit Character > 255, entgegen der aktuellen Festlegung.
Leider gibt es auch Varianten, die Unicode-Strings mit Character < 255 haben, das hat das websocket Problem ausgeloest.

Ich habe die FHEMWEB Pruefung auf "Unicode" jetzt auf die urspruengliche, enger gefasste Version zurueckgeaendert (is_utf8 && char > 255)
Bedeutet zwar, dass das Problem im https://forum.fhem.de/index.php?topic=125866 jetzt wieder auftaucht, allerdings betrifft das deutlich weniger Benutzer.