EDNA Demand Flexibility Protocols (2026)

Issuer: IEA 4E Efficient, Demand Flexible Networked Appliances (EDNA) Platform, under the IEA Technology Collaboration Programme on Energy Efficient End-Use Equipment (4E TCP); authored by Viegand Maagøe.

Scope

A comparative review of application-layer communication protocols for residential appliance demand flexibility specifically — water heaters, heat pumps/HVAC, pool pumps/heaters, and whitegoods — with PV inverters, battery storage (BESS), and EV supply equipment (EVSE) included as already-standardized comparators. Sweden is a 4E TCP member country (listed once, in the boilerplate); the report contains no Sweden-specific case study or finding — the seven jurisdictions reviewed in depth are the UK, California, Australia, New Zealand, Germany, France, and the EU as a bloc.

The Control Specificity × Temporal Horizon matrix

The report’s central analytical contribution, applicable across protocols and jurisdictions. Two dimensions:

Control specificity (three layers):

• Layer 1 — Market signal: prices, tariffs, carbon intensity, grid status. Receiver decides how to respond.
• Layer 2 — Service-level instruction: a desired outcome (“shed 2 kW”) without specifying the method. Receiver chooses how.
• Layer 3 — Device-specific command: a precise setpoint or mode change. Sender has decided; device executes within safety limits.

Temporal horizon: real-time (seconds–minutes), near-term scheduling (minutes–hours), forward planning (hours–days). Forward planning is identified as the most valuable horizon for residential appliances with thermal storage or deferrable operation (e.g. pre-heating water before a price rise), since it delivers flexibility with minimal comfort impact — real-time response, by contrast, usually means interrupting service.

Central asymmetry (Finding 5): any protocol capable of Layer 1 (with two-way communication) can also support Layer 2–3 use cases, but a protocol designed only for Layer 2–3 command-and-control cannot later carry Layer 1 price-based signalling. A jurisdiction that harmonizes on a Layer 2–3-only protocol risks needing a second protocol to unlock price-responsive flexibility later. The report therefore argues for prioritizing Layer 1-capable protocols in harmonization efforts, without treating Layer 2–3 protocols as unnecessary — they remain essential for direct control and emergency curtailment.

A second, orthogonal distinction (drawn from Bruce Nordman’s work at LBNL): energy management (temporal balancing of supply/demand, served by Layer 1 price signals) vs. capacity management (physical constraints at a specific network point — a transformer or connection limit — served by Layer 2 constraint signals in near-real-time). Conflating the two domains leads to protocol choices that address one poorly; several case studies illustrate this (Australia’s CSIP-AUS designed for capacity-domain solar export management now expected to also support energy-domain DF; France’s PULSADIS applying a capacity-style mechanism to an energy-domain problem).

Protocol landscape

Three protocols identified as the only credible, actively-developed candidates with growing certification ecosystems for residential appliance DF: OpenADR 3, Matter (v1.5), EEBUS — explicitly framed as an emerging practical set, not a “winner-takes-all” mandate.

• OpenADR 3.1 (released September 2025) — modernized, lightweight (REST/JSON, webhook/MQTT delivery); strong for Layer 1–2 signalling and forward schedules; established alliance and certification programme. Traditionally “upstream” (grid/aggregator → HEMS/device), but the report notes this framing is increasingly an oversimplification — UK deployments use OpenADR 3.1 directly to devices, HEMS, and CEMS.
• IEEE 2030.5 — powerful for Layer 3 DER setpoints (inverters, batteries); heavier XML-based architecture requiring strict profiles (e.g. CSIP, CSIP-AUS) to be deployable at scale.
• Matter (v1.5) — leading general-purpose smart-home standard, massive industry backing (Apple, Google, Amazon, Samsung), most extensive certification programme of any protocol in this space; v1.5’s new energy-management clusters (Commodity Tariff, Commodity Price, Device Energy Management) extend it toward Layer 1, blurring the upstream/local boundary. Version-alignment risk noted: a Matter 1.3 controller may not use a 1.5 device’s new energy clusters.
• EEBUS — highly energy-specific device semantics (SPINE data model), de facto standard in Germany (via §14a EnWG / VDE-AR-E 2829-6), but SPINE’s 7,000+ possible message-pattern combinations have caused real interoperability challenges even within a single national market; smaller certification ecosystem, regionally concentrated.

Ten cross-cutting findings (from the seven-jurisdiction comparison)

1. Process matters as much as the protocol — purely technical decisions without multi-stakeholder input produce resisted (California FDAS) or poorly-adopted (Australia AS/NZS 4755) standards.
2. Specifications alone do not guarantee interoperability. California Rule 21 launched without reference implementations; Australia’s CSIP-AUS was certified inconsistently across individual network operators despite a shared nominal protocol, causing real interoperability failures — the report elsewhere describes this general pattern as “the appearance of harmonisation without the substance” (a phrase used in a different section, about regional protocol additions — not a direct quote about CSIP-AUS specifically, and “false harmonisation” verbatim does not appear in the report). Centralized, physical-testing certification is named as the single most important enabler of real interoperability.
3. Functional harmonisation (defining required device behaviours, not mandating a protocol — California’s FDAS model) may be more achievable than protocol harmonisation.
4. Two-way communication is essential for scalable DF — Australia’s one-way DRM signals can’t be verified, measured, or settled; California’s MIDAS is also currently one-way and utilities have flagged this as a gap.
5. Layer 1-capable protocols should be prioritized (see matrix above).
6. Protocols will keep changing — policy needs built-in review/transition mechanisms (the UK is already migrating from OpenADR 2.0b to 3.1 before full implementation).
7. No jurisdiction studied addresses all three control layers comprehensively.
8. Three viable protocol candidates are emerging (OpenADR 3, Matter, EEBUS) — see Protocol landscape above.
9. Jurisdictions should distinguish energy-domain from capacity-domain coordination when designing DF frameworks (see matrix above).
10. Uncoordinated regulatory requirements across government bodies create conflicting device-level obligations. Concrete example given: Germany’s §14a requires heat pumps to accept DSO curtailment commands (capacity domain) while the EU’s Network Code on Demand Response (submitted to the Commission March 2025) introduces requirements for heat pumps to provide frequency-response services (power-quality domain) — obligations that can conflict at the device level. Manufacturers report needing dedicated national compliance teams rather than building one product for the EU market, contributing to the limited uptake of the EU Code of Conduct for Energy Smart Appliances (10 signatories) and to manufacturer stasis generally.

Recommendations — five-phase pathway

1. Establish a shared analytical framework (near-term) — promote the matrix + energy/capacity domain distinction as a common vocabulary; map conflicting regulatory requirements across government bodies before they’re codified.
2. Layer 1 harmonisation — market signals (near-term) — a harmonized minimum price/tariff/carbon-intensity dataset, mapped to OpenADR 3 and Matter’s Energy Price cluster formats; explicitly not a single-protocol mandate.
3. Functional and performance requirements by device class (medium-term) — required flexibility services, response/telemetry, and consumer-override requirements per appliance type, protocol-neutral.
4. Protocol convergence through certification (longer-term) — internationally recognized, physically-tested certification (not self-declaration, which the report calls out as the EU CoC’s current weakness); explicitly cautions that certification alone doesn’t guarantee convergence (IEEE 2030.5 has mature certification and hasn’t converged the residential market).
5. Geographic alignment (long-term aspiration) — acknowledged as structurally hard (physical grid differences, national regulatory traditions, sunk infrastructure investment); realistic goal is harmonized functional/performance requirements rather than protocol uniformity.

EU-level context

Two EU initiatives shape the environment without resolving the protocol question: the EU Code of Conduct for Energy Smart Appliances (voluntary, April 2024, SAREF4ENER semantics, only 10/11 signatories, self-declared compliance, complete wire-level mappings only for EEBUS SPINE) and the EU Data Act (Regulation 2023/2854, in force from September 2025, access-by-design from September 2026 — mandates structured machine-readable data access but is technology-neutral and doesn’t specify DF protocols or semantics). The report’s assessment: the CoC builds the semantic layer, the Data Act the legal force, but the protocol layer between them remains unresolved.

Relevance to this wiki

Confirms and extends Flexibility Communication Protocols‘s existing framing (the E.ON/Ellevio OpenADR-divergence finding is a direct, independent parallel to this report’s Finding 2 — a shared nominal protocol without centralized certification still fails to guarantee interoperability). Flags a currency gap: the wiki’s OpenADR pages currently describe 3.0.1 as “recommended for new implementations” (Energiföretagen’s 2025 position); this report confirms OpenADR 3.1 (Sept 2025) is the current OpenADR Alliance release, though it does not indicate whether Energiföretagen’s Swedish recommendation has been revisited since 3.0.1.

Does not resolve: whether the EU’s Art. 24 EMD Implementing Act will mandate OpenADR specifically or stay technology-neutral; EEBus adoption trajectory in Sweden; S2 adoption outside the Netherlands; Ei’s own forthcoming DSO–customer communication föreskrifter. These stay open — see Flexibility Communication Protocols‘s Data gaps.