What Is OpenADR? A Guide to Automated Demand Response
If you manage energy for a portfolio of buildings, run a SCADA or building automation system, or are scoping a demand response integration, you have almost certainly run into OpenADR. It is the protocol the grid uses to ask your loads to move — and increasingly, the one your utility or aggregator will require you to speak.
This guide explains what OpenADR is, the two flavours of demand response it carries, how the protocol actually works on the wire, who is using it, and how the 2.0a, 2.0b and 3.0 versions differ. It is written for the people who have to implement it, not just hear about it.
OpenADR in one paragraph
OpenADR (Open Automated Demand Response) is an open, IP-based standard for the automated exchange of demand response and dynamic price signals between energy providers and the loads that respond to them. It removes the human from the loop: instead of an operator reading an email and manually shedding load, a server publishes a structured event and your equipment reacts to it automatically, every time, in a way that can be measured and verified.
The standard began life at Lawrence Berkeley National Laboratory after the 2000–2001 California energy crisis, was funded by the California Energy Commission, and is now maintained and certified by the OpenADR Alliance. It is recognised by NIST as a key Smart Grid interoperability standard and by FERC as a foundational demand response standard. In practice, that recognition is why so many utility programs name it explicitly in their tariffs.
The two-node model: VTN and VEN
Every OpenADR deployment comes down to two roles:
- VTN (Virtual Top Node) — the server. This is operated by the utility, ISO/RTO, aggregator or DERMS platform. It publishes programs, events and prices.
- VEN (Virtual End Node) — the client. This sits on the customer side — in a gateway, a BMS, a controller, an EV charger, a battery inverter, or a cloud service representing many sites. It subscribes to the VTN, receives signals, and acts on them.
A VTN can serve thousands of VENs. A VEN can also act as a VTN to devices below it, which is how aggregators and DERMS platforms fan a single grid signal out to a fleet of sites. If you are the building or the load owner, you are almost always implementing the VEN side.
Reliability demand response vs price-responsive (economic) DR
OpenADR carries two fundamentally different kinds of signal, and understanding the distinction matters because they drive completely different control logic on your side.
Reliability (event-based) demand response is the grid asking you to reduce load because supply and demand are at risk — a heatwave, a generator trip, a transmission constraint. The VTN dispatches an event: start time, duration, and a level (often a simple LOW/MODERATE/HIGH signal, or a target kW reduction). You are expected to shed or shift a committed amount of load for that window, and you are typically paid a capacity payment to be available plus a performance payment for delivering. Non-performance usually carries a penalty. This is the classic "call an event, curtail the load" model that California's Auto-DR programs were built on.
Price-responsive (economic) demand response is the grid telling you what energy costs right now, and letting you decide what to do about it. Instead of an instruction to curtail, the VTN publishes a price — a dynamic tariff, a critical peak price, or a real-time market price — as a time series of intervals. Your VEN consumes that price stream and your own optimisation logic decides whether to run, idle, pre-cool, charge a battery, or shift a process. There is no penalty for "non-performance" because nothing was commanded; you simply respond to the economics. This is the model that suits battery storage, flexible industrial loads, and any site with a real optimisation objective.
The same protocol, and often the same VEN, handles both. What changes is the payload — a dispatch instruction versus a price forecast — and the intelligence you build behind it.
How OpenADR works operationally
A typical OpenADR lifecycle looks like this:
- Enrollment / registration. The customer is enrolled in a program (this part is usually out-of-band — paperwork, eligibility checks, meter validation). The VEN is then registered against the VTN and given credentials.
- Program and event publication. The VTN exposes one or more programs (e.g. a critical-peak-pricing program, an emergency curtailment program). When conditions warrant, it creates an event under that program with intervals, values and timing.
- Signal delivery. The VEN receives the event, either by polling the VTN (PULL) or by being notified (PUSH / webhook in 3.0). Events almost always arrive with advance notice — a day-ahead or hour-ahead notification window — so your systems can prepare rather than slam loads off instantly.
- Local execution. Your control system translates the signal into action: setpoint changes, sequenced load shedding, battery dispatch, generator start, process rescheduling. This logic lives on your side, not in the protocol.
- Opt-out and feedback. The customer can opt out of specific events (within program rules), and the VEN reports its intended participation back to the VTN.
- Telemetry and reporting. The VEN reports back — baseline data, real-time telemetry, and post-event measurement so the operator can verify performance and settle payments.
The protocol is deliberately agnostic about how you achieve the reduction. OpenADR defines the conversation between the grid and your edge; what happens downstream of the VEN — BACnet, Modbus, your SCADA points, your DERMS — is entirely up to you.
Which utilities and markets use OpenADR
OpenADR adoption started in California and spread from there. The three California investor-owned utilities — Pacific Gas & Electric (PG&E), Southern California Edison (SCE) and San Diego Gas & Electric (SDG&E) — built their Automated Demand Response (Auto-DR) programs on OpenADR and have required it for participating technology for over a decade. SCE's Auto-DR and PG&E's ADR program manuals both reference OpenADR directly as the communication standard for enrolled sites.
Beyond California, the same standard underpins demand response participation across most US markets, usually via an aggregator or DERMS layer that speaks OpenADR upstream:
- CAISO — the Demand Response Auction Mechanism and aggregator DR, plus utility AC-cycling programs.
- ERCOT — Emergency Response Service and controllable load resources.
- NYISO — Special Case Resources and day-ahead DR.
- ISO-NE — active demand capacity resources in the forward capacity market.
Internationally, OpenADR appears in DR and flexibility programs across Europe, Australia and Asia, and it is increasingly the protocol of choice for EV charging management, where a VTN coordinates whole charging networks and VENs represent individual stations or fleets.
The practical takeaway: if you want your load, battery or charger to participate in a utility or market DR program, OpenADR is very often the entry ticket — and a certified VEN is what gets you through the door.
In some jurisdictions, OpenADR capability is also written into building codes and energy regulations, so a certified VEN can be a compliance prerequisite for certain equipment — not just a way into a voluntary program.
A related benefit of building on an open standard: no vendor lock-in. Because the VTN–VEN interface is standardised, a utility or aggregator can move device connections to a different OpenADR server without re-engineering every endpoint, and a customer can change controls vendors without losing program eligibility. That portability is a large part of why the standard exists.
OpenADR 2.0a vs 2.0b vs 3.0
There are three versions you are likely to encounter. Choosing the right one is mostly about what your counterparty's VTN supports and what your device can carry.
| OpenADR 2.0a | OpenADR 2.0b | OpenADR 3.0 / 3.1 | |
|---|---|---|---|
| Released | 2012 | 2013 | 2023 (3.1 in 2025) |
| Intended for | Simple, low-cost devices (thermostats, basic loads) | Full utility DR, aggregators, telemetry | Modern EMS, DERs, VPPs, EV, in-building devices |
| Transport / format | XML, SOAP-style | XML, SOAP-style (EXI optional) | REST API, JSON |
| Reporting | Minimal | Full reporting & telemetry | Full reporting, webhooks/subscriptions |
| Security | Mutual TLS (mTLS) with certificates | Mutual TLS (mTLS) with certificates | Server-side TLS + OAuth2 client credentials |
| Push delivery | Limited | PUSH and PULL | Webhooks / message queue |
2.0a is a lightweight profile for resource-constrained devices. It handles basic event signals but has limited reporting, and you rarely choose it for new full-featured work today.
2.0b is the full-featured profile of the 2.0 generation. It adds full registration, opt/feedback, rich reporting and telemetry, and the PUSH/PULL delivery models that mature DR programs were built on, which is why a large installed base of older deployments runs on 2.0a/b. Its cost is complexity: XML payloads and mutual-TLS certificate management are non-trivial to implement and operate.
3.0 is a clean-sheet redesign aimed at the next decade. It drops XML and SOAP for a RESTful JSON API, replaces mutual-TLS certificate plumbing with server-side TLS plus OAuth2 client credentials, introduces a first-class program construct, supports webhooks for push delivery, and follows a "convention over configuration" philosophy that dramatically lowers the implementation burden — especially for the growing population of small, in-building VENs, DERs and EV chargers. 3.1.0, the current point release, refines the object model (for example, promoting resources to a top-level collection and tightening target-based authorization). Note that 3.1 is not backward compatible with 3.0, and neither 3.x version is wire-compatible with 2.0b — a 3.0 VTN and a 2.0b VEN cannot talk to each other directly.
In practice, 2.0a/b represents the established prior generation — widely deployed, but built on older XML/SOAP and certificate technology — while 3.0/3.1 is the direction the industry is moving, and where new EMS, DERMS, DER and EV integrations are being built. If you are starting fresh, 3.0 is the version designed for where the grid is heading.
Where to go from here
OpenADR is the connective tissue between grid operators and the loads, batteries and chargers that respond to them. Get the VEN right and your assets can earn from DR programs, follow dynamic prices, and stay compliant with utility requirements — all automatically. Get it wrong and you face certificate headaches, failed events, and missed payments.
If you are scoping an integration, the key decisions are: which version your counterparty's VTN requires (the 2.0 generation or the newer 3.0/3.1), whether you need certified compliance for a specific program, and whether you build the VEN in-house or deploy a pre-certified one and spend your time on the control logic that actually creates value.
[Optional CTA — adapt to your offering: If you'd rather skip the protocol plumbing, our pre-certified OpenADR VEN gets you connected to a VTN in weeks, not months. Talk to us about your program and stack.]
Frequently asked questions
Is OpenADR free to use? The specifications are published by the OpenADR Alliance, and you can implement against them. Formal certification (which many utility programs require) goes through the Alliance and its testing process, and Alliance membership applies for certain activities. Certification is not just a box-tick: the testing process catches real interoperability bugs, and uncertified VEN/VTN pairings are a common source of hard-to-debug field failures.
Do I need a VTN or a VEN? If you are a load, building, battery or charger owner participating in a program, you implement a VEN. If you are a utility, aggregator or DERMS platform dispatching others, you operate a VTN — and you may run a VEN upstream to your own provider at the same time.
Should I implement OpenADR 2.0 or 3.0? Match whatever the VTN you are connecting to supports — and note the two are not interoperable, so confirm before you build. 2.0a/b is the older generation behind many existing deployments, while 3.0/3.1 is the modern, REST/JSON redesign the industry is moving toward, and the natural choice for new projects.
Does OpenADR control my equipment directly? No. OpenADR delivers signals and prices to your VEN. Translating those into setpoints, load shedding or battery dispatch is your control system's job — which is exactly why it works across BACnet, Modbus, SCADA and DERMS environments.