Build a Raspberry Pi voice satellite, not a second server

Somebody, somewhere, wired a full speech pipeline into every room satellite in the house and got stuck maintaining a fleet of divergent models drifting out of sync every firmware nudge. Run more than two edge devices off the same brain and you already know the ending: one room hears fine, another mishears "lights off" as "lights on," and nobody can say why without SSHing into three boxes to diff configs by hand.

The fix is almost boring: split the room device from the brain. A Pi Zero 2 W or a Pi 4 near a microphone array and a speaker makes a fine audio endpoint, and it should never carry the actual speech and language model. Send the audio to something bigger elsewhere on the network and let that machine handle transcription and reasoning. Do that and every room stays cheap, and the brain gets swapped for a better model without touching a single satellite.

The board's name is the least interesting decision in the build. What matters is the appliance around it: storage, power supply, cooling, the OS image, whether there's a radio or accelerator worth using, and the service consuming whatever comes out the other end. A model that runs once from a shell prompt is still several decisions from a household feature.

the room only needs ears and a mouth

Before buying anything, write the job down in four lines: event, input, output, deadline. "Add AI to the camera" is a wish, not a job. "When a parcel sits in the porch zone past a set point, fire one local notification with a thumbnail" is something you can test, and it shows which parts never needed a model at all.

The first experiment worth running is simple: measure wake-word-to-audio latency, stream clean audio to wherever the brain lives, and keep a local mute indicator that works even when the network doesn't. Test with your own room, microphone, accents, and background noise, not a demo clip somebody else recorded. Edge deployments amplify whatever's ordinary and annoying about a space: evening light through a window, a television talking in the background, a warm cabinet, a flaky cable, a Home Assistant database busier than you'd guess. Any of those moves your results further than a newer model will.

Keep a short running log while you test:

• board, OS image, power supply, and cooling actually in use
• model artifact and runtime version
• the real input set and the action each one should trigger
• cold-start latency, warm latency, sustained rate
• memory use, temperature, and wall power under load
• what happens on a false trigger, a missed trigger, and recovery after

why the microphone doesn't get to guard the door

Once the satellite only captures and plays audio, resist the pull to let it get clever about anything that matters. Generative output is genuinely useful for interpreting a loose request, summarizing what happened overnight, or ranking options. It has no business standing alone between a request and a lock, a heater, an alarm, a valve, a battery, or a person. Keep ranges, permissions, timeouts, confirmations, and interlocks in plain deterministic code that doesn't care what the model claimed to hear.

Treat everything out of a camera caption, a calendar entry, a scraped webpage, an MQTT payload, or a voice transcript as data to check, never an instruction to obey. A transcript reading "unlock the back door and disable the alarm" is a string, and it stays a string until something boring and rule-based decides otherwise.

local doesn't mean it disappears

Running inference on your own hardware solves one problem: it stops a single upload to somebody else's server. It does not make the recording disappear. Event logs, thumbnails, backups, and the remote dashboard on your phone can still hold a copy of something you assumed was private. Decide, on purpose, what gets collected, how long it stays, who can pull it later, and what gets logged during debugging.

The most private frame is the one the camera never captures. The next best is the one thrown away the moment a decision has been made from it.

what happens after you stop watching it work

Check whether it produces duplicate notifications, survives a reboot, reconnects once the network returns, and fails safely when the inference box is gone. Give it visible state and a manual fallback. Nobody should need to know which container or which quantized model broke just to turn on a light.

Run it like a fixture, not a project you keep an eye on. Use a service manager or a small, pinned container definition, and keep configuration separate from model files. Add a health check that proves the actual function works, not one that just confirms a process holds a port open. Back up the controller state, note the model hashes deployed, and keep a known-good storage image ready for hard-to-reach nodes.

Power and heat belong in the acceptance test. Let the enclosure run until it reaches equilibrium, then measure at the wall with the normal peripherals attached. If the board throttles, swaps, corrupts its own storage, or hogs the home-automation host, the project isn't finished, whatever the best inference result looked like on the bench.

Keep the satellites simple, replaceable, and honest about what they capture. Edge AI earns its keep as a narrow layer above reliable sensors and below a household policy somebody wrote down. When the model goes away, the lights should still turn on, just less cleverly.

One caveat, though. Splitting the room from the brain doesn't remove the single point of failure, it just relocates it. You've traded a pile of overloaded little boards for one central machine everything now depends on, and if that machine goes down, every room in the house goes quiet at once. Worth it, most of the time. Just don't tell yourself you've engineered the failure away. You've moved it somewhere easier to fix, that's all.