"HUEBridge_Call: failed" mit neuester Firmware 1712201209?

[we5]

Hallo,

hatte eben ein Software-Update (1712201209) der Bridge angestossen, weil ich sowieso dabei war, neue Lampen ins System einzubinden, leider schmeisst das Modul HUEBridge seit dem die folgenden Fehler (Verbose is schon auf 5):

Code: [Auswählen]

2017.12.22 17:08:14 4 : using HUEBridge_HTTP_Request: GET groups
2017.12.22 17:08:14 3 : HUEBridge_Call: failed, retrying
2017.12.22 17:08:14 4 : using HUEBridge_HTTP_Request: GET groups
2017.12.22 17:08:14 3 : HUEBridge_Call: failed, retrying
2017.12.22 17:08:14 3 : HUEBridge_Call: failed

... es scheint wohl eine Beta-Firmware zu sein, denn ich habe gerade die Mail vom Hue Beta Team bekommen. Also falls noch jemand an diesem Programm teilnimmt, sollte es derzeit nicht installieren

[we5]

Ok, nach etwas rumprobieren hab ich rausgefunden, dass ich das Attribut "noshutdown" explizit auf 1 setzen muss 😂

[we5]

Offensichtlich hat sich das doch nicht gelöst. Bei mir kommen regelmässig Fehler und ganze LightScenes werden nicht geschaltet.
Auch einzelne Request auf Lampen funktionieren nicht oder nur teilweise. Ein Verbose auf 5 zeigt auch nicht mehr als "failed".

Habe schon alle möglichen Kombinationen aus "noshutdown", "pollDevices" und "queryAfterSet" probiert. Mir scheint, die Änderungen, die Philips da in der Bridge ausgerollt haben (oder besser testen, da Beta) haben auch etwas mit Throttling/Rejecten zu tun.

Die Response der Bridge sieht gut aus und wenn ich das selbst probiere, bekomme ich auch immer eine Antwort mit validem JSON.

[we5]

So, um das mal bisschen abzuschließen (ist ja auch ein Monolog hier).

Es kamen hier mehrere Dinge zusammen. Zum einen ist die Bridge in der Firmware wohl etwas "rigoroser" für zuviel Requests/Minute. Da ich im Dezember einige neue Lampen hinzugefügt habe und mehrere LightScenes nun unter Umständen >20+ Lampen schaltet, rejected das die Bridge. Geholfen hat zB. das Attribut async_delay mal auf 0.1 zu stellen.

Am schönsten wäre es natürlich, wenn das Bridge-Modul das Throttling/Queueing direkt übernimmt.

[justme1968]

wenn man LightScene über save verwendet werden normalerweise hue gruppen und szenen verwenden und das 10 kommandos/sekunde limit der bridge sollte keinen einfluss haben.

wie hast du die einzelnen szenen in der LigtScene angelegt?

das throttling im modul zu machen war bis jetzt noch nicht nötig. ich schaue mal wie gut das geht. das modul bekommt ja z.b. nicht mit wenn auch noch von extern geschaltet wird.

[we5]

wenn man LightScene über save verwendet werden normalerweise hue gruppen und szenen verwenden und das 10 kommandos/sekunde limit der bridge sollte keinen einfluss haben.

wie hast du die einzelnen szenen in der LigtScene angelegt?

das throttling im modul zu machen war bis jetzt noch nicht nötig. ich schaue mal wie gut das geht. das modul bekommt ja z.b. nicht mit wenn auch noch von extern geschaltet wird.

Nun ich hab die Lampen direkt per Namen im define/defmod. Anders habe ich das auch nie gemacht (gewusst). Ab und an benutze ich dann "save" wenn ich einen Zustand zB der EG-Lampen geändert habe (per HomeKit) und dies dann auch in FHEM persistieren möchte. Aber dann speichert er ja nur den aktuellen Zustand der für die LightScene definierten Lampen.

Ich wollte auch ungern die Szenen aus der Bridge nehmen, die finde ich nämlich umständlich und die LightScene steuert ja für manche Szenen auch eventuell noch per ZWave-Steckdosen geschaltete Lampen (Weihnachtsbaum etwa, oder Lichterketten im Innen- und Aussenbereich).

Grob gesagt habe ich mindestens pro Stockwerk und dann für den Aussenbereich eine LightScene. Im EG alleine sind es jetzt >10 und dann fing es auch an mit den Problemen. Manchmal wurden nur ein paar Lampen geschaltet, manchmal gar keine. Ging leider zeitlich auch einher mit dem Beta-Bridge-Firmware-Update. Ich wusste gar nicht, dass ich noch in dem Programm bin und die Aktualisierung lief nachts automatisch ... früher waren alle Lampen in einer LightScene-Config, aber das wurde zu unübersichtlich. Da ich dann angefangen habe, die Lampen pro Stockwerk aufzuteilen, habe ich natürlich in manchen Events mehrere LightScenes gleichzeitig geschaltet. Wenn dann über mehrere LightScenes hinweg direkt hintereinander die ~30 Lampen geschaltet werden, hat es gekracht. Nun hab ich angefangen überall ein "async_delay" mit 0.1 einzustellen und eine Master LightScene erstellt, die dann bestimmte Szenen quasi verteilt (also statt Lampen die Stockwerk-LightScenes als Objekte hat), und dort ebenfalls einen "async_delay" mit 1 Sekunde konfiguriert. So zumindest habe ich aktuell keine Probleme mehr, ist aber halt auch nur eine Behelfslösung.

Vielleicht mache ich aber auch was grob fahrlässig falsch

[justme1968]

du muss die szenen der bridge nicht verwenden.

wenn du die lampen in hue gruppen zusammen fasst und diese statt der einzelnen lampen in der LightScene verwendest wird beim save der status automatisch in einer hue szene gespeichert. alle anderen device typen der gleichen szene werden wie immer behandelt. beim aufrufen einer szene wird dann statt die hue lampen einzeln anzusprechen die szene der bridge abgerufen und die anderen device typen wie sonst auch direkt angesteuert. es geht also alles automatisch aber es reduziert die last der bridge und die anzahl der funk kommandos.

die szenen sind der 'offiziell' weg von phillips um das 10 kommandos pro sekunde limit zu umgehen. wobei es leider nicht ganz so einfach ist weil die anzahl der lampen immer noch eine rolle spielt und ausserdem phillips die kommandos wirklich einzeln zählt. also z.b. on + helligkeit + farbe sind schon 3-4 kommandos. weil fhem immer ein on sendet sich wenn die lampen schon an sind zählt das immer mit. das on weg zu lassen funktioniert aber nicht zuverlässig da fhem nicht unbedingt weiss ob die Lampe wirklich an ist.

alternativ der weg über async delay. das ist schon richtig so. so lange es dich nicht stört das nicht alle Lampen gleichzeitig schalten. dann bleiben nur die szenen.

[cejot]

Guten Abend zusammen,

habe am Freitag (aus der Ferne) über die HueApp das BridgeUpdate gemacht, weil ich was über den Fernzugriff der App steuren wollte. Heute komme ich wieder nach Hause aber FHEM reagiert kaum noch und protokolliert munter

2018.02.12 21:30:47 3: HUEBridge_Detect: 192.168.178.30
2018.02.12 21:30:47 3: HUEBridge_Call: failed
2018.02.12 21:30:47 1: HUEBridge_HTTP_Request http://192.168.178.30/api/ZacE9FdXXXXXXX0ZUrM6HJojEL5-Lho6Jb/sensors/23: Can't connect to http://192.168.178.30:80
2018.02.12 21:30:47 3: HUEBridge_Call: failed, retrying
2018.02.12 21:30:47 3: HUEBridge_Detect
2018.02.12 21:30:47 3: HUEBridge_Detect: 192.168.178.30
2018.02.12 21:30:47 1: HUEBridge_HTTP_Request http://192.168.178.30/api/ZacE9FdXXXXXXX9d9r0ZUrM6HJojEL5-Lho6Jb/sensors/23: Can't connect to http://192.168.178.30:80

[...]
mit verbose=5:

2018.02.12 21:55:08 3: HUEBridge_Detect: 192.168.178.30
2018.02.12 21:55:08 4: using HUEBridge_HTTP_Request: GET sensors/15
2018.02.12 21:55:08 3: HUEBridge_Call: failed, retrying
2018.02.12 21:55:08 3: HUEBridge_Detect
2018.02.12 21:55:08 3: HUEBridge_Detect: 192.168.178.30
2018.02.12 21:55:08 3: HUEBridge_Call: failed

Meine Firmware der Bridge (v2) ist jetzt die 1801260942 (ausgeliefert am Feb 5, 2018). Fands  gut, dass jetzt ZigBee v3 unterstützt wird, aber so im Nachhinein hätte ich wohl besser kein Update gemacht 

Wollte gerade mal noch das Async Attribut testen, aber FHEM reagiert quasi nicht mehr.... werde das wohl vertagen.

Falls jemand weitere Ideen hat - gerne.

[justme1968]

das fhem modul updaten oder noshutdown auf 1 setzen.

die firmware scheint aber noch andere problemen zu haben. schau dir die anderen threads dazu an.

[cejot]

Danke Dir für die schnelle Rückmeldung. Muss mich morgen darum kümmern, muss morgen früh raus :/ Hatte diesen Thread nur gefunden, weil ich versucht hab "meinen" Fehler zu finden. Aber, dass die Firmware weitere Fehler hat klingt nicht besonders vielversprechend - Juhu ;-)

[cejot]

Das Modulupdate hat leider nicht geholfen. Aber nachdem ich noshutdown auf 1 gesetzt hab läufts wieder rund soweit ich das sehe. Vielen Dank nochmal.

[inki]

Hallo zusammen,

ich habe FHEM und auch das Hue Plugin gestern zum ersten Mal aufgesetzt.
Mit der aktuellen Hue Bridge war ich zunächst auch nicht erfolgreich. Im Log stand nur:
    HUEBridge_Call: failed, retrying
    HUEBridge_Call: failed
    HUEBridge_OpenDev: got empty config

Da ja noch keine Userdaten von der Bridge vorlagen hat es nicht genügt, das Attribut noshutdown der Bridge auf 1 zu setzen.
Zusätzlich habe ich ein Attribut disable auf 1 gesetzt und dann nach ein paar Sekunden Wartezeit wieder gelöscht.
Erst dann kam die in der Doku beschriebene Aufforderung zum Drücken des Link-Buttons.

Ich hoffe, dieser Hinweis hilft vielleicht jemandem weiter der an derselben Stelle stecken bleibt...

Ingo

[Jendaw]

ich habe FHEM und auch das Hue Plugin gestern zum ersten Mal aufgesetzt.
Mit der aktuellen Hue Bridge war ich zunächst auch nicht erfolgreich. Im Log stand nur:
    HUEBridge_Call: failed, retrying
    HUEBridge_Call: failed
    HUEBridge_OpenDev: got empty config

Da ja noch keine Userdaten von der Bridge vorlagen hat es nicht genügt, das Attribut noshutdown der Bridge auf 1 zu setzen.
Zusätzlich habe ich ein Attribut disable auf 1 gesetzt und dann nach ein paar Sekunden Wartezeit wieder gelöscht.
Erst dann kam die in der Doku beschriebene Aufforderung zum Drücken des Link-Buttons.

Ich hoffe, dieser Hinweis hilft vielleicht jemandem weiter der an derselben Stelle stecken bleibt...

Auch ich wollte gerade die HUEBridge einrichten, stecke aber, trotz der Ratschläge bzgl noshutdown und disable nach wie vor fest. Die Fehlermeldung ist

Code: [Auswählen]

hueBridge: invalid json detected for http://hue/api/67c9c20eb9e86ae7a48663783d77c986/config: HASH(0x3f84a00)
HUEBridge_Call: failed, retrying
hueBridge: invalid json detected for http://hue/api/67c9c20eb9e86ae7a48663783d77c986/config: HASH(0x3efbb08)
HUEBridge_Call: failed, retrying
HUEBridge_Call: failed
HUEBridge_OpenDev: got empty config

Das JSON, welches unter der URL zurück kommt ist:

Code: [Auswählen]

{"name":"Philips hue","datastoreversion":"71","swversion":"1806051111","apiversion":"1.26.0","mac":"00:17:xx:xx:xx:xx","bridgeid":"001788xxxxxxxxxxx","factorynew":false,"replacesbridgeid":null,"modelid":"BSB002","starterkitid":""}
Hat sich evtl ein Feld geändert?

Gruß J

edit Nach einem Restart aller beteiligten Geräte (FHEM, HueBridge) ging das Pairing mit obiger Vorgehensweise (disbled setzen und anschließend löschen) auch bei mir.