Think twice before home face recognition
Face recognition on a front door is a bad default, and the reason has nothing to do with the model's error rate. The camera can be nearly perfect and the setup can still be wrong, because most of what a household wants from that lens is presence, not a name. Start from a household weighing face-based automations on a door or a room, running on a Raspberry Pi or Orange Pi with a camera that shouldn't be trusted alone.
Presence answers most of the question already
Write the job in four lines before any hardware gets ordered: event, input, output, deadline. Four lines. "Add AI to the camera" is a wish, not a job. "When a parcel sits in the porch zone past a set time, send one local notification with a thumbnail" is testable, and testing it usually shows the model was never the hard part.
Test against the room you have: the real light, camera angle, network, a Home Assistant database already busy. Edge deployments amplify ordinary variation more than any model upgrade will: evening glare, a television, a warm cabinet, a flaky cable. Keep a running note: board, OS, power, cooling, model artifact, runtime version, cold and warm latency, memory, temperature, wall power, false actions, missed actions, and recovery path. None of that shows up on a chart. All of it decides whether the feature survives a boring Tuesday.
Keep the model away from the deadbolt
A model can interpret a request, summarize camera events, or rank which door needs attention. It should never be the only thing between a stranger and a lock, a heater, an alarm, a valve, a battery, or a person's safety. Put ranges, permissions, timeouts, confirmations, and interlocks in deterministic code, not in the model's confidence. Treat everything the model reads, camera captions, calendar entries, MQTT payloads, voice transcripts, a fetched webpage, as data, never as an instruction.
Privacy needs the same treatment. Running inference locally stops exactly one thing: no upload happens, the same narrow claim going fully offline with local RAG makes. It says nothing about the recordings, the event log, the thumbnails, the backups, or a dashboard reachable from your phone, any of which can hold a copy. It's the identical gap meeting-notes privacy hits with a notetaker bot: local processing answers one question, retention answers a different one.
The safest photo is the one the camera never takes.
Decide what gets collected, how long it survives, who can retrieve it, and what a debugging session might expose. Second-best is a frame thrown away the instant the decision it fed gets made.
The real test happens on a boring Tuesday
Run the thing under a service manager or a small container pinned to a version, config kept apart from the model file you'll swap out later. Add a health check that proves the function works, not that a process owns a port. Back up the controller's state, record the model's hash, keep a known-good storage image for nodes installed somewhere annoying to reach.
Power and heat belong in the acceptance test. Let the enclosure reach its own steady temperature, then measure at the wall with the normal peripherals attached. A board that throttles, swaps, corrupts its own storage, or hogs the automation host isn't finished, whatever its best inference result looked like.
The point is a capability small enough to still run after the benchmark window closes and the board disappears behind a router.
The rule I'd actually keep: use less identifying signal than you're tempted to, unless identity changes a safe outcome, and when the model goes down, the automation should get dumber, never stop.