OCPP proxy or on-site CSMS? Adding load management to a charging site

A site that already runs a cloud CSMS for payments or a driver app, and now needs load management that respects its supply, has two on-site options: put a proxy in front of the cloud, or make the on-site system the CSMS. This guide explains both at message level, with their failure modes and security costs.

What is an OCPP proxy?#

An OCPP proxy is a device on the site network that sits between charge points and a central system: chargers connect to it as if it were the CSMS, and it connects onwards as if it were the chargers. OCPP 2.0.1 separates a local proxy, which only routes messages, from a local controller, which also sends its own commands.

The OCPP 2.0.1 architecture document describes a local proxy as a message router, for example one mobile-data unit serving chargers in an underground car park: "For the Charging Stations in the group the local proxy 'is' the CSMS. Similarly, for the CSMS the local proxy 'is' the Charging Station." A local controller goes further: it "can send messages to its Charging Stations, independently of the CSMS", typically to impose charge limits for local smart charging [2]. OCPP 1.6 already had the idea, describing its local controller as "a proxy for the group members' OCPP messages" [1].

The market uses "OCPP proxy", "OCPP gateway", "local controller" and "local EMS" loosely. In this guide, a proxy means a device that relays between chargers and an upstream CSMS and also enforces site limits: a local controller in OCPP terms.

Why can't a charger just connect to two systems?#

A charger can't connect to two systems because OCPP is point to point. An OCPP 1.6J charge point builds one connection URL from its central system's endpoint and holds one WebSocket to it. Adding a second controller, such as an on-site load manager beside an existing cloud CSMS, means putting something in the path or replacing the cloud link.

The OCPP-J 1.6 specification defines that single connection URL, which carries the charge point's identity so the central system knows who is calling [3]. Vendors feel the consequence. ABB states that its chargers accept only one OCPP server, so its c-kit site controller is not intended for integration into a charge-point operator's systems over OCPP [5]. gridX describes the same problem and its answer: a "custom-built OCPP proxy" that "maintains an OCPP protocol connection with both the EVCS and the customer's CSMS", so dynamic load management works "even without an internet connection" [6]. Beckhoff's TF6771 takes the controller approach: it provides local load management and "may still be connected to a remote CSMS in parallel" [7].

OCPP 2.0.1 formalises the pattern. The local controller opens a separate WebSocket to the CSMS for every charger that connects to it, using the same charger identity, and "SHALL work so that the CSMS can not notice" whether the charger is connected directly or through it [2].

What are the four ways to add load management to a charging site?#

There are four architectures for adding load management to a charging site: load management in the cloud CSMS, balancing built into the chargers, an on-site system that is the site's CSMS, and an on-site proxy in front of a cloud CSMS. They differ in where decisions are made, what happens when the internet drops, and who holds the data.

Four ways to add load management

Where limits are decidedInternet boundaryThe maker's own link

1. Cloud CSMS only#

The CSMS reads charger meter values (and sometimes a cloud-connected site meter) and sends SetChargingProfile over the internet. Nothing extra on site. When the link drops, each charger keeps its current transaction profile or falls back to whatever default profile it holds [1], and nothing reacts to the building's load until the link returns.

2. Charger-native balancing#

The chargers coordinate among themselves or through the maker's cloud. It works within one brand, and the best features may not be available over OCPP at all: Zaptec documents that its advanced balancing is not supported on its direct OCPP route [9]. See hardware-agnostic load management.

3. On-site CSMS#

Chargers connect directly to a CSMS on the site's network that also runs load management. The internet becomes optional. Cost recovery can run from exported session records through a billing provider; public roaming generally needs a cloud CSMS or roaming hub.

4. On-site proxy in front of a cloud CSMS#

Chargers connect to the local controller, which relays to the cloud and composes limits. The cloud keeps payments, roaming and the driver app; the site gains local control, plus a component with its own ID, queueing and TLS responsibilities.

How does an OCPP proxy handle messages?#

A load-managing OCPP proxy relays almost every message, answers some itself when the internet is down, and originates its own SetChargingProfile commands. The hard parts are composing its limits with the cloud's, keeping message and transaction IDs consistent, and replaying queued records in order when the link returns.

Composing charging limits#

A cloud CSMS may send its own profiles: a TxProfile for a driver's requested rate, one inside RemoteStartTransaction, or a ChargePointMaxProfile reflecting a contract. Passed through untouched, a cloud profile with the same purpose and stack level as the proxy's replaces it [1], and a broad ClearChargingProfile can delete the site's limits. The safe rule is that the charger only ever holds the lower of the cloud's request and the site allocation. A proxy gets there by rewriting cloud profiles before delivery, or by holding the site limit in a ChargePointMaxProfile the cloud never sends, which the charger combines with the transaction profile by taking the lower value. Either way, the cloud's view of the charger will show the site cap, not the number it asked for. Operators need to know why.

Message and transaction IDs#

OCPP-J pairs each request with its response by message ID. A proxy that sends its own commands must use IDs that cannot collide with the CSMS's (UUIDs or a reserved range), and must not forward the charger's replies to its own commands upstream; OCPP 2.0.1 makes both rules explicit [2]. Transactions are harder in OCPP 1.6, where the central system assigns the transactionId in its StartTransaction response [1]. If a session starts while the internet is down, the proxy gives the charger a provisional ID, forwards the start when the link returns, then translates between the two IDs for every later message in that session. OCPP 2.0.1 removes this problem: the charging station generates transaction IDs itself [2].

Store and forward when the internet drops#

An offline OCPP 1.6 charger must queue its transaction-related messages (StartTransaction, StopTransaction and periodic MeterValues) and deliver them in order [1]. With a proxy in the path, OCPP 2.0.1 says a local controller that loses the CSMS must close its chargers' connections too, so they queue as usual, "unless the Local Controller is capable of responding to Charging Station requests, and forwards transaction-related requests to the CSMS once the connection is restored" [2]. Disconnecting is simpler, but disconnected chargers also stop receiving live limits. A proxy that keeps load management running through an outage has to answer locally: durable storage that survives a power cut, strict ordering, and de-duplication on replay, because billing depends on each record arriving exactly once.

Authorisation caching#

OCPP 1.6 gives chargers an optional authorisation cache and local authorisation list for offline use [1]. A proxy can add its own cache of the cloud's Authorize answers so known drivers can still start. The cost is staleness: a card blocked in the cloud keeps working on site until the link returns. Choose the offline policy (known cards only, any card, or none) and write it down.

What does an OCPP proxy do to security?#

An OCPP proxy terminates the charger's TLS session on site and opens a separate one to the CSMS. That makes the proxy a trusted party in the middle: it can read and change every message, and it holds the credentials it uses to stand in for each charger. It has to be secured, patched and monitored like the CSMS itself.

OCPP 2.0.1 defines three security profiles: unsecured transport with HTTP Basic authentication, TLS with Basic authentication, and TLS with client-side certificates [2]. The Open Charge Alliance's OCPP 1.6 security whitepaper applies the same improvements to 1.6-J [4]. With a local controller in the path, OCPP 2.0.1 splits each link in two: towards the chargers the controller acts as the CSMS and is the TLS server; towards the CSMS it acts as the charging station and is the TLS client [2].

• Credentials multiply. Under Basic authentication the CSMS knows each charger by its identity and a stored password [3], so the proxy must hold every charger's upstream password. Under client certificates it needs a certificate the CSMS accepts for each charger identity, plus a server certificate the chargers trust.
• End-to-end trust stops at the proxy. At FOSDEM 2024, Achim Friedland described the duplicated HTTPS WebSocket connections this topology creates as "caused by OCPP protocol limitations" and warned that "HTTPS/TLS is no longer sufficient for end-to-end security", proposing signed OCPP messages as a remedy [8]. Until something like that is standard, the proxy can alter anything, including the meter values the CSMS bills on.
• The proxy is a target. Put it and the chargers on their own network segment, restrict what it can reach, log every message it rewrites, and include it in certificate renewal.

Proxy, on-site CSMS or neither: how do you choose?#

Keep the cloud CSMS and add a proxy when the cloud does work the site cannot easily replace, such as payments, roaming or a network-wide driver app, and the site also needs load management that survives internet outages. Make the on-site system the CSMS when the site's needs are local. Skip the proxy when simpler control is enough.

Keep the cloud CSMS and add a proxy when#

• Drivers pay through the cloud platform, roam onto the site, or use a network-wide app.
• An operator runs many sites on one CSMS and wants to keep that single view.
• The site has a hard supply limit and its internet link cannot be relied on.
• Both the proxy and CSMS vendors will test the arrangement: certificates, ID mapping and profile composition.

Make the on-site system the CSMS when#

• The site's needs are local: a fleet depot or workshop, a private workplace, an apartment car park.
• Charging must authorise, meter and load-manage with no internet.
• Data has to stay on the premises.
• Cost recovery can run from exported session records through a strata manager or billing provider.

A proxy is the wrong tool when#

• The supply has plenty of margin and the cloud's own load management is responsive enough.
• Every charger is one brand whose built-in balancing already does the job.
• Policy requires end-to-end TLS from each charger to the CSMS.
• The real requirement is for the building management system to cap charging; a direct BMS interface may be simpler (see BMS integration over Modbus and MQTT).

Where Nohmad Edge CSMS fits#

Nohmad Edge CSMS is an on-site CSMS, not a proxy. Chargers connect directly to it over OCPP 1.6J, and its load-management engine runs alongside on one industrial PC at the site. An upstream OCPP link that would let a site keep an existing cloud CSMS, known as proxy mode, is on the roadmap.

• Architecture three today. One box per site, speaking OCPP 1.6J (Core and Smart Charging) to any AC charger that implements smart-charging profiles — tested so far on simulators and real chargers including an Orbis VIARIS UNI; no published compatibility list yet. It works with no internet connection at all, and all data stays on the box.
• Load management on site. Capacity is re-allocated every 10 seconds (configurable 5–15 s) from real meters on real boards, per phase where meters and charger phase mappings exist. Limits go out with SetChargingProfile, and each charger gets an offline fallback profile (10 A by default).
• Authorisation without the cloud. Plug-in auto-start, or an RFID allow-list of up to 10,000 tags per charger, managed through the API today. Unknown chargers wait in Pending until an operator approves them.
• Data out. Session records (kWh, RFID tag, charger, bay) export to CSV, alarms reach a service desk as JSON webhooks, and a REST API takes self-service API keys. Edge CSMS does not bill, take payments or handle roaming; a strata manager or billing provider works from the exported records.
• Your chargers aren't ours. They speak standard OCPP, so you can point them at another CSMS if you ever leave.
• On the roadmap. Proxy mode (an upstream OCPP link for sites that keep an existing cloud CSMS), OCPP 2.0.1, and an optional AU-region cloud uplink for multi-site visibility.

If your site has to keep its current cloud CSMS, tell us about it: the platform, the charger models and the OCPP security profile in use. Edge CSMS is available for early sites by enquiry; see Edge CSMS. Installers and consultants can start at partners, and the commercial and industrial page, the capacity calculator and our guide to maximum demand cover sizing.

Sources#

These are the primary specifications, vendor documents and talks behind the statements in this article. OCPP section numbers refer to OCPP 1.6 Edition 2 and OCPP 2.0.1 Edition 4, published by the Open Charge Alliance. Vendor pages were checked on 23 October 2026.

1. Open Charge Alliance, OCPP 1.6 Edition 2: §3.5 local authorisation and offline behaviour; §3.7 transaction-related messages; §3.13 Smart Charging (stacking, combining, local smart charging, offline behaviour); §4.8 Start Transaction.
2. Open Charge Alliance, OCPP 2.0.1 Edition 4: Part 1 §8.2–8.3 (local proxy, local controller); Part 2 §A security profiles, §E transactions, K03 local smart charging; Part 4 §6 Local Controller.
3. Open Charge Alliance, OCPP-J 1.6 Specification: §3.1.1 connection URL; §6.2 authentication.
4. Open Charge Alliance, OCPP 1.6 Security Whitepaper, 4th edition, 5 February 2026.
5. ABB, c-kit.
6. gridX, Communication is key: the importance of OCPP, 14 September 2021.
7. Beckhoff, TF6771 TwinCAT 3 IoT OCPP.
8. Achim Friedland (GraphDefined), "Enhancing OCPP with E2E-Security and Binary Data Streams", FOSDEM 2024 Energy devroom, speaker page with talk and slides.
9. Zaptec, OCPP within Zaptec.