The Open Charge Alliance published OCPP 2.1 in January 2025. It is an extension of 2.0.1, not a redesign: the OCA's stated aim is that application logic built for 2.0.1 keeps working in 2.1, and the new functionality comes through new use cases, new messages, and new optional fields on existing messages. Everything in parts 1 to 10 of this series still applies. OCPP 1.6 has different application logic and is not compatible with 2.1.
This article sticks to what 2.1 adds at the level of features and message names. For field-level detail, work from the official 2.1 specification and schemas; it is new enough that vendor implementations and certification are still catching up.
Connecting with 2.1
The WebSocket subprotocol is ocpp2.1. A station that supports both versions offers both, and a CSMS that only knows 2.0.1 picks ocpp2.0.1, so a 2.1 station can operate against a 2.0.1 CSMS without the new features.
GET /ocpp/CS-DEPOT-0042 HTTP/1.1
Host: csms.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Protocol: ocpp2.1, ocpp2.0.1
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: ocpp2.1The RPC framework gains two message types on top of CALL (2), CALLRESULT (3) and CALLERROR (4):
| MessageTypeId | Name | Purpose |
|---|---|---|
| 5 | CALLRESULTERROR | Reports that a received CALLRESULT could not be processed (for example it failed validation) |
| 6 | SEND | An unconfirmed message: no response is sent. Used for high-frequency data such as periodic event streams |
If you share a frame parser between 2.0.1 and 2.1 connections, make sure it rejects or ignores types 5 and 6 on 2.0.1 connections and does not expect a response to SEND frames on 2.1 connections.
Bidirectional charging and ISO 15118-20
OCPP 2.0.1 supports ISO 15118-2. OCPP 2.1 adds support for ISO 15118-20, including bidirectional power transfer, so a station can discharge an EV battery to the site or grid (V2X) under CSMS control. This is a new functional block (Q, Bidirectional Power Transfer) and it extends the smart charging model so that schedules can describe discharge as well as charge. A new NotifyAllowedEnergyTransfer message communicates which energy transfer modes are allowed for a session.
Related smart charging additions include dynamic schedules that can be updated during a session (UpdateDynamicSchedule, PullDynamicScheduleUpdate), priority charging (UsePriorityCharging, NotifyPriorityCharging), and an AFRRSignal message for automatic frequency restoration reserve signals in grid-balancing use cases. For the bigger picture of V2G and where it actually stands, see V2G and bidirectional charging.
DER control
A second new functional block (R) covers distributed energy resource control. A bidirectional charger feeding power back is a DER and has to follow local grid codes: voltage and frequency ride-through, volt-var and similar curves, and responses to grid conditions. 2.1 lets the CSMS configure these controls on the station and lets the station report alarms and status.
| Message | Direction | Purpose |
|---|---|---|
SetDERControl | CSMS to station | Set a DER control setting or curve |
GetDERControl / ReportDERControl | CSMS to station / station to CSMS | Request and report configured controls |
ClearDERControl | CSMS to station | Remove controls |
NotifyDERAlarm | Station to CSMS | Report a DER alarm condition |
NotifyDERStartStop | Station to CSMS | Report that a DER control started or stopped being applied |
Tariffs and local cost calculation
In 2.0.1 the CSMS calculates cost and the station only displays it (part 9). 2.1 adds structured tariffs that the station can use to calculate cost itself, which matters for accurate prices while offline and for running-cost display without a round trip per update. The tariff structure is aligned with the tariff concepts used in roaming protocols such as OCPI (OCPI tariffs), which makes mapping a roaming tariff onto a station less lossy.
New messages include SetDefaultTariff, GetTariffs, ClearTariffs and ChangeTransactionTariff. Transactions can also be bounded by limits on cost, energy or time, which supports the prepaid and ad hoc payment cases below.
Payments and new authorization options
- Ad hoc payment with a payment terminal, either built into the station or a stand-alone terminal serving several stations.
NotifySettlementreports the payment settlement (reference, amount, time) to the CSMS. - Prepaid cards, where the transaction cost cannot exceed the card's balance.
- Dynamic QR codes for secure ad hoc payment via a web page;
NotifyWebPaymentStartedis part of this flow. - VAT number validation (
VatNumberValidation) for business invoicing.
Ad hoc card payment was previously handled with vendor-specific integrations and DataTransfer on top of OCPP. Standard messages for it make payment terminals much easier to support across hardware vendors. Background on why this matters is in EV charging payment options and NEVI and AFIR requirements.
Other additions
- Resuming transactions after a forced reboot or reset, instead of always ending them.
- Battery swapping for swap stations (two- and three-wheelers as well as cars), with
BatterySwapandRequestBatterySwap. - Periodic event streams (
OpenPeriodicEventStream,NotifyPeriodicEventStream,AdjustPeriodicEventStream,GetPeriodicEventStream,ClosePeriodicEventStream) for streaming monitored values efficiently, using the new SEND frame. - Certificate handling additions such as
GetCertificateChainStatus. - Improvements from community feedback across existing use cases.
Should you implement 2.1 now?
For a CSMS, 2.1 is mostly additive work on top of a solid 2.0.1 implementation. If your 2.0.1 support is still immature, finish that first; everything in 2.1 depends on it. Then prioritise by business need: payment terminals and local cost calculation are relevant to most public networks, while bidirectional charging and DER control only matter where you have V2X-capable hardware, vehicles and a grid arrangement that pays for it.
For charger firmware, the same logic applies in reverse: 2.1 support is a differentiator only if the hardware can actually do bidirectional power, has a payment terminal, or targets markets that need these features. Supporting both ocpp2.1 and ocpp2.0.1 at the handshake keeps the station usable with every 2.0.1 CSMS in the meantime.
Key takeaways
- OCPP 2.1 (January 2025) extends 2.0.1; 2.0.1 application logic is intended to carry over unchanged.
- Subprotocol
ocpp2.1, plus two new RPC frame types: CALLRESULTERROR (5) and SEND (6). - Headline additions: ISO 15118-20 and bidirectional power transfer, DER control, local cost calculation, payment terminals and prepaid, battery swapping.
- Verify field-level details against the official specification; ecosystem support is still maturing.
That completes the series. Start again from part 1, or see how HashTech approaches charging platforms on our EV charging page.
