DRAFT — not indexed by search engines. Visible only via direct URL or the admin page.

Free OCPP Simulators & Charge Point Emulators (2026 Guide)

An honest, verified rundown of free OCPP simulators and charge-point emulators — SteVe, CitrineOS, EVerest, MicroOcpp — and which one fits your test.

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 where a zero-setup browser tool fits.

If you just want to connect a virtual charging station to a real back-end and watch the frames move, the fastest path is Rey, the free browser-based virtual charge point. It opens a genuine OCPP WebSocket — 1.6, 2.0.1, or 2.1 — to your CSMS, or drives a full session against a built-in demo CSMS — no install, no account. More on where it fits below.

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, and TransactionEvent at your back-end. Rey, MicroOcpp, EVerest, and the Solidstudio virtual charge point 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 (coming soon) 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 fact below was checked against each project’s own repository and, where applicable, the Open Charge Alliance. Versions and status change, so re-check before you commit — but this is where things stand in 2026.

ToolWhat it stands in forOCPP versionsLicenseMaintained by
SteVeCSMS (server)1.2 / 1.5 / 1.6J onlyGPLsteve-community (originated at RWTH Aachen, Germany, 2013)
CitrineOSCSMS (server)2.0.1 (OCA-certified Core + Advanced Security)Apache 2.0LF Energy project, initiated by S44 (North America)
EVerestFull charger stack (station side, via libocpp)1.6 / 2.0.1 / 2.1Apache 2.0LF Energy project, initiated by PIONIX (Germany)
MicroOcppCharge-point client for microcontrollers1.6 mature; 2.0.1 alpha (off by default)MITmatth-x
ReyBrowser virtual charge point + built-in demo CSMS1.6 / 2.0.1 / 2.1Open source/tools/virtual-charge-point/

A few things worth spelling out, because the table compresses them.

SteVe is the veteran — a Java OCPP server running since 2013, widely used by CPOs and manufacturers, with a full implementation of the OCPP 1.6 security profiles (unsecured, Basic Auth, TLS, and mTLS). What it does not do is OCPP 2.0.1; a long-standing request for 2.0.1 support remains unimplemented. If your fleet is 1.6 — still the largest installed base in both North America and Europe — SteVe is a reasonable free back-end to point emulated 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, initiated by the North American firm S44 and now an LF Energy project. It has passed Open Charge Alliance certification for the Core and Advanced Security profiles, which is a meaningfully stronger claim than “we implemented the messages.” Its architecture is modular — separate pieces for core, smart charging, ISO 15118 support, reservations, and local auth lists — which makes it a realistic target to test firmware against.

EVerest is a different animal. It is a full EV-charging software stack — the station side, not the back-end — under Apache 2.0, hosted by LF Energy and initiated by PIONIX. 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 shines 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 — ESP32, ESP8266, and similar. Its OCPP 1.6 support is mature and production-ready across all feature profiles; its 2.0.1 support is explicitly alpha, disabled by default, and enabled with a build flag (MO_ENABLE_V201=1). It is the right tool when you are writing actual charger firmware, not when you want to click through a session quickly.

Where a browser virtual charge point fits

The projects above are powerful and, for real product work, often the right choice. But every one of them asks you to install something, stand up a runtime, or flash a board before you see a single frame. That friction is exactly what stops people from testing early.

Rey is the zero-setup option in the charge-point-emulator column. It is a free, browser-based virtual OCPP 2.0.1 charge point — you drive it in a tab and watch every OCPP-J frame move. It runs in two modes:

  • Explore — a built-in demo CSMS runs on the server, so you can play a complete session (BootNotificationAuthorizeTransactionEvent Started/Updated/Ended) and inspect each frame with no back-end of your own. This is the fastest way to see how OCPP behaves live rather than on a diagram.
  • Connect my CSMS — enter your own CSMS’s wss:// URL, a station id, and a Basic-auth password if it needs one, and Rey opens a real OCPP connection to your back-end. A relay presents the auth headers a browser cannot set itself, so you get a genuine round trip against your CSMS — before any hardware is on site.

That second mode is the point. You can smoke-test the boot handshake (does your CSMS return Accepted and hand back a heartbeat interval?), fire CSMS-initiated commands like RequestStartTransaction, Reset, TriggerMessage, or GetVariables and watch the station respond, and confirm your transaction accounting — all without leaving the browser. It is not a replacement for EVerest-grade testing or on-device firmware validation; it is the thing you reach for first, and often the thing that catches the obvious integration bugs cheapest.

A sensible workflow across the tools

You do not have to choose one. The productive pattern combines them by stage:

  1. Learn the sequence in a flow visualiser first. Step through the canned OCPP simulator until you can predict the next frame before it appears. Understanding the conversation is where most integration time is actually won.
  2. Exercise your CSMS live with a browser emulator. Point Rey at your 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.
  3. Harden against realistic firmware with EVerest or MicroOcpp when you need production-grade station behaviour, security profiles, or ISO 15118. And if you are on the firmware side, point MicroOcpp or EVerest at a free CSMS — SteVe for 1.6, CitrineOS for 2.0.1.
  4. Test the back-end at scale 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 is the same shape — which is precisely why a single emulator can stand in for hardware from any vendor.

Start here

If you are testing a back-end, open Rey, switch to Connect my CSMS, and put your first BootNotification on the wire in the next five minutes. If you are still building the mental model, run the interactive OCPP simulator first, then come back and drive a live one. The tools are free; the only expensive thing in OCPP integration is discovering a sequence bug in production instead of in a browser tab.

Frequently asked questions

What is the difference between an OCPP simulator and a charge-point emulator?

In practice the terms overlap, but the useful distinction is which side of the link the tool stands in for. A charge-point emulator behaves like a physical charging station so you can point your CSMS at it. A demo or reference CSMS behaves like a back-end so you can point real charger firmware at it. A learning simulator replays a canned message flow so you can study the sequence without connecting anything. Pick the one that matches the side you are testing.

Is there a free OCPP simulator that runs in the browser?

Yes. Rey is a free, browser-based virtual charge point at /tools/virtual-charge-point/. It opens a real OCPP WebSocket — OCPP 1.6, 2.0.1, or 2.1 — to your own CSMS over wss://, or drives a full session against a built-in demo CSMS with no backend of your own. There is nothing to install and no account to create.

Does SteVe support OCPP 2.0.1?

No. As of 2026 SteVe supports OCPP 1.2, 1.5, and 1.6J, including the 1.6 security profiles, but not OCPP 2.0.1. If you need a free open-source 2.0.1 CSMS, CitrineOS is the closest equivalent — it is OCPP 2.0.1 focused and has passed Open Charge Alliance certification for Core and Advanced Security.

Can I test my CSMS without buying a physical charger?

Yes, and it is the standard way integration teams de-risk a deployment. A charge-point emulator such as Rey, MicroOcpp firmware on a dev board, or an EVerest instance produces the same OCPP traffic a real station would, so you can validate boot, authorize, transactions, and command-and-control against your back-end long before hardware ships.

Found this useful? Share it.