Home Assistant OS 10: Better memory management and new board support

My cpu use is also way up. It’s completely insane. I’ve seen a 35%+ increase in CPU usage. I am not running Motion Eye(which some have purported to be an issue.) Even without Frigate(which does run the CPU hard) I’m still idling at something like 30% usage on a 5th gen NUC(old, yes I know but still plenty powerful.)

It is very clearly tied to the OS update(10) as can be seen in the history shot below:

I can’t rollback with a backup with totally sucks… can someone help me out here?

Oh, also tasmota devices are unavailable, which I saw a github issue has already been logged for. Whew, this update was a doozy. sigh

2 Likes

Post 63 above shows how to roll back to the previous OS version:

1 Like

Got it, thanks. BTW there is a space between ‘update’ and ‘–.’

Rollback of OS solved the Tasmota issues and the high CPU usage(dropped from ~80% to ~40%.) It was immediate.

Im on an Standard ODROID-N2+ 4GB/64GB eMMC … System Info:

Home Assistant 2023.4.6
Supervisor 2023.04.0
Operating System 10.0
Frontend 20230411.1 - latest

I am having an issue trying to move data file to external SSD… using a samsung NVMe 960 evo 500gig SSD in a USB3 enclosure. I formatted the SSD to ext4 and was able to see it on a windows PC. I plugged it into the HA unit and restarted. I was not wanting to boot from it but rather just move the datafiles.

I tried using the “Move Datadisk” function via the UI. It initially shows the Samsung device but when i select it within a min or so it tells me that the device is invalid or non existing.

I have tried several options via CLI and have had no luck.

Any suggestions or has anyone made an official report to HA dev team ?

Thanks for this. Bluetooth devices (Switchbot hot and meter) wouldn’t stay connected for more than a few hours on v10. So far so good since rolling back to v9.5

My Odroid C4 system also suffers from increased CPU load after upgrade from 9.5 to 10.0.
Seems to be related to BLE trackers (USB dongle + ESPHome proxy).
More details available here: Unusually high host CPU LOAD after ESPHome update 2023.4.0

This is a problem in the Audio plug-in which recently got updated. You can find details here: After the OS 10.0 update, odroid-c4 hassio_audio Failed to open /proc/asound/card0: No such file or directory · Issue #2510 · home-assistant/operating-system · GitHub

1 Like

HAOS v10.1 does not fix bluetooth, still broken. Seemed to stay up longer, but still died and rebooting bluetooth integration only allowed it to run for 10 seconds. Something is still wrong with this 10.1 release.

Can anyone comment on cpu usage issues with 10.1? I’m not touching it until someone else takes the plunge. :sweat_smile:

Intel NUC here and not seeing CPU usage problem on 10.1, but bluetooth and NVMe problems still exist.

1 Like

Same here, 10.1 didn’t solve my bluetooth issues.
I went back to 9.5 again

Is anyone else experiencing local DNS resolution issues since upgrading to 10.0? The issue persists on 10.1. Local DNS records are resolvable for a few hours, then it fails. Nothing obvious in the logs.

Once it stops working, I can perform an nslookup which works if I specify a local DNS server by IP address, but it fails without it.

I just updated to 10.1 and begun to have problems with all my chromecasts… no sound coming from them. I switched back to 10.0 and all returned to work… For my mistake i forgot to save the log about this issue…
Is another one having the same issues?

I just updated my yellow from v9.5 to v10.1.
And so far no issues. Ram usage is lower and cpu usage around the same.
I don’t use BT or chromecast.

BT, casting, and DNS randomly die in 10.1.
NVMe drives also start showing corruption after 3-5 hours of use.

I have yet again reverted to 9.5.

1 Like

@SamJWard, what do you mean “start showing corruption after 3-5 hours of use”? I haven’t found any posts or GitHub issues on this. What are the symptoms?

Note: I have experienced what looks like random failure to read the NVMe drive (and subsequent failure of all system components managed via Docker). This first occurred a day or so after upgrading the Yellow to 10.0, but after the first time, I downgraded in situ to 9.5. However, since then, it has happened twice more, so I am not sure it really is related to the upgrade. (It still might be, either by on-disk corruption or because some firmware BLOB has been upgraded and not rolled back with the OS.)

The drives SMART values are normal and don’t indicate any read errors, so it does not look like a hardware failure, at least not of the drive. A reboot by removing the power cable for a short time “fixes” the issues, but it happens again after a few hours or days.

not sure it this is related to anything you said,
but all was working fine, no issues for 30hours,
then exactly at the moment my daily backup started HA crashed. It can be a coincidence.
but I will keep track of this issue.

I have had this twice in the last few days also. Around the time of backups (using SAMBA Backups) the whole VM in Virtualbox crashes. Currently on OS 9.5 (10 and 10.1 no good as Bluetooth doesn’t work) and was on Core 2023.4.5. Have updated to 2023.4.6 today (broke Alexa Media Player again but I changed DNS to 8.8.8.8 and 1.1.1.1 and it is now working - no idea why, everything else is fine. Everything seems to be getting bit flaky with HA unfortunately.

I actually remember my full machine crashing twice on OS 9.5
this was both during esphome builds.
the backup and esphome builds have in common that the cpu usage is high,
so maybe something goes wrong when the CPU is stressed out.
but then it can also be hardware related of a cooling issue.
but that I do not see back in the measures
image
image
the spike after the reboot is because it needed to catch up with the backup plan

If the machine fully crashes, it could be related to out-of-memory issues. Compiling ESPHome requires quite a bit of memory, and especially on HAOS 9.5 this lead to out-of-memory situations with long freezes or sometimes killing of essential services. HAOS 10 should behave nicer, but I’d try to stay within 80% of memory usage even when compiling ESPHome or similar temporary loads.