Charger Connection Lifecycle

Chargers maintain persistent WebSocket connections to the CSMS. This page covers the connection lifecycle from power-on to steady-state operation.

Connection Establishment

1. WebSocket Handshake

The charger initiates a WebSocket connection to the CSMS endpoint:

wss://csms.example.com/ocpp/{chargePointId}

The final path segment (CP001, CHARGER_A, etc.) identifies the charger.

The CSMS validates:

• TLS certificate (mutual TLS if configured)
• Charger identity (path segment matches known charger)
• Protocol version (via WebSocket subprotocol header)

2. Boot Notification

Immediately after connecting, the charger sends BootNotification:

BootNotification contains:

• chargePointVendor - manufacturer name
• chargePointModel - model identifier
• chargePointSerialNumber - unique hardware ID
• firmwareVersion - current firmware
• iccid / imsi - cellular identifiers (if applicable)

CSMS response status:

Status	Meaning
Accepted	Charger is registered and ready
Pending	Known charger, awaiting manual approval
Rejected	Unknown or blocked charger

If Pending or Rejected, the charger must retry after interval seconds.

3. Connector Status Sync

After boot acceptance, the charger reports the status of each connector:

This ensures the CSMS has current state after any power cycle or reconnection.

Steady-State Operation

Heartbeat

The charger sends periodic heartbeats to confirm connectivity:

The heartbeatInterval is set in the BootNotification response. Typical values: 30-300 seconds.

If the CSMS doesn't receive a heartbeat within the expected window, it marks the charger as offline.

Status Changes

The charger reports significant state changes as they occur:

Connector statuses:

Status	Meaning
Available	Ready for use
Preparing	Cable connected, waiting for auth
Charging	Energy transfer active
SuspendedEV	EV paused charging
SuspendedEVSE	Charger paused charging
Finishing	Charging complete, cable still connected
Reserved	Reserved for specific user
Unavailable	Out of service
Faulted	Error condition

Connection Loss & Recovery

Offline Behavior

When the WebSocket connection drops:

1. Charger continues operating - ongoing transactions continue
2. Messages are queued - transaction events stored locally
3. Reconnection attempts - exponential backoff or fixed intervals

Reconnection

When connection is restored:

Important: Queued transaction messages are delivered in chronological order. The CSMS must handle potentially large backlogs after extended outages.

Duplicate Message Handling

Due to network issues, the CSMS may receive duplicate messages. Handle idempotently:

• StartTransaction with same timestamp + connectorId + meterStart = same transaction
• MeterValues with same transactionId + timestamp = deduplicate
• StopTransaction with same transactionId = already stopped

Connection Security

TLS Requirements

• Minimum TLS 1.2
• Valid certificates (not self-signed in production)
• Optional: mutual TLS for charger authentication

Charger Identity

Chargers are identified by:

1. Charge Point ID - configured in charger, sent in WebSocket path
2. Serial Number - hardware identifier in BootNotification
3. Client Certificate - if using mutual TLS

Authorization

OCPP 1.6 has no built-in connection authentication. Common approaches:

Method	Description
Path-based registration	Only known charger IDs accepted
HTTP Basic Auth	Password in WebSocket upgrade headers
Mutual TLS	Client certificate required
Security Profile 3	TLS + Basic Auth (OCPP 1.6 security spec)

Ping/Pong

WebSocket provides transport-level keepalive via Ping/Pong frames. This is separate from OCPP Heartbeat:

• Ping/Pong: Transport-level, detects dead connections quickly
• Heartbeat: Application-level, confirms OCPP layer is responsive

Both should be implemented for robust connection management.

Configuration Sync

After boot, the CSMS may retrieve or update charger configuration:

This ensures settings like HeartbeatInterval, MeterValueSampleInterval, and authorization modes are correctly configured.