OCPP 1.6J uses fourteen connector states in StatusNotification messages. OCPP 2.0.1 defines more than twenty, arranged in a two-level hierarchy: ConnectorStatus with an associated ChargingState beneath it. This is a structural change, not a minor revision. If your central system still parses 1.6 status strings while receiving 2.0.1 messages, silent misclassification can damage uptime reporting and fault detection.
Since late 2025, we have operated OCPP 2.0.1 connections beside 1.6J devices in our pilot network. The mixed-protocol issue is therefore practical, not theoretical. Here is what we review before moving an operator's hardware to 2.0.1, including failure modes we commonly find.
What Changes Between 1.6 and 2.0.1
The main structural shift replaces the flat StatusNotification status field with a two-level model. In OCPP 1.6, a connector sends one status such as "Preparing" or "SuspendedEV". In 2.0.1, ConnectorStatus values such as Available, Occupied, Reserved, Unavailable, and Faulted are paired with a TransactionEventRequest carrying detailed charging state. Your CSMS must process both streams and join them to identify the connector's actual state.
Smart charging is substantially broader. OCPP 1.6 introduced ChargingProfile with few ChargingSchedulePeriod entries. OCPP 2.0.1 adds ISO 15118-20 integration hooks, local controller profile stacking, allowing a site controller and cloud CSMS to send profiles while the charger arbitrates them, and dynamic profiles responding to real-time grid signals. Even if smart charging is not yet planned, your CSMS must receive and acknowledge these additions without errors.
Security profiles are now required in ways they were not in 1.6. OCPP 2.0.1 Security Profile 2 uses TLS with client-side certificate authentication and is expected by most compliant hardware. Some manufacturers provide Security Profile 1, basic authentication over TLS, by default for backward compatibility. Plan for the stricter profile during commissioning, and establish a process for certificate rotation and management.
CSMS Compatibility: A Common Migration Blocker
Before moving hardware, establish whether your central system management software fully supports OCPP 2.0.1 or only part of it. Many CSMS platforms advertise "OCPP 2.0.1 support" while covering only some message types, especially those for smart charging and device management.
Review this checklist with your CSMS vendor:
- Does it track the full TransactionEventRequest lifecycle (Started, Updated, Ended) and retain continuity through network interruptions?
- Does it correctly process charger-to-CSMS NotifyChargingLimitRequest messages?
- Does it support GetVariables and SetVariables, replacing deprecated OCPP 1.6 GetConfiguration and ChangeConfiguration?
- Does it handle RequestStopTransaction when a local stop races with an in-flight remote stop?
- Does it store and report the changed MeterValues format, using SampledValue objects with measurand enums?
If your CSMS vendor cannot confirm each item with a concrete answer, rather than "yes we support 2.0.1", consider the migration blocked. A CSMS that silently drops unknown message types may show no test error yet leave gaps in production session records.
Hardware Reality Check: Claimed vs Implemented Charger Features
Open Charge Alliance OCPP 2.0.1 certification does not assure full implementation. OCA tests cover a defined subset of functional blocks. A charger may be certified yet omit optional blocks such as SmartCharging or LocalAuthorizationList.
For each hardware model, verify these points before moving it to 2.0.1. First, determine whether the manufacturer's 2.0.1 firmware is a final release or beta. Several Indian-market vendors had 2.0.1 firmware in public beta as of early 2026, with known smart charging profile issues. Second, confirm the SecurityProfile supported during initial connection: some chargers claiming SP2 support silently fall back to SP1 when certificate validation fails. Third, test firmware updates. OCPP 2.0.1 adds UpdateFirmware with a signed firmware mechanism. A 2.0.1-format UpdateFirmwareRequest sent to a device whose handler only understands 1.6 can fail silently.
Mixed OCPP 1.6 and 2.0.1 Ops
Most operators will not move the full fleet at once. As hardware turns over, a mixed 1.6 and 2.0.1 network may persist for months or possibly years. This is a valid operating state, but your CSMS must keep separate state machines for each protocol version and report accurately across both.
In our pilot network, uptime reporting across protocol versions was the specific issue. A 1.6 charger reporting "Available" and a 2.0.1 charger reporting ConnectorStatus "Available" with no active ChargingState mean the same thing, though their raw messages differ. Correct normalization makes cross-fleet uptime reliable. Without it, phantom unavailability events or missing state transitions can distort fault detection rules.
Validate mixed-protocol reporting before launch. Run a controlled session on one 1.6 and one 2.0.1 device. Confirm that both appear identically in revenue and uptime reports, then inject a fault on each and verify that the monitoring layer raises the same alert.
Pre-Migration Checklist
Before moving a site to OCPP 2.0.1, complete these items in order. Skip none: each has caused a production issue for someone in our pilot network.
- Get vendor documentation confirming your CSMS supports the full TransactionEventRequest lifecycle, GetVariables, SetVariables, and the OCPP 2.0.1 MeterValues format, not verbal assurance.
- Verify each model has a manufacturer production release; never migrate on beta firmware.
- Test Security Profile (SP1 vs SP2) in staging, using the actual certificate chain intended for production, never in production.
- Validate SetChargingProfile handling in testing, even without current smart charging; a malformed response must not crash the CSMS message handler.
- Test a mixed-protocol session; verify uptime and revenue reports remain accurate and normalized across OCPP 1.6 and OCPP 2.0.1.
- Record the exact rollback firmware target before migration; confirm the manufacturer still provides OCPP 1.6 firmware.
The benefits of 2.0.1 are tangible: smarter charging, required security, and a clearer state model for more reliable fault detection. However, a poor migration disrupts more than staying on 1.6J for six more months. Plan the transition, test it on one site before rolling to your fleet, and treat the checklist above as a minimum, not a target.