Automated Demand Response with IoT
July 15, 2025 · Dr. Raj Patel
Utility capacity markets now price kilowatts not just kilowatt-hours, which has quietly turned demand response from a corporate social responsibility checkbox into a revenue line. In PJM, CAISO, ERCOT, and the ISO-NE footprint, commercial and industrial facilities can earn capacity payments, energy credits, and ancillary-service compensation simply for being able to reduce load on demand. The catch is that most DR programs pay only for verified curtailment: you must shed a committed amount of load, for a committed duration, within a defined response window, or you face penalty or clawback. An Internet of Things measurement and control layer is what turns that contractual commitment from a scramble into a repeatable operation.
How Demand Response Programs Are Structured
Before automating anything, it helps to know which product you are selling. The three dominant structures are:
- Capacity programs. You bid a fixed curtailment amount (say 800 kW) and are paid year-round for being available, whether or not events are called. Failure to perform during an event can forfeit a month of capacity revenue.
- Energy programs. You are paid for actual MWh reduced during an event window. This rewards depth of curtailment but pays nothing for idle availability.
- Ancillary services. You respond to fast dispatch signals (often within minutes) to regulate frequency or reserve. Response speed and metering quality decide eligibility.
Each structure imposes different telemetry and automation requirements, and a facility can stack multiple products across separate meters. The same load that earns capacity money can also shave your own peak demand charge, so the optimization is not purely about the utility check.
The Automation Gap in Manual DR
Traditional participation relies on a facilities manager receiving an event notification by email or phone, walking the floor, and manually switching off chillers or production lines. That workflow fails on three fronts. First, notification lag — events can be announced 30 to 60 minutes ahead in some markets but as little as 5 to 15 minutes in others. Second, measurement lag — the operator cannot see whether the shed is actually happening in real time. Third, restoration risk — turning loads back on too fast after an event can create a rebound spike that is nearly as expensive as the event itself.
What IoT Telemetry Adds
An IoT-based DR layer does three jobs that a human cannot reliably do under time pressure:
- It subscribes to events automatically. Standards like OpenADR 2.0b (used widely by utilities) and IEEE 2030.5 let a software client poll or receive push notifications, acknowledge the event, and confirm participation — no email chains, no phone trees. The same interface lets you send “ready to shed” and “shed completed” signals back to the program operator.
- It meters the shed. Panel-level and sub-meter energy transducers measure real power continuously. When the event starts, the platform captures the pre-event baseline, tracks the actual curtailment in near real time, and flags any drift below commitment before it becomes a penalty.
- It dispatches loads through existing controls. Rather than new switching infrastructure, the platform issues setpoint and schedule changes through the systems already present: BACnet points on a BAS, Modbus registers on compressors, or MQTT messages to smart load controllers.
A Worked Example: Shedding 600 kW at a Manufacturing Campus
Consider a plant with a 2 MW peak and a utility event calling for 600 kW of curtailment for four hours. A realistic shed portfolio might be assembled as follows:
| Load | Typical kW | Control path | Ramp time |
|---|---|---|---|
| Chilled-water system (pre-cooled) | 180 | BAS reset of CHW setpoint | 20 min |
| Air-compressor bank | 120 | Duty-cycling two of five units | 10 min |
| Production line (planned break) | 200 | MES/PLC coordination | 5 min |
| Warehouse lighting | 60 | Relay/lighting control | 1 min |
| Process ovens (thermal mass) | 40 | Modbus setpoint bump | 15 min |
Total available: 600 kW with roughly 100 kW of margin. The automation layer sequences the dispatch in reverse ramp order — lighting and production first because they respond instantly, chillers and ovens later because they carry thermal inertia and need lead time. It also respects a minimum runtime on each compressor so that the “shed” does not cause short-cycling damage when the event ends.
The Baseline Problem
Every program operator defines the “would-have-been” load differently: some use a weather-adjusted average of the prior five business days, others use a symmetric window around the event. The automated system must compute the exact baseline method the program uses, using the same 15-minute interval data, and display the running surplus or deficit. Facilities that skip this step routinely under-perform and get paid less because their internal estimate does not match the operator’s calculation.
Meeting Persistence and Ramp Requirements
Two requirements are easy to miss. First, persistence: the shed must be held for the full window — a 600 kW drop that fades to 300 kW by hour three is a partial performance. That means the dispatch logic should stage the fastest loads last so there is capacity in reserve to top up the shed if thermal loads drift. Second, ramp rate: markets with fast dispatch (some ancillary services require full response within 2–5 minutes) cannot rely on chilled-water thermal mass alone; they need electrically fast loads — lighting, fans, or battery storage — in the portfolio.
Implementation Path
- Inventory every switchable load and its real power draw (measure it, do not trust the nameplate).
- Map the control interface for each: BACnet, Modbus, MQTT, dry contact, or relay.
- Connect to the program operator’s event stream (OpenADR 2.0b or portal API).
- Build and validate the shed portfolio across two or three non-critical events first.
- Compare your measured performance against the operator’s settlement calculation after every event.
Automated DR is ultimately about making your kW a controllable, tradable resource rather than a passive expense. When event dispatch, metering, and settlement verification all run through the same IoT platform, the same loads that reduce your monthly bill can start earning program revenue with a defensible, auditable performance record. Integrar IoT’s energy platform handles the event subscription, sub-meter telemetry, and BAS/PLC dispatch in one system, so facilities can participate in multiple DR products across multiple meters without maintaining separate integration stacks.