503 server error when triggering a lot of lights simultaneously

[rvanbaalen]

Running the latest NodeRED with the latest huemagic. Everything up to date.

I have created a scene in NodeRED where I turn off most of the lights (50+) in my house but each time I trigger it, there are a handful of 503 server errors from HueMagic.

I'm guessing that huemagic is throwing all these API requests at the Philips Hue bridge simultaneously and that's where the bridge is tripping and rate limiting the requests.

Expected behavior: all lights queueing up and turning off eventually.

Actual behavior: some lights are skipped resulting in an unwanted scenario.

[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 try 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.

[rvanbaalen]

That's fast! I'm doing some testing right now. Started at 10; that was too high and still showing errors. Now I've set it to 1 and turning on all the lights in my house, triggering the scene (which basically turns everything off), and looking for errors. No errors = up the value with 1 and repeat. I'm currently at 4 without errors. To be continued.

[Foddy]

Interesting, according to the developer documentation of Philips Hue the bridge should be able to execute up to 10 req/s without any problems.

It seems that this value varies depending on the setup and the number of devices?!

[rvanbaalen]

Ok I'm back. I did a lot of testing. Like stated before, the scenario:

• Turn all lights on (50+ hue lights)
• Trigger the Good Night scene (turn off all lights, turn on 2 outdoor lights)

As soon as I set the worker value to a number higher than 2, I start seeing the 503 error (hint to the Philips Hue team; HTTP 429 is normally used for rate limiting errors). When the errors pop up, some lights fail to turn off.

When the worker value is <= 2, I don't get any errors and all lights consistently turn off.

Not sure if it's a good idea but perhaps you could implement a "retry" method where the payload is sent again X times when it failed the first time. But for me, setting the worker value to 2 works perfectly and it's still plenty fast.

@Foddy I made a little donation to your project :-) Love it and really appreciate the fast support!

[Foddy]

Thank you very much for your donation! I am glad that this issue is solved :)

[Foddy]

Not sure if it's a good idea but perhaps you could implement a "retry" method where the payload is sent again X times when it failed the first time. But for me, setting the worker value to 2 works perfectly and it's still plenty fast.

This is a good idea! I will implement this error behavior in the next version! :) I think this might help a lot of people with this specific error.

[whazor]

I think it is probably good to have some sort of 'execution queue', now commands get kinda lost after 503.