From Cheap Slots to Coordinated Systems

The arrival of half-hourly dynamic tariffs in the UK domestic market has changed the economics of household energy flexibility. A customer on a tariff such as Octopus Agile is exposed to a wholesale-linked unit rate that is published for each thirty-minute period, can fall to zero or below during periods of abundant renewable generation, and rises sharply in the early-evening peak. For a household with an electric vehicle, a home battery, an air-source heat pump and a hot water cylinder, this price signal creates a genuine opportunity: a large fraction of the home's annual consumption is deferrable by hours without any loss of service, and if it is concentrated in the cheapest periods the average unit cost of that energy can be reduced to a fraction of the flat-rate equivalent.

The difficulty is that the opportunity is typically pursued asset by asset. The charger has its own smart scheduling feature, the battery inverter its own time-of-use or tariff-aware mode, and the heat pump controller a weather-compensated schedule with a boost option. Each of these, acting rationally in isolation, arrives at the same conclusion: use the cheapest slots. This audit deconstructs the failure that results, sets out the linear programming architecture that resolves it, describes the data and control infrastructure through which such a system is implemented, and quantifies the physical trade-offs between electrochemical and thermal storage that the optimiser must respect. It is written for home automation specifiers, energy systems engineers and low-carbon infrastructure developers who must integrate multiple assets behind a single, finite supply connection.

The Mathematical Failure of Naive Scheduling

Naive scheduling is the practice of assigning each controllable asset its own independent timer or price-threshold rule. The essential property that makes it fail is that the cheapest period is the same for every asset. In a typical Agile price series the lowest prices of the day cluster in a small number of consecutive slots in the early hours, when demand is low and, in windy weather, wholesale prices collapse. A rule that instructs each asset to use the cheapest available slots, or to charge whenever the price falls below a threshold, will therefore schedule all of them into the same window, such as the 02:00 to 02:30 UTC slot in this example. It should be noted that Agile data is published with UTC timestamps, so that this slot corresponds to 03:00 local time during British Summer Time, a detail that is a common source of off-by-one-hour scheduling errors in the integration layer.

Continuous Current Calculation

Consider a single-phase 230 V household with a 32 A electric vehicle charger, a 16 A battery inverter charging from the grid, and a 16 A air-source heat pump operating in a pre-heating mode, together with a background household load. The individual powers are 7.36 kW, 3.68 kW and 3.68 kW respectively, giving a total controllable demand of 14.72 kW or 64 A. A conservative night-time baseload of 1.5 kW adds approximately 6.5 A. The simultaneous supply current is therefore 32 + 16 + 16 + 6.5 = 70.5 A, equal to approximately 16.2 kW.

This figure must be compared with the capacity of the supply head. A 60 A cutout fuse, with a capacity of 13.8 kW, is overloaded by 10.5 A, or 17.5%. Because the conventional non-fusing current of a cartridge fuse is approximately 1.25 times its rating, a load of 70.5 A on a 60 A fuse will not necessarily operate the fuse promptly, which is precisely the problem: the assembly is held in a thermal regime outside its design basis, for the full duration of the cheap window and repeated nightly, with the accelerated ageing of the fuse element, carrier and terminations that this implies. An 80 A cutout, with a capacity of 18.4 kW, carries the load with a margin of 9.5 A, but if a 13 A immersion heater is also enabled in the same slot as part of a hot water pre-heat, the total rises to 83.5 A and exceeds the rating. The correct design limit is in any case lower than the rating, since continuous loads should be kept to a defined fraction of it, commonly 80%, to allow for measurement tolerance, ambient derating and uncontrolled loads.

Systemic Efficiency Penalties

The consequences are not limited to the supply head. Where a hardware load limiter is installed, as it should be, the limiter will curtail the assets when the aggregate current approaches its threshold, and the curtailment is applied without knowledge of the price curve. In the example, with a limit of 64 A and the baseload of 6.5 A, the available capacity for flexible loads is 57.5 A or 13.2 kW, equal to 6.6 kWh per half-hour slot. The three assets request 14.72 kW, which is 7.36 kWh per slot, in each of the two cheapest slots, so that approximately 0.76 kWh per slot is curtailed and must be delivered later. Each asset's own scheduler considers its plan to have been executed, or falls back to the next cheapest slot it can find, which may be hours later. In a stylised overnight price curve in which the cheapest slots are priced at 4 to 5 p/kWh and the fallback slots at 15 to 18 p/kWh, the displaced 1.5 kWh costs approximately 20 pence more per night than if it had been placed in the next cheapest free slot, a figure that accumulates to a material amount across a year of nightly events.

The more serious penalties are physical. A charger that is throttled by an external limiter repeatedly changes its pilot signal and may suspend charging, which causes the macro-cycling and handshake overhead described elsewhere in this series, and it forces the on-board charger to operate in its least efficient low-current region. A heat pump that is interrupted during a pre-heat cycle may lock out on a low-flow or protection fault. A battery inverter that is starved by a collapsing supply voltage may trip on an under-voltage or over-current condition. Voltage drop in a long or shared service cable, which is proportional to current, falls with the load and recovers as the load decreases, so that the oscillation introduced by the interaction of limiters and schedulers can produce a hunting behaviour that is itself damaging.

It should also be stated plainly that a standard domestic Agile tariff has no demand charge or capacity-based penalty. The financial risk of a simultaneous spike arises from the displacement cost described above, from the consequences of any trip or interruption, and from tariffs and flexibility schemes, in the commercial and some emerging domestic offerings, that include a capacity element or an import-limit commitment. The primary risk to the average household is therefore physical rather than tariff-based, but the same coordination solution addresses both.

Linear Programming and Objective Function Architecture

Coordinating the assets is a classical optimisation problem. Linear programming (LP) provides the framework: it finds the values of a set of decision variables that minimise a linear objective function, subject to linear equality and inequality constraints, and does so with solvers that return a provably optimal solution in milliseconds for a problem of this size. A domestic problem with a 48-slot half-hourly horizon and a handful of assets has a few hundred variables and constraints, which is trivial for a modern solver such as HiGHS, CBC or GLPK.

Decision Variables and Objective

Divide the horizon into slots t = 1 to T of duration Δt hours. The decision variables for each slot are the electric vehicle charging power pev(t), the battery charge power pch(t) and discharge power pdis(t), the heat pump electrical power php(t), the electrical power directed to the hot water element or cylinder pdhw(t), the grid import g(t) and the grid export e(t), all in kilowatts and all non-negative. The prices are πimp(t) and πexp(t), in pounds per kilowatt-hour, taken from the tariff data. The objective function is the net cost over the horizon:

minimise the sum over t of Δt × [ πimp(t) × g(t) − πexp(t) × e(t) + cdeg × (pch(t) + pdis(t)) ]

The final term is a battery degradation cost per kilowatt-hour of throughput, which prevents the optimiser from cycling the battery for margins that do not repay the wear. If the battery has a replacement cost of the order of 400 pounds per kilowatt-hour and a cycle life of 6,000 cycles, the throughput cost is approximately 6.7 pence per kilowatt-hour, and with a round-trip efficiency of 90% the break-even condition for a charge-discharge cycle is that the discharge value is at least (charge price + degradation cost) divided by the efficiency, which at a charge price of 5 p/kWh is approximately 13 p/kWh. Spreads narrower than this destroy value, and the optimiser will correctly decline to trade them.

Constraints

The nodal energy balance links every asset to the grid connection in each slot: g(t) − e(t) = L(t) + pev(t) + pch(t) − pdis(t) + php(t) + pdhw(t) − PV(t), where L(t) is the forecast uncontrolled household load and PV(t) the forecast solar generation. This single equation is what couples the otherwise independent problems of the individual assets.

The battery state of charge evolves according to SoC(t+1) = SoC(t) + ηc × pch(t) × Δt − pdis(t) × Δt / ηd, with limits SoCmin ≤ SoC(t) ≤ SoCmax that preserve both a reserve for outages and the longevity of the cells, and power limits 0 ≤ pch(t) ≤ Pch,max and 0 ≤ pdis(t) ≤ Pdis,max. The vehicle has a similar energy state, Eev(t+1) = Eev(t) + ηev × pev(t) × Δt, with the departure constraint Eev(tdep) ≥ Etarget, which converts the user's requirement, such as 80% by 07:30, into a hard inequality, and with pev(t) = 0 after plug-out. A feature that deserves attention is the minimum charging current: the IEC 61851 control pilot does not permit a current below 6 A, so that pev is either zero or between 1.38 kW and 7.36 kW. This semi-continuous behaviour is non-convex and is properly modelled with a binary on-off variable, which converts the problem to a mixed-integer linear program, or MILP. The MILP remains small enough to be solved in seconds, and a continuous relaxation followed by rounding is a common practical simplification.

The thermal constraints apply the same logic to the building and the hot water cylinder. The building is represented by a lumped thermal-capacitance model: C × (Tin(t+1) − Tin(t)) = Δt × [ COP(t) × php(t) − UA × (Tin(t) − Tout(t)) ], where C is the effective thermal capacitance in kWh per kelvin, UA the heat loss coefficient in kW per kelvin, and Tout(t) the forecast outdoor temperature. Because the coefficient of performance depends on the outdoor temperature and the flow temperature, it is supplied as a fixed forecast value for each slot, which keeps the constraint linear. Comfort is enforced by Tmin ≤ Tin(t) ≤ Tmax, with the occupied and unoccupied limits varying by slot. The cylinder is treated as an energy store with a standing loss and a demand profile, and with a periodic constraint for the temperature required for legionella control.

The constraint that makes the approach genuinely co-optimising is the supply limit: g(t) ≤ Ilim × V / 1000 for every slot, in which Ilim is the configured current limit, set below the rating of the weakest element in the supply chain. With this constraint in place, the optimiser will spread the energy requirement across the cheapest slots that the connection can accommodate, rather than concentrating it in the cheapest slot. Returning to the stylised example, with a capacity of 6.6 kWh per slot and a total flexible requirement of 36 kWh (for example 24 kWh for the vehicle, 8 kWh for the battery and 4 kWh of thermal pre-heat), the minimum number of slots is 5.5, and the optimiser fills the six cheapest slots in rank order. With an illustrative overnight price curve of 12, 10, 8, 6, 4, 5, 7, 9, 11, 13, 15 and 18 p/kWh for the twelve slots from 00:00 to 05:30, the cost is approximately £2.25, at an average of 6.25 p/kWh, with no slot exceeding the limit.

A valuable by-product of the LP is the dual variable, or shadow price, of the supply constraint. This is the amount by which the objective would improve for each additional kilowatt of supply capacity, and it therefore quantifies, in pounds per kilowatt per year, the value of a network upgrade or a larger service head. If the shadow price is persistently zero the constraint is never binding and the connection is adequate. If it is high, the case for reinforcement can be made with the household's own data.

Receding-Horizon Operation

Forecasts are uncertain, so the problem is solved repeatedly in a receding-horizon, or model-predictive, scheme. At each interval, typically every 5 to 30 minutes, the controller updates its state estimates from the measured battery state of charge, vehicle state, indoor temperature and cylinder temperature, refreshes the forecasts, solves the optimisation over the remaining horizon, applies only the first step's decisions and repeats. This feedback absorbs forecast errors, a plugged-in vehicle with a different starting state of charge than expected, or a change in the occupants' behaviour. Open-source implementations of this architecture exist for Home Assistant, such as the EMHASS add-on, and can be adapted to local requirements.

API Webhook Control Loops and Edge Gateway Infrastructure

The optimisation is only as good as the data it receives and the reliability with which its decisions are executed. The control architecture consists of four layers: a data acquisition layer that retrieves prices and forecasts, a state estimation layer that reads the assets and the meter, the optimisation layer, and an actuation layer that writes set points to the assets.

Acquiring the Tariff Data

The Octopus Energy public API exposes the unit rates for each product and tariff as a JSON document. A request to the standard-unit-rates endpoint for the relevant product and tariff code, with optional period_from and period_to parameters, returns a results array in which each element has the fields value_exc_vat, value_inc_vat, valid_from and valid_to, with timestamps in UTC and values in pence per kilowatt-hour. The prices for the following day are normally published in the late afternoon, so that a scheduler can plan the next 24 hours or more by mid-evening. Several practical points govern the implementation: the product and tariff codes change with each revision of the product and should be configurable rather than hard-coded, results are paginated and the next link must be followed, the timestamps must be handled in UTC and converted for display only, and the integration must handle the case in which the data for the next day has not yet been published by retaining the last known plan and falling back to a safe default schedule.

Parsing and Orchestration in a Local Environment

Local automation platforms such as Home Assistant and openHAB provide the integration layer. The tariff data may be ingested by a dedicated integration, or by a REST sensor that polls the endpoint, and is exposed as an attribute list of price and time pairs. The optimiser, which may run as an add-on or an external service, consumes these data together with weather and solar forecasts and the live measurements, and returns a schedule of set points for each asset for each slot. Automations or a state machine then apply the set point for the current slot.

Control is exercised through the interfaces that the assets expose. Many inverters and heat pumps support Modbus over TCP or RS-485, and set points are written to holding registers. Vehicle chargers commonly support the Open Charge Point Protocol (OCPP) or a vendor REST API. Others are controlled through MQTT, or a manufacturer's cloud, which adds latency and a dependency on an external service. A local Modbus write completes in tens of milliseconds, and a local REST call in a comparable time, so that the loop is limited not by the transport but by the update interval of the measurement and the response time of the asset itself, which is typically a few seconds. Describing the loop as sub-second is therefore accurate for the transport, while the effective control interval is generally one to ten seconds for the protective layer and minutes for the economic layer.

Layered Protection and Failure Modes

The architecture should separate the economic layer, which decides when to consume, from the protective layer, which ensures that the supply limit is never exceeded. The protective layer should operate on a short interval, using a current transformer on the incoming tails, and should be capable of acting independently of the optimiser, so that the loss of the optimiser, the gateway or the internet connection leaves the household in a safe state. Where possible, the protection should be duplicated in hardware, with the charger's own load-management input providing a second line of defence. The behaviour on communication failure must be defined and tested for each asset: the charger should default to a minimal current or to suspension, the battery inverter to its self-consumption mode, and the heat pump to its native weather-compensation curve.

Two further cautions are worth recording. First, several inverters store certain configuration registers in non-volatile memory with a finite number of write cycles, so that writing a set point every few seconds to such a register can shorten the life of the device, and writes should be restricted to volatile control registers or throttled to changes only. Second, the cloud-based APIs offered by manufacturers are subject to rate limits, outages and changes without notice, and should be treated as a convenience rather than a foundation for a safety function.

Comparative matrix: automation framework tiers for half-hourly dynamic tariff arbitrage (illustrative planning ranges)
Automation Framework Tier Data Integration Vector Multi-Asset Coordination Mechanics Local Infrastructure Overload Protection Realised Financial Arbitrage Efficiency (share of perfect-foresight optimum)
Tier 1: asset-isolated schedulers (charger app, battery app, heat pump timer) Manufacturer cloud or app, each with its own tariff feed or fixed time window None: each asset independently targets the cheapest slots, producing convergence and simultaneous peaks Minimal: relies on the asset's own limits and on the supply fuse Approx. 40% to 60%, with the loss concentrated in curtailment, fallback to dearer slots and missed negative prices
Tier 2: rule-based local gateway (Home Assistant or openHAB threshold automations) Direct tariff API or integration; local Modbus, REST, MQTT or OCPP control Priority ordering and staggered start times; static, with no forward-looking trade-offs Good if a CT-based limiter is configured; reactive rather than predictive Approx. 60% to 80%, limited by the lack of forecasting and by rigid priorities
Tier 3: predictive LP or MILP co-optimisation with receding horizon Tariff API, weather and PV forecasts, live state of charge, thermal and meter data over local interfaces Unified objective and shared supply constraint; storage, thermal and vehicle states optimised jointly Supply limit embedded in the optimiser, with an independent fast-acting protective layer Approx. 80% to 95%, dependent on forecast quality and model fidelity
Tier 4: aggregator or flexibility-market participation Aggregator platform and market signals in addition to the local tariff data Portfolio dispatch; household constraints expressed to the aggregator and enforced locally Local limits retained; export and import commitments added Variable: additional revenue streams, offset by the aggregator's share and by reduced control

The efficiency ranges in the matrix are illustrative planning figures, expressed relative to a hypothetical perfect-foresight optimum for the same assets and tariff, and not measurements of any specific product. There is no standardised benchmark for these systems, and actual results depend on the tariff volatility in the period, the size of the storage relative to the load, the household's usage pattern and the forecast quality. The ordering of the tiers, and the identification of coordination as the principal source of the difference, are the points of engineering substance.

Electrochemical versus Thermal Storage Co-Optimisation

The household offers two distinct forms of storage to the optimiser, and their physical characteristics determine how load can be shifted. Electrochemical storage, in the battery and the vehicle, is energy-dense, flexible and fast, but has a round-trip efficiency of the order of 90% and a wear cost per cycle. Thermal storage, in the hot water cylinder and the building fabric, is cheap and has no cycle wear, but is subject to standing losses, limited temperature ranges, and a slower and less controllable response.

Domestic Hot Water

A 200 litre cylinder heated through 35 K stores m × c × ΔT = 200 × 4.18 × 35 / 3,600, which is approximately 8.1 kWh of thermal energy. If this energy is supplied by a 3 kW immersion element, with a coefficient of performance of 1, it requires 8.1 kWh of electricity and approximately 2.7 hours of full-power operation, equal to 13 A of additional supply current. If it is supplied by the heat pump in hot water mode, where the higher flow temperature of 50 to 60 degrees Celsius reduces the coefficient of performance to the region of 2.0 to 2.5, the electrical requirement is 3.2 to 4.1 kWh, at a lower current, but with the heat pump unavailable for space heating during that time. Standing losses for a well-insulated cylinder are commonly of the order of 1 to 2 kWh per day, which is the cost of storing the heat for use later in the day and which sets a limit to the benefit of shifting the heating far in advance. The optimiser must also schedule the periodic high-temperature cycle for legionella control, a constraint that can be satisfied at the cheapest convenient time.

Screed and Underfloor Heating

A concrete or anhydrite screed floor is a substantial thermal mass. A 100 square metre floor with a 65 mm screed contains approximately 6.5 cubic metres of material, or approximately 13 tonnes at a density of 2,000 kg per cubic metre, with a specific heat capacity of approximately 0.9 kJ per kilogram per kelvin, giving a capacitance of approximately 3.3 kWh per kelvin. Pre-heating the slab by 2 K therefore stores around 6.5 kWh of thermal energy, which can maintain comfort for several hours, as the time constant of a heavy screed is long. This is a powerful flexibility resource, but it responds slowly, it cannot be cooled on demand, and an overshoot beyond the comfort band is both wasteful and a quality-of-service failure. The optimiser must therefore treat the response lag explicitly, either by lengthening the model's time constant or by constraining the rate at which the slab temperature may be raised.

Balancing the Two Against the Supply Limit

The two forms of storage compete for the same supply capacity in the same cheap slots. A 10 kWh battery charging at 16 A, or 3.68 kW, requires approximately 2.7 hours to fill from empty, while the vehicle may require several hours more, and the heat pump, to deliver a pre-heat or a hot water cycle, draws a further 3.68 kW. If these requirements are met without coordination, the thermal penalty arises in two ways. In the first, the supply limit forces the heat pump to be interrupted or reduced, so that the heating or hot water cycle is incomplete and the system falls back on a direct electric element at a coefficient of performance of 1, in the more expensive period. In the second, the heat pump is operated at a higher flow temperature for hot water at precisely the time when the capacity is scarce, reducing the heat delivered per ampere of supply current. The LP resolves this by allocating the scarce current in the cheapest slots to the loads that deliver the greatest value per ampere, and the heat pump, with a coefficient of performance of 2.5 to 4, delivers two and a half to four times as much thermal energy per ampere as an immersion element, so that it generally takes priority over resistive heating, while the battery, which has no time-critical deadline, is filled in the residual capacity.

The battery also has a role in relieving the constraint. Charging it in the cheapest slots and discharging it to supply the household's own load in the more expensive evening period reduces the peak import at the connection. The optimiser can decide, for example, to discharge the battery to carry the heat pump through the evening peak rather than import at the highest prices, subject to the break-even spread described earlier. In summer the same architecture uses solar generation as an additional low-cost source, with the optimiser balancing export revenue against self-consumption.

Specification Guidance for Practitioners

Several practical conclusions follow from this analysis. First, the supply connection must be characterised before any automation is designed: the cutout rating, the service cable, the meter tails and the existing loads determine the current limit that the optimiser will be required to respect. Second, a protective load-limiting layer with an independent CT measurement should be installed in all multi-asset homes on dynamic tariffs, irrespective of the sophistication of the optimisation above it. Third, the tier of automation should be matched to the scale of the opportunity: for a single asset on a dynamic tariff an asset-native scheduler is adequate, whereas for two or more assets sharing a connection a coordinated approach is required. Fourth, a predictive optimiser should be validated against historical tariff data before deployment, with the actual import costs compared against those predicted by the model and the shadow price of the supply constraint recorded.

Finally, the failure behaviour must be commissioned as carefully as the nominal behaviour. The system should be tested with the internet connection removed, with the gateway powered down, and with each integration disabled in turn, and the resulting behaviour of each asset should be documented. A coordinated, constraint-aware optimiser can capture most of the value that a dynamic tariff offers while keeping the household within the limits of its infrastructure; an uncoordinated collection of individually clever schedulers will, on the cheapest night of the year, discover those limits for itself.