WebSocket: Invalid frame header

[timmib]

Guten Tag,

ich würde hier gerne nochmal hier auf das/mein Problem mit websockets bei HTTPS hinweisen.
https://forum.fhem.de/index.php/topic,114505.msg1087635.html#msg1087635

Eventuell war es damals auch das falsche Unterforum bei den UIs, denn der Server gibt ja laut Chrome den kaputten Response zurück.

wss://pitwo:8083/fhem/?XHR=1&inform=type=status;filter=HIER_JEDE_MENGE;since=1643568603347;fmt=JSON&timestamp=1643568604336

Viele Grüße

Tim

[rudolfkoenig]

Ich gehe davon aus, dass das Problem nicht generisch ist, sonst haette man das frueher schon gemeldet.
Dafuer spricht auch, dass laut Beitrag das Problem TabletUI spezifisch ist.

Ich helfe gerne, allerdings brauche ich etwas zum nachstellen des Problems.

[timmib]

Hallo Rudolf,

ja, das wird wohl etwas schwierig nachzustellen.

Ich hab mal grad meine FHEM Entwicklung VM auf HTTPS umgestellt und die produktive fhem.cfg dort genutzt.
Da kommen leider nicht genug Frames bis der Fehler kommt.

Ich hab mal alternativ auf der produktiven Instanz mit allerlei WebSocket Chrome Extensions probiert etwas rauszufinden. Die laufen aber auch nur recht früh auf den Fehler, aber ohne weitere Details.
Der "WebSocket King client" meldet auch nur:

An unknown error occurred: {"isTrusted":true}.

Was mich da nur wundert, sind die diversen SVG Grafiken aus den states die da verschickt werden.

z.B.

Code Auswählen Erweitern

["HUEDevice5","off","<div id=\u0022HUEDevice5\u0022  title=\u0022off\u0022 class=\u0022col2\u0022><a href=\u0022/fhem?cmd.HUEDevice5=set HUEDevice5 toggle&room=HUEDevice&fwcsrf=csrf_551213403330698\u0022><svg class=\u0022 off\u0022 data-txt=\u0022off\u0022 version=\u00221.0\u0022 xmlns=\u0022http://www.w3.org/2000/svg\u0022  width=\u0022468pt\u0022 height=\u0022617pt\u0022 viewBox=\u00220 0 468 617\u0022  preserveAspectRatio=\u0022xMidYMid meet\u0022> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform=\u0022translate(0,617) scale(0.221801,-0.221801)\u0022  stroke=\u0022none\u0022> <path d=\u0022M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z\u0022/> <path d=\u0022M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z\u0022/> <path d=\u0022M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z\u0022/> <path d=\u0022M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z\u0022/> <path d=\u0022M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z\u0022/> <path d=\u0022M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z\u0022/> <path d=\u0022M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z\u0022/> <path d=\u0022M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z\u0022/> <path d=\u0022M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z\u0022/> <path d=\u0022M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z\u0022/> <path d=\u0022M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z\u0022/> <path d=\u0022M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z\u0022/> <path d=\u0022M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z\u0022/> <path d=\u0022M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z\u0022/> <path d=\u0022M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z\u0022/> </g> </svg></a></div>"]

Eine Möglichkeit wäre, da Logging in FHEM selber einzubauen, um dann zu vergleichen, wo er aussteigt.

Ich hab es mal mit fiddler aufgezeichnet. Er meint auch "ProtocolError". Siehe Screenshot. Evtl. sagt es Dir ja was.

Viele Grüße

Tim

[timmib]

Ich hab es nochmal ein paar mal probiert. Es endet immer mit einer 25, also einem "end of medium".

[timmib]

Ich habe es nun auch mal mit HTTP (ohne S) probiert und auch funktioniert es nicht mehr.

Die Fehlermeldung in der Chrome Developer Console sagt:

Code Auswählen Erweitern

failed: Could not decode a text frame as UTF-8.

Da scheint also wirklich etwas korruptes über geschickt zu werden was kein Text ist.

Die Stelle im Code wäre in 01_FHEMWEB.pm

Code Auswählen Erweitern

sub
FW_Read($$) korrekt?

[rudolfkoenig]

FW_Read ist korrekt.
Eigentlich muss man Daten FHEM-intern als UTF-8 vorhalten, leider halten sich manche Module nicht strikt an diese Richtlinie.
Jetzt muesste man das Modul rausfinden, das der Verursacher ist.

[timmib]

OK,

das heißt ich bau hier mal provisorisch logging ein:

Code Auswählen Erweitern

   
    my $ret = FW_fC($data);
    FW_addToWritebuffer($hash,
                       FW_longpollInfo("JSON", defined($ret) ? $ret : "")."\n");
    $hash->{BUF} = substr($hash->{BUF}, $i+$len);
    FW_Read($hash, 1) if($hash->{BUF});
    return;

[timmib]

Also es liegt nicht an einem bestimmten Gerät.

Ich habe eine Stelle gefunden, wo es im Browser aufhört. Das Device habe ich deaktiviert, aber es passiert weiterhin.

Außerdem habe ich mal FW_addToWritebuffer ausgegeben und dort sind auch immer nur Nachrichten kleiner 65536.

Können wir da mal gemeinsam draufschauen?

[rudolfkoenig]

Außerdem habe ich mal FW_addToWritebuffer ausgegeben und dort sind auch immer nur Nachrichten kleiner 65536.

Ich meine so einfach ist die Pruefung auf "gueltiges UTF-8" nicht.

[timmib]

Ja, die Länge war eine andere Vermutung als das UTF-8.

Wie geschrieben, ich habe eine Stelle gefunden wo er aussteigt. Das war aber eine "normales" Homematicgerät mit dem es Serverseitig weiterging und im Client nicht. Die Deaktivierung dieses Homematicgeräts hat auch nix gebracht.

[herrmannj]

FW_Read ist korrekt.
Eigentlich muss man Daten FHEM-intern als UTF-8 vorhalten, leider halten sich manche Module nicht strikt an diese Richtlinie.
Jetzt muesste man das Modul rausfinden, das der Verursacher ist.

ähhm. sorry für kapern - aber fhem intern UTF-8 per policy? Als Character Stream oder Bytestream? Wo steht das denn? Im Kern würde ichs gut finden - macht aber konkret keinen Sinn. Perl intern ist theoretisch unicode. UTF8 ist ja nur eine (externe) Spezifikation und dort gilts es zwischen https://perldoc.perl.org/perlunicode#Byte-and-Character-Semantics zu unterscheiden. Wenn wir uns darauf einigen könn(t)en dass fhem intern alles Unicode ist und alle Schnittstellen extern utf8 byte (unless otherwise specified;) ), das wäre gut. Dann würde length('ö') immer 1 ergeben und/oder diverse regex vorhersagbarer funktionieren. Falls ich was verpasst habe, lern ich gern nach .

[timmib]

Lieber Rudolf,

du hattest natürlich Recht.

Der Schuldige war https://forum.fhem.de/index.php/topic,113820.165.html

Der Umlaut in "Verstärken" im Reading wurde auch im FHEM-WebUI als Fragezeichen in einer Raute dargestellt. Ich sag dem Entwickler bescheid.

Da ist aber noch ein Modul.... grrr.

[rudolfkoenig]

Als Character Stream oder Bytestream?

UTF-8 als Character-Stream sagt mir nichts, insofern Bytestream. Es ist mir klar, dass andersrum auch Vorteile hat, allerdings sind diese gegenueber der aktuell verwendeten nicht so gewaltig, dass ein Umbau aller(!) input/output Schnittstellen sich deswegen lohnen wuerde.

[justme1968]

das fhem intern alles als utf-8 vorhält bzw. vorhalten soll ist nur die halbe wahrheit. die internen strings sind nur byte folgen im utf-8 encoding die bei ausgabe über fhemweb als utf-8 encoded verkauft werden. es sind aber keine echten perl utf-8 (upgraded) strings. das bedeutet leider das alle perl routinen die auf zeichen basis arbeiten wie regex, in, explizite längen bestimmung oder implizite bei printf nicht korrekt funktionieren sobald ein charakter mit mehr als einem byte ins spiel kommt. typischweise sind das alle umlaute. deshalb gibt es intern auch schon einige workarounds bei einigen regexen.

das umstellen auf korrektes und vollständiges unicode handling wär zwar mit einigem aufwand verbunden, hätte am ende aber so viele vorteile das ich dafür wäre das zu stemmen. nicht zuletzt würden damit künstliche einschränkung für device und reading namen weg fallen die es nämlich genau deshalb gibt weil die diversen regexe die auf word oder zeichen matchen für die fhem ,unicode' variante nicht funktionieren wie sie sollten.

vielleicht könnte man damit anfangen fälle und testdaten zu sammeln die aktuell nicht so arbeiten wie erwartet und wünschenswert. sowie tesfälle die das aktuelle verhalten fest halten und das verhalten nach einer umstellung gegenpüfen. ich denke das es den aufwand wert wäre. das gewurschtel das wir immer wieder mit diesem thema haben ist 2022 und eigentlich schon länger nicht mehr zeitgemäß.

[herrmannj]

Ich würde das auch gut finden. Bitte gleich Unicode intern, alles nach aussen utf8. Das wird weh tun weil unzählige workarounds existieren und ehrlich gesagt weiß ich auch nicht genau wie wir das stemmen können weil ich es für unrealistisch halte alle Module zeitgleich umzubauen. Nichts desto trotz, echt nicht mehr zeitgemäß und das sind Versäumnisse der Vergangenheit. Aussitzen geht vielleicht, aber auch nicht ewig und besser wird's auch nicht.

[timmib]

Ich habe es eigentlich schon vorher herausgefunden, aber erst nicht glauben können.

Das HmIP-MP3P aus 88_HMCCUDEV.pm löst auch das Problem reproduzierbar aus. Ich kann da aber kein UTF-8 Problem erkennen. Ein get ... update führt zum direkten Tot des WebSockets.

Ich schreib mal den Maintainer an, bzw. mach ein neues Topic dafür auf.

[timmib]

Leider ist es so, das dies wirklich nur im HTTPS Modus auftritt. Siehe Screenshot, da kann man es deutlich sehen  (links=HTTPS, rechts=HTTP).

Code Auswählen Erweitern

["HmIP_MP3P_Terrasse","BLACK","<div id=\u0022HmIP_MP3P_Terrasse\u0022  title=\u0022BLACK\u0022 class=\u0022col2\u0022><a href=\u0022/fhem?cmd.HmIP_MP3P_Terrasse=set HmIP_MP3P_Terrasse on&room=Homematic&fwcsrf=csrf_354023319534818\u0022>BLACK</a></div>"]
["HmIP_MP3P_Terrasse-2.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-2.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.SOUNDFILE","INTERNAL_SOUNDFILE","INTERNAL_SOUNDFILE"]
["HmIP_MP3P_Terrasse-2.SOUNDFILE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.SECTION","0","0"]
["HmIP_MP3P_Terrasse-2.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-2.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.LEVEL","0","0"]
["HmIP_MP3P_Terrasse-2.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-2.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-2.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-2.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-6.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.SECTION","0","0"]
["HmIP_MP3P_Terrasse-6.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-6.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.COLOR","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-6.COLOR-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-color","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-color-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.COLOR_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-6.COLOR_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-6.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-control","off","off"]
["HmIP_MP3P_Terrasse-control-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.LEVEL","off","off"]
["HmIP_MP3P_Terrasse-6.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-pct","off","off"]
["HmIP_MP3P_Terrasse-pct-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-level","off","off"]
["HmIP_MP3P_Terrasse-level-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-6.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-6.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-9.WEEK_PROGRAM_CHANNEL_LOCKS","0","0"]
["HmIP_MP3P_Terrasse-9.WEEK_PROGRAM_CHANNEL_LOCKS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-5.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.COLOR","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-5.COLOR-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-color","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-color-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.SECTION","",""]
["HmIP_MP3P_Terrasse-5.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.ACTIVITY_STATE","UNKNOWN","UNKNOWN"]
["HmIP_MP3P_Terrasse-5.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-5.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.COLOR_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-5.COLOR_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.SECTION_STATUS","UNKNOWN","UNKNOWN"]
["HmIP_MP3P_Terrasse-5.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-state","off","off"]
["HmIP_MP3P_Terrasse-state-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-5.LEVEL","off","off"]
["HmIP_MP3P_Terrasse-5.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-pct","off","off"]
["HmIP_MP3P_Terrasse-pct-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-level","off","off"]
["HmIP_MP3P_Terrasse-level-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-4.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-4.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.LEVEL","0","0"]
["HmIP_MP3P_Terrasse-4.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-4.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-4.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-4.SECTION","0","0"]
["HmIP_MP3P_Terrasse-4.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-rssidevice","-74","-74"]
["HmIP_MP3P_Terrasse-rssidevice-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-rssipeer","-74","-74"]
["HmIP_MP3P_Terrasse-rssipeer-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-activity","alive","alive"]
["HmIP_MP3P_Terrasse-activity-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-battery","ok","ok"]
["HmIP_MP3P_Terrasse-battery-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.SECTION_STATUS","UNKNOWN","UNKNOWN"]
["HmIP_MP3P_Terrasse-1.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.SOUNDFILE","INTERNAL_SOUNDFILE","INTERNAL_SOUNDFILE"]
["HmIP_MP3P_Terrasse-1.SOUNDFILE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.SECTION","",""]
["HmIP_MP3P_Terrasse-1.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.ACTIVITY_STATE","UNKNOWN","UNKNOWN"]
["HmIP_MP3P_Terrasse-1.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.LEVEL","0","0"]
["HmIP_MP3P_Terrasse-1.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-1.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-1.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-1.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.SECTION","0","0"]
["HmIP_MP3P_Terrasse-7.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-7.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-7.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.COLOR","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-7.COLOR-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-7.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.LEVEL","off","off"]
["HmIP_MP3P_Terrasse-7.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.COLOR_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-7.COLOR_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-7.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-7.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-8.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.SECTION","0","0"]
["HmIP_MP3P_Terrasse-8.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-8.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.COLOR_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-8.COLOR_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.LEVEL","off","off"]
["HmIP_MP3P_Terrasse-8.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-8.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-8.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-8.COLOR","BLACK","BLACK"]
["HmIP_MP3P_Terrasse-8.COLOR-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.LEVEL","0","0"]
["HmIP_MP3P_Terrasse-3.LEVEL-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.SECTION_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-3.SECTION_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.PROCESS","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-3.PROCESS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.SECTION","0","0"]
["HmIP_MP3P_Terrasse-3.SECTION-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.ACTIVITY_STATE","STABLE","STABLE"]
["HmIP_MP3P_Terrasse-3.ACTIVITY_STATE-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-3.LEVEL_STATUS","NORMAL","NORMAL"]
["HmIP_MP3P_Terrasse-3.LEVEL_STATUS-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-devstate","ok","ok"]
["HmIP_MP3P_Terrasse-devstate-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]
["HmIP_MP3P_Terrasse-hmstate","off","off"]
["HmIP_MP3P_Terrasse-hmstate-ts","2022-02-02 22:31:41","2022-02-02 22:31:41"]


[timmib]

Es wird leider immer schlimmer.

Jetzt bekomme ich auch im HTTPS Maskierungsfehler. Auch hier mit Screenshot. Auch wieder Homematic.

Code Auswählen Erweitern

A server must not mask any frames that it sends to the client.

[timmib]

Es betrifft alle Homematicgeräte!

[timmib]

Und es passiert auch im "normalen" FHEM UI. Siehe screenshot.

[rudolfkoenig]

Und es passiert auch im "normalen" FHEM UI. Siehe screenshot.

Das ist jetzt keine Ueberraschung. Wenn "Muell" (Daten nicht nach Spec) vorhanden sind, kann das an vielen Stellen weh tun.

Ich habe jetzt eine Pruefung und Konvertierung in der zentralen FW_addToWritebuffer hinzugefuegt, danach konnte ich das Problem nicht reproduzieren.
Wenn doch noch Probleme bestehen, bitte beschreiben, wie ich das nachstellen kann.

nicht zuletzt würden damit künstliche einschränkung für device und reading namen weg fallen die es nämlich genau deshalb gibt weil die diversen regexe die auf word oder zeichen matchen für die fhem ,unicode' variante nicht funktionieren wie sie sollten.

Das ist nicht ganz korrekt.
Ich habe noch nicht gemerkt, dass viele Leute "Küche" mit K.che pruefen wollen, dass die Laenge eines Readingnamen irgendwen interessiert, oder dass man das zweite Zeichen von dem Readingnamen inspizieren will. Dafuer gibt es etliche Systeme, die nicht mit utf8 umgehen koennen, d.h. man spart durch diesen Regel etwas Aerger.

Bitte gleich Unicode intern, alles nach aussen utf8. Das wird weh tun [...]

Ich habe keine Problem mit Unicode intern, sehr wohl aber mit "Das wird weh tun".
Wenn wir eine Methode finden, wie wir das ohne ernsthaften Probleme fuer den Benutzer umstellen koennen, dann bin ich dabei.

[justme1968]

Ich habe noch nicht gemerkt, dass viele Leute "Küche" mit K.che pruefen wollen, dass die Laenge eines Readingnamen irgendwen interessiert, oder dass man das zweite Zeichen von dem Readingnamen inspizieren will. Dafuer gibt es etliche Systeme, die nicht mit utf8 umgehen koennen, d.h. man spart durch diesen Regel etwas Aerger.

die argumente beißen sich etwas in den schwanz . da es aktuell überhaupt nicht geht, kann man schlecht sagen das es niemand macht.

es gibt an einigen stellen workarounds die extra eingebaut sind weil diverse regex sonst auch jetzt schon nicht wie erwartet matchen würden. eben weil die internen strings keine 'echten' strings mit encoding sind sondern nur ein strom von bytes. den ärger den man aktuell vielleicht bei systemen die nicht mit utf-8 umgehen können handeln wir uns dafür umgekehrt bei den systemen ein die mit utf-8 umgehen können und sich deshalb nicht ohne workarounds mit fhem verstehen. tatsächlich gibt es auch jetzt schon mehr als einen thread in dem es um solche workarounds geht.

egal wie man es dreht und wendet: der einzig 'saubere' weg ist die schnittstelle nach fhem und aus fhem heraus genau zu spezifizieren. utf-8 würde einige workarounds sparen und sehr willkommen möglichkeiten schaffen. alles andere ist nicht mehr zeitgemäß. es geht auch nicht nur um die paar deutschen umlaute. auch wenn fhem hauptsächlich in deutschland verwendet wird gibt es noch viel mehr wünschenswerte 'sonder'zeichen.

lange rede kurzer sinn: ich denke es würde sich lohnen. auch wenn der aufwand groß ist.

ich überlege mal ob man das ganze etwas konkreter machen kann um besser zu sehen wie sich der aufwand zwischen zentralen bausteinen und den modulen die dann nachziehen müssen verteilt.

[timmib]

Hi,

Ich habe jetzt eine Pruefung und Konvertierung in der zentralen FW_addToWritebuffer hinzugefuegt, danach konnte ich das Problem nicht reproduzieren.

Ich hab ja keine Ahnung von Perl, aber solche Hinweise geben mir etwas zu denken.

No. Any use of utf8::is_utf8 is incorrect as you should never use it! Using utf8::is_utf8 to guess at semantics of a string is what's known as an instance of The Unicode Bug. Except for inspecting the internal state of variables when debugging Perl or XS module, utf8::is_utf8 has no use.....

Quelle: https://stackoverflow.com/questions/14579560/am-i-using-utf8is-utf8-correctly

[timmib]

Hallo Rudolf,

das Problem mit Homematic bei HTTPS ist damit unverändert vorhanden. Da andere Modul habe ich gelöscht, weil es zusätzlich zu dem UTF-8 Problem auch den Hauptloop mit HTTP calls blockiert.

VG

Tim

[timmib]

Ich in meiner Entwicklungsumgebung nochmal das Smarthings Modul installiert (https://forum.fhem.de/index.php/topic,113820.0.html

Und das Problem mit HTTPS und HTTP besteht weiterhin.

Code Auswählen Erweitern

Could not decode a text frame as UTF-8.

Die Datei 01_FHEMWEB.pm habe ich über svn geholt und händisch dorthin kopiert und geprüft, das es die neue Version ist. Über "update" ist sie nicht gekommen.

[rudolfkoenig]

Ich will jetzt nicht an der Kompetenz der stackoverflow-Experten zweifeln, ich kann nur dagegenhalten, dass diese Methode seit laengerem in FHEMWEB verwendet wird um aehnlich gelagerte Probleme zu beheben, und die letzte Aenderung bei mir einen websocket-Abbruch mit provozierten Unicode-Daten behoben hat.

Weitere Module aufzuzaehlen hilft mir nicht wirklich, wenn ich helfen soll, dann bitte was zum Nachstellen, und das ohne Hardware oder spezielle Accounts.

[timmib]

Ich hab dir eine Mail mit dem API-Key geschickt zum reproduzieren.

[rudolfkoenig]

Ich kann beim SST Modul kein Problem feststellen, das im Mail erwaehnte setList_hint schaut so aus, wie im Anhang, egal welche HttpUtils Variante ich verwende.

Nach naeherem Hinsehen ist das auch kein Wunder, das Modul verwendet HttpUtils.pm weder direkt, noch indirekt ueber DevIo.pm, die Daten werden mit HTTP::Request geholt.
Ich meine das Problem (wenn ueberhaupt vorhanden) sollte dem Maintainer gemeldet werden.

[timmib]

Hi,

die Probleme habe ich ihm bereits die Tage gemeldet.

Ich dachte es ging Dir darum es ohne Hardware etc. reproduzieren zu können.

Alternativ zu diesem Beta-Modul bleibt nur Homematic. Dem Maintainer habe ich auch geschrieben, aber bisher ohne Erfolg.

Viele Grüße

Tim

[rudolfkoenig]

Ich dachte es ging Dir darum es ohne Hardware etc. reproduzieren zu können.

Das schon, ich sollte fuers Problem aber halbwegs zustaendig sein, noch besser waere es, wenn das Problem mit dem hier beschriebenen Aenderung was zu tun hat.

[timmib]

Die Änderung war doch in FHEMWEB und nicht in den HttpUtils.

[rudolfkoenig]

Die Änderung war doch in FHEMWEB und nicht in den HttpUtils.

In der Tat, da habe ich was verwechselt, tut mir Leid.

Das Problem habe ich mit SST auch deswegen nicht bemerkt, weil es erst beim refresh auftrat, was per default erst nach 5 Minuten kommt, und ich war ungeduldig. Es stellt sich heraus, dass meine Pruefung mit "utf8::is_utf8($txt) && $txt =~ m/[^\x00-\xFF]/" zu konservativ war, da nur is_utf8 zugeschlagen hat. Ich habe das UND jetzt auf ODER geaendert, und scheine damit keine Probeme mehr zu haben.

[zap]

Alternativ zu diesem Beta-Modul bleibt nur Homematic. Dem Maintainer habe ich auch geschrieben, aber bisher ohne Erfolg.

Viele Grüße

Tim

Du erwartest jetzt hoffentlich nicht, dass ich alles stehen und liegen lasse, und mich mit einem Thema befasse, das anscheinend nur einen Nutzer betrifft (bzw. Konsequenzen hat). Ich habe aktuell eine Liste von mehr als 40 Issues für HMCCU. Ich nehme Dein Problem gerne auf die Liste, benötige jedoch konkrete Hinweise, was ich ändern soll, da ich nicht die Zeit habe, mich im Detail einzulesen.

Wenn das Problem nur mit https auftritt: warum nutzt Du nicht einfach http? Im lokalen Netz ist https kein Sicherheitsgewinn und remote würde ich sowieso VPN verwenden. Wer es dann schafft, die VPN Verbindung zu hacken, für den spielt die SSL Verschlüsselung auch keine Rolle mehr.

[timmib]

Ne, das erwarte ich nicht.

Btw. Die Tablets sind in einem VLAN, und da ist HTTP wirklich nicht das Problem.
Zum Administrieren nutzte ich aber lieber HTTPS. zum Glück erlaubt FHEM ja den Parallelbetrieb.

Man muss auch sagen, dass die clients automatisch reconnecten und Benutzer ggf. deswegen damit leben können.

Bin ich wirklich der einzige der HTTPS und Homematic nutzt?

[rudolfkoenig]

@timmib: habe die Aenderung zurueckgedreht wegen https://forum.fhem.de/index.php?topic=126048, was offensichtlich deutlich mehr Benutzer betrifft.
Es gibt leider unterschiedlich "kaputte" Module, und ich weiss noch nicht, wie ich das Problem fuer alle zufriedenstellend loesen soll.

[zap]

@timmib: habe die Aenderung zurueckgedreht wegen https://forum.fhem.de/index.php?topic=126048, was offensichtlich deutlich mehr Benutzer betrifft.
Es gibt leider unterschiedlich "kaputte" Module, und ich weiss noch nicht, wie ich das Problem fuer alle zufriedenstellend loesen soll.

Wenn Du Tipps hast, wie ich meine Module "reparieren" kann, gerne.

[rudolfkoenig]

Wenn Du Tipps hast, wie ich meine Module "reparieren" kann, gerne.

Die Module muessen Strings mit dem Perl-internen utf8-Flag oder Wide-Character (ord($str) > 255) vermeiden.
Solche Strings muessen vmtl. mit utf8::encode($string) "externalisiert" werden.

Ich habe fhemdebug mit dem Argument utf8check erweitert, das diese Pruefung rekursiv fuer alle Strings in den %defs, %modules und %attr uebernimmt.
Die Ausgabe schaut so aus:

Code Auswählen Erweitern

fhem> define d dummy
fhem> setreading d a b
fhem> fhemdebug utf8check
Checked 1372 elements
Found no strings with utf8-flag

fhem> {$defs{d}{READINGS}{a}{VAL} = utf8str() }
鸡
fhem> l d a
d                    2022-02-08 15:19:20    鸡

fhem> fhemdebug utf8check
Checked 1372 elements
Strings with utf8-flag set:
Key: def::d::READINGS::a::VAL Value:鸡


[herrmannj]

nur mal so, was passiert eigentlich wenn man in ein Modul "use utf8;" schreibt und der Autor dann "Jörg" ($id: jörg ...). Da geht doch nix kaputt oder ..

[herrmannj]

nur mal so, was passiert eigentlich wenn man in ein Modul "use utf8;" schreibt und der Autor dann "Jörg" (my $id: jörg ...). Da geht doch nix kaputt, wenn man das dann ausgiebt, oder ..

[rudolfkoenig]

Solange dieser String nirgendwo FHEM verlaesst, und nicht in der "Naehe" eines anderen Strings kommt (und sie mit dem utf8-flag infiziert), was wiederum FHEM verlaesst, ist das irrelevant. Ansonsten ist das potentiell ein Problem.

Manche Module wie telnet oder FHEMWEB versuchen zwar das Problem zu vermeiden, aber offensichtlich gelingt das nicht ueberall, wie man das genau in diesem Thread sieht.