A utility that knows every customer address, transformer assignment, and interconnection record for its solar customers has extensive administrative data about its DER fleet. What it likely lacks is operational data: what is each of those inverters doing right now, what are the feeders actually seeing in terms of net load and reverse power flow, and which assets are currently available versus offline or curtailed. The administrative view and the operational view are different data systems solving different problems, and confusing them is a persistent source of DER management failure.
Grid-edge telemetry is the operational data problem. This piece describes what it means, where it comes from technically, and why it's harder than it appears from the outside.
What "grid-edge" means operationally
The grid edge is the distribution secondary and service entrance level: the point where utility infrastructure connects to customer-owned premises and equipment. For DER management purposes, the grid edge is where the inverters, batteries, EVSE, and smart thermostats live. It is also the point where utility visibility historically ended.
Traditional grid metering infrastructure (SCADA, substation RTUs, automated switchgear) captures data at the feeder and substation level. AMI captures billing interval data at the meter level (typically 15-minute intervals, once per day or near-real-time in advanced AMI deployments). Neither of these was designed to provide sub-minute operational data about what individual DERs are doing at a given moment.
Grid-edge telemetry, as distinct from billing metering, means: continuous telemetry from individual DER assets (inverters, batteries, EVSE) at sub-minute polling intervals, with enough state information to support operational decisions. The relevant state variables include active power output, reactive power consumption, SoC, operating mode, curtailment status, and alarm conditions. Together, they tell the operations team what the feeder's DER contribution is in real time, not as a 15-minute average reconstructed from billing reads.
Why telemetry is harder to collect than it looks
A utility with 5,000 solar interconnections doesn't have access to 5,000 live data streams just because those customers signed an interconnection agreement. The inverter communications infrastructure is owned and operated by the inverter manufacturer. The telemetry from those inverters flows to the manufacturer's cloud platform, not to the utility's operations systems. Access requires an API integration with each manufacturer, which means separate authentication, separate data schemas, and separate reliability characteristics for each vendor's cloud platform.
A residential DER fleet assembled over five years through customer-driven installation will typically represent four to eight inverter manufacturers, two to four battery vendors, and multiple EVSE brands. Each has its own API, its own data model, and its own SLA for API uptime. Some provide real-time push telemetry; others require polling. Some provide 1-second resolution data; others provide 5-minute averages. Some have APIs that are well-documented and stable; others have APIs that were clearly designed for their own mobile apps rather than utility integrations and behave unpredictably under load.
IEEE 2030.5 was designed to address this fragmentation by providing a standard protocol for utility-to-DER communication. When an inverter is IEEE 2030.5 compliant and the utility has deployed a CSIP-compliant DERMS, the utility can poll DER state directly via the standard protocol rather than routing through the manufacturer's cloud. This is the right long-term architecture. In practice, IEEE 2030.5 compliance varies significantly by manufacturer and inverter vintage, and the installed base includes many assets that predate or don't implement the standard fully. Transitioning to a fully standards-based telemetry architecture takes years of installation turnover.
Latency and staleness in real-time DER operations
The latency between an event at the grid edge and its representation in the operations platform is a critical parameter that most telemetry vendors understate. When an inverter trips offline due to a voltage excursion, the event occurs at the device. The event is logged in the inverter's onboard memory. The telemetry system pulls the event during the next polling cycle. The poll response arrives at the data platform. The data platform processes and stores the reading. The operations view updates.
Each step adds latency. For an inverter API integration with a 5-minute polling cadence, the end-to-end latency from event to operations view can be 6 to 10 minutes. For a fleet of 3,000 inverters with a vendor API that rate-limits requests to prevent overload, the polling cycle for the full fleet may take 8 to 12 minutes to complete, meaning some assets' readings are always 12 minutes old. For grid operations, a 12-minute stale picture of feeder DER state is not an operational view; it is a lagging indicator that may not reflect the current grid state at all during fast-moving events like cloud transients or switching operations.
The difference between a telemetry platform designed for billing verification (15-minute intervals are fine, latency of several minutes is acceptable) and one designed for real-time dispatch operations (sub-5-minute data, latency measured in seconds to 2 minutes) is architectural, not a configuration parameter. A telemetry platform built for billing is not reusable for operations by reducing its polling interval; the underlying data pipeline, API call management, and storage architecture all need to be designed for the tighter latency requirement from the start.
Feeder-level visibility versus asset-level visibility
There are two distinct visibility requirements in DER operations that are sometimes conflated, and they have different data source requirements.
Feeder-level visibility is the question: what is the net load on this feeder right now, including the contributions from all DERs on the feeder? This can be addressed with distribution-grade meters at the substation and feeder head, combined with a feeder model that attributes load and generation to the feeder's sections. AMI data at 15-minute intervals, fed into a feeder state estimation model, can provide a reasonable feeder-level view of DER impact. This is useful for planning, post-hoc analysis, and feeder loading alarms. It is not sufficient for real-time dispatch decisions.
Asset-level visibility is the question: what is each specific enrolled asset doing right now, and what can I dispatch from it? This requires direct asset telemetry: the SoC of each battery, the current output of each inverter, the charge state of each enrolled EVSE. Feeder metering cannot provide this; it sees the net effect of all assets on the feeder, not the state of individual assets. A feeder with 50 solar-plus-storage customers may show 600 kW of net generation from 400 kW of solar and 200 kW of battery discharge, but the feeder meter cannot tell you which of the 50 batteries are currently discharging and which are at what SoC.
Dispatch decisions for demand response programs require asset-level data. Pre-dispatch capacity calculations require knowing which assets are available and at what state, not just what the feeder aggregate shows. This is why asset-level telemetry is not a nice-to-have for DER programs; it is a prerequisite for dispatch reliability.
Communication path diversity and redundancy
A grid-edge telemetry infrastructure that routes all data through manufacturer cloud APIs has a single-point-of-failure architecture: when a manufacturer's cloud platform experiences an outage, the utility loses visibility into all assets from that manufacturer simultaneously. For a fleet with significant concentration in one or two inverter brands, this can mean losing visibility into a large fraction of the DER fleet at the same time the utility most needs that data (high-demand events, when API load on cloud platforms is also highest).
A more resilient architecture maintains multiple data collection paths: manufacturer cloud APIs as the primary path for assets that support them; IEEE 2030.5 direct connections for compliant assets as a parallel path; MODBUS TCP direct device connections for inverters with local network access on utility-owned premises; and AMI meter reads as a trailing fallback for net-generation accounting when real-time paths are unavailable. Each path has different latency and reliability characteristics, and the telemetry platform needs to track data freshness per asset and per path so the operations view accurately reflects which assets are being monitored in real time versus which are on degraded or fallback data.
Building this kind of multi-path telemetry architecture from scratch is a significant engineering investment. For most utility operations teams, the practical path is a DER management platform that already handles multi-vendor, multi-protocol telemetry normalization, rather than building those integrations in-house. The operational requirement, though, is the same regardless of whether it's built or procured: real-time data from the grid edge, with honest staleness tracking, from assets that span multiple vendor ecosystems and communication standards.
What the data gap costs operationally
The cost of the grid-edge telemetry gap is not always visible in quarterly program reports or reliability statistics, because those reports aggregate over time windows that smooth out real-time gaps. But it shows up consistently in two places: demand response event under-performance (dispatch commitments that can't be met because the dispatch model doesn't know the fleet's real-time state) and feeder voltage anomalies that persist longer than they should because the operations team doesn't have fast enough visibility into which DERs on the feeder are causing or contributing to the excursion.
Closing that gap is not a matter of deploying more data; it is a matter of deploying the right kind of data infrastructure for the specific operational question being answered. Feeder-level metering answers feeder-level questions. Asset-level telemetry answers dispatch questions. Both are necessary, and neither substitutes for the other.