OCPP BootNotification Message: Fields, Statuses & Fixes

The BootNotification message is the first thing a charge point says after it establishes a WebSocket connection to its CSMS (Charging Station Management System). It’s how the charger identifies itself, how the CSMS confirms it’s a known device, and how the two sides agree on the heartbeat interval that follows. If you’re new to the protocol overall, what is OCPP covers the bigger picture, and OCPI vs OCPP vs ISO 15118 explains where OCPP sits relative to the roaming and vehicle-to-charger protocols.

It’s a tiny message — five or six fields and a simple request/response — but it’s the gateway to everything else. A broken BootNotification means a charger that never comes online, never accepts users, and sits stubbornly “offline” in your operations dashboard even when the hardware is fine.

This article walks through exactly what the BootNotification message carries in both OCPP 1.6 and 2.0.1, what each response status means, and the failure modes behind the most common real-world support tickets.

The basic flow

A charger goes through this sequence:

1. Power on (or recover from a network outage, or be reset).
2. Establish WebSocket connection to the CSMS URL it has configured. This involves TCP handshake, TLS handshake (in modern deployments), and WebSocket upgrade.
3. Send BootNotification as the first message on the new WebSocket.
4. Wait for response — Accepted, Pending, or Rejected.
5. If Accepted, begin normal operation: start heartbeating, send StatusNotification for each connector, become available for sessions.
6. If Pending, keep waiting and re-send BootNotification at the indicated interval.
7. If Rejected, stay in registration-failed mode and re-send at the indicated interval.

The whole exchange takes milliseconds when everything is healthy.

stateDiagram-v2
    [*] --> Connecting
    Connecting --> BootSent: WebSocket up
    BootSent --> Accepted: status Accepted
    BootSent --> Pending: status Pending
    BootSent --> Rejected: status Rejected
    Pending --> BootSent: retry
    Rejected --> BootSent: retry
    Accepted --> Operating: heartbeat<br/>and status
    Operating --> [*]

What BootNotification carries (OCPP 1.6)

A 1.6 BootNotification payload:

{
  "chargePointVendor": "ExampleCo",
  "chargePointModel": "X1-Outdoor-22kW",
  "chargePointSerialNumber": "EX-2024-098765",
  "chargeBoxSerialNumber": "EX-CB-2024-098765",
  "firmwareVersion": "1.4.7-prod",
  "iccid": "8931086224231234567",
  "imsi": "204041234567890",
  "meterType": "ABB-EVB1A22",
  "meterSerialNumber": "AB-2024-554433"
}

The fields:

• chargePointVendor (required) — the OEM/manufacturer name. In practice this is a hardware vendor string such as those a CSMS sees from ABB, ChargePoint, or Kempower, and the CSMS often keys allow-list and firmware-matching rules off it.
• chargePointModel (required) — the specific model.
• chargePointSerialNumber — serial of the charge point itself.
• chargeBoxSerialNumber — serial of the controller board/charge box (often the same as the above).
• firmwareVersion — current firmware string. Format is OEM-defined; some use semver, some use date stamps.
• iccid / imsi — SIM card identifiers, for cellular-connected chargers.
• meterType — the energy meter installed inside.
• meterSerialNumber — that meter’s serial.

Only vendor and model are required by the spec. Everything else is optional but, in practice, most OEMs send most fields and most CSMSes use them for inventory tracking.

What the CSMS responds with

The response carries the registration decision:

{
  "currentTime": "2026-06-26T08:00:00.000Z",
  "interval": 300,
  "status": "Accepted"
}

• currentTime — server time in UTC. The charger uses this to sync its clock. Crucial because every subsequent message timestamp is relative to this.
• interval — how often (seconds) the charger should send Heartbeat messages. Common values: 60-300 seconds for accepted chargers, 60-1800 for pending, 1800+ for rejected.
• status — Accepted, Pending, or Rejected.

If status is Pending or Rejected, the interval tells the charger how long to wait before retrying BootNotification.

What BootNotification carries (OCPP 2.0.1)

OCPP 2.0.1 reorganizes the same information under a chargingStation object and adds context about why the boot happened. (For the broader set of changes between releases, see the OCPP version comparison ^{(coming soon)}.)

{
  "chargingStation": {
    "model": "X1-Outdoor-22kW",
    "vendorName": "ExampleCo",
    "serialNumber": "EX-2024-098765",
    "firmwareVersion": "1.4.7-prod",
    "modem": {
      "iccid": "8931086224231234567",
      "imsi": "204041234567890"
    }
  },
  "reason": "PowerUp"
}

The reason enum tells the CSMS why this BootNotification fired. Possible values:

• PowerUp — first boot after power was applied.
• Triggered — sent in response to a TriggerMessage ^{(coming soon)} command from the CSMS.
• RemoteReset — after a CSMS-initiated reset.
• LocalReset — after a local (button-press or watchdog) reset.
• FirmwareUpdate — after a firmware update applied.
• ApplicationReset — software-level restart without hardware reset.
• ScheduledReset — planned reset on schedule.
• Watchdog — a watchdog timer fired.
• Unknown — when the charger doesn’t know why.

This context is genuinely useful operationally. A charger that BootNotifications with PowerUp once a day is probably losing power overnight (maybe a circuit issue). A charger that BootNotifications with Watchdog frequently has a firmware stability problem.

The three response statuses, in depth

Accepted

The charger is recognized and authorized. It can begin normal operation. The response includes the heartbeat interval and current time.

What the charger does next:

• Set its internal clock to currentTime.
• Start sending Heartbeat ^{(coming soon)} at the specified interval.
• Send StatusNotification ^{(coming soon)} for each connector (Available, Faulted, etc.).
• If a vehicle is plugged in already (e.g., the charger rebooted mid-session), send StatusNotification reflecting that state.
• Wait for user interaction or CSMS commands.

Pending

The CSMS recognizes the charger but isn’t ready to accept it. Typical reasons:

• The charger was just provisioned and the CSMS is still applying initial configuration.
• The CSMS is in maintenance mode for this charger.
• The CSMS is waiting for an operator action (e.g., “approve this newly-registered charger”).

The charger keeps retrying at the indicated interval. Each retry, the CSMS may transition the status to Accepted (provisioning done) or Rejected (operator chose to reject).

Rejected

The CSMS does not recognize the charger or is refusing to accept it. Reasons:

• The charger’s identity (vendor, model, serial) doesn’t match any expected record.
• The charger is registered with a different CSMS URL.
• The charger has been administratively deactivated.
• The charger’s certificate (in mutual-TLS configurations) failed validation.

The charger waits at the indicated interval and retries. It does NOT begin normal operation. Users can plug in, but nothing will happen — the charger has no authorization to start sessions.

This is the failure mode most likely to surface on a large network. Whether the CSMS is operated by a European CPO like Fastned or a North American one like Electrify America, a freshly-swapped or relocated charger that was pre-provisioned against the wrong CSMS record will loop on Rejected until an operator fixes the identity or the URL. The hardware looks fine on-site; the fault is entirely in the registration handshake.

Common failure modes

Things that go wrong with BootNotification, ranked roughly by frequency.

WebSocket never connects

The most common failure isn’t BootNotification itself — it’s the WebSocket that BootNotification is supposed to flow over. Causes:

• Wrong CSMS URL in the charger’s config.
• DNS resolution failure — the charger can’t resolve the CSMS hostname (firewall, captive portal, broken DNS).
• TLS certificate validation failure — the charger’s trust store doesn’t include the CSMS’s CA, or the CSMS is using a cert the charger doesn’t accept.
• Cellular outage — the SIM has no signal, or the carrier is blocking the destination.
• Authentication header missing — many CSMSes require Basic Auth or a header token at the WebSocket connect; missing or wrong → rejected by the CSMS before BootNotification is even sent.

Diagnosing this requires looking at the charger’s local logs (often serial console only) or the CSMS’s connection-attempt logs.

Status stuck Pending forever

The charger keeps retrying, never gets Accepted. Causes:

• CSMS provisioning pipeline broken — the workflow that should transition Pending to Accepted is failing.
• Operator needs to manually approve the charger in the CSMS UI and hasn’t.
• The charger’s identity is partial — it’s recognized but missing required fields, and the CSMS won’t accept it until they’re provided.

Charger gets Accepted but then never sees user sessions

BootNotification succeeded, Heartbeats are flowing, but no sessions ever start. Causes:

• StatusNotification missing — the CSMS thinks all connectors are Faulted or in an unknown state. Check whether StatusNotification with status=Available was sent post-boot.
• Tariff missing — some CSMSes refuse to allow sessions on chargers without a configured tariff. Provisioning gap.
• Local lockout — the charger has a local “out of service” button engaged.
• eMSP/roaming wiring incomplete — Authorize requests are being rejected because the CSMS doesn’t know how to validate them.

Clock drift

The currentTime in the BootNotification response is what the charger uses to sync its clock. If the CSMS sends wrong time (server misconfigured, NTP issues), the charger’s clock is wrong, and all subsequent timestamps (meter readings, transaction events) are off. Hard to detect — your dashboard just shows charging sessions happening at the wrong time.

Always verify CSMS time sync. UTC, NTP, no drift.

Firmware version mismatch

The charger reports firmware version “1.4.7-prod” but your CSMS expects “1.4.7” without the suffix. CSMS rejects boot because the version is unknown. Annoying, fixable by relaxing the matching rules.

Operational best practices

If you operate a CPO, a few things to do:

1. Monitor BootNotification frequency per charger. A charger that BootNotifications more than once a day is a warning sign. Repeated boots indicate connectivity instability, watchdog resets, or other problems worth investigating.
2. Alert on Pending or Rejected statuses. A charger sitting in Pending for hours is a provisioning failure that needs human intervention.
3. Log the reason field (2.0.1+). Use it for diagnostic correlation. Watchdog-heavy chargers are firmware-unstable; PowerUp-heavy chargers are power-supply-unstable.
4. Time-sync your CSMS rigorously. NTP everywhere, monitor drift, alert on drift > 1 second.
5. Standardize firmware-version strings with your hardware OEMs so your CSMS matching rules are predictable.
6. Test reboots. Periodically (in maintenance windows) trigger a Reset on chargers and confirm BootNotification flows cleanly. Discovers bugs before users do.

What BootNotification doesn’t tell you

A few things it does NOT cover, despite seeming like it should:

• Per-connector state. That comes via StatusNotification after the boot completes.
• Active transactions. A charger that rebooted mid-session must report the in-flight transaction via separate post-boot messages (TransactionEventRequest ^{(coming soon)} in 2.0.1 with eventType=Updated, for example).
• Configuration values. The CSMS knows what configuration it pushed; the charger doesn’t echo it back in BootNotification. If you want to verify, use GetConfiguration (1.6) or GetVariables (2.0.1) after boot.
• Capability discovery beyond model. Knowing the model is “X1-22kW” tells the CSMS what to expect, but rich capability discovery (which optional OCPP features the charger supports) requires further messages.

Key takeaways

BootNotification is a small, simple message that’s foundational to everything else in OCPP. A few things worth holding onto:

• It’s the first message on every new WebSocket, and nothing else works until it returns Accepted.
• Only chargePointVendor and chargePointModel are required in 1.6; everything else is optional but useful for inventory.
• The response’s interval means “heartbeat cadence” when Accepted and “retry delay” when Pending or Rejected — same field, different meaning.
• currentTime synchronizes the charger’s clock, so a wrong CSMS time silently corrupts every downstream timestamp.
• In 2.0.1, identification moves under a chargingStation object and the reason enum turns each boot into a diagnostic signal.

Almost every OCPP support ticket about “charger is offline” or “charger isn’t accepting sessions” starts with a question about whether BootNotification succeeded. Get this part right, instrument it carefully, and you save your operations team a lot of pain.

For what happens next in the connectivity lifecycle, see Heartbeat and the connection lifecycle ^{(coming soon)} and StatusNotification deep dive ^{(coming soon)}.