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

Begonnen von shaddi, 19 Januar 2022, 23:46:25

Vorheriges Thema - Nächstes Thema

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.
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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

shaddi

Zitat von: justme1968 am 20 Januar 2022, 11:30:06
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
        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

shaddi

Hi,

Zitat von: justme1968 am 22 Januar 2022, 21:28:33
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...

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

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

Zitat von: shaddi am 23 Januar 2022, 17:17:10
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)

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.

logol01

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?

justme1968

ich komme erst ein ein paar wochen dazu wieder mehr zu machen. bis dahin sollte ein regelmässiges at mit einem set <bridge> reconnect helfen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Klaus.A

Ähnliches Problem hier mit der V2-API (EventStream):

Im Hue-Bridge Modul (FHEM) wird EventStream mit "connected" gemeldet, aber im Abstand von ein paar Tagen ist die direkte Verbindung via V2 API weg und es wirkt wieder das Polling (mit der bekannten Zeitverzögerung, daher ist die Störung dann sofort erkennbar).

Ein "set [hueBridgeName] reconnect" löst das Problem, dann geht alles wieder.

Die Bridge ist ganz normal im LAN eingebunden. Keinerlei Besonderheiten. Alle Hue-Funktionen funktionieren fehlerfrei, sowohl im Hue-System als auch über FHEM.
Eine schnelle Lösung ist natürlich ein "at" einmal am Tag.

Ich frage mich nur, was die Verbindung stört - habe bisher nichts gefunden, beobachte das weiter.

Gruß, Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API