Open Brewj opened 2 years ago
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.
I'm also facing similar issues. After upgrading to 4.1.0, I've configured 7 workers. However, several commands are not executed, while this was not a problem before...
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...
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.
for 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.0
Same here. Reducing workers to 1 solved the issue for me.
@neptrio That worked for me thanks, but now I have a delay when operating more than one light with an event. So this is only a temporary fix until it is fixed in hue magic itself.
Confirmed, 1 worker works, 2 workers does not.
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
@MrTeal try to follow my recommendation and set the worker in the config to 5. Don't trigger multiple lights, trigger scenes instead and you should be fine.
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 :
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
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![Screenshot 2022-01-21 at 19 53 25](https://user-images.githubusercontent.com/5247403/150593211-86e558a6-6eb5-47a5-83fa-8383df3ebadf.png)
Please complete the following information: