Bug: Longpoll-Reconnect und Healthcheck kaputt incl. Ursache

peterk_de · 11 Februar 2019, 13:09:27

Hallo zusammen,

mein neues Tablet hat die doofe Angewohnheit, nach 5 Minuten "Bildschirm aus" die Netzwerkverbindung zu verlieren, obwohl es selbst und mit FULLY gegenteilig konfiguriert ist. Und das automatische Reloaden der Seite, wenn der Bildschirm angeht, dauert zu lange. Aber das ist ein anderes Problem. In diesem Zusammenhang ist mir nur aufgefallen, dass unter diesen Umständen kein sauberer Reconnect von FTUI erfolgt. Ich habe etwas tiefer gegraben:

Was passiert: Zunächst fliegt FTUI der Websocket um die Ohren (oder AJAX, spielt keine Rolle), was auch sofort erkannt wird:

Code Auswählen

Error while Longpoll: undefined; 
FTUI is offline

Das heißt, es wird in der Methode setOffline u.A. folgendes gemacht:

Code Auswählen

ftui.config.doLongPoll = false;

Wenn jetzt beliebig viel später das Netzwerk wieder da ist (in meinem Fall, weil ich über Fully den Bildschirm anschalte), kommt brav

Code Auswählen

'Page became visible again -> start healthCheck in 3 secondes

und sofort der Healthcheck . Der findet aber kein Fehler und reconnected den Longpoll nicht, denn er prüft folgendes:

Code Auswählen

if (timeDiff / 1000 > ftui.config.maxLongpollAge &&
   ftui.config.maxLongpollAge > 0 &&
   !ftui.config.DEMO &&
   ftui.config.doLongPoll) { ///// ftui.config.doLongPoll == FALSE -> KANN NICHT WAHR WERDEN!
            	ftui.log(1, 'Healthcheck: No longpoll event since ' + timeDiff / 1000 + 'secondes -> ftui.setOnline()');
            	ftui.setOnline();
            	ftui.restartLongPoll();
   }

Mit anderen Worten, der Longpoll wird nicht wieder angeschaltet, egal wielang das letzte Longpollevent her ist, weil ftui.config.doLongPoll in setOffline explizit abgeschaltet wurde ... ich versuche mich mal an einem Fix ...

Edit: OK ich glaube ich hab es jetzt ein Stück weiter verstanden: Nach shortpoll_intervall wird der Reconnect tatsächlich wieder versucht und der Longpoll geht dann auch bei mir wieder ... laut Doku also per Default nach 15 Minuten:

Code Auswählen

shortpoll_interval 900 Integer Zeitraum in Sekunden, nach dem ein vollständiger Refresh stattfindet

Das Problem ist, dass bei funktionierendem Longpoll dann alle N Sekunden ein Shortpoll passiert. Also wenn ich das auf deutlich kürzer Stelle um schneller zu Reconnecten (sagen wir auf 5 Sekunden) der Load von dem Tablet und FHEM natürlich extrem viel höher wird.

Daher denke ich, wäre es sinnvoll, den Healthcheck zu patchen, damit das in diesem Fall schneller geht ... das habe ich versucht und es klappt prinzipiell:

Code Auswählen


    healthCheck: function () {

 		ftui.log(1, 'Healthcheck: Starting. ftui.config.maxLongpollAge=' + ftui.config.maxLongpollAge + ", ftui.config.doLongPoll="+ ftui.config.doLongPoll +", ftui.poll.long.lastEventTimestamp=" + ftui.poll.long.lastEventTimestamp.toLocaleString("de-de"));

        var timeDiff = new Date() - ftui.poll.long.lastEventTimestamp;
        
        var longpollConfig = $("meta[name='longpoll']").attr("content") || '1';
        var shouldDoLongPoll = (longpollConfig != '0');
        
        if (timeDiff / 1000 > ftui.config.maxLongpollAge &&
            ftui.config.maxLongpollAge > 0 &&
            !ftui.config.DEMO &&
            shouldDoLongPoll && !ftui.config.doLongPoll) {
            	ftui.log(1, 'Healthcheck: No longpoll event since ' + timeDiff / 1000 + 'secondes -> ftui.setOnline()');
            	ftui.setOnline();
            	ftui.restartLongPoll();
        } else {
            ftui.log(1, 'Healthcheck: Finished - no errors found.');
        }
    },

Allerdings haut der Reconnect der Websockets dann leider trotzdem nicht immer hin (ca. 1/10 mal klappt es nach einer Weile und er aktualisiert wieder), das heißt setOnline() / restartLongPoll müsste noch weiter debuggt werden, was ich leider zeitlich nicht schaffe, aber vielleicht hilft es ja soweit schon jemanden

peterk_de · 12 Februar 2019, 12:53:11

OK ich habe es aufgegeben das Reconnecten mit FTUI-Mitteln zu versuchen ... mal geht es, mal nicht - alles für einen hohen WAF nicht akzeptabel.

Meine Lösung besteht jetzt im kompletten deaktivieren des FTUI-Healthchecks und einem eigenen kleinen Javascript, das einfach in FULLY einen Seitenreload triggert, wenn keine Longpoll-Events mehr kommen. Das läuft jetzt perfekt. Kann ich bei Interesse gern posten, ist aber fummelig. Was auch noch toll wäre: In FTUI eine offizielle Option zu schaffen, einen Fully-Reload zu triggern. Mehr als

Code Auswählen

if (typeof fully != 'undefined') {
  fully.loadStartUrl();
}

an der richtigen Stelle, die ich allerdings nicht sicher identifizieren konnte - vermutlich irgendwie im healthCheck - braucht es dazu auch nicht (geht aber glaub ich nur in der Pro-Version).

An/ausschalten kann ich den Bildschirm vom Tablet allerdings trotzdem nicht spontan (über einen Bewegungsmelder), da die Seite jetzt direkt nach dem Einschalten neu geladen wird, was viel zu lange dauert. Mit dem Fully Screensaver ist es auch nicht viel besser. Abhilfe ist daher jetzt ein schwarzes <div> über den gesamten Bildschirminhalt in Kombination mit gesenkter Bildschirmhelligkeit ... sieht FAST aus wie abgeschaltet

... So ein Gefrickel. Bei meinem alten Tablet und den anderen Tablets lief bzw. läuft das so gut, aber das mit dem neuen - Galaxy Tab A (2016), Android 8.1 - ist echt krampfig.

Thorsten Pferdekaemper · 31 Juli 2019, 15:32:24

Hi,
kann es sein, dass das noch nicht repariert ist? Ich glaube, dass ich dasselbe Problem habe. (...und ich glaube mindestens noch Devender in diesem Thread: https://forum.fhem.de/index.php/topic,102567.0.html).
Das Blöde daran ist, dass es ziemlich schwierig bzw. zeitaufwändig ist, das ganze zu analysieren. Ist da schon jemand weiter gekommen?
Gruß,
Thorsten

peterk_de · 01 August 2019, 09:31:39

Ich hatte es aufgegeben, einen sauberen Patch dafür zu bauen, da nichts zuverlässig funktioniert hat. Bei meinem aktuellsten Tablet bricht mir immer noch oft der Websocket weg - ich habe aber bislang keine Systematik gefunden. Mal passiert es nach 5 Minuten, mal erst nach 12 Stunden.

Mein Workaround ist aktuell, dass ich per at einen Dummy in FHEM alle 60 Sekunden auf die aktuelle Uhrzeit setze. Im TabletUI ist für den Dummy ein (unsichtbares) Label, was ich alle 2 Minuten (also per Javascript-Timer, unabhängig von irgendwelchen Events) auf die aktuelle Uhrzeit prüfe. Ist die Uhrzeit im Label zu alt, heißt das, das aus welchem Grund auch immer keine Longpoll Events mehr in der GUI ankommen. Dann wird ein kompletter Page-Reload getriggert (über Fully). Das ist sozusagen ein vollständiger Ende-zu-Ende-Check. Der Reload triggert am Tag auch wirklich immer mindestens 2-3 mal. Dumm nur, dass das Laden ewig dauert und das alles ziemlich gebastelt ist.

Thorsten Pferdekaemper · 08 August 2019, 16:48:00

Hi,
guck mal da:
https://forum.fhem.de/index.php/topic,102884.0.html
Kannst Du die Korrektur mal ausprobieren?
Gruß,
Thorsten

peterk_de · 11 August 2019, 11:53:11

Klingt vielversprechend, kann ich aber leider grad nicht testen - die Hausautomatisierung ist bei mir momentan komplett deinstalliert zwecks Umzug ;-( Frühestens Ende September spiele ich wieder mit - aber wer anders probiert das doch sicher gern mal aus ^^

vbs · 11 August 2019, 12:01:51

Wie genau ist denn das Problem bei euch? Ich habe auch das Problem, dass das Tablet wenn sein Bildschirm aus ist, die Inhalte im Hintergrund nicht aktualisiert. Wenn dann der Bewegungsmelder den Bildschrim einschaltet, dann sieht man erst noch die alten (z.B. Temperatur-)Werte. Dann nach ca. 1 Sekunde wird offenbar aktualisiert und die Werte springen um. Reden wir damit vom selben Problem?

peterk_de · 11 August 2019, 21:19:30

vbs - nein. Symptomatisch ist es bei mir so, dass sich das Tablet irgendwann überhaupt nicht mehr aktualisiert, egal ob Bildschirm an oder nicht. Zumindest nicht in Echtzeit (nur noch Shortpoll). Grund ist das wegbrechen der Sockets und fehlender / klemmender Reconnect. Das geht nur mit schmutzigen Tricks länger als ein paar Stunden.

vbs · 11 August 2019, 21:28:44

Also ich hab es nach einigem hin- und her mit dieser App geschafft, dass das Tablet die WLAN-Verbindung dauerhaft aufrecht erhält:
https://play.google.com/store/apps/details?id=pl.mariobile.bestwifikeeper&hl=de

Nur wie gesagt komisch, dass Werte nicht aktualisiert werden (bzw. erst wenn dann auch der Bildschirm an geht). Aber ich kann das Tablet (Galaxy Tab 2) jederzeit per Netzwerk einschalten (also das Display).

Thorsten Pferdekaemper · 12 August 2019, 14:56:00

Hi,
bei mir kommt es anscheinend darauf an, wie lange das Telefon "schläft". Wenn der Bildschirm ausgeht und ich ihn sofort wieder "aufwecke", dann ist alles ok. Wenn ich aber länger warte (ein paar Minuten), dann dauert es bis zu einer Minute und 10 Sekunden, bis alles wieder aktuell ist. (Ich glaube, dass ich auch schon den Fall hatte, dass es länger als 70 Sekunden gedauert hat, aber das konnte ich nicht sicher nachvollziehen, daher will ich es erstmal dabei belassen bis das nachvollziehbare Problem gelöst ist.)
Wie im anderen Thread beschrieben liegt das bei mir daran, dass der Websocket "zu geht" und FTUI das nicht so richtig mitbekommt. Die Lösung für genau dieses Problem ist auch relativ einfach (siehe den anderen Thread).

Ich habe bisher noch nicht ausprobiert was passiert, wenn man FTUI auf "longpoll/ajax" zwingt. Ich kann mir vorstellen, dass es dann auch wieder besser klappt. Allerdings ist das meiner Meinung nach auch etwas unschön, da Websockets eher die "heutige" Technik sind.

Ich halte auch nicht viel davon, das über irgendwelche "lass die Verbindung offen"-Tricks zu lösen. Meiner Meinung nach kann die Verbindung immer irgendwie abbrechen (z.B. wenn ich nicht zuhause bin und grade nicht immer VPN laufen habe). In dem Fall schlägt der Fehler nämlich auch zu. Außerdem kann ich mir vorstellen, dass es schon seinen Grund hat, solche Verbindungen zu schließen, wie z.B. den Akku zu schonen. (Für stationäre Tablets ist das unter Umständen egal.)

EDIT: Witzig ist auch, dass das ganze passieren kann, wenn ein Widget gar keine Rückmeldung vom Backend braucht. Siehe die "späte Aktualisierung" in.
https://forum.fhem.de/index.php/topic,102885.0.html .

Gruß,
Thorsten

abc2006 · 28 August 2019, 10:22:50

Moin,
ich hab mir jetzt mal alle verwiesenen Threads durchgelesen und bin mir nicht sicher, in welchem ich am besten antworte.
Ich habe mit FTUI folgende Situation: Tablet, Huawei Media Pad T5, Fully Browser. Seite wird einwandfrei angezeigt und ist auch responsiv (wenn ich drauf drücke, schaltet fhem)
Wenn ich morgens runter komme, schaltet Fully via Bewegungserkennung das Display ein, die Werte sind aber deutlich veraltet (z.B. die Sonne knallt, der Wechselrichter lärmt auf Hochtouren, aber das Tablet zeigt "0W". Wenn ich direkt in fhemweb schaue (vom Handy aus z.B.) habe ich die korrekten Werte.
Nach einigen Sekunden scheint die Seite die letzten Werte "nacharbeiten" zu wollen, auf jeden Fall ändern sich die Werte mehrfach in wenigen Sekunden, wild hoch und runter, aber im Bereich dessen, was im normalen Betrieb auftritt.
Meistens verliere ich dann die Geduld und lade die Seite manuell neu, dann funktioniert es sofort wieder. Wenn ich lange genug warte, funktioniert es auch von alleine wieder, das können allerdings deutlich mehr als 2 Minuten sein.

Könnte das hiermit zusammenhängen oder ist das ein anderes Problem?

Grüße,
Stephan

Thorsten Pferdekaemper · 28 August 2019, 15:30:14

Zitat von: abc2006 am 28 August 2019, 10:22:50
Könnte das hiermit zusammenhängen oder ist das ein anderes Problem?

Ich glaube, dass das auch damit zusammenhängen kann. Soweit ich das verstehe (was nicht unbedingt ganz stimmen muss), holt sich FTUI beim Reconnect unter Umständen alles, was seit dem letzten bekannten Update passiert ist. (Also alle Events der Readings auf der dargestellten Seite seit "gestern Abend".) Je nach Gerät kann da schon was zusammenkommen. Wenn jetzt noch das Widget (oder auch ein anderes Widget auf der Seite) beim Repaint ("update") langsam ist, dann kann es da wohl schon zu Verzögerungen kommen.

Hast Du mal ausprobiert, ob es longpoll vs. websocket einen Unterschied macht?

Gruß,
Thorsten

Ulm32b · 28 August 2019, 16:46:30

Zitat von: abc2006 am 28 August 2019, 10:22:50
[...]
Wenn ich morgens runter komme, schaltet Fully via Bewegungserkennung das Display ein, die Werte sind aber deutlich veraltet
[...]

Soweit ich mich erinnere, hatte ich ein ähnliches Problem. Meine Lösung war, den Bildschirm nicht abzuschalten, sondern einen Screensaver mit schwarzem Bild zu aktivieren. Der Stromverbrauch steigt, aber alle Anzeigen sind auf dem aktuellen Stand. Später entwickelte ich das weiter: Sehr dunkles, individuelles Bild, darin in Großbuchstaben eingeblendet: Uhrzeit und Temperatur. Als Screensaver wird quasi eine eigens gestaltete FTUI-Seite mit Hintergrundbild verwendet. Mit dieser Lösung bin ich sehr zufrieden.

abc2006 · 29 August 2019, 13:44:30

Hi Thorsten,
in meiner index.html steht

Code Auswählen

<meta name="longpoll" content="1"> <!-- 1=longpoll;0=shortpoll every 30sec -->
<meta name="longpoll_type" content="websocket"> 
<meta name="longpoll_maxage" content="240"><!--wird in diesem Zeitraum kein Longpoll empfangen, wird die seite refreshed -->

ich dachte, websocket IST longpoll ...
Ich hab da vor längerer Zeit mal rumprobiert, auch mit änderungen im FHEMWEB (z.b. attr FHEMWEB longpoll websocket) ist die aktuelle einstellung.
Kannst du bitte nochmal genauer spezifizieren, welchen Unterschied ich testen soll/kann?
Meintest du, ich soll "websocket" auf "ajax" ändern? Muss ich dann im FHEMWEB auch was ändern?

ZitatAls Screensaver wird quasi eine eigens gestaltete FTUI-Seite mit Hintergrundbild verwendet. Mit dieser Lösung bin ich sehr zufrieden.

Wie hast du das technisch umgesetzt? Screensaver mit Uhr und Datum wär natürlich auch cool ...

Danke euch und Grüße,
Stephan

Thorsten Pferdekaemper · 29 August 2019, 17:08:57

Zitat von: abc2006 am 29 August 2019, 13:44:30
Code Auswählen Erweitern
<meta name="longpoll" content="1">  <meta name="longpoll_type" content="websocket"> <meta name="longpoll_maxage" content="240">
ich dachte, websocket IST longpoll ...

Das war tatsächlich von mir etwas ungeschickt formuliert. Ich meinte damit den "alten" longpoll, also mit type=ajax.
(Übrigens stimmt Dein Kommentar zum longpoll_maxage meiner Meinung nach nicht: Ein Refresh der Seite gibt's da nicht. FTUI macht dann nur die Verbindung zu und wieder auf. Es wird also ein neuer longpoll gestartet.)

Zitat
Kannst du bitte nochmal genauer spezifizieren, welchen Unterschied ich testen soll/kann?
Meintest du, ich soll "websocket" auf "ajax" ändern?

Ja, genau das.

Zitat
Muss ich dann im FHEMWEB auch was ändern?

Nein. Ich bin mir noch nicht 100%ig sicher, aber ich glaube, dass die Einstellungen in FHEMWEB bezüglich long/shortpoll für FTUI völlig egal sind.
Gruß,
Thorsten