connection lost, ...

[gestein]

Hallo,

Die Arbeit sollte (teilweise) schon mal gemacht worden sein.
https://forum.fhem.de/index.php/topic,12605.msg1119674.html#msg1119674

Lg, Gerhard

[rudolfkoenig]

@Rudi: Kannst Du die paar SVG's eindampfen? Habe keine Inkscape

Ich habe jetzt die u.g. Liste durchgearbeitet:

gefrierschrank_icon.svg  941642  => 1562 (aus openautomation)
sprinkler_icon.svg       423703  => 10736 (aus der verlinkten Diskussion)
rc_TV1_on.svg            419312  unveraendert, enthaelt ein Bitmap. Sollte mAn entfernt werden.
kuehlschrank_small.svg   270578  => 12550 (aus der verlinkten Diskussion)
it_raspberry.svg         235113  unveraendert, ist aber mAn als icon ungeeignet, sollte entfernt werden.
solar_icon.svg           234856  => 1776 (aus openautomation)
wintergarten_icon.svg    187891  => 16834 (aus der verlinkten Diskussion)
springbrunnen_icon.svg    95779  => 48808 (mit inkscape Ctrl-L)

Die Anderen werden nach inkscape Vereinfachung zwar etwas kleiner, aber auch  etwas haesslicher, und die Ersparnis ist mAn nicht gerechtfertigt.

Beim Experimentieren mit  kuehlschrank_big (habs in inkscape nachgemalt) habe ich gelernt, dass die standard FHEMWEB-Faerbe-Methode (fill:#000000 zu ersetzen) mit inkscape nicht intuitiv ist: man muss gefuellte Flaechen (wie rect) verwenden, statt dicke Linien zu malen.

Danach habe ich openautomation/gefrierschank.svg bewundert, und kapiert, dass es mit einem Texteditor erstellt wurde.
Ich habe daraufhin kuehlschrank_big.svg mit der gleichen Methode nachgebaut: aus 177096 Bytes sind 916 geworden.

@gestein: Danke fuer deine Arbeit!

[Damian]

Danach habe ich openautomation/gefrierschank.svg bewundert, und kapiert, dass es mit einem Texteditor erstellt wurde.
Ich habe daraufhin kuehlschrank_big.svg mit der gleichen Methode nachgebaut: aus 177096 Bytes sind 916 geworden.

Wie effizient ein SVG-Icon erstellt ist, sieht man sofort, wenn man sich den HTML-Code anschaut. Die von Hand "programmierten" Icons benutzen effizient HTML-Elemente, wie Kreise, Rechtecke, Linien usw. Alles was automatisch generiert ist, bedient sich Sachen wie path, um von Pixel zu Pixel Linien zu ziehen oder einzelne Pixel zu setzen. Und es leuchtet sofort ein, dass z. B. einen Kreis aus Linien zu bauen, keine gute Idee sein kann

[Damian]

Ich muss den Thread noch mal aufwärmen, weil ich wieder Verbindungabbrüche habe.

Was mir aufgefallen ist, dass addToWriteBuffer mehrfach für die gleichen IDs aufgerufen wird.

Im DOIF habe ich folgenden Code für das Update von Tabellenzellen:

Code Auswählen Erweitern

      map {
         FW_directNotify("#FHEMWEB:$_", "doifUpdateCell('$pn','doifId','$doifId','$value','display:inline-table;$style')","");
      } devspec2array("TYPE=FHEMWEB") if ($value ne "");
Beim List TYPE=FHEMWEB kommt:

WEBHOME
WEBHOME_127.0.0.1_43716
WEBHOME_192.168.178.133_49415
WEBHOME_192.168.178.133_49416
WEBHOME_192.168.178.133_49417
WEBIconia

Geöffnet habe ich nur eine FHEM-Seite im Browser auf diesem PC.

In addToWriteBuffer habe ich eine Testausgabe mit den ersten Zeichen der Nachricht eingebaut und den Buffer auf 2 MB  erhöht, um zu sehen wie weit der gefüllt wird:

Code Auswählen Erweitern

if(!defined($hash->{$wbName})) {
    $hash->{$wbName} = $txt;
  } elsif($nolimit || length($hash->{$wbName}) < 2048000) {
    $hash->{$wbName} .= $txt;
    Log (1, "len wbName: ".length($hash->{$wbName})." len txt: ".length($txt)." txt: ".substr($txt,0,300));
  } else {
    return 0;
  }

so sehen die Ausgaben von zwei Zellen-Updates:

Code Auswählen Erweitern

2023.04.30 20:38:16.421 1: len wbName: 968787 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.423 1: len wbName: 968787 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.425 1: len wbName: 987954 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.442 1: len wbName: 985084 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00
2023.04.30 20:38:16.445 1: len wbName: 985084 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00
2023.04.30 20:38:16.447 1: len wbName: 1004251 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00

D.h. das ZellenUpdate wird statt einmal drei mal pro Zelle ausgeführt und bei mehreren SVG-Diagrammen kommt es im originalen fhem.pl zum Verbindungsabbruch, weil 1 MB überschritten wird.

[Damian]

Ich habe jetzt noch den Hash-Namen in der Ausgabe hinzugefügt:

Code Auswählen Erweitern

2023.05.01 12:34:27.828 1: name:WEBHOME_127.0.0.1_32986 len wbName:1010125 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
2023.05.01 12:34:27.830 1: name:WEBHOME_192.168.178.80_52735 len wbName:1009101 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
2023.05.01 12:34:27.832 1: name:WEBHOME_192.168.178.133_56294 len wbName:1009101 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
Es handelt sich offenbar um verschiedene Verbindungen (es waren bewusst zwei Browser von verschiedenen Rechnern auf der gleichen Seite) - das wäre dann ok. Sollte ich ggf. Update auf localhost unterbinden? Das würde aber das Problem nicht beheben.

Das Problem ist, dass eine SVG-Grafik je nach Aufwand über 30 KB hat (mit icons noch mehr), wenn man nun über dreißig Grafiken auf einem Bildschirm hat, dann kommt man schon an die Grenze.

Der Aufbau einer solchen kompletten Seite (offenbar mehrere MB groß) dauert lediglich Bruchteile einer Sekunde, dann erscheint es nicht sinnvoll Teile davon (ID-Update) bereits durch 1 MB zu begrenzen.

Die nächste Frage stellt sich, wie lange würden 2 MB halten?

Bei mir ging der Buffer bereits auf 1,6 MB hoch.

Oder braucht man eine andere Erkennung von toten Verbindung?

[rudolfkoenig]

Normalerweise wird eine Seite vom FHEMWEB und den betroffenen Modulen berechnet, und komplett an dem Browser geliefert.
Wenn man die Seite dynamisch aufbauen will, dann sollte ein JavaScript die Daten anfordern, z.Bsp. werden die SVGs bei plotEmbed=2 so geladen.
FW_directNotify ist nicht fuer inkrementellen Aufbau der Seite gedacht, sondern um Statusaenderungen mitzuteilen, oder ein Dialog asynchron einzublenden.

Die 1MB greift auch nur beim inkrementellen erweitern der Daten, d.h. nicht beim ersten mal.

[Damian]

Naja, es geht ja hier nur um Statusänderungen und nicht um einen neuen Seitenaufbau.

Das Problem wird einfach durch mehrere Events in einem Eventblock ausgelöst.

Vier Sensoren hängen an einem Device, wenn dieses im Minutentakt die Zählerdaten übermittelt, dann sollen deren Status und alles was damit zusammenhängt aktualisiert werden.

Es wird also keine neue Seite aufgebaut.

Da hier aber kein Text sich ändert, sondern ggf. auch ein Diagramm, so muss das Diagramm (oder zumindest dessen Daten) übertragen werden, was mit 20-30KB nicht mehr als ein SVG-Icon ist.

Das Problem tritt natürlich nur dann auf, wenn zufälligerweise viele Änderung auf einer Seite ausgelöst durch einen Eventblock zu erfolgen haben (siehe Anhang).

Spricht etwas gegen die einfache Lösung den Buffer auf 2 MB zu erhöhen?