Demand response

EU law defines demand response in Directive 2019/944 (Article 2, point 20) as a change of electricity load by final customers from their normal or current consumption pattern. The trigger can be a market signal, such as a time-variable price or an incentive payment, or the acceptance of the customer's bid to sell demand reduction or increase on an organized market. The customer can do it alone or through aggregation, which the same article defines as combining multiple customer loads or generated electricity for sale on any electricity market.

In practice there are two families. In implicit demand response the customer sees a price, for example a dynamic tariff, and shifts load on their own. Nobody calls them and nobody measures them against a baseline. In explicit demand response the customer, usually through an aggregator, sells flexibility as a product. The buyer (a grid operator, a capacity mechanism or a balancing market) sends a call, the portfolio reduces or increases load for a set window, and payment depends on what was measured.

An explicit event runs in five steps: enrollment and testing of each site, a baseline that estimates what the site would have consumed without the call, the call itself with a notice period, delivery, and settlement against the baseline.

In Poland most explicit demand response is sold through the capacity market, as capacity market demand reduction units. PSE announces availability periods (formerly called "okresy zagrożenia", now "okresy przywołania") no later than 8 hours in advance. A supplier with a demand reduction unit can ask PSE for a test period. During a test the unit must deliver at least its capacity obligation for that hour. A failed test costs the supplier the capacity payment for the affected period and triggers a penalty.

On the balancing market an aggregator can pool generation, storage and consumption sites into an aggregator scheduling unit (jednostka grafikowa agregatu, JGA) of 0.2 MW to 50 MW; the entry rules since the June 2024 reform are described under aFRR. So far nobody has used this route: URE's review of the first year of the reform, covering the period to June 30, 2025, counted no aggregator units registered on the balancing market.

Most of a demand response platform is data handling; dispatch is the smaller part. These requirements usually decide its architecture:

• The asset registry works at metering point level. Each point (in Poland, the PPE number, punkt poboru energii) needs its declared or contracted power, the reduction it can offer, its owner and the aggregation unit it belongs to. One customer may have points in several units, and one call may cover points of several customers.
• The baseline method comes from the program rules, so the system has to implement it exactly, version it and recompute it when a call is added at short notice or when meter data arrives late. Gaps in meter data need an explicit rule; silent interpolation will be challenged at settlement.
• A call has a start, an end and a requested power. The platform splits that power across points (evenly, by declared capacity, or with a safety buffer above the requested volume) and validates that the sum matches the call.
• SMS, e-mail or API notifications must reach participants, and the system should notice when they did not.
• Measurement runs on interval data at settlement resolution (15 minutes in most EU markets). Reports per hour or per interval should be generated as soon as each interval closes, with totals per call, per unit and per customer.
• Grid operator, aggregator, end customer and an energy consultant managing points on the customer's behalf each see only their own points and their share of a call.

We built the demand-side response module of the Zeronest energy management platform. It groups individual metering points into aggregation units and lets an aggregator create a call across them. In 2026 the allocation logic changed at the request of an aggregator using the platform: a call used to split the requested reduction evenly across points, and now each point is assigned the power declared for it. The declared values can add up to more than the call, so an aggregator can call 5 MW while requiring 5.25 MW from its customers. The API rejects a call when the requested total does not match the limit and buffer.

When a call is created, participants get an SMS and an e-mail with a confirmation link. Ten minutes later the platform checks that every SMS went out and e-mails the operator a list of messages that failed. The platform builds a corrected baseline profile for each call, has a process for rebuilding data after outages, including gaps longer than ten days, and generates the report for each hour shortly after it ends: for a call from 14:00 to 15:00, at 15:15. A customer whose points share a call with other customers sees only the total power of their own points.