The vocabulary

OCPP has been through three major versions across fifteen years, and each one renamed things. The result is that the same object has two or three names depending on which document you are reading, and two different objects share a name that sounds like it should mean the obvious thing.

This page is the one to keep open while you read everything else.

The thing on the wall#

All three names for the hardware mean the same physical unit. "Charge Point" is 1.6's term and survives in field names you will still see on the wire — chargePointVendor, chargePointModel, and the charge_point_id in a station's connection URL. 2.x renamed it to "Charging Station" and that is what current specifications use throughout.

Likewise the server: 1.6 says Central System, 2.x says CSMS (Charging Station Management System). Same role.

We use Charger in the API and the console, because it is the word operators actually use.

EVSE and Connector — the one that trips everybody#

This is the most common early misunderstanding, and it costs people days.

OCPP 2.x describes charging hardware as three nested tiers:

Charging Station          the physical unit
 └─ EVSE                  can deliver energy to one EV at a time
     └─ Connector         a single physical outlet or tethered cable

• An EVSE (Electric Vehicle Supply Equipment) is an independently operated part of the station that can charge one vehicle at a time. It is the unit of "can someone charge here right now".
• A Connector is a single physical socket or attached cable.

The trap: one EVSE can have several connectors, but only one of them can be in use at a time. A post with both a CCS cable and a CHAdeMO cable, sharing one power module, is one EVSE with two connectors — not two EVSEs. Plugging into the second one while the first is charging is not possible, and any model that treats connectors as independently usable will get this wrong.

So: count EVSEs to know how many cars can charge simultaneously. Count connectors to know what plug types are available.

Numbering#

• EVSEs are numbered from 1, sequentially, with no gaps.
• Connectors are numbered from 1 within each EVSE. Every EVSE has a connector 1.

Connector numbers are therefore not unique across a station. "Connector 1" is meaningless on its own; you need the EVSE too.

Zero means the whole station#

Both tiers reserve 0 for "the station itself, not any particular part of it":

• In OCPP 2.x, evseId 0 addresses the entire charging station when the CSMS initiates, and refers to the station's main controller when the station reports.
• In OCPP 1.6, which has no EVSE concept at all, connectorId 0 plays this role — it means the charge point as a whole. A StatusNotification on connector 0 is the station's own status, and the specification is explicit that it has no direct relationship to the status of the individual connectors. Only Available, Unavailable and Faulted are valid there. A MeterValues on connector 0 is the station's main meter, not any session.

Treating connector 0 as "the first connector" is a real and common bug.

1.6 has no EVSEs#

OCPP 1.6 is flat: a charge point has connectors, numbered from 1, and that is the entire structure. There is no middle tier.

Flowion models the 2.x hierarchy for every charger regardless of version, so a 1.6 charger is given a single synthesized EVSE (id 1) holding all its connectors. See How Flowion maps onto OCPP.

Identifiers#

An idTag in 1.6 is a bare string of at most 20 characters — typically the UID read off an RFID card. 2.x replaces it with IdToken, a structured type carrying both a value and a type saying what kind of credential it is (ISO 14443 RFID, a key code, a MAC address, a token the CSMS itself issued, and so on).

The important point for an integrator: an id token identifies a credential, not a person. One driver may carry several cards; one card may be shared by a fleet. Mapping tokens to accounts is your business logic, not OCPP's.

A parentIdToken (1.6: parentIdTag) groups tokens so that, for example, any card in a household can stop a session another card started.

Transaction, session, charge#

Transaction is OCPP's word, and it is the one to use. It spans from the moment charging is authorized and begins to the moment it stops — one car, one EVSE, one continuous visit.

"Session" is used loosely in the industry to mean the same thing, and sometimes to mean a driver's whole interaction including the app. We avoid it.

The two versions record a transaction very differently:

• 1.6 sends three unrelated messages: StartTransaction, then any number of MeterValues, then StopTransaction. The CSMS allocates an integer transaction id and returns it; the station echoes it back on everything after.
• 2.x sends one message type, TransactionEvent, with eventType of Started, Updated or Ended. The station chooses the transaction id, a string, and it is present from the very first event.

Note who allocates the id: it changed sides between versions. Do not assume you can hand a 2.x id to a 1.6 charger, or vice versa — see How Flowion maps onto OCPP.

Status words that sound alike#

Connector status answers "what is this outlet doing?" 1.6 defines nine values:

Available through Reserved are Operative; Unavailable and Faulted are Inoperative.

Two of these are worth a second look:

• SuspendedEV and SuspendedEVSE are opposites and easily transposed. EV suspended means the car stopped drawing. EVSE suspended means the station stopped supplying — which is what load management looks like from the outside. If both apply, SuspendedEVSE wins.
• Preparing and Finishing are why a connector is not free the instant a session ends. A cable left plugged in keeps a connector out of circulation.

OCPP 2.x splits this single concept in two: a connector status covering availability, and a transaction's charging state covering whether energy is moving. Flowion models it 2.x's way for every version.

Registration status#

The answer to a station's BootNotification:

These are not merely informational; each puts the station into a different mode with different rules about what it may send. See Lifecycle of a charging session.

Acronyms you will meet#

OCPP concerns exactly one of these relationships: operator to their own hardware. Roaming, pricing and driver apps live in OCPI and are out of scope here.

Flowion's own words#

These are ours, not OCPP's, and exist above the protocol entirely:

Getting started covers these properly.