A charger reports GroundFailure. Another reports OtherError with vendorErrorCode "E-114". A third reports NoError while sitting in Faulted state, which the specification does not forbid and several vendors do anyway. All three units are on the same network, and your operations team has to decide which one needs a van.
OCPP 1.6 defines a small closed set of error codes and an open vendor field beside it. The closed set is too coarse to act on and the open field is undocumented. This is the single largest source of wasted field visits on a mixed fleet, and it is fixable with a week of work.
Build a fault dictionary, per vendor
The work is unglamorous: for each hardware model you run, record every vendorErrorCode you have observed, what the unit was actually doing at the time, and what resolved it. After a few months you have something no datasheet gives you — a mapping from the code the charger emits to the action a technician should take.
| Observed | Vendor code | Actually means | Action |
|---|---|---|---|
| Faulted | E-114 | Contactor did not close | Remote reset, then dispatch if it repeats |
| Faulted | GFCI-2 | Residual current trip | Never clear remotely — dispatch |
| Unavailable | (none) | Set unavailable by an operator | Check who, and why |
| Available | TEMP-HI | Derating due to enclosure heat | Check ventilation and shade at the site |
The fourth row is the interesting one. A unit reporting Available while quietly derating is not a fault by any definition the protocol offers, but it is a revenue problem, and the only way to see it is to be reading the vendor field.
Three classes, not nine codes
For dispatch purposes the taxonomy that matters has three entries, and every vendor code should map to exactly one of them.
- 01Self-clearing. Transient, resolves on its own or on a reset. Log it, watch the rate, do nothing else unless it repeats.
- 02Remotely recoverable. Needs a reset, an availability change or a configuration correction, but no human at the site.
- 03Requires a person. Electrical protection, physical damage, connector faults. These must never be cleared remotely, because clearing them re-energises equipment that tripped for a reason.
Measure the dictionary, not just the faults
Once codes are classified, the useful metric stops being fault count and becomes the share of faults resolved without a dispatch. That number is directly controllable, it improves as the dictionary fills out, and it is the one operations metric that translates straight into cost.
Track the unmapped codes too. An unrecognised vendorErrorCode arriving for the first time is either a new failure mode or a firmware change nobody told you about. Both are worth an email to the vendor while the evidence is fresh.