Power edge AI nodes with PoE when wiring allows

PoE is the best thing that ever happened to a camera or voice satellite mounted with no outlet nearby: a dead node becomes a switch port you power-cycle from the couch, not a ladder trip. That part of the pitch is real. What it won't do is pay your power and thermal bill, and that bill is where these builds quietly fail months after the demo worked fine.

start from the sentence, not the board

Pick a Pi or an Orange Pi later. First write the job in four short pieces: event, input, output, deadline. "Add AI to the camera" is a wish, not a job. "When a parcel sits in the porch zone for twenty seconds, produce one local notification with a thumbnail" is something you can fail at, and failing at it shows which half of the appliance never needed a model. Then test against the room you actually have, not a clean bench: the real microphone, camera angle, language, network. Edge deployments amplify ordinary variation more than a rack server ever tolerates, so evening light, a television talking nearby, a warm cabinet, a marginal cable, or a busy Home Assistant database will move your results more than swapping the model does. Trust what happened on that hardware, not the number the first clean run gave you.

the model doesn't get to hold the keys

Generative output is fine at interpreting a request or summarizing history. It has no business being the only thing between a person and a lock, a heater, an alarm, or a valve. Put the ranges, permissions, timeouts, confirmations, and hard interlocks in boring deterministic code, and treat everything the model reads, camera text, calendar entries, scraped pages, MQTT payloads, voice transcripts, as data to be suspicious of, not instructions to follow.

Local inference stops one upload. It does not stop the recordings, thumbnails, logs, and backups that pile up after it.

Decide on purpose what gets kept, how long, who can pull it, and what a debugging session exposes: the most private frame is the one the camera never saves, the next best is discarded right after the decision it fed. On power, don't trust the headline PoE class as what reaches the board; a HAT and its onboard conversion eat a real slice of that budget before any peripheral sees a milliwatt, the same hardware for local LLMs habit of budgeting real numbers over spec-sheet ones, just on smaller silicon.

build the thing you'll forget is running

Run it under a service manager or a small pinned container, keep configuration apart from the model files, and write a health check that proves the actual function, not merely that a process owns a port. Back up the controller state, record the model hashes you depend on, keep a known-good image for any node installed somewhere annoying to reach. Then run the enclosure long enough to hit thermal equilibrium and measure power at the wall with every peripheral attached: a board that throttles, swaps, corrupts its storage, or drags down your home automation host under real load was never finished, whatever its best inference looked like in a screenshot. When the inference service goes down, the automation around it should get dumber, not stop.

I still don't have a clean answer for the flip side of the recovery story. PoE gives you one cable and one point of remote control, which is also one point of failure: a switch needing its own reboot takes every node behind it down at once. Fixing that means a second power path, or a second switch, and at that point you've rebuilt the complexity PoE was supposed to save you from.