OCPP 1.6 simulator

An OCPP 1.6 simulator is a virtual charge point that speaks OCPP-J over WebSocket so you can test a CSMS (or CPMS) without booking a lab EVSE. Chargeflux runs that station in the cloud: browser UI, hosted runtime, charger presets, and a message console you can filter and export.

Most commercial backends still onboard fleets on OCPP 1.6J. If your product claims 1.6 support, you need a repeatable way to prove BootNotification acceptance, remote start/stop, meter values, and reconnect behaviour — not a one-off script that only works on your laptop.

Launch the OCPP 1.6 simulator · Getting started · Test CSMS without hardware

Who this OCPP 1.6 simulator is for

CSMS / CPMS engineers validating Core profile flows before a hardware slot is free
QA teams that need a stable virtual station ID and exportable session logs
CPO software teams comparing how an OCPP charge point simulator (virtual charge point) behaves versus a single physical EVSE

Prefer a full software-only checklist? See test CSMS without hardware. Layers (electrical vs firmware vs OCPP): EV charger testing. Need 2.0.1 as well? Use the OCPP 2.0.1 simulator on the same product.

Why teams pick a hosted OCPP 1.6 simulator

Searching for an OCPP 1.6 simulator usually means one of three jobs: prove Boot works against a real CSMS endpoint, reproduce a session bug with shared logs, or cover dual-stack CSMS code before the hardware bench is free. A hosted OCPP 1.6J path shortens that loop — public wss:// reachability from the cloud runtime, a UI product and QA can share, and a console that correlates CALL / CALLRESULT by unique ID.

What you can prove with an OCPP 1.6J simulator

Scenario	Why it matters	How Chargeflux helps
Station registration (`BootNotification`)	Wrong identity, model, or heartbeat handling blocks every later test	Connect → inspect call/result pair in the console with timing
Local and remote sessions	Authorization and RemoteStart paths often diverge in CSMS code	Drive connector states from the UI; correlate by unique ID
Metering during charge	Billing and session UIs break when MeterValues shape or cadence is wrong	Periodic MeterValues while Charging; export JSON after
Availability and reset	Ops tools depend on ChangeAvailability / Reset	Supported CSMS commands return real framed responses
WebSocket drops	Production chargers disconnect; CSMS must recover	Reproduce disconnects; see WebSocket troubleshooting

Supported outgoing actions (station → CSMS)

The OCPP 1.6 simulator sends the Core messages most CSMS teams exercise first on a ocpp1.6 subprotocol connection:

BootNotification
Heartbeat
StatusNotification
Authorize
StartTransaction
MeterValues
StopTransaction

Supported incoming CSMS commands

The simulator handles these commands from the CSMS where practical. Unsupported actions return a valid CALLERROR or a documented not-supported response:

RemoteStartTransaction and RemoteStopTransaction
Reset
ChangeAvailability
TriggerMessage
GetConfiguration and ChangeConfiguration
ClearCache

First useful path: BootNotification on OCPP 1.6J

Before any charging flow, register a station identity your CSMS already knows (or is willing to auto-provision). A typical OCPP 1.6J path looks like this:

Open the simulator and set protocol to OCPP 1.6
Paste a wss:// CSMS base or full URL (connect your CSMS)
Connect — the hosted runtime opens WebSocket with subprotocol ocpp1.6 and sends BootNotification
Confirm the result is Accepted, Pending, or Rejected and that heartbeat interval is applied when Accepted

Step-by-step UI walkthrough: getting started.

Charger presets

Presets reduce setup time. Each preset is fully editable after you select it:

Single AC Type 2 — 7.4 kW (one connector, single-phase)
Single AC Type 2 — 22 kW (one connector, three-phase)
Dual AC Type 2 — 22 kW (two connectors)
Single DC — 50 kW (one connector)

Connector state model

Each connector moves through a simplified state model that stays aligned with the OCPP messages the station emits:

Available -> Preparing -> Authorize -> StartTransaction
          -> Charging -> periodic MeterValues
          -> StopTransaction -> Finishing -> Available

The simulator prevents invalid actions: you cannot start an already active transaction, stop when no transaction exists, or charge on an unavailable or faulted connector. When an action is disabled, the UI explains why.

Message console (OCPP message inspector)

Every message is recorded with direction, timestamp, action, unique ID, request-response correlation, and timing where measurable. Expand a row for formatted JSON and a plain-language explanation; filter by action or direction; export the session as JSON or readable text. That makes the product a practical OCPP test tool for debugging payload shape issues, not only a connect button.

OCPP 1.6 simulator vs hardware lab vs ad-hoc scripts

Approach	Strength	Weakness
Hardware EVSE lab	Real RF, power path, vendor quirks	Slow to book; hard to parallelize; expensive
Local scripts / open-source clients	Flexible; free to hack	Setup drift, weak UI, poor shared logs for product/QA
Hosted OCPP 1.6 simulator (Chargeflux)	Fast CSMS integration loops, shared console, presets	Not a substitute for final hardware or OCA certification

Not a certification tool

The simulator validates the OCPP envelope and supported payloads against bundled OCPP 1.6 JSON schemas, but it is a development and testing tool — not an official OCPP certification or conformance lab. Use it to ship CSMS features faster; finish compliance with the process your market requires.

Related guides

OCPP 1.6J sample messages — JSON examples and when each Core message is triggered
What is OCPP? — protocol roles, 1.6 vs 2.0.1, core vocabulary
EVSE simulator — when a virtual charge point beats a hardware-only lab
OCPP 2.0.1 simulator — dual-stack CSMS paths
Connect your CSMS — endpoint and subprotocol requirements
API — automate hosted stations from CI

How to start testing

Launch the simulator, pick an OCPP 1.6 path, connect your CSMS, and walk a Boot → Authorize → Start → MeterValues → Stop cycle. Pricing and plan limits are on pricing. New to the protocol vocabulary? Read what is OCPP first.

FAQ

What is an OCPP 1.6 simulator?

Software that pretends to be an OCPP 1.6J charge point: it opens a WebSocket to your central system, exchanges framed CALL / CALLRESULT messages, and lets you drive connector states so the CSMS sees realistic traffic without a physical charger.

Is this the same as an OCPP 1.6J simulator?

Yes in practice. OCPP 1.6 over JSON (OCPP-J) on WebSocket is what almost every modern CSMS expects. Chargeflux uses the ocpp1.6 subprotocol for that path.

Can I use this OCPP 1.6 simulator to test RemoteStartTransaction?

Yes. Once the station is accepted and a connector is available, send RemoteStartTransaction / RemoteStopTransaction from your CSMS and watch the correlated frames in the message console.

Does Chargeflux only support OCPP 1.6?

No. OCPP 1.6J and 2.0.1 are supported today. OCPP 2.1 is on the public roadmap without a promised date. Use the matching simulator doc for each version so dual-stack CSMS code gets real coverage.

How is this different from a free local OCPP charge point simulator?

Local tools are fine for one engineer. A hosted OCPP charge point simulator adds a shared UI, cloud runtime that can reach public CSMS endpoints, presets, and exportable session logs so product and QA can reproduce the same run.

Is an OCPP 1.6 simulator enough for compliance or certification?

No. Use it to prove integration behaviour and catch payload or session bugs early. Official OCPP compliance or certification still needs the process and tooling your market requires — Chargeflux is a development and CSMS testing tool, not an OCA lab.

Last reviewed August 2026 · Chargeflux.io