Repository navigation
Error: Request failed with status code 503 #295
Description
Activity
Have rolled back to 3.0.0 and normal behaviour has been restored, so I wonder what specific action added into 4.0.0 is effecting it.
@Brewj with 4.1.0 so called "workers" have been added, so prevent hitting the limit of the hue API.
Updating to 4.1.0 should fix your issue.
But make sure to go into the bridge config and set the amount of workers!I have similar problems, tried several things, including update to 4.1.0 as mentioned above.
Finally I rolled back to my working setup with node-red version 10.3.0 and huemagic 3.0.0.
Hopefully a solution will come soon.Same issue here. Upgrade to 4.1.0 is a disappointment, everything worked ok before. Commands are not queued and executed correctly. Hope an update can fix this issue.
Same issue here. Upgrade to 4.1.0 is a disappointment, everything worked ok before. Commands are not queued and executed correctly. Hope an update can fix this issue.
In the end I moved all my functionality to using home assistant nodes. No issues yet. But not sure if that would work for you...
I would considor that. If no solution happens soon.
Same here, although iirc via Home Assistant it was trickier to do blinking (alert), that's why I moved to Huemagic.
I have similar problems, tried several things, including update to 4.1.0 as mentioned above. Finally I rolled back to my working setup with node-red version 10.3.0 and huemagic 3.0.0. Hopefully a solution will come soon.
Same here - can you tell me how to rollback?
I run samba backup every night. Rolling back was restoring a backup.
Reacted by MarcAroni81for me its not working with 4.1 either. Any suggestions what the best amount of workers should be?
I have tested with 4 to 7, same problem. Something wrong in the logic. Have to set delay for even get it to work. Hope a solution comes soon.
I'm having this issue as well. Have reduced workers to <10.
Thanks Foddy for all your work.
I have similar problems, tried several things, including update to 4.1.0 as mentioned above. Finally I rolled back to my working setup with node-red version 10.3.0 and huemagic 3.0.0. Hopefully a solution will come soon.
Same here - can you tell me how to rollback?
from the command line on my pi I just ran the following, you can specify which ever version you desire. Then stop, restart Node Red.
npm install node-red-contrib-huemagic@3.0.03 remaining items
There is a general limit on how many tasks you can perform on the HUE clip API v2
This is the official documentation from HUE developers.Knowing this, it isn't really a problem with the HueMagic Contrib.
Edit: "grouped_lights" means that these are several lights in containers like groups/rooms/zones
If you exceed the limit you'll be always getting the 503 error.
It "might" be triggered... or not ;)Edit2: if you deploy full/flows that contain light / group nodes it is obvious that the error occurs. I'd recommend to deploy always changed nodes
Having "node-red-contrib-philipshue-events" in your flows, that works perfectly with api v2 (it reads all data from the bridge and need to switched for desired commands) in combination HueMagic works pretty zero issues for me at the moment. I had similar problems. You might give it a try. It use it for all events that normally come out of grouped-lights and lights.
I'm also getting a lot of 503's since the update to 4.1.0, unfortunately I'm running it in docker and I cannot seem to roll back to 3.0.0 easily.. but it messed up 30% of my flows, which were working fine on 3.0.0
Thanks for the quick response. I’ll need to do some modifications and create some extra scenes to get my previous setup working in this new way.
I have this same issue and it is indeed related to having at least one 'HUE Group node' in a flow which also triggers other 'single light point' HUE nodes.
Solution I found to workaround this issue :
- either replace your group node by multiple light nodes (this is actually what the HUE bridge itself does when receiving a group command, it will split it and send multiple commands). But this quickly gets quite blurry in flows when having many lights per group :-(
- either set number of workers to 1
Technically, I guess it would require the HueMagic engine to handle workers differently : as soon as a group request is processed, it must always wait at least 1 second before sending next command, regardless of the number of workers set... (?)
I have this same issue and it is indeed related to having at least one 'HUE Group node' in a flow which also triggers other 'single light point' HUE nodes.
Solution I found to workaround this issue :
- either replace your group node by multiple light nodes (this is actually what the HUE bridge itself does when receiving a group command, it will split it and send multiple commands). But this quickly gets quite blurry in flows when having many lights per group :-(
- either set number of workers to 1
Technically, I guess it would require the HueMagic engine to handle workers differently : as soon as a group request is processed, it must always wait at least 1 second before sending next command, regardless of the number of workers set... (?)
What I did, I created "zones" in the Hue app for the light groups I used to address individually (which worked in the pre 4.1 version). so before I had 2 situations where a different set of lights needed to turn on which I all addressed individually, now I had to create 2 groups/zones (which might somewhere be more efficient I guess) containing these lights to achieve the same. but then it does work.
Guys, if you want to get the Bridge Response ultimately quick and without errors use the "node-red-contrib-philipshue-events"
It reads the API V2 properly and you get an unreal amount of status updates from the bridge, like 10 in one second, when you trigger a scene with 10 lights.
The output of this node can be switched to the flows where the status updates are needed. On the other hand, don't trigger multiple lights, use scenes. (It's still fine to trigger a single light, but avoid multiple at once)
When both things are done you get zero issue hue running in node red. HueMagic for the scenes, for sensors, buttons.
The other contrib for responses. I have the worker on 5.If scenes are not working correctly at the moment for you, look for my posted Issue, I found a solution. There is just one command wrong in the file. You can change it by yourself.
On the other hand, don't trigger multiple lights, use scenes. (It's still fine to trigger a single light, but avoid multiple at once)
For me (and many others) it's not possible to do that since the command to the light depends on the input (brightness, color, light temperature etc.) Also this is working perfectly fine with a version <4, so it is most certainly a bug. I hope it gets some focus since this makes it impossible for me and others to upgrade. Thanks!
@johnekarlsson i strongly recommend to use scenes to turn lamps / groups on and off. It's fine to turn of lamps individually.
Even using API v2 https request, for me it isn't possible to send more than 2 (maybe 3) http request at once, what seems to be a node red problem. The developer information published says following:
""We can’t send commands to the lights too fast. If you stick to around 10 commands per second to the /light resource as maximum you should be fine. For /grouped_light commands you should keep to a maximum of 1 per second. The REST API should not be used to send a continuous stream of fast light updates for an extended period of time, for that use case you should use the dedicated Hue Entertainment Streaming API.""
I using https request now for 2-3 weeks and had never a problem
- added 2 commits that reference this issue
on Aug 16, 2026 @Brewj and everyone else in this thread – sorry for the really long silence on this one, it stayed open way longer than it should have :S
This was HueMagic simply talking too fast. The bridge accepts roughly 10 light commands and only about 1 group command per second, and HueMagic happily fired everything at once – so the bridge answered with 429 or 503 and the commands were lost. The usual workaround was turning the worker setting down to 1, which of course made everything slow.
Commands are now paced to what the bridge actually accepts, so you can leave the worker setting alone.
Fixed in v5.0.0 – the release is on npm 🙂
Excellent thank you
Reacted by Foddy
Describe the bug
Since upgrading NodeRed and the HueMagig node I'm getting the following error: Request failed with status code 503 for about half of my lights when deploying / restarting the flow or NodeRed. "Executing Command" displays under the fixture node not the status.
Toggling the fixture on and off from the NR Dashboard or the Hue app restores the functionality but the "Executing Command" frequently returns.
Flow to Reproduce
Expected behaviour
Nodes should connect as previously.
Screenshots
Please complete the following information: