HUEBridge / deCONZ & Interval

Begonnen von P.A.Trick, 05 Dezember 2021, 19:02:57

Vorheriges Thema - Nächstes Thema

P.A.Trick

Hallo Andree, ich bin gerade dabei zwei Aquara Sensoren in mein deCONZ zu packen. Das hat auch soweit gut funktioniert, jedoch bin ich gerade über das Interval gestoßen.
Ich meine mich erinnern zu können, dass deCONZ nicht "gepollt" wurde. Ich habe bei der Def kein Intervall angegeben.
Dennoch erscheint in den internen Reading 60 und das passt auch mit der Verzögerung bei dem die Events ankommen.

Internals:
   DEF        192.168.1.107
   FD         60
   FUUID      5db0ab00-f33f-cbb9-8433-87b815830848c359
   FVERSION   30_HUEBridge.pm
   INTERVAL   60
   NAME       deCONZ
   NOTIFYDEV  global
   NR         115
   NTFY_ORDER 50-deCONZ
   PORT       46616
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   bridgeid   00212EFFFF04864D
   buf       
   host       192.168.1.107
   mac        b8
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       Phoscon-GW
   swversion  2.13.1
   updatestate 0
   websocket  1
   websocketport 8443
   zigbeechannel 25
   READINGS:
     2020-10-14 13   alert           none
     2020-10-14 13   bri             254
     2020-10-14 13   colormode       xy
     2020-10-14 13   ct              370 (2702K)
     2020-10-14 13   effect          none
     2020-10-14 13   hue             8738
     2021-12-05 16   lastError       resource, /lights/20/state, is not modifiable. Device is not reachable.
     2020-10-14 13   lastseen        2020-10-14T11
     2020-10-14 13   onoff           1
     2020-10-14 13   pct             100
     2020-10-14 13   reachable       1
     2020-10-14 13   rgb             Unknown argument rgb, choose one of lights groups scenes rule rules sensors schedules whitelist
     2020-10-14 13   sat             198
     2021-12-05 19   state           connected
     2020-10-14 13   xy              0.3333,0.3333


Habe ich Demenz, oder ging das mal ohne Interval?
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

justme1968

wenn es ein internal websocket gibt kommen von deconz events per push. d.h. updates sollten fast sofort da sein wenn etwas über deconz passiert. das gilt nicht wenn du mit einer Fernbedienung lampen direkt schaltest. davon bekommt deconz selber nur verzögert etwas mit. und fhem danach sofort per event.

gepollt wird trotzdem zusätzlich noch alle 60 sekunden weil per event nicht alles versendet wird. das ist in diesem fall also nur backup.

wenn du im bridge device verbose auf 4 stellst solltest du sehen ob events kommen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

P.A.Trick

Hm ich habe
websocket = 1 im Internal, dennoch pollt deCONZ nur und schickt bei den Sensoren leider nicht direkt.

Kann ich prüfen, ob die Websocket Verbdinung überhaupt aufgebaut ist?

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

CoolTux

websocket  1
websocketport 8443


Bei Dir wurde wohl ein websocket eingerichtet.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

P.A.Trick

Gut dann stelle ich mir die Frage warum es nicht funktioniert? Jemand eine Idee wie ich es debuggen kann?
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

CoolTux

Irgendwelche Besonderheiten auf dem Weg zu Deinem phoscon? Firewall oder so?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

P.A.Trick

Phoscon läuft im docker auf einem entfernten pi. Keine FW oder ähnliches. Die Phoscon Webseite funktioniert einwandfrei. Dort werden die Status Änderungen instant angezeigt.
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

CoolTux

Zitat von: P.A.Trick am 06 Dezember 2021, 07:47:54
Phoscon läuft im docker auf einem entfernten pi. Keine FW oder ähnliches. Die Phoscon Webseite funktioniert einwandfrei. Dort werden die Status Änderungen instant angezeigt.

Auf welchen Port läuft Dein phoscon? Also wie greifst Du darauf zu?
nur http:// oder https:// oder http://ip:8080 oder https://ip:8443 ???

In Enddefekt muss in Deinem Docker der phoscon websocket auf 8443 erreichbar sein.
Im Logfile von FHEM steht dann sowas ähnliches wie

2021.12.01 03:21:45 3: PhosconGw: websocket opened to 192.168.240.21:443
2021.12.01 03:21:45 3: PhosconGw: websocket: Switching Protocols ok


Entscheident ist das Switching Protocols
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

justme1968

der port der auf phoscon seite für das websocket verwendet wird muss in der docker konfiguration berücksichtig werden und auf genau dem gleichen port von fhem aus erreichbar sein weil der port teil des protokolls ist.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

P.A.Trick

Zitat von: justme1968 am 06 Dezember 2021, 08:44:30
der port der auf phoscon seite für das websocket verwendet wird muss in der docker konfiguration berücksichtig werden und auf genau dem gleichen port von fhem aus erreichbar sein weil der port teil des protokolls ist.

Ich habe den 8443 mal explizit angegeben, allerdings ließ sich dann keine Verbindung aufbauen. Sofern ich den 8090er Port vom Webfrontend angebe, klappt es mit der Verbindung.
BTW. Ich habe gerade mal versucht den key (API) zu löschen. Dabei ist mein FHEM abgestürzt und danach scheint die Push Funktionalität wieder zu klappen. Merkwürdig....

2021.12.06 10:02:50 2: Perfmon: ready to watch out for delays greater than one second
Not a HASH reference at ./FHEM/30_HUEBridge.pm line 1465.
2021.12.06 10:02:38.530 4: parse status message for deCONZ
2021.12.06 10:02:38.530 3: unauthorized user
2021.12.06 10:02:38.473 4: using HttpUtils_NonblockingGet: GET
2021.12.06 10:02:28.523 4: parse status message for deCONZ
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

justme1968

#10
es werden zwei ports benötigt. der normale api port und der wesocket port. in fhem kannst du nur den ersten angeben. das war schon richtig. du musst dein docker richtig konfigurieren.


ich frage mich wirklich jedes mal warum man sich diesen docker mist antut. es gibt auf netzwerk ebene alles mögliche das richtig oder nicht automatisch funktioniert. tut euch einen gefallen und installiert nativ oder in einer richtigen virtualisierung.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

P.A.Trick

Zitat von: justme1968 am 06 Dezember 2021, 10:12:14
es werden zwei ports benötigt. der normale api port und der wesocket port. in fhem kannst du nur den ersten angeben. das war schon richtig. du musst dein docker richtig konfigurieren.

Ja das ist auch der Fall:

tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN


Blöd ist, dass es jetzt wieder funktioniert und ich weiß nicht warum.
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

justme1968

was ist der fall?

ich sehe nur einen port (8443) ...
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

P.A.Trick

Zitat von: justme1968 am 06 Dezember 2021, 10:16:20
was ist der fall?

ich sehe nur einen port (8443) ...

Ich habe nur nach dem einen gegrept:

➜  ~ netstat -tulpen|grep 8443                                          pi@raspberrypi3
tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      0          1792583    -
➜  ~ netstat -tulpen|grep 8090                                               pi@raspberrypi3
tcp        0      0 0.0.0.0:8090            0.0.0.0:*               LISTEN      0          1791493    -
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