OpenADR for Niagara: Automated Demand Response on a Tridium Station

If you build or maintain systems on the Niagara Framework, you already own the hardest part of demand response: a platform that sees every load in the building and can act on it. OpenADR is simply the missing link that lets the grid talk to that platform automatically. This guide is for the systems integrators, controls engineers and energy managers who want to connect a Niagara station to a demand response program — how it works, where the VEN sits, and why the version you choose matters more than it used to.

New to the protocol itself? Start with our OpenADR overview and come back. Everything below assumes you know what a VTN and VEN are.

Why Niagara is the natural home for OpenADR

OpenADR defines the conversation between the grid and your edge, but it deliberately stops at the edge — it delivers a signal and leaves the response to you. That is exactly the gap Niagara already fills. A Niagara station integrates HVAC, lighting, metering, generators, batteries and more into one normalised data model, with control logic running on the wire sheet. It is, in effect, the building's response engine. Bolt an OpenADR VEN onto it and a grid event becomes just another input that your existing sequences can act on.

That combination is powerful for three reasons. The load is already there and already controllable — no separate gateway has to relearn the building. The control logic is already written — curtailment becomes a few links, not a new system. And the same station handles measurement and verification, so the telemetry a program wants is data you are already trending.

How OpenADR works on a Niagara station

In OpenADR terms, your Niagara station acts as a Virtual End Node (VEN). A driver (or module) running in the station registers with the utility's or aggregator's Virtual Top Node (VTN), subscribes to one or more programs, and receives events and price signals.

Inside the station, those signals surface as points and components — an active-event flag, an event level or target, start and end times, a price value for the current interval. From there it is ordinary Niagara work: link those points into your control logic on the wire sheet so that when an event fires, the station executes your curtailment strategy, and when it clears, the building returns to normal. Opt-out logic, participation feedback and the telemetry reports the VTN expects are all wired the same way — as components linked to station data.

The important architectural point is that the VEN is a translator, not a controller. It hands the grid signal to the station; your sequences decide what actually happens to the chiller, the lighting circuit or the battery. Tridium's own driver describes this as a "link-ready" interface for exactly this reason, and it is the right mental model regardless of which VEN you use.

Where the VEN runs

You have a few placement options, and the right one depends on the site:

On a JACE controller — the VEN lives on the same edge controller that runs the building. Good for a single site with its own controls, and resilient because the response logic stays local even if the wider network is down.
On a Niagara Supervisor — the VEN runs at the supervisory layer and fans events out to the JACEs below it. This suits a campus or a portfolio managed from one Supervisor, where one registration represents many downstream controllers.
As an external/cloud VEN bridged into the station — the VEN runs as a separate service and passes signals into Niagara over BACnet, Modbus, MQTT or an API. This is the model that scales across large fleets and is the most natural fit for modern, cloud-hosted OpenADR.

Whichever you choose, the station's job downstream is identical.

What you can build once it's connected

With grid signals available as station points, the response strategies are limited only by what the building can do:

Staged load shedding — drop non-critical lighting circuits and controlled receptacles first, then trim HVAC, on a defined sequence.
HVAC curtailment — raise chilled-water temperature, stage off air handling units (AHUs) and rooftop units (RTUs), throttle VAV boxes, or slow cooling-tower and pump VFDs during an event.
Setpoint and pre-conditioning strategies — widen zone deadbands during an event, or pre-cool ahead of a forecast price spike using the day-ahead notice OpenADR provides.
Refrigeration and process loads — defer defrost cycles, trim refrigeration racks in grocery and cold storage, or shed deferrable process and pumping loads.
Generator or battery dispatch — discharge battery storage (BESS) or start standby generation when an event or price threshold is reached.
Operator dashboards and alarms — surface upcoming and active events on Px views so facilities staff can see what the building is about to do, and override if needed.
Automatic measurement and reporting — trend baseline and event-period consumption and report performance back to the VTN for settlement.

Which buildings run Niagara — and the loads they shed

Niagara's strength is that it integrates almost any building system, regardless of manufacturer, over BACnet, Modbus, LonWorks, MQTT and dozens of other drivers. That same breadth is why it's such a good demand response host: whatever speaks to the station can become a controllable load. These are the verticals where Niagara is most common and the loads each typically curtails under an OpenADR event:

Commercial office and multi-tenant real estate — central chillers, AHUs and VAV zones, common-area lighting and garage ventilation. Portfolio operators and REITs often run a Niagara Supervisor across many sites, making one VEN registration cover a whole estate.
Higher education and campuses — central plant chillers and cooling towers, building-level AHUs, lab HVAC (non-critical zones only), and district lighting, typically coordinated from a campus Supervisor.
K-12 schools and government buildings — rooftop units, HVAC scheduling and lighting, plus water and wastewater pumping for municipal sites.
Healthcare and hospitals — non-critical HVAC zones, AHUs and common-area lighting, with life-safety, surgical and isolation systems explicitly excluded from any shed strategy.
Data centers — cooling-side flexibility (raising CRAC/CRAH and chilled-water setpoints within SLA limits) and shifting to on-site generation or battery, rather than shedding IT load.
Retail, big-box and grocery — RTUs and lighting across the floor, plus refrigeration racks and deferred defrost in grocery and convenience stores — a measure California utilities have recently moved to make incentive-eligible.
Industrial and manufacturing — deferrable process loads, pumps, compressed air and facility HVAC, usually with an on-site VEN so the response logic stays local and autonomous.
Warehouses, cold storage and agriculture — refrigeration, lighting, HVAC, and irrigation or agricultural pumping loads, several of which are also newly recognised in California incentive programs.

The pattern across all of them: the OpenADR VEN only has to reach the Niagara station, and the station already speaks to the equipment. You curtail in the protocols you already run — OpenADR never has to touch the chiller, the RTU or the refrigeration controller directly.

The version gap every Niagara integrator should know about

Here is the part most "OpenADR on Niagara" write-ups skip. Almost every OpenADR option available for Niagara today is built on the OpenADR 2.0 generation. Tridium's Niagara 4 VEN Driver is a 2.0 driver, certified by the OpenADR Alliance to the 2.0 specification and supported on Niagara 4.10 and above; the common third-party drivers are likewise 2.0a/2.0b. There is, at the time of writing, no widely available OpenADR 3.0 VEN driver for Niagara.

That matters because OpenADR 2.0 and 3.0 are very different under the hood. 2.0 is XML and SOAP-style messaging secured with mutual-TLS client certificates — capable, but heavy to deploy and operate, and certificate management is a recurring source of field headaches. OpenADR 3.0 is a clean REST/JSON redesign secured with TLS plus OAuth2 client credentials, with webhooks for push delivery and a far lighter implementation footprint. It is also the version being built out for the things the grid is moving toward: distributed energy resources, batteries, EV charging and VPP participation.

To be clear, 3.0 is not killing 2.0. The OpenADR Alliance positions version 3 as a complement to the still widely deployed 2.0, and the two will coexist for years — a 2.0 VTN and a 3.0 VEN cannot talk to each other directly, so you match whatever your program's VTN speaks. But the direction of travel is unmistakable: new programs, new DER and EV use cases, and the simpler security model are all pulling toward 3.0. A Niagara estate that can only speak 2.0 is, increasingly, on the wrong side of that line.

Bringing OpenADR 3.0 to Niagara

Closing that gap is straightforward in principle. Because OpenADR 3.0 is a standard REST/JSON API, a 3.0 VEN can either run as a station-side integration or as an external certified VEN that bridges grid events into Niagara through the protocols the station already speaks — BACnet, Modbus, MQTT or a direct API link. The station then treats a 3.0 event exactly as it would a 2.0 one: as points to link into your existing control logic. Your curtailment sequences, dashboards and reporting do not need to change; only the upstream connection to the grid does.

That means a Niagara site can participate in a modern OpenADR 3.0 program without ripping out the controls work already in place — and without taking on the certificate-management overhead of the older 2.0 stack.

Getting started

If you are scoping a Niagara demand response integration, work through these in order: confirm which OpenADR version the program's VTN requires (2.0 or 3.0 — they are not interoperable); decide where the VEN should sit (JACE, Supervisor or external/cloud); make sure your VEN is OpenADR-certified, since most programs require it and certification catches interoperability bugs before they reach the field; then map the grid signals to the control sequences and reporting the program expects, and test against the VTN before go-live.

Frequently asked questions

Does Niagara support OpenADR? Yes. A Niagara station can act as an OpenADR VEN, receiving demand response events and price signals from a VTN and linking them into station control logic. There are drivers that add this capability, and external VENs can also bridge into a station.

What version of OpenADR does the Tridium Niagara driver use? Tridium's Niagara 4 VEN Driver implements OpenADR 2.0 and is certified to the 2.0 specification. It runs on Niagara Supervisors and JACEs on Niagara 4.10 or higher. The widely available third-party Niagara drivers are also 2.0a/2.0b.

Can I run OpenADR 3.0 on Niagara? Not with the standard off-the-shelf drivers, which are 2.0. Because 3.0 is a REST/JSON API, the practical route today is a certified 3.0 VEN that bridges events into the station over BACnet, Modbus, MQTT or an API, so your existing Niagara logic handles the response unchanged.

Should the VEN run on a JACE or a Supervisor? A JACE keeps the response local and resilient for a single site; a Supervisor suits a campus or portfolio where one registration represents many downstream controllers. Large fleets often use an external or cloud VEN instead.

What loads can a Niagara building actually curtail? Anything the station controls — typically HVAC (chillers, AHUs, RTUs, VAV boxes, cooling-tower and pump VFDs), lighting circuits, controlled receptacles, refrigeration, battery storage and standby generation. Offices, campuses, schools, retail and grocery, warehouses and industrial sites are common Niagara verticals; critical loads in hospitals and data centers are excluded, with flexibility coming instead from non-critical zones, cooling setpoints and on-site generation or storage.

Does the VEN control my equipment directly? No. The VEN delivers the grid signal to the station as data. Your Niagara sequences decide what happens to the equipment — which is exactly why Niagara is such a good fit for OpenADR.