Silicon Labs Multiprotocol: all of sudden, increased CPU usage HAOS #3139
Comments
|
Restart the addon and very likely its starting OK. |
|
yes, definitely restarting the addon solves the issues. thanks. |
|
As expected restarting the add-on is only a temporary fix. It's kind of strange it seems to happen every time I have other add-ons being updated. I don't know if that makes sense. |
|
I just wanted to provide an update that I'm still seeing this issue from time to time. However it's kind of strange it's like every time I'm starting or restarting other add-ons this add-on all of a sudden has elevated CPU usage. For example today I was reconfiguring the Piper add-on (changing the voice settings) and I stopped Piper and restarted Piper and I noticed my CPU was elevated even after several monutes,and it wasn't because of Piper it was because of the Silicon Labs Multiprotocol addon. I had to restart the Silicon Labs Multiprotocol addon and the cpu calmed again. Again it just seems to be a bizarre link with other add-ons that is causing this add-on to have elevated CPU. Why would restarting other other add-ons affect the Silicon Labs Multiprotocol addon? |
|
Just wanted to mention another instance of this happening there was updates for 4 other of my add-ons (i.e. zwave, adgaurd, sqlite, etc), and again I noticed after those updates were done my CPU was elevated and it was silicon multi-protocol add-on that was elevated. After a restart of the addon,it went back down.
Anybody know why this is happening? Is there some communication that's broken during updates and the multi-protocol add-on does not recover from? |
|
Then having CLI to the Linux OS its the mDNS in the OS that is having problems like its something being locked and all processes that is using it can triggering it and its looks the addon is using it most of all so its the most likely getting the problems. |
|
that's an interesting point. An idea might be: "maybe supervisor is doing some type of USB scan which is causing the adapter to malfunction" I do have logs but I suspect these logs were created because I restarted the Silicon Labs addon. Next time I will keep an eye on the logs before restarting that addon to confirm. |
|
I can see you have updated the addon then the last error is new for the last version but its not critical but the last Zigbee have more fixes for communication and reset of the RCP that can helping getting the communication working better with the RCP. |
|
you're right. I found this upcoming update for the last error: hopefully this will solve the issue. thanks |
|
@MattWestb @Anto79-ops I have a build of the add-on with a new mDNSResponder version (1790.80.10). The mDNSResponder needed quite some patching since the new version of the upstream version of the mDNSResponder was buggy, so I am not 100% confident. Also the bump to this new version in upstream OpenThread didn't got merged yet (see openthread/ot-br-posix#1919). However, I have it running in my production for a couple of days stable here. You can try this "preview" with access to the OS shell (on port 22222, or the keyboard/screen terminal) using: Then stop and start the add-on (do not use restart, as that doesn't recreate the container). Note: This is a hack, essentially it overwrites the current version with a different version 😊 The image will get overwritten next time the add-on receives an upgrade. But it works for testing. Would be interesting to see if this resolves the mDNS CPU spikes for you. |
|
Hi @agners Thank you very much for this opportunity to try out the patch. I'd be happy to install it. Just a quick a question for installation, I have both access to root from ssh port 2222 and keyboard/screen terminal addon Do l simply just type the 2 lines in the directory it's in the moment I log in. I.e. pwd is /root Thanks |
Yes, it doesn't matter in which directory. |
|
Thanks! The addon still says its 2.3.1 but I suspect that is expected but just wanted to confirm that. Here is the cli output for the process
I stopped and started the addon. |
|
The 64 bit is only running Ziogbeed but the logs looks like: I shall trying updating the 2 32 bits also but i must finding the URL for doing it so need looking in docker for it. Edit: I was doing one restart so it was not OK and have one start stop and updating the log. |
|
I was trying : so i have doing it wrong or its the arm7 not build in the test repro. |
Yes, that is expected. The add-on itself reads the version from the container image tag. |
Awesome. By the way there was an update for Z-WaveJS UI today (another add-on that I have) and I did not experience the elevated CPU after updating that add-on. So far so good 👍 |
The armv7 image was missing. I just built and pushed it. |
|
RK3228 on armbian Ubuntu 32 is up and running and looks working OK: I updating the NanoPI Neo after restart of my laptop then its like doing Windows update. Edit: Bringing up one more OTBR is making HA loosing contact with the thread devices as expected so its no go. |
|
Hi I just wanted to provide an update that since using the "hacked" version of this addon, I have not experienced elevated cpu readings, including when a few addons have been updated I'd be willing to close this issue but perhaps maybe a few more days or a few more updates for add-ons just to make sure but so far this is going really well. 👍 thabks @agners |
|
On my production instance, I've noticed that the mDNS announcements for the So while I did not have the 100% CPU issue, this "lost discovery" is a bit concerning to me. I've restarted the add-on, and the Thread instance appears again, the DNS-SD messages are sent out again. I'll monitor it again. Anyone else seen this? |
|
Hi, I don't think I've experienced this, checking my logs I do see that let me know if you would like me to dig deeper. |
|
Just wanted to provide another update. Again more good news there have been more add-on updates. More time has passed and I have not experienced an elevated CPU usage since installing the hacked version of the Silicon Labs Multiprotocol addon. As far as the CPU utilization concern, I'd consider it solved. However, I have not been able to see the issue that you've experienced so I will leave this issue up to you whether or not you want to close it or keep it open. Thanks again @agners for your help, and please let me know how I can contribute more if needed. |
|
Hi @agners -- just found this report after some googling while trying to understand why my border router kept disappearing from my thread panel in HA. I've been experiencing the exact same cluster of symptoms (border router isn't showing up in the thread panel, currently configured matter over thread devices continue functioning, multiprotocol addon consuming one full CPU core). Is there any benefit to you having another person pull your custom docker image for testing? I see that you marked #3169 as ready for review a few hours ago so if there's no need for additional testing I'm happy to just wait. Thanks! |
|
Hi all, I just wanted to confirm the issue of the disappearing thread border router device. When it happens do you have to do any actions to get it back like reload or something like that? Maybe the closest thing I've experienced with this is that when I do open the thread panel it takes a second or two for the border router devices to populate but they always repopulate of the times I've done it. The skyconnect was always on the thread panel. |
|
@itpeters I just merged that commit, so it will soon appear as an add-on update. As for disappearing Thread border router from the Thread panel: This is a different issue it seems. I first thought it was a regression of #3169 (since I was running a version with that change), but since you were running the version before (and also others reported they observed the same while running the old version), it doesn't seem to be a regression. The disappearing Thread border router warrants another issue. If anyone catches the add-on behave like that, please post a new issue along with the add-on logs. I am closing this issue since it is about the 100% issue which is expected to be resolved with #3169. |
|
I've just had the 100% CPU case in the pure OpenThread Border Router add-on. It seems that in this case the |
|
Is the addon using its own mDNS or its it using the OS one ? |
|
The add-on brings it's own mDNS suppport, it uses the mDNSResponder from Apple. If htop was showing Home Assistant OS itself has systemd-resolved with performs mDNS and DNS-SD operations. But we aren't really make use of that. Home Assistant Core brings it's own mDNS implementation provided by https://github.com/python-zeroconf/python-zeroconf. |
Describe the issue you are experiencing
Hello,
I just recently enabled multi-pan on my SkyConnect on HAOS/RPi and ZHA.
Home Assistant 2023.7.2
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest
Silicon Labs Multiprotocol: 2.2.0
ZHA
Open Thread Border Router
Thread
Matter 4.8.3
I don't actually have any thread or matter devices (I tried to install nanoleaf, but it simply would not work)I have 2 thread devices now.I do have 5 google nest hubs that are acting as a TBR of which I added my SkyConnect, (firmware 4.3) too so I have a single thread network with 6 thread border routers.
I had to change my ZHA channel from 20 to 16.
Every once in a while (almost every 2 days), I notice increased CPU usage of HA and glances tells me it's coming from the Silicon Labs Multiprotocol addon (see towards the end this CPU Plot)
The logs for the addon (or at least what I could copy and paste are full of this):
stoppinf the addon and restarting it, solves the issue
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.2.0
Steps to reproduce the issue
...
System Health information
System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
Spotify
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?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: