Automatische Updates werden immer länger...

[Prof. Dr. Peter Henning]

Nach einem Tipp von Rudi habe ich es problemlos hinbekommen, dass eine komplett neu erstellte weblink-Seite, die auch Readings enthält, automatische Updates erhält. Dazu muss man nur eine abgespeckte Version des Unterprogramms initInform aus 01_FHEMWEB.pm ausführen, um die "eigene" Seite für die Inform-calls zu registrieren. So weit, so gut.

Beim Testen habe ich dann ein wenig mit dem JavaScript Code herumgespielt, und es ist mir Folgendes aufgefallen:

Angenommen, man bleibt auf einer Seite - sagen wir mal, der Detailansicht einer Instanz des Astro-Moduls. Und hat dessen Update-Intervall auf 10 Sekunden gestellt.

Dann gibt es logischerweise alle 10 Sekunden durch JavaScript ein Update. Allerdings wird der String, den FHEMWEB an die Seite schickt, immer länger. Es werden tatsächlich alle Updates seit dem "since"-Zeitstempel immer wieder neu verschickt. Man kann das einfach ausprobieren, indem man in die fhemweb.js, function doUpdate testweise ein

Code Auswählen Erweitern

alert("doUpdate mit Daten "+input);
einbaut - der input-String wächst und wächst mit jedem Update.

Ich hielte es für sinnvoll, das irgendwie zu begrenzen.

LG

pah

[rudolfkoenig]

Allerdings wird der String, den FHEMWEB an die Seite schickt, immer länger.

Ich gehe davon aus, dass Du hier das longpoll Problem (wieder-)entdeckt hast. Longpoll laeuft so: man kriegt eine "unendlich" grosse Seite nach und nach langsam geliefert, man wird aber aufgerufen, wenn was Neues eingetroffen ist. Wenn man merkt, was beim letzten Aufruf da war, dann kann man ausrechnen, was neu dazugekommen ist. fhemweb eroeffnet die Verbindung neu, wenn die Daten 1MB erreicht haben, um den Browserspeicher zu schonen. Alternativ kannst du websocket verwenden (attr WEB longpoll websocket), damit braucht man diesen Unfug nicht.

[betateilchen]

• es gibt eine Menge devices, die kein websocket können
• es gibt Browser, die mit dem "fhemweb eröffnet die Verbindung neu, wenn die Daten 1 MB erreicht haben" nicht zurechtkommen und dann nur noch eine Fehlerseite anzeigen

In manchen Fällen scheitert also sowohl longpoll als auch websocket. Irgendwie ist das Thema "automatische updates" ein fürchterliches Gefrickel. (nein, ich weiß auch keine bessere Lösung)

[Prof. Dr. Peter Henning]

Es ist mir ziemlich egal, ob das Problem nur "wiederentdeckt" wurde - ich hatte es nämlich nicht auf dem Radar.
Ich halte es aber für unnötig, dass "doUpdate" mit der vollen Historie im Event aufgerufen wird.

LG

pah

[rudolfkoenig]

Ich halte es aber für unnötig, dass "doUpdate" mit der vollen Historie im Event aufgerufen wird.

Ich auch, leider kann ich nicht so viel dagegen machen, FW_doUpdate wird direkt vom Browser so aufgerufen.
Leider sind meine Connections zu den Browserhersteller oder W3C ziemlich mau.

[herrmannj]

• es gibt eine Menge devices, die kein websocket können

... wie zb Android 4.3 ... mit 0,35% globaler Bedeutung. Richtig ist das ~90% "in the wild" das können und für die letzten 10% Möhren gibt es in Teilen sogar "Ersatzbrowser". Websocket ist heute normal !
http://caniuse.com/websockets/embed/

• es gibt Browser, die mit dem "fhemweb eröffnet die Verbindung neu, wenn die Daten 1 MB erreicht haben" nicht zurechtkommen und dann nur noch eine Fehlerseite anzeigen

In manchen Fällen scheitert also sowohl longpoll als auch websocket. Irgendwie ist das Thema "automatische updates" ein fürchterliches Gefrickel. (nein, ich weiß auch keine bessere Lösung)

Das ist in fhemweb historisch gewachsen. Und smartvisu/fronthem zeigend das die Technik sehr wohl funktioniert.

vg
joerg