OCPP test tool

An OCPP test tool lets a CSMS or CPMS team send real framed messages to their backend without waiting on a physical charge point. Think of it as Postman for a WebSocket protocol: you exercise the contract your server must accept, with a station identity and connector states, instead of a one-off script that only the person who wrote it can rerun.

Chargeflux is that tool in the browser. The cloud runtime opens the OCPP WebSocket; you drive an EVSE simulator (virtual charge point) for OCPP 1.6 and OCPP 2.0.1. It is for development and QA, not an OCA certificate harness.

Launch the OCPP test tool · Getting started · OCPP compliance testing

What an OCPP test tool is (and is not)

Search results mix four different jobs under one phrase. Pick the row that matches the question you actually have, or you will book a lab for a bug a message console would have shown in minutes.

Broader layering (electrical vs firmware vs protocol): EV charger testing. Protocol primer: what is OCPP. QA vs certificate: OCPP compliance testing.

Who this OCPP test tool is for

• CPO engineering teams building or customising a CSMS
• Integrators connecting a third-party CPMS before station firmware is on the bench
• QA engineers who need a repeatable Boot → transaction → MeterValues path
• Backend developers who cannot monopolise a shared hardware EVSE

What you can prove without hardware

1. Connection and identity — WebSocket URL, station identity, subprotocol (ocpp1.6 / OCPP 2.0.1), TLS. Guide: connect your CSMS.
2. BootNotification acceptance — registration status, heartbeat interval, and how your CSMS labels unknown vs accepted stations. Sample frames: OCPP 1.6J sample messages.
3. Session lifecycle — Authorize, StartTransaction / TransactionEvent, MeterValues, StopTransaction with connector states you can set from the UI.
4. CSMS → station commands — RemoteStart/Stop or RequestStart, and availability where the version guide lists them. Reset is acknowledgement-only here: the station returns Accepted and does not reboot, reconnect, or send a follow-up BootNotification. Configuration reads (GetConfiguration) are OCPP 1.6-only; OCPP 2.0.1 GetVariables is not implemented yet.
5. Operator debugging — message console with correlated request/response pairs you can export for tickets. Failure paths: WebSocket troubleshooting.

OCPP test tool vs scripts vs a hardware lab

Use more than one. They fail in different places. A hosted OCPP test tool is the daily driver; scripts help when the case must live in your pipeline image; hardware is the gate before production, not the place to discover a rejected BootNotification.

• Hosted tool — shared station identity, readable console, no local install. Best when product, QA, and a remote integrator need the same session.
• Scripts — full control and custom edge cases. Cost is setup time and log files nobody else can read.
• Physical EVSE — cable, meter, vendor firmware, field network. Keep a pilot station. Do not block every backend change on it.

Chargeflux is not a load generator for hundreds of stations on the free tier (up to two concurrent hosted stations). Fleet-scale load testing is a different product job.

Recommended first path (30 minutes)

1. Open getting started and create a virtual station. Demo Mode explores a sample session without an account; a real CSMS connection uses free magic-link sign-in.
2. Point the station at a non-production CSMS URL (connect your CSMS).
3. Confirm BootNotification is accepted and Heartbeat continues on the interval your backend set.
4. Run one local start and one remote start; watch MeterValues land on the backend.
5. Force a disconnect / reconnect and confirm your CSMS recovers station state.

Repeat on the version you claim: OCPP 1.6 simulator and, if you advertise it, OCPP 2.0.1 simulator. API control for CI is on Pro — see the API.

FAQ

Ready to try it? Start a virtual station or open the simulator after sign-in.

Last reviewed September 2026 · Chargeflux.io