Design a Pi camera pipeline before choosing the model
So no, the detector isn't the bottleneck. Arguing over which quantized net to flash onto a Pi Camera rig before you've defined the job is how these projects go sideways. Point a camera at a doorway or a workbench and most of what it sees never needs a network at all.
The four lines that save you a board
Write the job in four lines before buying anything: event, input, output, deadline. "Add AI to the camera" fails that test outright. "When a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" passes, and shows which parts never needed a model. Crop to the region that matters, gate on motion, then pick a detector for accuracy, in that order. Test against the room you actually have, evening light and camera angle included: edge setups amplify ordinary noise more than any model revision will.
What a benchmark number won't tell you
A benchmark percentage says nothing about whether the thing survives an ordinary Tuesday. Log the board, the OS, the power supply, the model file and runtime deployed, the real input set behind each test, cold latency against warm latency against sustained rate, and memory, temperature, power measured at the wall. Check the failure side too: what a false trigger costs against a missed one, and whether it comes back clean after a reboot. Somebody in the house needs to see the state and have a manual override.
Two things the network doesn't get to decide
The common mistake is feeding full-resolution, continuous video into inference just because the sensor can supply it. A model can read a scene, summarize a log, rank a few options, and none of that makes it a safe layer between a decision and a lock, a heater, or a valve. Ranges, permissions, timeouts, and interlocks belong in deterministic code, not in whatever the network outputs. Treat camera text, calendar entries, and voice transcripts as data to doubt, never instructions to obey. Local inference stops one upload; recordings, logs, and a remote dashboard can still carry a copy off the device.
What keeps working after launch day
Put it under a service manager or a small pinned container, configuration kept apart from the model file, with a health check that proves the actual function, not just a process holding a port open. Back up the controller state, keep a hash of whatever model is deployed, and for a board installed somewhere awkward, keep a known-good image ready to reflash. Let the enclosure reach a steady temperature with peripherals attached and measure at the wall. The board is not the point. Something that throttles or drags down the home-automation host isn't finished, whatever the inference numbers looked like. Cut the visual workload before reaching for a faster chip; when the model goes away, the automation should get dumber, not stop.
Next thing I'd actually check, before spending on any board: kill the inference container for an afternoon and see whether the crop-and-motion-gate pipeline alone still catches the events that matter.