Closed Kane610 closed 1 year ago
951 is ERR_BRIDGE_BUSY, it may occur when sending too fast. Currently 20 tasks are allowed to be queued.
Allright. I will add that to the list of known errors for better prints.
Isn't 20 a bit low?
Isn't 20 a bit low?
For normal use cases it should be fine.
I think when the limit is hit, it's an indication that the client side needs to be checked why so many commands are send in a short time.
The Hue API has a pretty good page describing the matter: https://developers.meethue.com/develop/application-design-guidance/hue-system-performance/
I think when the limit is hit, it's an indication that the client side needs to be checked why so many commands are send in a short time.
I had this Internal error 951 with Home Assistant and an automation to turn off all my lights at the same time. I have 20 Philips HUE lights and 6 HUE motion sensors.
I had similar issues with HomeKit: when recalling a HomeKit scene, it would create a storm of up to 50 requests towards deCONZ (or the Hue bridge). I took several measures in homebridge-hue to address that:
With these, I haven’t seen the need to manage the time between requests.
Alternatively, Don’t try and control each individual light from Home Assistant. Instead expose a group or CLIP sensor and use gateway rules to update the lights.
I will look into adding some retry mechanism should that message appear. This is the first time I got this reported
Combine multiple requests for the same light (on/off, brightness, colour) into a single gateway request.
Is it somehow related to #1357 ? How would you implement that into DeConz API ?
Alternatively, Don’t try and control each individual light from Home Assistant. Instead expose a group or CLIP sensor and use gateway rules to update the lights.
I will try to call groups separately instead of the big group of all lights, which I think is like calling all lights independently.
I will try to call groups separately instead of the big group of all lights, which I think is like calling all lights independently.
It is 👍
For Home assistant I'm adding a retry mechanism triggered by the BridgeBusy error.
Isn't 20 a bit low?
For normal use cases it should be fine.
I think when the limit is hit, it's an indication that the client side needs to be checked why so many commands are send in a short time.
It's not a strange use case at all. If I leave my house, all lights in the house should be turned off at the same instant. I have more than 20 lights, so more than 20 commands are sent simultaneously. I don't want to do special logic to turn them off one by one.
Isn't 20 a bit low?
For normal use cases it should be fine. I think when the limit is hit, it's an indication that the client side needs to be checked why so many commands are send in a short time.
It's not a strange use case at all. If I leave my house, all lights in the house should be turned off at the same instant. I have more than 20 lights, so more than 20 commands are sent simultaneously. I don't want to do special logic to turn them off one by one.
That's why you use groups.
1 group is 1 request.
It's not a strange use case at all. If I leave my house, all lights in the house should be turned off at the same instant. I have more than 20 lights, so more than 20 commands are sent simultaneously. I don't want to do special logic to turn them off one by one.
That's why you use groups.
1 group is 1 request.
Groups add a lot of complexity and are inflexible because you can no longer configure scenes in Home Assistant that set each light separately. They also seem to cause sync issues with HA's internal cache.
Although I realize it's less common, In my case I actually have continuous transitions between multiple scenes depending on e.g. amount of sunlight and time of day so each light changes both brightness and color independently of each other once every second. Groups don't offer that level of control.
I don't see why 100 simultaneous requests would be a problem for a 2.4 ghz network, it's not like the packets are very big either.
Sending 20x the same request to different devices is just utterly inefficient and therefore nonsense. Zigbee groups solve this demand by just sending 1 request as broadcast to all group members simultaneously benefiting from being immune to routing issues. However, while this works beautifully typically for the most basic commands (like on/off, level control), limits are quickly reached in more complex scenarios.
So, perfect fit for a zigbee group is switching all devices off at once. Note, however, that zigbee groups and HA groups are apparently not the same.
@SwoopX but I'm saying it's not the same request. They are different requests because different lamps have different properties and rules. For example, IKEA lights and Hue lights do not have the same range of color temperature, and ambience vs RGB lights behave differently. Some lights don't have color at all. So you can't just send a single command to the entire house. ZigBee supports up to 250 kbps bitrate which means it can send a hundred 300-byte packets per second. But I do hope they have some sort of batching built into the protocol.
@SwoopX but I'm saying it's not the same request. They are different requests because different lamps have different properties and rules. For example, IKEA lights and Hue lights do not have the same range of color temperature, and ambience vs RGB lights behave differently. Some lights don't have color at all. So you can't just send a single command to the entire house. ZigBee supports up to 250 kbps bitrate which means it can send a hundred 300-byte packets per second. But I do hope they have some sort of batching built into the protocol.
Turn off is the same for all devices.
Anyway we are offtopic and this is a very old issue.
Locking this up.
Hi!
A user of home assistant and deconz gets this error:
[pydeconz.utils] HTTP request response: [{'error': {'address': '/groups/5', 'description': 'Internal error, 951', 'type': 901}}]
when sending[pydeconz.utils] Sending {'data': '{"on": false}'} to http://*IP*:*PORT*/api/*API_KEY*/groups/5/action
What does that error actually mean?
Original issue reported here: https://github.com/home-assistant/home-assistant/issues/22852