hiho,
seit dem heutigen update bekomme ich defekte umlaute im floorplan.
spiele ich das alte 01_fhemweb zurück, sind meine umlaute wieder da.
Das FLOORPLAN Modul ist seit Jahren verwaist.
Kannst Du was zum Nachstellen basteln?
Oder wenigstens ein Screenshot und die problematischen Konfigurationsteile?
das Gleiche bei mir mit den Umlauten beim Wettermodul.
Solche Meldungen ohne Details bzw. was zum Nachstellen erhoehen nur das Widerwillen zum helfen.
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.
Wenn es OK ist, dann brauche ich nichts zum Nachstellen, das kann ich selber :)
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.
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
Zitat von: the ratman am 07 Februar 2022, 13:50:10
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.
Zitat von: the ratman am 07 Februar 2022, 13:50:10
und ne dumme frage:
Die Frage ist nicht dumm, und die Antwort ist ziemlich simpel.
Zitat von: the ratman am 07 Februar 2022, 13:50:10
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.
Selbes Problem mit "normalen" FHEMWEB.
# 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
Signalverstärker WZ
angezeigt.
ZitatSelbes Problem mit "normalen" FHEMWEB.
Danke fuers Beispiel.
Leider kann ich es nicht nachstellen (s.u), und habe noch keine Ahnung, wo es schiefgeht.
Cfg:
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
cfg/fhem.cfg.test: text/plain; charset=utf-8
hexdump -cx cfg/fhem.cfg.test
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.
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.
Kannst Du bitte die Ausgabe von
{ utf8::is_utf8($defs{HUESensor65562}{name}) }
zeigen?
Der Unterschied zwischen den Version ist, dass im Webinterface alte Version folgendes HTML kommt:
<div class="col1">
<a href="/fhem?detail=deCONZ_HUEDevice14">
[..]
Signalverstärker_AZ
</a>
</div>
In der neuen Version kommt:
<div class="col1">
<a href="/fhem?detail=deCONZ_HUEDevice14">
[..]
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):
fhem> { utf8::is_utf8($defs{HUESensor65562}{name}) }
1
Zitatfhem> { 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.
vielen dank ... ich habe wieder umlaute *g*