OCPP 1.6 Deployment. Keeping Chargers Alive When the Network Isn't

The OCPP spec tells you what messages to send. It doesn't tell you what happens when the 4G modem drops at 3 AM, when a power outage kills the charger mid-session, or when 500 chargers try to reconnect to your backend simultaneously after a server restart. This post is about that.

The reality of charger connectivity

Chargers live outdoors. They connect over 4G/LTE, sometimes Wi-Fi, occasionally wired Ethernet. The cellular connection drops regularly. weather, congestion, tower maintenance, SIM issues. Power outages happen multiple times a week in some regions. Temperature extremes cause reboots.

Your OCPP implementation has to survive all of this without losing transactions or leaving chargers in undefined states.

Reconnection: exponential backoff or you DDoS yourself

When the WebSocket drops, the charger needs to reconnect. The wrong way: retry immediately, in a tight loop.

Rendering diagram...

Start at 5 seconds, double each retry, cap at 15 minutes. This prevents a fleet of 1,000 chargers from hammering your server at the same instant after a backend restart. I've seen backends go down because they restarted during peak hours and 300 chargers reconnected simultaneously with no backoff. The reconnection storm was worse than the original outage.

Offline charging: the charger must keep working

When the WebSocket is down, the charger should:

1. Check the Local Authorization List for RFID cards
2. Start sessions locally
3. Queue every message: StartTransaction, MeterValues, StopTransaction
4. Replay the queue in order when connectivity returns

Rendering diagram...

The timestamps in queued messages must be the original ones, not the time of replay. Otherwise billing calculations are wrong and you'll have angry customers disputing charges with timestamps that don't match their actual usage.

Idempotency: messages will arrive more than once

Network hiccups cause duplicates. Your backend must handle them:

• BootNotification received twice? Just respond again.
• StartTransaction with the same idTag + timestamp + connectorId? Return the same transactionId. Don't create two transactions.
• StopTransaction received twice for the same transactionId? Stop once, acknowledge both. Don't bill twice.

The rule: process based on content, not on the fact that you received a message. If you've seen this exact StartTransaction before, return the same result.

Watchdogs

Charger side: The firmware should have a hardware or software watchdog that restarts the OCPP stack if it hangs, reboots the charger if unresponsive, but never. ever. reboots during an active charging session. That's a safety issue.

Backend side: Track heartbeat freshness per charger.

Rendering diagram...

If a charger misses two heartbeat intervals, something is wrong. It might just be a network blip. or it might be a bricked unit that needs a site visit.

Logging and observability

You cannot debug what you cannot see. Log every OCPP message. both directions. with timestamps, charger ID, and message ID. Structure them so you can filter by charger, by transaction, by time range.

{
  "timestamp": "2026-01-07T14:30:00Z",
  "chargerId": "CP-001",
  "direction": "CP->CS",
  "action": "StartTransaction",
  "messageId": "uuid-123",
  "payload": {"connectorId": 1, "idTag": "RFID-ABC123"}
}

When someone reports a billing error, you want to pull up the full transaction lifecycle in one query: Authorize → StartTransaction → every MeterValues → StopTransaction. If you can't do that in under a minute, your logging isn't good enough yet.

Load testing

Before deploying at scale, simulate:

• Reconnection storms: disconnect 500 chargers, let them reconnect with backoff
• Burst BootNotifications: 500 simultaneous boots after a power outage
• High-frequency MeterValues: every charger sending every 10 seconds

If your backend falls over in testing, better now than in production with real revenue on the line.

The spec describes a protocol. Deployment is where you make it actually work.