There is no single best OCPP simulator. There is the one that matches which side of the charging link you are trying to test, and most of the frustration people feel with these tools comes from reaching for the wrong category. This guide sorts the free, open options honestly, verifies what each actually does today, and shows you which one belongs at which stage of a project.
First, decide which side you are testing
OCPP is the protocol between a charging station and a CSMS (Charging Station Management System). Every tool in this space stands in for one side of that link, and the single most useful question to ask before you download anything is: which side do I already have, and which side am I faking?
- You have a CSMS and need a station. You want a charge-point emulator: software that behaves like a physical charger, opens the WebSocket, and sends
BootNotification,Authorize, andTransactionEventat your back-end. MicroOcpp and EVerest live here. - You have charger firmware and need a back-end. You want a demo or reference CSMS to point your firmware at. SteVe and CitrineOS live here.
- You have neither and just want to learn the sequence. You want a flow visualiser that replays a canned conversation so you can read every frame. Our interactive OCPP simulator is this kind, and the companion piece on testing without hardware covers the workflow.
Get this wrong and you will spend an afternoon fighting a server when what you needed was a client. If the protocol itself is still fuzzy, start with what is OCPP and come back.
The honest comparison
Every claim below was checked against each project’s own repository in August 2026. Open-source projects move, so treat this as a starting point and re-check the repo before you commit to one.
| Tool | What it stands in for | OCPP versions | License | Maintained by |
|---|---|---|---|---|
| SteVe | CSMS (server) | 1.2 / 1.5 / 1.6J only | GPL | steve-community |
| CitrineOS | CSMS (server) | 2.0.1 focused | Apache 2.0 | LF Energy project |
| EVerest | Full charger stack (station side, via libocpp) | 1.6 / 2.0.1 / 2.1 | Apache 2.0 | LF Energy project |
| MicroOcpp | Charge-point client for microcontrollers | 1.6 mature; 2.0.1 experimental | MIT | matth-x |
A few things worth spelling out, because the table compresses them.
SteVe is the veteran, a Java OCPP server that has been running since 2013 and implements the OCPP 1.6 security profiles: unsecured, Basic Auth, TLS, and mTLS. What it does not do is OCPP 2.0.1, and a long-standing request for it remains unimplemented. Since 1.6 is what most fielded hardware was commissioned against, SteVe is a perfectly reasonable free back-end to point emulated 1.6 chargers at. If you are building for 2.0.1, look elsewhere.
CitrineOS is the open answer to that gap: an Apache-2.0 CSMS built specifically around OCPP 2.0.1, now an LF Energy project. Its architecture is modular, with separate pieces for core, smart charging, ISO 15118 support, reservations, and local auth lists, which makes it a realistic target to test firmware against. If certification matters to your procurement process, check the Open Charge Alliance’s certified-products register directly rather than trusting any secondary description, including this one. Certification status is exactly the kind of fact that changes without anyone updating a blog post.
EVerest is a different animal. It is a full EV-charging software stack for the station side rather than the back-end, under Apache 2.0 and hosted by LF Energy. Its libocpp component is a C++ implementation covering OCPP 1.6, 2.0.1, and 2.1. You can run EVerest as a very realistic charge-point emulator, but it is heavier to stand up than a browser tab. It earns that cost when you want production-grade station behaviour, ISO 15118 Plug and Charge, and hardware-in-the-loop testing.
MicroOcpp, formerly ArduinoOcpp, is a portable C/C++ OCPP client aimed at microcontrollers such as the ESP32. Its OCPP 1.6 support is the mature path; its 2.0.1 support is experimental and gated behind a build flag rather than on by default. It is the right tool when you are writing actual charger firmware, and the wrong one when you want to click through a session quickly.
What none of them will do for you
A gap worth naming, because it catches teams repeatedly: none of these tools tells you whether your sequence is right. They will each happily let you send a StopTransaction for a transaction that was never started, or a MeterValues referencing an unknown transactionId, because those are legal frames in isolation.
Sequence errors are the expensive class of OCPP bug, and they survive every test that checks one message at a time. The full session message flow is the reference to diff your own traffic against, and common OCPP errors explained catalogues the failures that recur.
A sensible workflow across the tools
You do not have to choose one. The productive pattern combines them by stage:
- Learn the sequence in a flow visualiser first. Step through the OCPP simulator until you can predict the next frame before it appears. Understanding the conversation is where most integration time is actually won.
- Exercise your CSMS live with an emulator pointed at your own
wss://endpoint, and confirm boot, authorize, a full transaction, and the command-and-control path all behave. This catches sequence and payload mistakes in minutes rather than in a pilot. - Harden against realistic firmware with EVerest or MicroOcpp when you need production-grade station behaviour, security profiles, or ISO 15118. If you are on the firmware side, point MicroOcpp or EVerest at a free CSMS instead: SteVe for 1.6, CitrineOS for 2.0.1.
- Test the back-end under load once single-session behaviour is solid, using whichever CSMS matches your target version.
None of this is region-specific. Whether you are a North American workplace-and-fleet operator, a European public CPO, or a manufacturer shipping to both, the OCPP conversation has the same shape, which is precisely why one emulator can stand in for hardware from any vendor.
Start here
If you are still building the mental model, run the interactive OCPP simulator first and watch a full session move. If you already have a back-end, get a BootNotification onto the wire against it today rather than next sprint.
The tools on this page are all free. The only expensive thing in OCPP integration is discovering a sequence bug in production instead of in a browser tab, and every hour spent in a simulator is an hour not spent reading logs from a charger in a car park in the rain.