Raspberry Pi: install Home Assistant the right way, with backups and automations

Home Assistant is the open-source home automation platform that ties together every smart device in your house: lights, sensors, switches, thermostats, vacuums, sprinklers, the garage door. It runs on a Raspberry Pi, integrates with everything from Philips Hue to MQTT to ESPHome, and has a real automation engine.

The install has three flavors (OS, Supervised, Container) and people argue about which is right. This tutorial picks one (OS), walks through the install, and covers the parts most people get wrong (the backup, the YAML automation, the device-discovery magic).

What you need

Raspberry Pi 4 (2 GB minimum, 4 GB recommended) or Pi 5
A microSD card (32 GB or larger, A1 rated) or, better, a USB SSD
An ethernet connection (Wi-Fi works on the Pi for setup, ethernet is more reliable long-term)
About 30 minutes for the install, plus 15 minutes for the initial wizard

Home Assistant OS vs Supervised vs Container

There are three install flavors:

Home Assistant OS is a minimal Linux distribution whose only job is to run Home Assistant. The supervisor manages add-ons, updates, and backups. This is the recommended path for a Pi.
Home Assistant Supervised is Home Assistant running on top of your own Debian install. You get a supervisor, but you also have to maintain the OS. It is the most fragile option.
Home Assistant Container is Home Assistant in a Docker container. You do not get a supervisor, add-ons, or the built-in backup tool. It is the right pick if you already have a Docker host and you know what you are doing.

For a Pi that is dedicated to home automation, Home Assistant OS is the right choice. It is the path with the least ongoing maintenance.

Install Home Assistant OS

The official installer is at https://www.home-assistant.io/installation/raspberrypi.

The flow:

Download the Raspberry Pi Imager (the same one you use for Raspberry Pi OS).
Choose OS >> Other specific-purpose OS >> Home assistants and home automation >> Home Assistant OS.
Choose your storage (the SD card or USB SSD).
Optionally configure Wi-Fi and SSH through the imager’s “edit settings” menu. (Ethernet is simpler if you have it.)
Write the image.

Boot the Pi. Wait about 20 minutes for the initial setup. The Pi will appear on your network as homeassistant.local.

From a browser on the same network, go to http://homeassistant.local:8123. The initial setup wizard starts.

The initial setup wizard

The wizard asks for:

Username and password. This is the admin account. Pick a strong password; it is the front door to your house.
Name of your home. Shown in the UI and used in automations (person.brian is one example).
Location. Used for sunrise/sunset automations and weather.
Privacy. Whether to share anonymous usage data with the Home Assistant project. I share.
Devices found on the network. The wizard scans for compatible devices and offers to set them up. This is the device-discovery magic (more on this below).

When the wizard finishes, you are in the default “Overview” dashboard. It is mostly empty. The next step is adding integrations.

The integrations

An integration is a driver for a specific device or service. The popular ones:

MQTT for talking to ESP32 sensors, Node-RED, and other home-grown things. Requires a separate MQTT broker (Mosquitto is the standard pick; the add-on is a one-click install).
ESPHome for ESP32 devices flashed with ESPHome firmware. The integration auto-discovers them on the network.
Philips Hue for Hue lights and accessories. The integration finds the Hue bridge automatically.
TP-Link Kasa, Shelly, Z-Wave JS, Zigbee Home Automation, Google Cast, Apple TV, Sonos - the list is long. Most of them auto-discover on the local network.

To add an integration: Settings >> Devices & Services >> Add Integration >> search for the name. The flow is the same for all of them.

The MQTT and ESPHome integrations are the two I add first on every fresh install. The rest depend on the devices you have.

The automations editor (the GUI)

Settings >> Automations & Scenes >> Create Automation. The editor is a drag-and-drop flow:

Trigger: what starts the automation. Time of day, device state, MQTT message, webhook call.
Condition (optional): an extra check before running. “Only if someone is home,” “only if it’s dark outside.”
Action: what to do. Turn on a light, send a notification, call a service.

Example: turn on a light at sunset.

Trigger: Sun >> Sunset
Action: Light: Turn on light.living_room

That’s it. The automation runs every day at sunset.

The GUI editor is the right tool for 80% of automations. For the other 20%, the YAML editor is more powerful.

The YAML automation (for complex rules)

The same automation in YAML:

alias: "Living room light at sunset"
trigger:
  - platform: sun
    event: sunset
    offset: "-00:30:00"   # 30 minutes before sunset
action:
  - service: light.turn_on
    target:
      entity_id: light.living_room
    data:
      brightness_pct: 80
      color_temp_kelvin: 2700

The YAML version lets you do things the GUI cannot, like offsets on the trigger, complex conditions, and parallel actions. The downside: a typo breaks the automation, and the error message is sometimes cryptic.

The rule: use the GUI for simple stuff, the YAML for complex stuff, and do not be afraid to switch back and forth.

The device-discovery magic (mDNS)

When you add an integration, Home Assistant scans your local network for compatible devices using mDNS (multicast DNS, also known as Bonjour). This is why your Hue bridge, your ESPHome devices, and your Sonos speakers show up automatically.

The trade-off: mDNS only works on the local network. If you access Home Assistant over a VPN or a remote proxy, device discovery does not work (the mDNS packets are not routed). The devices that were already added keep working; only new device discovery is affected.

If you have a complex network (multiple VLANs, multiple subnets), the mDNS reflector is the fix. It is a small service that forwards mDNS between subnets.

The “I bricked my install” recovery section

Home Assistant is a full OS, and full OS installs can break. Common breakages:

A bad update that crashes on boot.
A misconfigured YAML that prevents Home Assistant from starting.
An SD card that has had too many write cycles.

The fix is a backup. The good news: Home Assistant has a built-in backup tool.

Settings >> System >> Backups >> Create Backup. Pick what to include (the full Home Assistant config, the add-ons, the automation history). The backup saves to a local file or to a cloud provider (Google Drive, Dropbox, etc.).

The rule: take a backup before every update, and especially before any time you edit YAML or add a new integration. Restoring from a backup is much faster than rebuilding from scratch.

If the install is bricked, the recovery flow is:

Remove the SD card or SSD from the Pi.
Mount it on a laptop with a card reader.
Find the backups directory.
Copy the most recent backup to a safe place.
Reflash the SD card with Home Assistant OS.
Boot, run through the wizard.
Restore the backup. Most of your config comes back, including integrations, automations, and add-ons.

The add-ons may need to be reinstalled if the OS version changed. The devices need to be reachable again (they were not stored in the backup, just their config in Home Assistant).

Home Assistant vs Node-RED

Node-RED is the other home automation tool people compare to Home Assistant. Both are real options.

Home Assistant wins on:

Out-of-the-box integrations. Hundreds of devices have native integrations, with auto-discovery and a UI.
The automation engine. The trigger/condition/action model is built in, no flow editor required.
The community. A huge ecosystem of add-ons, custom integrations, and forum answers.

Node-RED wins on:

Flexibility. The flow editor handles complex logic (loops, conditionals, parallel branches) more naturally than Home Assistant automations.
Language-agnostic processing. JavaScript, Python, and shell snippets can be embedded in a flow.
Integration with non-home-automation tools. Node-RED is a general-purpose flow engine; it integrates with databases, web APIs, and message brokers without add-ons.

The rule: Home Assistant is the right tool for “smart home automation.” Node-RED is the right tool for “data flow automation” where the data happens to be in a smart home.

A lot of people run both. Home Assistant for the integrations and the UI, Node-RED for the complex automations, with Home Assistant calling Node-RED flows via the rest_command integration.

What you learned

Home Assistant OS is the recommended install path on a Pi.
Integrations connect Home Assistant to devices. Most are auto-discovered.
The GUI automations cover 80% of cases. The YAML automations cover the other 20%.
Backups before every update, and especially before any config edit.

When something breaks

Home Assistant will not boot. A bad YAML or a failed update. Boot from the SD card on a laptop, fix the YAML, or reflash and restore from backup.

The integrations page shows “failed to set up.” The device is unreachable. Check the network (same subnet, no firewall blocking the mDNS port). Restart the integration.

The automation does not run. The trigger is wrong, or the condition is filtering it out. The Traces tab (in the automation detail view) shows the history and the reason each run did or did not fire.

The UI is slow. Too many devices, or a too-small Pi. Move to a Pi 4 with 4 GB or a Pi 5.

The SD card is corrupted. Replacements are cheap. Reflash and restore from backup. The lesson: backups.

What to build next

A “good morning” automation that turns on lights, starts the coffee maker (via a smart plug), and reads the weather.
A presence detection setup that knows who is home and adjusts the climate accordingly.
A dashboard for a wall-mounted tablet.
An alarm panel that arms when everyone leaves and disarms when someone arrives.

The presence detection setup is the most useful for a household. The wall-mounted dashboard is the most fun to build.