OCPP 1.6 Error Codes: A Category Is Not a Diagnosis

What OCPP 1.6 actually reports.

Open Charge Alliance explains that OCPP 1.6 uses StatusNotification to report the charging station or connector state. The message carries a status and an errorCode, with optional free-format info and vendorErrorCode fields that can be vendor-specific. A standard category therefore narrows the reporting class; it does not prove one physical root cause.

The standard category set is: ConnectorLockFailure, EVCommunicationError, GroundFailure, HighTemperature, InternalError, LocalListConflict, NoError, OtherError, OverCurrentFailure, OverVoltage, PowerMeterFailure, PowerSwitchFailure, ReaderFailure, ResetFailure, UnderVoltage and WeakSignal.

Use five operational groups, while keeping the exact category.

• Electrical and supply: GroundFailure, OverCurrentFailure, OverVoltage and UnderVoltage. Stop repeated retries and assign qualified electrical or charger service.
• EV and connector interface: EVCommunicationError and ConnectorLockFailure. Capture vehicle, connector, session and external condition; the category alone does not identify which physical part failed.
• Charger hardware or thermal: HighTemperature, PowerMeterFailure and PowerSwitchFailure. Preserve measurements and vendor context; do not open an energized cabinet.
• Authorization, reset and network: LocalListConflict, ReaderFailure, ResetFailure and WeakSignal. Check the responsible data, reader, command and communication path without exposing credentials or payment-card data.
• Generic reporting: InternalError, OtherError and NoError. Retain the vendor fields and logs. NoError does not certify that the entire vehicle, charging chain or site is healthy.

Read status and errorCode together.

Available, Preparing, Charging, SuspendedEVSE, SuspendedEV, Finishing, Reserved, Unavailable and Faulted describe the reported state. Unavailable or Faulted may indicate downtime, but a connected WebSocket alone does not prove the complete charging application is functional.

OCA also notes a limitation: OCPP 1.6 does not represent multiple simultaneous errors cleanly or selectively clear one while another remains. Keep the chronological message history instead of treating the latest line as the complete incident.

Do not translate other code systems into OCPP 1.6 by appearance.

1. Charger screen or app: may show a manufacturer-specific code or customer message.
2. Vehicle warning or DTC: requires the exact make, model, year and market documentation.
3. vendorErrorCode: is a vendor field, not one of the 16 standard errorCode values.
4. OCPP 2.0.1: its StatusNotification no longer carries the OCPP 1.6 errorCode field; device-model event reporting such as NotifyEvent uses different evidence.
5. Regional error lists: may be carried in vendor or technical fields and must be identified by their own source and version.

NoError arrives. Can the support ticket be closed?

Not from that field alone. Consider an illustrative support ticket: a driver reports an interrupted session, and a later record contains NoError. Before closing it, the operator needs to establish whether the record belongs to the same station, connector and time period, and whether the reported operational state and actual session outcome support resolution. This example is a review workflow, not a prescribed sequence of valid protocol messages.

1. Preserve identity: keep station and connector references beside each event. Do not collapse different ports into one incident timeline.
2. Preserve sequence: retain timestamps, time zones and preceding unresolved events. Record uncertainty if clocks or event delivery differ.
3. Preserve meaning: standard category, manufacturer field and customer-facing message belong in separate fields.
4. Record closure ownership: identify who reviewed the evidence and the applicable equipment procedure. A green dashboard tile is not a safety inspection.

Our September 20 tool update removes the green result for NoError, gives explicit review guidance for faulted/unavailable or unknown state, and places possible danger ahead of all code interpretation. Recurrence means events already observed; users must not retry equipment to fill in the form. The tool receives no live equipment telemetry.

Review a reported category ↗ or prepare a sanitized incident brief ↗.

The label looks familiar. Which field did it come from?

Illustrative support example, not a customer case: a ticket quotes GroundFailure, and someone selects the matching OCPP 1.6 category. Later, an authorized reviewer finds that the quoted text was copied from a manufacturer field, not from StatusNotification.errorCode. The spelling alone cannot establish the standard category or the failed component.

1. Keep the original evidence: preserve the exact field path, original value, protocol version, timestamp and source record. Keep the real standard errorCode separately when it is present; never replace it with the manufacturer text.
2. Correct the source: for a vendorErrorCode value, choose Unknown in this reference and retain the field name in the incident brief. For a screen message, choose Charger screen or mobile app. Neither choice authorizes a standard-category interpretation.
3. Recalculate after correction: changing any input clears the old result. Submit again to get source-verification guidance; the previously selected category must not carry over as a diagnosis.
4. Escalate the evidence: ask the operator or manufacturer to interpret the exact model and firmware record. Do not create new faults, reset equipment or reconnect to obtain evidence.

For OCPP 2.0.1, choose its separate source option: its StatusNotification does not carry the OCPP 1.6 error field. This example is our evidence-handling workflow, not a universal mapping, an OCA-prescribed repair procedure or a statement that the quoted manufacturer value has a known meaning. Possible danger always takes priority, regardless of the selected source.

Check the source before the category ↗ · Prepare the evidence handoff ↗

One visible alert does not prove a first occurrence

A filtered dashboard can show one alert without establishing how often the problem has occurred. In this fictional example, a support handoff contains one InternalError record from a fifteen-minute view. Earlier records and the filter settings have not been checked. Choose Unknown for recurrence, not “No repeat observed”. The example is about the evidence available, not the cause or severity of that category.

Record the scope of the history reviewed

1. Identify the records: retain the station and connector identity, source system, original timestamps and time zone. Record the filter and time range rather than calling a screenshot the complete history.
2. Keep gaps visible: note unavailable earlier records, uncertain clock alignment or missing data. Ask the operator to review existing logs; do not create another session, reset equipment or reproduce the fault.
3. State a bounded finding: after review, “no repeat observed in the stated records and time range” is narrower than “first-ever fault”. If already observed events repeat, preserve each event and its identity rather than merging different connectors.
4. Keep code meaning separate: the standard category, vendor fields and observed session outcome remain separate evidence. A recurrence answer does not identify a failed part or establish that the equipment is safe.

OCA describes limitations in how OCPP 1.6 represents multiple errors and their clearing. Our history-scope worksheet is a support practice, not an OCA-mandated lookback period. The reference tool now starts recurrence at Unknown and includes the selected evidence scope in its checklist, including for NoError. It reads your selections, not the station logs.

Possible danger takes priority over this desk review. For smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the site operator and local emergency services. Do not approach equipment to fill gaps in a report. Electrical diagnosis belongs to qualified personnel; no force, protection bypass or energized cabinet work is authorized.

Review the category with recurrence left unknown ↗ · Prepare a sanitized evidence handoff ↗

Minimum evidence before escalation.

• Exact code and source, without paraphrasing
• OCPP version, status, errorCode, info, vendorId and vendorErrorCode when present
• Timestamp and time zone, station ID, connector ID and transaction or session reference
• Charger model, firmware, CSMS build and relevant event history
• Vehicle make/model/year, connector type, state of charge and external conditions
• Observed recurrence, reviewed time range and record coverage; leave uncertain history unknown

Do not include card numbers, security codes, passwords, access tokens, personal IDs or VINs in a shared support record.

Safety boundary.

For smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the operator and local emergency services. Do not approach unsafe equipment to collect evidence or operate it. Do not repeatedly reset protective trips, bypass protection or locks, change protection settings, open an energized cabinet or perform live electrical testing. Electrical diagnosis belongs to qualified personnel following the exact equipment documentation.

OtherError is confirmed. The vendor detail is missing.

Keep the confirmed standard category and the missing detail separate. A blank export cell is not evidence of NoError, a particular failed component or a code used by another manufacturer.

A fictional support export.

An authorized reviewer has verified an OCPP 1.6 StatusNotification.errorCode value of OtherError and the same record's Faulted status for an identified connector. The support export does not show info or vendorErrorCode. Earlier history has not been reviewed. These are illustrative observations, not a customer incident or a complete protocol message.

1. Preserve what is confirmed: retain the source record, station/connector reference, original timestamp and time zone, protocol version, exact field path, status and category.
2. Name the evidence gap: write “not visible in this export”. Do not claim “absent from the original message” until an authorized reviewer checks that message. A field omitted from an export, absent in a message or present with an empty value are different observations.
3. Assign the lookup: ask the operator or manufacturer to review the already available original record and applicable product documentation. Preserve the result as a sourced addition; do not invent a manufacturer code or infer a component from a similar-looking code.

Use the category without inventing a diagnosis.

For this fictional case, select confirmed OCPP 1.6 source, OtherError, Faulted and recurrence Unknown. Select no listed danger only if existing safe observations support that answer. The reference returns a vendor-specific evidence and ownership checklist; it does not decide what failed or permit a reset, retry or return to service.

If the category's source is also unverified, change source to Unknown: the source-confirmation gate replaces category interpretation. Unknown or present danger takes priority over both. Editing answers clears the previous result. The tool has no vendor-detail input or log parser and cannot distinguish a missing export column from an omitted protocol field; keep that distinction in the separate incident brief.

No new charging session, remote command, forced release, opened cabinet, energized test or protection bypass is requested. Electrical diagnosis belongs to qualified personnel. For smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the operator and local emergency services. Do not approach for evidence.

Source check — October 31, 2026: OCA, Improving Uptime Monitoring with OCPP v1.3, section 4.1.3 distinguishes status and errorCode from optional vendor-specific info and vendorErrorCode. The export worksheet above is our original support practice, not an OCA diagnostic procedure. Screen codes, vehicle DTCs and OCPP 2.0.1 techCode remain separate systems.

Review the confirmed category ↗ · Record the evidence gap ↗

A received Heartbeat is not a reported errorCode

A communication record and a connector fault report answer different questions. OCA separates WebSocket ping, OCPP message exchange through the heartbeat mechanism, and StatusNotification. A working WebSocket does not establish that the complete charging application works; OCPP message exchange gives more reassurance about that application. Neither observation supplies a missing StatusNotification.errorCode.

Keep an online label out of the category field

In this fictional desk-review example, an operator's export contains a recent Heartbeat and the dashboard labels the station online. The handoff contains no matching connector status or error record. A colleague has selected NoError in the reference form because the dashboard looks healthy. Correct that assumption before interpreting the result.

1. Preserve what was received: retain the message type, station identity, timestamp, time zone and export source. Keep “dashboard says online” as the dashboard's wording, not as a connector state or a standard error value.
2. Leave the category source unresolved: choose Unknown for the code source, reported operational state and recurrence. Here Unknown means the source of an error category is unconfirmed, even if the protocol version itself is known. The form's source gate withholds category interpretation, including when NoError remains selected.
3. Review existing records: ask the operator for the applicable connector's actual status/error record and its time context. If that evidence later confirms an OCPP 1.6 errorCode, select its exact value and reported state. Even a genuine NoError record is not a safety clearance or proof of a successful customer session.

The tool reads selections, not telemetry, and has no Heartbeat importer. Record the communication evidence separately in the incident brief. This example calls for no new session, reconnect, reset or remote trigger command. Do not invent missing messages, translate vendor fields or vehicle DTCs into standard categories, or merge different connectors' records.

Leave danger as unknown unless existing safe observations support a different answer; possible danger takes priority over source review. For smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress, keep people away and contact the operator and local emergency services. Do not approach to collect evidence. Electrical diagnosis belongs to qualified personnel; no energized work, forced release or protective bypass is authorized.

Check the source before interpreting a category ↗ · Keep communication evidence in a separate incident brief ↗

Use the OCPP 1.6 category reference.

Select the confirmed code source, standard category, reported state and recurrence. The browser tool produces a conservative explanation, ownership cue and evidence checklist; it is not a universal fault-code decoder or repair approval.

Open Tool 08 ↗

Primary sources.

OCA reference rechecked October 22, 2026: sections 4.1.1–4.1.3 distinguish communication checks from status and error reporting. The worked example is our evidence-handling practice, not an OCA-prescribed test. OSHA remains background from an earlier review. Exact charger, vehicle, CSMS and local safety requirements control final action.

• Open Charge Alliance — Improving Uptime Monitoring with OCPP v1.3 ↗
• OSHA 29 CFR 1910.334 — Use of equipment ↗