BootNotification is the first message a Charge Point sends to the CSMS after every
boot or reboot. It carries two required fields — chargePointVendor and
chargePointModel — plus up to seven optional identifiers.
The CSMS responds with Accepted, Pending, or Rejected;
normal operations may only begin once Accepted is received.
What is BootNotification?
BootNotification is the handshake that opens every OCPP session. When a Charge Point (CP) powers up or reboots, the very first message it sends to the Central System Management Software (CSMS) must be a BootNotification request. The CSMS uses this message to register or re-register the Charge Point and to synchronize the clock.
Send on every boot — no exceptions
OCPP 1.6 §4.2 states that a Charge Point SHALL send BootNotification each time it boots or reboots, even if it was already accepted in a prior session (Open Charge Alliance, 2015, §4.2). Skipping BootNotification after a watchdog reset is one of the most common integration mistakes.
Until the CSMS responds with Accepted, the Charge Point is in a restricted state.
It must not initiate transactions, Heartbeats, StatusNotification messages, or any other OCPP
operations. It should hold local events in a queue and wait.
The response always includes three fields: status (Accepted,
Pending, or Rejected), the CSMS's current UTC clock
(currentTime), and an interval in seconds. The meaning of
interval shifts depending on the status: when accepted it becomes the Heartbeat
interval; when pending or rejected it is the minimum wait time before retrying.
Message format
OCPP-J encapsulates every request inside a CALL frame — a JSON array with exactly four elements (Open Charge Alliance, 2015, §4.2.1):
2— the message-type identifier for CALL- A unique ID string you generate, used to correlate the matching CALLRESULT
- The action name:
"BootNotification" - The payload object containing the Charge Point fields
The unique ID ("19223201" above) can be any non-empty string. UUID v4 is common in
production; sequential integers work fine in test environments. The CSMS echoes the same ID back
in the CALLRESULT so your implementation knows which response matches which request.
Required & optional fields
The table below is derived directly from the official OCPP 1.6 JSON Schema
(BootNotificationRequest.json, draft-04). All string constraints are exact — a value
even one character over the listed maximum will fail schema validation at a strict CSMS.
| Field | Required | Type / max | Description |
|---|---|---|---|
| chargePointVendor | Yes | string / 20 | Vendor name of the Charge Point. The 20-character limit is a frequent source of truncation bugs with long brand names. |
| chargePointModel | Yes | string / 20 | Model identifier of the Charge Point. Also limited to 20 characters. |
| chargePointSerialNumber | No | string / 25 | Serial number of the physical Charge Point unit. Used for asset tracking and RMA workflows. |
| chargeBoxSerialNumber | No | string / 25 | Serial number of the individual charge box (EVSE). Relevant for multi-outlet units where each connector has a distinct identity. |
| firmwareVersion | No | string / 50 | Current firmware version string. CSMSes use this to check eligibility for over-the-air updates. Must be a string, not a number. |
| iccid | No | string / 20 | ICCID of the modem's SIM card. Links the Charge Point to its cellular network subscription. |
| imsi | No | string / 20 | IMSI of the modem's SIM card. Pairs with ICCID for full cellular identity registration. |
| meterType | No | string / 25 | Type of energy meter installed in the Charge Point (e.g. "Landis+Gyr E350"). |
| meterSerialNumber | No | string / 25 | Serial number of the energy meter. Useful for audit trails and meter replacement tracking. |
Example payloads
Minimal — required fields only
The smallest valid BootNotification payload. Use this as a baseline when diagnosing whether a CSMS rejects your message for schema reasons vs. authentication reasons.
With cellular modem (ICCID + IMSI)
For LTE/4G Charge Points, include the SIM identity fields so the CSMS can correlate the device with its network subscription and carrier billing records.
Full payload — all nine fields
A production example with every field populated. Use the Validator to confirm each value stays within its maximum character length before deploying.
CSMS response
The CSMS wraps its reply in a CALLRESULT frame (message type 3) that echoes the same
unique ID as the original CALL. The response payload always contains all three fields:
currentTime, interval, and status.
Registration successful. The interval value becomes the Heartbeat interval.
Normal OCPP operations may start immediately.
Registration not yet complete (e.g. awaiting provisioning). Wait at least
interval seconds, then send a new BootNotification. No transactions.
Registration refused. Wait at least interval seconds before
reconnecting. Typically indicates a configuration or security issue at the CSMS.
Accepted response example
Pending response example
OCPP 2.0.1 differences
OCPP 2.0.1 significantly restructures the BootNotification payload. If you are building or testing a 2.0.1 implementation, the following changes are breaking incompatibilities — a 1.6 payload sent to a 2.0.1 CSMS will fail schema validation (Open Charge Alliance, 2020, §4.3.1).
| Change | OCPP 1.6 | OCPP 2.0.1 |
|---|---|---|
| Payload structure | Flat top-level object | Nested chargingStation object |
| Vendor field | chargePointVendor (max 20) | vendorName (max 50) inside chargingStation |
| Model field | chargePointModel (max 20) | model (max 20) inside chargingStation |
reason field | Not present | Required. Enum: PowerUp, FirmwareUpdate, LocalReset, RemoteReset, ScheduledReset, ApplicationReset, Triggered, Watchdog, Unknown |
| Modem fields | iccid, imsi at root level | modem: { iccid, imsi } nested inside chargingStation |
| Response extras | None | Optional statusInfo object with reasonCode (max 20) and additionalInfo |
Common errors
chargePointVendor exceeds 20 characters
The most common field-length violation. Names like "Schneider Electric SE"
(21 chars) fail silently at CSMSes that truncate rather than reject. Always keep the
vendor string at or under 20 characters — abbreviate if necessary
(e.g. "Schneider Elec.").
firmwareVersion sent as a number instead of a string
The schema defines firmwareVersion as type: "string".
Sending "firmwareVersion": 2 (integer) fails JSON Schema validation.
Always quote it: "firmwareVersion": "2.1.4".
Starting Heartbeat before receiving Accepted
Some firmware starts the Heartbeat timer the moment the WebSocket connects.
Per OCPP 1.6 §4.2, the Charge Point must wait for Accepted before
sending any other messages, including Heartbeat. Starting early can confuse CSMSes
that track state transitions strictly.
Not resending BootNotification after Pending
When the CSMS returns Pending, the correct behaviour is to wait
interval seconds, then send a new BootNotification. Some
implementations treat Pending like Accepted and proceed to normal operation — this
results in transactions the CSMS may not recognise as valid.
Omitting chargePointModel entirely
Both chargePointVendor and chargePointModel are required.
A payload with only chargePointVendor fails with
"required property 'chargePointModel' not found". Both fields must be
present even if the CSMS doesn't display them in its UI.
How to test BootNotification
You can validate and test BootNotification frames entirely in the browser using the tools on this site — no local CSMS setup required.
- Build your payload — Open the
OCPP 1.6J Builder, select
BootNotification from the message list, and fill in the form fields.
The builder enforces
maxLengthconstraints at input time so you catch truncation errors before sending anything. - Validate the CALL frame — Paste the generated frame into the
Validator. It runs the official OCA JSON Schema
(
BootNotificationRequest.json) against your payload and pinpoints exactly which fields violate the spec. - Validate the response — Switch to the Response tab in the Validator and paste a BootNotificationResponse frame to confirm the CSMS-side payload is also schema-valid.
- End-to-end test — Use the Simulator to
connect to a real or test CSMS over WebSocket. The Simulator sends BootNotification
automatically on connect and logs the raw CALLRESULT — including the
statusandintervalvalues — in the message panel.
Rodolfo Carrillo
OCPP integration engineer and creator of OCPP Tools. All articles are verified against the official Open Charge Alliance specification and tested using the on-site Validator, Builder, and Simulator.
Build a frame in seconds
Form-driven payload builder — pick fields, get a valid frame, copy to clipboard.
Frequently asked questions
Does the Charge Point need to send BootNotification on every restart?
What is the maximum length for chargePointVendor?
What should a Charge Point do when it receives a Pending response?
What is the difference between chargePointSerialNumber and chargeBoxSerialNumber?
Can the Charge Point start a transaction before receiving Accepted?
Does OCPP 2.0.1 BootNotification require a reason field?
Sources & further reading
- · Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, §4.2 — BootNotification. https://openchargealliance.org/my-oca/ocpp/
- · Open Charge Alliance. (2015). OCPP-J 1.6 Specification, §4.2.1 — CALL message format. https://openchargealliance.org/my-oca/ocpp/
- · Open Charge Alliance. (2020). Open Charge Point Protocol 2.0.1, §4.3.1 — BootNotificationRequest. https://openchargealliance.org/my-oca/ocpp/