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 kinds 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 exchanging 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. NIST recognizes it as a key Smart Grid interoperability standard, and FERC lists it as a foundational demand response standard. That recognition is a big part of 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, 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 own the building or the load, you are almost always implementing the VEN side.

Reliability demand response vs price-responsive (economic) DR

OpenADR carries two fundamentally different kinds of signal. 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 with a 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. In return you typically earn a capacity payment for being available plus a performance payment for delivering, and 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 optimization 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 model suits battery storage, flexible industrial loads, and any site with a real optimization 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:

1. Enrollment / registration. The customer enrolls in a program, either directly with a utility or via an aggregator. This part is usually out-of-band: paperwork, eligibility checks, meter validation. The VEN is then registered against the VTN and given credentials.
2. Program and event publication. The VTN exposes one or more programs, such as a critical-peak-pricing program or an emergency curtailment program. When conditions warrant, it creates an event under that program with intervals, values and timing.
3. Signal delivery. The VEN receives the event, either by polling the VTN (PULL) or by being notified (PUSH, or a webhook in 3.0). Events almost always arrive with advance notice, whether day-ahead or hour-ahead, so your systems can prepare rather than slam loads off instantly.
4. 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.
5. 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.
6. 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, whether that's BACnet, Modbus, your SCADA points or 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 name OpenADR 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. It is also becoming 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. A certified VEN can be a compliance prerequisite for certain equipment, not just a way into a voluntary program.

There is a related benefit to building on an open standard: no vendor lock-in. Because the VTN-VEN interface is standardized, 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 mostly comes down to what your counterparty's VTN supports and what your device can carry.

2.0a is a lightweight profile for resource-constrained devices. It handles basic event signals but has limited reporting, and you would 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 still 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. 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 lowers the implementation burden considerably, 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. 3.0/3.1 is where the industry is heading, 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 going.

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-built one and spend your time on the control logic that actually creates value.

Get connected in weeks, not months

You don't have to build any of this from scratch. Daydream Energy offers ready-made OpenADR modules that handle the protocol layer for you: VEN connectivity for OpenADR 3.0 and 2.0b programs, registration and OAuth2/certificate management, event handling, and the reporting and telemetry your program requires. Drop a module into your stack, point it at your utility or aggregator's VTN, and spend your engineering time on the dispatch logic that earns the revenue.

Explore the Daydream Energy modules or get in touch to talk through 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. 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.