The OCPP 2.0.1 and 2.1 protocol reference.
All 91 messages of OCPP 2.0.1 and 2.1 with their fields and an example, which ones 2.1 added, the device model that took over from the configuration keys of 1.6, and the three security profiles.
MessagesDevice modelSecurity profilesComing from 1.6Questions
What are OCPP 2.0.1 and 2.1?
They are the newer versions of the Open Charge Point Protocol, the open standard of the Open Charge Alliance for how a charger talks to the software that manages it: the CSMS in the specification, the back office in the market. As in 1.6J, the charger opens a WebSocket to the back office and both sides send JSON messages over it.
OCPP 2.0.1 is not backward compatible with 1.6. It describes a charger as a device model of components and variables, has three security profiles built in, reports a transaction in one message, TransactionEvent, and supports ISO 15118 for Plug and Charge and for smart charging with input from the car.
OCPP 2.1 builds on 2.0.1. Its schemas are the 2.0.1 schemas with optional fields added, and it adds 27 messages for bidirectional charging, DER control, tariffs on a charger that calculates the cost itself, payment at the charger, periodic event streams and battery swapping. A charger and its back office agree on one version when the WebSocket opens.
- An open standardFree to implement, maintained by the Open Charge Alliance. OCPP 2.1 is also published as IEC 63584-210.
- WebSocket and JSONOne connection the charger keeps open. 2.1 adds SEND, a message that gets no answer.
- 91 messages64 in 2.0.1 and 27 more in 2.1, in 19 functional blocks.
- Both directionsThe charger and the back office each start their own messages.
All 91 OCPP 2.0.1 and 2.1 messages
Every message is a request from one side and a response from the other, matched by a message ID. NotifyPeriodicEventStream is the one exception: a SEND message in 2.1 that gets no answer.
Security
Certificates for the charger and the back office, and the security events a charger reports.
Provisioning
Booting, registering with the back office, reading and setting the device model, and resets.
Authorization
Checking an ID token before charging, the authorization cache, and in 2.1 ad-hoc payment.
Local authorization list
The list of ID tokens the back office stores on the charger, so it can authorize on its own.
Transactions
One message, TransactionEvent, for the start, the updates and the end of every transaction.
Remote control
Starting and stopping a transaction from the back office, unlocking a connector and triggering a message.
Availability
The status of every connector, the heartbeat, and taking a charger or EVSE out of service.
Reservation
Reserving an EVSE for an ID token, and cancelling that reservation.
Tariff and cost
Prices and running cost for the driver; in 2.1 also tariffs on a charger that calculates the cost itself.
Meter values
Meter readings outside a transaction; during a transaction they travel in TransactionEvent.
Smart charging
Charging profiles with power or current limits, limits from outside, and the needs of the vehicle.
Firmware management
Updating firmware on a charger, and publishing it through a local controller.
Certificate management
Installing and checking certificates, including the contract certificates of Plug and Charge.
Diagnostics
Logs, monitors on the device model, events, customer data and, in 2.1, periodic event streams.
Display message
Messages the back office sets for a charger to show drivers.
Data transfer
Vendor data, for functions the standard does not cover.
Bidirectional power transfer
New in 2.1: control of charging and discharging (V2X) through charging profiles.
DER control
New in 2.1: grid support settings for a charger and car that act as a distributed energy resource.
Battery swapping
New in 2.1: battery swap stations.
No message matches that search.
The OCPP 2.0.1 device model
In OCPP 1.6 a charger has a flat list of configuration keys. In 2.0.1 and 2.1 it describes itself as components, such as the charging station, an EVSE, a connector or a controller like OCPPCommCtrlr, and every component has variables. A variable can hold four values: Actual, Target, MinSet and MaxSet. What used to be a configuration key is now a variable of a controller component.
How you work with it
- GetVariables and SetVariablesRead or set several variables in one message. The charger answers for each variable on its own.
- GetBaseReport and GetReportAsk for the whole device model or a part of it. The charger sends it back in NotifyReport messages.
- MonitorsSetVariableMonitoring watches a variable for a threshold, a change or a fixed interval, and the charger reports through NotifyEvent.
- Enabled, per functionThe controller of an optional function, such as AuthCacheCtrlr or ReservationCtrlr, has an Enabled variable that switches that function on or off.
The answers to SetVariables
- Accepted
- The value is set.
- Rejected
- The variable exists, but the value was refused.
- Unknown
Component - The charger has no such component.
- Unknown
Variable - The component has no such variable.
- NotSupported
AttributeType - The variable has no value of that type, for example no Target.
- RebootRequired
- The value is stored and takes effect after a restart.
Variables that took over from the best-known 1.6 keys
The specification standardizes many more, listed in its appendices. A charger reports the ones it has in answer to GetBaseReport.
| Component and variable | Type | What it sets | In OCPP 1.6 |
|---|---|---|---|
| OCPPCommCtrlr | integer in seconds | Seconds without other messages after which the charger sends a Heartbeat. | Heartbeat |
| OCPPCommCtrlr | integer | How often the charger tries to deliver a TransactionEvent the back office could not process. | Transaction |
| OCPPCommCtrlr | integer | Seconds the charger waits before it tries again. | Transaction |
| OCPPCommCtrlr | integer in seconds | Seconds between WebSocket pings; 0 switches the charger's own pings off. | Web |
| OCPPCommCtrlr | integer | How often the charger retries a reset that failed. | Reset |
| OCPPCommCtrlr | boolean | Unlock the cable at the charger when it is unplugged at the car. | Unlock |
| SampledDataCtrlr | list | What the charger measures during a transaction, sent in TransactionEvent with eventType Updated. | Meter |
| SampledDataCtrlr | integer in seconds | Seconds between those readings; 0 sends none during the transaction. | Meter |
| SampledDataCtrlr | list | What goes into the TransactionEvent that ends the transaction. | Stop |
| AlignedDataCtrlr | integer in seconds | Seconds between clock-aligned readings. | Clock |
| AlignedDataCtrlr | list | What the clock-aligned readings contain. | Meter |
| AlignedDataCtrlr | list | Clock-aligned readings that go into the TransactionEvent that ends the transaction. | Stop |
| TxCtrlr | integer in seconds | Seconds a driver has to plug in after the transaction started, before it is cancelled. | Connection |
| TxCtrlr | boolean | End the transaction when the cable is unplugged at the car. | Stop |
| TxCtrlr | boolean | Stop a running transaction when its ID token turns out not to be accepted. | Stop |
| TxCtrlr | integer | Energy in Wh the charger may still deliver after the back office rejected the ID token. | Max |
| TxCtrlr | list | When a transaction starts: on authorization, on plugging in, when energy flows, and so on. | New in 2.0.1 |
| TxCtrlr | list | When a transaction ends, chosen from the same list. | New in 2.0.1 |
| AuthCtrlr | boolean | Whether the charger checks the ID token of a remote start with an Authorize first. | Authorize |
| AuthCtrlr | boolean | Start transactions for ID tokens it already knows while offline. | Local |
| AuthCtrlr | boolean | Start for ID tokens it already knows without waiting for the back office. | Local |
| AuthCtrlr | boolean | Start transactions for unknown ID tokens while offline. | Allow |
| AuthCacheCtrlr | boolean | Use the authorization cache. | Authorization |
| LocalAuthListCtrlr | boolean | Use the local authorization list. | Local |
| LocalAuthListCtrlr | integer | Most ID tokens in one SendLocalList. | Send |
| SmartChargingCtrlr | integer | Highest stack level a charging profile may have. | Charge |
| SmartChargingCtrlr | list | Whether schedules can be in amps, in watts or both. | Charging |
| SmartChargingCtrlr | integer | Most periods in one charging schedule. | Charging |
| SmartChargingCtrlr | boolean | Whether the charger can switch from three phases to one during a transaction. | Connector |
| ReservationCtrlr | boolean | Whether a reservation can be for the charger as a whole rather than one EVSE. | Reserve |
No variable matches that search.
OCPP 2.0.1 and 2.1 security profiles
Both versions define three security profiles. A charger and its back office use one at a time, and it is set before the first OCPP message. The back office sets it per connection slot with SetNetworkProfile, and the charger reports the one in use in SecurityCtrlr.SecurityProfile.
| Profile | How the charger proves who it is | How the back office proves who it is | The connection |
|---|---|---|---|
| 1. Unsecured transport with basic authentication | HTTP Basic authentication, with a password | It does not | Not encrypted. Only for trusted networks, such as a VPN between the charger and the back office. |
| 2. TLS with basic authentication | HTTP Basic authentication, with a password | Its TLS server certificate | TLS 1.2 or higher |
| 3. TLS with client side certificates | Its own TLS client certificate | Its TLS server certificate | TLS 1.2 or higher |
- Stepping downA charger may only go from profile 3 to profile 2, and only when AllowSecurityProfileDowngrade is set to true. It never steps down to profile 1 through OCPP.
- Passwords and certificatesThe password is SecurityCtrlr.BasicAuthPassword. The charger asks for a new certificate with SignCertificate, and the back office delivers it with CertificateSigned.
- Security eventsThe charger reports what happened, such as a reset, a firmware update or credentials the back office rejected, with SecurityEventNotification.
From OCPP 1.6 to 2.0.1, message by message
OCPP 2.0.1 kept many 1.6 message names, and renamed or merged others. A link opens the message in this reference or in the 1.6J reference.
| OCPP 1.6 | OCPP 2.0.1 and 2.1 | What changed |
|---|---|---|
| StartTransaction, StopTransaction | TransactionEvent | One message with eventType Started, Updated or Ended. The charger sets the transaction ID, a string. |
| MeterValues | TransactionEvent, MeterValues | Readings during a transaction go in TransactionEvent; MeterValues carries readings outside one. |
| StatusNotification | StatusNotification, NotifyEvent | StatusNotification only reports the connector status, with evseId and connectorId. Error codes go in NotifyEvent, and 2.1 prefers NotifyEvent for availability too. |
| RemoteStartTransaction | RequestStartTransaction | Carries an idToken object and a remoteStartId, which comes back in the TransactionEvent that starts the transaction. |
| RemoteStopTransaction | RequestStopTransaction | Stops a transaction by its ID, which is now a string. |
| ChangeConfiguration | SetVariables | Sets several variables of the device model in one message. |
| GetConfiguration | GetVariables, GetBaseReport, GetReport | Reads chosen variables, or asks for a report that arrives in NotifyReport messages. |
| GetDiagnostics | GetLog | Asks for a diagnostics log or a security log. |
| DiagnosticsStatusNotification | LogStatusNotification | Reports the progress of that upload. |
| Reset | Reset | Immediate or OnIdle in place of Hard or Soft, and it can reset one EVSE. |
| ChangeAvailability | ChangeAvailability | Targets the charger, an EVSE or a connector through its evse field. |
| Authorize | Authorize | An idToken object with a type, in place of the idTag string. |
| BootNotification | BootNotification | Adds the reason for booting; the charger's details sit in a chargingStation object. |
| Heartbeat, UnlockConnector, ClearCache, DataTransfer, ReserveNow, CancelReservation, SendLocalList, GetLocalListVersion, SetChargingProfile, ClearChargingProfile, GetCompositeSchedule, TriggerMessage, UpdateFirmware, FirmwareStatusNotification | The same names | The same messages, with fields for EVSEs and the newer data types. |
Questions about OCPP 2.0.1 and 2.1
Version 2.0.1 of the Open Charge Point Protocol, published by the Open Charge Alliance in 2020. It replaced OCPP 2.0, and compared with 1.6 it adds the device model, security profiles, ISO 15118 support and TransactionEvent. It is not backward compatible with 1.6.
OCPP 2.1 was published in January 2025 and is also the standard IEC 63584-210. It adds 27 messages and removes none: bidirectional charging (V2X) and DER control, ISO 15118-20, tariffs on a charger that calculates the cost itself, payment at the charger with a card terminal or a QR code, priority charging, dynamic charging profiles, periodic event streams and battery swapping. Choose New in 2.1 above the messages to see them.
The 2.1 schemas are the 2.0.1 schemas with optional fields added, and according to the Open Charge Alliance, logic written for 2.0.1 keeps working with two small changes: SignCertificate can carry a requestId that CertificateSigned then repeats, and NotifyMonitoringReport has one new required field. The version is still agreed per connection: in the WebSocket handshake the charger offers, for example, ocpp2.1, ocpp2.0.1 and ocpp1.6, and the back office picks one.
2.0.1 has its own set of messages: a device model in place of configuration keys, security profiles, TransactionEvent in place of StartTransaction and StopTransaction, the EVSE as a level between the charger and its connectors, and messages for ISO 15118. A charger and its back office agree on one version when the connection opens. The table above pairs the messages, and the OCPP 1.6J reference has every 1.6 message.
After OCPP 2.0 came out, issues turned up that could only be fixed by changing the message schemas, which a 2.0 implementation could not follow. The Open Charge Alliance gave the fixed version its own number, 2.0.1, and advises implementing only 2.0.1. In the specification, OCPP 2.0 means 2.0.1 unless it says otherwise.
The Open Charge Alliance publishes both free of charge on its website, with a JSON schema for every message and an errata sheet. This reference follows the JSON schemas and part 2 of the specification. Where the two differ, the specification and its errata are right.
Look it up in the charger database: 102 chargers there list OCPP 2.0.1 and 4 list 2.1. The datasheet usually says it too. A charger that supports several versions offers them all when it connects, and the back office picks one.
OCPP 1.6J on Plugchoice
Plugchoice connects OCPP 1.6J chargers today, depending on model, firmware and configuration.