OCPP 2.0.1 Simulator
OCPP is a conversation between a charging station and a CSMS. Pick a scenario and watch the actual OCPP-J frames go by — request, reply, and the occasional error — one message at a time, each explained.
How to read an OCPP message
OCPP 2.0.1 runs as JSON over a WebSocket (the ocpp2.0.1
subprotocol). Every message is a JSON array — not an
object — of one of three shapes:
- CALL
[2, "<id>", "<Action>", {…}]— a request. Either side can send one. - CALLRESULT
[3, "<id>", {…}]— a success reply, carrying the same unique id as its CALL. - CALLERROR
[4, "<id>", "<errorCode>", "<description>", {}]— a failure reply.
That reused message id is the whole correlation mechanism: a reply is matched to its request by id, not by order. Parse a message as an object, or mint a fresh id for the reply, and you break it.
What each scenario shows
- Boot & first heartbeat — a station comes online, registers, reports its connector, and starts its heartbeat.
- RFID charging session — the whole session lifecycle through one message:
TransactionEventwitheventTypeStarted, Updated, then Ended. - Remote start — the CSMS as the client, asking the station to begin (the reverse direction).
- Smart charging — a
SetChargingProfilethat shapes power over time. - Plug & Charge — ISO 15118 certificate authorization surfacing over OCPP, with no card or app.
- CALLERROR — what a protocol-level failure actually looks like on the wire.
Want the full reference — the device model, security profiles, and the traps that reach production? Read What is OCPP, see how the layers fit in OCPP vs OCPI vs ISO 15118, or browse every OCPP guide. When you are ready to see the roaming side, try the OCPI 2.2.1 simulator.
This is a teaching aid: the flows are canned, accurate sample messages, not a live connection to any charging station. It runs entirely in your browser.
Frequently asked questions
What is an OCPP simulator?
An OCPP simulator stands in for a charging station or a CSMS and reproduces the OCPP messages they exchange, so you can learn or test the protocol without physical hardware. This one plays an accurate OCPP 2.0.1 (OCPP-J) conversation step by step so you can inspect every frame.
Are these real OCPP 2.0.1 messages?
Yes. Every frame matches the OCPP 2.0.1 (OCPP-J over WebSocket) specification — the CALL/CALLRESULT/CALLERROR array framing, the field names, and the enum values are all spec-accurate. Timestamps and ids are sample values.
What do CALL, CALLRESULT, and CALLERROR mean?
They are the three OCPP-J message types. A CALL (2) is a request; a CALLRESULT (3) is a success reply carrying the same unique id; a CALLERROR (4) is a failure reply. The reused id is how a reply is matched to its request.
Can I use this to test my own CSMS?
This simulator plays accurate, canned flows for learning; it does not open a live WebSocket to your backend. For that, use Rey — a free virtual charge point that connects to your CSMS over wss:// and runs a real OCPP session against it, in the browser. See the Virtual Charge Point tool at /tools/virtual-charge-point/.
Does it cover OCPP 1.6?
It models OCPP 2.0.1, which unifies start, meter, and stop into one TransactionEvent message. Many concepts — the WebSocket transport, request/response pairing, the boot-then-heartbeat lifecycle — carry back to 1.6, but the payload shapes differ, so always test against the version your firmware speaks.