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?
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.
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?
websocket 1
websocketport 8443
Bei Dir wurde wohl ein websocket eingerichtet.
Gut dann stelle ich mir die Frage warum es nicht funktioniert? Jemand eine Idee wie ich es debuggen kann?
Irgendwelche Besonderheiten auf dem Weg zu Deinem phoscon? Firewall oder so?
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.
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
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.
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
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.
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.
was ist der fall?
ich sehe nur einen port (8443) ...
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 -