When a charger won't start a session, drops offline, or reports a fault that doesn't make sense, the answer is almost always visible in the raw OCPP traffic between the charger and the CSMS - if you know what each message actually means. This is a reference to the OCPP messages that come up most often when diagnosing a real issue, not a full protocol specification.
Connectivity & lifecycle
| Message | Direction | What it tells you |
|---|---|---|
| BootNotification | Charger → CSMS | The charger has just powered on or reconnected and is announcing itself, including model and firmware version. Repeated BootNotifications without a clean shutdown in between usually means the charger is rebooting unexpectedly. |
| Heartbeat | Charger → CSMS | A periodic “still here” signal. Heartbeats stopping without a corresponding offline event is the first sign of a network-layer problem rather than a charger fault. |
| StatusNotification | Charger → CSMS | Reports a connector's current state - Available, Preparing, Charging, Faulted, and so on - and, when Faulted, an error code. This is usually the first message worth checking when a charger reports a problem. |
Charging sessions
| Message | Direction | What it tells you |
|---|---|---|
| Authorize | Charger → CSMS | The charger is checking whether a presented ID (RFID card, app-initiated session) is allowed to charge. A failed Authorize response, not a hardware fault, is the most common reason a session “won't start.” |
| StartTransaction / TransactionEvent | Charger → CSMS | OCPP 1.6 uses StartTransaction; 2.0.1 folds this into TransactionEvent. Marks the actual beginning of a charging session once authorization succeeds. |
| MeterValues | Charger → CSMS | Periodic energy and power readings during a session. Missing or flat MeterValues on a session that otherwise looks active often points to a metering fault rather than a connectivity issue. |
| StopTransaction / TransactionEvent (Ended) | Charger → CSMS | Marks the end of a session and reports the final meter reading used for billing. A session that never sends this can leave a driver's account showing an open, unbilled session. |
Remote operations
| Message | Direction | What it tells you |
|---|---|---|
| RemoteStartTransaction / RequestStartTransaction | CSMS → Charger | The platform is instructing the charger to begin a session - used for app-initiated starts. If this is sent but no StartTransaction follows, the charger accepted the command but failed to actually begin charging. |
| UnlockConnector | CSMS → Charger | A remote request to release the connector latch, most often used to resolve a driver stuck with a cable that won't disconnect. |
| Reset | CSMS → Charger | A remote soft or hard reboot of the charger, typically the first remote fix attempted before a truck roll for a charger stuck in a bad state. |
| ChangeConfiguration / SetVariables | CSMS → Charger | OCPP 1.6 uses ChangeConfiguration; 2.0.1 uses SetVariables. Updates a charger's local configuration remotely - useful for confirming a charger is actually running the settings the platform thinks it has. |
Diagnostics & firmware
| Message | Direction | What it tells you |
|---|---|---|
| FirmwareStatusNotification | Charger → CSMS | Reports progress of a remote firmware update - Downloading, Installing, Installed, or a failure state. Firmware stuck mid-update is a common cause of a charger that goes unresponsive after an update was pushed. |
| GetDiagnostics / diagnostics upload | CSMS → Charger | Requests the charger upload its local logs for deeper troubleshooting than the live message stream provides - the next step when message-level diagnosis doesn't explain the fault. |
| DataTransfer | Either direction | A vendor-specific extension message for functionality outside the standard spec. Seeing unexpected DataTransfer traffic usually means the charger vendor has a proprietary feature layered on top of standard OCPP. |
For the broader differences between protocol versions - including how message names changed from 1.6 to 2.0.1 - see OCPP 1.6 vs. OCPP 2.0.1. A CSMS worth running a business on should surface this level of detail directly in its operator console, rather than requiring raw log access to diagnose a charger issue - see how CarChargeOS handles fault detection and alerting on the platform page.
Frequently asked questions
Do OCPP 1.6 and 2.0.1 use the same message names?
Mostly not exactly - 2.0.1 consolidates several 1.6 messages (like StartTransaction and StopTransaction) into a unified TransactionEvent message, and renames some CSMS-to-charger messages (ChangeConfiguration becomes SetVariables, for example). The underlying concepts carry over even where the names changed.
What's the first message to check when a charger seems stuck?
StatusNotification, almost always - it reports the connector's current state and, if there's a fault, an error code that usually points directly at the problem before you need to look at anything else.
Why would a session show as active with no MeterValues coming in?
That combination typically points to a metering fault on the charger itself rather than a network or software issue - the session and connectivity are fine, but the charger isn't reporting energy delivered.