Use mmWave presence before adding an AI camera

Skip the camera. If the question is "is anyone in here," an mmWave presence sensor answers faster, cheaper, and with less to leak than a camera plus a recognition model. That only holds when presence is genuinely all you need: the moment an automation has to know it's a parcel and not the cat, you've left the job a radar chip was built for.

The simplest sensor that already sees what you need beats the cleverest one that has to guess at it.

Small-board AI splits into two camps, and both are wrong: point a vision model at everything, or write the category off because it isn't a chatbot. The useful work sits between, small jobs next to the sensor, no cloud account, little power. Presence-driven lighting and HVAC is the textbook case: pick the sensor that already knows the answer instead of guessing it from pixels.

Write the outcome down before you touch a board

Four lines before any hardware gets ordered: event, input, output, deadline. Skip "add AI to the porch camera" and write something testable, like a notification that fires once a shape holds in a zone for a set time. Writing it this plainly usually shows half the pipeline doesn't need a model. The first experiment is tuning zone and dwell time, then fusing in a door or motion sensor to catch what the radar misses alone.

Test with the room you actually have: lighting, doorway angle, network, home-automation instance under load. Edge deployments turn small variation into large, evening glare or a warm cabinet moves the result more than a model update does. Log more than accuracy: cold and warm latency, memory and heat under load, how often it fires on nothing or stays quiet, and whether it survives a reboot and reconnects once the network returns. The board matters less than what's around it: power, cooling, storage, the OS image, and the service that turns a detection into an action. Run it as a pinned service, not a script someone restarts by hand, and back up the controller state and model hash. A feature other people rely on needs visible state and a manual override; nobody should have to know which container crashed to turn on a light.

Don't let a model guard the thing that matters

The deeper failure isn't the wrong sensor, it's letting a model become the only thing between a request and a lock, a heater, an alarm, or a valve. Generative output is fine for interpreting a request or ranking options; it has no business protecting something that can hurt a person or a house. Put permission checks, ranges, and timeouts in deterministic code, and treat camera, calendar, or voice output as data to check, not instructions to obey.

Privacy needs the same suspicion end to end. Local inference stops one upload, but the recordings and logs still sitting on the device are copies of your living room too, and someone has to decide what gets kept and for how long. The frame a camera never captures is the private one; the next best is discarded the moment the decision is made. Reserve vision for what an ordinary sensor genuinely can't answer; when the model goes down, the fallback should be dumber, not silent.

I've settled on the tradeoff without much regret: the sensor will never tell me who's in the hallway, only that someone is, and that gap isn't worth a camera pointed at my own house.