Design the smart home to work when AI is down
If a chatbot has to finish a sentence before your front door unlocks, you've already lost the argument. Quick qualifier: I'm not against AI in the smart home, only against putting it anywhere load-bearing. A house running natural-language control alongside ordinary automations is fine. A Raspberry Pi or Orange Pi near the sensors, running a small model locally, ranking notifications or answering a thermostat question, earns its keep. The board matters less than the appliance around it: storage, power, cooling, the OS, whatever accelerator the job needs, and the service that actually consumes the output.
Write the job down before you buy the board
Write the job in four lines: event, input, output, deadline. "Add AI to the camera" isn't a job, it's a wish. "When a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" is a job, because you can test it and tell when it fails. That precision also shows which parts never needed a model. Then do what almost nobody does: stop inference on purpose and watch what the house does. Keep the physical switches, and settle the no-model behavior first. Test against your actual room: the real microphone, camera angle, sensor, language, the Wi-Fi that actually drops. Evening light changes everything, so does a television in the background, none of it shows up in a benchmark number. Keep a plain log: board, OS, power supply, model and runtime version, real inputs against expected action, latency cold and warm, memory, temperature, wall power, and every false or missed action with recovery.
The lock doesn't get a vote
Generative output is good at interpreting a fuzzy request or ranking a handful of options. It's a bad last line of defense for a lock, heater, alarm, valve, or person. Put ranges, permissions, timeouts, confirmations, and device interlocks in deterministic code a model never touches. Treat camera captions, calendar entries, scraped webpages, MQTT payloads, and voice transcripts as data to be checked, not instructions to be obeyed.
A model can rank your options. It should never be the last check between a voice command and a door.
Privacy needs the same treatment, followed through. Local inference stops one upload, but recordings, logs, thumbnails, backups, and a remote dashboard can still leave copies of the same moment. Decide what gets collected, how long it stays, who can reach it, and what gets logged when you're debugging with verbosity turned up. The most private frame is the one the camera never captures. The next best is the one thrown away after the decision.
Plan for the version of you that forgot how this works
Run it under a real service manager or a pinned container, not a terminal window left open. Keep configuration separate from the model files. Add a health check that proves the actual function, light comes on, door reports locked, not just that a process holds a port. Back up the controller state, record the model hashes, and keep a known-good storage image for any board installed somewhere hard to reach. Power and heat belong in the acceptance test: run long enough for the enclosure to reach a steady temperature, and measure at the wall with peripherals attached. If it throttles, swaps, corrupts the SD card, or hogs the home-automation host, it isn't finished, whatever the demo looked like. That's resilient AI architecture scaled down to a board that costs less than dinner. The rule that holds: losing the model should make the house less convenient, never less safe or less functional. Edge AI is a narrow layer above reliable sensors and below a household policy you could explain out loud. When the model can't be reached, the house should get dumber, not go dark.
None of this is free. The boring, testable, fallback-safe version of a feature usually takes longer to build than the flashy demo that got you excited about the board, and I'd be lying if I said I always finish the deterministic scaffolding before losing interest and wandering off to the next board.