HUEBridge push api unterstützung

[stera]

Ich habe nun nochmal weiter getestet. Dachte, wenn ich im Docker ein Fhem aufbaue, das im Host-Netzwerk läuft sollte es eigentlich gehen. Aber leider das geht auch nicht. Habe sogar die fhem.cfg von der Raspberry-Testinstallation genommen womit es auf dem Raspi funktioniert.

Allerdings konnte ich auf dem Docker "Fhem Host" ein Fehler im Log endlich sehen:
Nach dem Start habe ich nochmal ein "set HUEBridge1 reconnect" gemacht

Hier nochmal ein Vergleich zwischen Raspberry Testversion und Docker FhemHost. Der Unterschied ist die Nachricht mit dem "NonBlocking via https" ?

Code: [Auswählen]

----------- Docker Fhem Host ---------------------
-------geht leider nicht -----------------

2022.01.16 22:24:58 5: Cmd: >set HUEBridge1 reconnect<
2022.01.16 22:24:58 4: HUEBridge_openEventStream: tying to connect to eventstream
2022.01.16 22:24:58 5: HttpUtils url=https://192.168.10.28/eventstream/clip/v2
2022.01.16 22:24:58 4: IP: 192.168.10.28 -> 192.168.10.28
2022.01.16 22:24:58 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.28
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
Accept: text/event-stream
HUE-Application-Key: ooEIqreUStwwiwf0HvICxxxxxxxxxxxxxxxxxxxxxxx

2022.01.16 22:24:58 5: GET /fhem?room=HUEDevice&fw_id=20 HTTP/1.1
Host: 192.168.10.65:8083
Connection: keep-alive
Cache-Control: max-age=0


Code: [Auswählen]

----------- Raspberry Testinstallation ---------------------
-------so geht es -----------------

2022.01.16 21:22:54 5: Cmd: >set HUEBridge1 reconnect<
2022.01.16 21:22:54 5: HttpUtils url=https://192.168.10.28/eventstream/clip/v2 NonBlocking via https
2022.01.16 21:22:54 4: IP: 192.168.10.28 -> 192.168.10.28
2022.01.16 21:22:54 5: HttpUtils request header:
GET /eventstream/clip/v2 HTTP/1.1
Host: 192.168.10.28
User-Agent: fhem
Accept-Encoding: gzip,deflate
Connection: keep-alive
Last-Event-ID: 1642368154:0
HUE-Application-Key: wsjjiBK0LfAxa6s1VYIxxxxxxxxxxxxxxxxxxxxxxx
Accept: text/event-stream

2022.01.16 21:22:54 5: GET /fhem?room=HUEDevice&fw_id=294 HTTP/1.1
Host: 192.168.10.113:8083
Connection: keep-alive
Cache-Control: max-age=0


[stera]

Hallo,

ich nochmal. Wahrscheinlich werden wir so schnell noch keine Lösung finden. Ich habe auf dem Raspberry auch Docker installiert und auch hier besteht das Problem, also kann man die Synology ausschließen. Ich hatte zwischendurch eine IOBrokerTestversion im Docker hochgefahren. Hier hat man mittlerweile auch schon ein hue-push-client für den Adapter. Da funktioniert es innerhalb Docker. Alles merkwürdig.

Bis eine Lösung da ist, werde ich in Fhem auf dem Raspberry die Bewegungsmelder und Switch pushen und es per MQTT schicken. Dann hört endlich das pollen auf.

Mir ist noch aufgefallen, dass die Zustände anders sind. Soll das so sein?
z.B. SwitchDimmer hat im State beim drücken den Wert "0100" u. "0101" und nicht "1000" und "1001". Wenn man dann weiterhin pollt, dann überschreibt er den Wert nach 1min wieder mit dem richtigen Wert -> also 0100 -> 0101 -> nach 1min dann wieder 1001

Gruß,
Stefan

[justme1968]

das war ein tippfehler. im ersten post ist eine korrigierte version.

[justme1968]

es gibt ganz oben noch mal eine neue version. mir ist gerade aufgefallen das die events des friends of hue taster (d.h. ohne batterie) noch falsch waren. die liefern komplett andere nummern als die dimmer taster und der smart button.


wenn es die nächsten tage keinen einwand gibt würde ich den aktuellen stand erst mal so einchecken.

[knorxi]

Echt super, dass du die Events der neuen API jetzt auswertest.
Ich bin begeistert. Vielen Dank!
Allerdings sind mir noch 32 Dinge aufgefallen.

• Nach einem shutdown restart bleibt die HUEBridge bei mir immer in "EventStream
  connecting". Ein "set HUEBridge reconnect" bringt sie dann in "connected".
  Im Log steht:
  HUEBridge: http request failed: https://192.168.178.52/auth/v1: Can't connect(2) to https://192.168.178.52:443:  SSL connect attempt failed
  HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: Can't connect(2) to https://192.168.178.52:443:  SSL connect attempt failed
  
• Die Temperatur vom Bewegungssensor wird um Faktor 100 zu klein dargestellt (z.B. 0.195 statt 19.5), da sie ja in HUEDevice.pm mit dem Faktor 0.01 multipliziert wird.
• Ich habe eine Szene mit vielen Lampen.
  Wenn ich diese aufrufe, dann wird ein langer Eventstream mit mehr als 4096 Bytes erzeugt.
  Ich bekomme dann den Fehler: "HUEBridge: invalid json detected: .... "
  Ich habe mir mal die Länge von $data ausgeben lassen, wenn das passiert.
  Die Länge ist dann immer 4096 und $data ist abgeschnitten.
  Probehalber habe ich das abgeschnittene $data zwischengespeichert und beim nächsten $data vorne angefügt.
  Das funktioniert
  Vielleicht kannst du ja noch so etwas ähnliches einbauen.
  Warum aber nur maximal 4096 Bytes beim Callback ankommen, weiß ich nicht 
  

[justme1968]

1. welche version verwendest du? in der version von heute sollte das eigentlich behoben sein.

2. ist seit ein paar tagen schon behoben

3. schaue ich mir an.

[knorxi]

zu 1.: Mit der Version von heute geht's bei mir auch nicht. Vielleicht liegt's ja an meiner Konfiguration, da ein reconnect später sofort funktioniert
zu 2.: Sorry, habe ich erst heute gemerkt.
zu 3.: Super, danke.

Mir ist noch aufgefallen, dass ich im Log so etwas bekomme:
2022.01.17 17:44:22 1: PERL WARNING: Argument "22Z" isn't numeric in addition (+) at ./FHEM/99_Utils.pm line 117.

Liegt vermutlich am "Z" in der "creationtime":  [{"creationtime":"2022-01-17T16:44:22Z", ...

[justme1968]

1. bitte schau mal ob es beim starten http fehler von der bridge gibt wenn der eventstream nicht connected

3. ich habe ganz oben eine gepatchte HttpUtils.pm angehängt. damit werden die zerstückelten langen events korrekt zusammengebaut.

ich denke das rudi die änderung demnächst übernimmt: https://forum.fhem.de/index.php/topic,122066.msg1201344.html#msg1201344

4. 30_HUEBridge.pm ist ebenfalls neu, der zeit fehler sollte auch behoben sein.

[justme1968]

ok... letztes update für heute.

version und beschreibung ganz oben.

[justme1968]

was mir gerade noch einfällt: ich habe den verdacht das das verbinden der events dann nicht funktioniert wenn die bridge überlastet ist. z.b. durch zu viele status abfragen. das könnte z.b. sein wenn beim starten von fhem alle sensoren auf einmal pollen. wenn man die events verwenden sollte das pollen der einzelnen devices eigentlich komplett unnötig sein. geht das verbinden dann beim starten besser?

[rabehd]

Ich habe gestern Abend das Modul mit dieser Version ersetzt.
Jetzt habe ich zusätzlich Sensoren, die ich nicht kenne und wohl auch nicht habe.

    
HUESensor1
manufacturername Signify Netherlands B.V.
modelid PHDL00
name Daylight   

und eine Anzahl von "Rocker support"
(Beispiel)
Name HUESensor161
manufacturername Philips
modelid HUELABSENUM
name Rocker support
type CLIPGenericStatus

Was ist das?

[justme1968]

natürlich 'hast' du die. sonst würden sie ja nicht angelegt.

Daylight ist ein virtueller sensor in jeder bridge der für tageszeit abhängige dinge verwendet werden kann

die anderen sind irgendwelche hilfskonstruktionen die angelegt werden wenn du mit der app die tasten der diversen schalter konfigurierst.

ich weiß noch nicht genau ob und wie ich die unwichtigen automatisch ignorieren kann.

der knackpunkt ist: wenn ich geräte weg lasse und später ein event dafür kommt wird im log eine warnung angezeigt. ich könnte mir zwar im prinzip merken was ich weg gelassen habe, am besten merken könnte ich es jeweils in einem fhem device alles andere wäre deutlich aufwändiger. aber die devices wurden ja absichtlich nicht angelegt. und schon beisst sich die katze in den schwanz.

das einfachste ist du ignoriert die zusätzlichen devices einfach erst mal.

[rabehd]

das einfachste ist du ignoriert die zusätzlichen devices einfach erst mal.

Das tue ich auch, sind schon in einem separatem Raum.
Eine Zuordnung zur Realität wäre angenehm, aber ich kann die ganzen Sensoren namens "Rocker support" sind mir ein Rätsel. Ich vermisse nichts, deshalb ist ignorieren auch ok.

[knorxi]

Habe die 3 neuen Dateien seit gestern Abend im Betrieb.
Lange Eventstreams gehen jetzt und der Zeitfehler ist auch behoben. Super, Danke.
Zum Problem, dass der Eventstream auf "connecting" bleibt:
Wie verhindere ich das Pollen? Habe jetzt "pollDevices" auf 0 gesetzt. Ist da richtig?
Dann bleibt der Eventstream aber immer noch auf "connecting".
Ich habe versuchsweise mal alle defines mit HUE ans Ende der fhem.cfg verschoben.
Dann wird im Log etwas anderes eingetragen.
Vorher:
2022.01.18 09:10:15 1: 1
2022.01.18 09:10:15 2: HUEBridge: http request failed: https://192.168.178.52/auth/v1: Can't connect(2) to https://192.168.178.52:443:  SSL connect attempt failed
2022.01.18 09:10:15 1: 2 type:>application id< lastID:><
2022.01.18 09:10:20 1: 1
2022.01.18 09:10:20 2: HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: Can't connect(2) to https://192.168.178.52:443:  SSL connect attempt failed
2022.01.18 09:10:20 1: 2 type:>event< lastID:><

Nachher:
2022.01.18 09:50:02 1: 1
2022.01.18 09:50:02 2: HUEBridge: http request failed: https://192.168.178.52/auth/v1: empty answer received
2022.01.18 09:50:02 1: 2 type:>application id< lastID:><
2022.01.18 09:50:02 1: 1
2022.01.18 09:50:02 2: HUEBridge: http request failed: https://192.168.178.52/eventstream/clip/v2: empty answer received
2022.01.18 09:50:02 1: 2 type:>event< lastID:><

Andere http-Fehler bekomme ich nicht.

[justme1968]

pollDevices sollte auf 1 oder 2 stehen und alle intervalle aus den sensor definitionen müssen raus.

das bridge device sollte vor allen anderen hue devices in der config stehen.

auf welcher hardware läuft dein fhem? wie viele lampen und taster hat du an deiner hue bridge?