[FUIP] Sporadisches 'Aufblitzen' des roten Disconnect-Bildschirms

Begonnen von fhemfreund, 09 Januar 2022, 18:32:21

Vorheriges Thema - Nächstes Thema

fhemfreund

ich sehe seit kurzem (vermutlich nach einem Update) sporadisch ein 'Aufblitzen' - sprich für eine sehr kurze Dauer den roten Disconnect-Bildschirm in FUIP. Der Fehler tritt auf allen Endgeräten (Tablet, PCs usw.) auf und ist nicht reproduzierbar. Sobald der Disconnect-Bildschirm wieder verschwindet (dauert max. 1/2 Sekunde) ist alles wieder wie vorher. Es ist auch sonst keine Beeinträchtigung in FUIP festzustellen. Ein Ändern der Parameter 'toastMessages' auf 'off' und 'longpoll' auf 'websocket' hatte keinen Erfolg.

Kann man irgendwo einen (längeren) Timeout einstellen, bzw. diesen Check komplett deaktivieren?

Andreas

Benbaeck

Würde mich auch Interessieren.
Habe seit kurzem genau das selbe Verhalten.

Thorsten Pferdekaemper

Hi,
ich schau mir das nochmal genauer an, aber hier schonmal ein paar Anmerkungen dazu:

Dass das Frontend mal kurz "disconnected" ist, wenn der Browser wieder aufwacht (weil z.B. das Handy eine Weile nicht angefasst wurde oder weil der Browser minimiert war oder das Tab gerade im Hintergrund war) ist im Prinzip normal. Das liegt an der Art und Weise wie sich die Teile schlafen legen. Es sieht dann beim Aufwachen so aus, als ob das Backend sich schon eine ganze Weile nicht mehr gemeldet hat. (...wobei man es schaffen könnte, für diesen Fall erst einmal ein Connect zu versuchen, bevor man alles rot macht.)

Bei anderen "disconnected" Szenarien sollte der rote Bildschirm immer gerechtfertigt sein, denn da gibt es schon eine gewisse Zeit, während der sich das Backend nicht mehr gemeldet hat bzw. ein Connect abgelehnt hat (sonst würde das Frontend es ja gar nicht mitbekommen).  ...aber vielleicht gibt es da inzwischen einen kleinen Bug. Das muss ich mal prüfen.

Die toast-Messages dürften darauf keinen Einfluss haben. ...und seit "multifhem" (also so seit September 2021) kann man den longPollType gar nicht mehr einstellen. Falls das bei Euch noch geht, dann bitte mal ein Update machen. Oder ist da der "longpoll" von FHEMWEB gemeint? Der ist für FUIP sowieso schon immer egal und inzwischen gibt es bei FUIP sowieso nur noch Ajax (also longpoll) und kein Websocket mehr.

Das mit dem Timeout schaue ich mir mal an, aber ich gehe mal davon aus, dass das nichts nützen würde. Das ganze komplett zu deaktivieren halte ich für keine gute Idee. Dann würde man überhaupt nicht mehr mitbekommen, wenn es keine Verbindung mehr gibt.

...aber wie gesagt: Ich schau mir's mal genauer an.

Gruß,
    Thorsten 
FUIP

fhemfreund

@Thorsten,

danke dass du mal danach schaust - das 'aufblitzen' ist echt etwas 'nervig'.

Zitat
Dass das Frontend mal kurz "disconnected" ist, wenn der Browser wieder aufwacht (weil z.B. das Handy eine Weile nicht angefasst wurde oder weil der Browser minimiert war oder das Tab gerade im Hintergrund war) ist im Prinzip normal. Das liegt an der Art und Weise wie sich die Teile schlafen legen. Es sieht dann beim Aufwachen so aus, als ob das Backend sich schon eine ganze Weile nicht mehr gemeldet hat. (...wobei man es schaffen könnte, für diesen Fall erst einmal ein Connect zu versuchen, bevor man alles rot macht.)
Das kann ich in meinen Szenarien ausschließen, da das auch im geöffneten Browser auf dem PC-Desktop z.B. beim Wechsel von Menüeinträgen auftritt. Wie gesagt, war dieses Verhalten früher gar nicht vorhanden.

Zitat
Die toast-Messages dürften darauf keinen Einfluss haben. ...und seit "multifhem" (also so seit September 2021) kann man den longPollType gar nicht mehr einstellen. Falls das bei Euch noch geht, dann bitte mal ein Update machen. Oder ist da der "longpoll" von FHEMWEB gemeint? Der ist für FUIP sowieso schon immer egal und inzwischen gibt es bei FUIP sowieso nur noch Ajax (also longpoll) und kein Websocket mehr.
Ja hatte den von FHEMWEB probiert. Gut zu wissen - drehe das dann inkl. der toast Messages wieder zurück.

Zitat
Das mit dem Timeout schaue ich mir mal an, aber ich gehe mal davon aus, dass das nichts nützen würde. Das ganze komplett zu deaktivieren halte ich für keine gute Idee. Dann würde man überhaupt nicht mehr mitbekommen, wenn es keine Verbindung mehr gibt.
Naja ggf. könnte man es ja optional per Attribut deaktivierbar machen? In meinem Fall - falls es keine andere Lösung gäbe - wäre das in jedem Fall für mich die bessere Option.

Andreas

Thorsten Pferdekaemper

Hi,
das ganze passiert gar nicht durch einen Timeout, sondern wenn die Verbindung zu FHEM tatsächlich fehlschlägt. Vielleicht kann ich da was einbauen, dass das Teil trotzdem erstmal einen Reconnect versucht und dann erst den Fehlerbildschirm bringt.
Aber ich würde gerne erst einmal wissen, was da vor sich geht. Könntet Ihr mal folgendes machen:

Das Attribut loglevel auf 1 setzen
Das Attribut logtype auf localstorage setzen
Falls das Attribut logarea (oder so) gesetzt ist, dann bitte löschen.
(Das alles natürlich im FUIP-Device.)
Dann das ganze mal laufen lassen, bis es mal wieder blitzt, gerne auch mehrfach.
Dann ein refresh der Seite machen (das schreibt dann die Logdatei tatsächlich).
In /opt/fhem/FHEM/lib/FUIP/log müsste jetzt was stehen. Das hätte ich gern.

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
ich hatte jetzt auf einer meiner Testinstallationen auch den Effekt und konnte das tatsächlich auch ins Log schreiben. Das Problem tritt dann auf, wenn die Seite die ganze Zeit offen ist, aber für 15 Minuten kein Event vom Backend kommt. (D.h. dass sich 15 Minuten lang keine Änderung ergibt.) Dann wird nicht nur der Longpoll neu gestartet, sondern sicherheitshalber auch nochmal ein Shortpoll gemacht, um sicher zu gehen, dass man nichts verpasst hat.
Das ist aber etwas verworren implementiert (von mir...) und das Teil schießt sich den eigenen Shortpoll ab, wundert sich darüber und haut das Fehler-Overlay raus.
An der Stelle sind dann alle Verbindungen weg (Shortpoll und Longpoll) und das ganze kann sich in Ruhe wieder neu aufbauen.
Jetzt ist mir glaube ich klar, was da passiert und kann das umbauen. ...aber nicht mehr heute.
Gute Nacht,
   Thorsten
FUIP

fhemfreund

@Thorsten,

fyi - hatte das logging eingeschaltet - 'natürlich' kam der Fehler während des Loggings bei mir nicht. Umso besser ist, dass du ihn nachstellen konntest.

Andreas

Thorsten Pferdekaemper

Hi,
so, das sollte jetzt erledigt sein. Mal kurz FUIP updaten und es passiert hoffentlich nicht mehr.
Ich habe da jetzt keine neuen Timeouts oder ignorier-Schalter eingebaut, sondern einfach das Durchstarten der Verbindung etwas geordnet. Dadurch müsste jetzt sogar der Seitenwechsel etwas schneller gehen, aber das bemerkt man möglicherweise auch nicht.
Ein bisschen was habe ich auch hier erklärt:
https://pferdekaemper.com/fuip/doc/changes.html
Gruß,
   Thorsten
FUIP

fhemfreund

Zitat von: Thorsten Pferdekaemper am 18 Januar 2022, 22:49:00
so, das sollte jetzt erledigt sein. Mal kurz FUIP updaten und es passiert hoffentlich nicht mehr.
Habe dein Update eingespielt (inkl. letzter Fhem Version) - hatte aber gerade wieder einen kurzen Aufblitzer - also bei mir tritt leider daher das Problem immer noch auf

Andreas

Thorsten Pferdekaemper

Hi,
Mist, dann ist da noch was anderes. ...also wenn Du es doch noch schaffst, das zu tracen, dann her damit. Ich werde es auch mal weiter beobachten.
Gruß,
   Thorsten
FUIP