How BootNotification works (OCPP 1.6J)

BootNotification is the first OCPP 1.6J message after the WebSocket connects. The charger identifies itself. Until the CSMS answers Accepted, it should not start a session.

If the CSMS replies Pending, Edition 2 says retry BootNotification after the given interval and send nothing else until Accepted. That rule is why a station can “connect” and still never charge. See the OCPP 1.6 overview and official download. Also in the 1.6J sample list.

When BootNotification is triggered

  • The charger (or virtual charge point) opens a new WebSocket to the CSMS.
  • The device reboots after a Reset, power loss, or firmware install.
  • The CSMS sends TriggerMessage with requestedMessage: "BootNotification".

The station identity in the URL (for example CF-DEMO-A7K2) tells the CSMS which charger this is. The payload carries vendor, model, and firmware.

BootNotification sample message

Required fields are vendor and model. Serial number and firmware are optional in the spec but almost every CSMS uses them for inventory.

Charge point → CSMS
JSON[
  2,
  "a7k2-boot-01",
  "BootNotification",
  {
    "chargePointVendor": "Chargeflux",
    "chargePointModel": "CF-AC7 Type 2",
    "chargePointSerialNumber": "CF-DEMO-A7K2",
    "firmwareVersion": "1.6.0-cf"
  }
]
CSMS → charge point
JSON[
  3,
  "a7k2-boot-01",
  {
    "status": "Accepted",
    "currentTime": "2026-08-14T10:15:03.000Z",
    "interval": 300
  }
]

interval is in seconds. 300 means “send a Heartbeat every five minutes.”

What Accepted, Pending, and Rejected mean

StatusMeaning
AcceptedThe station may operate. Start heartbeats and connector status reports.
PendingCSMS is not ready (unknown station, waiting on an operator). Retry boot only.
RejectedCSMS will not register this identity. Retry later at the given interval. Check the station is provisioned.

Chargeflux shows this pair in the message console with timing. Walk through the UI in getting started.

Heartbeat sample (the keep-alive that follows)

After Accepted, the charger sends an empty Heartbeat on that interval. The CSMS answers with the current time so meter timestamps stay close.

Charge point → CSMS
JSON[
  2,
  "a7k2-hb-01",
  "Heartbeat",
  {}
]
CSMS → charge point
JSON[
  3,
  "a7k2-hb-01",
  {
    "currentTime": "2026-08-14T10:20:03.000Z"
  }
]

If heartbeats stop, most CSMS products mark the station offline. That is an operations feature, not a side effect.

Typical boot sequence

1. Charger opens wss://csms.example.com/ocpp/CF-DEMO-A7K2
   (WebSocket subprotocol: ocpp1.6)
2. BootNotification → Accepted (interval = 300)
3. StatusNotification for each connector (often Available)
4. Heartbeat every 300 seconds

Next, the plug will change state. See connector status. To start energy flow, continue with the charging session messages.

How to test BootNotification in Chargeflux

  1. Register the same station identity in your CSMS that you type into the simulator.
  2. Connect. Confirm the CALL / CALLRESULT pair and the registration status.
  3. If the socket never opens, fix transport first — WebSocket troubleshooting.
  4. Leave the station connected and confirm Heartbeat lands on your interval.

Related

FAQ

When is BootNotification sent in OCPP 1.6J?

As soon as the WebSocket is up — after power-on, firmware reboot, or a reconnect. The central system can also ask for another BootNotification with TriggerMessage.

What does a BootNotification Accepted reply mean?

The charger may operate. Apply the interval from the reply as the Heartbeat period in seconds, and start sending StatusNotification for each connector.

What should a charger do if BootNotification is Pending?

Retry BootNotification after the given interval. Until the status is Accepted, it must not send other OCPP messages.

Is Heartbeat the same as BootNotification?

No. Boot is the introduction. Heartbeat is the later keep-alive. The CSMS currentTime on Heartbeat also helps the charger set its clock.

Last reviewed August 2026 · Chargeflux.io