OCPP error codes
OCPP 1.6 defines 16 values for the errorCode field of StatusNotification. Fifteen describe faults; one says everything is fine.
An OCPP error code arrives in the errorCode field of a StatusNotification. It is a fixed enum — a charger may not invent values — which is what makes fleet-wide fault reporting possible at all.
The set is deliberately small, and that is its main limitation. Sixteen codes cannot describe every way a charger fails, so manufacturers put the real detail in vendorErrorCode, a free-text field alongside it. Read both. The standard code tells you the category; the vendor code tells you what actually happened.
| Error code | Meaning | Usual cause | Typical response |
|---|---|---|---|
NoError | No fault. Sent with normal status changes. | Normal operation. Sent alongside ordinary status changes. | None |
ConnectorLockFailure | Failure to lock or unlock the connector. | Mechanical latch jammed, debris in the socket, or a failed lock actuator. | Site visit |
EVCommunicationError | Communication with the vehicle failed. Often a Control Pilot problem. | Control Pilot signalling failed. Often the vehicle or the cable, not the charger. | Retry, then site visit |
GroundFailure | Ground fault circuit interrupter tripped. | The residual-current device tripped. Treated as a safety fault. | Site visit |
HighTemperature | Internal temperature too high. | Ambient heat, blocked ventilation, or sustained high-current delivery. | Often self-clears |
InternalError | Fault in an internal hardware or software component. | A hardware or software component failed. The vendor error code is where the detail is. | Remote reset, then site visit |
LocalListConflict | Local authorization list version conflict during an update. | A SendLocalList update conflicted with the version the charger holds. | Remote fix |
OverCurrentFailure | Over-current protection tripped. | Over-current protection tripped, usually a vehicle or cable fault. | Often self-clears |
OverVoltage | Supply voltage above the permitted range. | Supply voltage above the permitted range. A grid-side problem. | Utility |
PowerMeterFailure | The power meter failed. | The energy meter stopped responding. Billing data from this point is suspect. | Site visit |
PowerSwitchFailure | The power switch or contactor failed. | The contactor failed to open or close. | Site visit |
ReaderFailure | The RFID reader failed. | The RFID reader failed. The charger may still work via remote start. | Site visit |
ResetFailure | A requested reset failed. | A requested reset did not complete. | Remote reset, then site visit |
UnderVoltage | Supply voltage below the permitted range. | Supply voltage below the permitted range. A grid-side problem. | Utility |
WeakSignal | Wireless communication signal too weak. | Cellular or Wi-Fi signal too weak to hold a connection reliably. | Site visit |
OtherError | A fault that none of the other codes describes. | A fault none of the other codes describes. Check vendorErrorCode. | Depends on vendor |
NoError is not the absence of a message
NoError is sent constantly, because every ordinary status change carries an errorCode and healthy transitions use this value. A monitoring pipeline that counts StatusNotification messages with an error code, without filtering NoError, will report a fault rate of essentially 100%.
Faults are reported on connector 0 when they affect the station
A fault in shared hardware — the meter, the modem, the main contactor — belongs on connectorId: 0, which refers to the charge point itself. A fault on a specific socket belongs on that connector. Chargers that report everything on connector 1 make it impossible to tell a dead socket from a dead station.
The error code does not clear itself
There is no 'error resolved' message. A fault is cleared by a subsequent StatusNotification carrying NoError, and if the charger never sends one, your dashboard shows the fault forever. When reconciling state after a reconnect, TriggerMessage with StatusNotification is how you ask for the current truth.
OCPP 2.0.1 has no error codes
This table is an OCPP 1.6 table, and there is no 2.0.1 equivalent. StatusNotification in 2.0.1 has no errorCode field at all — faults are reported through NotifyEvent, raised against a component and variable in the device model, with a severity from 0 to 9.
The result is more expressive and much less convenient: there is no fixed list of sixteen values to switch on, because what a station reports depends on its own device model. Any 1.6 fault handling being ported to 2.0.1 has to be rebuilt rather than mapped.
Vendor error codes
vendorErrorCode is free text, paired with vendorId to say whose namespace it belongs to. It is not standardised, not documented in OCPP, and frequently the only thing that identifies the actual failure. Collect it from day one — retrofitting it into a fleet's history is not possible.