Which OCPP version am I dealing with?
Flowion speaks OCPP 1.6J, 2.0.1 and 2.1. See how a charger's version is chosen, what each adds, and why your integration stays the same.
On this page
Three OCPP versions are in the field, and Flowion speaks all three. The charger decides which one it offers: it is the client, and its firmware lists the versions it supports. Flowion meets it on the newest one they share.
The versions are not small increments. They are different protocols with overlapping vocabulary, which is exactly why Flowion keeps them away from your code.
The three versions
OCPP 1.6 is the workhorse. Most chargers in service speak it, and most sold today still do. It is flat, simple and widely interoperable: no EVSE tier, three separate messages per transaction, a bare string for a card.
OCPP 2.0.1 is a redesign. It adds the EVSE tier, one TransactionEvent message for the whole session, typed id tokens, display messages, and a device model that lets the CSMS discover what a station can do instead of guessing. (There was a 2.0 before it; it was withdrawn.)
OCPP 2.1 extends 2.0.1 rather than replacing it: tariffs and cost on the station, limits on a single session, scheduled resets, and the groundwork for bidirectional charging and local energy control. A 2.1 station is a 2.0.1 station with more to offer.
| Row | 1.6 | 2.0.1 | 2.1 |
|---|---|---|---|
| Structure | connectors only | station, EVSE, connector | same as 2.0.1 |
| Transaction | 3 message types | one TransactionEvent | same as 2.0.1 |
| Transaction id | integer, CSMS assigns | string, station assigns | same as 2.0.1 |
| Card | bare string, up to 20 chars | typed IdToken | same as 2.0.1 |
| Device model | none | components and variables | extended |
| Subprotocol | ocpp1.6 | ocpp2.0.1 | ocpp2.1 |
How the version is chosen
The station lists what it can speak in the WebSocket handshake:
Sec-WebSocket-Protocol: ocpp2.0.1, ocpp1.6
Flowion answers with the newest version on that list, so every charger is met on the most capable protocol both sides speak. A station offering all three gets 2.1.
If a station offers nothing the server supports, the handshake completes without a protocol and the connection closes at once. A station that connects and drops straight away is usually set to offer a version nobody agreed on.
Flowion records the version each charger settled on, as ocppVersion on the charger, so you see what it actually speaks rather than what its datasheet promises.
What it means for your integration
One integration for the whole fleet. The API talks about chargers, outlets, sessions and cards, and none of those belong to a protocol version. A 1.6 charger and a 2.1 charger are the same kind of object to your code, and a mixed fleet needs nothing extra.
Ask a charger what it can do. GET /v1/charging-stations/{id}/commands/capabilities answers, for the everyday commands, whether this charger supports each one, from what Flowion already knows about it. It works while the charger is offline. See Commands.
Some features belong to one version. A few things exist only on the newer wire, and a few only on 1.6:
| Feature | Where it works |
|---|---|
| Messages on the charger's screen | 2.0.1 and 2.1 |
| A limit on one session's energy, time or charge level | 2.1 |
| Tariffs sent to the charger itself | 2.1 |
| Firmware updates | 1.6 |
| Diagnostics files | 1.6 |
| A local list of cards the charger checks itself | 1.6 |
When you ask for something a charger's version cannot carry, Flowion says so with a clear error instead of sending an approximation. The console checks the same capabilities before it offers an action.
Some fields only newer chargers fill in. A 1.6 charger never reports what kind of card was shown, why it sent a transaction event, or which remote start a session came from. Those fields are empty rather than guessed, so "the charger did not say" never looks like a real value.
How Flowion maps onto OCPP has the full account of the translation.
Security
Every charger connects over TLS (wss://) and proves who it is with its own key, which you can rotate at any time: OCPP's Security Profile 2. The key is shown once when you add the charger and only a hash is stored.
The pieces for Security Profile 3, where a charger proves who it is with a client certificate instead of a password, are in place: Flowion runs its own certificate authority and signs certificates for 2.x chargers that ask for one. Accepting certificate-based connections is not switched on yet.
Practical advice
Check what a charger negotiated, not its spec sheet. Firmware configuration decides it: a 2.0.1-capable charger set to offer only 1.6 will speak 1.6.
Do not plan around a version upgrade. Moving a charger from 1.6 to 2.0.1 is a different protocol, usually a firmware change, and sometimes not offered for hardware already installed.
Expect a mixed fleet. Chargers last ten years, so a fleet that grows will hold several versions at once. That is the case Flowion's version-neutral API is built for.
Check a model before you buy. The supported devices list shows, charger by charger, what each one speaks.