Lifecycle of a charging session
Follow one charge from power-on to unplug: the OCPP messages on the wire at each step, and what Flowion does with each one.
On this page
This page follows one charge from the moment a station is switched on to the moment the driver drives away. At each step you see the OCPP messages on the wire and what Flowion does with them.
The message names are OCPP 1.6's, because its shape is the easiest to read. Where 2.x differs, the last section shows how.
1. The station comes online
A station that has just powered on does three things, in order.
It opens a WebSocket to ocpp.flowion.io, over TLS, proving who it is with its own credentials. The version is agreed in the same handshake; see OCPP in ten minutes.
It sends BootNotification, describing itself: vendor, model, serial number, firmware version, and modem details if it has one.
It waits. Until the boot is answered, a station may send nothing else, not even messages it queued before the reboot. The answer decides what happens next:
| Answer | What the station does |
|---|---|
Accepted | Takes the heartbeat interval, sets its clock from currentTime, and starts operating. |
Pending | Stays connected and waits. The CSMS may read and configure it; it sends nothing of its own unless asked. |
Rejected | Goes quiet until its retry interval passes. |
interval means two things. On Accepted it is the heartbeat interval; otherwise it is how long the station waits before trying to boot again.
What Flowion does: a charger's first boot is answered Pending. While it waits, Flowion reads everything the charger says about itself (its outlets, its settings), writes the configuration its make and model should have, and then accepts it. The charger can serve drivers from the moment Flowion knows what it is. Flowion keeps a history of boot reports, and you can read the charger's registration progress through the charger endpoints. How a charger registers has the detail.
2. Idle
Once accepted, the station settles into a quiet loop.
StatusNotification for each connector, reporting Available. Connector 0 means the station as a whole.
Heartbeat every interval seconds. Flowion answers with the current time, which keeps a station without a battery-backed clock accurate, and so keeps the timestamps on your sessions right.
MeterValues may arrive with nobody charging, for example a reading from the station's main meter on connector 0.
3. A driver arrives
The driver presents an RFID card.
StatusNotification: Preparing. The connector is taken, but no transaction has begun. You see the same when someone plugs in before showing a card.
Authorize. The station asks whether this card may charge:
The CSMS answers with a status:
Accepted, Blocked, Expired, Invalid or ConcurrentTx. A refusal is still a CallResult: the exchange worked, the answer was no.
A station may skip this message when the card is in its local list or its cache. That is what keeps a site charging through a network outage, and it is why you will not see an Authorize before every session.
What Flowion does: it decides each request against the access you set for the charger, its site or its project, and the people you have allowed. It also keeps each charger's offline settings, and its local list where the charger has one, in step with those choices, so offline decisions follow the same rules.
4. Charging begins
StartTransaction reports that a session has begun:
meterStart is the meter's running total in Wh at the start, not zero and not the session's consumption. The response assigns the transaction id:
The station may have let the driver in from a cached answer that is now out of date, so the CSMS decides again here. Flowion does: a card revoked since it was cached is refused at this point. Flowion also always answers, because a station that gets no answer resends the message and creates duplicates.
StatusNotification: Charging. The contactor closes and energy flows. Short visits to SuspendedEV or SuspendedEVSE are normal while a car settles into its charge curve.
5. While charging
MeterValues arrive periodically, carrying the transaction id:
Readings can include energy, power, current, voltage and state of charge. The transactionId is what ties a reading to a session; a reading without one is a standalone reading, typically from the main meter.
Status can change without the session ending. SuspendedEVSE in the middle of a session usually means load management has paused this outlet to make room for others. The transaction is still open.
What Flowion does: it keeps the readings on the session as they arrive, so the session's energy is there while it is still running, and it shares the site's capacity between the chargers drawing from it.
6. It ends
The driver presents their card again, or unplugs.
StopTransaction:
Energy delivered is meterStop - meterStart: 32.9 kWh here.
A stop cannot be refused. By the time this message arrives, the charge has already ended; the response only acknowledges it. A missing reason means Local, a normal stop by the driver. Anything else names itself: EmergencyStop, PowerLoss, Reboot, DeAuthorized.
StatusNotification: Finishing, then Available once the cable is out. An outlet with a cable still in stays occupied, which is why a site can look full with nobody charging.
What Flowion does: it closes the session with its energy, stop reason and full event history, and, when a tariff applies, works out what the session cost.
The same story in OCPP 2.x
The steps are the same; the messages are fewer.
| 1.6 | 2.x |
|---|---|
StartTransaction | TransactionEvent (eventType: Started) |
MeterValues during a session | TransactionEvent (eventType: Updated) |
StopTransaction | TransactionEvent (eventType: Ended) |
One message type instead of three, each with a triggerReason saying why it was sent. The transaction id changes sides: in 2.x the station picks a string id, present from the first event. Every event that carries a card is a fresh chance to decide, and Flowion decides each one, so a card revoked mid-session is refused on the next event.
What you end up with
Whichever version a charger speaks, Flowion stores the same thing: a session with an event log, the meter readings attached, and outlets whose status you can follow over time. Your code reads one shape for the whole fleet. See Track sessions, energy and cost.