Forecast home energy on a small board
So no, you don't reach for a language model because the readings are numbers. Sensor data gets serialized to JSON, starts looking like text, and a dryer waits on a model it never needed. Short-horizon load forecasting wants a Raspberry Pi pulling smart-meter and tariff data, not a chatbot. The model is the easy part; power, cooling, OS, and the service that reads the number decide whether the project works.
Spec the sentence before you spec the silicon
Write the job in four lines: event, input, output, deadline. "Predict energy use" isn't one. "When the forecast crosses the cheap-tariff threshold, queue the water heater" is. Start with persistence, then a moving average, then a compact forecaster, and stop once the simpler one works. Test on your own meter and network, not a public dataset that rhymes with your case. Edge deployments amplify ordinary variation: a flaky Wi-Fi bridge or a bloated database wrecks a forecast faster than any model swap fixes it.
The numbers a spec sheet won't give you
Accuracy is the least interesting number here. What matters is whether it survives a reboot, reconnects once the network returns, and fails safe when inference is down. Keep a running record: board, OS, power supply, model artifact and runtime, latency cold and warm, sustained rate, memory, temperature, wall power, plus every false or missed action and its recovery path. Nobody should need to know which container crashed. It needs visible state and a manual override that doesn't require you.
Keep the model on the advisory side of the wall
Generative output is fine for interpreting a request or summarizing a week of usage. It has no business being the only thing between a bad forecast and a heater left running. Ranges, permissions, timeouts, confirmations, and device interlocks belong in deterministic code, not a prompt. Any external feed, MQTT, calendar, a scraped webpage, counts as untrusted input. Privacy needs the same full-path thinking: local inference stops one upload, but logs, thumbnails, backups, and a dashboard still leave copies around. Decide what's kept, how long, and who can reach it.
The boring plumbing that decides if it survives a summer
Run it under a real service manager or a pinned container, keep configuration apart from the model file, and write a health check proving a forecast gets produced, not that a process holds a port open. Back up its state, hash the model, and keep a known-good image ready. Let the enclosure reach thermal equilibrium before trusting a measurement, taken at the wall with real peripherals attached. A board that throttles, swaps, or corrupts its own storage under that load isn't finished, whatever the accuracy looked like on the bench. Pick the smallest model that matches your data's shape; when it goes missing, the schedule should get dumber, not dark.
None of which changes that for one household and one dryer, a cron job and a spreadsheet would have gotten most of the way there for a fraction of the effort. I'd still build the forecaster. I just wouldn't call it the efficient choice.