OpenADR 2.0 is the protocol that makes automated demand response work at scale. If you are building software that participates in utility demand response programs — whether as a Virtual End Node (VEN) that receives curtailment signals or as a Virtual Top Node (VTN) that dispatches them — understanding how OpenADR's message model works is not optional. You will be implementing it from day one.
This guide covers the practical developer aspects: the core message flow, the difference between 2.0a and 2.0b, how registration works, and where teams tend to stumble.
The core OpenADR concepts
OpenADR is fundamentally a publish-subscribe protocol for energy events. There are two roles in every OpenADR exchange:
- VTN (Virtual Top Node) — The utility or demand response aggregator. Publishes events to enrolled participants.
- VEN (Virtual End Node) — The customer-side device or software system. Subscribes to events and responds with reports.
An "event" in OpenADR is a structured signal from a VTN that communicates a demand response instruction: reduce load by X kilowatts during this time window, or shift load to off-peak hours. The VEN receives the event, interprets it, and executes whatever load control actions are appropriate for its devices.
The VEN then sends "reports" back to the VTN confirming what happened: how much load was shed, when curtailment started and ended, what telemetry the devices produced during the event. This feedback loop is how demand response programs verify compliance and calculate settlement payments.
2.0a vs 2.0b: which do you need?
OpenADR 2.0a and 2.0b are both in active use, and the difference matters depending on which utilities you are integrating with.
| Feature | OpenADR 2.0a | OpenADR 2.0b |
|---|---|---|
| Transport | HTTP/HTTPS + XMPP | HTTP/HTTPS only |
| Payload format | OADR XML schema | OADR XML schema (extended) |
| Registration | Optional | Mandatory party registration |
| Report capability | Basic | Extended report types, TELEMETRY_STATUS |
| Typical deployment | Older utility programs | Newer programs, ISO/RTO dispatch |
Most new programs are built on 2.0b. But if you are targeting utilities in regions with older infrastructure — parts of the Southeast, some municipal utilities — you may encounter 2.0a deployments. Supporting both is not hard, but it means your parsing layer needs to handle both schemas.
The registration flow
In OpenADR 2.0b, a VEN must register with a VTN before it can receive events. The registration flow has three steps:
- oadrQueryRegistration — The VEN queries the VTN to discover its capabilities and the profiles it supports.
- oadrCreateRegistration — The VEN sends a registration request with its own capabilities (which OADR profiles it implements, what report types it can generate).
- oadrCreatedRegistration — The VTN responds with a registration ID that the VEN includes in all subsequent messages.
This sounds simple. In practice, the registration step is where a lot of integrations stall. VTN implementations vary in how strictly they validate registration payloads, and some utilities have out-of-band requirements (certificate provisioning, enrollment in a demand response program database) that must be completed before registration succeeds. We have seen teams spend two weeks on a registration step that should take two hours.
Event lifecycle: what your VEN needs to handle
Once registered, the VEN enters a polling loop — it sends oadrRequestEvent messages to the VTN and receives event payloads in response. Each event has:
- An event ID and modification number (to handle event updates)
- An active period (start time, duration)
- One or more intervals with signal values (the actual load reduction instruction)
- A response required flag (does the VTN expect an opt-in/opt-out response?)
Your VEN needs to track event state across its full lifecycle: Pending (event published but not yet active), Active (curtailment window is live), Cancelled (VTN cancelled before or during the event), and Completed. State transitions can come from updated VTN signals or from local timers reaching their expiry.
The response flow is equally important. If the event has oadrResponseRequired set, your VEN must send an oadrCreatedEvent with an opt-in or opt-out status. Utilities use this acknowledgement for program compliance tracking. Missing it can result in the VEN being counted as non-responsive.
Reports: the part that usually gets underbuilt
Demand response programs settle on reported telemetry, not on promises. The reporting leg of OpenADR is where the financial accountability lives, and it is the part that teams most often build as an afterthought.
OpenADR 2.0b defines several report types. The two you will use most often:
- TELEMETRY_USAGE — Interval meter readings reporting actual energy consumption. This is the primary settlement data for most demand response programs.
- TELEMETRY_STATUS — Device operational status reports. Used for programs that need to verify which devices participated in a demand response event.
Reports in OpenADR are streamed during and after events using oadrUpdateReport messages. Your VEN needs to collect device telemetry in real time during demand response events and format it correctly for the VTN. If your device layer is collecting data at 15-minute intervals and the program requires 5-minute interval reporting, that is a mismatch you need to design for upfront.
Demand response settlement is only as accurate as the telemetry you report. Build the reporting pipeline before you build the event handler, not after.
Transport and security
OpenADR 2.0b uses HTTP/HTTPS as its transport. The VEN makes HTTP requests to the VTN endpoint — there is no persistent connection to manage. The VTN does not push events to the VEN; the VEN polls for them.
Authentication is handled via TLS client certificates (the preferred option for production deployments) or HTTPS with out-of-band credentials. Most utility VTN implementations require certificate-based authentication for production enrollment. The certificate provisioning process varies significantly by utility — some have a self-service portal, others require manual procurement from their IT team.
One practical note: the polling interval matters. OpenADR does not specify a required polling frequency, but utilities expect VENs to poll often enough to receive events before their active period starts. A 5-minute polling interval is a reasonable baseline; some programs have requirements as tight as 1 minute for emergency curtailment events.
Testing before production
Most major VTN software vendors (OpenADR Alliance certified implementations) offer sandbox environments for VEN testing. Certifying your VEN against the OpenADR Alliance's conformance test suite is worth the effort if you are targeting multiple utility partners — it is much easier to debug protocol compliance in a controlled test environment than in a live demand response program with financial penalties for non-performance.
The DER market is projected to add hundreds of gigawatts of flexible load capacity in the coming decade. OpenADR is the protocol that coordinates that flexibility. Understanding it at the implementation level is foundational for any developer building demand response software.
