Devices become unavailable but come back after restarting Controller (or bulb) #76
Comments
|
Are you running the most recent build of Z-Stack on the device? There were a few lockup bugs with older firmware releases. |
|
HA says "Texas Instruments CC1352/CC2652, Z-Stack 3.30+ (build 20210120)" I believe this is the latest version (at least if you are talking about koenkk firmware builds) |
|
Is it always a specific bulb or is it the entire network? Give the most recent build from the You should take a network backup before upgrading and restore it after upgrading, to ensure your network settings aren't erased. I don't recall the UNIFLASH defaults but it's better to be safe than sorry. If that doesn't fix things, it would be most helpful it you recorded ZHA debug logs for a few days, until the issue appears. |
|
Got it, than you very much for helping so quickly! The problem occurs with multiple lamps of multiple vendors (hue, gledopto, tradfri) and I had some issues with Heimann smoke detectors too (they were changing their NWK when changing their primary router) but that was tackled with your PR #73 . Will report back, thanks again. |
|
During the network backup i got these messages: 2021-07-04 20:03:46.066 server zigpy_znp.znp.security WARNING Ignoring invalid address manager entry: AddrMgrEntry(type=<AddrMgrUserType.Assoc: 1>, nwkAddr=0xFFFE, extAddr=14:ff:fe:ed:71:cb:5d:08) The interesting thing is, that the ieee addresses seem to be "shfted". i have no such ieee address, but i do have 84:2e:14:ff:fe:ed:71:cb Might this be part of the problem? |
|
Yeah, possibly. This is a firmware bug though, not something I can fix in zigpy-znp: #65 Are these devices still on your network? I've only noticed this happening when devices move parents from the coordinator and these are just "stale" entries. |
|
Thanks for the link! If I understand correctly, the cause of this issue is not quite found yet. |
|
The network restore overwrites all of those NVRAM entries but you can do a full erase and then a restore if you want, it shouldn't hurt. Before you do that, if you're comfortable posting it here, could you perform an NVRAM backup? |
|
Puddly is also having one email address in its header but i dont knowing if hi is using it but its mush better then putting network keys on forums but if you is reforming the network its no danger then using on new network key :-)) |
|
I saw the key but my understanding was it is a key that is valid only for the one - unknown - device. Was that incorrect? |
|
I have a NVRAM backup and will send it to you @puddly by email - tomorrow. If anything else is of interest let me know. If this works it might be worth considering making a backup + immediate restore available in the UI as part of some maintenance/troubleshooting process. |
Every APS link key in Z-Stack is computed from the TCLK seed, a device's IEEE address, and a shift of 0-15, making it possible to determine every current and future APS link key for every device (if a device uses APS encryption). The computation is entirely reversible too (for whatever reason), so it's actually enough to leak one key and one IEEE address (which isn't really private) or two keys to compute the internal seed. Now, whether or not that means anything is another matter, since doing anything with this information requires someone to physically stand outside your house to determine the IEEE addresses of the Zigbee 3.0 devices on your network potentially using APS link keys. If your threat model includes an attacker standing outside your home, they're in sniffing range and could have picked all these keys up anyways if you didn't join your devices with Zigbee 3.0 install codes.
It's some sort of bug with Z-Stack. I've never personally had this glitch impact any of my Z-Stack networks using the same hardware as you so it'd probably be better to put in the effort to identify what can trigger this bug instead of making the backup/restore hack (if it works) more user-friendly. |
|
Ok if lights randomly turn on and off while someone is standing outside my house I will consider forming a new network. But seriously, thanks for the clarification. Always interesting to learn how things work. And next time I read "seed" I will hopefully be aware of it's significance. I totally agree that it would be best to identify the underlying root cause and making it more user friendly may also not be the right way to go. But if this actually works it might be worth mentioning it in FAQ/Troubleshooting/Docs. This has been haunting me for months now 🤪 |
|
By the way, I have successfully reset NVRAM and restored the network backup. Everything seems to have come back up as if nothing ever changed - beautiful. I will send you the NVRAM bin tomorrow, I cannot SCP it with my phone and I am "trying to fall asleep" |
|
So, over night I lost 4 Aqara Window Sensors - but no lights. I am having difficultys pairing them again, though. Will try to find out what's going on. |
|
Just checking in: Nevertheless, since then everything seems to be working fine! |
|
The "joining devices thru this" is working great but some end devices is not liking some routers. |
That no news. Google for "aqara dropping off the network" and aqara compatible routers. |
|
It was to me, I hadn't lost a window sensor in months. Today over night HA did not show anything as unavailable, but an other window sensor was not updating. I "fixed" it by pressing the reset button shortly which I believe makes it choose another parent. I have not noticed anything malfunctioning. But I do have one Remote Control (An IKEA 5 Button remote) where it says the power sensor is unavailable. Is this to be expected? The remote seems to be working fine. |
|
For IKEA remotes do one "reconfigure" from the device card and waking the remote up then sending the commands. IKEA remotes is working OK but is lazy reporting if not fixing the reporting that is not being OK after pairing or making one new binding so its best reconfigure them also if doing on new binding to one group. |
|
Well this week has passed pretty quickly. I have had no mentionable problems with my ZigBee devices! This is absolutely genius. Thanks for your help and thanks for all the work you put into this, greatly appreciated! Would you be willing to accept a PR with a doc update mentioning the possibility of making a backup and restoring for troubleshooting? |
|
That's good to hear! Maybe the corrupted NVRAM entries are negatively affecting Z-Stack somehow, as I do recall seeing the coordinator broadcasting the
Sure, thank you. |
I am using ZHA in Home Assistant and "quite frequently" (every few days) have bulbs that seem to be unresponsive. They show up as unavailable in HA and do not seem to respond to any Cluster Commands.
I always thought it's the bulbs fault and simply restarted the bulb by power cycling it.
But I noticed that often it also works to restart the controller (I am using a Lauch XL Cc1352-P; I believe).
This makes me believe that the issue could actually be fixed in Ziggy.
Any help on how I can approach fixing this is appreciated.
The text was updated successfully, but these errors were encountered: