OCPP Simulator: Test Charge Point Messages Online (Free)

If you have ever tried to learn OCPP by reading the specification, you already know the problem: the spec describes messages in isolation, but a real charging session is a conversation — a specific sequence of requests and responses moving in both directions over a WebSocket. The fastest way to actually understand it is to watch that conversation happen. That is what an OCPP simulator is for, and you can try the interactive OCPP simulator right now, free, with nothing to install.

This article explains what an OCPP simulator does, how to read the message flow it produces, and where a browser-based walkthrough ends and a full send-your-own-messages test harness begins. If you are brand new to the protocol, start with what is OCPP for the big picture, then come back here for the hands-on view.

What an OCPP simulator actually simulates

OCPP is the protocol between a charging station and its back-end, the CSMS (Charging Station Management System). A simulator stands in for one side of that link so you can test the other — or, in a teaching tool, it plays both sides so you can watch the whole exchange.

There are two broad kinds of OCPP simulator, and it helps to know which you need:

• A flow visualiser. It replays a realistic OCPP conversation step by step and lets you inspect every frame. You are not connecting real hardware; you are learning the sequence, the field names, and the timing. This is the fastest way to build an accurate mental model. Our OCPP 2.0.1 simulator is this kind.
• A live endpoint. It opens an actual WebSocket and either behaves like a charging station (so you can point your CSMS at it) or behaves like a CSMS (so you can point real firmware at it). This is what integration and QA teams use to test their own code against realistic counterpart behaviour.

Both matter. You use the visualiser to understand the protocol; you use a live endpoint to test your implementation of it. Most people underestimate how much of the work the first kind saves — a huge share of OCPP integration bugs come from misunderstanding the sequence, not from a broken socket.

Reading the message flow

OCPP 2.0.1 runs as JSON over a WebSocket, a variant usually called OCPP-J. Every message on the wire is a small JSON array, and the first element is a number that tells you the message type:

• 2 — a Call (a request)
• 3 — a CallResult (a successful response)
• 4 — a CallError (something went wrong)

So a BootNotification request looks roughly like [2, "unique-id", "BootNotification", { ...payload... }], and the CSMS answers with [3, "unique-id", { ...payload... }]. The unique-id ties the response back to its request — essential, because multiple messages can be in flight at once. Once you have seen this a few times in the simulator, OCPP stops being abstract; you can read it straight off a browser’s network tab in production.

The canonical opening sequence of a session goes like this:

1. The station opens the WebSocket and immediately sends BootNotification to identify itself. The CSMS replies Accepted, Pending, or Rejected. Nothing else happens until this succeeds — see the BootNotification message ^{(coming soon)} for the full field breakdown and failure modes.
2. The station begins sending Heartbeat at the interval the CSMS handed back, and a StatusNotification for each connector so the backend knows what is available.
3. When a driver plugs in and presents a token, the station sends Authorize, and the CSMS decides whether that token may charge.
4. The session itself is carried by TransactionEvent messages — Started, then periodic Updated frames with meter readings, then Ended. In 1.6 this was split across StartTransaction, MeterValues, and StopTransaction; 2.0.1 unified them. The details are in the TransactionEvent message ^{(coming soon)}.

Watching those four stages play out frame by frame is the single most useful thing you can do to internalise OCPP, and it is exactly what the interactive tool steps you through.

Both directions matter

A common misconception is that the charging station does all the talking. It does not. OCPP is bidirectional: the CSMS can initiate messages too. A remote start is the clearest example — the operator’s backend, acting as the client of the exchange, tells the station to begin a transaction on a driver’s behalf (think of starting a session from a mobile app). The station then runs the same TransactionEvent flow it would for a local plug-in.

Other CSMS-initiated commands include configuration changes, resets, firmware updates, and smart-charging profiles that cap or shape the power a station may deliver. A good simulator lets you see these reverse-direction flows, because they are where a lot of real integrations get tripped up — teams build the station-to-CSMS path cleanly and then discover the command-and-control path behaves differently.

This is not a European-versus-North-American distinction, by the way. Whether you operate a public network like a large CPO in Germany or a workplace-and-fleet platform such as EV Connect in the United States, the OCPP conversation is the same shape. The protocol is deliberately vendor- and region-neutral, which is precisely why a single simulator can stand in for hardware from any manufacturer and back-end logic from any operator. What differs between deployments is which optional features a given station and CSMS choose to support — smart charging, ISO 15118 Plug and Charge, local authorisation lists — not the core message grammar.

From walkthrough to testing your own messages

Once the flow makes sense, the natural next step is to test your own code. Here is how the visualiser fits into a real workflow:

• Learn the sequence in the interactive simulator until you can predict the next frame before it appears.
• Diff against your logs. Pull the OCPP traffic from your own charger or backend and compare it, message by message, to the reference flow. Discrepancies jump out fast when you know what should be there.
• Test edge behaviour. What does your CSMS do when BootNotification returns Pending? When an Authorize is rejected? When a TransactionEvent arrives out of order after a reconnect? These are the cases that cause production incidents, and they are cheap to rehearse against a simulator.
• Move to a live endpoint when you need to exercise your actual socket, TLS, and reconnection logic — the parts a visual walkthrough deliberately abstracts away.

When something does go wrong on the wire, the failure is usually one of a small set of recurring patterns — a mismatched unique-id, a CallError the sender does not handle, a station stuck retrying BootNotification. We catalogue these in common OCPP errors explained ^{(coming soon)}, and every one of them is easier to recognise after you have watched the healthy flow first.

Try it

Reading about TransactionEvent frames is one thing; watching a Started event turn into a stream of metered Updated events and then an Ended is another. Open the free OCPP 2.0.1 simulator, pick a scenario, and step through it. Inspect each frame, note which side sent it, and watch how the unique-id links request to response. Fifteen minutes with the tool will teach you more about how OCPP behaves than an afternoon with the specification — and it costs nothing.