WebSocket Absturz durch 88_HMCCUDEV bei HTTPS

[timmib]

Hallo,

ich habe soeben herausgefunden, dass ein get ... update auf mein HmIP-MP3P zu einem direkten Absturz der WebSockets führt.
Siehe hierzu auch Topic https://forum.fhem.de/index.php/topic,125866

Ich sehe da keine Umlaute oder andere Sonderzeichen die UTF-8 Probleme bringen könnten in des Readings.

Keine Ahnung was da los ist.

Viele Grüße

Tim

[timmib]

Es ist so, das dies nur bei Aktiverung von HTTPS auftritt. Es kann also sein, dass es ein grundsätzliches Problem mit den websockets ist.

Siehe hierzu auch den verlinkten Thread und den Screenshot (links=HTTPS, rechts=HTTP).

[timmib]

Betrifft auch HmIP-SMO-A.

[timmib]

Es betrifft alle Homematicgeräte.

[zap]

Meldungen im fhem Log ?

Nochmal zum Verständnis für mich: Nutzt Du https für das FHEM WebUI UND für den CCU Zugriff?

[timmib]

Hallo,

ich nutze FHEMWEB wie folgt:

Code Auswählen Erweitern

defmod WEB FHEMWEB 8083 global
attr WEB HTTPS 1
attr WEB confirmDelete 0
attr WEB longpoll websocket
attr WEB sslVersion TLSv12:!SSLv3


und HMCCU so.

Code Auswählen Erweitern

defmod d_ccu HMCCU homematic-raspi
attr d_ccu ccuflags procrpc
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

Im FHEM log steht dazu nix. Ich kann nochmal mein UTF-8 Erkennugscode dort einfügen, aber der schlägt bei Events zu HMCCU bzw. um genau zu sein zu HMCCUDEV nicht an. Kann ich aber gerne nochmal prüfen.

Aufgefallen ist das in der Developer Console von Chrome, bzw. daran das keine Updates mehr im TabletUI ankommen. Siehe dazu auch den verlinkten anderen Thread.

Viele Grüße

Tim

[zap]

Ziemlich schräg. Ich kanns leider nicht nachvollziehen, da ich TabletUI schon lange nicht mehr benutze

[timmib]

Nutzen nicht viele UIs websockets? Ich dachte selbst das normale FHEMWEB nutzt das auch.

[zap]

Fürs UI nutze ich IOBroker.

Wenn das FHEM Web auch Websocket nutzt, müsste ich ja damit die Probleme auch sehen. Funktioniert aber, mit https

[frank]

FHEMWEB nutzt websocket nur für "longpoll" zum automatischen aktualisieren, zb readings.
muss aber eventuell erst im attr lonpoll vom FHEMWEB device eingestellt werden.

[timmib]

Ja, das ist wie oben geschrieben aktiviert.

Code Auswählen Erweitern

attr WEB longpoll websocket

Ich hab hier mal ein Screenshot angehangen das es auch im "normalen" Web Ui passiert. (immer)

[zap]

Ich sehe in der Konsole manchmal solche Meldungen: "Websocket connection to XXX failed: Compressed bit must be 0 if no negotiated deflate-frame extension". Wobei XXX die URL eines FHEM Set-/Get-Befehls ist.

Das kann ich für verschiedene Module reproduzieren. Allerdings hat es zumindest bei mir keine negativen Auswirkungen.

An den Modulen kann das m.E. nicht liegen. Die Befehle Module geben ja nur irgendeinen Text zurück, den FHEM dann darstellt.

Ansonsten: HMCCU gibt eben auf Get-Befehle Plain-Text zurück. Ansonsten werden lediglich Readings über die Standard-FHEM-Funktionen aktualisiert.

=> Bis mir niemand das Gegenteil beweist, sehe ich das Problem nicht bei HMCCU.

Ich kann das aktuell auch nur mit Safari testen, da Google Chrome mangels echtem Zertifikat sich weigert, eine https Verbindung zu FHEM aufzubauen.

[timmib]

Hi,

schau dir bitte mal https://forum.fhem.de/index.php/topic,125866.msg1205354.html#msg1205354 an und reagiere da bitte auch am Besten dort drauf.

Websockets sind nach Norm immer UTF-8.

Viele Grüße

Tim

PS In Chrome einfach per IP FHEM aufrufen, dann kommt man auch an der Trust Meldung vorbei.