OCPP feature coverage
OCPP 2.1 organises its use cases into nineteen functional blocks, A to S. This page states plainly which of them this platform implements, so you can find out in a minute rather than an afternoon.
Coverage is assessed by whether the capability is reachable through the API and works end to end — not by whether a version number is mentioned somewhere.
| Register | |
|---|---|
| ✅ | Works today. Reachable through the API, end to end. |
| ◐ | Partial. Some of the block works; the rest is absent. |
| ✗ | Not implemented. No API, and generally no wire support either. |
The blocks#
| Block | State | Notes | |
|---|---|---|---|
| A | Security | ◐ | Basic auth over TLS (Security Profile 2) and credential rotation work. TLS client certificates (Profile 3), certificate signing and security event reporting do not. |
| B | Provisioning | ✅ | Boot handshake, registration status, configuration keys, the 2.x device model, reset, triggered messages. |
| C | Authorization | ✅ | Id-token registry, live authorization, the station-side cache. |
| C | Payment | ✗ | No payment terminal support, no cost model. |
| D | LocalAuthorizationList | ✅ | Curate a list, push it, read a station's version. OCPP 1.6. |
| E | Transactions | ✅ | Full lifecycle, event log, energy, transaction ceilings. |
| F | RemoteControl | ✅ | Remote start and stop, unlock connector, triggered messages, capped remote start. |
| G | Availability | ✅ | Operative and inoperative, per connector, EVSE or station. |
| H | Reservation | ✗ | No reservation endpoints. |
| I | Tariff and Costs | ✗ | No pricing or cost concept anywhere in the platform. |
| J | Metering | ✅ | Transaction and standalone readings. Main-meter readings are discarded. |
| K | SmartCharging | ◐ | Static charging limits, a circuit model, and a live equal-share optimizer. Most of the block's twenty-eight use cases are not exposed. |
| L | Firmware Management | ✗ | No remote firmware update. |
| M | Certificate Management | ✗ | No certificate installation or rotation. |
| N | Diagnostics | ✗ | No log retrieval, no monitoring or event configuration. |
| O | Display Message | ◐ | Messages a station reports are handled at the gateway; nothing is exposed through the API, and messages cannot be set. |
| P | DataTransfer | ✅ | Both directions. |
| Q | Bidirectional Power Transfer | ✗ | No vehicle-to-grid support. |
| R | DER Control | ✗ | No distributed energy resource control. |
| S | Battery Swapping | ✗ | Not supported. |
Eight blocks work, three are partial, eight are absent.
What that means in practice#
The core of running a charging network is covered. Provisioning, authorization, transactions, metering, remote control and availability are the blocks a fleet uses every day, and all six work.
The commercial layer is not. Tariffs, costs and payment are entirely absent. There is no pricing concept in the platform at all — which is worth knowing early if you expected to read a session's cost rather than compute it from energy and your own rates.
Smart charging is partial in a specific way. You can install ceilings and model the electrical topology, and the optimizer will share capacity between active sessions. What you cannot do is reach OCPP's own smart-charging vocabulary — charging profile stacks, composite schedules, most of the twenty-eight use cases in block K.
Nothing in the vehicle-to-grid family exists. Bidirectional power, DER control and battery swapping are all absent. These are OCPP 2.1's newest blocks and the least widely supported in hardware.
Beyond the blocks#
Some things this platform does are not OCPP use cases at all, and so appear nowhere above:
- Multi-tenancy — organizations, environments, members and roles.
- Electrical topology — sites and the circuit tree, with invariants enforced on write.
- Day-ahead energy prices — collected from ENTSO-E and served through the API.
- Live event streaming — server-sent events instead of polling.
Equally, a few known gaps sit inside blocks marked ✅:
- Main-meter readings (a station's own meter, belonging to no connector) are logged and discarded.
- Boot history is not kept — only the latest boot report.
- Command follow-ups are not correlated. An accepted remote start and the transaction it produces are unrelated records, and nothing tracks whether an accepted triggered message was ever honoured.
Protocol versions#
All three versions connect, boot, authorize, report status, run transactions and send meter values. OCPP 1.6 is the most complete implementation and is what a station offering several will be given. See Which OCPP version am I dealing with?.
Coverage above is platform coverage. A block marked ✅ still depends on the
station in front of you supporting it — a 1.6 station has no device model, and
a station that does not implement UnlockConnector will say so.
Reading this page honestly#
Two things it deliberately does not do.
It does not claim a block is supported because the wire types exist. Several blocks have partial plumbing in the gateway with nothing reachable through the API; those are marked ✗ or ◐, because a capability you cannot invoke is not a capability.
It does not promise dates. Absent blocks are absent; some are planned, and this page will say so when they arrive rather than before.
If something here is wrong — a block marked ✗ that you have working, or the reverse — that is a documentation bug worth reporting.