Replacing Raspberry Pi 3b Home Assistant

Fulcrum

After running Home Assistant on a trusty first revision Raspberry Pi 3b for a number of years, it unfortunately is no longer able to keep up. Both due to the incremental creep in system requirements for newer versions of Home Assistant Operating System (HAOS); Along with changing demands and extra duties placed on the machine over that time. This has resulted in large periods of time where the load is too much and my smart home goes down or otherwise becomes non-responsive.

Home_Assistant_logo

Why HAOS in the first place?

When initially deploying Home Assistant, I opted to go for the DIY HAOS installation method, on my Raspberry Pi 3b. The reason I went with Home Assistant OS was primarily due to it’s simplicity of install and management, being largly set and forget. Being the recommended installation type was also a signifcant decider for first time use.

Raspberry Pi 3B

The original Pi 3B specs

  • 1.2GHz Quad Core ARMv8 CPU
  • 1GB RAM

The 1GB of RAM would seem to be my most limiting factor for Home Assistant, being maxed out with heavy swap-file useage too. Although the cpu will also frequently see upwards of 90% utilisation.

Options

1: Upgrade to a Pi 4/5

This would seem the simplest option, keeping everything more or less exactly how it was in terms of management, config etc. I might even be able to simply pop the SD-Card out of the Pi 3 and place it straight into the new unit, minimising friction and downtime to redeploy. More RAM (up to 8GB or 16GB for Pi 5), faster cores, USB 3.0 data transfer and even USB-C PD input.

So why not go this way?

When I initally setup Home Assistant, it was as a very simple small way to control a couple of IoT devices over LAN without depending on a manufacturer cloud service. Think turning smart bulbs on/off, scheduling actions for time of day. Since then my use grew including hosting additional services on the Pi like Wireguard, a Matter server, MQTT broker, intermediary synthing relay machine, Tailscale and more. Now I also somewhat have the desire to gain a bit more fine grained control over the services running in my home lab.

Additionally this would involve purchasing new hardware, which I am heasitant to do when I already have alternatives on hand.

2: Proxmox (VM)

An interesting alternative would be to still run HAOS as a VM instead. Running in a VM would fix my performance issues and provide greater portability to change the underlying hardware further in future.

For this something like Proxmox would be particularly appealing. A type-1 hypervisor, with support for Linux Containers (LXC)

I do not think I am ready to manage a proxmox install for this purpose, although I’m still interested to learn it to add as another tool.

3: Pure Docker Containers

It is made very clear that this is not a way that Home Assitant intends most users to run their system. Very much considered the extra for experts option and ultimately your own responsibiltiy to troubleshoot and support (although there are some in the community who run Home Assistant this way and can lend a hand).

While this would mean losing some of the nice QoL features HAOS provides (the addons system & automatic updates),

This method appeals with how the vast majority of my other services are configured using compose yaml files and deployed with docker compose. So would blend perfectly with my other current setups. Home Assistant addons could just be replaced with their standard docker image releases.

Comparision Matrix

🛈 NOTE: This matrix highlights the trade-offs between options based on some of the factors that are most important to me, rather than a direct comparison

Feature/Consideration HAOS SBC Proxmox VM Docker
Addon support
Automatic updates
Power consumption 🟩 🟨 - 1 🟨 - 1
Flexibility 🟥 Low 🟨 Med-High 🟩 High
Setup complexity 🟩 Low 🟥 High 🟨 Medium
Maintainance 🟩 Low 🟧 Med-High 🟨 Medium
Deployment control 🟥 Low 🟩 High 🟩 High
Future proofing ease Average Good Good
🔲 🔲

Conclusion

Selected Solution: Docker

I can always switch back to a HAOS based solution later on if I so desire. Using compose files, with docker, will give me the required performance and more control in a format that I am already reasonably comfortable managing.

This also highlights the need for me to look into better methods to monitor for base image updates, as the number of containers I manage grows further. Whether this transitions into full kubernetes or something else will require additional research.


  1. Power consumption really not considered here as although higher, the machine(s) are already running along with other services. ↩︎ ↩︎