Run Frigate around an SBC, not necessarily on it
Four RTSP cameras, a Raspberry Pi running Frigate, and a Coral stick doing the actual detection: that's the working split, not the board buried in a heatsink the size of a brick.
Small-board AI draws two bad takes: the Pi as a mini gaming rig, or anything short of frontier scale waved off. The useful middle is quiet, bounded work that sits near the cameras. Decode, detection, recording, and the Home Assistant hooks all want different hardware. The board's name barely matters. What matters is the appliance around it: storage, supply, cooling, the OS image, and whatever service consumes the result.
the job description before the shopping list
Write the event, input, output, and deadline in four lines before buying anything: "add AI to the camera" isn't a job, but "when a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" is.
Test against footage from the actual porch: a marginal cable or a bloated Home Assistant database moves the result more than a model swap. Keep a short record:
board / OS / power / cooling
model artifact, runtime version
cold and warm latency, sustained rate
false action, missed action, recovery pathAccuracy alone doesn't clear a household feature: duplicate notifications, reboot survival, a safe fallback when the detector's down.
the lock still needs a dumb switch behind it
The common mistake: routing every decision through one box for a tidy diagram. A model can interpret or rank; it should never be the only thing between a request and a lock, heater, alarm, valve, or battery. Permissions, timeouts, and interlocks belong in code readable without a GPU; camera captions, MQTT payloads, and voice transcripts count as untrusted data, not instructions.
Privacy wants the same end-to-end thinking: local inference stops one upload, not all of them, recordings, logs, and backups can each keep a copy of the frame. Decide what's kept, how long, and who can pull it. The safest frame is the one never captured.
run it like a fridge, not a lab bench
Use a service manager or a pinned container definition, keep configuration apart from the model files, and write a health check that proves the pipeline works. Back up the controller state and keep a known-good storage image: these nodes sit somewhere inconvenient.
Power and heat belong in the acceptance test: run until the enclosure reaches a steady temperature and measure at the wall. Any of these fails it regardless:
- the board throttles under sustained load
- storage corrupts after a dirty shutdown
- the pipeline goes silent instead of degrading
Optimize the camera system, not the board count. When the detector's unreachable, the porch light should still work, minus the smart part. I haven't sorted out the debugging side of privacy: when something breaks, diagnosing it means pulling the image the setup was built to avoid keeping.