Concept draft 0.2
Proposed functional model for Home Power Automation
This document describes the functions, information and responsibility boundaries needed for automatic, time-aware coordination across multiple home energy devices. It does not prescribe a product, protocol, optimization method or deployment architecture.
GridPassport concept draft, published for clarity and review. It is not an industry standard, specification, certification program or conformance claim. The words “should” and “can” are descriptive, not normative requirements.
Scope
What this model describes.
In scope
- The declared boundary of one home or residential site.
- Two or more independently controllable energy devices.
- Current state, requirements, forecasts, deadlines and external signals.
- Planning, automatic dispatch, confirmation, verification and recovery.
- User authority, device authority, failure visibility and decision records.
Outside this model
- Electrical protection, battery management, anti-islanding or HVAC safety logic.
- A required protocol, data model, transport, cloud service or hardware gateway.
- A required optimization algorithm, use of AI or commercial business model.
- Guaranteed savings, carbon reduction, resilience or cross-brand interoperability.
- Formal product certification or legal compliance in any market.
Core terms
Terms used in this document.
| Term | Meaning in this model |
|---|---|
| Site | The declared residential boundary, normally measured at one grid connection point, plus the devices included in the plan. |
| Energy resource | A controllable device or subsystem that produces, stores or uses electricity, such as a battery inverter, EV charger or heat pump. |
| Coordinator | The HEMS, CEMS or other service that maintains shared context and produces the time-dependent plan. |
| Hard constraint | A limit the coordinator must not intentionally violate, such as a device operating bound, grid-connection limit or manual stop. |
| Household requirement | A declared result or range such as EV readiness, minimum battery reserve or indoor comfort. |
| Preference | A goal that can be traded against another goal, such as lower cost, more solar self-use or lower peak demand. |
| Material action | A command or schedule change that can materially affect energy, cost, comfort, mobility or reserve. |
System boundary and actors
The model separates household authority, coordination and device control.
An implementation should declare which devices and measurements are inside its boundary. External prices, forecasts and grid signals enter as inputs; they do not take away local safety authority.
| Actor | Provides | Retains authority over |
|---|---|---|
| Household | Requirements, preferences, consent, schedules and manual instructions | Enabling, pausing or overriding automation within safe equipment operation |
| Coordinator | Shared state, forecasts, conflict resolution, timed plan and decision record | Choosing between feasible actions inside declared constraints |
| Device controller | Capabilities, state, operating limits, command response and measured outcome | Manufacturer safety logic and rejection of unsafe or unavailable actions |
| Metering source | Site or device measurements with units, timestamps and quality information | The integrity and availability of the measurement it publishes |
| External provider | Tariffs, forecasts, grid limits, reliability events or demand-response requests | The meaning, validity period and provenance of its signal |
| Installer or operator | Commissioning, declared site limits, device permissions and fallback configuration | Work that requires qualified access under local rules |
Information
A plan needs values and evidence about their quality.
Every operational value should have a source, unit, timestamp and validity state. Forecasts should also identify their horizon and, where available, uncertainty.
| Information class | Examples | Quality question |
|---|---|---|
| Measured state | Site power, battery state of charge, EV connection, room temperature | How recent, complete and accurately timestamped is the reading? |
| Resource capability | Power range, energy need, availability window, ramp or cycling limit | Is the capability current, and which device or controller asserted it? |
| Requirements | Departure deadline, minimum reserve, comfort range, manual pause | Is it hard or preferred, who set it, and when does it expire? |
| Forecast or signal | Solar forecast, weather, tariff, export rate, grid event | What period does it cover, and what happens if it is missing or revised? |
| Action state | Planned, sent, accepted, rejected, failed, stale, cancelled | Does the status confirm receipt only, or the physical outcome as well? |
Decision functions
Eight functions close the control loop.
- Observe. Collect site and device state, then mark missing, invalid or stale data.
- Look ahead. Ingest relevant forecasts, deadlines, tariffs and external limits for the chosen horizon.
- Build feasible options. Ask what each resource can do while preserving hard constraints.
- Resolve conflicts. Protect safety and hard requirements before comparing preferences such as cost or self-consumption.
- Plan. Produce time-bound actions across the included resources and state the assumptions behind them.
- Dispatch. Authenticate the target, send allowed actions and record the command and expected response.
- Confirm and verify. Distinguish command acceptance from the measured physical outcome where telemetry supports it.
- Recover and explain. Replan after material change or failure, use the declared fallback and make unmet requirements visible.
Decision horizons
An implementation may combine immediate protection and correction, intraday scheduling and day-ahead planning. The appropriate horizon and update rate depend on the devices, tariff, forecasts and use case.
Authority and conflict handling
The coordinator chooses only among allowed actions.
| Class | Examples | Expected handling |
|---|---|---|
| Safety and installation limits | Battery operating bounds, anti-islanding, thermal protection, connection-point power limit | Remain authoritative. The coordinator must not intentionally work around them. |
| Manual instruction | Pause automation, stop charging, temporary comfort change | Take effect promptly within safe equipment operation and have a clear duration or release condition. |
| Hard household requirement | Minimum reserve, EV energy by departure, allowed comfort range | Protect when feasible. If requirements conflict, report which one cannot be met and why. |
| Preference | Lower cost, more solar self-use, lower peak, lower emissions | Optimize only inside the feasible region left by higher-authority constraints. |
Failure handling
Unavailable control must become a visible state.
| Condition | Minimum response proposed by this model |
|---|---|
| Stale or missing input | Do not present an old value as current. Reduce the available action set or use the declared fallback. |
| Command rejected | Record the rejection and reason, update resource availability and replan if the action was material. |
| No acknowledgement | Mark the outcome unknown. Check state before retrying so a delayed command is not duplicated. |
| Lost device connection | Let the device continue its local safe behavior, remove uncertain flexibility and show reduced coverage. |
| Conflicting requirements | Preserve safety, identify the infeasible combination and make the expected shortfall visible before the deadline where possible. |
| Clock or timezone mismatch | Reject or revalidate time-bound actions until timestamps and tariff periods can be interpreted consistently. |
Worked example
EV readiness with a protected battery reserve.
From inputs to a checked result.
- Boundary
- One grid connection point, one home battery and one EV charger. Heating is observed but not controlled in this example.
- State
- Battery 62%; EV connected and needs 18 kWh; current site import 0.8 kW.
- Constraints
- Battery reserve at least 30%; EV ready by 07:00; connection-point import at most 11 kW.
- Signals
- Low tariff from 01:00 to 04:00; weak solar forecast for the following morning.
- Plan
- Keep battery discharge disabled for EV charging, schedule the charger inside the low-price period and leave margin under the site limit.
- Dispatch
- Send the schedule with an expiry time. Record whether the charger accepts or rejects it.
- Verification
- Check charger power, EV energy delivered and battery state. Replan if charging starts late or household load reduces available power.
- Explanation
- “EV charging moved to 01:00-04:00. The 30% home-battery reserve remains protected.”
Security, privacy and records
Control authority needs an auditable boundary.
Device identities, commands and external signals should be authenticated. Access should use the least authority needed for the declared function, with explicit commissioning and revocation.
The system should minimize household data, state what leaves the site and define how long detailed device state and decision logs are retained.
A decision record should include the active requirements, relevant inputs, selected action, target, timestamps, command response, measured outcome where available and fallback used.
This model does not define a security profile. Implementations remain responsible for applicable product, electrical, privacy and cybersecurity requirements.
Relationship to existing work
The model is intended to sit inside established residential energy systems.
A HEMS or CEMS may already implement every function described here. Standards and protocols can supply device capabilities, measurements, schedules and external signals. HPA does not add a new communication layer.
The separate system and standards contextdistinguishes residential system architecture, device flexibility interfaces, grid and market signals, EV charging backends and DER data models.
Open questions and changes
What still needs external review.
Open questions
- Which capabilities belong in a minimum profile and which should be optional?
- How should outcome verification work when only indirect site telemetry is available?
- Which failure and recovery test cases are portable across device types?
- How should local-only, cloud and hybrid implementations disclose reliability differences?
- What independent governance would be needed before any conformance claim?
Change note for draft 0.2
- Changed status from “reference model” to a proposed functional concept model.
- Added the site boundary, actors, information quality and authority split.
- Separated command acceptance from physical outcome verification.
- Added failure states, security, privacy and explicit non-goals.
- Removed the claim that GridPassport is a certified or neutral reference implementation.
Sources
Standards and public criteria considered.
These organizations have not reviewed or endorsed this GridPassport proposal.
- IEC 63402-1:2025: Customer energy management systems
An established reference for CEMS architecture and general requirements. This HPA proposal does not replace it.
- ISO/IEC 15067-3:2024: HES model of a demand-response energy management system
A formal residential energy-management model relevant to actors, interfaces and demand response.
- IEA 4E EDNA: Residential HEMS and controllers
Documents the range of HEMS functions and residential devices already coordinated by the market.
- S2: Background and approach
Explains the split between a customer energy manager and device-side resource managers that retain local constraints.
- ENERGY STAR: Smart Home Energy Management Systems criteria
Public requirements covering automated control, user opt-out, privacy, cybersecurity reporting and field performance.
Review
Challenge the model before it becomes a specification.
Useful feedback identifies an unclear boundary, missing failure state, conflicting responsibility or test case that the model cannot describe.