Virtual power plant software for aggregators and energy cooperatives

Demand response software takes an aggregator's call, splits it across metering points, tells participants and settles the hour against a baseline. We have been building the demand-side response (DSR) module of the Zeronest platform since May 2025, and on March 23, 2026 it handled a real call in production.

The module has a DSR operator, who sees all installations, and a DSR client, who sees only its own. A separate consultant role acts on behalf of the aggregator or a client. The module groups metering points into aggregation units and stores unavailability notices for each point and each unit. The aggregator creates a call that covers many of its clients' metering points.

Since 2026 each metering point receives its own declared power in a call instead of an equal share, with a buffer above the ordered value. For example, a 5 MW call can require 5.25 MW from clients. The API rejects a call whose total does not match the limit and the buffer, and it splits power into whole kW. A call lasts at most one hour and starts on the full hour, and calls are expected between 7:00 and 22:00.

The baseline is corrected with data from the third, fourth and fifth hour before the call. The correction factor is the average difference between consumption and the profile, capped between -20% and +20%, and it also applies to the following hours of the call. When meter data goes missing after an outage, the platform has a process for restoring it, including gaps longer than 10 days.

Participants receive an SMS and an e-mail with a confirmation link. Ten minutes after a call is created, the system checks SMS delivery and e-mails the operator a list of messages that were not sent. The report for a call hour is ready a quarter of an hour after it ends, so a 14:00-15:00 call is reported at 15:15. The call limit in the report is the sum of the metering points' limits. A client whose points share a call with others sees only the combined power of its own points.

Energy cooperative software calculates, hour by hour, what each member and the cooperative as a whole owe and are owed. We built the energy cooperative module for Zeronest in 2026. It settles a cooperative on two levels, the whole group and each metering point. It divides the energy of every hour into three streams: used by members on site, put into the deposit, and exchanged with the grid. The deposit is unused energy carried over to later months.

Hourly settlements are available through an API. They are recalculated every 5 minutes between the 23rd and 58th minute of the hour, with a check of who was a member in that hour. In July 2026 the cooperative operator got control over many installations at once, and in September 2026 a new deposit settlement mode. Testing caught, among other things, Wh shown as kWh and group self-consumption calculated from the wrong measure.

The rules come from Polish law. A cooperative can have up to 10 MW of capacity and must cover at least 70% of its own needs. Energy the members feed into the grid is set against energy they take from it at a 1:0.6 ratio, on hourly data, and the deposit is valid for up to 12 months. From October 19, 2026 the hourly data comes from CSIRE, Poland's central energy market information system.

Balancing market software has to deliver declared power within the market's activation time while respecting the limits set by the distribution system operator (DSO). PSE, the Polish transmission system operator, gives full activation times for its four balancing products: 30 seconds for FCR, 5 minutes for aFRR, 12.5 minutes for mFRR and 30 minutes for RR.

Since December 2025 we have been building an EMS for Global Green, an operator of solar and battery storage sites in Germany and Canada, covering 15 MWh of storage. The EMS runs on an industrial computer on site and sends data to the cloud. Its orchestrator combines setpoints from trading, aFRR and direct control, resolves conflicts between them and only then splits the result across batteries. We closed the orchestrator's initial implementation on June 29, 2026, and the MVP is in progress.

Two additions came in July 2026. The first is loss compensation: after resolving conflicts, the orchestrator raises discharge power and lowers charge power by a configured percentage, so the commitment is met at the grid connection point. The result never leaves the battery's operating range, and every clipped value is logged. The second is three controllers for DSO commands: a battery limit, a direct battery command and an export limit. We modelled the DSO in a simulator. In September 2026 a new version of the EMS went onto the controller at one site.

As of October 2026, migration of the existing aFRR pipeline to the new platform is in testing, and the controller that combines trading and aFRR on one battery has a finished design and is being implemented.

The EMS we built for Skyfri does peak shaving and limits export at the DSO's request. By October 2024, DSO-requested export limiting, zero-export algorithms and a maximum load limiter had been tested on site together with the DSO.