When something goes wrong on a charging station, it reports the problem to the CSMS via a StatusNotification message with an error code. Your CSMS needs to react correctly to each one — triggering alerts, pausing billing, flagging the station for maintenance. Testing this without a simulator means intentionally breaking real hardware.
How OCPP error codes work
A StatusNotification message carries a connector status (Available, Preparing, Charging, Faulted, etc.) and an optional error code. Error codes typically appear alongside a Faulted status, but some can accompany other states to signal non-blocking conditions — for example, a WeakSignal warning while the station is still charging.
OCPP 1.6 standard error codes
- ConnectorLockFailure — the connector lock mechanism failed to engage or disengage
- EVCommunicationError — the station cannot communicate with the EV (CP signal or ISO 15118)
- GroundFailure — a ground fault was detected on the output circuit
- HighTemperature — internal temperature exceeds the safe operating threshold
- InternalError — a software or hardware fault with no more specific code
- LocalListConflict — a local authorization list entry conflicts with a CSMS response
- NoError — no error condition (normal operating status)
- OtherError — a fault not covered by any specific error code; vendorErrorCode provides detail
- OverCurrentFailure — overcurrent detected on the output
- OverVoltage — output voltage exceeds the safe limit
- PowerMeterFailure — the power meter is not reporting or is reporting incorrect values
- PowerSwitchFailure — the main power switch (contactor) failed to operate
- ReaderFailure — the RFID or NFC reader is not functioning
- ResetFailure — the station failed to reset when commanded
- UnderVoltage — input voltage is below the minimum required level
- WeakSignal — the cellular or Wi-Fi signal strength is insufficient for reliable operation
Manufacturers extend this with custom fault details using the vendorErrorCode field.
What your CSMS must do with each
Different error codes call for different CSMS responses. A HighTemperature fault should trigger an immediate alert to the site operator and suspend new sessions. WeakSignal may log a monitoring entry without halting billing. PowerMeterFailure likely requires flagging the active transaction for manual review. ReaderFailure means no new RFID sessions can be started until the hardware is repaired.
Getting this logic right — and keeping it correct across CSMS releases — requires testing each error code deliberately, including the transitions in and out of Faulted status.
Fault injection with a simulator
SimIt lets you set any connector to any error state via a REST API call. Put a connector into Faulted with HighTemperature, verify your CSMS triggers the right alert, reset the fault, and confirm the connector returns to Available. Script this in a CI pipeline to catch regressions in your error handling logic automatically.
Start fault injection testing free with SimIt.