Tech OVN

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.

CapabilityOCPP 1.6JOCPP 2.0.1
Status in the marketDominant — most deployed backends speak itGrowing — newer backends and tenders
TransportJSON over WebSocketJSON over WebSocket
Built-in security profilesNo — relies on transport securityYes — defined security profiles
Certificate managementNot definedDefined, including updates
Smart chargingBasic charging profilesSubstantially extended
Device model / diagnosticsLimitedFull structured device model
Firmware update handlingBasicImproved and better defined
Transaction handlingSimpler, looserStricter and more explicit
Display and tariff messagingNot definedSupported
Backend availability todayVery wideNarrower but expanding
Migration pathNot 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

Specify chargers that support both, and run whichever your backend supports today. OCPP 1.6J remains the most widely supported version across charge point management systems, so it is usually what a site actually runs on day one. OCPP 2.0.1 adds security profiles, certificate management, a structured device model and much richer smart charging — it is where the market is heading, and increasingly what tenders ask for. Hardware that speaks both means the backend decision stays reversible.
No. They are different protocol versions and a 2.0.1 charger will not simply talk to a 1.6 backend, or vice versa, unless the charger implements both. This is the single most important practical point when specifying — it is a hardware capability question, not a configuration one.
It denotes the JSON-over-WebSocket transport, as opposed to the older SOAP variant. In practice OCPP 1.6J is what people mean when they say OCPP 1.6 today; the SOAP variant is effectively obsolete.
Not necessarily. OCPP 1.6J supports charging profiles, which is enough for common load management on a site — capping total current across a group of chargers so the incoming supply is not exceeded. OCPP 2.0.1 extends this considerably and is the better foundation if you are building sophisticated tariff-driven or grid-responsive charging.
Tech OVN AC chargers are standards-compliant on both OCPP 1.6J and OCPP 2.0.1, so they can be operated from your existing backend or from ours. Note that we support the standard as published — we do not build custom integrations to a specific CPO backend.
Yes, provided the charger genuinely implements the OCPP version your platform expects. That is the whole point of the standard. Ask any manufacturer which version they implement and whether it is the full profile or a subset — the second question is the one that catches people out.
OCPP connects a charger to its management system. OCPI connects charging networks to each other, so a driver with one operator's account can charge on another operator's hardware. They solve different problems and you may need both — OCPP as a hardware specification, OCPI as a commercial roaming one.

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.