Virtual Power Plant Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the dispatch scope get underestimated so often?

Almost every distributed energy resource project is scoped as though dispatch were an application programming interface call. Send a setpoint, receive a success response, count the device as delivering. Then the first real event arrives with a ten minute notification window and the fleet spans three thermostat brands, a residential battery fleet, grid-interactive water heaters and forty commercial sites behind a building controls vendor that speaks an industrial protocol and nothing else.

What the scope missed is that every vendor cloud has its own private definition of an acknowledgement. One confirms at the interface boundary. One confirms only when the device reports back. One confirms nothing you can act on, and you learn the truth from telemetry twenty minutes after the interval closed. Layer on rate limits, batch sizes and retry behaviour that differ per vendor, and the dispatch path is a scheduling problem with unequal latency, not a broadcast.

This is specific to distributed energy because the performance interval is fixed by somebody else and starts whether you are ready or not. In most software a slow response is an inconvenience. Here it is a missed interval and a reduced award.

The fix is to measure your own acknowledgement distribution per channel from your own event history rather than trusting a vendor's nominal figure, then order commands so the slowest path fires first and the fast paths are pre-positioned. Hold a reserve pool so devices predicted not to respond in time are substituted before the interval opens rather than mourned after it closes. Latency-aware ordering plus a reserve pool is the change that moves measured performance in mixed fleets.

What goes wrong with enrollment, meter and device data?

The data problem in this category is identity. A participant is a customer account at the utility, a service point with a meter identifier, one or more devices each with a vendor-side identifier, and a program enrollment with a start date and a tariff. Nothing joins those automatically, and every one of them can change independently. The customer moves. The meter is replaced. The thermostat is swapped under warranty and the vendor issues a new device identifier without telling anyone.

The consequence is quiet and expensive. Devices that dispatch fine but whose meter data lands under an old service point never appear in your settlement calculation, so you deliver energy you do not get paid for. Devices whose enrollment lapsed keep receiving commands, which produces complaints and, in some programs, a compliance question. Duplicate participants inflate your enrolled capacity, so you bid a fleet that does not exist.

Migration from a previous platform makes it worse, because you inherit whatever mapping the old system had plus whatever was fixed manually in spreadsheets along the way. The honest expectation is that a meaningful share of records will not reconcile on first pass.

The fix is to model the participant, the service point, the meter and the device as separate objects with dated links between them, so history is reconstructable rather than overwritten. Then run a reconciliation report as a standing operational screen: devices with no meter, meters with no device, enrollments with no tariff, and devices that dispatched in the last event but produced no interval data. Somebody works that queue weekly, and your bid stops being fiction.

Why do the device cloud integrations break after launch?

They break because they are not your code and they change on somebody else's release schedule. A vendor deprecates an authentication method, tightens a rate limit before a heat wave, changes a payload field, or reissues credentials during a partner programme migration. None of that appears in your test suite because your test suite talks to your own code.

The specific damage here is that a break can be silent. A command that returns a success response but never reaches the device looks identical to a working dispatch until settlement, at which point the interval is gone. Fleets routinely run for weeks with one brand quietly not applying setpoints because nobody reconciled command intent against telemetry.

The other launch-day surprise is access. Sandbox credentials, rate limit agreements and partner certification queues run on the vendor's calendar, not yours, and they can add weeks per brand. Teams that start integration paperwork at the integration phase rather than in week one lose that time from the schedule with nothing to show for it.

The fix: one adapter per device cloud with its own contract tests, so a breaking change fails in a single place while the rest of the fleet keeps dispatching. Then build the operational half, which matters more. Reconcile every command against telemetry, flag vendors whose commands are acknowledged but not applied, and let the dispatcher substitute from the reserve pool the moment a channel starts under-performing rather than after the settlement statement arrives.

What happens when market baseline and settlement are not covered?

This is the gap that produces the failure in the opening paragraph. Aggregation platforms show telemetry-based performance dashboards. Those are useful for operations and close to useless for revenue, because the market settles you against a baseline computed from interval meter data under the rules of the product, which might be an averaging method with a day-of adjustment, a regression, or a control group.

If you cannot reproduce that calculation yourself, three things become impossible. You cannot challenge a settlement statement, because you have no independent number. You cannot forecast revenue with confidence, because your forecast is built on the wrong measure. And you cannot answer a commercial participant who asks why this event paid less than the last one when they did the same thing, which is the conversation that loses accounts.

The participant payment half has the same shape. A residential customer enrolled mid month, opted out of one event, has two devices on different tariff terms and churned before quarter end. A commercial participant has a demand charge interaction and a contract paying on nominated capacity rather than measured delivery. Nothing in the aggregation layer is built to be a subledger, so the payment run happens in spreadsheets and eventually stops reconciling to the market revenue that funded it.

The fix is to implement the baseline method of the products you actually bid into, run it forward as a forecast before you submit an offer, and store every input so the calculation is reproducible a year later. Then make settlement a ledger: immutable device-level records, participant statements under the tariff terms in force on that date, and corrections posted as new entries rather than edits.

Should you build custom or configure what you already own?

If you run a single thermostat brand under a straightforward utility demand response tariff with a couple of thousand participants, stay on Virtual Peaker or EnergyHub and put the money into enrollment. At that size dispatch is not your constraint, the platform will control your devices competently, and a build is an expensive route to the same result. Virtual Peaker in particular is good at utility-branded enrollment and customer-facing control, which is where the value sits at that scale.

If your devices sit inside AutoGrid Flex or EnergyHub Mercury and your market participation is simple, configure rather than build. Both maintain broad device integration catalogs and both will dispatch your fleet.

Build when two or more of these are true. Your fleet spans three or more device brands and you are measurably losing performance to acknowledgement latency. You bid into a wholesale product and cannot reproduce the settlement baseline. Participant payments are calculated outside the platform and no longer reconcile to market revenue. Your batteries need cycling limits enforced during dispatch because a warranty depends on it. Or the platform running your program owns the customer relationship and your strategy requires that you own it.

How do hidden costs get into the quote?

The count of distinct device clouds is the dominant driver and the one most often understated, because a proposal says device integration as a single line when each vendor is a separate project with its own sandbox access problem and its own certification queue.

Batteries are the second. State of charge management, reserve floors and warranty-aware cycling are modelling work, not an on-off command, and a dispatch engine that ignores them will offer capacity the asset is not allowed to deliver. Participation in a second market product is the third, since each product carries a different baseline method, different telemetry obligations and a different offer format, so it is close to a second settlement implementation rather than a configuration change.

Commercial and industrial sites are the fourth and they are the easiest to underestimate, because every building controls estate is bespoke and the site survey is unavoidable. And interval meter data access is the fifth, because arranging it at the right granularity and lag takes calendar time nobody puts in the plan.

What separates a build that works from one that fails here?

Ask the developer how they would handle a device cloud that acknowledges a command and never applies it. Somebody who has shipped this talks immediately about reconciling command intent against telemetry and flagging silent failures per vendor. Somebody who has not describes an API call and a success response, which is exactly the assumption that produces a fleet quietly under-delivering for a month.

Ask them to draw the path from a market instruction to a customer payment. You want interval meter data and telemetry as separate inputs arriving at different latencies, the baseline method as a versioned calculation with stored inputs, and the participant ledger as immutable postings with tariff terms dated by effect. If the drawing has one table called events, they are going to learn energy settlement on your budget and your regulator's timeline.

Ask which device integrations they have actually built, by vendor name. Thermostat clouds, battery inverter interfaces and commercial building controls are unrelated engineering problems, and a firm that has done one of the three says so plainly rather than claiming a category.

Then settle ownership before kickoff: the repository, the cloud accounts and the device integration credentials. The integration layer is the asset in this category, and a supplier holding those credentials holds your fleet. At Digital Heroes the client owns everything from the first commit. Start by pulling your last three events and asking whether anyone can reconstruct, device by device, why measured delivery differed from the plan. If nobody can, that is your first scope.