Occupancy-aware HVAC without camera surveillance
Sensor fusion for a house doesn't need to know who is in a room, only that someone is there.
That's the whole trick behind occupancy-aware HVAC without a camera: door contacts, PIR motion, mmWave radar, and Wi-Fi or BLE presence each answer a narrower question than who this is, and fusing them gets the coarse answer needed without building anything like a face model. Put that controller on a small board instead of a phone app calling a vendor's cloud, and a second constraint shows up: no camera in the loop, nothing leaving the property, no guarantee the network is reachable when it matters.
Twenty seconds in the porch zone is a spec, add AI is not
Write the job in four lines: event, input, output, deadline. A vague ambition doesn't survive contact with hardware. Something like when a parcel sits in the porch zone for twenty seconds, fire one local notification with a thumbnail, is testable, and testable specs reveal which parts never needed a model at all. Comfort control is the same shape: give each signal a confidence and a decay rate, keep a manual override that always wins, log every decision rather than just the ones that look wrong later. Test it against real rooms, not a bench setup: the door hinge that never fully latches. Edge deployments amplify what's ordinary about a house more than they amplify the model.
Cold boot, warm boot, sustained load: log all three
A four-minute household routine isn't proven by accuracy alone. Surviving a reboot, reconnecting once the network returns, and staying safe when the inference service isn't there matter more day to day than a point of precision nobody will ever see. Keep a field log. Keep it plain.
| what you record | why it earns a column |
|---|---|
| board, OS, power supply, cooling | throttling and brownouts a bench test misses |
| model artifact and runtime version | silent drift after a container updates itself |
| real input set and expected action | whether the spec still holds in the actual house |
| cold latency, warm latency, sustained rate | the number that matters is sustained, not cold |
| memory, temperature, wall power | the board that's fine idle and chokes under load |
| false action, missed action, recovery path | the failure mode nobody wants to admit exists |
None of these rows are exciting. Exciting was never the bar for a thermostat.
Locks and heaters don't get to trust a confidence score
The common failure is treating one flaky presence sensor as ground truth. Right behind it is letting a generative component make the final call on something that can burn, flood, or lock somebody out. A model can interpret a request, summarize a history, rank a set of options. It has no business being the only thing standing between a person and a stuck valve or a dead battery pack. Ranges, permissions, timeouts, confirmations and interlocks belong in deterministic code a model can request but never bypass. Treat camera text, calendar entries, MQTT payloads and voice transcripts as data to be checked, not instructions to be obeyed: a spoofed payload has no idea it isn't allowed to open your garage.
The photo you never take is the only private one
Local inference solves exactly one problem: the frame never leaves the house as an upload. It does not solve the other five. Recordings, event logs and thumbnails can all hold a copy of something you assumed stayed home, and so can a backup or a remote dashboard left open on a laptop. Decide what gets collected, how long it survives, who can pull it up, and what a debugging session is allowed to see. The most private frame is the one never captured. The next best is the one thrown away right after a bounded decision gets made.
Thermal equilibrium in a cupboard is part of the spec
Run the service under a process manager or a small pinned container, keep configuration separate from the model files, and write a health check that proves function, not just that a port is listening. Back up the controller state, export model hashes, keep a known-good image for the node wedged behind the water heater. Power and heat belong in the acceptance test: run it long enough for the enclosure to reach equilibrium, measure at the wall with the real peripherals attached, and if it throttles, swaps, or corrupts storage, a good inference result on day one means nothing. I wouldn't bother clustering boards for redundancy on a house this size; a known-good image and a spare board on a shelf covers it. Combine modest signals and fail toward defaults that stay safe and comfortable, so when the model goes away the house gets less clever, not stopped.
I'd stop short of calling any of this finished, because the moment you add a third or fourth zone the confidence-and-decay math stops being something you can eyeball, and I haven't built tooling to make that easier either. So take the log format above as a starting discipline, not a guarantee that your porch will never send you a confident notification about a determined cat.