The idea
A Raspberry Pi and a handful of metered smart plugs that decide when your deferrable appliances run. You tell it "the dishwasher needs to be done by 7am"; it pulls the next 24 hours of grid carbon intensity and wholesale price for your region, finds the window that fits the appliance's runtime, and switches the plug on then. A one-page local dashboard shows what ran when, what it cost, and what it would have cost if you had just pressed start.
Why build this
Half-hourly tariffs are no longer exotic. Octopus Agile in the UK, aWATTar and Tibber across the EU, and time-of-use plans from most US utilities all expose per-interval pricing, and prices now go genuinely negative on windy nights. Carbon intensity swings just as hard — a load moved from 6pm to 2am can be a third of the emissions for the same kilowatt-hours.
The tooling to exploit that is bad. Appliance delay-start buttons are dumb timers: you guess a number of hours and hope. Utility apps show you yesterday's prices. Home Assistant can do this, but only if you are willing to hand-write template sensors and a scheduling automation, which is a weekend of YAML for something that should be a checkbox. The gap is a purpose-built appliance scheduler that a non-Home-Assistant household can plug in and use.
Stack sketch
- Switching: off-the-shelf Shelly Plus Plug S or Plus 1PM — mains-rated, energy-metering, local HTTP and MQTT, no cloud dependency. Skip building your own relay board; certified hardware is not where you want to be original.
- Controller: Python + FastAPI on a Pi Zero 2 W, or any always-on box. APScheduler for the timer layer.
- Broker: Mosquitto, so plugs report power draw continuously and the scheduler can detect a cycle finishing.
- Grid data: UK National Grid Carbon Intensity API (free, no key, 48-hour regional forecast), Electricity Maps or WattTime elsewhere. Prices from the Octopus Agile REST endpoint, aWATTar, or Nordpool day-ahead.
- Storage: SQLite with Litestream replicating to object storage. The whole dataset is half-hourly rows; nothing bigger is warranted.
- UI: a single SvelteKit page served from the same box. ntfy for "your laundry starts in 10 minutes" pushes.
Scope for v1
In:
- Three or four plugs, each with a name, a typical runtime, and a deadline.
- One region, one tariff, one optimisation target chosen by the user: price or carbon.
- A greedy window search over the forecast — find the contiguous N half-hours before the deadline with the lowest total. No solver needed.
- Cycle-complete detection from the power trace (draw drops below a threshold for five minutes).
- A "run now" override on every plug, obvious and one tap away.
Out: solar and battery forecasting, EV charge curves, multi-home accounts, any hosted component beyond the tariff fetch.
Where it could go
The natural next step is self-consumption. Once you can read an inverter locally — SunSpec Modbus, the Enphase local API, Fronius Solar API — the objective changes from "cheapest half-hour" to "run while the roof is producing", which is a bigger saving than tariff arbitrage for most households with panels.
After that, measurement becomes the product. You have per-appliance energy traces plus counterfactual prices, so you can report verified savings rather than a vague promise. That number is what makes the device worth recommending, and it is also the entry ticket to demand-response programmes, where utilities pay for curtailment they can actually verify.
Watch out for
Some appliances handle a mid-cycle power cut badly — a modern dishwasher resumes, an older dryer forgets everything, and a fridge or anything with a compressor should never be on a scheduled plug. Ship a hard allowlist of appliance types and refuse to schedule anything else.