OCPP 2.0.1: What Actually Changed and Why It Matters

Why OCPP 2.0.1 is a bigger jump than you think

Most engineers encountering OCPP 2.0.1 for the first time assume it's an incremental patch on 1.6. It isn't. The device model was fundamentally redesigned, the message format changed, and several core concepts were renamed or restructured.

Here's what you actually need to know.

What this changes in rollout planning

The practical impact is not only "more features." OCPP 2.0.1 changes how rollout teams should evaluate chargers, backend abstractions, and coexistence strategy.

• Mixed fleets become a long-term operating model rather than a temporary migration phase.
• Capability discovery matters more because charger features are described with more precision but also more vendor variance.
• Transaction handling needs retesting because TransactionEvent replaces older assumptions around start/stop flows.
• Configuration governance gets harder because a richer model creates more opportunities for drift between charger, backend, and field expectations.

If a vendor says it "supports OCPP 2.0.1," the useful follow-up is not a protocol checkbox. It is whether your operations team can roll out, monitor, and troubleshoot a mixed 1.6/2.0.1 fleet without building a parallel exception process.

The new device model

OCPP 1.6 modelled a charger as a flat list of connectors. Simple, but too simple for modern multi-outlet, multi-EVSE hardware.

OCPP 2.0.1 introduces a three-layer hierarchy:

• Charging Station — the physical unit
• EVSE (Electric Vehicle Supply Equipment) — an outlet group
• Connector — the physical plug

This matters because modern chargers often have multiple EVSEs, each with multiple connector types (CCS, CHAdeMO, Type 2). The new model lets you address them precisely.

Message format changes

The JSON structure changed significantly. In 1.6, a BootNotification looks like:

[2, "19223201", "BootNotification", {
  "chargePointModel": "Optimus",
  "chargePointVendor": "VendorX"
}]

In 2.0.1:

[2, "19223201", "BootNotification", {
  "reason": "PowerUp",
  "chargingStation": {
    "model": "Optimus",
    "vendorName": "VendorX",
    "firmwareVersion": "1.0.0",
    "modem": { "iccid": "...", "imsi": "..." }
  }
}]

The envelope is the same (OCPP-J array), but the payload schema is different almost everywhere.

Smart charging improvements

OCPP 1.6's smart charging was notoriously incomplete. 2.0.1 adds:

• ISO 15118 Plug & Charge support — automatic authentication without RFID
• V2G hooks — vehicle-to-grid capability signalling
• Dynamic pricing signals — the CPMS can push tariff information to the charger

For fleet operators and utilities, these aren't nice-to-haves. V2G support alone changes the economics of a charging deployment.

Migration checklist

If you're migrating from 1.6 to 2.0.1:

1. Audit your connector model — map your physical hardware to the EVSE hierarchy
2. Update your message handlers — BootNotification, StatusNotification, TransactionEvent all changed
3. Test with a broker — don't connect directly to production until you've validated against a 2.0.1-compliant intermediary
4. Plan for 1.6 coexistence — most field hardware will stay on 1.6 for years

EV Cloud handles the 1.6 ↔ 2.0.1 translation automatically, so your CPMS can be 2.0.1-native even when your chargers are on older firmware.

Minimum proof before you accept a "2.0.1-ready" claim

Before a charger or backend is approved for rollout, ask for evidence against a bounded test plan:

1. Boot and inventory accuracy: confirm the charger exposes the expected station, EVSE, and connector structure.
2. Transaction consistency: validate start, update, suspend, resume, and stop events under unstable network conditions.
3. Smart charging behavior: prove setpoints are enforced, rejected cleanly, or downgraded predictably rather than silently ignored.
4. Configuration lifecycle: test reading, updating, and auditing key variables without manual site intervention.
5. Fallback and coexistence: run the same operational workflow across both 1.6 and 2.0.1 chargers and compare what breaks.

Teams that skip these checks usually discover protocol gaps only after commissioning, when the cost of rollback is much higher.

If 2.0.1 matters to your shortlist, evaluate migration with it

Protocol support alone is not enough. Buyers should look at how vendors handle coexistence, rollout sequencing, and charger-specific exceptions in the field.

Use the OCPP platform buyer guide and the best OCPP platforms for CPOs to score shortlists more rigorously. If migration is already in scope, continue with the legacy CSMS migration plan for CPOs.