OCPP runs over WebSocket, and that shapes everything above it. 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 a frequent cause of 400 errors during CSMS development.

If you are using SimItNow, do not include the CP ID in the URL yourself. SimItNow appends it as the final path segment automatically, exactly as shown above, so pass only the base URL (ws://csms.example.com/ocpp) as csmsUrl. Adding the CP ID to csmsUrl as well produces a duplicated path segment (.../CHARGE-POINT-001/CHARGE-POINT-001) in the real connection URL, and many CSMS implementations reject that as a protocol error immediately after the WebSocket upgrade rather than with a clear 404.

The subprotocol header

During the WebSocket handshake, the client sends a Sec-WebSocket-Protocol header declaring which OCPP version it speaks, one of ocpp1.6, ocpp2.0.1 or ocpp2.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 allows only one outstanding CALL per direction at a time, so 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. Testing this with real hardware is awkward, because it means dropping and restoring a connection on demand.

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

Try SimItNow free, with no installation or infrastructure to set up.