This is a look at an operational problem that a growing number of cooperatives and municipal utilities encounter as they build out community solar and behind-the-meter battery programs: the hardware is performing as expected, but the economic and reliability benefits aren't materializing because the operations software can't see the assets clearly enough to dispatch them well.
The scenario below is representative of a class of problems we encounter in early-access program conversations, not a verbatim account of any single organization. The operational details are realistic for a mid-sized electric cooperative running a community solar program with an attached battery incentive program.
The setup
A mid-Atlantic electric cooperative had built a community solar program over three years, enrolling 340 residential customers as virtual net metering subscribers. About 190 of those customers had also installed behind-the-meter battery systems through a parallel incentive program, adding approximately 1.4 MWh of enrolled storage capacity distributed across seven distribution feeders.
The cooperative's program team had done the hard work: designed the program, recruited participants, handled interconnection paperwork, and built an enrollment database in a DERMS system they licensed from a utility software vendor. The DERMS held enrollment records, participated in some OpenADR event signaling, and generated quarterly program performance reports.
The problem: the afternoon peak reduction the program was supposed to deliver was consistently coming in at 60 to 65% of the modeled target. The cooperative's load forecasters had modeled 800 to 850 kW of battery dispatch capacity available on an average peak afternoon. The actual metered response in demand response events was consistently 480 to 550 kW.
Finding the bottleneck
The initial diagnostic assumption was that customer compliance was low. If enrolled customers were opting out or not responding to DR signals, that would explain the gap. But when the program team looked at the OpenADR event logs, opt-out rates were under 10%, which was within expected range for a residential program of this type. The non-response wasn't customers declining to participate; it was assets that were either in the wrong state to contribute or weren't receiving dispatch signals effectively.
Digging further, the team identified the actual gap: battery SoC at dispatch time was lower than the dispatch model assumed. The DERMS dispatched assets based on enrolled capacity, not current SoC. An enrolled 10 kWh battery was treated as having 10 kWh available regardless of whether its current SoC was 90% or 35%. In the afternoons, a significant fraction of enrolled batteries had been partially discharged earlier in the day, either through customer-initiated time-of-use optimization or through automated self-consumption logic in the home energy management systems that accompanied the battery installations.
When the DR event signal went out at 4 PM, the batteries that had been cycling since noon had 4 to 5 kWh available on average rather than 8 to 9 kWh. The dispatch model expected full reserves. The actual fleet had half-reserves on a portion of the portfolio. The gap between modeled and actual delivery was the SoC data gap.
The data latency dimension
The DERMS did have a battery monitoring component: it pulled SoC data from the battery vendor's cloud API on a scheduled basis. The schedule was every 6 hours. The most recent SoC data in the DERMS at 4 PM on any given afternoon was the reading from the 10 AM scheduled pull, or potentially from the overnight pull if the 10 AM pull had failed.
A 6-hour-old SoC reading is not useful for dispatch decisions. Battery self-consumption optimization can move SoC by 20 to 40 percentage points in a 6-hour window during peak solar generation hours. The dispatch model was making decisions based on stale state information, and there was no mechanism in the existing workflow to update that state before issuing the dispatch signal.
The vendor's cloud API supported polling at 15-minute intervals. The DERMS vendor's documentation mentioned this capability but the implementation the cooperative was running hadn't been configured to use it. The 6-hour polling cadence was the default. No one had changed it because the quarterly program reports were being generated from enrollment data, not from real-time SoC data, and the reporting function worked fine at 6-hour cadence.
The fix: continuous SoC telemetry with pre-dispatch state confirmation
The resolution required two changes. First, the polling cadence needed to increase to 15-minute intervals to maintain a usable SoC picture of the fleet. This was a configuration change in the DERMS integration settings, not a software development project. The vendor confirmed the API rate limits would accommodate this for 190 enrolled devices.
Second, the dispatch workflow needed a pre-dispatch confirmation step that calculated available capacity from current SoC data rather than enrolled capacity. Before issuing the 4 PM DR event signal, the system would pull the most recent SoC for each enrolled battery, calculate the expected discharge capacity based on current SoC minus a reserve floor (leaving 20% minimum SoC to protect battery longevity as specified in the program agreement), and use that calculation as the available capacity input to the dispatch model.
This meant the dispatch signal would sometimes commit less capacity than the enrolled maximum. If the fleet's average SoC at 4 PM was 65% rather than the assumed 85%, the dispatchable capacity would be calculated accordingly, and the program would commit to delivering that realistic capacity rather than over-committing against optimistic assumptions.
What changed operationally
With 15-minute SoC telemetry and pre-dispatch capacity calculation in place, the actual vs. modeled delivery gap closed substantially. The dispatch model was no longer working from enrollment records as a proxy for real-time state. Pre-dispatch capacity calculations based on current SoC data produced commitments that the fleet could reliably meet because they were derived from actual fleet state rather than design-day assumptions.
There was an initial period where the pre-dispatch calculations showed significantly less available capacity than the old model had assumed. That wasn't a regression; it was the existing gap becoming visible. The cooperative's peak demand management program was previously over-committing and under-delivering in ways that didn't show up clearly in the quarterly reports, because the reports were tracking event response rates (participation) not actual delivered capacity versus committed capacity.
The lesson that generalizes from this situation: curtailment events and dispatch shortfalls on battery programs are frequently attributable to data latency rather than hardware performance or customer compliance. Before concluding that a battery program's delivery gap is a participation problem, it is worth examining the SoC data infrastructure: when was the last SoC reading taken, what is the polling cadence, and is the dispatch model using enrollment data or current state as its capacity estimate. In our experience, the answer to those questions explains the gap more often than any other single factor.
A note on what was not changed
The cooperative's community solar allocations, virtual net metering agreements, feeder assignments, and battery incentive program terms were all unchanged. The DERMS enrollment database structure was unchanged. No customer communications or program agreements were modified. The fix was entirely in the operations software layer: polling cadence and dispatch model inputs. Hardware performing below expectation was, in this case, not performing below expectation at all. It was performing fine; the software just couldn't see it clearly enough to use it well.