Raspberry Pi 5 support and more in Home Assistant OS release 12 & Supervisor update

Blog
1

TL;DR: Home Assistant OS 12 adds support for Raspberry Pi 5 and ODROID-M1S boards, with the Linux kernel updated to 6.6. Additionally, backups have become faster, and add-ons can now signal when they should not be auto-updated.

Raspberry Pi 5

With the release of Home Assistant OS 12, we officially announce Raspberry Pi 5 support! Many Home Assistant OS users have extensively tested the preview releases during the last few months, and after some initial hiccups with the Raspberry Pi 5-specific update mechanism, things are stable and solid today. As a third of all Home Assistant users currently use a Raspberry Pi board as their dedicated Home Assistant system, we are sure this support will make many users very happy!

Compared to other Raspberry Pi boards, HAOS does not use U-Boot as an extra bootloader. Instead, the Raspberry Pi’s built-in “tryboot” functionality is used to automatically fall back to a previous release in case of an update failure. This new update mechanism integration required us to have a longer testing phase.

In our testing, the higher CPU clock of the Raspberry Pi 5 (up to 2.4GHz) makes Home Assistant feel noticeably snappier compared to previous Raspberry Pi boards. Additionally, a Raspberry Pi HAT that provides NVMe SSD support allows you to extend your Raspberry Pi with fast, reliable, and cost-effective storage. We do recommend using an SD card as the boot medium and using the data disk feature to move most of the Home Assistant installation onto the NVMe. This is easy to set up and guarantees a reliable boot.

ODROID-M1S

The Raspberry Pi 5 is not the only new board that is supported with this release. We are happy to announce that the family of supported ODROID devices from the Korean manufacturer Hardkernel has become bigger thanks to a community contribution from Tim Lunn (darkxst), who implemented board support for the ODROID-M1S. The ODROID-M1S is the newest single-board computer from Hardkernel, which is similar to the already supported ODROID-M1, which was added in Home Assistant OS 10. This new board offers a slimmer form factor, 4 or 8 GB of RAM on board, and an embedded 64 GB eMMC storage. Home Assistant OS can be booted either from an SD card or the system can be flashed to the eMMC card using the procedure described in the documentation. While the board also has an NVMe slot for a solid-state drive, it is not supported as a boot device. However, just like on the Raspberry Pi 5, it can still be used as the data disk.

Just like its larger brother, the ODROID-M1S is powered by a quad-core ARM Cortex-A55, but while ODROID-M1 has (very slightly) beefier Rockchip RK3568 SoC, this board sports the RK3566. Some of our more curious readers may notice this is the same processor that is found on our Home Assistant Green! While there are some similarities between those two boards, Home Assistant Green can offer you a seamless out-of-box experience, allowing you to set up your smart home in a matter of minutes. But Home Assistant is also about the freedom of choice, so if you are looking for a more DIY approach, ODROID-M1S might be the right choice for you.

Linux 6.6

Home Assistant OS 12 now comes with Linux kernel 6.6! This is good news for those who want to run their Home Assistant on newer hardware that lacked support in the previous 6.1 kernel. This version update also allows us to extend the list of supported Wi-Fi and Bluetooth cards, including ones you may find in new mini-PCs, a popular platform for Home Assistant OS. Those who run their installations on a Raspberry Pi (including the CM4 in Home Assistant Yellow) may notice their kernel version still starts with 6.1. This is because we are not using the upstream kernel but the downstream one maintained by the Raspberry Pi developers. But this kernel was also updated to the latest stable version, which we hope will resolve some sporadic bugs.

Home Assistant OS sticks to the LTS (long-term support) kernels, which are usually released once per year - just like Buildroot, the base system we use for Home Assistant OS. This time, we are slightly ahead of schedule, because usually the kernel update is done alongside the bump of the Buildroot version. But don’t worry, the Buildroot update is coming soon as well, and we expect to include its update in one of the next minor Home Assistant OS releases coming in the following weeks. This will conclude this year’s spring cleaning of Home Assistant OS, and we will be ready to focus on new features and improvements again!

Faster Backups

Home Assistant Supervisor and Core’s built-in backup functionality has become much faster. Thanks to contributions from bdraco, the backup feature gained faster compression speeds due to a library named isal, which provides optimized low-level functions for compression and decompression. More importantly, the backup feature now avoids intermediate copies, making it faster on slower storage media especially. If you used uncompressed backups before because the backup used to be too slow for you, now is the time to give compressed backups a try again! 😀

Home Assistant OS users’ backup functionality is part of Supervisor. You’ll have received the improvements incrementally over the releases of the past few weeks. At the time of writing, your installation should run on Home Assistant Supervisor 2024.02.0 with all these improvements built in.

Safer add-on auto-updates

Last, but not least, the Supervisor features an auto-update flag for add-ons. However, depending on the nature of an update to the add-on, the new version might need user intervention or have breaking changes. Add-on developers now have the option to prevent auto-updates to such versions. Users of the auto-update feature might see an update notification despite auto-updates being enabled. This means that the author of the add-on decided that this particular update should not be auto-updated and instead be manually approved by the user.

Note: We generally don’t recommend auto-updates for add-ons, as even safe updates might interfere with regular operation. For example, during the automatic update of an add-on like Z-Wave JS, your Z-Wave devices would unexpectedly become unavailable for a short time. The better approach for such add-ons is to plan some time to maintain your Home Assistant system every once in a while and update your add-ons in a batch.

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2024/02/26/home-assistant-os-12-support-for-raspberry-pi-5
9 Likes
2

Any reason for the recommendation to boot from SD card instead of just directly off an nvme drive?

3

Also improvements were released for restoring backups too.

1 Like
4

I think some NVME devices can have compatibility issues booting. With the proposal to use an SD card for boot and move data to NVME, you get the best of both worlds.

5

My system hangs for some reason during boot. It doesn’t get past loading groups, and no addons are loaded.

It’s been a good 20 minutes, restarting and rebooting the system does nothing.

Any ideas please?

Edit: So it’s booted up now as well as the addons, however lovelace not showing the entities despite z2m working correctly. I deleted frontend cache, restarted but still the same issue?

Supervisor isn’t responding to restart commands, I have to reboot System level from my server.

6

You’ll need to add more details to your description for your issue and this thread will be adding more replies to the blog topic, where your conversation could get lost.

It would be better to start your own thread in the Home Assistant OS section: Home Assistant OS - Home Assistant Community

Include what version of HA OS you are running, what hardware it is is running on, what you are seeing in the logs if anything, etc

1 Like
7

I understand your point about auto updates not being recommended. But Home Assistant has garnered a large folllowing of people that want “just home automation” and that don’t see Home Assistant as a system they need to maintain.

The point about integrations being unavailable could be just as easily be diminished if Home Assistant supported a simple maintenance/auto-update period, like “tuesday at 4am” for basic/safe add-on and Home Assistant/Supervisor updates and reboots.

This would really alleviate most of the concerns and make sure that the less savy users keep up with the security and stability updates.

2 Likes
8

Some boards can’t directly boot u-boot from nvme. Odroid M1 instead use workaround - boot u-bot from SPI and after boot from nvme. It’s possible to store only loader and A/B but required external work and support. So not in priority. Just use SD and NVME as Data Drive :wink:

9

It can boot directly. You just need to use proper OS.

10

It would need at very least be organized around timezones. If it would be 4am local time, then an update would be spread out over 24h.

The post is about add-on updates in particular. Add-ons are maintained by various developers, so not every developer might prefer the same update time.

In the end, in a way, the users are still responsible for their instance. It is possible to update add-on using hassio.addon_update service call. So creating a blueprint which updates add-on on a particular day would be rather straight forward.

In fact, we have discussed to remove the auto update feature as it stands today and promote a solution using Core automation and service calls. But currently it isn’t as easy to automate such updates, so we kept the current feature set.

This reminds me: The current hassio.addon_update service call has essentially the same problem as the built-in auto update: How-to deal with add-on updates which have breaking changes :thinking: There probably should be a flag weather to execute such an update or not.

@CentralCommand thoughts?

11

The RK3568 ROM can’t but it can via SPL/U-Boot from SPI EEPROM yes. However, HAOS’ A/B fallback boot requires control over the boot process so we can’t reuse that boot flow :cry:

1 Like
12

Where do I configure that my backups are compressed?

13

There is an option in services (Home Assistant Supervisor: Create a full backup.)

LIke:

service: hassio.backup_full
data:
  compressed: false
  homeassistant_exclude_database: false
1 Like
14

can someone point me to developer docs on how to configure auto updates to be disabled? Maybe the addon config docs just haven’t been updated yet Add-On Configuration | Home Assistant Developer Docs

15

The documentation indeed was still missing, I’ve just merged the PR updating the docs. See breaking_versions configuration option in the Add-On Configuration section.

1 Like
16

So this is only configurable in YAML? Does this compress backups that happen when performing upgrades, too?

17

Now the big question remains. Can we simply change hardware, place your SD (or SSD) in Raspberry Pi 5 and everything keeps working as it should?

18

Not really a “big question”…the post is about Pi 5 support for Home Assistant OS so how would HAOS for a different hardware magically work on Pi 5…

You’ll need to install HAOS 12 for your Pi 5, boot this and then you can restore a backup of core and all things should work…fingers crossed. It’s a combination of instructions from Raspberry Pi - Home Assistant plus Onboarding Home Assistant - Home Assistant and then finally from Common tasks - Operating System - Home Assistant

2 Likes
19

So how would one go about following the guidance of installing HA OS on an SD card and then connecting to a NVMe drive using the data disk feature? I bought the Argon ONE V3 M.2 NVME PCIE Case and didn’t have any problems getting HA OS installed on an SD card and restoring my instance from a backup, but I can’t get it to detect the attached NVMe drive. The instructions that came with the Argon case say to run some scripts that mess with the Pi 5 eeprom and config.txt (seems to be true for other NVMe “hats” as well), but that doesn’t seem possible on HA OS as it doesn’t have any of the necessary packages to run the scripts, let alone even download them, even when accessing HA OS over SSH.

As an aside, Assuming I figured out how to run the scripts for my Argon case or figured out how to manually make the same changes that the scripts are making, I’m concerned that a future HA OS update would overwrite those changes. Is that a valid concern?

I would appreciate some guidance here! For now I’ll just keep my Pi 4 HA host live…

20

Just off the top of my head, maybe you could use a fresh SD card with Raspberry Pi OS to do the eeprom and config.txt changes. Make note of the config.txt changes. Then boot from your HA SD card and reference this post for applying the same changes to the HA config.txt: How to access config.txt in Hassio? - #7 by flamingm0e