BootNotification

Core CS->CSMS OCPP 2.0.1

Sent by the Charging Station to notify the CSMS that it has booted and is ready to accept messages. Includes a reason for booting and a structured ChargingStation object.

Quick Reference

Required Fields

reason BootReasonEnumType

Reason for sending this notification (PowerUp, FirmwareUpdate, LocalReset, RemoteReset, ScheduledReset, Watchdog, etc.)

chargingStation ChargingStationType

Object identifying the Charging Station - must include model and vendorName

chargingStation.model string(20)

Model name of the Charging Station

chargingStation.vendorName string(50)

Vendor name of the Charging Station

Optional Fields

chargingStation.serialNumber string(25)

Vendor-specific serial number of the Charging Station

chargingStation.firmwareVersion string(50)

Firmware version of the Charging Station

chargingStation.modem ModemType

Modem object with iccid and imsi fields

Example Payload

{
  "reason": "PowerUp",
  "chargingStation": {
    "model": "SuperCharger Pro",
    "vendorName": "VendorX",
    "firmwareVersion": "v2.0.1",
    "serialNumber": "SN-12345",
    "modem": {
      "iccid": "89123456789012345678",
      "imsi": "310260000000000"
    }
  }
}

Example Full Frame

[
  2,
  "msg-001",
  "BootNotification",
  {
    "reason": "PowerUp",
    "chargingStation": {
      "model": "SuperCharger Pro",
      "vendorName": "VendorX",
      "firmwareVersion": "v2.0.1",
      "serialNumber": "SN-12345",
      "modem": {
        "iccid": "89123456789012345678",
        "imsi": "310260000000000"
      }
    }
  }
]

Format: [MessageType, MessageId, Action, Payload]

Open in Builder Go to Validator

Overview

The BootNotification message is the first message a Charging Station sends after connecting to the CSMS. It provides identification and status information and establishes the heartbeat interval.

When to Send

After establishing a WebSocket connection to the CSMS
After a firmware update completes
After a factory or local reset
When triggered by the CSMS via a Reset or TriggerMessage command
After a watchdog reset (use reason: "Watchdog")

Expected Response

The CSMS responds with:

status: Accepted, Pending, or Rejected
currentTime: ISO 8601 timestamp for clock synchronization
interval: Heartbeat interval in seconds

Key Differences from OCPP 1.6J

The most important structural change in OCPP 2.0.1 is that the boot payload uses a nested object instead of flat fields:

OCPP 1.6J	OCPP 2.0.1
`chargePointVendor` (string)	`chargingStation.vendorName` (string, max 50)
`chargePointModel` (string, max 20)	`chargingStation.model` (string, max 20)
`chargePointSerialNumber`	`chargingStation.serialNumber`
`firmwareVersion` (flat)	`chargingStation.firmwareVersion`
No `reason` field	`reason` required (enum)

Usage Notes

The Charging Station MUST NOT send any other request until it receives a BootNotification response with status: Accepted
If status is Pending, send Heartbeats at the given interval and retry BootNotification when the CSMS indicates readiness
If status is Rejected, the Charging Station should wait before retrying

Best Practices

Always provide reason - Use the most accurate enum value to help operators diagnose unexpected reboots
Include firmwareVersion - Critical for remote diagnostics and firmware management
Use the returned interval - Set your heartbeat timer to the value returned in the response
Clock synchronization - Use currentTime in the response to sync the Charging Station clock

Testing Tips

Test with minimal payload (reason + chargingStation.model + chargingStation.vendorName) to verify basic acceptance
Verify the Pending flow: the CSMS may respond Pending when provisioning is incomplete
Test that the Charging Station waits for Accepted before sending other messages

Common Errors

`PropertyConstraintViolation`

Cause: chargingStation.model exceeds 20 characters

Solution: Ensure model name is max 20 characters

`PropertyConstraintViolation`

Cause: chargingStation.vendorName exceeds 50 characters

Solution: Ensure vendor name is max 50 characters (note: 1.6J was 20 chars)

`TypeConstraintViolation`

Cause: reason field contains a value not in BootReasonEnumType

Solution: Use one of: ApplicationReset, FirmwareUpdate, LocalReset, PowerUp, RemoteReset, ScheduledReset, Triggered, Unknown, Watchdog

`FormationViolation`

Cause: chargingStation sent as flat fields instead of an object

Solution: In OCPP 2.0.1, chargingStation is a nested object - not flat fields like chargePointVendor/chargePointModel

Related Actions

Heartbeat StatusNotification Reset