INSIGHTS / UPTIME & OPERATIONS

EV Charger Fault Reporting: The Incident Data Operators Need Before a Reset

A vague report such as ‘the charger failed’ creates slow diagnosis and unnecessary site visits. Operators need a consistent incident record before logs roll over, equipment is reset or the same incomplete description passes between the driver, network, manufacturer and service team.

BUYER PAIN POINT

Operators lose diagnostic evidence when vague fault reports are followed by repeated resets before the exact code, OCPP context and session conditions are captured.

PROJECT RESPONSE

Use one incident brief across drivers, CSMS teams, charger suppliers and service personnel; preserve the exact data first, then follow the model-specific recovery and safety procedure.

Start with the operating context.

Capture the exact message before interpreting it: code source, full wording, timestamp and time zone, charger and connector identity, session or transaction ID, vehicle model and approximate state of charge, connector standard, authorization method, operating state and visible external condition. For OCPP 1.6, preserve StatusNotification status, errorCode, info, vendorId and vendorErrorCode when present. OCPP 2.0.1 uses component-oriented NotifyEvent data instead of the OCPP 1.6 errorCode field. Never merge these with a charger-screen code or vehicle DTC from another manufacturer.

Good commercial charging decisions connect vehicle use, site conditions and the operator's intended service. The selected equipment can then be reviewed against the final technical, commercial and destination-market requirements.

Planning checklist.

  • Immediate danger signs and whether the equipment must be isolated
  • Exact code system, message, timestamp, charger, connector and session identity
  • Vehicle, connector, authorization, network and environmental context
  • Responsible team, evidence package and model-specific service documentation

Use an evidence ladder instead of one vague description.

  1. Safety state: record smoke, fire, arcing, burning smell, abnormal heat, exposed conductors, collision damage or water ingress first. If any are present or uncertain, keep people away and escalate before collecting more data.
  2. Exact user-visible symptom: preserve the complete screen or app wording and language without converting it into a guessed OCPP category.
  3. Protocol evidence: for OCPP 1.6, retain status, errorCode and optional vendor fields. For OCPP 2.0.1, retain the event timestamp, component, variable, actual value, techCode and techInfo when implemented.
  4. Asset and session context: charger model, firmware, station/connector identity, timestamp and time zone, session reference, vehicle model/year, state of charge, connector standard and authorization method.
  5. Sequence and ownership: state what happened before and after the fault, which safe actions were attempted, whether it repeats, and which party owns the next evidence or service action.

Why regional or vendor codes need their own label.

Idaho National Laboratory's ChargeX work proposes Minimum Required Error Codes for the North American charging ecosystem. Its OCPP 1.6 examples place the CX... value in vendorErrorCode with an identified vendorId; OCPP 2.0.1 examples use techCode within event data. These proposed regional codes are useful context, but they are not an extra set of universal OCPP 1.6 errorCode values. Keep the field name, source and version attached to every code.

Sanitize the brief before it leaves the operator's system.

Use the minimum identifiers necessary for the authorized service team. Remove card numbers, security codes, passwords, access tokens, personal IDs and full VINs. Attach external-condition photographs and backend logs only when collection and sharing are safe, permitted and relevant. The browser tool does not transmit the form automatically; the operator decides whether and where to copy it.

How this applies to a commercial charging project.

Xiaochong provides a browser-based incident brief builder that keeps the report on the user’s device until it is copied. The company can also discuss EVSE analyzer configurations, English technical documentation, test guidance, OCPP integration, commissioning and maintenance support for selected projects. Root-cause diagnosis and repair remain model- and site-specific.

Images and portfolio references are a useful starting point, but final technical data, dimensions, protection rating, certification, payment integration and delivery terms should be confirmed for the selected model and destination market.

Common buyer questions.

Is an OCPP errorCode a complete diagnosis?

No. It is a standardized category in OCPP 1.6. Preserve related status, info, vendorId and vendorErrorCode plus the charger’s own logs. OCPP 2.0.1 uses NotifyEvent component data and must be interpreted separately.

Should an operator keep resetting a faulted charger?

No. Capture the evidence first and follow the manufacturer’s controlled recovery procedure. Ground, insulation, overcurrent, voltage, power-switch, heat, damage or water-related events require conservative isolation and qualified review rather than repeated resets.

What sensitive data should be removed?

Remove payment-card data, security codes, passwords, access tokens, personal identifiers and full vehicle VINs. Use only the minimum operational identifiers authorized for the service workflow.

Primary technical sources.

Rechecked September 12, 2026. Product-specific service procedures and local safety requirements still control the final action.

PROJECT REVIEW

Turn this planning guide into a project brief.

Send the country, site type, required power, connector, quantity and operating needs. Xiaochong Energy will help identify the relevant product and technical questions for your project.