Use edge vision to watch a garden selectively

Pick the job first. The board comes second.

A timelapse rig, a critter-detection camera, and a plant-health monitor are three different appliances sharing a lens, each wanting its own schedule and its own model, sometimes no model at all: a timelapse cares about a bean plant creeping upward over a week, a feeder camera cares about a fox at the fence for four seconds, a plant monitor cares about neither until light or soil crosses some threshold worth logging. Buy one Pi-class board expecting all three jobs for free and you'll be disappointed. The category also draws two bad instincts: treating the board like a tiny gaming rig, or writing the whole idea off because it isn't a frontier chatbot. Both miss the real shape of the job, which is quiet, bounded, and idle most of the day. Outdoor change is slow until it suddenly isn't, and full-rate inference just burns power waiting for that moment.

The four lines that save you a GPU

Before any hardware decision, write the event, input, output, and deadline in four lines. "Put machine vision on the garden camera" is not a job, it's a wish. "When motion at the feeder holds more than two seconds during daylight, save one frame and queue a local notification" is testable, and testable is the point.

event:    motion at feeder, daylight hours only
input:    PIR trigger + camera frame
output:   local snapshot, one push notification
deadline: notification within a few seconds of trigger

That exercise also shows which parts need no model at all. Timelapse needs an interval timer and disk discipline, nothing that deserves the word inference. A plant check needs a schedule tied to the growth cycle, not the clock, since the interesting change happens over days. Only animal detection earns a model, because only it has to tell a real visitor from a branch moving in the wind.

Sample at the event's rate, not the camera's, and mask whatever moves for reasons unrelated to your question. Test against your actual bed, your actual feeder, your actual network, not a demo clip: low evening light, a spider on the lens, a flaky cable, or an overloaded home-automation database will move your result further than swapping model versions ever will. Accuracy alone isn't enough, either. Does it survive a reboot, reconnect after the router hiccups, stop repeating the same alert when nothing reset the trigger? Anything the household has to trust needs visible state and a manual fallback.

The valve doesn't care what the camera thinks it saw

I've watched a detector trained on indoor people get pointed at a bed of runner beans, misfire constantly, and get wired into something that can hurt something: a heater, a lock, an irrigation valve, an alarm. Treat a vision model's output as a hint, nothing more. The code that opens a valve or arms an alarm should live entirely outside the model, with its own ranges, permissions, and timeouts. Camera text, calendar entries, and voice transcripts are data handed to you by a stranger, never an instruction.

Privacy needs the same thinking. Local inference stops one kind of leak, the upload. It does nothing about the recordings, thumbnails, and backups piling up on the SD card and syncing somewhere without anyone deciding that on purpose. Decide up front what gets kept, how long, and what a debugging session gets to see. The most private frame is the one never taken; the next best is deleted right after the decision.

Run it as an appliance, not a demo left open in a terminal: a service manager, configuration kept apart from the model file, a health check that proves the actual function rather than that a process is squatting on a port. Keep a known-good storage image for the node bolted to a fence post somewhere inconvenient. Power and heat belong in the same acceptance test as accuracy: let the enclosure reach whatever temperature it reaches outdoors, then measure at the wall with everything running normally. A board that throttles or corrupts its own storage after a few hours has failed, even if the one result you screenshotted looked perfect.

The rule that's held up: build the capture schedule around the biological question first, and let the model be a narrow layer above a reliable sensor and below a household policy you could explain to a relative who doesn't code. When the model goes down, the automation should get dumber, not disappear. The feeder light still comes on at dusk. The valve still runs on its timer. Only the "was that actually a heron" judgment goes quiet for a while.

What I still don't have a clean answer for is the shoulder season, the couple of weeks when the timelapse cadence, the motion mask, and the actual biological event all disagree about what counts as change. Frost fog blanks the lens some mornings. The same wind that wrecks your animal-detection false-positive rate is also the first real growth week for whatever you're trying to watch. I haven't written a schedule yet that satisfies both jobs from the same camera at once.