HUEBridge push api unterstützung

[dmoibm]

Super! Funktioniert sehr gut!

die implementierung hier ist ohne doku und durch probieren entstanden. inzwischen hat phillips das neue api angekündigt und in einer unvollständigen test version zum teil dokumentiert. wenn die doku vollständig ist das ganze nicht mehr beta status hat baue ich es komplett ein und dann wird es auch eingecheckt. vorher vermutlich nicht.

Bin also auch bereit zu testen. Habe diverses neues und altes Material von Hue.

[justme1968]

ich habe ganz oben eine neue version angehängt. damit müssten die buttonevents für die diversen hue schalter und buttons funktionieren. getestet mit einem hue dimmer switch, einem hue smart button und einem friends of hue senic smart switch. hue tap müsste auch gehen.

es gibt wie gehabt events für initial press, hold, short release und long release.

das schnelle pollen sollte damit nicht mehr nötig sein.

achtung: nur die hardware die mit batterie betrieben wird unterstützt repeat und long. d.h. senic und tap liefern nur press und release.

[dmoibm]

Super! Herzlichen Dank!

Nach Kurztest: funktioniert sehr gut!

Nur eine Kleinigkeit: Beim Modul LWV001 ist ein (bei mir) nicht existentes Icon "hue_filled_filament" eingetragen (31_HUEDevice.pm Zeile 84/85).

[justme1968]

das icon habe ich erst vorgestern mit drei weiteren neuen eingecheckt. du kannst es dir per update images/fhemSVG holen.

[stera]

Guten Morgen zusammen,

herzlichen Dank erstmal, dass hier fleißig weiter gearbeitet wird. Ich habe heute die beiden Dateien ersetzt und neu gestartet. Noch scheint das bei mir nicht zu pushen. Die Lampen sind trotzdem verzögert, wenn man über die HUE App einschaltet. Soll man bei der Sensor Config das PollInterval entfernen?

Irgendwas mache ich bestimmt noch falsch und hoffe auf eure Antwort.

Vielen Dank.

Code Auswählen Erweitern


Internals:
   DEF        sensor 121 1 IODev=HUEBridge1
   FVERSION   31_HUEDevice.pm:0.254300/2022-01-06
   ID         S121
   INTERVAL   1
   IODev      HUEBridge1
   NAME       HUE_WZ_Schalter
   NR         206
   STATE      4000


Code Auswählen Erweitern


Internals:
   DEF        192.168.10.28
   EventStream connecting
   FVERSION   30_HUEBridge.pm:0.242960/2021-04-21
   INTERVAL   60
   NAME       HUEBridge1
   NOTIFYDEV  global
   NR         18
   NTFY_ORDER 50-HUEBridge1
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.48.0
   bridgeid   xx
   has_v2_api 1


[justme1968]

EventStream connecting

d.h. die verbindung steht noch nicht.

gib mal von hand ein set HUEBridge1 reconnect ein. geht es dann auf connected?

[stera]

Hallo,

okay, danke für die Antwort. Ich habe den Befehl probiert, das ganze System nochmal neu gestartet, das Hue Gatway neu gestartet. Lieder ohne Erfolg.
Liegt es am Docker Betrieb oder müssen die attr. richtig gesetzt werden ?

Gruß,
Stefan

[justme1968]

es könnte an docker liegen.

was sagt das log bei verbose 5?

dein bridge device hat auch recht wenig internals. ist das eine philips bridge oder deconz?

[stera]

Ne, ist eine normal Hue Bridge. Das Log füllt sich schnell, weil ich viele Polls wg BWM und Dimmer habe..

Muss ich bei Docker ein Port aufmachen?

Code Auswählen Erweitern


2022.01.15 13:31:17.488 4: using HttpUtils_NonblockingGet: GET sensors/157
2022.01.15 13:31:17.496 5: HUEBridge_dispatch: sensors/157
2022.01.15 13:31:17.622 4: HUEBridge_closeEventStream: closing eventstream
2022.01.15 13:31:17.623 4: HUEBridge_openEventStream: tying to connect to eventstream
2022.01.15 13:31:17.741 4: using HttpUtils_NonblockingGet: GET sensors/167
2022.01.15 13:31:17.751 5: HUEBridge_dispatch: sensors/167
2022.01.15 13:31:17.784 4: using HttpUtils_NonblockingGet: GET sensors/95
2022.01.15 13:31:17.801 5: HUEBridge_dispatch: sensors/95
2022.01.15 13:31:17.846 4: using HttpUtils_NonblockingGet: GET sensors/46
2022.01.15 13:31:17.855 5: HUEBridge_dispatch: sensors/46
2022.01.15 13:31:17.866 4: using HttpUtils_NonblockingGet: GET sensors/102
2022.01.15 13:31:17.875 5: HUEBridge_dispatch: sensors/102


Hatte nur nicht alle internals mitgenommen:

Code Auswählen Erweitern


Internals:
   DEF        192.168.10.28
   EventStream connecting
   FUUID      5d960448-xxxxxx
   FVERSION   30_HUEBridge.pm:0.242960/2021-04-21
   INTERVAL   60
   NAME       HUEBridge1
   NOTIFYDEV  global
   NR         18
   NTFY_ORDER 50-HUEBridge1
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.48.0
   application id 300c5cb3-xxxxxxxx
   bridgeid   0017xxxxx
   has_v2_api 1
   host       192.168.10.28
   mac        00:17:xx:60:f2:xx
   manufacturer Signify
   modelName  Philips hue bridge 2015
   modelid    BSB002
   name       Bredx
   swversion  1949107040
   updatestate 1 [18]
   zigbeechannel 25
   READINGS:
     2022-01-15 12:03:07   lastError       resource, /lights/63, not available
     2022-01-15 13:27:47   state           connected
     2022-01-08 14:55:07   swupdate        1.49.1.1
   helper:
     apiversion 77824
     count      0
     last_config_timestamp 1642249667
     offsetUTC  3600
     updatestate 1
     HTTP_CONNECTION:
       FD         10
       NAME       
       addr       https://192.168.10.28:443
       auth       0
       buf       

       compress   1
       displayurl https://192.168.10.28/eventstream/clip/v2
       header     HUE-Application-Key: Bgxxxxx
Accept: text/event-stream
       host       192.168.10.28
       httpdata   : hi



[justme1968]

das log bitte vom set HUEBridge1 reconnect sein.

[stera]

Sollte da mehr kommen? Ich habe das gemacht und da kommen nur die 2 Zeilen

[stera]

So, ich habe nochmal weiter getestet.

Auf einer anderen FhemInstanz mit Docker ist das gleiche Problem. Nächster Versuch auf einer normalen Raspberry Installation. Hier funktioniert es.

Scheint noch Probleme in einem DockerContainer zu machen. Hast du eine Idee @justme1968

Viele Grüße

[justme1968]

warum tut ihr euch immer wieder diesen docker mist an. fast alles was das netzwerk angeht ist dort nicht plug&play.

in dem fall habe ich gerade keine idee, die verbindungen gehen alle vom modul aus. das sollte eigentlich der einfachere fall sein.

[stera]

Docker hat für mich einiges an Vorteile -> Mehrere FhemInstanzen, Auf Synology Diskstation leicht zu installieren, die gemappten FhemOrdner können per TimelimeBackup gesichert werden, Mit einer Installation könnte ich keine 2 GAssisstant Verbindungen herstellen und und...) Das System läuft seit Umzug auf Synology/Docker super stabil.

Echt komisch was das ist. Liegt es vllt daran, dass Fhem einen anderen Port außerhalb hat (nicht 8083)? Kann ich in der PM irgendeine Logzeile hinzufügen um mehr Infos zu bekommen woran es scheitert?

Schönen Sonntag noch.

[justme1968]

die ganzen vorteile habe ich mit echter virtualisierung auch ohne mir die ganzen nachteile zu erkaufen. auch auf einer synology mit dem virtual machine manager. und fhem selber läuft ganz problemlos nativ auf meiner diskstation.

und wie man sieht läuft es nur so lange stabil wie es keine probleme gibt

prinzipiell ist docker was das netzwerk angeht nicht transparent und es gibt hier eine ganze reihe threads deren bei denen docker die ursache des problems war und das ist noch ärgerlicher wenn man erst nach einigem hin und her drauf kommt.

aber zurück zum thema: wie gesagt baut im aktuellen fall fhem die verbindung auf. diese richtung sollte eigentlich tatsächlich problemlos gehen. und die bridge ist eine echte.

stell mal global auf verbose 5 und schau ob im log mehr zu sehen ist.