OCPP — the Open Charge Point Protocol — is the language between a charger and a management platform. You do not need to implement it, but you do need to be able to read it, because every billing dispute and every mysterious fault is ultimately settled by looking at the frames.
The shape of the protocol
OCPP-J runs over a WebSocket. The charger connects out to the platform — which is why firewalls that block WebSocket upgrades are a common commissioning failure — and both sides can then send calls. Each call gets a result or an error, correlated by a message id.
Two directions matter. Charger to platform: BootNotification, Heartbeat, StatusNotification, Authorize, StartTransaction, MeterValues, StopTransaction. Platform to charger: RemoteStartTransaction, RemoteStopTransaction, Reset, UnlockConnector, ChangeAvailability, ChangeConfiguration, GetConfiguration, SetChargingProfile, UpdateFirmware, GetDiagnostics, TriggerMessage.
The session flow, frame by frame
charger platform
│ BootNotification ─────────────▶│ model, vendor, firmware
│◀──────────────── Accepted, interval
│ StatusNotification ───────────▶│ connector 1: Available
│ Heartbeat ────────────────────▶│ every N seconds
│
│ StatusNotification ───────────▶│ connector 1: Preparing
│ Authorize (idTag) ────────────▶│
│◀──────────────── Accepted │ or Blocked / Expired / Invalid
│ StartTransaction ─────────────▶│ meterStart, timestamp
│◀──────────────── transactionId │
│ StatusNotification ───────────▶│ connector 1: Charging
│ MeterValues ──────────────────▶│ every 30-60s: energy, power, SoC
│ StopTransaction ──────────────▶│ meterStop, reason
│ StatusNotification ───────────▶│ connector 1: AvailableAlmost every operational question reduces to "where in this sequence did it stop, and what was the last frame". A session that never reaches StartTransaction is an authorisation or payment problem. One that reaches Charging but has no MeterValues is a billing problem waiting to happen.
The configuration keys that cause disputes
| Key | Why it matters | Sensible value |
|---|---|---|
| HeartbeatInterval | Determines how fast you detect an outage | 60–300 seconds |
| MeterValueSampleInterval | How often energy is reported during a session | 30–60 seconds |
| MeterValuesSampledData | Which measurands are reported — must include energy | Energy.Active.Import.Register at minimum |
| StopTransactionOnEVSideDisconnect | Whether unplugging ends the session | true, in almost all cases |
| ConnectionTimeOut | How long the charger waits for a plug-in after authorisation | 60–120 seconds |
| LocalAuthorizeOffline | Whether the unit can authorise without the platform | true for depots and weak-signal sites |
| AuthorizeRemoteTxRequests | Whether a remote start still needs an Authorize | Depends on your flow — but know which you have set |
Reading a message log
When a driver disputes a session, the log answers it in four steps: find the Authorize and confirm it was accepted; find the StartTransaction and note meterStart; walk the MeterValues and confirm the energy progression is continuous; find the StopTransaction and check meterStop and the stop reason.
The stop reason is the most under-used field in the protocol. EVDisconnected, Remote, Local, PowerLoss, EmergencyStop and DeAuthorized tell you immediately whose action ended the session, which resolves most disputes without further investigation.
Common failure signatures
- Reconnect storms — the charger connects, disconnects and reconnects repeatedly. Usually a mismatched heartbeat expectation or an aggressive firewall idle timeout.
- Duplicate transaction ids after a reconnect — the charger replayed buffered transactions. Your platform must be idempotent about this or it bills twice.
- MeterValues that reset to zero mid-session — a charger restart. The energy calculation must handle a decreasing register.
- StatusNotification with vendorErrorCode but errorCode NoError — the vendor is signalling something outside the standard. Read the vendor field.
- Authorize accepted but StartTransaction never arrives — the driver walked away, or the connector never detected the plug.
What OCPP does not do
It does not handle payment, pricing, roaming, or driver identity beyond an opaque tag. Those are the platform’s responsibility. It also does not guarantee that a charger implements everything it claims — which is why the acceptance test matters more than the compliance statement.