Chargers lose connectivity. The outage itself is rarely the problem for a CSMS. The trouble starts when the station comes back and delivers a session that began while it was offline, with timestamps from the past, in one burst. Billing from arrival time instead of event time, a second transaction for the same session, and a transaction id the CSMS never issued are all bugs that only show up after a reconnect.

Cause an outage on demand

Three calls control the connection of a simulated station:

# drop the WebSocket for 60 seconds, then reconnect
curl -X POST https://api.simitnow.com/v2/cs/CP-001/network/disconnect   -H "SIMITNOW-API-KEY: $API_KEY"   -H "Content-Type: application/json"   -d '{"duration": 60}'

# bring a station back early, or after a disconnect with no duration
curl -X POST https://api.simitnow.com/v2/cs/CP-001/network/connect   -H "SIMITNOW-API-KEY: $API_KEY"

# simulate a power cut
curl -X POST https://api.simitnow.com/v2/cs/CP-001/network/power-loss   -H "SIMITNOW-API-KEY: $API_KEY"

Without a duration, the station stays offline until you call network/connect. Asking to disconnect a station that is already offline returns 409.

What the station does while it is offline

It keeps running. Meters advance and connector status changes. A transaction started through the API needs an EV plugged in (the connector in Preparing) and involves no authorization. On OCPP 1.6, a walk-up start while offline is accepted for a tag in the authorization cache or the local list, because LocalAuthorizeOffline is true by default, and for any tag when AllowOfflineTxForUnknownId is true (it defaults to false). Transaction messages produced during the outage are queued and delivered in order after the reconnect: StartTransaction, MeterValues and StopTransaction on OCPP 1.6, TransactionEvent on 2.0.1 and 2.1.

Heartbeats and status notifications are not queued. By the time the link returns they would describe a moment that has passed. After the reconnect the station sends a fresh BootNotification, then a StatusNotification for each connector, and only then delivers the queue.

OCPP 1.6: the placeholder transaction id

On 1.6 the CSMS assigns the transaction id in the StartTransaction response, and an offline station has nobody to ask. When you start a transaction through the API while the station is disconnected, the response carries a negative transaction id. It is a local placeholder, and it stops the transaction just as well as a real id would.

On replay the CSMS sees the queued StartTransaction, answers with the real id, and the station rewrites every queued message that still quotes the placeholder before it sends them. Your CSMS should therefore see the real id on every later MeterValues and on the StopTransaction. A negative id on the wire after the replay would be a station bug. If the CSMS refuses the StartTransaction, the station drops the messages that depend on it instead of sending them.

OCPP 2.0.1 and 2.1: offline events

On 2.x the station creates the transaction id itself, so there is no placeholder. Events produced during the outage are marked offline: true, and the sequence numbers continue across the gap, unless the queue overflowed and dropped Updated events (see below). A CSMS should bill from the timestamp inside the event, not from the moment it arrived.

When the queue fills

The queue holds up to 500 messages. When it is full it drops the oldest intermediate message to make room, a MeterValues sample on 1.6 or an Updated TransactionEvent on 2.x, so a 2.x series can then show gaps in its sequence numbers. It never drops the start or the end of a transaction. Only when the queue holds nothing but starts and ends is a new start request through the API refused with 503, instead of being accepted and lost. A long outage with a short meter interval is the way to test how your CSMS handles gaps in a meter series.

A dropped connection does not end the session

When your CSMS closes the connection, or the link drops, a station on any of the three versions keeps its running transaction and the EV stays plugged in. It reconnects, carries on with the same transaction and keeps sending meter readings. Restart your CSMS in the middle of a charging session and check that it does not open a second transaction. A Reset, deleting the station and the daily message allowance still end the session. So does an update of SimItNow itself that restarts the station, because the transaction and the queue are held in memory.

Reconnect timing

The station never stops retrying. reconnectWaitTimeInSeconds (default 5) is the lower bound of a random base that each station draws when it is created, up to about double that. Each attempt waits between its base and twice the base. Repeated handshake timeouts stretch that further. If the CSMS keeps refusing the station, because it is busy (429 or 503), because the credentials are refused (401 or 403) or because the URL does not exist (404), the wait grows geometrically up to about a minute (between 30 and 60 seconds, with jitter). Once the CSMS is back, the station recovers on its own.

Power loss is a different test

A disconnect leaves the sessions running and queues what happens next. A power loss ends them: every active transaction is stopped with the reason PowerLoss before the station goes offline, so your CSMS receives the StopTransaction messages immediately and sees how each session ended. The station stays offline until you call network/connect.

A checklist for your CSMS

For other failure cases, such as malformed messages and rejected remote starts, see OCPP invalid scenario testing. Create a free account to run these tests against your own CSMS.