Where AI belongs around a heat pump
A heat pump should never let a language model decide when the compressor turns off. That's the claim, and it leaves room for AI nearby.
Small-board AI talk splits into two wrong camps: one treats a Raspberry Pi like a miniature gaming PC, the other writes off anything short of a frontier chatbot as a toy. Both miss the middle: quiet, bounded jobs by the sensors, no cloud account, barely on the power meter.
Heating is slow, and it punishes anyone who corrects it minute by minute. Start from a Home Assistant install with indoor, outdoor, and energy sensors. The board matters less than the appliance around it: storage, supply, cooling, OS, accelerator, the service using it. A model run once from a shell prompt is still several decisions from a household feature.
Four lines and a boring baseline
Write the job before buying hardware: event, input, output, deadline, four lines. Try "when a parcel sits in the porch zone for twenty seconds, send one local notification with a thumbnail" instead of "add AI to the camera," and half of it needs no model.
Build the boring thing first: a plain weather-compensation curve, judged over full days, tested against the real room, sensor, and network, because edge setups amplify variation a bench test never sees. Keep a record: board, OS, model version, real inputs against expected action, latency, and every false or missed action with its recovery.
Accuracy alone is not the finish line. Check for duplicate notifications, a clean reboot, reconnection once the network returns, and safe behavior when inference goes down. Anyone else in the house needs visible state and a manual override, not knowledge of which container crashed.
Downstream of the safety line
The failure I keep seeing: a system optimizing the compressor minute by minute off noisy readings, teaching it to short-cycle. Generative output can interpret a request or rank a few options, but it has no business being the only safeguard for a valve, a lock, a battery, or a person. Ranges, permissions, timeouts, and hard interlocks belong in deterministic code; camera captions and MQTT payloads are data to check, not instructions to obey.
Let the model suggest the setpoint. Never let it own the limit.
Privacy gets the same treatment. Local inference stops one upload, but the log line, the thumbnail, and the phone dashboard can still keep a copy. Decide what gets kept, how long, and who can pull it while debugging. The most private frame is the one the camera never records.
Run it like an appliance, not a demo: a service manager or pinned container, configuration kept apart from the model file, a health check that proves real function, not a process holding a port. Back up the controller state and keep a known-good image for hard-to-reach nodes. Run to a steady temperature and measure power at the wall with real peripherals: a board that throttles or corrupts storage isn't finished.
The rule that has held up: let the model advise a setpoint inside whatever the manufacturer and your own comfort range allow, nothing more. When the model goes away, the house should get less clever. It should not stop.
So before you install anything, find your router and pull the network cable. Watch what the heat pump does with no model in the loop. If it keeps holding a sane temperature on its own, you already built the right boundary.