Autor Thema: 30_HUEBridge.pm / Websocket-Verbindung manchmal in undefinierten Zustand  (Gelesen 838 mal)

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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

Offline P.A.Trick

  • Hero Member
  • *****
  • Beiträge: 1940
  • Love it, change it or leave it
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.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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..

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21293
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, …

https://github.com/sponsors/justme-1968

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21293
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, …

https://github.com/sponsors/justme-1968

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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?

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21293
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
        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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, …

https://github.com/sponsors/justme-1968

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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
        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...

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21293
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, …

https://github.com/sponsors/justme-1968

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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.

Online MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 12303
  • NIVEAu ist keine Creme...
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Offline shaddi

  • New Member
  • *
  • Beiträge: 31
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.

Offline logol01

  • New Member
  • *
  • Beiträge: 3
Hallo zusammen,

es scheint so, dass Ihr Euch hier auskennt.
Erstmal muss ich mich entschuldigen - ich bin Anfänger.....

ich habe eine original Philips Hue Bridge mit FHEM eingebunden.
FHEM läuft auf einem Raspberry.
In der HUE Bridge ist ein "Friends of Hue Switch" eingebunden, den ich in meiner FHEM installation auch finde.
Die Betätigung des Schalters wird mir in meiner FHEM Installation angezeigt über "Status".
Ich schicke das Signal per MQTT zu meinem Loxone Miniserver und das funktioniert perfekt!

Nach 1-2 Tagen geht das plötzlich nicht mehr.

Über die HUE iPhone App sehe ich aber, dass das Drücken des Schalters in der Hue Bridge ankommt - in FEHM jedoch nicht mehr.
Kann das bei mir auch diese Websocket Problem sein?
Wenn ich nun FHEM mit "shutdown" neu starte, funktioniert der Schalter sofort wieder und das drücken des Schalters kommt sofort wieder in FHEM an.

Nun meine Frage: kennt ihr das Problem?
Was kann ich dagegen machen?

Gibt es irgend eine Lösunge, dass die Verbindung stabil läuft?
« Letzte Änderung: 12 August 2022, 21:21:59 von logol01 »

 

decade-submarginal