Websocket-Verbindung kann bei großer Datenmenge nicht wieder aufgebaut werden

Begonnen von dennisk, 01 November 2025, 08:37:30

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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...

dennisk

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.

Torxgewinde

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

Torxgewinde

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();
}

rudolfkoenig

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.

Torxgewinde

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.