BootNotification: how a charger comes online

The message

// Charge point -> CSMS
[2, "19223200", "BootNotification", {
  "chargePointVendor": "ExampleVendor",
  "chargePointModel": "DC60-CCS2",
  "chargePointSerialNumber": "CP014-002",
  "chargeBoxSerialNumber": "CB-2024-88231",
  "firmwareVersion": "2.4.1",
  "iccid": "89910123456789012345",
  "imsi": "404451234567890",
  "meterType": "Landis+Gyr E360",
  "meterSerialNumber": "MTR-77123"
}]

// CSMS -> charge point
[3, "19223200", {
  "status": "Accepted",
  "currentTime": "2026-08-11T08:59:58Z",
  "interval": 900
}]

Sent immediately after the WebSocket opens, and again after every reboot, firmware install or reconnection following a long outage.

The three verdicts

interval does double duty: on Accepted it is the heartbeat period; on Pending or Rejected it is how long to wait before retrying. A short retry interval on Rejected across a fleet of unknown chargers is a self-inflicted denial of service on your own CSMS.

Rejected as a security control

Rejected is the gate for chargers you do not recognise. A CSMS endpoint is reachable from the internet, and unknown units will connect — misconfigured hardware pointed at the wrong CSMS, units from a decommissioned site, and occasionally something you should look at more closely.

A reasonable policy:

• Known and provisioned → Accepted.
• Known but not yet configured → Pending, configure, then accept on the retry.
• Unknown serial → Rejected with a long interval, and log it.
• Known but decommissioned → Rejected, and alert — a retired unit reconnecting is worth investigating.

Accepting anything that connects means your fleet inventory is defined by whatever dials in, which is not an inventory.

Free fleet inventory

Every boot carries a full hardware and firmware census. Recorded over time it answers questions that are otherwise expensive:

The boot pattern itself is diagnostic. A charger sending BootNotification every few minutes is in a reboot loop — a fault no availability metric will show you, because between reboots it reports as fine. Alert on boot frequency, not just on boot failure.

What happens after a reboot

A reboot is not free. Depending on the vendor and how it happened:

• Queued offline transactions may or may not survive. A hard reset is materially more likely to lose them than a soft one.
• Configuration may have reverted, particularly after a firmware install. Re-apply rather than assume.
• Active sessions end. Expect StopTransaction with reason Reboot or PowerLoss.
• The charger re-reports status for every connector, so treat post-boot status as authoritative and discard what you held before.

Using the boot as a trigger to reconcile — verify configuration, check firmware version, refresh status — turns an unavoidable event into a consistency checkpoint.

Production lessons

• Use Pending to provision before first use. It is what the status exists for.
• Reject unknown serials with a long retry interval and log every one.
• Persist every boot as an inventory record, not just the latest state. The history is what makes it useful.
• Alert on boot frequency to catch reboot loops that availability metrics hide.
• Set interval per charger here rather than pushing configuration changes fleet-wide.
• Re-verify configuration after every boot following a firmware change.
• Serve currentTime from a synchronised clock — this is the charger's first clock set, and every timestamp it produces afterwards inherits it.