Sonoff Zigbee 3.0 Dongle Randomly Died and ZHA made fixing it worse. #124
Comments
Did you do a network backup/restore? ZHA doesn't keep track of network settings so switching hardware will leave you with a new network with random settings. |
|
Yes I did as I have multiple dongles. The issue is why did zha or home assistant disable all entities just because of a config entry change which is necessary to change the USB Id. Disabling all the entities makes it very time consuming if one has a lot of devices to re-enable. Whether that's because of a dongle isuse or because of a migration. |
|
The dongle lockup issue is something I can possibly take a look at in zigpy-znp. Can you make NVRAM backups of both a working and a broken dongle and email them to me/attach them here?
@Adminiuga @dmulcahey This is the second report of all entities being disabled by HA Core (#111) after disabling/re-enabling ZHA or editing a path in |
|
I will email the 2 Nvram backups. Is there a reason I'm unable to backup the sonoff dongle with
Yes please undo whatever occured in an ha core update. If a configuration change occurred I don't see why it's important that entities are disabled at all. |
|
|
|
I see I was using the command I used on the nortek. |
|
Any update on what happened to the problem stick? |
|
I see no differences in the NVRAM between the two. Both produce nearly identical network backups when written to my stick, with the only two differences being:
Everything else is structured normally. To double check, I restored both NVRAM backups one by one to my ZZH! and tested sending commands. Wireshark shows that both NVRAM backups produce the "same" network from the perspective of a listening device. Can you "swap" the NVRAM between the two? Do this offline with the current devices, the backup you took earlier may be too old: $ WORKING_STICK=/dev/serial/by-id/...
$ BROKEN_STICK=/dev/serial/by-id/...
$ python -m zigpy_znp.tools.nvram_read $WORKING_STICK -o nvram.working.json
$ python -m zigpy_znp.tools.nvram_read $BROKEN_STICK -o nvram.broken.json
$ python -m zigpy_znp.tools.nvram_reset $WORKING_STICK
$ python -m zigpy_znp.tools.nvram_reset $BROKEN_STICK
$ python -m zigpy_znp.tools.nvram_write $WORKING_STICK -i nvram.broken.json
$ python -m zigpy_znp.tools.nvram_write $BROKEN_STICK -i nvram.working.jsonAfter adjusting the serial port, the "broken" stick should start working. If not, it is a hardware problem. |
|
I will look into swapping Nvrams. Any word on the disabled by configuration entry change made by home assistant core? I just noticed it on my Roomba integration I disabled. At least that was 3 entities not 100+ to re-enable. |
|
Fixed by home-assistant/core#63944, seems like it will be released in HA Core 2021.12.10. |
|
Sounds good because enabling all the devices was awful especially when it's possible the sonoff stick has a problem. It can take a quick swap from quick to a super long time. |
|
This is slightly unrelated but related to what happens when the coordinator dies. I inquired about whether it's possible for a failover coordinator and le_top who made a component for automatic backups said he found mention of it in a 2008 ZigBee paper. Is this something that's possible with zha? It would be great to have a coordinator ready to take over immediately when one dies. |
|
I'm still not sure what "coordinator dies" means in your case. Did the dongle itself have a hardware glitch? Did some core router of your network have a firmware glitch and "lock up" but still pretend to be online (IKEA and other routers can do this until they're rebooted)? Was it a host hardware issue? |
|
I didn't try to use the other coordinator yet so I don't know if it works still. That's why I said it was slightly unrelated to what happened to me but it would be great if it ever happened again for another coordinator to immediately take over. I was inquiring as to whether it's possible if the coordinator locks up for example and stops sending commands another coordinator can take over. My coordinator per the logs I attached did have an issue what the cause was I don't know but it was unresponsive to home assistant. I'm wondering if it's possible that can be detected and another coordinator could immediately take over. If you see the link I attached le_top linked a few articles discussing this very possibility. That a coordinator could immediately take over if it detected the main coordinator was down for example. |
|
Without figuring out the root cause, there's no point in trying to fix an unknown problem with a complicated solution. The coordinator's firmware may have very well been running even if the stick's serial interface is down, so the coordinator appeared "alive" on the network while appearing "dead" to the host, preventing any sort of backup coordinator from ever detecting a problem. It'd be a whole lot easier to use https://github.com/mvp/uhubctl and have two coordinators plugged into a supported USB hub. Power cycle the hub to physically reset the sticks, restore a backup onto the second coordinator, and change the serial port path to point to it. Restart HA and you're good to go. Heck, since zigpy-znp auto-reconnects in case the radio becomes unresponsive, you could even do a hot swap without restarting HA if you create some |
|
How would a hotswap be done? Is there a potential way to automate when zigpy-znp autoreconnects it would hot swap to another coordinator? |
|
Create a symlink and externally update it to point to the correct radio. |
As the title suggests my sonoff zigbee 3.0 dongle randomly froze up. I restarted the dongle by plugging it back in and it was very sluggish then I started getting a ton of errors.
I did not have ZigBee debug logging on. Here's the home assistant logs from the UI.
ZHA or home assistant core made this worse because I have multiple dongles and I switched to another and changed the config entry. I have done this multiple times to troubleshoot except this time all 106 devices were "disabled by configuration entry" and there was no way to enable them even if there was a full reboot. The only way to enable it was to press on the entity go to device settings and hit disable then re-enable and update then it gave me an enable button and I enabled it.. I had to do that 106 times and that was awful. If this is a zha issue can we get that removed? Why does it matter if I change the config entry that doesn't mean make my life harder after my sonoff stick died lol.
I can't re-enable the coordinator at all as there's no entity to click on hopefully that doesn't cause issues.
One of them switched after doing disable and re-enable at the same time and hitting update to saying "disabled by user" even though it was enabled the entire time I never updated it with "disabled" I just clicked it twice but it never updated as disabled. Another kept the same message just now of "disabled by configuration entry". Needless to say not sure what happened to my sonoff dongle thankfully I have 4. But zha just made everything 10x more difficult.
The text was updated successfully, but these errors were encountered: