Reference · built on requestOperator by FibricEnergy & demand

Event Response

Turns a demand-response event notice into a curtailment plan for the event window, checked against meters and equipment state.

Request accessPricing ↗

About

A utility or aggregator sends a demand-response event through an OpenADR 3 VTN: a program, a priority, targets, and intervals whose payloads carry a price or a simple level. Someone then has to decide which loads to shed, by how much, and whether the building can do it that afternoon.

Event Response subscribes to those events, reads the site's interval meters over Modbus TCP and zone and equipment state from the building platform, and drafts a plan for the window: which noncritical zones get a setpoint shed, which fans or chillers stage down, and what the meter should show. Title 24 asks zone-level DDC to raise noncritical cooling setpoints by 4 degrees or more on a central signal; the plan uses the shed your platform already supports. A person approves the plan before the window opens, and the delivered intervals go back to the VTN as a proposed report.

This is a reference listing. It documents what Fibric would read from Event Response and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Events from the VTN through GET /events or a subscription callback: programID, priority, targets, intervalPeriod, and each interval's payloads
  • Program details through GET /programs, including the payloadDescriptors that say what a PRICE or SIMPLE payload means
  • Interval meter readings over Modbus TCP: kW, kWh, and power factor at the service entrance and the major feeders
  • Zone setpoints, occupancy state, and equipment run state from the building platform over BACnet/IP or a Niagara station
  • The loads and shed steps your team has listed as available, with the comfort or process limit each one carries
  • Reports already sent for the event through GET /reports, so a delivered interval is never reported twice

Proposed actions

  • Target capability: propose a curtailment plan for the event window naming each load, its shed step, and the expected kW reduction
  • Target capability: propose the noncritical-zone setpoint shed on the building platform for the window, with the reset step scheduled
  • Target capability: propose staging a listed deferrable load down through the building connector, within the limits you set for it
  • Target capability: propose an opt-out when meters and equipment state show the site cannot deliver the requested reduction
  • Target capability: propose the event report through POST /reports with the metered intervals attached

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Answer an afternoon price event

    Read the PRICE intervals from the VTN, compare them with the site's meter history over Modbus TCP, and get a plan that sheds noncritical-zone setpoints on the Niagara station for the priced hours. Approve it before the window.

    With OpenADR 3, Modbus TCP, Tridium Niagara

  • Stage chillers down on a simple signal

    For a SIMPLE-level event, the plan names which chillers and fans stage down over BACnet/IP and for how long, then the metered intervals go back to the VTN as a proposed report once the window ends.

    With OpenADR 3, BACnet / IP

  • Pause EV charging for the window

    Where chargers sit behind the site meter, the plan can add a temporary charging profile on the OCPP management system alongside the building shed, restored when the event closes.

    With OpenADR 3, Open Charge Point Protocol (OCPP), Modbus TCP

Requirements

  • An OpenADR 3 connector registered as a VEN with the VTN, in the program and targets your site belongs to
  • A Modbus TCP connector polling the site's interval meters, or a building platform that exposes the same readings
  • A BACnet/IP, Niagara, or building management connector with the shed and reset points the platform supports
  • A written list of sheddable loads, their steps, and the comfort or process limit that bounds each one
Authentication
Authenticates to the VTN with OAuth 2.0 client credentials and the read_targets, read_ven_objects, and write_reports scopes the VTN grants, reads meters through the Modbus connector's register allow-list, and writes to the building platform only through approved proposals.

Limits

  • It reads events as the VTN publishes them. OpenADR 2.0b sites need a gateway, and the VEN must match the VTN's 3.x version.
  • The expected reduction is an estimate from the loads you listed and recent meter history. The meter during the window is the only proof.
  • It does not shed loads itself and cannot promise a kW figure to the utility. Both stay with the person who approves the plan.
  • Events with a randomizeStart, or intervals shorter than the meter's polling period, are handled at the meter's resolution rather than the event's.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Event Response ↗

Questions and answers

What gets approved before an event window?
The plan for the window: each load, its shed step, the setpoint or profile change, the reset time, and the reduction it expects. You can drop a load, change a step, or opt out. Until someone approves it, no setpoint moves and no report is sent.
What goes back to the utility?
Only what you approve: a report through the VTN's /reports endpoint carrying the metered intervals for the window. The receipt keeps the event id, the plan, the readings, the report sent, and who approved each step.
Will it shed a load on its own if nobody answers in time?
Never. An event that reaches its start with no approved plan is logged as missed, and the operator proposes an opt-out where the program allows one. It writes nothing to equipment without an approval.
Ask about Event Response

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy