Subscribe & get the latest news in your email
By
Joachim Lohse
August 1, 2026
An operator buys chargers from three vendors, because procurement found a better price on the second tranche and a third supplier could deliver faster. All three are OCPP 1.6J certified. On paper, the depot is standardized.
Then the details start to surface. MeterValues arrive at different intervals with different measurand sets. One vendor resets the transaction ID after a reboot, so sessions get double-counted. Load management that works perfectly on vendor A silently under-delivers on vendor B. Nobody notices until a truck leaves the yard at 40% state of charge and the dispatcher has to re-plan the route mid-shift.
This is not a story about bad hardware. It is a story about the gap between conformance and interoperability. A certificate says a charger can complete a defined set of message exchanges in a lab. It does not say the charger will behave the same way as the unit parked next to it, under real load, on a congested network, with three charging profiles stacked on top of each other.
This article is a field guide to where OCPP leaves room for interpretation, what breaks as a result, and how to test for it during commissioning instead of discovering it in production.
Third-party certification validates a snapshot: a specific firmware build, against a specific test suite, in a controlled environment. Three things limit how much that snapshot is worth in the field.
Optional features stay optional. Large parts of OCPP are conditional. A charger can be fully certified while implementing only a subset of smart charging functionality. Certification tells you the implemented parts work. It does not tell you which parts exist.
Firmware moves faster than audits. By the time a unit is installed, it has usually shipped several firmware revisions past the version that was certified. Regressions in smart charging behavior are common and rarely documented in release notes.
Compliance is a two-sided problem. The backend can be just as loose with the spec as the charger. When both sides are approximately compliant in different directions, troubleshooting becomes an argument rather than a diagnosis. If you are still building your baseline understanding of the protocol, our guide to setting up and troubleshooting OCPP chargers covers the fundamentals this article builds on.
One correction to a common assumption: Chinese manufacturers are not systematically worse than European or North American ones. Across our own testing, incomplete smart charging implementations show up at every price point and in every region, including from well-known Tier 1 OEMs.
These are the failure modes we see most often in multi-vendor depots. Handling them is the job of your OCPP-compliant charging software and the OCPP server underneath it — not something you can fix in procurement alone.
The most frequent gap. Many chargers implement TxProfile and TxDefaultProfile but not ChargingStationMaxProfile (or ChargePointMaxProfile in 1.6). Session-level limits work; site-level limits do not. As a rough rule of thumb, expect roughly half of the smart charging surface to be missing on any given unit until you have proven otherwise.
OCPP defines how profiles at different stack levels combine and which one wins. Firmware frequently gets this wrong: it applies the most recently received profile instead of the highest-priority one, ignores stack levels entirely, or drops a lower-level profile when a higher one expires. In a depot running a baseline site limit plus dynamic per-session limits, this is the difference between a controlled ramp and a breaker trip.
The failure mode that costs the most time. A CSMS sends SetChargingProfile. The charger replies Accepted. The internal controller then ignores the limit, rounds the setpoint to arbitrary steps, or fails to apply it because the value was expressed in watts rather than amps. From the backend's point of view everything succeeded. From the transformer's point of view nothing did.
ChargingStationMaxProfile requires connectorId = 0 (or evseId = 0) to express a station-wide limit. Flawed firmware accepts the same profile on connectorId = 1 — and then applies the entire station limit to that single connector while leaving the others uncapped. The result is one throttled vehicle and an unbounded site load.
Sampled interval, aligned interval, and the configured measurand set vary by vendor and often reset after a firmware update. If your energy management logic assumes a 30-second Power.Active.Import sample and one vendor delivers 300-second Energy.Active.Import.Register only, your control loop is running on stale data and your billing records are inconsistent.
What happens when the WebSocket drops mid-session is where implementations diverge hardest. Some chargers resume the transaction with the same ID and buffered meter values. Some start a new transaction. Some reset the transaction counter after a reboot and collide with IDs already in the backend. Some resume charging at full power, discarding the profile that was active before the disconnect.
Vendors support different key sets, use different names for equivalent behavior, and return Accepted for keys they do not implement. Configuration you believe you have pushed to a fleet may exist on only part of it. Normalizing this is what our hardware configuration for OCPP chargers tooling exists to do — one configuration intent, translated per model and verified by read-back rather than trusted on the response code.
Outdated TLS versions, expired or self-signed certificates, and plaintext fallbacks are still common. In a multi-tenant hub, that means session and identification data can be captured on the local network. Security is rarely part of the interoperability conversation and should be.
OCPP 1.6J quality has improved measurably year over year. OCPP 2.0.1 has not caught up, and 2.1 raises the bar again.
Where 1.6 asked a charger to handle a modest message set, 2.0.1 introduces a hierarchical device model and well over 60 message types. OCPP 2.1 extends that further with bidirectional charging and V2X, dynamic tariff structures, and richer smart charging semantics. Every added abstraction is another place for firmware to diverge.
Expect a learning period comparable to the one 1.6J went through. Treat any OCPP 2.0.1 or 2.1 claim as a starting point for testing, not as a specification you can build a commissioning schedule around.
AFIR in Europe and NEVI in the United States both require open, smart-capable infrastructure with real-time data transparency, and both attach deadlines to it. The direction is right, and the industry is broadly moving with it. It also means a lot of protocol development is happening against fixed dates rather than on a schedule set by the engineering work.
Certification against a deadline is a narrower target than robustness across every deployment scenario. Conformance suites test defined message exchanges under controlled conditions. A depot with 40 trucks, a 1.2 MW grid connection, and setpoints that move every few minutes exercises paths those suites were never designed to reach. Firmware can satisfy the first and still surprise you in the second — not because anyone cut corners, but because the validation environment and the operating environment are genuinely different problems.
For a buyer the practical implication is the same either way: treat regulatory compliance and field reliability as two separate questions, and verify the second yourself.
Commissioning delays. The most common consequence. Software go-live slips while you wait on a vendor firmware fix, which can take days or weeks — and sometimes arrives with a new regression.
Features you paid for but cannot use. Load management and energy management depend on chargers actually honoring setpoints. If a unit does not react to commands, or follows a profile intermittently, peak shaving and depot scheduling degrade to static allocation. The economics of the site change with it.
Multi-week troubleshooting. Root cause is rarely obvious. Time goes into proving where the fault sits, then into convincing the responsible party that it is theirs. Both halves are slow.
Certifications and audits cannot solve this, because firmware and software versions change constantly. The durable fix is architectural: critical systems — EMS, energy management, payment — must be built on the assumption that OCPP will not be followed.
In practice that means the backend:
Two side effects follow. Sites stay stable in spite of imperfect hardware, and OEMs get concrete, reproducible evidence of where their firmware diverges, which is the only pressure that reliably moves the standard forward.
Detection has to be automatic, because the failure is invisible by design. Hardware diagnostics watches command-to-effect: profile sent, setpoint expected, power actually delivered, deviation flagged. Charger logging and audit preserves the full message trace, so when you open a ticket you send the OEM a timestamped exchange showing Accepted followed by no change in delivered power — not a description of a problem.
That distinction matters more than it sounds. Automated escalation with a reproducible log turns a three-week argument into a bug report.
Do this at commissioning, on every model and every firmware version, not on a sample.
Our charger commissioning support service runs this sequence as part of site acceptance, and the guide to commissioning and testing EV charging hubs walks through the wider process it sits inside.
La interoperabilidad es más barata de comprar que de depurar.
Ampcontrol ha probado más de 45 marcas de cargadores y cerca de 100 modelos. Dos conclusiones se mantienen constantes.
La calidad de OCPP 1.6J mejora genuinamente año tras año. La compatibilidad con la carga inteligente es más amplia y fiable que hace tres años, y las brechas más críticas se han reducido.
OCPP 2.0.1 se encuentra donde estaba 1.6J hace varios años para la mayoría de los fabricantes, y 2.1 extenderá esa curva. Planifique un periodo de aprendizaje.
La conclusión práctica no ha cambiado. "Compatible con OCPP" es el punto de partida de una conversación, no una garantía de interoperabilidad. Realice pruebas durante la puesta en marcha, exija SLA basados en el comportamiento y utilice un backend que asuma que el protocolo puede fallar y mantenga el sitio operativo de todos modos.
¿Está planificando un depósito con múltiples proveedores o depurando uno que no ofrece la gestión de carga que especificó? Hable con el equipo de Ampcontrol.
Ampcontrol es un software basado en la nube que se conecta sin problemas a redes de carga, vehículos, sistemas de flota y otros sistemas de software. No se necesita hardware, solo una integración única.
