Methodology

Ampernomics replays your real half-hourly electricity usage against alternative tariffs, solar generation and battery dispatch — all on the same timeline. This page explains exactly what the model does, what data it uses, and where it makes simplifying assumptions.

It is intended as a complement to the How it works page, which gives a higher-level overview.

1. The principles behind the model

Everything below follows four rules:

Your real usage — we use your actual half-hourly consumption, not a synthetic profile.
Real prices — tariff prices come from the Octopus Energy API, including half-hourly Agile settlement prices.
One timeline — usage, prices, solar generation, and battery decisions all live on the same 30-minute grid.
No perfect hindsight — the battery is dispatched one day at a time. The optimiser sees only the prices and modelled solar that a real controller would know on the morning of that day.

The last rule matters. A model that sees the whole year up front systematically overstates what a battery can earn — especially small batteries, which a perfect-foresight optimiser can cycle several times a day to skim every short price spike. The way the simulation is structured (Section 6) deliberately removes that advantage.

2. Your data

We accept a year of half-hourly consumption (kWh) as a CSV — typically the file you can download from your supplier or from Octopus's API. We also ask for your postcode.

The postcode is mapped to a UK distribution region using the first one or two characters of the outward code. The region selects the right Octopus tariff variant and the right grid cell for solar irradiance. We do not use the postcode for anything else; raw consumption data is deleted within 24 hours (see the Privacy Policy for full retention details).

3. Tariffs

We model three tariff types, all sourced from real Octopus Energy products:

Price cap — the Ofgem-capped standard variable tariff. A flat unit rate plus a daily standing charge. This is the baseline most UK households are on.
Economy 7 — two unit rates: a cheaper night rate (00:00–07:00 local time) and a peak rate the rest of the day, plus a standing charge.
Agile — a half-hourly variable tariff. Prices are set the previous afternoon for each of the next day's 48 slots and can occasionally go negative when supply outstrips demand.

For each scenario we look up the real unit rate (or rates) and standing charge for every slot in your dataset, then cost your usage against them. No averaging, no extrapolation. Negative Agile prices are preserved end-to-end.

Where solar is included, exports are valued at Octopus Agile Outgoing rates, again pulled from the API.

4. Solar

We reconstruct what a south-facing array at your location would have generated using the Open-Meteo satellite irradiance archive, which is itself derived from Copernicus satellite data. For each hour we fetch the global tilted irradiance (GTI) on a panel oriented:

35° tilt
0° azimuth (due south)

For a system rated $P$ kWp, each half-hour slot's energy is:

E_{slot} = \frac{GTI}{1000} \cdot 0.5 \cdot P \cdot PR

where $GTI$ is the mean hourly irradiance in W/m², the factor of 1000 converts to kW (1 kWp is defined as the system's output at 1000 W/m² standard test conditions), 0.5 hr is the slot duration, and $PR = 0.77$ is a fixed performance ratio. The PR absorbs the losses a real system has — inverter and wiring losses, soiling, mismatch, temperature, angle of incidence, spectral and reflection effects. The value was calibrated against PVGIS hourly output for five UK postcodes across 2019–2023, which produced a mean implied PR of 0.774 (range 0.74–0.82) across 25 site-years.

The hourly figure is then split evenly across the two half-hour slots in the hour. We do not pretend to have sub-hourly satellite data; we just preserve the slot shape the rest of the model expects. To scale to your scenario we multiply by the system size in kWp.

5. Battery: shifting energy through time

A battery does not generate energy — it changes when you use it. We dispatch the battery using a linear program (LP), solved with the GLOP solver from Google OR-Tools. The LP plans one calendar day at a time (48 half-hour slots), then carries the resulting state of charge forward into the next day's plan.

For each slot $t$ the LP chooses how much energy to charge from PV and from the grid, how much to discharge to the load and to export, and how much PV to send directly to the grid. Subject to the physics:

\begin{array}{rcl} {soc}_{pv} (t) & = & {soc}_{pv} (t - 1) + η \cdot c_{pv} (t) \cdot Δt - (d_{load,pv} (t) + d_{export} (t)) \cdot Δt / η \\ {soc}_{grid} (t) & = & {soc}_{grid} (t - 1) + η \cdot c_{grid} (t) \cdot Δt - d_{load,grid} (t) \cdot Δt / η \\ {soc}_{pv} (t) + {soc}_{grid} (t) & \leq & Capacity \\ e_{pv} (t) + c_{pv} (t) \cdot Δt & \leq & {pv}_{excess} (t) \\ e_{pv} (t) + d_{export} (t) \cdot Δt & \leq & ExportLimit \cdot Δt \end{array}

Power-flow variables (the $c$ charge terms and $d$ discharge terms) are bounded above by the inverter's max-power rating. $Δt = 0.5$ h, and $η = \sqrt{round_trip_efficiency}$ is split across charge and discharge so the round-trip loss matches the spec.

The objective is to minimise net cost in pence over the 48 slots:

minimise \sum_{t} [p_{import} (t) \cdot g (t) - p_{export} (t) \cdot (e_{pv} (t) + d_{export} (t) \cdot Δt)]

Why two state-of-charge variables?

The LP tracks PV-origin and grid-origin charge separately ( ${soc}_{pv}$ and ${soc}_{grid}$ ). Only PV-origin charge is allowed to flow back out as export. This stops the model from buying cheap grid energy at midnight and "exporting" it as solar — a real installation cannot do that, and Smart Export Guarantee terms forbid it.

Default constraints

Round-trip efficiency: 90%
Inverter power scaled to battery size (800 W for 2 kWh, 3 kW for 5 kWh, 5 kW for 10 kWh)
Export limit: 3.68 kW (the standard G98 single-phase domestic limit)

6. Why we don't use perfect hindsight

If you give a single LP the entire year of prices and demand at once, it will find the absolute mathematical minimum cost. That number is interesting but no real battery controller could ever achieve it. It also disproportionately flatters small batteries: a perfect-foresight oracle can cycle a 2 kWh battery several times a day to skim every short Agile spike, but a real controller learns prices a day ahead at most and forecasts demand only approximately.

To mirror what a well-tuned real controller would actually do, the production simulation:

Builds a typical-day demand profile for your household: the mean kWh consumed in each of the 48 half-hour slots of the day, derived from your own data. If a slot has no samples, a UKERC PC01 domestic profile (scaled to your average) fills in.
For each calendar day, runs the LP with: your typical-day profile as the demand forecast; the real half-hourly prices for that day (genuinely known the previous afternoon for Agile); the real modelled PV for that day; and the actual state of charge carried over from the previous day.
Costs the resulting plan against your actual consumption for that day. Any gap between forecast and actual demand shows up as extra grid import or unused PV, just as it would on a real installation.

This is essentially what a "trained" residential controller does in practice. We tested rolling 30-day lookback forecasts against the typical-day profile and found the difference was within 1–4% of savings — small enough that the simpler typical-day profile is what runs in production.

7. The scenario grid

For every simulation we run a fixed grid of:

3 tariffs — price cap, Economy 7, Agile
4 solar sizes — 0, 1, 4, 8 kWp
4 battery sizes — 0, 2, 5, 10 kWh

That is 48 scenarios per simulation. Each scenario that includes a battery solves 365 daily LPs (48 slots each), so a full simulation is on the order of 13,000 LP solves. The scenarios run in parallel as separate queue messages on Azure Functions, so wall-clock time stays short.

8. Financial results

For each scenario we compute:

Annual cost — total imports priced at that scenario's tariff, minus any export revenue, plus the standing charge.
Saving vs your current setup — the difference between this scenario and the price-cap-with-no-solar-no-battery baseline.
Monthly cost breakdown — the same totals split by calendar month so seasonality is visible.

For scenarios that involve buying hardware (solar or battery), we also compute a net present value over a 20-year horizon at three discount rates (3.5%, 5%, 7.5%), assuming 0.5%/year solar degradation and one battery replacement at 70% of the original cost when its cycle budget is exhausted. NPV is intended as an honest comparison across scenarios, not a savings forecast.

Battery capex depends on whether solar is in the same install package. An installer fitting solar and a battery on the same visit shares an inverter and the electrician's on-site time, so a 5 kWh battery costs £3,300 alongside a roof solar install but £5,000 on its own; a 10 kWh battery is £6,000 with solar and £8,500 standalone. The plug-in 2 kWh battery is unaffected (no shared install work), and balcony solar doesn't qualify as a joint install. Each scenario uses the price that matches its configuration.

9. How the recommendation is chosen

Three picks, one headline

The recommendation widget shows three ways to read the same 48 configurations:

Recommended — our pick after balancing savings against upfront cost and right-sizing for your home.
Highest Return — the configuration with the highest 20-year NPV.
Cheapest — the configuration with the lowest annual bill. A factual statement; ignores upfront cost.

Click any of them to swap which configuration the page shows. You can also lock the tariff, solar size, or battery size individually — that overrides the engine's choice entirely and shows you a setup of your choosing.

How the "Recommended" pick is chosen

The engine is trying to answer one question: which of the 48 configurations is most worth paying for? Not the biggest saver — the best balance, sized for your home.

It works through six filters, in order:

Future options are set aside. Balcony solar (1 kWp) and Plug-in battery (2 kWh) aren't yet legal in the UK. They appear on the cards with a "future option" badge but aren't candidates for the headline. If you explicitly lock onto one, the page will show it.
Each upgrade has to pay for itself. For a given tariff, going from "no kit" to "4 kWp solar" has to earn back at least its capex in extra 20-year NPV — otherwise that configuration isn't a candidate. Same applies for any further step up.
Right-sizing: no power stations. Any configuration whose annual solar generation would exceed your household's annual consumption is dropped from contention. Solar is meant to offset your consumption — not turn your house into a small power station selling electricity back to the grid. (The configurations stay visible on the cards if you want to lock onto one; they just aren't recommended by default.)
Cheaper-and-better dominates. If one configuration costs less than another and has a higher NPV, the more expensive one is dropped. Why pay more for less.
Pick the best survivor per tariff. The highest-NPV configuration that passed steps 2–4 becomes the tariff's "best candidate".
Final tie-break by utility. Among the surviving best-candidates (plus the no-kit option for each tariff), pick the one with the highest "utility" — defined below.

The utility score

utility = 20-year NPV − capex friction, where the capex friction is 10% of the upfront cost.

Spending £10k on solar feels different to spending £2k, even when 20-year NPVs are similar: the bigger commitment ties up cash, raises the financing question, and lifts the stakes if anything goes wrong. The 10% knob says "every £1 of upfront cost is worth 10p of utility headroom" — modest, but enough to break ties when one configuration earns slightly more than another for materially more upfront. The configuration with the highest utility score wins the "Recommended" badge.

The story attached to the recommendation

Alongside the recommended configuration, the page tells you why — was the saving driven mostly by the tariff change, mostly by the solar, mostly by the battery, or a balanced mix. That sentence comes from a separate classifier that decomposes the annual saving into the three components and picks the dominant one if it accounts for more than 60% of the saving, otherwise calling it a mix.

Tunable knobs (for the curious)

Three numbers shape the engine's behaviour. None are user-facing; all are locked at sensible defaults; but they're worth knowing:

Capex weight (default 0.10) — fraction of upfront cost deducted from utility. Higher = the engine prefers smaller, cheaper setups.
Maximum gen-to-use ratio (default 1.0) — solar generation can be up to this multiple of household consumption before the configuration is flagged as oversized. 1.0 means "no recommended configuration generates more than it consumes annually". The default could be relaxed for households planning an EV or heat pump that will significantly increase future consumption.
Minimum marginal ROI (default 1.00) — the "is this upgrade worth it" bar in step 2 above. 1.00 means "the upgrade adds at least £1 of 20-year NPV per £1 of capex"; anything below 1.00 destroys NPV and is gated out.

10. Honest limits

No model predicts the future. Specifically:

Tariffs change. Today's Agile prices are not next year's Agile prices. The price cap moves quarterly. The model tells you what would have happened over the historical period in your data — it is a strong indicator, not a guarantee.
Weather varies. Solar generation depends on the actual irradiance that occurred. A sunnier or cloudier year would shift the numbers.
Behaviour can change. If you switch to a time-of-use tariff and start running the dishwasher overnight, your savings will be larger than the model predicts — the model assumes your usage pattern stays the same.
One PV configuration. We assume a single, unshaded, south-facing array at 35° tilt. Real roofs face many directions, often have shading, and may be split across pitches. East/west splits and shading would reduce generation.
Typical-day demand forecast. The LP plans against a typical day, not your actual day. On a day where you use much more or less than usual the dispatch is suboptimal — this is realistic, but it is not perfect.
No intra-day re-planning. Real controllers re-plan more often than once a day. We do not model this; the cost is small and well within other modelling uncertainties.
Battery degradation is simplified. We model end-of-life as a single capacity replacement at the cycle budget; real batteries degrade gradually over their life.

Despite these limits, replaying your real usage against real prices, real weather and a realistic dispatch model gives a much better picture than any "typical household" estimate.