Multi-Vendor Charger Knowledgebase
Mixed fleets are the normal condition, not a failure of procurement. Tenders are won by different vendors, networks get acquired, and pilots become permanent. The operational problem is that a technician standing in front of an unfamiliar unit has no idea what its fault code means.
Why mixed fleets happen, what actually differs between vendors operationally, fault codes that mean different things to different manufacturers, building procedures a technician can follow, keeping it current, and what to standardise against what to accept.
Ask about mixed hardwareFor An operator running mixed hardware, usually after acquisitions or successive tenders that each chose differently.
Why mixed fleets happen
- Successive tenders, each won on price by a different vendor
- Acquisition of another network, complete with its hardware
- A pilot that became permanent because it worked
- A vendor leaving the market, or a product being discontinued
- Site hosts who specified their own equipment before the operator arrived
None of these is going to stop, so an operation designed on the assumption of one vendor is designed for a situation that will not persist.
What actually differs
Swipe to compare
| Area | How much it differs | Operational impact |
|---|---|---|
| OCPP messages | Moderately. Optional features, vendor extensions | Integration effort per vendor |
| Fault codes | Completely. No shared meaning | A technician cannot read an unfamiliar unit |
| Configuration keys | Completely | Every setting change is vendor specific |
| Firmware update process | Substantially | Separate procedure and risk profile each |
| Physical service access | Substantially | Different tools, different procedure, different hazards |
| Diagnostics available | Substantially | What can be resolved remotely varies by brand |
| Spares | Completely | Separate inventory per vendor |
The second row is the one that costs most day to day. Everything else can be looked up in advance; a fault code is encountered by somebody standing in a car park.
Fault codes have no shared meaning
OCPP defines a small set of standard error codes and every manufacturer extends them, so the same numeric code means unrelated things across two brands, and the same physical fault appears under different codes.
The practical consequence is that a technician who knows one brand deeply is close to useless in front of another, and confidence makes it worse rather than better. A mapping from each vendor's codes to a common internal vocabulary is the single highest-value thing a mixed-fleet operator can build, because it lets one procedure and one set of skills apply across the estate. Charger360 maintains that mapping across the brands it manages, and it is how we run mixed fleets ourselves.
Procedures a technician can actually follow
A knowledgebase that requires reading is a knowledgebase that gets ignored at three in the afternoon in a basement.
- 1
Per vendor, per model
Not per vendor. Models within a brand differ enough to matter, and assuming otherwise is how a technician gets a surprise.
- 2
Reachable from the unit
By QR or asset ID from a phone, in the field, with no signal assumption that will not hold in a basement.
- 3
Photographs as evidence
Where the isolator is, which fastener, what the indicator looks like. A photograph settles in a second what a paragraph does not.
- 4
Safety first, explicitly per model
Isolation points and hazards differ between brands and cannot be assumed from experience with another.
- 5
What not to attempt
Which is as important as what to do, and is usually missing.
Keeping it current
- Vendors change firmware, and behaviour with it. A procedure written against an old release can be wrong in an interesting way
- Discontinued models still need support long after the vendor stopped caring
- Technicians discover things that are not in any document, and there has to be a route for that to get in
- Record what a vendor's support is actually like, since it varies and it decides whether to escalate or to solve it yourself
The third one is the whole discipline. A knowledgebase that only receives content from the top is out of date within a year.
What to standardise, what to accept
Swipe to compare
| Standardise | Accept |
|---|---|
| Fault vocabulary across vendors | Vendor fault codes themselves |
| Ticket handling and escalation | Different firmware processes |
| Response and dispatch procedure | Different physical service access |
| Reporting and availability metrics | Different diagnostic depth |
| Safety procedure at a high level | Model-specific isolation points |
Standardise the operation. Accept the equipment. Attempting to force vendors into a common shape wastes effort that the mapping layer solves properly.
Want this applied to your own site?
Ask about mixed hardwareTechnically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
Should we standardise on one vendor?
It is a reasonable procurement goal and it will not survive contact with acquisitions, tenders and discontinued products. Design the operation for a mixed fleet regardless.
What is the highest-value thing to build?
A mapping from each vendor's fault codes to a common internal vocabulary. It lets one procedure and one set of skills apply across the estate.
Do OCPP fault codes not solve this?
No. OCPP defines a small standard set and every manufacturer extends it, so the same code means different things across brands and the same fault appears under different codes.
How detailed should procedures be?
Per model, not per vendor, and photograph-led. A technician in a basement will not read a paragraph, and models within a brand differ enough to cause surprises.
How do we keep it current?
By giving technicians a route to add what they discover. A knowledgebase that only receives content from the top is out of date within a year.
Running hardware your team does not know?
Tell us which brands and models. The fault code mapping is usually the first thing worth building.
Ask about mixed hardware