OpenADR Integration

Skip key takeaways

Updated October 4, 2026

• The platform is the VEN, the station is driven over OCPP A CSMS or DERMS plays the client role toward a VTN that a utility, operator or aggregator runs.
• OpenADR 3 adds a REST and JSON protocol without retiring 2.0b After the Alliance's six-month grace period a commercial VTN must implement both 2.0b and 3 to certify.
• Five objects and one transport choice carry the whole interaction Programs, events, reports, VENs and resources travel over REST with OAuth, delivered by webhook, polling or the MQTT or WebSocket channel LF Energy's VTN offers.
• Interval to charging profile is the mapping you own Each event interval becomes an OCPP 2.0.1 SetChargingProfile, a capacity limit as a station ceiling and a price series through the optimizer.
• Certification tests the interface, never the logic behind it The Alliance tests only the VTN to VEN exchange, leaving the scheduler, the OCPP mapping and the fallback behavior outside its program.

Copy takeaways

OpenADR integration puts a charging or energy platform on the receiving end of grid signals. An operator or an aggregator publishes a price series or a capacity limit, and the platform has to turn each interval into something a charging station or a DER controller can execute, then report back what it delivered. The OpenADR Alliance states the scope of the standard: "OpenADR standardizes the message format used for Auto-DR and DER management so that dynamic price and reliability signals can be exchanged in a uniform and interoperable fashion among utilities, ISOs, and energy management and control systems." The Alliance's own scope statement stops at the message format; how a CSMS or a DERMS acts on those messages is platform engineering.

In short: In this design the platform is the VEN, not the charger. It obtains an OAuth token from the VTN or from the identity provider the VTN operator designates, registers itself and its resources, then works with five REST objects (programs, events, reports, VENs and resources) plus subscriptions where the VTN supports webhooks. OpenADR 3 is RESTful, with JSON messaging in LF Energy's description of 3.1, while the older 2.0b profile is XML with polling. Every event interval maps to an OCPP charging profile or a DERMS setpoint through logic you own, and the Alliance certifies the VTN to VEN exchange, not that logic and not what a VEN does when its VTN stops answering, so the outage behavior is yours to design.

Where OpenADR sits in a charging platform

The protocol defines two roles and leaves the software behind them to the implementer. The Alliance's FAQ describes both: "A VTN is typically a “server” that transmits OpenADR signals to end devices or other intermediate servers." and "A VEN is typically a “client” and can be an “Energy Management System” (EMS), a thermostat or other end device that accepts the OpenADR signal from a server (VTN)." A charging platform is a VEN in this picture, and so is a DERMS that takes signals from a utility.

Where the VTN lives decides who your counterpart is. The Alliance's certification process page places it inside the systems that manage distributed resources: "Each VTN can have 1-N VENs. Commonly VTNs are part of a resource management system like a DERMS." The same page adds that a VEN need not be a device: "VENs can be simple devices like load controllers, thermostats or more powerful implementations like energy management systems or aggregator level control servers." A CSMS with a smart-charging engine is that aggregator level control server; where a DERMS sits relative to the CSMS is covered in our energy software development guide.

One system can hold both roles. The FAQ covers the case: "A VTN and VEN can be the same device. For example a DR aggregation server can act both as a VEN for a utility DR signal, and as a VTN for end devices." That chaining is a charge point operator that receives a capacity profile and redistributes it to sites. Whether the platform also acts as a VTN toward its own assets is a design choice, and where the stations speak OCPP the answer is no, because the station is driven over OCPP rather than OpenADR.

LF Energy's EV use case puts a CPO platform in the VEN role. On its OpenLEADR project page, "Dutch Distribution System Operators (DSOs) will use OpenADR 3.1 to send static and dynamic grid capacity profiles to Charge Point Operators (CPOs)" appears as a grid-aware charging scenario.

Which OpenADR version to target

Two generations of the protocol are live, and the newer one does not retire the older. The Alliance is explicit on its OpenADR 3 page: "The OpenADR 3 Standard (“OADR 3”) is not intended to replace the OpenADR 2.0a/b Profile Specifications. Rather, it provides an additional, simplified way to add OpenADR functionalities in current, as well as different and new scenarios." The same page names the three documents in the package: the OpenADR 3 OpenAPI YAML Specification is the normative reference and supersedes any other document, while the OpenADR 3 Definitions define the information models, enumerations and security aspects, with the information model duplicated from the YAML in readable form. A third document, the OpenADR 3 User Guide, walks through scenarios the Alliance labels illustrative rather than normative.

The Alliance's own pages call the standard OpenADR 3 or OpenADR 3.0, and none of the six pages read for this article mentions a 3.1. LF Energy names 3.1 throughout and states that its Rust implementation targets 3.1. Its openleadr-rs README carries a warning to read before you pin a dependency: "Please note that OpenADR 3.1 is not backwards compatible with OpenADR 3.0." Treat OpenADR 3 as the family name, ask each VTN operator which revision its server implements and test against it.

Registering the VEN and authenticating

In OpenADR 3 the VTN is an HTTP server and the VEN a REST client, so the VEN can be written in any language. LF Energy's openleadr-rs README describes its client library the same way: "The VEN is a library for conveniently interacting with the REST API provided by a VTN." Registration creates or updates the VEN object on the VTN. Expect the VTN operator to hand you the VEN's identity and credentials out of band. Each station, EVSE group or DER unit the VEN controls is then a resource under that VEN.

Authentication is OAuth. The same README notes that "The VTN implements its own OAuth provider, which is mainly relevant for testing and prototyping." and that the VTN can be configured to use a third-party OAuth provider instead. A VEN is a machine client with no user in the loop, so a client-credentials style grant is the natural fit. Which grant and which scopes a VTN offers are stated in the OpenADR 3 OpenAPI specification and in the operator's configuration, so read both.

The specification comes from the Alliance's specification page after a short form; the download links arrive by email, and the specifications are license free, though copyright of the Alliance and subject to its terms. Keep the client secret in the platform's secret manager and treat token refresh as part of the VEN's health check, because an expired token looks exactly like an unreachable VTN.

Programs, events, reports and subscriptions

Five objects carry the data model. The openleadr-rs README lists them as what its VTN and VEN handle: "The client and server do support creating, retrieving, updating, and deleting programs, events, reports, VENs, and resources." As the OpenADR 3 User Guide and Definitions describe them, a program is the enrollment context the VTN operator sets up for a tariff, a capacity-management scheme or a demand-response campaign, an event belongs to a program and is the signal itself, a report is what the VEN sends back and a resource is an asset under the VEN that an event can target and a report can describe.

Resources can also nest. The openleadr-rs README states that a resource group is managed by the business-logic role rather than the VEN role and so has no VEN or client ID, and adds: "Because of this nested structure, resource groups are well-suited for representing bottlenecks in the grid topology." LF Energy's project page lists the feature as one it expects to be standardized in a later revision, so a grid bottleneck is a grouping the operator's business logic makes, not one the VEN registers.

An event is a sequence of intervals carrying typed payload values, and the payload types are enumerated in the OpenADR 3 Definitions document. Drive the platform from that enumeration as configuration, because the same VEN will meet price programs, capacity programs and programs that send both. The VEN's job on receipt is mechanical: validate the event against the program it names, resolve which resources it targets, persist it and hand each interval to the schedule mapper.

Event delivery is the part to settle with each VTN operator. The specification names a webhook mechanism, subscriptions, under which the VTN calls back an endpoint the VEN registered. Not every VTN implements it. The README is candid: "Currently, real-time updates via the webhook mechanism, known as subscriptions in the specification, are not supported." and the project offers MQTT and WebSocket signaling instead, with MQTT needing a broker. Make the transport a pluggable adapter, webhook receiver, poller and message client, with polling as the always-available default, because a VEN that can only receive pushes is blind whenever the push channel fails.

From event intervals to charging schedules

OpenADR ends at the VEN. Downstream sits OCPP, which the Open Charge Alliance's protocol page defines: "OCPP is the global open communication protocol between charging stations and charging management systems." OCPP 2.0.1 extended the smart charging functions 1.6 already had, and the message that carries a schedule of power or current limits to a station is SetChargingProfile.

The table separates what is sourced from what is ours. Object names are the Alliance's and LF Energy's; platform actions are editorial engineering practice, not requirements of either standard; OCPP messages are named by title from OCPP 2.0.1 Part 2, the specification obtainable from the OCA download page with or without an account, and nothing in this table is quoted from it.

OpenADR object (sourced)	Platform action (editorial)	OCPP 2.0.1 message (by title)
Program	Store the program identity and its interval and payload conventions as configuration and decide which assets belong to it	None
VEN	Run the VEN as the platform's integration service that holds the OAuth token, creates or updates the VEN record and authenticates every call to the VTN	None
Resource	Map each charging station, EVSE group or DER unit to a resource under the VEN so that targeted events and per-asset reports have an addressee	None, the resource maps to identifiers the CSMS already holds
Event	Translate each interval of the event into a schedule for the affected assets: a capacity limit becomes a station or site ceiling, a price series feeds the smart-charging optimizer and on the DERMS side the interval becomes a scheduled setpoint	SetChargingProfile carrying a station-wide ceiling, a transaction default or a transaction-specific schedule, and ClearChargingProfile when the event ends or is withdrawn
Report	Aggregate metered energy and delivered demand per interval and post reports to the VTN on the cadence the VTN operator asks for	MeterValues and the readings inside transaction events as inputs, nothing is sent to the station
Subscription	Register a callback so that the VTN pushes object changes, or poll the events endpoint, or use an MQTT or WebSocket channel where the VTN offers one, as LF Energy's does	None
No object: VTN unreachable	Keep the last received event in force until its intervals expire, fall back to the standing default afterwards, alarm the operator and re-read active events when the VTN answers again	SetChargingProfile with the transaction default as the standing fallback and ClearChargingProfile to lift an expired ceiling

The ClearChargingProfile entry depends on the VEN noticing a modified or withdrawn event, which nothing announces under polling. On every poll the VEN compares the events it holds with the events endpoint, reconciles by event id and modification time, re-derives the schedule of anything that changed and clears the profile of anything that disappeared.

Mapping is a translation between two time models. An OpenADR interval, as the OpenADR 3 Definitions describe it, says that from a start, for a duration, a payload value applies. An OCPP charging profile says that from a start, across a set of periods, a limit applies, with a purpose that marks it as a ceiling, a transaction default or a one-transaction schedule.

The program type decides the mapping, the fallback and the report material. A capacity limit is a site-level fact: it becomes a ceiling on each station once the site limit is split by the platform's allocation rule; the fallback when the VTN falls silent is conservative, because the last thing the network operator said was a limit; the report is built from demand held under that limit. A price series is an input, not a limit: it feeds the optimizer that emits per-transaction schedules; the fallback is permissive, because the absence of a price is not a constraint; the report is built from energy delivered per interval.

Allocation is site policy, not protocol: equal share gives every active station the same slice, priority classes serve fleet bays or fast chargers first and plugged-in-first lets earlier sessions keep their allocation while later arrivals share the remainder.

A ceiling and a per-transaction schedule can coexist on the station because profiles stack. The OCA's OCPP 2.0.1 certification page describes its Smart Charging profile as "Support for Smart Charging (all profile types, including stacking), to control charging." Stacking lets the event's ceiling and the optimizer's schedule sit on one station without one overwriting the other.

On the DERMS side the translation is shorter: an interval payload becomes a scheduled change of the setpoint the DERMS already holds for each asset, with the same start and end. The failure mode differs: charging profiles are held by the station under OCPP 2.0.1 Part 2, so a short loss of the CSMS does not clear them, whereas a DERMS setpoint is enforced by the platform's own control loop, so an interval that starts while that loop is down is missed unless the schedule is persisted and replayed.

Reporting back and telemetry

Reports close the loop: the VTN operator sets what is reported and how often, and the VEN posts what the platform measured per interval. In a charging platform the raw inputs are the meter values the station already sends over OCPP, so the report pipeline aggregates telemetry the CSMS already stores. The collection, buffering and clock discipline that make device telemetry trustworthy are covered in our IoT development guide.

One design point comes from the open implementation. The openleadr-rs README records one place where it is stricter than the specification requires: "In particular, we do not allow VENs to delete their own reports but instead allow this to the business logic (BL)." Whatever a given VTN allows, treat a posted report as immutable and post corrections as new reports, because the VTN operator may settle or audit against the original.

When the VTN is unreachable

The Alliance's pages and its certification program cover the VTN to VEN exchange, not what a VEN does when its VTN stops answering. The pattern below is our design, not a requirement of the standard.

Events already received stay in force until their last interval expires. The VEN persisted them on receipt and, under OCPP, the station holds the profiles derived from them, so an outage during an active event changes nothing at the station. When the last interval expires, the platform falls back to its standing default: the transaction default the CSMS would apply without OpenADR, or the safe setpoint of a DERMS asset.

The outage itself is an alarm with a threshold: a single failed poll is noise, while polling that keeps failing for longer than the shortest interval in use is an incident, because by then the platform may be executing a stale schedule. When the VTN answers again, the VEN re-reads every active event rather than trusting the notifications it missed and re-derives the schedules. Log the gap, because a report for an interval inside the outage is still owed.

Living with OpenADR 2.0b

The Alliance's certification rules keep the two generations side by side. Its OpenADR 3 page sets the requirement for the server side: "After a grace period of 6 months from the publication of the initial set of Certification Profiles, commercial VTNs must implement OpenADR 2.0b and OpenADR 3 to obtain certification." That rule binds VTNs, not VENs: a certified commercial VTN will speak both, but a VEN that only speaks 3 cannot talk to a VTN that has not yet added 3, so 2.0b stays on the list until every counterpart VTN has migrated.

OpenADR 2.0b is mechanically a different protocol: XML payloads rather than JSON, and a VEN that registers with the VTN and then polls for work. The OpenLEADR Python documentation, which implements 2.0b, describes what its client does on start: "This will connect to an OpenADR server (indicated by the vtn_url parameter), handle registration, start polling for events and reports, and will call your coroutines whenever an event or report is created for you." Reports are offered by the VEN, requested by the VTN and then delivered, and the messages are the oadrDistributeEvent, oadrPoll and oadrRegisterReport family rather than REST resources.

Security on 2.0b is certificate based. Per the Alliance's FAQ, "OpenADR 2.0 supports ECC and RSA server and client certificates with TLS and XML wrapping functionalities." The VEN holds a client certificate the VTN will accept, so certificate issuance, rotation and expiry monitoring are part of the integration.

Keep 2.0b behind the same internal interface as OpenADR 3: the scheduler consumes a normalized event, a list of intervals with typed values against a resource, and neither the XML nor the JSON leaks past the adapter that produced it, which keeps the mapping table valid for both generations and reduces a VTN operator's migration to swapping one adapter. One caution: LF Energy states on its project page that the Python implementation is unmaintained, so it is a reference for what 2.0b looks like rather than a base to build on.

Certification as a process

Certification is optional for an integration and mandatory for a claim. The Alliance's OpenADR 3 page is unambiguous: "Only products or systems that went through the OpenADR Alliance Certification Program can claim OpenADR compliance or certified status." A platform can integrate with a certified VTN without being certified itself; certification earns its cost when the VEN is sold to third parties or a network operator makes it a condition of enrollment.

OpenADR 3 certification is by profile, which the Alliance contrasts with the 2.0 series, where generally every function had to be implemented. A VTN seeking certification implements every feature and every profile, since VTNs are the center of interoperability, whereas a VEN may implement any combination and needs at least one. The profiles the same page marks as already available are a Continuous Pricing VEN and a Baseline VEN, and a charging-specific one appears only as "EVSE Management VEN (not defined yet, just a possibility)" in its list of examples, so a charging platform certifies against one of the available VEN profiles.

The process runs on a test tool. On its OpenADR 3 certification page the Alliance notes that "OpenADR 3 is a simplified RESTful version of the OpenADR protocol and therefore enables a simplified testing framework compared to version 2.0b." and describes downloadable test assets and an online test tool, positioning the local assets as development tooling: "These tests can be incorporated into a CI/CD pipeline or otherwise used during development of VEN or VTN products." The run itself is executed online with a Certification Manager present, and the page states the fee: "The cost is USD $1,250 and includes 3 hours with the CM to prepare for testing and execute the final certification run." Its other certification pages add that a final verification takes place at an Alliance-appointed test house, only members can request certification and the submission is a signed Declaration of Conformity, a signed PICS and the test report.

Per the certification process page, the Alliance tests the interface between a VTN and a VEN with either node as the device under test, and "Intelligence build into the systems not related to the OpenADR 2.0 message exchange is not part of the OpenADR Alliance testing program." The scheduler, the OCPP mapping and the fallback logic are therefore never certified by anyone but you, and the VEN under test need not show a user interface.

The Alliance's suite is closed source, which LF Energy says keeps it out of public CI, so the licensed local test assets, which the Alliance offers to members, are the only way to run the Alliance's own tests in your pipeline. As a counterpart to develop against, LF Energy's openleadr-rs README describes its VTN as a stand-alone binary that the VEN reaches over HTTP.

How Pharos Production helps

An OpenADR integration has four parts outside the certified VTN to VEN interface: the VEN service, the interval-to-profile mapper, the report aggregation over OCPP telemetry and the outage behavior.

Our energy software development team builds that layer inside an existing CSMS or DERMS, keeps 2.0b and 3 behind one event model and prepares the VEN for the Alliance's test tool when certification is the goal.

Sources: OpenADR Alliance pages on openadr.org (OpenADR 3.0, Specification, OpenADR 3 Certification, Certification process, About OpenADR and FAQ); the OpenADR 3 OpenAPI YAML Specification, Definitions and User Guide, cited by title; the LF Energy OpenLEADR project page, the openleadr-rs README and the OpenLEADR Python documentation; the Open Charge Alliance OCPP protocol, Download OCPP and OCPP 2.0.1 certification pages; OCPP 2.0.1 Part 2 Specification, cited by title. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: October 4, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• What is the difference between a VTN and a VEN in OpenADR?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  Think of the VTN as the publisher and the VEN as the subscriber: the Alliance describes a VTN as typically a server that sends OpenADR signals and a VEN as typically a client that accepts them. Whoever runs the grid program, a utility, a system operator or an aggregator, operates the VTN, the party whose load responds operates the VEN and one aggregation platform can hold both roles, VEN upward and VTN downward.

  In this guide's architecture the VEN is an integration service inside the CSMS rather than the charging station, which is driven over OCPP and sees no OpenADR message.

• Does a charging station need to support OpenADR?

  Copy link Copies a direct link to this answer to your clipboard.

  It need not. In this design OpenADR stops at the VEN, which is the platform, and the station is driven over OCPP.

  The platform translates each event interval into a charging profile and sends it to the station with the OCPP 2.0.1 message SetChargingProfile, then builds the OpenADR report from the meter values the station already reports. A station therefore needs OCPP smart-charging support, including stacked profiles so that a capacity ceiling and a per-transaction schedule can coexist, and no OpenADR support of its own.

• Is OpenADR 3 compatible with OpenADR 2.0b?

  Copy link Copies a direct link to this answer to your clipboard.

  They are separate protocols rather than two versions of one wire format, and the Alliance positions OpenADR 3 as an addition to the 2.0a and 2.0b profiles, not a replacement. The generations differ in transport and security, REST with JSON messaging and OAuth on the 3 side in LF Energy's description against XML, client certificates and a polling VEN on the 2.0b side, and LF Energy adds that within the 3 family its 3.1 is not backward compatible with 3.0.

  Expect to run both behind one internal event model until every VTN you talk to has moved.

• How does a VEN authenticate to an OpenADR 3 VTN?

  Copy link Copies a direct link to this answer to your clipboard.

  Through OAuth: the VEN presents a bearer token on every REST call, obtained either from the VTN's own token endpoint, which LF Energy's README says is mainly for testing and prototyping, or from a third-party identity provider the VTN operator has configured. Treat the VEN as an unattended machine client: a client-credentials style grant fits, the client secret lives in the platform's secret manager and an expired token should raise the same alarm as an unreachable VTN.

  The exact grant and scopes come from the OpenADR 3 OpenAPI specification and the operator's configuration, so confirm both first.

• What should a platform do when the OpenADR VTN is unreachable?

  Copy link Copies a direct link to this answer to your clipboard.

  Decide it in advance and write it down, because the Alliance certifies the VTN to VEN exchange and not what a VEN does when its VTN stops answering. A defensible rule honors every event already received until its last interval ends, then drops to the default the site would run with no OpenADR at all, and treats silence longer than the shortest interval in use as an incident rather than a retry.

  On reconnection, re-read the active events from the VTN instead of trusting the notifications that were missed and post the reports still owed for the gap.

• Do you have to certify a platform to use OpenADR?

  Copy link Copies a direct link to this answer to your clipboard.

  No. A platform can integrate with a certified VTN without certifying its own VEN. Certification is required only to claim OpenADR compliance or certified status, which matters when the VEN is sold to third parties or when a network operator makes it a condition of enrollment.

  OpenADR 3 certification is by profile, the run is executed online with a Certification Manager, only Alliance members can request it and a final verification takes place at an appointed test house. The test covers the VTN to VEN interface only and never the scheduling logic behind it.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.