If a charger reaches the backend but never appears usable, the fault is almost always in the first few messages of the session rather than anywhere later. BootNotification and heartbeat are where a connection either establishes a working relationship or quietly fails to.
The reason these problems are hard to diagnose is that both sides usually report success. The charger says it sent BootNotification. The platform says it accepted a connection. Neither is lying, and the charger is still unusable.
What BootNotification actually establishes
BootNotification is the charger introducing itself. It sends its identity and hardware details, and the central system replies with a status, the current time, and an interval telling the charger how often to send heartbeats.
That reply matters more than the request. The status determines whether the charger is accepted, told to wait, or rejected outright, and each of those produces very different behaviour afterwards.
The three responses and what they mean
A charger stuck in Pending is the most commonly misdiagnosed case. Everything looks connected, no errors appear, and the unit will not start a session, because from the platform's point of view it has not finished being commissioned.
- Accepted: the charger is registered and may begin normal operation, including transactions.
- Pending: the central system knows the charger but is not ready to authorise it, usually because configuration or provisioning is incomplete. The charger should wait and retry rather than proceed.
- Rejected: the central system will not accept this charger. It should retry only after the interval it was given.
Identity mismatch is the most common cause
The charge point identity the unit sends must match what the platform expects, exactly. A trailing space, a case difference, or a serial number entered from the label rather than from the firmware will all produce a connection that establishes at the transport layer and fails at the application layer.
This is worth checking first because it is quick to rule out and it accounts for a large share of commissioning failures. Read the identity from the charger's own configuration rather than from the sticker.
Heartbeat is a liveness check, not a keepalive
The heartbeat interval returned in the BootNotification response tells the charger how often to check in. Its purpose is to let the platform know the charger is still there, and to keep the charger's clock aligned with the platform's.
Two failure modes follow from that. If the interval is longer than the network's idle timeout, the connection drops between heartbeats and the charger appears to flap. If the charger ignores the interval it was given and uses its own, the platform may mark it offline while it believes itself connected.
Reconnect loops
A charger reconnecting every few seconds is usually being rejected somewhere it cannot report. Common causes are a WebSocket upgrade that fails after the TCP connection succeeds, a subprotocol mismatch where the two sides cannot agree on the OCPP version, or a certificate problem on a secured connection.
Look at the transport layer before the application layer here. A charger that never gets far enough to send BootNotification will produce no OCPP evidence at all, which is itself the diagnostic signal.
Clock divergence
The BootNotification response carries the central system's time, and chargers use it to set their own. Where a charger does not apply it, or applies it and then drifts, transaction timestamps stop agreeing between the two sides.
This rarely prevents charging. It quietly corrupts billing reconciliation instead, which is worse, because it is discovered at month end rather than at commissioning.
A working order to debug in
Each step makes the next one meaningful. Debugging out of order produces the familiar situation where both parties have evidence their side is fine.
- Confirm the charger reaches the backend at the transport layer at all.
- Confirm the WebSocket upgrade completes and both sides agreed an OCPP subprotocol.
- Capture the BootNotification request and read the identity it actually sent.
- Read the response status. Pending and Rejected are answers, not errors.
- Confirm the charger adopted the heartbeat interval it was given.
- Compare the charger's clock to the platform's after boot.
When it is not the charger
Platforms differ in what they require at boot. Some expect configuration keys the charger does not send. Some reject identities that are valid but not pre-registered. A charger that works against one backend and fails against another has not necessarily changed.
This is the practical difference between protocol compliance and interoperability, and it is why integration is verified against the specific platform and version you intend to run.