OCPP Connector Model: How Multi-Socket Stations Report Status
In OCPP, a charging station exposes one or more connectors. Each connector has an ID, and every status, metering and transaction message references a connectorId. Getting this model right is what makes per-socket billing and per-socket diagnostics possible.
The Numbering Convention
| connectorId | Object | Reported data |
|---|---|---|
| 0 | The station itself (aggregate) | Station-level summary |
| 1…n | Individual sockets | Independent status + metering |
On the WANLIN-002, connectorId 1 = the left socket and connectorId 2 = the right socket. On the WANLIN-010, connectorId 1–10 map to sockets 1–10 in physical/phase order (1–4 on L1, 5–7 on L2, 8–10 on L3).
Why Platforms Must Track Each Connector
- Fault isolation: a shorted socket reports connectorId=n as Faulted; the station and other connectors stay Available. Platforms that infer per-socket state from connectorId 0 will show healthy sockets as broken.
- Correct billing: MeterValues and StartTransaction/StopTransaction carry the connectorId; billing must match the socket the rider actually used.
- Reservations: ReserveNow targets one connectorId, so a rider can reserve a specific socket.
- Smart charging: TxProfile applies per transaction/connector, enabling per-socket power schedules.
Conclusion: when choosing multi-socket OCPP hardware, verify that every physical socket is a real OCPP connector with independent status and metering — not just one aggregate report. That is the difference between operating a charging network and guessing at one.
