System and standards context
How HPA relates to HEMS and energy standards
Home Power Automation is a proposed capability profile that a residential energy-management system can implement. It is not a new communication layer and does not replace HEMS, CEMS or the standards used to exchange device capabilities, measurements, schedules and external signals.
HEMS and CEMS describe established system categories. S2, EEBUS, Matter, OpenADR, OCPP and SunSpec solve different interoperability problems. HPA describes behavior expected from the residential coordinator, regardless of which suitable interfaces it uses.
Terminology
The terms answer different questions.
| Term | What it describes | How to use it here |
|---|---|---|
| EMS | A broad term for technical energy-management systems in homes, buildings, industry and other sites. | Define the context when using it. It can also be confused with the organizational energy-management system in ISO 50001. |
| HEMS | A Home Energy Management System. Capabilities range from monitoring and scheduling to multi-device optimization. | Use it as the established residential system category. A capable HEMS may satisfy the complete HPA proposal. |
| CEMS | A Customer Energy Management System, used in standards including IEC 63402. | Use it when the standards context or customer-premises architecture calls for that term. |
| HPA | A GridPassport-proposed category term and capability profile for automatic coordination across multiple home energy devices and time. | Use it to state the proposed behavior threshold, not to rename every HEMS or claim a new technical standard. |
| GridPassport | A product being developed using the proposed HPA model. | Describe its implemented and planned capabilities separately from the category definition. |
Functional map
HPA belongs in the residential coordination function.
The map is functional rather than a required deployment. One implementation may be local, another cloud-based, and a third hybrid.
Tariffs, market prices, carbon data, weather, solar forecasts, grid power limits and demand-response events. Examples of exchange mechanisms include provider APIs and OpenADR.
A HEMS, CEMS or another residential control service maintains shared site context and resolves decisions across devices. This is the function that may satisfy the proposed HPA profile.
Depending on the equipment and architecture, the coordinator may use S2,EEBUS, Matter, SunSpec Modbus, manufacturer APIs or other suitable interfaces. OCPP connects a charging station with its management system and may be one part of an EV charging path.
Battery inverter, EV charger, heat pump, air conditioner, water heater and other controllable equipment. Device and installation safety controls remain authoritative.
This is not a protocol stack
The named standards are not interchangeable and do not all sit at the same interface. The rows show where information and control may enter the coordination process, not a mandatory sequence of technologies.
Standards by role
Each interface solves a narrower problem.
| Standard or family | Primary role in this context | What it does not establish |
|---|---|---|
| IEC 63402 / ISO/IEC 15067-3 | Customer or home energy-management architecture and requirements. | They do not make HPA a recognized successor category. |
| S2 | Exchange of energy flexibility between a customer energy manager and device-side resource manager. | It does not prescribe the household's optimization objective or commercial product. |
| EEBUS | Energy use cases and interoperable information for devices, EMSs and grid-connection scenarios. | It is not merely transport, and HPA should not claim to add coordination that EEBUS use cases already cover. |
| Matter | IP-based smart-home interoperability, including growing energy data and device capabilities. | Support for energy information does not itself select one whole-home optimization policy. |
| OpenADR | Interoperable exchange of price, reliability, demand-response and DER-management information with energy systems. | It is not the local control algorithm for a battery, charger or heat pump. |
| OCPP | Communication between a charging station and a charging-station management system. | It is not a general home energy-device protocol and does not describe the full EV-to-home control path. |
| Modbus / SunSpec Modbus | Register communication and common DER information models for monitoring and control. | Basic data access is not a multi-device planning or optimization function. |
Example information paths
One decision may cross several interfaces.
| Use case | Possible path | Decision left to the coordinator |
|---|---|---|
| Dynamic price response | A provider API, Matter tariff data or OpenADR signal supplies time-bound price information. | Which flexible device should move, by how much and within which household limits. |
| Battery operation | SunSpec Modbus, EEBUS, S2 or a manufacturer API may expose state, limits and control. | How battery use interacts with EV readiness, solar forecast, reserve and site power. |
| EV charging | EEBUS, Matter, S2, OCPP through a charging backend or a manufacturer interface may expose different parts of the path. | The charging schedule that meets departure needs without breaking site or battery constraints. |
| Grid power limit | EEBUS, Matter, OpenADR or a local gateway may convey a site limit, depending on market design. | How available site power is allocated among controllable devices and household requirements. |
Interoperability claims need scope
A product should name the standard version, role, interface, device type and tested function. “Supports S2” or “supports Matter” is too broad without that detail.
What HPA leaves open
The capability profile should not choose the whole architecture.
- Location: local controller, cloud service or hybrid.
- Method: rules, optimization, model-predictive control, machine learning or a combination.
- Interfaces: open standards, manufacturer APIs or both.
- Commercial model: product sale, subscription, utility service or another arrangement.
- Device safety: remains with the device, installation and applicable regulation.
- Grid participation: requires separate market, contract and communication arrangements.
- Cross-brand coverage: must be demonstrated for the exact supported equipment.
- Performance: needs a declared evaluation method and evidence, not a category label.
Questions for a product or integration
Ask about functions before labels.
- Which devices can the system observe, and which can it control automatically?
- Which versions and functions of each interface have been tested?
- Where does planning run, and what continues when the internet or vendor cloud is unavailable?
- How are device constraints, site limits, user overrides and household requirements prioritized?
- Can the system distinguish command acceptance from a measured result?
- What is logged, what leaves the home and who can revoke control authority?
- Which performance claims are based on replay, simulation or field measurement?
GridPassport
Implementation claims will be narrower than the model.
GridPassport is being developed to implement the proposed HPA functions across supported equipment. The definition is protocol-neutral; the product will use the interfaces actually available for each manufacturer, model and deployment.
Current and planned device coverage belongs in thecompatibility directory. A standards claim will only be made with the relevant version, role and tested scope.
Sources
Primary references for the map.
The referenced organizations have not reviewed or endorsed the HPA proposal.
- IEC 63402-1:2025: Customer energy management systems
An established CEMS architecture and requirements reference.
- IEA 4E EDNA: Residential HEMS and controllers
Describes HEMS that connect and optimize residential generation, storage and loads.
- S2 standard documentation
Describes exchange of resource flexibility between a customer energy manager and resource manager.
- EEBUS energy-management solutions
Covers power limitations, dynamic pricing, flexibility and self-consumption use cases.
- Connectivity Standards Alliance: Matter 1.5 energy management
Adds standardized tariff, price, carbon, metering, grid-limit, solar and EV energy information.
- OpenADR Alliance: OpenADR overview
Defines interoperable exchange of dynamic price and reliability signals among grid actors and energy-management systems.
- Open Charge Alliance: OCPP
Defines communication between charging stations and charging-station management systems.
- SunSpec Alliance: SunSpec Modbus
Defines common information models for monitoring and controlling distributed energy resources over Modbus.
Continue
See the behavior expected from the coordinator.
The functional model covers site boundaries, user authority, information quality, planning, dispatch, verification and recovery without selecting one interface.