What an EV Charger Does When the Internet Drops: OCPP 1.6J Offline Behaviour and Where a Local CSMS Proxy Fits

It is 8 PM at a condo car park, a resort, or a roadside stop. The 4G modem drops for twenty minutes. A driver is plugged in. Another is walking up with an RFID card. What should happen?

Most of the answer is not up to your charging management system (CSMS). It is up to the charger. The CSMS only gets a say beforehand, through configuration, and afterwards, when the connection comes back and it has to make sense of what the charger did on its own.

This post covers both halves, for OCPP 1.6J, the protocol version our production platform runs today.

Who decides: the charger

OCPP 1.6J is a WebSocket connection from the charger to the CSMS. When it drops, the CSMS cannot answer an authorization request or start a session. The charger’s firmware decides what to do, within what the OCPP specification allows and what the CSMS configured the last time the charger was connected.

That has a practical consequence: two chargers from different vendors can behave differently in the same outage. Offline behaviour is a property of the charger model and its configuration, which makes it something to test, not assume.

The settings that shape offline sessions

OCPP 1.6 defines configuration keys that control this. These are the ones that matter most for offline behaviour:

Key	What it controls
LocalAuthorizeOffline	Whether the charger may authorize an ID tag from local data while it has no connection
LocalPreAuthorize	Whether the charger may start charging on local authorization without waiting for the CSMS to answer
AuthorizationCacheEnabled	Whether the charger keeps a cache of earlier authorization results
LocalAuthListEnabled	Whether the local authorization list is used (the CSMS pushes the list to the charger)
AllowOfflineTxForUnknownId	Whether an ID tag the charger does not know may start a session while offline
TransactionMessageAttempts and TransactionMessageRetryInterval	How many times, and how often, the charger retries delivering transaction messages
MeterValueSampleInterval	How often energy readings are sampled during a session

Not every charger supports every key, and defaults differ. The reliable way to find out is to read the charger’s actual configuration (OCPP’s GetConfiguration) and ask the vendor what the offline behaviour is, rather than trusting a datasheet line.

The Simplico EV CSMS page makes the same point at a practical level: chargers that are OCPP-compliant let authorized local sessions continue using cached RFID data and resync transactions when connectivity returns.

What happens to the session

During an outage, a charger that is allowed to can start a session for a locally authorized driver, keep charging, and queue the messages it would normally send immediately: the start of the transaction, meter readings, and the stop. When the connection returns, it delivers them.

The driver notices nothing. The operator sees a gap, and then a session appearing late with timestamps from the past. One detail worth knowing: the CSMS normally assigns the transaction ID when it answers the start message, so readings recorded during the outage typically cannot carry that ID until the charger reconnects.

What the CSMS has to get right on reconnect

This is where a platform earns its keep. Four rules we would hold any CSMS to:

1. Use the charger’s timestamps, not arrival time. A session that started at 8:03 PM and arrived at 8:27 PM happened at 8:03 PM. Billing, reports, and tariff windows depend on that.
2. Be idempotent. Retries mean the same message can arrive twice. Handling a duplicate must not create a second session or a second charge. It is the same discipline we describe for payments in Idempotency in Payment APIs.
3. Reconcile before billing. Do not close or invoice a session while a charger is still catching up. Wait until the stop message and the final readings are in.
4. Keep the raw messages. When a session looks wrong, the original OCPP messages are the evidence. Our demo platform records raw OCPP messages alongside sessions for exactly this kind of debugging.

Payments change the picture

Offline continuation works cleanly for drivers whose identity the charger can check locally, such as RFID tags in a local list or cache.

A QR scan-to-charge session paid by PromptPay or QR30 is different. Payment is confirmed outside the charger, so those sessions generally depend on connectivity. The product page describes offline continuation for cached RFID sessions; unless your deployment is designed otherwise, plan QR-paid sessions as connectivity-dependent and decide deliberately what a driver should see when the site is offline.

Where a local CSMS proxy fits

For most sites, an occasional outage plus a charger that handles it well is enough. For sites where outages are frequent or expensive, such as a remote location, a weak mobile signal, or a venue where a dead charger costs real money, there is another option: put a small CSMS-side service on the site itself.

flowchart TD
    A["Charger"] --> B["Local CSMS proxy on site"]
    B -->|"uplink up"| C["Central CSMS"]
    B -.->|"uplink down - buffers locally"| D["Local buffer"]
    D -.->|"uplink restored - forwards"| C

The charger keeps talking to something on the local network even when the uplink is down. The proxy buffers what it hears and forwards it to the central CSMS when the connection returns. Our EV CSMS page says we can deploy a local CSMS proxy for unreliable sites.

It is a per-site decision, not a default. It adds one more component to run, patch, and monitor, so it only pays off where the cost of outages justifies it. Measure how often a site actually drops before deciding.

A commissioning test worth adding

Whatever the architecture, test the failure instead of trusting it. For each charger model:

1. Start a session with an RFID tag that is in the local list.
2. Cut the uplink mid-session (disable the modem or unplug the network).
3. Let the charger run, then stop the session at the charger.
4. Restore the uplink.
5. Check that the session appears once, with correct start and stop times, energy matching the charger’s own display, and no duplicate billing.
6. Repeat with a QR-paid session and note exactly what the driver experiences.

Our commissioning step already includes test sessions and end-to-end payment validation. Ask for the offline test to be written into the scope.

What this post does and doesn’t claim

• It describes OCPP 1.6J behaviour in general terms. Individual chargers differ, so test your model.
• The statements about Simplico’s platform are limited to what our product page says: cached RFID sessions can continue offline and resync, and a local CSMS proxy can be deployed for unreliable sites.
• A local proxy is scoped per site. It is not part of every deployment.
• OCPP 2.0.1 is available as an upgrade path for new deployments and is not covered here.

FAQ

Will a charger keep working if it loses internet?
It depends on the charger model and its configuration. Chargers that support local authorization can continue sessions for drivers they can verify locally, then resync when the connection returns.

Will an offline session be billed correctly afterwards?
That is the CSMS’s job on reconnect: use the charger’s timestamps, ignore duplicates, and reconcile before invoicing. Test it during commissioning.

Do I need a local proxy?
Not for most sites. It is worth discussing where outages are frequent or costly. We scope it per site.

Which chargers work with your platform?
Any charger that supports OCPP 1.6J over WebSocket. We validate your exact model during commissioning.

See how it behaves

You can connect a real or simulated charger to the public demo and watch the OCPP messages arrive: the practical demo guide walks through it. Packages and the deployment process are on the EV CSMS page.

If you are planning a site and want offline behaviour tested properly, tell us the site, how many charge points, and when you want to be live, and we will send a scoped proposal within 48 hours: hello@simplico.net. We are also running a founding-partner program for the first operators on the self-hosted platform.

OCPP is a trademark of the Open Charge Alliance. PromptPay and QR30 are services of the Bank of Thailand.