Open nerdyninny opened 2 months ago
Hey there @dmulcahey, @adminiuga, @puddly, @thejulianjes, mind taking a look at this issue as it has been labeled with an integration (zha
) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)
zha documentation zha source (message by IssueLinks)
What are the model names of the affected Hue lights?
What are the model names of the affected Hue lights?
Philips Hue (HA name: Hue Kitchen Counter Corner Lamp): IEEE: 00:17:88:01:00:1d:a7:eb, Nwk: 0x5249, LLC011 by Signify Netherlands B.V. | Firmware: 0x43005d0b
Philips Hue (HA name: Hue Kitchen Counter Strip Light): IEEE: 00:17:88:01:00:cc:0c:13, Nwk: 0x4256, LST001 by Signify Netherlands B.V. | Firmware: 0x43005d0b
Update: I just moved my coordinator to a central part of my home (1st floor, instead of basement). I have a lot of routers/repeaters (mains) already on the network (27 Hue Bulbs, 2 Hue Strips Lights, 1 Hue Bloom Lamp, 1 Tuya Air Monitoring Sensor, 17 ThirdReality Outlets). 13 ThirdReality Outlets were already present before I migrated the Hue devices, but I added another 4 afterwards to see if it would improve anything. Anyway, after moving my coordinator, I still have several Hue devices that intermittently work when controlled directly (EmberStatus.DELIVERY_FAILED: 102), but work very fast/consistently when I use the Zigbee group they happen to be part of. I've also noticed the same 'delivery failed' issue on some of my ThirdReality outlets as well, but I haven't bothered to add them to a Zigbee group.
How many devices total are on the network? Source routing could possibly help if the network is a decent size.
95 total. Source routing is already enabled.
zha: enable_quirks: true custom_quirks_path: /config/zha_quirks/ zigpy_config: source_routing: true ezsp_config: ����� CONFIG_MAX_END_DEVICE_CHILDREN: 0 ����� CONFIG_TX_POWER_MODE: 3 ����� CONFIG_NEIGHBOR_TABLE_SIZE: 16 ����� CONFIG_SOURCE_ROUTE_TABLE_SIZE: 110
—-
https://github.com/home-assistant/core/assets/59848054/27fe7fd6-dfee-4928-aeb5-7e7921eda67c
I figured a video of the issue might help.
Ok, let’s try something. Put Zigpy at debug (can do with the logger set level service) then try to control a couple individual devices that give you trouble. Then get the logs and look at what is logged for the source routes for the bad transactions. Maybe there is a router on the network misbehaving. We can try power cycling and / or pulling the devices with the nwk in the route that is logged.
Also, get rid of CONFIG_TX_POWER_MODE
.
So I went ahead and just removed all the configuration.yaml Zha entries under ezsp_config, and disabled source routing for now.
Moving the coordinator made somewhat of a positive difference in terms of the total number of unresponsive Hue lights.
I haven’t done the Zigpy debug, mostly because I don’t know how and finger crossing things will stabilize.
I do have a question though:
Why are the lights unresponsive via the GUI as a Device, but consistently responsive when the same Device (or even Devices, plural) is added to a Zigbee Group? I get that a single command can be sent to a set of Zigbee grouped lights, which decreases network traffic, but even when I power on a single bulb (one command), it is also unresponsive? And even in the case of source routing enabled, wouldn’t the path be the same regardless?
So I went ahead and just removed all the configuration.yaml Zha entries under ezsp_config, and disabled source routing for now.
Moving the coordinator made somewhat of a positive difference in terms of the total number of unresponsive Hue lights.
I haven’t done the Zigpy debug, mostly because I don’t know how and finger crossing things will stabilize.
I do have a question though:
Why are the lights unresponsive via the GUI as a Device, but consistently responsive when the same Device (or even Devices, plural) is added to a Zigbee Group? I get that a single command can be sent to a set of Zigbee grouped lights, which decreases network traffic, but even when I power on a single bulb (one command), it is also unresponsive? And even in the case of source routing enabled, wouldn’t the path be the same regardless?
No
Source-Routed Packets:
Broadcasts:
Group addressing: in Zigbee is a method used to efficiently manage communication among multiple devices within a Zigbee network. It allows a single message to be sent to multiple devices that are configured to listen to the same group address. This is particularly useful in home automation and IoT applications where multiple devices, like lights or sensors, need to receive the same command simultaneously. Here's how it works in detail:
So the TL;DR they are very different. Group messaging is technically multicast (a broadcast that only some devices will act on) essentially spray and pray… where as source routing is a message sent along a pre determined path to a particular device. This is why I wanted you to enable debug so we could see what devices were in the path to determine if maybe a particular device is swallowing messages or if your routes aren’t updating for some reason.
I can confirm I might be observing the same issue. I have few Philips Hue lights. After the 2024.4 update I started noticing one of my Hue lights - a light strip - started misbehaving, becoming non-responsive time to time. I have it as a part of a scene and when the automation fires this light does not turn on sometimes, other times it fires without any issue. There hasn't been any issues before the update, it was working quite reliably. Other of my Hue lights seems to be working well though so I am not sure why only this one misbehave. When trying to fix the light using reconfiguration, it very often fails. I did a factory restart of it once. Also this should not be a signal issue as the device is few meters from the HUB and there are multiple other routers in the room
My Zigbee network seems have mostly stabilized, except for one Hue Spotlight Color bulb.
I can control it consistently only via a Zigbee Group (it’s in a room group with 3 total). If I change the problem bulb’s color, or on/off, I get the following error:
Failed to call service light/turn_on. Failed to send request: Failed to deliver message: «EmberStatus.DELIVERY_FAILED: 102>
Kinda wonky and I don’t understand why a Zigbee group command works on it, but not a direct command by itself. It’s sporadic too as I’ve reset the bulb several times now. It’ll work for a day, or a few days, and then stop working (except when in a zigbee group).
Bulb stats: LCT002 by Signify Netherlands B.V. Firmware: 0x43006502
Device Type: Router LQI: 140 RSSI: -65 Last seen: 2024-05-28T21:58:25
The LLC011 is apparently TI/CC2530-based and is known to cause issues (especially with source routing) on anything but very old firmware. You might want to remove these devices from your network for now if you experience stability issues. The Hue firmware development team is informed of the issue.
Related thread:
especially with source routing
Does going back to broadcast routing (instead of source routing) fix it?
I read the thread you hyperlinked to. I downloaded the oldest OTA firmware, but can’t seem to downgrade and looking at the debug logs it’s saying I have the latest firmware already. Any tips on how to downgrade using Zha?
The problem
ZHA - Individual Lights Unresponsive/Inconsistent, except within a Zigbee Group
I recently started having a lot of unresponsive/inconsistent Philips Hue lights. It all started when I migrated off the Philips Hue bridge and added around 25 devices (mostly Bulbs) to ZHA. I have a total of 95 nodes currently.
Something I noticed is that when the same unresponsive/inconsistent Philips Hue lights are controlled via a Zigbee group, they work very fast and snappy. But when I control them individually, that's when I see error messages like this one (see screenshot):
Failed to call service light/turn_off. Failed to send request: Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102<
Things I've tried:
What version of Home Assistant Core has the issue?
core-2024.4.3
What was the last working version of Home Assistant Core?
Unsure
What type of installation are you running?
Home Assistant OS
Integration causing the issue
ZHA
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
Diagnostics information
home-assistant_zha_2024-04-24T12-53-22.693Z.log
Debug during on/off failures of individual Hue lights, and on/off success when Group containing same lights on/off is sent.
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
Diagnostic Logs config_entry-zha-65910acf658adfe741b482ea10beeb3f.json