Use local AI to reduce notification fatigue

My porch camera fires an event every time a shadow crosses the driveway, the recycling truck idles at the curb, or next door's cat does its evening lap. None of that needs my attention, and by the third buzz in ten minutes I've done what every homeowner eventually does: stopped looking at the app. That's the actual failure mode "AI camera" products are supposed to fix, and most of them don't, because they're solving detection, not attention. A notification that gets swiped away unread has already failed, regardless of how good the model behind it was.

Small-board AI attracts two flavors of bad advice. Some people treat a Raspberry Pi or an Orange Pi like a miniature gaming PC and expect chatbot-grade output from it. Others write off anything that isn't a frontier model as a toy. Both skip the useful middle: small, boring jobs that run near the sensor, need no cloud account, and sip power doing it. My real constraint isn't compute. It's that people ignore systems that cry wolf, and once they start ignoring notifications, they ignore the real ones too. A house generating camera, door, energy, battery, and maintenance events all day needs something between "log everything" and "alert on everything," and that middle layer is where a small local model earns its keep.

Four lines beat a shopping cart

Before you order a board, write the job down in four lines: event, input, output, deadline. "Add AI to the camera" is a wish dressed up as a spec. "When a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" is something you can build, and more importantly, something you can check.

• event: what triggers the check
• input: exactly what data the model sees
• output: exactly what the household gets
• deadline: how long you have before the answer is useless

Writing it out this way tells you which parts don't need a model at all. A twenty-second dwell timer is a counter, not an inference call. The model earns its place when you need to group related events, keep track of where a decision came from, apply a risk rule on top, and let it answer "not sure" instead of guessing. That last part matters more than people expect: a model that can abstain beats one that's marginally more accurate but always commits to an answer.

Test it with your actual room. Your microphone, your camera angle, your sensor placement, your language, your network, not a demo clip from a vendor's website. Edge deployments amplify ordinary household variation: evening light through the blinds, a television talking over a voice command, a cabinet running warm next to the router, a flaky USB cable, a Home Assistant database that's been growing untouched for way too long. Any one of those moves your results more than swapping model versions does. Keep a field record while you test:

board / OS / power supply / cooling
model artifact and runtime version
real input set and expected action
cold latency, warm latency, sustained rate
memory, temperature, wall power
false action, missed action, recovery path

For a feature that fires a few times a minute, accuracy is not the whole story. Does it survive a reboot? Reconnect once the network comes back? Behave sanely when the inference service is just down for a while? A feature used by anyone else in the house needs visible state and a manual fallback. Nobody in my family should have to know which container crashed just to turn on a light.

The lock doesn't get a vote (notifications)

Here's where I get strict, because this is the part people get wrong in a way that can actually hurt someone. The common failure is letting a model quietly suppress a smoke, leak, lock, or alarm event because it pattern-matches to routine noise. Generative output is fine at interpreting a request, summarizing history, or ranking a list of options for you to glance at. It has no business being the only thing standing between a person and a stuck valve, an unlocked door, or a battery about to vent. Ranges, permissions, timeouts, confirmations, and interlocks belong in plain deterministic code that doesn't care what the model thinks today. Anything out of a camera, a calendar entry, a webpage, an MQTT payload, or a voice transcript gets treated as data, never as an instruction, no matter how well-formed it looks.

What the camera keeps after the fact

Privacy needs the same full-path thinking, not just a check on the model. Running inference locally stops one upload, sure, but recordings, event logs, thumbnails, backups, and any remote dashboard you've bolted on can still leave copies scattered around. Decide, on purpose, what gets kept, for how long, who can pull it, and what happens to it the day you're debugging with verbose logging on and forget to turn it back off. The most private frame is the one the camera never records. The next best is the one thrown away the instant a bounded decision gets made.

Health checks, backups, and the wall socket

Run it under a service manager or a small container definition you've actually pinned, with configuration kept apart from the model file so you can swap one without touching the other. Add a health check that proves the feature works, not one that just confirms a process is squatting on a port. Those are different claims, and only one of them matters at three in the morning. Back up the controller state, export your model hashes, and keep a known-good storage image ready for any node you installed somewhere annoying to reach twice.

Power and heat are part of the acceptance test, not an afterthought. Run the thing long enough for the enclosure to hit thermal equilibrium and measure at the wall, with whatever peripherals you'd actually leave attached day to day. If it throttles, starts swapping, corrupts the SD card, or hogs the box your home-automation stack depends on, it isn't done, even if the one inference result you screenshotted looked great.

The rule I keep coming back to: safety alerts stay deterministic, and AI only gets to touch low-risk prioritization. Edge AI is a narrow layer sitting above sensors you trust and below a household policy you wrote on purpose, nothing more than that. When the model goes away for whatever reason, the automation underneath it should get dumber, not stop.

I wouldn't bother running a model on-device just to summarize logs nobody reads. That's a cron job and a few lines of Python, not an accelerator card. Save the board for the one job that actually needs judgment under uncertainty, and skip it everywhere else.

Next on my list: go check whether my own reboot path actually reconnects cleanly, because I've never tested it on purpose, only found out the hard way when it didn't.