Use MQTT as the narrow bridge to local AI

People wire the camera feed straight into whatever inference box they have running and let it make the call, and this has already gone wrong for plenty of them. The pattern repeats: raw video, audio, or a slice of the automation database gets published somewhere convenient, and a model's read of it ends up unlocking a door or opening a valve. The failure rarely announces itself: a confident, plausible read of a frame the model never fully understood, and nothing downstream double-checks it before acting.

The fix has less to do with a smarter model than with what the AI worker gets to see: a subscriber to a short list of well-defined MQTT topics, not a scraper with a standing invitation to the whole house. Which board sits under it matters less than people think, a Raspberry Pi and an Orange Pi will both run a small classifier fine. What matters is the appliance around the chip: storage, supply, cooling, the OS image, radio or accelerator support, and whatever consumes the result downstream.

Four lines beat a shopping list (mqtt)

Before any hardware gets ordered, write the event, the input, the output, and the deadline in four lines. "Add AI to the camera" isn't a job, it's a mood. "When a parcel sits in the porch zone for twenty seconds, publish one notification with a thumbnail" is a job, because you can test it and tell when it's wrong. Writing it this way usually shows that half of what you assumed needed a model doesn't.

Once the job is written, build the plumbing on purpose: versioned topics, small schemas, retention rules, per-client access. Test with the actual room, the real mic, camera angle, and network. Edge deployments exaggerate ordinary variation: evening light, a television talking nearby, a warm cabinet, a flaky cable, a database under load, any of which can move the result more than a model upgrade would.

Keep a short record for every job you ship:

• board, OS, power supply, and cooling
• model artifact and runtime version
• a real input set with the expected action
• cold latency, warm latency, and sustained rate
• memory and temperature under load, and power drawn at the wall
• what a false action costs, what a missed one costs, and the recovery path

Accuracy alone doesn't clear the bar for something running unattended in a hallway. Check for duplicate notifications, reboot survival, clean reconnection once the network returns, and safe behavior when inference disappears. Anything used by other people needs a visible state and a manual override, so nobody has to know which container is misbehaving just to turn on a light.

The model doesn't get to hold the keys (mqtt)

The failure from the opening is the default outcome of treating a language model as a permission system. It can summarize a history, rank a few options, interpret a loose request, fine. It should never be the only thing standing between a request and a lock, a heater, an alarm, a valve, a battery, or a person. Put ranges and permissions, timeouts and confirmations, and device interlocks in ordinary deterministic code, and treat camera text, calendar entries, and voice transcripts as data to be checked, never as instructions to be obeyed. The same discipline that keeps agent architectures useful applies here: the model earns trust with a small blast radius, not a big vocabulary.

Privacy needs the same full-path thinking, not just a "runs locally" checkbox. On-device inference removes one upload, but recordings, logs, thumbnails, backups, even a remote dashboard can still leave copies you forgot about. Decide up front what gets collected, how long it stays, and who can pull it later. The most private frame is the one the camera never captures. The next best one is discarded the instant its bounded decision gets made.

Then operate the thing like an appliance, not a demo you're still proud of. Run it under a service manager or a small, pinned container, keep configuration apart from the model files, and add a health check that proves the function works, not just that a process owns a port. Back up controller state and keep a known-good image for hard-to-reach nodes. Run it long enough for the enclosure to reach a steady temperature, and measure power at the wall with real peripherals attached; if it throttles, swaps, or corrupts storage, it isn't ready, whatever the best inference result looked like on your bench. When the service goes down, the house should get dumber, not dark.

If I keep exactly one rule out of all this, it's the one about what goes on the wire: publish the smallest event that lets something else make one bounded decision, nothing wider. That's it. That's the whole architecture.