Multiprotocol Add-On Crashing #3408
Labels
Comments
|
I have the same problem |
|
What devices do you have on your ZigBee and Thread networks? How many? Can you upload a debug log of the addon crashing? |
|
This is the debug log when I try to restart the SkyConnect Multiprotocol integration which fails. I have only some Zigbee devices. No thread devices (yet). The problem also happened after upgrading to 2.4.3. |
|
Thanks! What about the addon logs? |
|
Same issue Mostly third reality stuff and not using any thread/matter devices currently but planning to soon |
|
Looks like otbr-agent[301]: 00:44:31.900 [W] P-RadioSpinel-: Handle transmit done failed: Parse
otbr-agent: ../../third_party/openthread/repo/src/core/mac/sub_mac.cpp:624: void ot::Mac::SubMac::HandleTransmitDone(ot::Mac::TxFrame&, ot::Mac::RxFrame*, ot::Error): Assertion `false' failed.Specifically, |
|
I rolled back the Multiprotocol addon update back to 2.4.2 where is has been known to be stable in my environment. I have about 60 Zigbee devices and 3 thread bulbs. All were working fine prior to 2.4.3. |
|
|
Restarting the add-on also fixes the SkyConnect Multiprotocol integration. |
|
Looks like the exact same problem as above, thanks. Make sure you keep the watchdog enabled for the addon so that it auto-restarts. |
Yes, I just did. I noticed it was off when I searched for the logs. Thanks. |
|
The ever first version I installed was 2.4.3 (today), so I do not have any older versions in a backup. Is there any way to install an older version directly? |
|
Same here. ~80 zigbee devices in the network. RPi 4, SkyConnect stick. Stable until 2.4.3 update today. Running ZHA. |
|
Same here :( |
|
I also have this issue. Crashed 2 times in the middle of the night. ZHA in combination with Skyconnect. I now have the watchdog running and hope it will restart at the next crash so my Zigbee network will not be broken for hours... |
|
+1 Logs maybe related: and Logs (partly) from Silicon Labs Multiprotocol AddOn |
|
Crashed, restarted, but still crashes, so went back to previous version. |
|
I just installed from a backup. I not aware of an addon option to install a specific version. |
If you have 80 zigbee devices you shouldn't be running Multi protocol at all but just use an additional stick for Thread OR use 3rd party border routers such as homepod minis. Multi protocol is only suitable for smaller sized setups as the radio is shared between the 2 protocols. Next to that we do not recommend multi protocol at all at this point due to stability issues. This issue report is actually a duplicate of an existing issue: #3192 I would advise to only use multi protocol in test setups for now. On your production setup, use zigbee only firmware and use a dedicated extra stick with thread only firmware or existing border routers from Apple or Google. |
|
Duplicate of #3192 |
|
@marcelveldt @frenck OP reports "This issue began after updating to Multiprotocol version 2.4.3. ", what makes you believe that this is a duplicate of #3192? While I agree, such a large setup is much better served with separate radio (see also this information page about why that is), I think from a debugging perspective it might be better to collect regression reports separately from the original crashes. |
|
Also reverting back to Multiprotocol version 2.4.2 fixed the problem for me. I have only 17 zigbee device. Some light switch, smart plug and temp. sensors... |
puddly
changed the title
|
I'm facing the same issue. |
|
Glad this topic is reopened. Especially because before the update there was no issue and after the update there is, regardless of if we should or shouldn't use the integration for whatever reason. |
|
I have the same problem, ZHA is in initialization status and nothing works anymore... unti a complete reboot. I have the Skyconnect stick and it runs in multiprotocol mode, although I don't have any Thread devices yet. But exactly this mode was the reason to buy it and switch from Sonoff... Because it was supposed to support everything and now the solution is to let it run on Zigbee only and use something else for Thread? It worked completely error-free and without failures until a certain update. |
|
Unfortunately, previous versions also did not work for all users error free 😢 . Especially folks which were using the Thread network as well. So we do have to continue development, and update to newer version. We've recently updated to Silicon Labs latest version based on Gecko SDK 4.4.0. Unfortunately, as many of you observe, this seems to have negative effect on some system. @Guardempire (and others) Home Assistant creates a add-on specific backup by default. If previous versions do work fine for you, you can simply downgrade to that previous version and skip/ignore this update. The multiprotocol solution has also some technical downsides. If you have two sticks anyways, I'd consider using them to form separate networks (as linked above, see this article). We'll continue to work with Silicon Labs to get to the bottom of (all) the issues. 🤞 |
|
Hi @agners , This is the kind of communication I like. Understanding, informative, helpful and hopeful. Thank you! |
|
Hey @agners, Greetings! |
|
Maybe a disclaimer for the product: Only for development purposes and don't use it in production environment. |
|
This issue has been fixed with the latest version of the addon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the issue you are experiencing
About 1-2 hours after restarting Home Assistant, the Multiprotocol add-on crashes. This issue began after updating to Multiprotocol version 2.4.3. No manual configuration changes were made on my end. The current workaround was to enable the watchdog to restart the Multiprotocol addon when it crashes.
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
Which add-on are you reporting an issue with?
Silicon Labs Multiprotocol
What is the version of the add-on?
2.4.3
Steps to reproduce the issue
System Health information
Anything in the Supervisor logs that might be useful for us?
No response
Anything in the add-on logs that might be useful for us?
The text was updated successfully, but these errors were encountered: