Connectivity issues with new Clip v2 API

[hurenkam]

With the update to a more recent node-red (2.1.4) and node-red-contrib-hue-magic (4.0.4), I've started to get connectivity problems when i deploy my whole setup. I have now disabled some of my flows, and run reduced functionality (3 tabs => 3 rooms). When i enable more, I will typically run into 'request failed with status code 503' errors connecting to the bridge. Thinking the bridge might be throttling the functionality, decided to add multiple bridge entries for the same bridge (with different app keys), however that does not seem to fix the issue for me. In the earlier pre-Clip2 version, i had the possibility to reduce the polling frequency to avoid overloading the bridge interface, are there any tweaks i can use to reduce traffic to/from the bridge?

[spudje]

I have the exact same problem. Triggering more than 2 lights in parallel in Node Red, results in only 2 of them working and all the rest erroring with 'request failed with status code 503'. Hope a fix is available very soon. This breaks quite a lot of automations.

[MrMiracles]

Same, fixed it for now with a 250ms delay.

[Foddy]

I implemented a worker queue in HueMagic in the latest version. From now on, the commands to the bridge will be executed in a throttled manner, whereby the value of the parallel commands can be set in the bridge configuration.

Can you guys try it again with this update? It might be better if you set a value below 10 in the configuration if the errors are still appearing. Let me know if this fixed your issue.

[spudje]

Thanks for your quick efforts to fix! Unfortunately it didn't fix it. I have set worker to 8, but still only 2 lights can be controlled { "alert": 5, "color": "blue"}, the others (2) still show the "input error" and won't blink. "Error: Request failed with status code 503"

[Foddy]

What happens if you set the worker value to 1? Do you still face this issues?

[Foddy]

According to the Philips Hue documentation the bridge can execute different commands at different speeds. You can for example only execute 1 group or 10 light commands per second without hitting the implemented buffer. If you want play an alert effect (which needs more resources on the bridge) I would generally suggest you to put all these lights inside a group (maybe called “Alert”) and execute your alert command on the group. This will perform much better and hopefully without any API limitation errors.

[spudje]

Mmm, that is something to consider. However, something tells me I had it that way in the past (but maybe not with huemagic) and I moved away from it because lights weren't blinking in synchronisation.

[MrMiracles]

Will try it tomorrow evening!

[MrMiracles]

Seems to work if I set the worker to 1. Great job fixing it so fast! I was already executing my command on groups by the way...

[hurenkam]

Things have definately improved with this new release, but with workers set to 10, i still see a 503 at the end of my 'deploy'. With workers set to 1, i don't see any 503 errors anymore.

What i do notice now is the following message twice for every one of the 9 groups that i use. This i did not see before, and could be related to changes made in the new release: "The group in not yet available. Please wait until HueMagic has established a connection with the bridge or check whether the resource ID in the configuration is valid.." Is this an error, or is it just a warning? Not sure how exactly i can see when the bridge connection is ready, do i need to add a startup delay somewhere now?

Functionally everything seems to work as expected (at first glance, i did not test very extensively yet).

Update: It seems that feedback from groups, as well as group commands (on/off/brightness) does not work for affected groups. See also issue #178 which seems to be closed with release 4.2.2, but even after updating to that release (and restarting node-red), i am still experiencing this problem.

[spudje]

Blinking a group is also a no go. Apparently the group node has a bug too. They don't return to the previous state after the blinking but simply turn off :(

So I guess the worker issue needs fixing so we can address more than 2 lights in parallel.

[Schmetterfliege]

I had 4.0.5 installed until a few minutes ago, and wanted to play with the "alarm" effect. Triggering it once, was fine. Twice, fine too. But while testing my flow, it got worse and worse, and I ended up in a restart loop of my node red server. I didn't see any 503 errors in the debug tab (debug nodes were enabled), but like 2 seconds after NR was restarted, it crashed again due to this issue:

To fix this, I had to delete all huemagic nodes I had. No clue what exactly I did wrong to trigger this. I now updated to 4.1.0, set workers to 10 and the alarm function works fine now (did just a quick test). E.g. if I set it to 1 second, it shows it for 1 second only. Before I had the infinite crash loop, setting the seconds had no effect. Sometimes it would show the alarm effect for up to 10 seconds before stopping, even if I set it to e.g. 2. So I'll assume I messed with the buffer? Anyways, once the alarm is finished, the lights stay off - as reported in #294