Compare
OCPP 1.6J vs OCPP 2.0.1
One is what most backends run today. The other is where tenders are heading. The two are not compatible, which makes this a hardware decision rather than a settings decision.
The short answer
Buy hardware that speaks both, and run whichever your backend supports. OCPP 1.6J is still the most widely supported version across charge point management systems, so it is what most sites actually run on day one. OCPP 2.0.1 brings security profiles, certificate management, a structured device model and far richer smart charging.
Because the two are not backward compatible, a charger that implements only one version locks you to a class of backend for the life of the asset. Dual support keeps that decision reversible for the price of asking the question at procurement.
Side by side
What changes between versions, and what it means when specifying.
| Capability | OCPP 1.6J | OCPP 2.0.1 |
|---|---|---|
| Status in the market | Dominant — most deployed backends speak it | Growing — newer backends and tenders |
| Transport | JSON over WebSocket | JSON over WebSocket |
| Built-in security profiles | No — relies on transport security | Yes — defined security profiles |
| Certificate management | Not defined | Defined, including updates |
| Smart charging | Basic charging profiles | Substantially extended |
| Device model / diagnostics | Limited | Full structured device model |
| Firmware update handling | Basic | Improved and better defined |
| Transaction handling | Simpler, looser | Stricter and more explicit |
| Display and tariff messaging | Not defined | Supported |
| Backend availability today | Very wide | Narrower but expanding |
| Migration path | — | Not backward compatible with 1.6 |
Where each version earns its place
Specify 1.6J when the backend already exists
If the operator runs an established CPO platform, it almost certainly speaks 1.6J. Forcing 2.0.1 on a site whose backend does not support it creates an integration problem with no operational benefit.
Specify 2.0.1 when security is contractual
The defined security profiles and certificate handling are the substantive difference. If the site sits inside a corporate network with a security review, 2.0.1 answers questions that 1.6J leaves to the transport layer.
Specify 2.0.1 for sophisticated smart charging
Basic load capping works fine on 1.6J. Tariff-driven scheduling, grid-responsive charging and richer device management are where 2.0.1 pulls ahead.
Always ask whether it is the full profile
Compliance with a version is not binary in practice. Ask which messages are implemented, not just which version is claimed. A charger supporting a subset can still fail against a backend that uses the rest.
Where Tech OVN sits
Our AC chargers are standards-compliant on both OCPP 1.6J and OCPP 2.0.1, so the same hardware works against your existing backend or ours. You are not buying into a platform by buying the hardware.
One thing we are explicit about: we implement the published standard. We do not build bespoke integrations to a particular CPO backend. If your platform expects something outside the specification, that is worth establishing before a purchase order rather than after.
Frequently asked questions
Related
EV charging management system
OCPP backend, tariffs, sessions and site load management.
Learn More →Type 2 22 kW commercial charger
IP55 AC charger, OCPP 1.6J and 2.0.1, single or dual gun.
Learn More →EV charger controller (OEM)
Controller board for manufacturers, with OCPP and IEC 61851-1.
Learn More →AC vs DC charging
Which one a site actually needs, and when DC is unavoidable.
Learn More →Start an EV charging business
Dealer, mini CPO or full CPO — the three models compared.
Learn More →White-label EV chargers
OEM and ODM programmes with your branding.
Learn More →Specifying chargers for a site or a tender?
Tell us which backend you run and we'll confirm exactly what our chargers implement — before you raise the PO.
