[gelöst - Workaround] Keine Aktualisierung der Anzeige - fronthem vs. Smartvisu

[msome]

Hallo zusammen,

vielleicht kennt jemand auch das folgende Problem und kann mir einen Tipp geben wie das Problem vermieden werden kann.

Bei mir läuft gerade Smartvisu 2.9.2 mit fronthem v21 und im Prinzip funktioniert's echt gut.
Aber völlig unregelmäßig werden die Elemente auf Smartvisu nicht mehr aktualisiert.
Heute hab ich die Situation endlich mal auf dem Tablet erwischt bevor jemand aktualisiert (Seite neu geladen) hat.
Der Chrome-Inspect über den PC zeigt, dass der FHEM Treiber in Smartvisu meint die Verbindung steht io.socket.readyState = 1
aber FHEM sagt, der Client wäre disconnected. Siehe Screenshot im Anhang wo man FHEM-Fronthem und Javascript-Konsole vom Smartvisu auf'm Tablet sieht.

Irgendeine Idee woran dies liegen könnte?
Es ist scheinbar keine Timeout-Erkennung im SmartVisu Treiber implementiert - was jedoch auch schwierig ist
bei einem Event-basierten System wo man nie weiß ob gerade nix passiert oder gerade ein Problem besteht.

Danke,
Matthias

[ReviloEgros]

Hallo,

ich habe ziemlich oft das selbe Problem, und auch noch keine wirkliche Lösung gefunden. Um dem vorzubeugen bzw. entgegenzuwirken habe ich einmal ein Watchdog auf das fronthem Device. Wenn es für mindestens 10 Sekunden disconnected ist, wird automatisch smartVISU auf dem Tablet neu geladen. Ich hatte es vorher mit Notify probiert, aber nach jedem Seitenwechsel in smartVISU geht er kurz auf disconnected. Da hatte er nach jedem Wechsel dann neu geladen und ich war wieder auf der Startseite. Doof! Aber auch hier hatte ich ab und an das Problem, das dieser disconnect unbemerkt blieb. Nun frage ich per AT jede Minute den status ab, und lade ggf. neu. Bisher fahre ich damit ganz gut. Achja, bei einem FHEM neustart lade ich smartVISU auch neu.

Code: [Auswählen]

defmod fronthem_192.168.188.20WD watchdog fronthem_192.168.188.20:disconnected 00:00:10 fronthem_192.168.188.20:connected set LenovoTab restart
attr fronthem_192.168.188.20WD autoRestart 1
attr fronthem_192.168.188.20WD regexp1WontReactivate 1

Code: [Auswählen]

defmod check_smartvisu at +*00:01:00\
{\
if (ReadingsVal('fronthem_192.168.188.20', 'state', '') eq "disconnected")\
{\
fhem "set LenovoTab restart";;\
}\
}
attr check_smartvisu alignTime 00:00

Code: [Auswählen]

defmod INITIALIZED notify global:INITIALIZED {\
fhem "set LenovoTab restart";;\
}

[GammaTwin]

automatisch smartVISU auf dem Tablet neu geladen

Code: [Auswählen]

set LenovoTab restart

Klingt interessant. Was für ein Device ist das "LenovoTab"? Lädst Du aus FHEM heraus die smartVISU neu?

[msome]

Vielen Dank.

Ich muss es mir mal genauer ansehen, bei mir wäre das Tablet ein AMAD device - daher könnte ich schon mit
"set svTablet system reboot" das Tablet neu starten - ehrlich gesagt ist das schon sehr mit Kanonen auf Spatzen geschossen.

Wenn ich am Wochenende mal Zeit habe werde ich mir mal ansehen, ob ich es über AMAD - Automagic schaffe,
dass Chrome die aktuelle Seite einfach einen "reload" macht. Wäre wohl die einfachste Methode.

Aber ich hab mir alternative überlegt den io_fhem umzuschreiben dass er ein Timeout-Monitoring macht.
Dazu bräuchte ich ja nur ein Event das alle 10sec von FHEM an SV senden - wenn es ausbleibt, dann würde ich die Verbindung resetten, d.h. die aktuelle Verbindung schließen, den aktuellen Reconnect stoppen und startReconnectTimer auslösen. Damit wäre auch gleich das Retry-Handling "for free" implementiert.

Mal sehen, irgendwas muss ich tun. Der aktuelle Zustand ist unhaltbar. Besser keine Daten als falsche Daten.

Vielen Dank für den Tipp mit dem Watchdog.

[ReviloEgros]

Klingt interessant. Was für ein Device ist das "LenovoTab"? Lädst Du aus FHEM heraus die smartVISU neu?

Das LenovoTab ist ein Tablet von Lenovo auf dem Fully als Browser läuft. Da das Tablet ziemlich langsam ist und nach einiger Zeit im betrieb auch Fully anfängt reichlich zu "stottern", starte ich die Fully App auf dem Tablet neu (Auch einmal in der Nacht um 3 Uhr). Es würde bei neueren und schnelleren Tablets wahrscheinlich auch reichen die URL in Fully neu zu laden, aber so bin ich das Problem auch erstmal los, bis ich mir ein neues Tablet zulege Ich hatte es eine Zeitlang auch mit AMAD an FHEM angebunden, aber das wurde dem Tablet ziemlich schnell zu viel, und ich bekam oft die Meldung "The App stopped working again" auf dem Display. Deswegen habe ich AMAD wieder runter geschmissen und nutze nur noch Fully, was für meine Zwecke auch ausreichend ist.

[GammaTwin]

und wie spielen Fully und "set LenovoTab restart" zusammen?

[ReviloEgros]

LenovoTab ist ein Device vom Type Fully.

Code: [Auswählen]

defmod LenovoTab FULLY 192.168.188.20 passwort 60
attr LenovoTab event-on-change-reading state
attr LenovoTab group Tablet
attr LenovoTab icon fa_tablet
attr LenovoTab pingBeforeCmd 0
attr LenovoTab pollInterval 60
attr LenovoTab room 01_Wohnzimmer


[GammaTwin]

Den Typ Fully kannte ich noch gar nicht - Danke

[msome]

Wollte nun mal das AMAD / Automagic update angehen und hab direkt im Automagic Forum gesehen, dass Automagic nicht mehr unterstützt / weiterentwickelt wird.

Damit hat sich's für mich auch erledigt, werde jetzt auch auf Fully umstellen - keine Lust, ein totes Pferd Automagic weiterzureiten.

Eine erste gute Erfahrung mit dem Fully-Support; damit ist schon mal ein Basis-Bonus vorhanden. 
   ( Sie haben eine Mail-Anfrage von mir direkt, konkret und sehr schnell beantwortet. Top. )

[msome]

Umstieg erfolgreich, somit ist zwar nicht klar warum die Verbindungsstati auseinanderlaufen aber zumindest ist jetzt ein Workaround vorhanden.

Danke @ReviloEgros, ich hab deine Definition vom Watchdog + AT + INIT so übernommen. Dreifach hält besser.

[ReviloEgros]

Danke @ReviloEgros, ich hab deine Definition vom Watchdog + AT + INIT so übernommen. Dreifach hält besser.

Ach keiner Rede wert. Nur hatte ich es auch schon ein paar mal, das FHEM mir gesagt hat das fronthem Device sei connected, hat aber trotzdem keine Daten bekommen. Ist zwar bisher echt selten vorgekommen, stört aber trotzdem. Nur dafür habe ich für mich noch keine Lösung gefunden.

[msome]

Hi, kann das Problem jetzt auch nachvollziehen.
Hatte jetzt heute die Situation dass die SV Seite in Fully komplett stand, auch der Sekundenzeiger der "lokalen" Uhr lief nicht mehr. Das Fronthem device war auf connected.
Das ist jetzt ein neues Problem, kannte ich vor Fully (da lief SV direkt in Chrome) noch nicht.
Mit Chrome lief die Uhr - läuft ja auch in Javascript - immer weiter, nur die Verbindung zu Fronthem wurde unterbrochen.

Aber zumindest ein bisserl besser - da der Sekundenzeiger sich nicht mehr rührt, weiß man zumindest direkt dass die Oberfläche auch wahrscheinlich alte Daten anzeigt.

Dann muss ich wohl doch noch irgendein Timer-Event in der Visu einbauen das zyklisch einen FHEM dummy
bedient (+1 oder sowas) um eine direkte Rückmeldung zu haben und ein offline der Visu erkennen zu können.

Oh Mann, kann nicht einfach was mal direkt funktionieren :-)...

[wvhn]

Mit @ReviloEgros zusammen habe ich im smartVISU-Forum Treiber geändert und getestet. Anbei jetzt eine Version, von der ich mir auch hinsichtlich des hier geschilderten Problems Verbesserungen erhoffe. Auf Testergebnisse bin ich gespannt.

Vielleicht noch eine grundsätzliche Anmerkung:
smartVISU abonniert die items der aktuell aufgerufenen Seite beim Backend. Das bedeutet, dass dem Backend mittels des Kommandos "monitor" mitgeteilt wird, für welche items es selbständig jede Änderung "melden" muss. Danach hört smartVISU auf dem Websocket nur noch mit und versucht, die Verbindung offen zu halten. Geschossene Verbindungen (onclose Event im io_fhem Treiber) werden wieder geöffnet und noch bestehende, aber nicht bereite Verbindungen (socketReadyState >1) werden wieder gestartet (autoReconnect Option auf der Config-Seite).

Wenn es dennoch zu Verbindungsproblemen kommt, dann hilft natürlich der zeitgesteuerte Page reload, aber eigentlich wäre es sinnvoller, das Websocket-Modul auf der fhem Seite robuster einzustellen. Dabei kann ich aber leider nicht helfen.

Gruß
Wolfram

[herrmannj]

auf fhem seite kann ein reread cfg zu dem beschriebenen Verhalten führen (inkl händisch die cfg editieren)

[wvhn]

Nachdem hier bisher keine Katastrophenmeldungen hinsichtlich der neuen Treiberversion eingetroffen sind, habe ich diese in den develop branch gepusht.

Gruß
Wolfram