Devices and tariffs: data at the edge

Standards decide whether a heat pump is a source of portable data or a locked proprietary box. That is the whole argument of this section. The physical flexibility of a domestic asset is worth nothing to the system unless something can discover it, read its state, send it an instruction and record what happened, and none of those four things work reliably if every manufacturer invents its own vocabulary.

GB answered that with two published standards. PAS 1878:2021 sets out system functionality and architecture: what an appliance has to be able to do before it can be called an Energy Smart Appliance (ESA), and what the surrounding roles are. PAS 1879:2021 is its operational partner, a code of practice for how demand side response is actually run through those appliances: how signals are formed, sent, acted on and evidenced. One standard describes the shape of the system, the other describes its conduct.

Three roles carry the architecture. The ESA itself is the controllable asset: a heat pump, a battery, an electric vehicle charge point, in some cases a hot water cylinder. The Customer Energy Manager (CEM) is the device or software in the home that coordinates those appliances and decides which one runs when, given the household constraints. The DSR Service Provider sits outside the home, aggregating flexibility across many households and offering it into the markets you met in the previous module. Between them runs the data that this course cares about: capability declarations, state of charge, availability windows, dispatch instructions and the confirmation that an instruction was honoured.

Read the layering carefully, because it explains where the data quality problems live. The appliance layer produces raw device telemetry, which is fine-grained but inconsistent between manufacturers unless a standard forces the shape. The CEM layer turns that into a household-level picture, and it is the first place where a genuine aggregation decision is made: two appliances asking for power at once have to be sequenced by something. The service provider layer turns household pictures into a market-facing offer, which is the point at which the data acquires a commercial consequence and therefore an assurance requirement.

None of this replaces the metering chain you already know. The smart meter remains the settlement-grade instrument, its reads travel over the DCC network, and a Consumer Access Device (CAD) attached to the home area network (HAN) can give an app a local view of the same meter with the consumer permission you studied under privacy and consent. ESA data is a second, parallel stream: richer, faster, device-specific and, above all, not settlement evidence. Confusing the two is the most common analytical error at the edge of the system. A heat pump can tell you exactly what it intended to do; only the meter tells you what the supply point actually took.

The takeaway is a procurement one as much as a technical one. When a manufacturer says a product is smart, the question that matters is whether it conforms to the PAS 1878 architecture and can be operated under the PAS 1879 code of practice. If it does, its data and its controls are portable between service providers and survive a change of supplier. If it does not, the household has bought flexibility that only one company can ever sell.

When control signals move megawatts, the signal senders get regulated. That is the second argument of this module, and it follows directly from the first. Once a standards-based architecture lets one organisation address hundreds of thousands of heat pumps and chargers at once, the ability to send a message becomes an ability to move national demand. A software instruction with that reach is a system asset, and GB regulates system assets through licences.

The vehicle is the DESNZ Smart Secure Electricity Systems (SSES) programme. SSES has two halves. The first sets requirements for energy smart appliances themselves, so that devices sold into GB homes meet the interoperability, cyber security and data expectations that the PAS standards describe. The second, and the more interesting half for a data professional, addresses governance: who is accountable for the organisations that operate load control at scale, and under what enduring arrangements. The government response on SSES enduring governance set that direction.

Ofgem then consulted on implementing a load control licensing regime, running from December 2025 to February 2026. The proposition is that organisations sending load control signals to domestic devices should hold a licence with conditions attached, in the same way that supply, distribution and metering communications are licensed activities. Read that against the rulebook module: a licence condition is the instrument Ofgem can enforce directly, which is why obligations that must actually bite tend to end up there rather than in guidance.

For data work, licensing changes three things. It creates an identifiable, addressable population of controllers, which means the sector can finally count them and audit them. It attaches record-keeping and assurance duties to control signals, so the instruction and its outcome become evidence rather than private application logs. And it puts cyber security expectations on a path that can be enforced, which matters because a compromised load control channel is a demand-side attack surface with physical consequences.

There is a bridge here to the flexibility module you have just completed. Flexibility market registration is about knowing which asset exists and where it sits on the network. Load control licensing is about knowing which organisation is allowed to move it. Those are two halves of the same accountability question, and they are being answered by two different regulatory workstreams at roughly the same time. Anyone building a device data model should expect to carry both an asset identity and a controller identity, because the enduring arrangements will want to see each.

Comparison and automation services are being handed a public data rail. The tariff interoperability programme is not a nudge towards better disclosure; it is a staged construction of machine-readable price data as shared infrastructure, and it arrives on three dated steps rather than in one release.

The first step landed on 18 May 2026. Standard Licence Condition 11C and REC Schedule 35 require standardised, machine-readable tariff data. The significance is the pairing: the licence condition places the duty on the supplier, and the REC schedule carries the technical detail that says what the data has to look like. That is the GB pattern you have seen throughout this course, an obligation in the licence and a specification in the code, and it is why reading a code schedule is often the only way to know what a data obligation actually demands.

The second step is public tariff pricing interfaces from 18 February 2027. At that point the prices of tariffs that are on offer become programmatically available rather than merely published. The third step, consumer-specific tariff sharing, follows in November 2027 and is a different kind of thing entirely: it concerns the tariff a particular household is actually on, which makes it personal data and pulls it under the consent and lawful basis regime you studied earlier in the course. The ordering is deliberate and worth memorising, because it moves from standardising the format, to opening the generic prices, to sharing the individual arrangement.

Notice what each step unlocks. Standardisation alone kills a whole class of integration cost: a service that wants to reason about tariffs no longer needs a bespoke parser per supplier. Public pricing interfaces make automated comparison a commodity, which is the competition argument the programme rests on. Consumer-specific sharing is what makes genuine automation possible, because an optimiser cannot schedule a household asset intelligently unless it knows the actual prices that household will be charged, not the prices some tariff on the open market would charge.

This is also where devices and tariffs join up. A time-of-use tariff only creates value if something can act on it, and an ESA only creates value if it knows what the next few hours will cost. Standardised tariff data plus a standards-based control architecture is the pairing that makes household flexibility automatic rather than manual. Until both exist, tariff switching stays a human chore and load shifting stays a hobby.

One caution before the worked example. Machine-readable does not mean simple. A real tariff carries unit rates, standing charges, time bands, export terms where the household has an export arrangement, and conditions such as fixed term end dates. A standardised schema makes those fields findable; it does not make the commercial logic trivial. Expect the early integrations to get the simple half-hourly cases right long before they handle the awkward hybrid tariffs correctly.

The clearest way to see why any of this matters is to cost the same task at three different times of day. An Agile-style tariff publishes a unit rate for every half hour, aligned to the same Settlement Period clock that the whole market runs on, and open supplier interfaces make those 48 daily rates readable by any application. The hands-on module walked that data pull from the market side. Here we take the consumer side and ask the question a household actually has: when should the washing machine run?

Set up the load first, because a costing that treats an appliance as a single lump is wrong. A washing machine cycle of about ninety minutes does not draw evenly. Most of the energy goes into heating water at the start, and the later stages are mechanical and comparatively light. Take a 1.10 kWh cycle split across three consecutive half hours as 0.60 kWh, 0.35 kWh and 0.15 kWh. The unit rates below are illustrative figures chosen to show the method, not published prices, and the standing charge is excluded because it does not change with timing.

Start at 18:00, the evening peak

Rates of 32.0p, 30.5p and 28.0p per kWh give 0.60 times 32.0 = 19.2p, plus 0.35 times 30.5 = 10.7p, plus 0.15 times 28.0 = 4.2p. Total: about 34.1p.

Start at 13:00, the daytime shoulder

Rates of 14.5p, 13.8p and 13.2p give 8.7p, plus 4.8p, plus 2.0p. Total: about 15.5p.

Start at 02:00, the overnight trough

Rates of 8.2p, 7.9p and 8.0p give 4.9p, plus 2.8p, plus 1.2p. Total: about 8.9p.

The same 1.10 kWh costs roughly four times as much at the evening peak as it does overnight. Nothing about the appliance changed and nothing about the household changed. Only the timing did.

Three lessons come out of that arithmetic, and each connects to something taught earlier in the course. First, the weighting matters more than the total. Because 55 percent of the energy lands in the first half hour, the cost is dominated by the rate at the start time, which is exactly why a naive optimiser that costs a cycle at the average of three rates gets a different answer from one that models the load shape. Second, the half-hourly granularity is not a tariff design flourish; it exists because GB settlement is half-hourly, and under Market-wide Half-Hourly Settlement domestic consumption is settled on actual half-hourly reads rather than shaped estimates. The price signal a household sees and the volume the market settles are on the same clock.

Third, and this is the point of the module, the entire calculation depends on data availability at both ends. It needs forward tariff prices in a readable form, which is precisely what the tariff interoperability timetable is building, and it needs an appliance that can be told to start at 02:00 and will report that it did, which is precisely what the PAS 1878 architecture and the load control governance work are building. Today a motivated household can do this manually with an open tariff interface and a delay timer. The programmes described in this module are what turn that into a service that works for people who are not motivated, which is where the system value actually is.

One honest limitation to carry forward. Shifting a wash cycle saves pennies. The amounts become material when the load is large and routinely shiftable, which in practice means electric vehicle charging, heat pump preheating and home battery cycling rather than laundry. The washing machine is the teaching example because the arithmetic is transparent. The business case sits with the heavier assets, and that is where the flexibility markets in the previous module and the device architecture in this one actually meet.