Unfortunatley since 0.113 I’m having the same issue of CPU usage constantly going up (only reboot helps). The same happens after updating to 0.114.2.
| arch | armv7l |
|---|---|
| chassis | embedded |
| dev | false |
| docker | true |
| docker_version | 19.03.11 |
| hassio | true |
| host_os | HassOS 4.12 |
| installation_type | Home Assistant OS |
| os_name | Linux |
| os_version | 4.19.127-v7 |
| python_version | 3.8.3 |
| supervisor | 234 |
| timezone | Europe/Warsaw |
| version | 0.114.2 |
| virtualenv | false |
Running on Raspberry Pi 3 B+.
Restart is not the same as reboot. I hope you mean restart.
Could you please wait until the CPU use is high and run the py-spy tool mentioned further up in this topic then paste the results here. This will help with diagnosis of the issue.
It doesn’t seem to go higher than ~30% after a few days, the load sensor (15m) indicates a value around 1 though.
I hope the fix on zeroconf 0.28.1 will solve my issue. I’ll let you know when 0.114.3 is released. Thank you
Yeah, I meant restart. Unfortunately I did it once again so I will need to wait for CPU usage to rise… which probably will take few days. Will get back with py-spy results. Thanks!
That makes sense if it is zeroconf since the thread it is running it is probably maxing out the cpu core.
Just wanted to add I’m experiencing the same issue since 0.113 on an RPi3 B+. You can see after a restart it’s normal but it slowly continues to increase. It seems to stop around 20-25%. Will keep an eye out for 0.114.3 and update as soon as it’s released.
Please post py-spy recordings & dumps if you can.
Sorry for the delay. I did a py-spy recording for about 4 minutes. During the whole time CPU usage was above 60% on an i7 CPU. btw… I’m now on 0.114.2
This is how it looked for the last 6 hours:
I will now disable all automations just to make sure it’s not related to them.
I’m still not sure where the network traffic comes from. I’m also investigating this one.
Update: Network traffic is mostly from 224.0.0.251 (multicast DNS).
I just realized that restarting Home-Assistant throws this in the log:
2020-08-20 08:12:22 ERROR (zeroconf-ServiceBrowser__nut._tcp.local.-_ipps._tcp.local.-_api._udp.local.-_plugwise._tcp.local.-_Volumio._tcp.local.-_googlecast._tcp.local.-_dkapi._tcp.local.-_miio._udp.local.-_axis-video._tcp.local.-_spotify-connect._tcp.local.-_daap._tcp.local.-_hap._tcp.local.-_elg._tcp.local.-_wled._tcp.local.-_viziocast._tcp.local.-_bond._tcp.local.-_esphomelib._tcp.local.-_ipp._tcp.local.-_printer._tcp.local._362) [homeassistant.components.zeroconf] Failed to get info for device
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zeroconf/__init__.py", line 213, in service_update
service_info = zeroconf.get_service_info(service_type, name)
File "/usr/local/lib/python3.8/site-packages/zeroconf/__init__.py", line 2371, in get_service_info
info = ServiceInfo(type_, name)
File "/usr/local/lib/python3.8/site-packages/zeroconf/__init__.py", line 1732, in __init__
if not type_.endswith(service_type_name(name, allow_underscores=True)):
File "/usr/local/lib/python3.8/site-packages/zeroconf/__init__.py", line 268, in service_type_name
raise BadTypeInNameException("Type '%s' must end with '._tcp.local.' or '._udp.local.'" % type_)
zeroconf.BadTypeInNameException: Type '' must end with '._tcp.local.' or '._udp.local.'
It only appears once after starting up. Probably not related. Just wanted to mention it.
Update: the message repeats. It is not only once.
Sorry for spamming here… just wanted to let you know it is not related to the automations. Nothing changed while all automations have been disabled.
Something happened at around 13:30 and CPU usage is way up there again.
py-spy does show about the same as last time.
I had the zeroconf error again at 13:25. Could be related. Exact same error as I’ve posted above.
I also see these kind of messages every few minutes:
2020-08-20 13:25:55 INFO (MainThread) [homeassistant.components.mqtt.discovery] Component has already been discovered: binary_sensor 240AC48074A0, sending update
2020-08-20 13:25:55 INFO (MainThread) [homeassistant.components.mqtt] Got update for entity with hash: ('binary_sensor', '240AC48074A0') '{'state_topic': 'opengw/OpenMQTTGatew
ay_ESP32_BLE/LWT', 'name': 'OpenMQTTGateway_ESP32_BLE', 'unique_id': '240AC48074A0', 'device_class': 'connectivity', 'payload_on': 'online', 'payload_off': 'offline', 'payload
_available': 'online', 'payload_not_available': 'offline', 'platform': 'mqtt'}'
2020-08-20 13:25:55 INFO (MainThread) [homeassistant.components.mqtt] Ignoring unchanged update for: binary_sensor.openmqttgateway_esp32_ble_2
So I will re-enable all automations but get rid of the OpenMQTTGateway for testing.
You have a device on your network that is broadcasting an invalid mdns name. We recently added a workaround for this issue to prevent the ServiceBrowser from collapsing. It shouldn’t cause any issue anymore besides an annoying log message. The solution is for the vendor to fix the device firmware if they are interested in doing so (most of these were caused by older HomeKit stacks that have been fixed with device firmware updates).
Thank you for the py-spy. 0.114.3 is out. Can you give it a spin?
This sounds promising, thanks @bdraco. There are many devices on the network and I assume a few of them could have a bad firmware.
I’m installing the update right now. Will report back in a few hours. I’ve also removed the OpenMQTTGateway from the network
0.114.3 locked and loaded. Now it’s just a waiting game…
Quite a difference… this is 6 hours on 0.114.3.
I will now start to re-enable all the integrations I removed for testing. But looks very promising. Thanks for all your hard work. A fantastic software!
@bdraco It looks like you’ve fixed it. Thanks for your persistence in chasing this down. Much appreciated.
Same thing here, thanks a lot. Now I won’t hear the fan again 
