OCPP Charger Simulator
A simulated two-connector EV charger that speaks OCPP 1.6J over WebSocket. It boots against a central system, runs charging sessions with live meter values, and answers the operator's remote commands the way the standard says a real unit should.
- Period
- Context
- My role
The problem
A central system can only be tested against a charger, and real chargers are expensive, shared and slow to reset. The backend itself stays private, but the thing I needed to test it against didn't have to be: a demo charger that receives and responds to OCPP messages according to the standard, runnable on a laptop.
How it was built
The boot handshake
The charger opens a WebSocket on the ocpp1.6 subprotocol and announces itself with a BootNotification carrying vendor, model, serial and firmware. Only once the central system accepts does it mark both connectors Available, report each with a StatusNotification, and start sending Heartbeats at whatever interval the server handed back. If the connection drops, it reconnects and boots again.
A charging session that looks real
Each connector has its own state: status, transaction, reservation and energy register. A session moves through Preparing, Charging and Finishing with a StatusNotification at each step, and while charging it sends MeterValues every ten seconds: per-phase current, power, temperature and an Energy.Active.Import.Register that only goes up. Now and then a session drops into SuspendedEV or SuspendedEVSE, so the backend has to deal with pauses as well as the happy path.
Answering the central system
It handles the operator-side commands a CSMS actually sends: RemoteStart and RemoteStopTransaction, ReserveNow with automatic expiry, CancelReservation, ChangeAvailability, and GetConfiguration with the standard keys and an unknownKey list. ChangeConfiguration, Reset and ClearCache return a random valid status on purpose, so the rejection and reboot-required paths get exercised too.
Where it landed
- A charger to develop the central system against, without needing hardware
- Covers boot, heartbeat, status, transactions, meter values, reservations and remote control
- Built with the mobilityhouse ocpp library, so messages are validated against the OCPP 1.6J schemas
Specification
- Protocol
- Runtime
- Connectors
- Sends
- Answers