Place Thread border routers for resilience, not AI
Two Thread border routers at opposite ends of a house still let a battery sensor drop off the mesh a couple of times a week, and no model fixes that. The board was never the bottleneck. The radio topology is.
Small-board AI gets two kinds of bad advice: treat a Pi like a gaming rig, or dismiss anything short of a frontier chatbot. Both miss the middle: bounded jobs near the sensors, off the cloud, low power.
Language intelligence cannot make up for a network that keeps losing endpoints. The board matters less than the whole appliance around it: storage, power, cooling, OS, radio, and the service consuming the output.
Four lines decide whether you need a model at all
Write the event, input, output, and deadline before ordering hardware. "Add AI to the camera" fails that test. "When a parcel sits in the porch zone past a set time, send one local notification with a thumbnail" passes, and half the job needs no model.
The first test is a survey, not a benchmark: map coverage, find single points of failure, verify credentials, pull the controller's plug.
| Field | What you're checking |
|---|---|
| Board, OS, power, cooling | Survives the enclosure |
| Latency, sustained rate | What the household feels |
| False and missed action | What happens when it's wrong |
Accuracy alone tells you little. Check for duplicate notifications, clean reboot recovery, and safe behavior when inference is gone. Anything others rely on needs visible state and a manual override.
The lock does not get a vote from the language model
The failure I see most is someone debugging LLM tool calls while the mesh underneath quietly drops devices. Generative output is fine interpreting a request or ranking options; it has no business standing alone between a bad decision and a lock, heater, valve, or person. Ranges, permissions, timeouts, interlocks belong in deterministic code the model cannot talk around. Camera text, calendar entries, MQTT payloads, transcripts: all of it is data, never instructions.
Privacy needs the same thinking: local inference stops one upload, but recordings, logs, and backups still leave copies. Decide what's collected, how long, and who can retrieve it. The most private frame is the one the camera never records.
Build the thing to survive being ignored
Run it under a service manager or a small pinned container, not a terminal session someone will close. Keep configuration apart from the model files. A health check should prove the feature works, not that a process owns a port. Back up controller state and keep a known-good image handy.
Power and heat belong in the acceptance test: run the enclosure to equilibrium, measure at the wall. If the board throttles, swaps, or corrupts storage, it isn't ready, whatever the screenshot showed. I wouldn't bother chasing every dip on a sensor's signal graph; it doesn't care that you noticed.
Stabilize transport and state before anything conversational touches the system. It's a narrow layer above sensors you trust, below a policy already clear. When the model goes away, automation should get less clever, not stop.
None of this proves a cheap board runs a model. It never needed proving. What I still don't have is a way to test a mesh degrading slowly, not one you've just unplugged. Pulling a router's power tells you about failure, not the weeks of packet loss that come first.