Skip to main content
Technical Preview

Overview

OpenADR 3 is the OpenADR Alliance standard for demand response and dynamic pricing over a REST API. A utility or aggregator runs a VTN (Virtual Top Node). Sites and devices connect to it as VENs (Virtual End Nodes): they read programs and events (price signals, load-shed requests, import / export capacity limits, GHG signals) and send reports (measured usage, baselines, status) back. A business logic (BL) client on the utility side creates the events. The OpenAdr3Vtn connector maps 26 MQTT topics onto the OpenADR 3.0.1 API: one token request, 12 read events and 13 write events. With it, a Coreflux broker can act as the VEN for a plant or building: it picks up DR events on MQTT, hands them to the controls that shed or shift load, and reports the measured response to the utility. Each event publishes the VTN reply on <topic>/response. All endpoints carry the base path /openadr3/3.0.1 (left out in the table).
Write events change VTN state. CreateEvent, UpdateEvent and DeleteEvent need the business-logic role (write_events): a new event is a demand-response instruction to every targeted VEN. Reports, subscriptions and VEN / resource registration are VEN writes. Restrict who can publish to these topics with a rule. This connector leaves out program administration and VEN / resource deletion.

Prerequisites

  • Access to a VTN: the URL from your utility, aggregator or DR program, or your own VTN (for example the open-source openleadr-rs VTN).
  • Client credentials (client_id, client_secret) for a VEN client, and a business-logic client if you create events. The VTN operator issues them.
  • The VTN base path. The OpenADR 3.0.1 specification uses /openadr3/3.0.1. Some VTNs serve the API at a different path or at the root. Change the endpoints if yours does.
  • Outbound HTTPS from the broker to the VTN.

Authentication

OpenADR 3 uses OAuth 2.0 client credentials. FetchToken posts a form body to auth/token and gets back {"access_token": "...", "token_type": "Bearer", "expires_in": 3600}. Every other event sends Authorization: {value.json.authorization} with the value Bearer <access_token>. The specification calls auth/token a convenience endpoint that a commercial VTN may leave out. In that case, get the token from the utility’s authorization server and store it in OPENADR_AUTHORIZATION. Scopes: read_all (VENs and BL), write_programs and write_events (BL), write_reports (VENs), write_subscriptions and write_vens (VENs and BL).

Configuration

Query parameters (3.0.1): An event carries intervals, and each interval has payloads such as {"type": "PRICE", "values": [0.17]} or {"type": "IMPORT_CAPACITY_LIMIT", "values": [50]}. intervalPeriod sets the start and duration (ISO 8601, for example PT1H).

Basic Syntax

Examples

Get a token: publish
to energy/openadr/auth/token and read access_token from energy/openadr/auth/token/response. Read the events of one program: publish
to energy/openadr/event/list. Report measured usage for an event: publish
to energy/openadr/report/create. Actions that keep a token and poll events:
Restrict who can publish to energy/openadr/# with a rule, because these payloads carry the client secret and token.

Notifications (webhooks)

Instead of polling, create a subscription with subscription/create. Its objectOperations[].callbackUrl points to a Coreflux REST API server connector (ENABLE_SERVER), and the VTN posts {"objectType", "operation", "object"} to it whenever an event, program or report changes. OpenADR 3.1 also lets a VTN publish these notifications to an MQTT broker, which fits a Coreflux broker directly.

Notes

  • Versions: this connector follows OpenADR 3.0.1. OpenADR 3.1.0 (August 2025) keeps the same objects but uses a targets query parameter, moves resources to a top-level /resources path, and adds auth/server and MQTT notifiers. Check which version your VTN runs.
  • Spec source: the OpenAPI document is published by the OpenADR Alliance (Apache 2.0). A public copy is on GitHub.
  • Polling: DR events are usually published hours or a day ahead. Polling event/list every 5 minutes is plenty; subscriptions remove the need to poll.
  • Testing status: the connector has only been tested against the specification and a local mock VTN. Results against a real VTN are still to come.
Last modified on October 21, 2026