30_HUEBridge.pm / Websocket-Verbindung manchmal in undefinierten Zustand

[shaddi]

Hi,

ich habe jetzt öfters beobachtet, dass in manchen Situationen die Websocket-Verbindung weg fliegt, aber das Modul das nicht mitbekommt. Es kann vorkommen, dass zeitgleich beide Systeme (fhem + deCONZ) kaputt gehen und dann die Variable websocket irgendwie auf 1 bleibt, obwohl keine Websocket-Verbindung mehr exisitiert. Man merkt das recht schnell, wenn die Zigbee-Taster erst Minuten später reagieren, da sie per Poll abgeholt werden.

Ich konnte den Zustand nicht aktiv erzwingen, weder durch kill-9 von fhem noch deCONZ oder gleichzeitig. Aber sobald der Socket weg ist, versucht das Modul die Verbindung nicht neu aufzubauen, wenn websocket=1 noch in den internals ist. Ich weiss also nicht, wie das passiert..

Ich habe jetzt in das Modul ein HUEBridge_closeWebsocket($hash); in den "inactive"-call gepfuscht; damit kann ich wenigstens im Betrieb den reconnect neu forcieren.

Gibt es keine bessere Möglichkeit die Verbindung des Websockets zu tracken? Irgend eine art "Heartbeat?"

bye,
 Karl

[P.A.Trick]

Ja das Problem habe ich auch.
Vermutung: Es passiert, wenn der deCONZ Prozess zum Beispiel neu gestartet wird. Danach scheint es keinen Neuaufbau der Websocket Verbindung zu geben.

[shaddi]

Ja, eben das konnte ich nicht nachstellen. Wenn ich den deCONZ stoppe, wird auf fhem-Seite sofort das close getriggert und die interne Variable gelöscht. Er versucht dann auch laut Log immer wieder neu zu verbinden. Sobald der deCONZ wieder da ist, läuft auch wieder alles. Gleiches gilt auch, wenn ich den FEHM durch trete..

Das muss also irgendwas sein, dass das Modul nicht mitbekommt, dass die Connection gerade weg geflogen ist und deswegen das Event mit Vars löschen nicht durchführt.
Die Polls laufen dann brav weiter, die gehen ja per HTTP/GET, glaube ich..? Aber per Websocket kommt logischerweise nichts mehr rein..

[justme1968]

bitte versuch mal mit netstat auf dem fhem und auf dem deconz rechner rauszufinden in welchem zustand die verbindung gerade ist.

wenn auf netzwerk ebene nicht zu bemerken ist das die verbindung weg ist kann das modul nicht reagieren.

ab morgen sollte bei einem set reconnect das websocket und der event stream neu verbunden werden.

ich könnte einen reading für das letzte emfangene event einbauen. darauf könnte man dann ein notify setzen das neu verbindet wenn länger kein event gekommen ist. das hängt natürlich dann davon ab ob es genug devices im system gibt die auch events erzeugen.

[justme1968]

ab morgen gibt es ein createEventTimestampReading attribut um für jedes event ein reading mit timestamp zu erzeugen. darauf kann man dann einen watchdog für ein reconnect ansetzen.

[shaddi]

bitte versuch mal mit netstat auf dem fhem und auf dem deconz rechner rauszufinden in welchem zustand die verbindung gerade ist.

Ich konnte es gerade reproduzieren. Ich musste dafür meinen deCONZ hart vom Strom trennen, damit er sein disconnect nicht raus schicken kann. Nach einer Zeit ist dann zwar die TCP-Session im netstat dann auch weg, aber das Modul behauptet immer noch, dass websocket=1 sei. Werde heute mal updaten; dann hat man wenigstens ein manuelles reconnect zur Verfügung. Geschickter wäre aber eine Art Keepalive. Hab jetzt die Websockets RFC nicht gelesen.. gibts sowas wie ein Keepalive?

[justme1968]

hattest du probiert ob du mit dem createEventTimestampReading weiter kommst?

ansonsten: ja. websockets haben ein keepalive. aktuell wird nichts damit gemacht. ich weiss auch nicht ob deconz etwas sendet.

du kannst im HUEBridge modul in zeile 106 mal ein logging einbauen und schauen ob etwas kommt und mir dann sagen wie oft.

du kannst auch probieren an dieser stelle etwas wie

Code: [Auswählen]

        RemoveInternalTimer($hash, 'HUEBridge_openWebsocket' );
        InternalTimer(gettimeofday()+300, 'HUEBridge_openWebsocket', $hash, 0);
einzubauen und die 300 auf etwas stellen das zuverlässig größer als der abstand zwischen den keepalive nachrichten ist.

[shaddi]

Hi,

hattest du probiert ob du mit dem createEventTimestampReading weiter kommst?

ansonsten: ja. websockets haben ein keepalive. aktuell wird nichts damit gemacht. ich weiss auch nicht ob deconz etwas sendet.

du kannst im HUEBridge modul in zeile 106 mal ein logging einbauen und schauen ob etwas kommt und mir dann sagen wie oft.

du kannst auch probieren an dieser stelle etwas wie

Code: [Auswählen]

        RemoveInternalTimer($hash, 'HUEBridge_openWebsocket' );
        InternalTimer(gettimeofday()+300, 'HUEBridge_openWebsocket', $hash, 0);
einzubauen und die 300 auf etwas stellen das zuverlässig größer als der abstand zwischen den keepalive nachrichten ist.

ok, also der deCONZ sendet von sich aus keinen Keepalive. Im Netstat bleibt die TCP-Session (auch nach 4 Stunden offline-Zeit des deCONZ) auf established. Somit findet niemals ein disconnect o.ä. event statt. Das Modul bekommt also niemals mit, dass die Verbindung tot ist. Der Poll der Devices findet ja auch über einen speraten HTTP GET statt; dieser kann die tote Verbindung auch nicht erkennen.

Ich versuche mal mit meinen rudimentären Perl-Kentnissen ein KeepAlive einzubauen... Vielleicht in dem Poll-Timer oder so...

[justme1968]

schau dir erst mal an ob createEventTimestampReading funktioniert. das wird nur geändert wenn daten über den eventmechnismus gekommen sind. nicht für daten vom pollen.

ansonsten kann du die beiden zeilen von oben auch vor das do in zeile 81 packen. das sollte auch gehen.

[shaddi]

Ja, aber das ist eigentlich doch nur Symptombekäpfung. Sauberer wäre es, wenn die Verbindung geprüft wird und ggf. dann neu aufgebaut wird.

Klar, das wird bei 99% der anderen User nie auftauchen, da sie vermutlich den deCONZ auf der selben Kiste haben wie den FHEM. Da gibt es niemals
den Zustand, dass eines der Geräte spontan rebootet oder offline geht.

[MadMax-FHEM]

Klar, das wird bei 99% der anderen User nie auftauchen, da sie vermutlich den deCONZ auf der selben Kiste haben wie den FHEM. Da gibt es niemals
den Zustand, dass eines der Geräte spontan rebootet oder offline geht.

Bei mir laufen fhem und deCONZ (auch) auf unterschiedlichen PIs.

Ich mache regelmäßig updates und ab und an auch mal einen reboot unabhängig voneinander...

Probleme habe ich bislang noch keine feststellen können...

Gruß, Joachim

[shaddi]

Das passiert nur, wenn eines der beiden Enden nicht sauber herunter gefahren wird. Da kommt halt dann einfach kein TCP-FIN was die Verbindung abbauen würde. Und da vom Modul auf diesem Link auch nie etwas raus geht, wird hier halt auch nicht getriggert.