Let an LLM summarize the dashboard, not run it

So no, I'm not letting the model near the lock. That line doesn't move. What it can do is read the boring stuff, motion events, door contacts, thermostat cycles, whatever Home Assistant logged overnight, and hand me three sentences over coffee. A model that writes a briefing is a far smaller risk than one with opinions about your front door, and treating those as the same problem is where these projects usually go sideways.

The board underneath barely matters. What matters is the appliance around it: storage, power supply, cooling, an OS you can rebuild from an image, and the service that reads the model's output. A script that runs once from a shell prompt is nowhere near a household feature.

Write the job down before you touch a GPU

Four lines: trigger, input, output, deadline. "Summarize the night" isn't a job. "When the porch camera logs three unlabeled motion events between midnight and six, produce one paragraph with times and a confidence note" is, and writing it that way shows you half of it needs no model at all. Aggregate the deterministic facts in code first, counts, timestamps, zone names, redact anything sensitive, then ask the model only for the exceptions and the evidence behind them, never the raw feed. Test against your actual room, camera angle, and network, because evening light, a television left on, a warm cabinet, or a Home Assistant database that's grown fat over time will move the output more than a model swap ever will. Track what changed and what happened: hardware, model and runtime version, cold and warm latency, memory and temperature, and what the system does when it's wrong. A briefing that duplicates itself after a reboot or goes silent when the container dies isn't finished. It needs visible state and a manual fallback, because nobody should have to know which container is unhealthy to learn if the garage door was left open.

The narration layer doesn't get a vote on the hardware

The failure I see most is someone dumping the whole event history into context and getting back a vague, confident paragraph about a quiet night. Generative output is fine at interpreting, summarizing, ranking. It has no business being the only thing standing between a bad reading and your heater, your valve, or your alarm. Permissions, timeouts, confirmations, device interlocks: deterministic code, always. Anything reaching the model, calendar entries, camera captions, MQTT payloads, voice transcripts, counts as data, not instruction. Privacy needs the same full-path thinking: local inference stops one upload, but the recordings, thumbnails, logs, and backups behind it can still leak, so decide up front what's kept and who can pull it when you're debugging. Run it long enough for the enclosure to hit steady temperature and measure power at the wall; if it throttles or corrupts storage under real load, it isn't ready, whatever the demo looked like. None of this proves a cheap board can run a model. It proves the briefing still works once the novelty wears off.

The rule I keep: the model narrates what deterministic code already decided, never the other way round.