If you operate any meaningful fleet of OCPP chargers, you’ve probably opened the door to a world of error codes that aren’t always clearly documented. Some are obvious. Some are vendor-specific. Some appear identical but mean different things on different chargers.
This article is a practitioner’s reference: the OCPP errors you actually see in production, what they mean, and how to handle each.
The two error layers
OCPP has two distinct error layers worth distinguishing.
Charger-level errors reported via StatusNotification’s errorCode field. These describe physical conditions of the charger — connector lock failed, over-current, ground fault, etc.
Protocol-level errors reported via the OCPP CallError envelope (message type 4 in the JSON RPC array). These describe what went wrong with handling a specific OCPP message — message format invalid, action not implemented, etc.
A given problem typically appears at one layer, not both. A failed StartTransaction might be a CallError (the charger didn’t accept the request) or a follow-up StatusNotification with errorCode (the charger started but immediately faulted). If you’re new to how these messages fit together, what OCPP is and how it works sets the context.
flowchart TD
P[OCPP message] --> Q{Problem type}
Q -->|Physical fault| C[StatusNotification<br/>errorCode field]
Q -->|Message handling| E[CallError envelope<br/>message type 4]
C --> C1[ConnectorLockFailure<br/>GroundFailure<br/>PowerMeterFailure]
E --> E1[NotImplemented<br/>FormationViolation<br/>SecurityError]
style C fill:#e8f5e9,stroke:#43a047
style E fill:#e3f2fd,stroke:#1e88e5Charger-level errors (StatusNotification errorCode)
The OCPP 1.6 standard enum:
- NoError — clears the error state. The charger is no longer reporting a fault.
- ConnectorLockFailure — the cable lock didn’t engage. Connector unsafe to use.
- EVCommunicationError — the charger can’t talk to the vehicle (ISO 15118 communication failed, pilot pin issue, etc.).
- GroundFailure — ground fault detected. Safety system tripped.
- HighTemperature — charger or internal component is too hot.
- InternalError — generic fault, often vendor-specific.
- LocalListConflict — conflict in the local authorization list.
- OtherError — vendor-specific or unclassified.
- OverCurrentFailure — too much current drawn; safety tripped.
- PowerMeterFailure — meter is not reporting correctly.
- PowerSwitchFailure — internal switch or contactor failed.
- ReaderFailure — the RFID reader is not working.
- ResetFailure — a reset command failed.
- UnderVoltage — input voltage too low.
- OverVoltage — input voltage too high.
- WeakSignal — cellular/wifi signal too weak (rarely used).
OCPP 2.0.1 has more granular error reporting through the device model and NotifyEvent messages. The codes are similar in spirit but better organized. This is one of several areas where OCPP 2.0.1 differs from 1.6.
What each common error actually means
ConnectorLockFailure
The cable lock didn’t engage when a vehicle plugged in (or didn’t disengage when the user tried to unplug). Mechanical issue with the connector lock mechanism.
Common causes:
- Worn or damaged lock motor.
- Debris in the connector.
- Cable not fully inserted.
- Lock mechanism stuck due to temperature or moisture.
Resolution:
- User can sometimes resolve by reseating the cable.
- Persistent issue requires technician visit to inspect / replace the lock motor.
- A charger frequently reporting this needs maintenance.
GroundFailure
Safety system detected current leaking to ground. Could be:
- Damaged charger internal wiring.
- Wet conditions affecting insulation.
- Faulty vehicle.
- Damaged cable.
Resolution:
- Charger goes offline for safety; will not allow further sessions until cleared.
- Often requires inspection.
- Recurring ground faults at one charger indicate a real issue.
HighTemperature
A component is too hot. Often the power module or the connector itself.
Common causes:
- Sustained high-power charging in hot ambient.
- Insufficient cooling.
- Sensor drift.
Resolution:
- Charger throttles or pauses until temperature drops.
- Usually self-resolves.
- Frequent high-temp events indicate a cooling issue.
InternalError
Generic. Could be anything. Vendor documentation needed.
Common causes:
- Firmware bug.
- Memory or storage issue on the charger.
- Software state inconsistency.
Resolution:
- Try a reset.
- Check firmware version; update if available.
- If recurring, escalate to OEM support.
OverCurrentFailure
Charging tried to deliver more current than the safety system allows.
Common causes:
- Vehicle requested more than the charger can provide (negotiation bug).
- Sensor drift causing false trip.
- Real fault — short or partial short in cable.
Resolution:
- Charger shuts down until cleared.
- Investigate cable; check vehicle behavior.
- Recurring across many cars suggests charger sensor issue.
PowerMeterFailure
The energy meter isn’t reporting. Critical — without meter values, you can’t bill the session correctly.
Common causes:
- Meter hardware failure.
- Communication failure between charger controller and meter.
- Calibration drift.
Resolution:
- Charger should refuse to allow sessions until meter is operational.
- Technician visit usually required.
EVCommunicationError
Charger can’t communicate with the vehicle via ISO 15118 or pilot-pin signaling.
Common causes:
- Vehicle hardware issue.
- Cable issue.
- ISO 15118 PLC interference.
- Vehicle and charger speaking incompatible protocol versions.
Resolution:
- Session won’t start or stops mid-session.
- User can sometimes try a different charger to isolate vehicle vs charger.
- Persistent issue on one charger across many vehicles suggests charger problem.
Protocol-level errors (CallError envelope)
The standard OCPP error codes:
- NotImplemented — the receiver doesn’t support this action.
- NotSupported — the action is supported but not in this context.
- InternalError — generic server-side error.
- ProtocolError — message format is wrong.
- SecurityError — security check failed (auth, signature, etc.).
- FormationViolation — message structure violates the spec.
- PropertyConstraintViolation — a field violates its constraints.
- OccurrenceConstraintViolation — required field is missing.
- TypeConstraintViolation — a field has the wrong type.
- GenericError — fallback.
NotImplemented
The receiver doesn’t have a handler for this message.
Common causes:
- CSMS uses a new feature the charger doesn’t support.
- OCPP version mismatch — CSMS speaks 2.0.1; charger registered as 2.0.1 but actually only supports a subset.
- Vendor-specific actions sent to a different vendor’s charger.
Resolution:
- Detect at the CSMS — don’t send features the charger doesn’t have.
- Charger capability discovery should inform this.
InternalError (protocol-level)
Receiver had an error processing the message.
Common causes:
- Bug in CSMS or charger firmware.
- Database error on the CSMS side.
- Resource exhaustion.
Resolution:
- Retry usually safe.
- Persistent InternalError on a specific message type indicates a bug.
FormationViolation
The message doesn’t conform to the OCPP JSON structure.
Common causes:
- Malformed JSON.
- Missing required fields.
- Wrong array structure (OCPP messages are arrays).
Resolution:
- Bug fix on the sender. Catch in your schema validation.
SecurityError
Authentication or security check failed.
Common causes:
- Wrong credentials (Profile 2 Basic Auth).
- Certificate validation failed (Profile 3 mTLS).
- Token expired or revoked.
Resolution:
- Rotate credentials.
- Renew certificates.
- Check trust roots.
Diagnostic patterns
A few patterns for troubleshooting OCPP errors in production.
Pattern: Charger going offline frequently
Investigate:
- BootNotification (coming soon) frequency — is the charger rebooting?
- Heartbeat (coming soon) — is the charger sending them on the interval?
- StatusNotification errorCode — any reported faults?
- Network connectivity — is the WebSocket flapping?
Common conclusions:
- Cellular signal issue (look at iccid/imsi behavior).
- Watchdog reset (firmware instability).
- Power supply problem (intermittent voltage).
Pattern: Session won’t start
Investigate:
- Authorize message — did it succeed?
- StartTransaction message — did it get sent? Did CSMS respond?
- StatusNotification — what state is the connector in?
- Any errorCode reported?
Common conclusions:
- Authorization rejected by eMSP.
- Connector in Faulted state.
- Charger in maintenance mode.
Pattern: Session ended unexpectedly
Investigate:
- StopTransaction reason field.
- StatusNotification just before/after.
- MeterValues sequence.
Common conclusions:
- EmergencyStop pressed.
- EVDisconnected (user unplugged).
- Charger faulted (StatusNotification with errorCode).
- DeAuthorized (auth expired).
Pattern: Meter values look wrong
Investigate:
- PowerMeterFailure errorCode (most direct indicator).
- Unit consistency in MeterValues (Wh vs kWh, A vs W).
- Start/Stop meter readings vs sum of periodic samples.
Common conclusions:
- Meter hardware issue.
- Implementation bug in unit handling.
- Reading-context interpretation issue.
Best practices for handling errors
A short list for CSMS implementers.
Categorize errors. Some are user-facing (“session failed”). Some are operational (“charger offline”). Some are bugs (“we sent a bad message”). Different handling.
Don’t silently swallow errors. Log everything. Surface to operations dashboards.
Distinguish transient from persistent. A transient error (one-off InternalError) shouldn’t trigger an alert. A persistent error (10 in a row) should.
Correlate. Errors on charger X at time T may correlate with similar errors on chargers Y and Z at the same time — indicating a CSMS or shared-infrastructure issue, not a charger issue.
Charger-specific knowledge base. Each OEM has its own quirks and vendor-specific error codes. Maintain a doc per OEM with known issues and resolutions.
Customer-facing translation. Don’t show users “ConnectorLockFailure”; show them “There was a problem with the cable. Try reseating it.” Translate technical errors to actionable advice.
The honest summary
OCPP errors come from two layers (charger-level via StatusNotification, protocol-level via CallError) and from many sources (real hardware issues, network problems, firmware bugs, configuration mistakes). Effective troubleshooting requires distinguishing the layers, knowing the common causes, and having operational visibility. Most “the charger isn’t working” support tickets trace back to one of the handful of common errors discussed here; familiarity with them dramatically speeds resolution time.