New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZHA stops working when adding devices, then fails to load. universal_silabs_flasher probes for bootloaders. #115141
Comments
Hey there @dmulcahey, @Adminiuga, @puddly, @TheJulianJES, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) zha documentation |
ZHA expects that the stick can send a startup broadcast to disable joins. This should always work. For your stick, however, it does not: 2024-04-07 20:05:33.613 DEBUG (MainThread) [bellows.zigbee.application] Request (<BroadcastAddress.ALL_ROUTERS_AND_COORDINATOR: 65532>, 12) failed to enqueue, retrying in 1.5s: EmberStatus.NETWORK_BUSY Is your stick on a USB extension cable and away from interference sources such as USB 3.0 ports, SSDs, 2.4GHz WiFi, and so on? |
Yes. What about the |
Double check and make sure your antenna is screwed on. I don't think I've ever seen this error before.
In this case, yes and no. Yes because the radio did not start up (as the flasher checks to see if you have the wrong firmware installed). No because the radio did start and communication with the firmware did happen but it failed due to other communication reasons before ZHA was able to talk to it. |
To me, it seems like the Zigbee system (Home Assistant's ZHA integration + the stick) can be in two states, "working" and "not working". In the working state, everything seems normal and stable. In the not working state, it is as described above with cycling between Initializing and Failed to set up. It also seems that I trigger the not working state when adding new devices, as this has happened three or four times. After adding a few, it won't add anymore, and if I then restart Home Assistant, I end up with the Initializing/Failed cycle. Restarting Home Assistant again does not help. Restarting the entire computer might help, I will try now. |
Is there a possibility that when for instance startup takes longer time than expected, the flasher starts up and interrupts ZHA initialization? Can I disable the flasher somehow? |
I did not find a way to get ZHA up and running by unplugging/plugging, turning off/on, restarting etc, so I let it stay in the initialization cycle over night. Now, it's up and running as normal again. Is there anything I should test in this state? |
Not really, startup fails due to the broadcast error. The flasher doesn't interfere because ZHA spawns it after failure. The startup broadcast failure is the main problem. Reposition your coordinator to see if it helps. |
So do you interpret that this is due to some critical commands that fail on air (due to no ACK or similar)? In any case, I will experiment with the position, and can also try another stick if I can take a backup and restore to that one. What should I look for in the logs to judge whether there are still critical issues? Some examples from logs:
|
There are no communication issues with the stick itself, as the wire protocol has checkums and ACKs. The startup
|
Strange. I switched stick and restored backup (nice process!), and see the same issues - trying again and again to initialize. So at least it is not a problem with the specific stick. I also moved it further away from other stuff (with 1 m Deltaco USB cable). Zigbee channel 25, and although I have a WiFi access point in the same room, it is on channel 1. In general it seems to work well when it is first up and running, and struggle during startup and when adding new devices. Maybe this leads to a larger amount of messages, which triggers an issue? Do you have a recommendation for the next steps? I have an older Deconz stick I could try (but probably have to re-add all devices), or I could try Zigbee2MQTT to see if it can be a software issue. |
What stick did you switch to? There aren't any known stability issues with the EZSP library that would cause this to happen, it's in my opinion environmental.
People run 300+ devices without issues, there's no real limit that would cause this problem.
You can try it as long as you flash more recent firmware to it, the migration flow works with it as well. |
I ordered two of the SLZB-07, so I switched to the second one. I also just moved the NUC to a different room, let's see if it changes anything. Even though the network could initialize and I can control devices, there are occasional errors in the log, example below. Is there anything I should try in this state to narrow down the problem?
|
I upgraded to the latest firmware of the ConBee, but I was not able to restore settings from backup. So, either I need to set up the entire network on that one to see if it can be a problem with the stick firmware/driver etc, or set up the network in Zigbee2MQTT to see if that can give any more information. Or do you have other suggestions to narrow down the cause? |
Can you upload a full debug log of ZHA starting up and not failing with your original coordinator? It'll include more info. |
I think you are on to something, even when it initializes successfully there are some errors. The full log is over hundred MB, so I'll first try with an excerpt if that is OK. I'll start from the two last cycles of trying to initialize, and then some minutes from "regular operation". |
The problem
I am in the process of setting up my Zigbee network. I recently set up Home Assistant and bought a new Zigbee stick (SMLIGHT SLZB-07). After adding some devices, the next ones did not show up, so I reloaded the integration. It cycled between "Initializing" and "Failed setup, will retry".
Multiple restarts, plugging out and in stick etc did not help, until it suddenly started working again. After adding three new devices, nothing appeared for the fourth one, and I reloaded the integration again. Then the same cycle happened.
The times it does not work, I get log entries from
universal_silabs_flasher
probing for bootloaders right afterFailed to set up ZHA
. I suspect this is interfering with the ZHA communication, but it might as well be a regular part of the ZHA integration trying to understand which stick it is communicating with?Attached are logs from one initialization cycle, except some lines with MAC addresses removed.
What version of Home Assistant Core has the issue?
core-2024.4.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant Container
Integration causing the issue
Zigbee Home Automation
Link to integration documentation on our website
https://www.home-assistant.io/integrations/zha/
Diagnostics information
home-assistant_2024-04-07T18-06-04.492Z.log (MAC addresses masked)
Summary:
First, a lot of log entries during initialization. There are a few error messages during initialization, not sure how concerning they are:
Then, ZHA seems to either give up, or be interrupted, before
universal_silabs_flasher
does its thing:Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
Home Assistant is running as a container in an Ubuntu VM in a Proxmox hypervisor on an Intel NUC.
The text was updated successfully, but these errors were encountered: