When we describe Nexwatt's core technical challenge to energy engineers who haven't worked in community solar, the reaction is often: "that sounds like a standard distributed data aggregation problem." It's not — and the reason it's not comes down to a specific mismatch between how community solar programs collect subscriber meter data and what ISO capacity markets require for real-time dispatch telemetry. This post is an honest description of that mismatch and why it's harder to solve than it looks.
How Community Solar Meter Data Actually Arrives
Community solar programs subscribe residential and small commercial customers to solar generation. The subscriber's electric bill is reduced based on their share of the program's output, calculated from production data that flows through the electric distribution company's metering infrastructure. In most states with community solar programs, the EDC reads the subscriber's AMI meter on the same schedule as billing — typically every 15 or 30 minutes for interval data, with a transmission delay that means the most recent data available to the program operator may be 24-48 hours old.
The 24-48 hour delay exists because residential AMI data collection is optimized for billing accuracy, not operational visibility. AMI meters store interval data locally and transmit it to the utility's MDMS in batches — some systems transmit hourly, some nightly. The MDMS then processes and validates the data before making it available to program operators through EDI feeds or Green Button Connect exports. By the time a community solar program operator sees a subscriber's meter reading in their system, the interval may have occurred two days earlier.
For subscriber billing, this latency is acceptable — the generation credit is calculated after the fact, and the EDC settlement process operates on a monthly basis. For ISO capacity market telemetry, it's a problem. ISOs require capacity resources to report real-time or near-real-time output during dispatch events, with typical requirements in the range of 2-10 minute update intervals. A data source with a 24-48 hour delay cannot meet this requirement, regardless of how sophisticated the aggregation software is.
The Dual Data Path Problem
The practical response to this latency gap is to operate two parallel data paths: the authoritative AMI/MDMS path for settlement and billing purposes, and a supplemental near-real-time path for ISO telemetry reporting during dispatch events. The near-real-time path is typically built on inverter monitoring APIs — SolarEdge, Enphase, SMA, and similar platforms that provide generation data at 5-15 minute latency through cloud APIs.
This approach works, but it creates a data reconciliation requirement. The inverter monitoring data and the AMI data will not agree exactly, for several reasons: inverter clocks drift, meter read timestamps are rounded differently than inverter timestamps, and inverter-reported generation includes losses that occur between the inverter and the meter. An aggregation platform that uses inverter data for real-time telemetry and AMI data for settlement needs to maintain a running reconciliation of the two sources and flag systematic discrepancies for investigation.
We're not saying that inverter data is unreliable in an absolute sense — it's generally accurate enough for real-time telemetry purposes. The issue is that the ISO settles based on the metered data, not the inverter data. If your telemetry reports 3.2 MW during a dispatch event but the settlement meter shows 2.9 MW, you have a 300 kW performance shortfall on the settlement record even if your telemetry was reporting in good faith from real-time inverter data. Understanding the systematic relationship between your inverter data and your metered data before dispatch events occur — not after — is essential for commitment sizing and shortfall risk management.
Subscriber Meter Resolution Variability
The latency problem is compounded by resolution variability within the subscriber base. A community solar program serving a mix of residential and small commercial subscribers will have meter data arriving at different resolutions and latencies depending on the EDC and rate class. Residential accounts on 15-minute AMI intervals in a modern metering district may have relatively fresh data (4-6 hours delayed) while residential accounts on older metering infrastructure in a different part of the same utility territory may be on manual-read billing cycles with monthly meter data availability.
For ISO telemetry purposes, the relevant question is: what is the minimum metering coverage needed to characterize the aggregated portfolio's output in near-real-time? The answer depends on the composition of the portfolio. A portfolio where 80% of capacity is in commercial accounts with 15-minute submetering and solid SCADA connections is in a different position than a portfolio where 80% of capacity is spread across residential rooftop accounts with AMI meters and 24-hour data latency.
Programs with predominantly residential BTM assets need the most robust supplemental telemetry path because they have the most latency in their primary data source. This is worth understanding before ISO enrollment, not after — the telemetry architecture needed for a residential-heavy portfolio requires more investment in inverter API coverage and local edge collection than a portfolio anchored in commercial and industrial accounts.
The Gap-Filling Problem
Even with a well-designed dual data path, gaps in real-time data occur. Inverter API outages, communication dropouts at individual installations, network connectivity issues at edge collection points — these are normal operational events in a distributed asset fleet. The aggregation platform needs a strategy for handling them during dispatch events: does it interpolate from recent data, report the last-known value with a staleness flag, or reduce the reported capacity to exclude assets with stale data?
Each approach has implications for ISO performance assessment. Interpolating from stale data risks reporting performance that didn't actually occur. Reducing reported capacity conservatively avoids overstatement but may trigger performance shortfalls against the committed level if the excluded assets were actually performing. ISO telemetry specifications typically address gap-filling requirements, but the specification language doesn't always map cleanly to the operational reality of a distributed asset fleet where data gaps are portfolio-wide events (when an inverter API goes down) rather than individual-asset events.
The programs that manage this well establish clear gap-filling policies in advance — documented at the platform level and reviewed with the ISO's telemetry team before the enrollment process is complete. Discovering your gap-filling approach is non-compliant during a dispatch test event is a significantly worse outcome than clarifying it during telemetry testing.
What Good Telemetry Architecture Looks Like
For a community solar VPP targeting ISO capacity market participation, a telemetry architecture that can meet real-time reporting requirements should include: (1) direct inverter API polling at 5-minute or better intervals for the generation assets, with failover to cached last-known values for API outages; (2) AMI data ingestion from EDC MDMS for settlement reconciliation and data quality benchmarking; (3) a reconciliation layer that tracks the systematic offset between inverter-reported and AMI-metered data for each asset over rolling periods; (4) alerting for data staleness thresholds that allows operators to investigate and remediate before dispatch events occur; and (5) an ISO telemetry reporting module that aggregates the real-time data path and delivers it to the ISO's interface at the required protocol and polling interval.
Building this from scratch is a multi-month engineering project. Sourcing it from a platform that's already designed around the ISO telemetry requirement — rather than adapting a subscriber billing tool — compresses the timeline substantially. The critical insight is that the telemetry architecture needs to be designed for the ISO dispatch use case from the start, not retrofitted onto a subscriber management system that was originally built for billing.
The data latency problem in community solar VPPs is well-understood by the small number of organizations that have worked through ISO capacity enrollment for BTM portfolios. It's less well-understood by community solar program operators who are evaluating their first ISO enrollment — which is why it tends to be the step that causes the most unplanned schedule delays.