Back up the smart-home AI stack in layers

A Raspberry Pi (or an Orange Pi, the board doesn't matter much) running Home Assistant, MQTT, a downloaded model, and a vector index for search looks like a single appliance right up until the SD card dies, and then you find out, the hard way, which of those pieces you actually needed to keep.

Some of what's on that board is irreplaceable: the Home Assistant configuration, the automations tuned over months, the entity registry, the MQTT topic map, whatever state actually describes your house. Some of it is just bulk you downloaded once and can download again: the model weights, the camera ring buffer, the vector index built from your file library. Treat those two categories the same in a backup plan and you end up paying to store gigabytes of re-fetchable model files forever, or worse, losing the few kilobytes of YAML that made the house actually work.

Sort what's precious from what's just heavy

Start by writing the job down in four lines: event, input, output, deadline. 'Add AI to the camera' is not a job. It's a wish. 'When a parcel sits in the porch zone for twenty seconds, fire one local notification with a thumbnail' is a job, and it's testable. It also tells you immediately which parts of the stack need protecting and which don't: the notification rule and the porch-zone definition are precious, the object-detection model underneath it is not.

Once the job is written down, the first real backup work isn't a script that tars up the whole SD card. It's encrypted configuration backups with export manifests, rehearsed onto spare storage before you actually need them. A backup you've never restored is a hope, not a plan. Boot the spare card, confirm Home Assistant comes up with the right automations and the right entities, and only then trust the process.

Test that restore with data from the actual room: the real camera angle, the real microphone, the real network, the real language your household speaks. Edge deployments amplify variation that a lab test hides: evening light, a television talking in the background, a warm equipment cabinet, a flaky USB cable, a Home Assistant database that's gotten large and slow, any of these can move the result more than swapping model versions does.

Keep a short field record next to the config, not buried in your head:

board / OS / power supply / cooling
model artifact and runtime version
real input set and expected action
cold latency, warm latency, sustained rate
memory, temperature, wall power
false action, missed action, recovery path

For a job that runs constantly in someone's house, accuracy is the least interesting number on that list. What matters is whether the system throws duplicate notifications, comes back cleanly after a reboot, reconnects once the network returns, and fails safely when the inference container is down. If a feature is used by anyone else in the household, it needs a state a normal person can see and a manual fallback that doesn't require knowing which container is unhealthy.

The model doesn't get anywhere near the lock or the heater

The failure I see most often is someone who has copied terabytes of storage image around and never once proven the controller can actually boot from the backup. Restoring successfully is a different claim from having files somewhere.

A model can interpret a request, summarize an event log, rank a few options. It should never be the only thing standing between a person and a lock, a heater, an alarm, a valve, or a battery charger. Put ranges, permissions, timeouts, confirmations, and hard device interlocks in ordinary deterministic code, not in a prompt. That's the same logic behind treating output validation as a guardrail rather than a suggestion: anything that reaches the model is data, not instruction, whether it arrives as:

• camera OCR text
• calendar entries
• scraped webpages
• MQTT payloads
• voice transcripts

None of that is trustworthy just because it arrived over your own network.

Privacy needs the same full-path thinking as safety. Running inference locally stops one upload to a vendor, but the recordings, the event logs, the thumbnails, the backups, and any remote dashboard you've bolted on can all still leave copies of your house sitting somewhere. Decide, in writing, what gets collected, how long it lives, who can pull it, and what happens to it when you're debugging at midnight with a laptop open. The most private frame is the one the camera never captures in the first place. The next best is the one discarded a second after the bounded decision gets made.

Run it as an appliance, not a demo you half-remember how to restart. Use a service manager or a small, pinned container definition, keep configuration well away from the replaceable model files, and add a health check that proves the actual function rather than just that some process is squatting on a port. Back up controller state, export the model hashes you're depending on, and keep one known-good storage image for any node installed somewhere annoying to reach.

Power and heat belong in the same acceptance test, not a separate one you skip when you're tired. Let the enclosure reach its real equilibrium temperature, measure at the wall with the normal peripherals plugged in, and if the board throttles, starts swapping, corrupts storage, or quietly monopolizes the home-automation host doing something else, the setup isn't done, whatever the best single inference result looked like.

The rule that's actually held up: optimize recovery time, and verify the small set of things that are genuinely critical rather than the whole disk image. Edge AI earns its place as a narrow layer sitting above reliable sensors and below a household policy someone actually wrote down, which is most of what makes an edge deployment resilient instead of merely working on the bench. When the model goes away, the automation underneath it should get dumber, not stop.

What I still haven't found a clean answer for is the multi-board household: three or four of these SBCs scattered around the house, each with its own config-versus-cache split, and no single restore drill that covers all of them at once without turning into its own maintenance project.