Overview
I bought a Raspberry Pi 4 for Home Assistant, followed the official install guide, had it running in twenty minutes, and then spent three weekends getting it to do things that were actually useful. The install is the easy part. This is the part nobody writes up.
What follows is what I'd tell a friend who was thinking about doing this.
Is the Pi actually the right hardware?
The honest answer depends on how many devices you're going to connect. The Pi 4 with 4GB is fine for a few dozen entities. Above that, you'll notice the UI getting sluggish, automations firing late, and the SD card dying every six months. The Pi 5 with 8GB is better. So is any used mini PC — an Intel N100 box costs about the same as a Pi 5 with case, PSU, and storage, has an SSD, and is roughly five times faster.
| Setup | Typical cost | Good for |
|---|---|---|
| Pi 4, 4GB, SD card | ~$75 | <30 devices, experiments |
| Pi 5, 8GB, NVMe | ~$150 | <100 devices |
| N100 mini PC, 16GB, SSD | ~$180 | <300 devices, addons |
| Old laptop | Free | Anything, with a battery backup |
SD cards are the single biggest reliability problem with the Pi route. I've had three fail in two years. If you go with a Pi, use NVMe via a HAT or a good USB SSD, not an SD card. It's $40 and it's the difference between "runs for years" and "surprise reboot on a Tuesday."
Install method: HAOS, not Docker
Three options for installing Home Assistant:
- Home Assistant OS (HAOS) — the whole OS is dedicated to HA. Supervised addons work. Updates are managed.
- Supervised — HA on top of Debian. Same addon support, more control, more ways to break it.
- Container — just the HA process in Docker. No addons, no Supervisor. Simplest, most limited.
Start with HAOS. If you've already got a Proxmox host and know what you're doing, a VM running HAOS is a good middle ground. The container install is fine if you're confident you won't want addons — but you will want addons.
The first three things to configure
- Set a static IP on the HAOS device itself, not just a DHCP reservation. Some integrations get confused if the IP changes.
- Enable automatic backups to a network share or Google Drive. The defaults back up to the local disk, which doesn't help if the disk dies.
- Set up HTTPS with the Let's Encrypt addon. You need it for voice assistants, and you need it if you ever want to access HA from outside your home.
Skip Nabu Casa unless you specifically want the cloud voice features. The local-only setup works fine and there's no subscription.
Integrations that actually matter
The first-run experience is a wizard that finds devices on your network. It'll find Hue bridges and Chromecasts. It won't find your Zigbee devices or your custom ESPHome boards, because those need a coordinator or manual configuration.
What I'd prioritize:
| Integration | Why |
|---|---|
| Zigbee2MQTT or ZHA | Local Zigbee control without the manufacturer's cloud |
| ESPHome | Flash cheap ESP32/ESP8266 boards with your own firmware |
| Matter | Now mature enough for new devices |
| Mobile app | Gives you device tracking and notifications for free |
Zigbee2MQTT is the one I'd recommend over ZHA, despite it being more setup. It's more compatible, easier to debug, and doesn't lose devices when you move the coordinator to a different USB port.
The first automation that saves real time
Don't start with lights. Start with something annoying you do manually every day. For me it was remembering to check that all doors were closed before leaving. That became a notification when the household goes "away" and a door is open.
trigger:
- platform: state
entity_id: person.me
to: "not_home"
condition:
- condition: state
entity_id: binary_sensor.front_door
state: "on"
action:
- service: notify.mobile_app_my_phone
data:
message: "Front door is still open"
That's it. No complex logic, no templating. The value is the message arrives while you're still close enough to turn around.
Automations: the three things I got wrong
Don't use "or" conditions casually
An automation that fires when "time is 7pm OR motion detected in kitchen" will fire every time someone walks into the kitchen in the evening, not just at 7pm. I spent an hour once trying to figure out why my kitchen lights kept turning on when I got water at night.
Use "for" to avoid flapping
A motion sensor that's technically on for 200ms because of a passing car will trigger the automation. Adding a duration prevents this:
trigger:
- platform: state
entity_id: binary_sensor.driveway_motion
to: "on"
for:
seconds: 5
Test in Developer Tools before saving
Automations that seem correct often aren't, and the debug cycle is slow. Use the Developer Tools → Template editor and Template tab to test conditions and templates inline. Faster than watching logs.
Where it stops being fun
Two things consistently cause people to give up. The first is Zigbee range. Your coordinator is in one corner of the house and the sensor is three walls away, and nothing works until you add a repeating device (a plugged-in light or smart outlet) between them. Buy a few more repeaters than you think you need.
The second is updates. HA releases a new version every month, and occasionally one breaks an integration. I've learned to read the release notes and wait a week before updating. Backups before every update, no exceptions.
Is it worth it?
If you have more than three smart devices from more than one manufacturer, yes. The value of HA isn't that it does anything you couldn't do with the individual apps. It's that it lets you write rules across manufacturers — "if the door opens and it's after sunset and nobody's home, turn on the hallway light and send a notification" — and none of the vendor apps will ever let you do that.
If you have two Hue bulbs and a thermostat, HA is more work than it's worth. Come back when you have a problem it solves.
