Menu

How a charger registers

See what happens between a charger's first connection and its first session: credentials, the boot handshake, and the setup Flowion runs for you.

4 min readEdit this page
On this page

Between "a charger is plugged in" and "a driver can charge" sits registration: the charger proves who it is, describes itself, and gets configured. Flowion runs all of it for you. This page shows what happens on the wire, for when you want to know.

Connect a charger covers the steps you take on site.

1. You add the charger

You create the charger in Flowion with the charge point id it will connect with. You can also declare its outlets up front, each on the circuit that feeds it, so load management covers the charger from its very first session:

POST/v1/projects/$PROJECT/charging-stationsbash
curl -X POST "$API/projects/$PROJECT/charging-stations" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"chargePointId": "CP-01",
       "evses": [{"evseId": 1, "circuitId": "'$CIRCUIT'"}]}'

The response carries the charger's authorizationKey, once. Flowion stores only an Argon2id hash of it, so it cannot be shown again; you can always rotate it for a new one.

2. The charger connects

The charger opens a WebSocket to ocpp.flowion.io over TLS and signs in with HTTP Basic: its charge point id as the username, the key as the password. That is OCPP's Security Profile 2. A wrong id or key never gets past the handshake.

The OCPP version is agreed in the same handshake. Flowion picks the newest one the charger offers; see Which OCPP version am I dealing with?.

3. The boot handshake

The charger's first message is BootNotification: vendor, model, serial number, firmware and modem details. Until it gets an answer, it may send nothing else, so the answer is a gate.

Flowion answers a new charger Pending, which tells it to stay connected and wait while the CSMS sets it up. Then Flowion runs three steps on its own:

StepWhat Flowion does
inventoryReads everything the charger reports about itself: its configuration on 1.6, its full device model on 2.x.
configurationWrites the configuration its make and model should have, such as heartbeat interval and which meter values to send.
triggerAsks the charger to boot again, so it re-announces itself with its new settings.

On that next boot, Flowion answers Accepted, with the heartbeat interval for its model, and the charger starts serving drivers.

Each Pending answer asks the charger to retry in 30 seconds. If a step keeps failing, Flowion accepts the charger anyway after five attempts and records which step failed and what the charger said, so a stubborn charger still comes online and the reason stays on record.

Registration status is something Flowion decides, never a value anyone sets by hand, so no charger is left stuck on Pending or Rejected by a mistake. A charger that has already registered is accepted on every later boot.

Follow it as it happens

GET/v1/charging-stations/$CHARGER/registrationbash
curl "$API/charging-stations/$CHARGER/registration" \
  -H "Authorization: Bearer $TOKEN"

state is one of neverSeen, provisioning, provisioned, acceptedUnprovisioned (accepted after the attempts ran out), grandfathered (registered before this process existed) or deprovisioned. The response also carries when each step finished, the number of attempts, and the last failure with the charger's own words.

What the charger tells you

Once it has booted, the charger record carries:

  • bootReport: vendor, model, serial number, firmware version and modem details, from the latest boot.

  • ocppVersion: what it actually negotiated (ocpp1.6, ocpp2.0.1 or ocpp2.1).

  • status: online or offline, whether it holds a connection right now.

  • lastSeen: when Flowion last heard from it at all. Use it to judge whether an online charger is really alive.

  • lastBootAt: when the latest BootNotification arrived.

Every boot is kept too. GET .../boot-reports lists them, newest first: entries minutes apart are a restart loop, and an entry with a new firmwareVersion is a firmware update.

Outlets appear on their own

You never have to create EVSEs or connectors. Any you did not declare up front appear as the charger reports them, and declared ones are matched to the charger's own report.

GET/v1/charging-stations/$CHARGER/evsesbash
curl "$API/charging-stations/$CHARGER/evses" \
  -H "Authorization: Bearer $TOKEN"

Check the shape against the hardware when you commission it. A two-cable post reporting two EVSEs rather than one EVSE with two connectors is telling Flowion that two cars can charge at once. See The vocabulary.

Rotate the key

POST/v1/charging-stations/$CHARGER/credentialbash
curl -X POST "$API/charging-stations/$CHARGER/credential" \
  -H "Authorization: Bearer $TOKEN"

The response carries the new authorizationKey, once, and the old key stops working immediately.

Deprovision a charger

DELETE/v1/charging-stations/$CHARGERbash
curl -X DELETE "$API/charging-stations/$CHARGER" \
  -H "Authorization: Bearer $TOKEN"

The charger's key stops working, so it can no longer open a new connection. The record and its history stay, and disabledAt records when it happened. Calling it again is harmless.

This does not reach the hardware: a deprovisioned charger that is still powered on will keep trying to connect. Reconfigure or power it down if it should stop.

Endpoints

Chargers · EVSEs and connectors · Commands

In the API reference