OCPP runs over WebSocket. This is not an implementation detail — it is a core part of the protocol. Understanding how the WebSocket layer works helps CSMS developers debug connection issues, write correct reconnect handling, and understand why simulators behave the way they do.

The connection URL

A charging station connects to the CSMS by opening a WebSocket connection to a URL that includes the station's identity. The typical format is:

ws://csms.example.com/ocpp/CHARGE-POINT-001

The charge point identity (CP ID) is part of the URL path, not a header or payload field. This is how the CSMS knows which station is connecting before any OCPP messages are exchanged. If the CP ID contains spaces or special characters, they must be percent-encoded. A missing or malformed CP ID is one of the most common causes of 400 errors during CSMS development.

The subprotocol header

During the WebSocket handshake, the client sends a Sec-WebSocket-Protocol header declaring which OCPP version it speaks — either ocpp1.6 or ocpp2.0.1. The CSMS must echo this header in its response. If the header is missing or mismatched, the client must close the connection immediately. Many connection failures in early CSMS development trace back to this header being omitted.

Message format

All OCPP messages are JSON arrays sent over the WebSocket text channel. There are three types:

The unique ID is a string chosen by the sender. The responder echoes it back so the sender can match the response to its original request. OCPP requires that only one outstanding CALL exist per direction at a time — the sender must wait for a response before sending the next request.

Reconnect behaviour

Real chargers lose connectivity. The OCPP specification requires a station to reconnect after a disconnection, using a back-off interval to avoid overwhelming the CSMS during network outages. Your CSMS must handle reconnects correctly: resuming in-progress transactions, restoring configuration state, and not creating duplicate sessions. Reconnect handling is one of the hardest parts of CSMS development to test with real hardware — it requires being able to drop and restore a connection at will.

SimIt gives you full control over the WebSocket lifecycle. Disconnect a station, trigger a reconnect with configurable timing, or simulate a power loss that drops all active connections — all via REST API.

Try SimIt free — no installation or infrastructure needed.