- OCPP
- Simulating a charger
Simulating a charger
Model a full charging session end to end — boot, status transitions, authorization, transaction, and meter values.
This guide walks through a complete OCPP 1.6 session, from boot to a stopped transaction, and shows where to inject the edge cases worth testing. To deploy the lab station in the Dashboard (1.6 or 2.0.1), use Virtual charger.
Session walkthrough
Boot
On connect the charger sends
BootNotification. Until it receivesAccepted, a compliant charger should only sendBootNotificationandHeartbeat.Connector status
In OCPP 1.6,
StatusNotificationdrives the connector through its lifecycle, includingCharging. Test that your Central System reflects each transition and handlesFaulted/Unavailableout-of-band. OCPP 2.0.1StatusNotificationis only Available, Occupied, Reserved, Unavailable, or Faulted — charging state lives onTransactionEvent.Available → Preparing → Charging → Finishing → AvailableAuthorize and start
If the CPMS returns
Acceptedon authorize, follow withStartTransactioncarrying theconnectorId,idTag,meterStart, andtimestamp.authorize.json[2, "msg-020", "Authorize", { "idTag": "TAG-123" }]Meter values
During the session, emit
MeterValueson the configured interval. Vary the sampled values to exercise billing and live-session UI.Stop
StopTransactioncloses the session withmeterStop, areason, and an optional transaction data array. Confirm the CPMS computes the correct energy delivered.
Sample messages
[
2,
"msg-021",
"StartTransaction",
{
"connectorId": 1,
"idTag": "TAG-123",
"meterStart": 0,
"timestamp": "2026-01-15T12:00:00Z"
}
]Edge cases to inject
- Disconnect between
StartTransactionandStopTransaction MeterValueswith a decreasing register (clock/meter rollback)StopTransactionwithreason: "PowerLoss"
The left sidebar lists Overview, Actions, and Test cases only (not every message). Open the index pages below or use ⌘K search — hit labels include the protocol version (for example · OCPP 1.6) so same-named actions stay distinct.