Listed
The product is identified. Integration has not been validated.
Integration due diligence
A brand is not compatible. A tested model and capability are.
Record the exact hardware, firmware, connection path and functions that work. Then test command feedback, failure behavior and manual override before calling an energy device supported.
Short answer
Compatibility is a versioned test result.
The useful unit is not "Brand X". It is "model X, hardware revision Y, market Z, firmware A, through gateway B, validated on this date for these exact signals and commands".
Anything less invites two common failures: read-only monitoring sold as control, and an integration that works in a demo but has no safe behavior when data, network or firmware changes.
Support levels
Use precise labels instead of one compatibility badge.
Monitored
Named telemetry has been read, checked and timestamped.
Controllable
Documented commands have been tested inside safe ranges.
Coordinated
Commands and observed response form a verified control loop.
Resilience-tested
Timeout, outage, reboot, fallback and override have been verified.
These five labels are a GridPassport editorial framework, not an industry certification standard.
Compatibility record
Twelve fields to complete before installation.
| Area | What must be recorded or tested |
|---|---|
| Identity | Exact model code, hardware revision, market or region and applicable grid code. |
| Software | Device, gateway and API firmware versions, plus the date last validated. |
| Connection | LAN, RS485, Modbus TCP, cloud API, OCPP or another path, including any required gateway. |
| Authentication | Local credentials, tokens, installer access, renewal and recovery method. |
| Monitoring | Exact signals, units, timestamps, precision, direction conventions and refresh interval. |
| Control | Writable commands, ranges, ramp limits, acknowledgement and permissions. |
| Feedback | Whether actual power or state is read back after every material command. |
| Authority | Priority of device safety, grid code, vendor optimizer, HEMS and user override. |
| Failure | Timeout, stale-data limit, controller loss, WAN loss and device disconnection behavior. |
| Override | Physical or app override, duration and the route back to automatic control. |
| Updates | Support period, changelog, regression policy and retest trigger. |
| Ownership | Who enables access, maintains gateways and fixes the integration after change. |
Protocol nuance
A protocol name does not tell you what the device can do.
Modbusmoves data, but the exact register map, units and writable values can still differ.
SunSpecadds shared DER models, while optional models and manufacturer extensions still require validation.
OCPPcan identify charger capabilities, but Core certification alone does not guarantee the optional Smart Charging profile.
Cloud APImay expose monitoring only, enforce rate limits or stop working when account or vendor services are unavailable.
Acceptance test
Make failure part of commissioning.
- Read every required signal across normal, charging, discharging, idle and fault states.
- Send a bounded command, verify acknowledgement and read back the actual response.
- Disconnect WAN while keeping the local network available.
- Stop the HEMS controller and confirm the device returns to a documented safe policy.
- Restart device, gateway and controller in different orders.
- Feed stale or missing data and verify the timeout.
- Use the homeowner override and confirm automatic control resumes predictably.
- Repeat the relevant tests after firmware or gateway changes.
The final handover should state what is monitored, what is controlled, what fails open or closed and who receives the first support call.
FAQ
Compatibility questions.
What does HEMS compatibility mean?
It means a specific model, hardware revision, region, firmware and connection path has been validated for named monitoring or control capabilities. A manufacturer logo alone is not enough.
Does Modbus support guarantee compatibility?
No. Modbus defines communication mechanisms, but register maps, units, writable values, security and vendor extensions still vary. The exact model and map must be tested.
Is monitoring the same as control?
No. An integration may read power and state without exposing any safe write command. Compatibility should list monitoring and control separately.
Why does firmware matter?
Firmware can change registers, authentication, behavior and supported functions. A compatibility record should include the validated version and be retested after relevant updates.
Who owns an integration failure?
That should be agreed before installation. The homeowner needs to know who enables access, who maintains gateways and credentials, and who diagnoses a failure after device or firmware changes.
Sources
Protocol and device references.
- Modbus Organization: protocol specifications
The official Modbus specifications. Protocol availability does not by itself define a shared device data model.
- SunSpec Modbus
Defines interoperable information models for distributed energy equipment while still allowing model and manufacturer-specific capabilities.
- Open Charge Alliance: OCPP 2.0.1 certification
Shows that OCPP certification uses profiles and that Smart Charging is a separately tested capability rather than a consequence of Core alone.
- SolarEdge Monitoring API guide
A concrete manufacturer example of monitoring endpoints and request limits that should not be confused with device control.
- Victron GX Modbus-TCP manual
Explains that available registers and writable configuration depend on the connected device and system.
- ENERGY STAR: Smart Home Energy Management Systems criteria
Public criteria for connected home energy services, device control, user overrides, time-of-use response, privacy and cybersecurity reporting.