IEEE 2030.5-2018
Smart Energy Profile (SEP 2.0) — Application Protocol for DER Communication
IEEE 2030.5 defines a RESTful HTTP/XML protocol for secure, interoperable communication between distributed energy resources (DER), gateways, and utility/aggregator head-end systems. It enables remote monitoring, control, pricing, and demand response over IP networks — the application layer above IEEE 1547's physical behavior requirements.
Core purpose
Provide a standard communication protocol so utilities/aggregators can monitor and control DER from any vendor without proprietary APIs. The "HTTP/REST for energy devices" — DER expose resources (endpoints) that clients GET/PUT/POST to read status or send commands.
What it is at its core
IEEE 2030.5 is a RESTful application protocol — not a physical layer or power system spec. Key characteristics:
- Client-server model — DER/gateway acts as server hosting resources; utility DERMS or aggregator acts as client polling those resources
- Resource-oriented — Everything is a resource with a URI:
/edev (end device), /der (DER program), /dr (demand response), /mr (metering), /tm (time/tariff)
- XML payloads — Data exchanged as XML over HTTPS (not JSON, for historical/standards-body reasons)
- Security built-in — TLS 1.2+ required, certificate-based device authentication, role-based access control
- Publish-subscribe — Optional push notifications via HTTP long-polling or pub/sub for real-time events
Think of it as the API layer that IEEE 1547 devices use to talk to the grid — 1547 defines what the inverter must do, 2030.5 defines how to tell it to do it.
Village metering context
IEEE 2030.5 is a Phase 3 standard in the ISV roadmap — relevant when a village microgrid has a utility/aggregator DERMS to talk to. Phase 1–2 (prepaid metering, village-internal control) use simpler protocols (DLMS, Modbus, MQTT) without the overhead of IEEE 2030.5 certificate infrastructure. OpenAMI MQTT northbound is the Phase 2 telemetry path; 2030.5 becomes relevant only at utility interconnection (Phase 3).
How it came to be
2008
ZigBee Smart Energy Profile 1.0 — Original SEP over ZigBee (mesh RF). Home area networks (HANs) for smart meters, in-home displays, thermostats.
2012
SEP 2.0 released by ZigBee Alliance — moved to IP/HTTP/XML instead of ZigBee RF. More generic, supports WiFi/Ethernet/cellular, not just mesh.
2013
California adopts SEP 2.0 as mandatory for smart inverter communication (Rule 21 Annex). Utilities need standard API to control rooftop solar fleet.
2018
IEEE 2030.5-2018 — ZigBee Alliance donates SEP 2.0 to IEEE. Becomes IEEE standard, aligned with IEEE 1547-2018 interoperability requirements (Annex E).
2020+
SunSpec Alliance publishes IEEE 2030.5 implementation guide. CSIP (Common Smart Inverter Profile) test certification launched. Adoption grows in CA, HI, Australia, Germany.
Why IEEE standardized it
Before 2030.5, every DER vendor had a proprietary cloud API. Utilities wanting to control aggregated fleets (e.g., 10,000 rooftop inverters for VPP) had to integrate with SolarEdge, Enphase, SMA, Tesla APIs separately — vendor lock-in nightmare. IEEE 2030.5 solved this by providing a single standard protocol all vendors could implement, so utilities/aggregators connect once and reach any compliant device.
Resource structure and message shape
IEEE 2030.5 organizes functionality into function sets (resource trees). Here's the visual structure:
🌐 IEEE 2030.5 Resource Tree (Server = DER/Gateway)
📡 /dcap (Device Capability)
Root resource — advertises which function sets the device supports
GET /dcap → returns links to available resources
🔌 /edev (End Device)
EndDevice
lFDI: device cert fingerprint
sFDI: short device ID
deviceCategory: "PV_INVERTER"
changedTime: timestamp
Registration
dateTimeRegistered: ISO8601
pIN: enrollment PIN
pollRate: default 900 sec
⚡ /derp (DER Program)
DERControl (Commands)
opModConnect
Connect/Disconnect
opModExpLimW
Export limit (W)
opModFixedPFAbsorbW
Fixed power factor
DERCurve (Settings)
curveType: 0 (opModVoltVar)
xMultiplier: voltage
yMultiplier: VAR
CurveData: [(x,y), ...]
curveType: 1 (opModFreqWatt)
xMultiplier: frequency
yMultiplier: power
CurveData: [(x,y), ...]
DERStatus (Monitoring)
readingTime: timestamp
genConnectStatus: 0=disconnected, 1=connected, 2=available
inverterStatus: operating state code
localControlModeStatus: active control mode
operationalModeStatus: current op mode flags
📊 /mr (Metering / Mirror Usage Point)
MirrorReadingSet
ReadingType: defines units, multiplier, data qualifier
timePeriod: start/duration for interval data
💰 /tm (Time / Tariff)
TimeTariffInterval: TOU pricing
RateComponent: energy charges
ConsumptionTariffInterval: tiered rates
🚨 /dr (Demand Response)
DRProgram: event definitions
EndDeviceControl: curtailment commands
LoadShedAvailability: capacity bid
🔒 Security Model
TLS 1.2+ required — all HTTP traffic encrypted
X.509 certificates — mutual auth (client cert + server cert)
lFDI (Long Form Device Identifier) — SHA256 hash of device cert for unique ID
Role-based access — server checks client cert roles before serving resources
How requests work
Client (DERMS) sends HTTP requests to server (DER/gateway):
- GET /edev/0/derp/1/derc/5 → read DER control #5 settings
- PUT /edev/0/derp/1/derc/5 → update control (e.g., change export limit)
- POST /edev/0/derp/1/derc → create new control command
- GET /edev/0/mr/1/mrs → read metering data (mirror reading set)
Server returns XML payloads with requested data or confirmation. Client polls periodically (default 900 sec) or subscribes for push notifications.
Relationship to other standards
| Standard |
Relationship to IEEE 2030.5 |
| IEEE 1547 |
1547 defines behavior (volt-VAR curves, ride-through). 2030.5 is the protocol to configure and monitor that behavior remotely. |
| SunSpec |
Device information model. IEEE 2030.5 DER function set is based on the SunSpec inverter control model. 701–712 is the schema CSIP maps to DERControl. Many inverters speak both — SunSpec Modbus locally, 2030.5 remotely. |
| OpenADR |
Demand response protocol (VTN ↔ VEN). IEEE 2030.5 /dr function set can carry OpenADR-style events, or devices use both protocols (2030.5 for DER control, OpenADR for DR programs). |
| CSIP (Common Smart Inverter Profile) |
SunSpec Alliance test profile for IEEE 2030.5 + 1547 compliance. Defines which 2030.5 function sets are mandatory for California Rule 21. |
| IEC 61850 |
Substation automation protocol. Different domain (utility SCADA vs. DER fleet management). Some overlap in metering/control concepts but not interoperable. |
Relevance to village microgrids
When IEEE 2030.5 matters for ISV deployments
IEEE 2030.5 is utility-facing — designed for scenarios where a utility DERMS or aggregator needs to control DER remotely. For village microgrids:
- Phase 1–2: Village-internal control uses simpler protocols (DLMS for prepaid meters, Modbus for inverters, MQTT for telemetry). No IEEE 2030.5 needed.
- Phase 3: When village interconnects to main utility grid and utility wants to control the microgrid as aggregated DER (export limits, curtailment, VPP participation), then IEEE 2030.5 becomes relevant.
- Certificate overhead: IEEE 2030.5 requires X.509 cert infrastructure (enrollment, provisioning, renewal). Village operators may lack PKI capability; OpenAMI MQTT is lighter-weight for Phase 2.
Most ISV villages won't implement IEEE 2030.5 until they have a utility interconnection agreement requiring it (Phase 3, years after initial deployment).
ISV-specific considerations
- OpenAMI MQTT vs. IEEE 2030.5 — OpenAMI uses JSON/MQTT for village-internal telemetry (Phase 2). IEEE 2030.5 is for utility-facing control (Phase 3). They serve different layers.
- Gateway role — Village gateway (Street EMS) could act as IEEE 2030.5 server, aggregating multiple DER/meters into one interface for utility DERMS.
- Prepaid/STS unchanged — IEEE 2030.5 doesn't address prepaid metering, STS tokens, or village billing. Those stay in DLMS/COSEM domain (Phase 1).
- IEEE 2030.5 + Modbus — Likely deployment: village uses Modbus/MQTT internally (Phase 1–2), adds IEEE 2030.5 gateway at PCC when grid arrives (Phase 3).
Key takeaways
- IEEE 2030.5 is the standard communication protocol for DER — the "API" that IEEE 1547 devices use to talk to utilities/aggregators
- RESTful HTTP/XML over TLS — resource-oriented (devices expose endpoints), certificate-based security
- Function sets: DER control/status, metering, pricing/tariffs, demand response, time sync
- For ISV: Phase 3 standard — relevant at utility interconnection, not for village-internal operations (Phase 1–2 use DLMS, Modbus, MQTT)
- Complements IEEE 1547 (behavior) and SunSpec (device models 701–712) — the application layer above physical DER
Further reading