Multi-backend routing

The OCPP proxy is the OCPPLab product wedge for mixed fleets: chargers keep one stable field URL while you change backends, dual-run a new CPMS, or cut over station by station. This guide is the operator path for two backends and a controlled cutover.

Dashboard UI map (screenshots): Proxy. WebSocket wiring details: Connecting to your CPMS.

Why this exists

OCPPLab is still not a full CPMS by default. You keep (or introduce) one or more upstream CPMS backends; the gateway terminates the field and routes OCPP.

Topology

1  Charge points (field)
2           |
3           |  wss://…OCPPLab…/<charge-point-id>
4           v
5     ┌─────────────┐
6     │ OCPP gateway │  one stable entry point
7     │    + proxy   │
8     └──────┬──────┘
9            |
10     routes (priority, active)
11       /              \
12      v                v
13 Backend A          Backend B
14 (legacy CPMS)      (new CPMS)

• Backend — upstream CPMS WebSocket / OCPP endpoint and how OCPPLab authenticates to it
• Route — charger → backend mapping with priority and active / inactive
• Session — live charger↔proxy WebSocket while the station is connected
• Wire logs — station-side and backend-side OCPP messages for dual-run proof

Prerequisites

• Station registered in Dashboard and able to complete BootNotification
• Network path from OCPPLab to each upstream CPMS (wss://, correct security profile)
• Operator access to Proxy in Dashboard (/dashboard/ocpp-proxy)

Never paste live OCPP passwords, OCPI tokens, or client certificates into tickets, chat, or public issues. Rotate anything that may have been exposed and use Dashboard or your secret store for operational credentials.

Add a second backend (dual-run)

Use this when the fleet already points at OCPPLab and you want a new CPMS to receive traffic without dropping the old one.

1. 1

   Define backends

   In Proxy → Backends, create (or verify) two backends:

   • A — current production CPMS
   • B — candidate CPMS

   Record eligibility and credentials carefully. Prefer TLS and the security profile each CPMS expects.

2. 2

   Attach proxy chargers

   Ensure the stations you will dual-run appear under Proxy → Chargers (proxy path), not only managed CSMS mode if your org separates those.

3. 3

   Create routes

   Under Proxy → Routes, map a pilot charger set:

   • Primary route → Backend A (active, higher priority)
   • Secondary route → Backend B (active only if your dual-run model mirrors or shadows traffic)

   Exact dual-run semantics (mirror vs exclusive primary) depend on how you configure routes for your org. Prefer a small pilot before fleet-wide dual-run.

4. 4

   Prove connectivity

   On the pilot stations:

   • Confirm Sessions shows a live WebSocket to OCPPLab
   • Open Charger log and Backend log for BootNotification / Heartbeat / session messages
   • Run a short test session and compare outcomes on A and B where both are expected to see traffic

Cut over a charger or cohort

Use this when dual-run is healthy and you want traffic to prefer or exclusive-route to the new backend.

1. 1

   Pick a cutover unit

   Cut over by single station, site, or firmware cohort — not the whole estate on day one. Document the rollback (reactivate the legacy route).

2. 2

   Adjust routes

   For each cutover station:

   • Raise priority (or activate) the Backend B route
   • Lower priority or deactivate Backend A when exclusive cutover is intentional
   • Leave field CSMS URL unchanged on the charger — only OCPPLab routes change
3. 3

   Validate the session path

   After reconnect or natural heartbeat:

   • Station stays online in Dashboard
   • Wire logs show traffic toward Backend B
   • Remote start/stop and a short session complete cleanly
   • Observability / webhook consumers still see expected events
4. 4

   Roll forward or roll back

   • Forward — expand the cohort when pilot metrics look sane
   • Back — restore the legacy route priority/active flags; chargers still do not need a new field URL

Operator checklist

Failure modes

Related

• Proxy (Dashboard UI) — screenshots for backends, routes, sessions, logs
• Connect a charger
• Architecture
• Managed chargers