Orange Pi 5 as a low-power AI node
Silicon is not the bottleneck here. An RK3588 has capable CPU, memory, and an NPU rated at whatever TOPS number the marketing page landed on, more than a house job needs. What holds an Orange Pi 5 back is the NPU driver, the conversion toolchain, and an OS image that has to keep agreeing with both.
Small-board AI collects two bad takes: an Orange Pi as a shrunken gaming PC, or nothing worth doing short of a frontier chatbot. The real opportunity sits between: a bounded job near a sensor, no cloud account, little power, working with or without the internet, like an Orange Pi 5 Plus doing image classification and a couple of home-automation helpers. The board is the least interesting part of the appliance you are building.
Buy for the toolchain, not the TOPS number
Buy on the TOPS figure alone and you can spend the project fighting an incompatible driver instead of shipping. I would not buy a board before its accelerator toolkit and OS image are confirmed to work together. A model that runs once from a shell prompt is still several decisions from a household feature: storage that survives a power cut, cooling that holds over hours, and a downstream service that knows what to do with the result.
The chip was never the risk. The driver stack was.
Four lines beat a shopping list
Write the job before you write code: event, input, output, deadline, four lines or fewer. Add AI to the camera is a wish, not a job. When a parcel sits in the porch zone for twenty seconds, create one local notification with a thumbnail, that is testable and shows which parts never needed a model. Confirm the OS image, kernel, toolkit, and model conversion path agree before designing a service, then test with the real room: camera angle, microphone, language, network. Edge deployments amplify ordinary variation, evening light, a flaky cable, more than a model revision ever will. Accuracy alone is not the finish line: check duplicate notifications, reboot survival, reconnection, and what happens when the inference service goes down. A feature other people rely on needs visible state and a manual override: nobody should have to know which container is unhealthy to turn on a light.
Give the model an off switch, not a veto
A model can interpret a request, summarize a history, or rank a few options. It should never be the only thing standing between a person and a lock, a heater, an alarm, or a valve. Put ranges, permissions, timeouts, and hardware interlocks in deterministic code that ignores what the model just said, and treat anything pulled from a camera frame, a calendar entry, a webpage, an MQTT payload, or a voice transcript as data, never an instruction. Privacy needs the same thinking end to end: local inference stops one upload, but recordings, logs, and backups can still leave a copy, so decide what gets kept, how long, and what debugging exposes. Run it as a service, config kept apart from the model file, controller state backed up, with a health check that proves the actual function, not a process holding a port, tested for hours until the enclosure settles. A board that throttles, swaps, corrupts storage, or hogs the automation host is not ready.
Prove one model doing one job end to end before planning a second one. Edge AI works best as a narrow layer above reliable sensors and below a policy stated plainly: a capability that still works once the benchmark window closes and the box is back in a cupboard. Before calling it done, check whether the OS image and accelerator toolkit still agree after the last update, whether the automation gets simpler instead of silent when the inference service goes down, and whether anyone else can tell the system is in trouble.