Running Your Smart Home on a Single Board Computer: A Field Engineer's Take

I've lost count of how many Raspberry Pis are scattered around my house. Some
are doing real work, a couple are gathering dust in a drawer, and one has been
quietly logging my furnace runtime for the better part of three years without a
single reboot. That last one is the whole point of this article. Embedded single
board computers (SBCs) have quietly become the backbone of a lot of serious home
automation setups, and not because they're trendy. They just hit a sweet spot
that the big cloud platforms and the cheap proprietary hubs both miss.

Why bother with an SBC at all

The pitch from commercial smart home ecosystems is convenience. You buy the hub,
you scan a QR code, and your lights talk to your phone. That works right up until
the vendor sunsets the product, raises a subscription fee, or has an outage that
takes your front door lock offline. I've watched all three happen to people I
know.

An SBC flips the relationship. You own the brain. The processing happens on a
board sitting in your utility closet, not in a datacenter three states away. That
means your automations keep firing when your internet is down, your sensor data
never leaves the house unless you decide it should, and nobody can brick your
setup with a bad firmware push.

There's a latency angle too that people underrate. A motion-triggered light that
round-trips to the cloud and back can take 800ms to a second and a half. The same
rule running locally on an SBC fires in under 100ms, often closer to 30. You feel
the difference. It's the gap between a light that anticipates you and one that
catches up to you.

Picking a board without overthinking it

The market is genuinely crowded now, which is good for prices and bad for
decision paralysis. Here's how I actually sort them out:

Board	RAM options	Storage	Best fit	Rough watt draw
Raspberry Pi 5	4 / 8 / 16GB	microSD, NVMe	General hub, large Zigbee networks	5-8W
Raspberry Pi Zero 2	512MB	microSD	Single-purpose sensor node	1-2W
Orange Pi 5	4-32GB	eMMC, NVMe	Local video, heavier processing	6-10W
Radxa Rock 5B	4-16GB	eMMC, NVMe	Performance per dollar	6-9W
Le Potato (AML-S905X)	1-2GB	microSD	Cheap, low-stakes deployments	2-4W

My honest default for most people is still a Pi 5 with 8GB and an NVMe drive. Not
because it's the fastest or cheapest, but because the software support is so deep
that you'll almost never be the first person to hit a given problem. When
something breaks at 11pm, you want a forum thread waiting for you, not silence.

If you're building a dedicated sensor that does one tiny thing, drop to a Pi Zero
2 or an ESP32 and stop overspending. There's no prize for running Home Assistant
on a board that only needs to read a temperature probe.

The software stack that actually holds up

I've tried a lot of combinations. The one I keep coming back to is Home Assistant
running in a container, with an MQTT broker handling device chatter, and a Zigbee
coordinator plugged in over USB. It's not the only valid setup, but it's the one
that has survived contact with reality.

A minimal docker-compose for the core looks roughly like this. Note the indented
formatting since I'm avoiding fenced blocks here:

version: "3"
services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    volumes:
      - ./ha-config:/config
      - /etc/localtime:/etc/localtime:ro
    network_mode: host
    restart: unless-stopped
  mosquitto:
    image: eclipse-mosquitto:2
    volumes:
      - ./mosquitto:/mosquitto/config
    ports:
      - "1883:1883"
    restart: unless-stopped

The network_mode: host line matters more than it looks. Home Assistant's device
discovery leans on mDNS and broadcast traffic, and bridging it into a container
network breaks half of that silently. I burned an entire Saturday on this before
I understood why my Chromecasts kept vanishing.

For Zigbee, I run zigbee2mqtt rather than the bundled ZHA integration. Opinions
differ here and ZHA has gotten much better, but zigbee2mqtt's device support
catalog is enormous and it decouples the radio from any one home automation
platform. If I ever migrate off Home Assistant, my Zigbee mesh comes with me.

The unglamorous problems nobody warns you about

This is the part most tutorials skip, and it's where deployments actually die.

SD card death. microSD cards were never designed for the constant small
writes a logging system produces. A database that flushes every few seconds will
chew through a consumer card in months. I've replaced more dead cards than I'd
like to admit. The fix is straightforward: boot from an SSD or NVMe drive, or at
minimum move your database and logs off the card. On a Pi 5 with native PCIe this
is trivial now. On older boards you boot from USB.

You can check write wear indirectly by watching how much your storage is being
hammered:

iostat -dx 5

If your root device is showing sustained writes when nothing should be happening,
something is logging too aggressively. Track it down before it kills the card.

Thermal throttling. These boards run hot under load, especially the
RK3588-based ones. A Pi 5 without a heatsink will throttle, and a throttled board
makes automations feel sluggish in ways that are maddening to diagnose because
nothing actually errors out. Check it directly:

vcgencmd measure_temp
vcgencmd get_throttled

A non-zero throttled value means you've already hit limits at some point. Spend
the eight dollars on an active cooler. It pays for itself in sanity.

Power supply quality. Undervoltage is the silent killer. A flaky USB-C
brick that sags under load causes random reboots, corrupted writes, and Wi-Fi
dropouts that you'll spend days blaming on software. Use the official supply or a
known-good one rated above your peak draw. This is the single most common cause
of "my Pi is unstable" complaints I see.

Security, because it's in your house

The moment your SBC touches devices that matter (locks, cameras, garage doors)
you have to take this seriously. A few non-negotiables from my own setup:

Practice	Why it matters
Separate IoT VLAN	Contains a compromised gadget to one network slice
No port forwarding	Use a VPN like WireGuard for remote access instead
Automatic security updates	Unpatched SBCs are low-effort targets
SSH keys, not passwords	Brute force is constant on anything exposed
Local-only cloud bypass	Cut devices off from vendor servers where you can

The VLAN point deserves emphasis. Most consumer IoT firmware is mediocre at best,
and you should assume any given smart plug could be a foothold. Putting them on
an isolated network segment means a compromised bulb can't pivot to your laptop.
Your SBC straddles both networks deliberately and acts as the controlled bridge.

For remote access, resist the urge to forward a port to your dashboard. Stand up
WireGuard instead. A minimal peer config is tiny:

[Interface]
PrivateKey = <your-key>
Address = 10.0.0.2/24

[Peer]
PublicKey = <server-key>
Endpoint = home.example.com:51820
AllowedIPs = 10.0.0.0/24

Now your phone tunnels into the home network and reaches the dashboard as if it
were local. Nothing's exposed to the open internet.

Is it worth the effort

Honestly, it depends on your tolerance for tinkering. If you want lights you
never think about and you're fine renting that convenience from a vendor, buy the
polished commercial hub and don't look back. There's no shame in it.

But if you've ever been annoyed by an automation that broke because a server you
don't control had a bad day, an SBC-based setup is liberating. The upfront cost
is real (a few hours of reading and a hundred-ish dollars in hardware) but the
payoff is a system that does exactly what you told it to, keeps running when the
internet doesn't, and answers to nobody but you.

That furnace logger I mentioned at the top has paid for itself ten times over in
catching a failing igniter before it left us cold in January. No subscription, no
cloud, no permission needed. Just a small board doing its quiet job in the dark.