EthosPowerAIReference design · Intelligence
Carbon-Aware Load Scheduling for GB Sites
- NESO Carbon Intensity API
- Python
- Postgres
- OCPP charge controller
- Job scheduler
- ntfy
The problem
A site's flexible loads run when people plug them in or when a cron line says so, usually in the evening peak. The carbon report then multiplies a year of bills by an annual average factor, and nothing in it could have changed when anything ran.
What I would build
An agent reads NESO's 48-hour regional carbon intensity forecast for the site's postcode, picks the lowest-intensity window that still meets each flexible load's deadline (fleet charging, a battery's grid charge, batch jobs, a nightly sync), and writes the schedule to the charge controller or job scheduler. A person sets every deadline and can override any slot. Each half-hour of metered energy is logged against the forecast, and against NESO's estimated actual where one exists, with source, method and fetch time attached for Scope 2 reporting.
The logic flow
Click any node for what it does, what it hands on, and where a person is required.
What it returns
A reference design on a public API, not a system I run. In NESO's forecast for South England pulled on 16 October 2026, a three-hour fleet charge on arrival averaged 242 gCO2/kWh and the best window before its deadline averaged 140. Those are forecast regional averages, not marginal intensity and not measured avoided emissions.
Why it fits
A site manager can now ask an assistant when the grid in South England will be cleanest tomorrow and get an answer read straight from a public forecast, which was most of what a carbon-reduction report used to charge for. A firm that responds by having a model write that report faster, from the same annual bills multiplied by the same annual average factor, has automated the part the customer no longer needs and kept the part that never moved a kilowatt-hour. The report arrives sooner; the fleet still charges at six in the evening, because that is when the drivers plug in, and the customer's assistant cannot reach the charger.
This design reaches the charger, and the batch queue behind it. It reads NESO's 48-hour regional forecast for the site's postcode, takes the deadline a person has set for each flexible load, and writes the lowest-intensity window that still meets that deadline to the charge controller or the job scheduler. Anyone on site can override a slot, and the log keeps the override and the reason. No load moves without a deadline a person chose. In the forecast fetched for South England on the evening of 16 October 2026, UK time, a three-hour fleet charge started on arrival on Saturday evening averaged 242 gCO2/kWh, and the same charge moved into the small hours of Sunday averaged 140. Those are forecast regional averages, not avoided emissions, and the report says so on every line: it keeps forecast apart from estimated actual, and each figure carries its source, its method and the time it was fetched.
A five-year strategy built on this, offered as a sketch rather than a plan, would sell the firm's judgment about flexibility instead of its paperwork about emissions: which loads on a customer's site can move, how far, against what deadline, and what the customer gives up each time one does. The scheduling should be routine within a year. The arguments about which loads may move, and who signs the override when a deadline slips, stay with people. A firm that keeps the method tag beside every figure can defend its numbers when an auditor, or the customer's own assistant, asks where they came from. A number without its method is an opinion.
See it run
Want one of these?
Every part of it is open source and self-hostable. What I bring is the build, the checks around the project's gaps, and the judgement about where your gates should sit.