Hallo,
ich habe schon lange (seit wann kann ich leider nicht genau sagen) ein Problem bei FHEMWEB und der Websocket-Verbindung. Ich nutze attr longpoll websocket, was hinter meinem Reverse Proxy nginx soweit auch funktioniert. Es gibt aber immer wieder das Problem, dass die Websocket-Verbindung getrennt und danach nicht wieder aufgebaut wird - nur ein Reload der gesamten Seite hilft. Mir ist aufgefallen, dass die mglw. mit der via Websocket übertragenen Datenmenge zusammenhängt. Ich erhalte z.B. über mein Auto alle 30min. diverse JSON-Daten via MQTT (mosquitto), die u.a. auch einige als base64-encodierte Bilder enthalten. Immer, wenn diese Daten übertragen werden, sehe ich oben links in FHEMWEB den schwarzen Balken mit dem Text Connection lost, trying a reconnect every 5 seconds.. In der Browser Konsole (Firefox, passiert aber auch bei anderen Browsern) sehe ich dann folgendes (nur ein Ausschnitt, geht bis zum Reload so weiter:
08:25:31.309 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
08:25:31.314 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981930.1801498%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981931304 aufbauen. fhemweb.js:1454:19
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981930.1801498%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981931304 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:31.320 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
08:25:36.216 ERRMSG:< fhemweb.js:611:13
08:25:37.327 ERRMSG:< fhemweb.js:611:13
08:25:37.332 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981930.1801498;fmt=JSON&fw_id=1761980331.68416×tamp=1761981937329
[HTTP/1.1 101 Switching Protocols 36ms]
08:25:37.599 Rcvd: ["myskoda2mqtt_xxx_user","User<br>(Backend: 2025-11-01 08:25:32, MQTT: 2025-11-01 08:25:32)","<div id=\u002...(375) fhemweb.js:611:13
08:25:37.600 Rcvd: ["myskoda2mqtt_xxx_driving_score","Aktuelle Woche: 96 Punkte<br>(Letzte Berechnung: 2025-06-11, MQTT: 2025-11-01 08:25...(426) fhemweb.js:611:13
08:25:37.600 Rcvd: ["myskoda2mqtt_xxx_maintenance","Nächste Inspektion in: 332 Tagen, 8700km<br>Nächster Ölwechsel in: 332 Tagen, 8700km<...(674) fhemweb.js:611:13
08:25:37.601 Rcvd: ["myskoda2mqtt_xxx_widget","Zustand: CLOSED, PARKED<br>Position: Straße 99, Stadt<br>(MQTT: 202...(469) fhemweb.js:611:13
08:25:37.602 Rcvd: ["myskoda2mqtt_xxx_auxiliary_heating","Status: OFF<br>Dauer: 1200 Sekunden<br>(Auto: 2025-10-31 08:07:06, Backend: 202...(881) fhemweb.js:611:13
08:25:37.602 Rcvd: ["myskoda2mqtt_xxx_health","(Auto: 2025-10-31 08:07:39, Backend: 2025-11-01 08:25:32, MQTT: 2025-11-01 08:25:32)","<di...(406) fhemweb.js:611:13
08:25:37.602 Rcvd: ["myskoda2mqtt_xxx_trip_statistics","Aktuelle Woche:<br>Entfernung: 208km<br>Fahrzeit: 286min<br>Benzinverbrauch: 6.1l...(703) fhemweb.js:611:13
08:25:38.337 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981936.73415;fmt=JSON&fw_id=1761980331.68416×tamp=1761981938334
[HTTP/1.1 101 Switching Protocols 50ms]
08:25:38.351 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981938334 aufbauen. fhemweb.js:1454:19
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981938334 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:38.358 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
08:25:43.346 ERRMSG:< fhemweb.js:611:13
08:25:43.348 ERRMSG:< fhemweb.js:611:13
08:25:44.350 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981944347 aufbauen. fhemweb.js:1454:19
08:25:44.353 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981936.73415;fmt=JSON&fw_id=1761980331.68416×tamp=1761981944347
[HTTP/1.1 101 Switching Protocols 38ms]
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981944347 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:44.364 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981944350 aufbauen. fhemweb.js:1454:19
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981944350 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:44.370 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981936.73415;fmt=JSON&fw_id=1761980331.68416×tamp=1761981944350
[HTTP/1.1 101 Switching Protocols 44ms]
08:25:49.333 ERRMSG:< fhemweb.js:611:13
08:25:49.334 ERRMSG:< fhemweb.js:611:13
08:25:50.336 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981950333 aufbauen. fhemweb.js:1454:19
08:25:50.340 Inform-channel opened (websocket) with filter room=Auto2 fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981936.73415;fmt=JSON&fw_id=1761980331.68416×tamp=1761981950333
[HTTP/1.1 101 Switching Protocols 81ms]
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981950333 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:50.350 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
Firefox kann keine Verbindung zu dem Server unter wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981950337 aufbauen. fhemweb.js:1454:19
Die Verbindung zu wss://fhem.xxx.de/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DAuto2%3Bsince%3D1761981936.73415%3Bfmt%3DJSON&fw_id=1761980331.68416×tamp=1761981950337 wurde unterbrochen, während die Seite geladen wurde. fhemweb.js:1454:19
08:25:50.356 ERRMSG:Connection lost, trying a reconnect every 5 seconds.< fhemweb.js:611:13
GET
wss://fhem.xxx.de/fhem?XHR=1&inform=type=status;filter=room=Auto2;since=1761981936.73415;fmt=JSON&fw_id=1761980331.68416×tamp=1761981950337
Meine nginx-Config sieht so aus:
server {
include /etc/nginx/includes/ssl.conf;
server_name fhem.xxx.de;
access_log /var/log/nginx/fhem.access.log;
error_log /var/log/nginx/fhem.error.log debug;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8083;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
access_log off;
client_max_body_size 0;
}
}
Kann es an der übertragenen Datenmenge liegen? Andere Updates, z.B. meiner Wetterstation, die ca. alle 16 Sekunden kommen, funktionieren problemlos und die Websocket-Verbindung bleibt bestehen. An einem Timeout kann es in meinen Augen nicht liegen, da das z.B. auch auftritt, wenn ich FHEM kurz vor dem 30-minütigen Update von meinen Fahrzeugdaten im Browser öffne, auch dann stirbt die Websocket-Verbindung und kann nicht wieder aufgebaut werden.
Hat jemand eine Idee oder ähnliche Probleme?
Wenn es noch mehr Infos braucht, bitte ich um Rückmeldung.
Viele Grüße
Dennis
Die Voreinstellung fuer nginx websocket Timeout ist meines Wissens 60s, das kann man aber erhoehen.
Gibt es Probleme ohne nginx?
Wie gross sind denn die Daten?
Steht im FHEM log was Besonderes?
Zitat von: rudolfkoenig am 01 November 2025, 11:24:15Die Voreinstellung fuer nginx websocket Timeout ist meines Wissens 60s, das kann man aber erhoehen.
Gibt es Probleme ohne nginx?
Wie gross sind denn die Daten?
Steht im FHEM log was Besonderes?
Wie groß die Datenmenge ist, weiß ich ehrlich gesagt nicht. Wie kann ich das am besten bestimmen? Timeout im nginx hatte ich mal testweise auf 75s,mehr geht laut Doku nicht. Ändert aber nichts. Und da wie gesagt alle ca. 16s ein Update von meiner Wetterstation kommt, kann ich mir Timeout eigentlich nicht vorstellen.
Im Log von FHEM steht dazu gar nichts, mit aktuell global verbose 3. Müsste ich verbose anpassen, um ggf. was zu sehen? Würde FHEMWEB reichen, oder global?
Ohne nginx müsste ich probieren, läuft schon lange mit. Rückmeldung dazu kommt.
Ohne nginx tritt dasselbe Problem auf.
ZitatTimeout im nginx hatte ich mal testweise auf 75s,mehr geht laut Doku nicht.
Die Stelle im Doku wuerde mich interessieren.
Ich habe den Wert mal auf 3600s gesetzt, und es mit 180s erfolgreich getestet.
ZitatIm Log von FHEM steht dazu gar nichts, mit aktuell global verbose 3. Müsste ich verbose anpassen, um ggf. was zu sehen? Würde FHEMWEB reichen, oder global?
Ich habe eine Fehlermeldung erwartet, dazu braucht man verbose nicht zu verstellen.
Wenn ein reload das Problem behebt, dann wird das Problem im Browser und oder proxy (nginx) liegen.
Gibts das Problem auch mit einem anderen Browser bzw. auf einem anderen OS?
Evtl. Inkognito-Modus probieren, da sind die Browser-Extensions normalerweise inaktiv.
Ich meinte das hier: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout
Ist aber für diesen Fall vermutlich nicht relevant, falsch gemerkt, sorry.
Inkognito macht keinen Unterschied, Chrome, Chromium, Vivaldi und Brave getestet.
Wenn man im FHEMWEB verbose auf 5 setzt, dann sieht man auch die Verbindungsversuche.
Woemoglich sieht man da was, wenn der Browser versucht die Verbindung neu aufzumachen.
Hast Du ein allowed gesetzt oder das allowFrom Attribut?
Welches OS ist das?
allowed habe ich bei der nginx-variante gesetzt. Für den Test ohne nginx habe ich eine neue FHEMWEB-Instanz erstellt ohne allowed. OS sind Linux und Android. Windows teste ich, Rückmeldung folgt.
Windows unter Edge passiert das gleiche.
Kannst Du noch das FHEMWEB-verbose Experiment durchfuehren?
Weitere Idee: die grossen Readings (temporaer) in FHEM filtern, und pruefen ob das Problem damit zusammenhaengt.
Und koenntest du so ein Bild mir zur Verfuegung stellen, hier als Anhang oder per Email?
Hab Dir gerade zwei PMs geschickt, einmal mit den Bildern (zwei fehlen, da diese sensible Infos enthalten) und einmal mit der Log-Ausgabe verbose 5 kurz vor und nach dem Verbindungsverlust.
Nach etwas Experimentieren: die grosse Datei (1MB+) verstimmt den Browser so stark, dass es danach nichtmal versucht eine neue Verbindung aufzumachen, trotz "new WebSocket(...)".
Ich weiss nicht, wie ich das reparieren soll.
Da aber 1MByte+ an base64 encoded Bilddaten im Browser eh nicht so ideal sind, schlage ich vor stattdessen einen Link auf die Bilder zu schicken.
Das kann man z.Bsp mit dem readingList Attribut so gestalten:
.*/images/caroblique:.* { WriteFile("www/images/caroblique.png", decode_base64($EVENT));; return {caroblique=>'<html><img style="max-width:256px" src="fhem/images/caroblique.png"></html>'} }\
.*/images/carside:.* { WriteFile("www/images/carside.png", decode_base64($EVENT));; return {carside=>'<html><img style="max-width:256px" src="fhem/images/carside.png"></html>'} }\
.*/images/status:.* { WriteFile("www/images/status.png", decode_base64($EVENT));; return {status=>'<html><img style="max-width:95px" src="fhem/images/status.png"></html>'} }
Und mit folgender Variante aendert sich sogar das Bild:
.*/images/caroblique:.* { my $n="images/caroblique.png";; WriteFile("www/$n",decode_base64($EVENT));; return {caroblique=>"<html><img style='max-width:256px' src='fhem/$n?".time."'></html>"} }\
.*/images/carside:.* { my $n="images/carside.png";; WriteFile("www/$n",decode_base64($EVENT));; return {carside=>"<html><img style='max-width:256px' src='fhem/$n?".time."'></html>"} }\
.*/images/status:.* { my $n="images/status.png";; WriteFile("www/$n",decode_base64($EVENT));; return {status=>"<html><img style='max-width:95px' src='fhem/$n?".time."'></html>"} }
Vielen Dank für Deine Mühe und die Analyse des Ganzen. Habe nun Deinen Lösungsvorschlag umgesetzt, damit tritt das Websocket-Problem aktuell nicht mehr auf.
Mir fällt da noch eine Sache ein. Ich nutze FHEM auch viel auf meinem Smartphone. Da habe ich das Problem, dass bedingt durch die Batteriesparmechanismen jede App im Hintergrund irgendwann pausiert wird. Also auch der Browser. Wenn ich diesen dann wieder in den Vordergrund hole, ist FHEM noch geöffnet, wird aber nicht neu geladen. Ich sehe aber auch wieder oben links die Meldung, dass die Verbindung nicht aufgebaut werden kann. Dann muss ich die ganze Seite neu laden, danach funktionierts wieder. Könnte man das in Javascript automatisieren, d.h. wenn Websocket-Verbindung nicht herstellbar,dann lade die Seite neu? Wäre das sinnvoll, oder übersehe ich etwas, was dagegen spräche?
Ich kann das einbauen, nur ueber das "wie" bin ich noch unsicher: direkt nach dem ersten Fehlversuch? Mit Attribut aktivierbar?
Eigentlich ist das ein Bug irgendwo (ich vermute den Browser).
Die KI Antwort dazu in der google Suche ist mAn falsch.
Das Problem scheint bekannt zu sein, eine Loesung habe ich auf die schnelle nicht gefunden.
Wenn jemand einen Hinweis hat...
Es ist auch definitiv Browser-abhängig, wie ich nun feststelle - ist mir vorher gar nicht so aufgefallen. Firefox unter Android baut die Verbindung wieder auf, zeigt aber die Fehlermeldung oben links gar nicht an. Hermit unter Android (eine Art Browser, der Webseiten im Grunde als Apps darstellt), baut die Verbindung wieder auf, zeigt aber vorher auch die Fehlermeldung an. Brave ebenso wie Hermit. Mehr Browser hab ich grade nicht. Es scheint also über die Zeit Verbesserung in den Browsern eingetreten zu sein. Ich hatte das schon so lange, dass ich vor meinem Post gar nicht explizit nochmal den aktuellen Stand geprüft habe. Da ich aber bei meinen Google-Suchen und KI-Befragungen auf eben genau die Erkenntnis gestoßen bin, dass das Problem bekannt ist, habe ich den Post abgesetzt, da er zu meinem eigentlichen Problem in diesem Thread passte. Vielleicht gibt es ja trotzdem noch Input zur grundlegenden Thematik, aber ein Problem scheint es aktuell nicht mehr zu sein. Mea culpa.
Ggf. hilft ein Testdevice. Es erzeugt alle zehn Sekunden ein blödsinnig großes HTML reading. Hat man es im Browser geöffnet wird es ja mit den Updatemethoden von FHEMWEB im Browser geladen und angezeigt:
defmod HTML_Testdevice at +*00:00:10 { \
# Array of colors\
my @colors = qw(red green blue yellow orange purple pink cyan);;\
\
# Randomly pick a color from the array\
my $random_color = $colors[rand @colors];;\
\
# Generate a random number\
my $random_number = int(rand(1000));;\
\
# Get the current timestamp\
my $timestamp = strftime('%Y-%m-%d %H:%M:%S', localtime);;\
\
my $size = 1024 * 1024;; # 1 MB\
my @chars = ('A'..'Z');;\
my $big;;\
$big .= $chars[rand @chars] while length($big) < $size;;\
my $visual_block = qq(<div style="width:100%;;height:20px;;overflow:hidden;;background:#ddd;;font-size:0;;">$big</div>);;\
\
\
# Create the HTML snippet\
my $html_snippet = <<"HTML";;\
<div style="color: $random_color;;">\
Random Number: $random_number<br>\
Timestamp: $timestamp<br>\
$visual_block\
</div>\
HTML\
\
$html_snippet =~ s/\n//g;;\
\
readingsSingleUpdate($defs{"HTML_Testdevice"}, "meinReading", "<html>$html_snippet</html>", 1);;\
}
attr HTML_Testdevice room Experimente
Ich habe es auch bei Cooltux auf seinen Server gestellt, aber die Datenmenge auf 100k reduziert. Damit bleibt die Websocket Ok, bei 1MB bricht sie dauernd ab: https://demo-fhem.cooltux.net/fhem?detail=HTML_Testdevice
HTH
In fhemweb.js, in der Funktion FW_doUpdate(evt), da ist doch ein hartes Limit von 1MB kodiert. Warum ist das so klein definiert, heutige Webanwendungen können doch ruhigen Gewissens auch mal 10-100MB beanspruchen IMHO. Ist das nicht das ursächliche Problem in diesem Fall? Zumindest wäre es doch dann ein Kandidat für ein Attribut das man sich als Admin selbst aussuchen können möchte, oder?
function
FW_doUpdate(evt)
{
var errstr = "Connection lost, trying a reconnect every 5 seconds.";
...
// reset the connection to avoid memory problems
if(FW_longpollOffset > 1024*1024 && FW_longpollOffset==input.length)
FW_longpoll();
}
ZitatWarum ist das so klein definiert [...]
Weil fhemweb.js alt ist, und damals(TM) war Speicher noch nicht so ueppig vorhanden :)
ZitatIst das nicht das ursächliche Problem in diesem Fall?
Nein, in diesem Fall funktioniert das automatische Reconnect.
Dein Testprogramm zeigt zwei Grenzen auf: erstens die 1000k Grenze in fhem.pl/addToWritebuffer und die 1MB Grenze in fhemweb.js
Ersteres verhindert, dass ein zugeklapptes Notebook den Speicherverbrauch im Backend ins unendliche treibt.
Letzteres schont den Speicher im Browser.
Ich kann diese Grenzen aendern, wenn jemand mir einen nicht kuenstlichen Fall zeigt, wo das benoetigt wird.
Danke für den Einblick, ne - dann ist der Fehler ja nochmal ein anderer und das Testdevice hilft hier nicht.
Die Grenze der Websocket ist vermutlich dann hier ja auch nicht das Problem und dann muss man noch wohl weiterrätseln was beim OP schief läuft.
Bezüglich aufbohren der Limits: Ich denke es ist Ok es auf den Werten zu belassen, da es ja gerade der immense Vorteil von FHEM gegenüber zB. Homeassistant ist, dass es schlank (RAM, CPU, HDD) und lesbar/überschaubar (LOC) ist. Ich schätze es zumindest ja genau deshalb, während HASS zwar mittlerweile populärer ist, aber auch irgenwie schon fast bloatet und auch zu einem gewissem Anteil undurchsichtig wird. Egal, das wird nun OT, Fazit: erstmal so lassen; denke ich auch.
@rudolf: Als kleine Verbesserung wäre doch spannend in fhemweb.js ein wenig mehr zu loggen, oder?:
FW_pollConn.onerror = (e) => {
console.error("WebSocket error", e);
};
FW_pollConn.onclose = (e) => {
console.warn("WebSocket closed", e.code, e.reason);
};
Ich kann es leider nicht nachstellen, aber so könnten wir wenigstens mehr vom Browser erfahren...
Ähnlich zu den Infos unter: https://blog.postman.com/websocket-connection-failed/
onclose und onerror werden bereits umgeleitet, und in der Zeile 1285 wird close ausgewertet.
Fehlt nur noch eine Pruefung auf error, und dafuer brauche ich noch einen Testfall...