Most smart-home automations do not need an LLM
Skip the model. For most smart-home automations, a plain state machine or a cron schedule beats an LLM outright: cheaper, faster to react, fails in ways you can predict. The qualifier: there's a real band of jobs built on ambiguous or unstructured input where a model earns its keep, and pretending that band doesn't exist is its own kind of bad advice.
Small-board AI attracts two opposite mistakes: one camp treats a Raspberry Pi like a miniature gaming PC, the other sneers at anything short of a frontier model, and both miss the useful middle: bounded jobs near the sensor, no cloud account, little power. Language models add value at ambiguity and unstructured input, not at ordinary boolean logic, which is what most of a house runs on.
Draft the job in four lines before you shop for silicon
Write the event, the input, the output, the deadline, four lines. "Add AI to the camera" isn't a job description; "when a parcel sits in the porch zone for a fixed number of seconds, generate one local notification with a thumbnail" is. Write the deterministic rule first, then find the one judgment call it can't make: that narrow gap, not the whole pipeline, is where inference belongs. Test with the real room, the actual camera angle, the network, evening light, because edge deployments amplify ordinary variation more than any model revision does. Keep a field record: board, OS, power, cooling; model and runtime version; real inputs against expected action; cold and warm latency; memory, temperature, wall power; what a false action costs against a missed one, and how it recovers. Accuracy alone won't settle it. What matters is whether it survives a reboot, reconnects when the router blinks, and does something sane when the inference service isn't there.
Keep the model on the wrong side of the safety line
The common failure: someone swaps a ten-line automation for a prompt, and the lock or the heater depends on wording that behaves differently every time the model updates upstream. Generative output is fine for interpreting a loose request or ranking a few options. It has no business being the only thing standing between a mistake and a lock, a heater, an alarm, a valve, a battery, or a person. Ranges, permissions, timeouts, confirmations, interlocks: keep all of that in deterministic code. Treat anything the model reads, camera captions, calendar entries, MQTT payloads, voice transcripts, as data, never as instructions.
Privacy needs the same full-path thinking. Local inference stops one upload, but the recording, the log, the thumbnail, the backup you forgot, any of those can leave a copy the model never touched. Decide up front what gets kept and for how long. Then run it like an appliance, not a demo: a pinned service, config apart from the model file, a health check that proves real function, not just a process holding a port. Run it to thermal equilibrium and measure power at the wall: a board that throttles or corrupts storage isn't ready, whatever its best run looked like.
Reach for the model only where the requirement is uncertainty, not everywhere the budget happens to allow it.
That's the rule I work by: when the model goes away, the automation should get dumber, not stop. I'll admit the four-line exercise gets tedious by the fifteenth sensor, and there's a pull to just point a camera at a model and skip the write-it-down step, especially for automations nobody but you will watch fail.