Nach ca 10 Minuten keine Daten mehr vom Backend

[KaiAlfonso]

Hi,

ich hab schon seit mehreren Versionen (ist auch mit 3.3 nicht besser) folgendes Problem.

Ich habe 2 Wandtablets mit Android Betriebssystem. Dort zeige ich mit der App Fully die Smartvisu Seite an. Irgendwann ca 10-12 Minuten) verliert er wohl die Connection zum Backend und zeigt keine Statusänderungen mehr an, bis ich die Seite reloade. Es kommt auch kein Fehler Badge oder ähnliches.

Backend ist Fhem - kann natürlich auch am Backend Treiber liegen. Ich habe mir erstmal beholfen, in dem ich in Fully ein Auto-Reload mache, halte das aber nur für ein Workaround.

Kennt jemand das Problem?

Außerdem bekomme ich seit dem Update auf 3.3 nach ca 2 Minuten folgenden Fehler in der JS Console

index.php:1 Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received

Das hat mit meinem Problem (wohl) nix zu tun, weil danach noch Änderungen angezeigt werden

Viele Grüße

Kai

[KaiAlfonso]

index.php:1 Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received

Ich hatte gesehen, das vor 45 Minuten noch ein neues Release gepushed wurde - damit kommt zumindest der JS Fehler nicht mehr

[wvhn]

Hallo Kai,

das Problem ist bei mobilen Browsern bekannt. Dafür gibt es eigentlich den Reconnect-Mechanismus in smartVISU, der beim fhem-Treiber schon eingebaut ist.
Zum Stromsparen geht das Tablet in den Schlaf und kappt dabei die Verbindung zum Websocket-Server. In der Regel sollte dabei noch ein "close"-Event getriggert werden, den der Treiber verarbeitet. Der fhem-Treiber startet bei Erkennen des close-Events den Reconnect-Timer, der im Abstand von einer Minute immer wieder versucht, den Websocket zu öffnen. Bedingung dafür ist eben, dass der close-Event getriggert wurde und (nach dem Aufwachen des Tablets) vom Treiber erkannt wird. Beides hängt von der verwendeten Hardware und vom Browser ab. Fully scheint da leider in der kostenlosen Version nicht sehr kooperativ zu sein.

Die Bezahlversion von Fully hat ein javascript-API, das eigene Events für das Einschlafen und Aufwachen triggert. Hierzu hatte ich seit v3.2 Eventhandler eingebaut. die dies erkennen und und den Websocket gezielt schließen und wieder öffnen.

Bei mobile Safari auf iOS- / iPad-OS werden die close-Events in der Regel erkannt. Bei meinen Tests hatte ich festgestellt, dass der Reconnect sporadisch auch in der Standby-Phase gestartet, dann aber nicht zu Ende ausgeführt wurde. Indem der Reconnect ab v3.3 nur noch startet, wenn auch gerade eine Visu-Seite aktiv ist, funktioniert das in meinen bisherigen Tests mit höherer Zuverlässigkeit - auch bei einem alten Android-Handy. Die gleiche Logik habe ich auch für fhem eingebaut.

Wir können dem Thema gerne im neuen Jahr noch einmal nachgehen. Ich hatte mir eine debug-Seite geschrieben, die einige Lebenszeichen des Treibers auf einer normalen Visu-Seite ausgibt. Die kann ich Dir dann schicken und eine präparierte Treiberversion dazu erstellen.

Gruß
Wolfram

[KaiAlfonso]

Hi,

danke für deine ausführliche Antwort. Ich habe Fully in der lizenzierten Version - muss man die API explizit aktivieren?. Der Fehler kommt aber auch auf dem Windows PC, wenn ich die Seite in einem Chrome Tab geladen habe (in den Dev Tools mit iPhone Profile, wenn das wesentlich ist)

Wir können gerne im neuem Jahr mehr ein deep dive machen, um ggf. den Fehler zu eliminieren.

[KaiAlfonso]

Nachtrag: Die Javascript Engine war deaktiviert - ich habe die mal aktiviert und den Web Autoreload rausgenommen und schaue mal, ob sich was verbessert hat.


Vielen Dank Dir

[wvhn]

Moin,

das JavaScript-API von Fully muss man nicht aktivieren. Das ist einfach da, wenn man die richtige Version hat. Ich hatte das mit einem Anwender ausführlicher getestet.

In der ./pages/base/root.html werden die Eventhandler ab Zeile 268 angelegt:

// if a fully kiosk browser is active stop the websocket when device goes in sleeping mode
if (typeof fully !== 'undefined')  {
fully.bind('screenOn',"io.init();");
fully.bind('screenOff',"io.close();");
};

Um zu testen, ob die Eventhandler getriggert werden, kannst Du anstelle von io.init() und io.close() etwas einfügen, das man am Tablet sehen kann. Also ein item schreiben, das auf einer Visu-Seite angezeigt wird, oder einfach ein Licht einschalten.

io.write('item', '1')

Wenn das Verhalten am PC unter Windows auch auftritt, dann muss man auf fhem-Seite die Einstellungen des Websocket-Servers unter die Lupe nehmen.

Gruß
Wolfram

[KaiAlfonso]

Danke für für die Erläuterung Wolfram,

ich habe mal ein wenig Komplexität reduziert, das heißt, ich gehe jetzt nicht mehr über den Reverse Proxy (ich nutze Traffik) auf die Visu, sondern über die interne URL und schon funktioniert das nach ein paar Stunden immer noch. Das heißt, der Proxy macht da irgendein quatsch. Werde ich mich mal bei Gelegenheit drum kümmern - die Tablets können auch über die interne URL gehen, die externe mit Reverse Proxy brauche ich eh nur für mein Handy, wenn ich außerhalb des Home-Netzes bin und da komme ich eh in kein Timeout, da ich nur kurz was einstelle oder nachschaue.