OCPP CSMS platform for charging network operators

What the OCPP server does

A charging station management system (CSMS) is the back end that chargers talk to. Ours listens on one WebSocket endpoint, recognises the protocol version the charger asks for, and routes the connection to the matching handler. A charger needs only the server address, its identity and a password.

Version	Status in the platform
OCPP 1.6J (JSON)	Core flow: boot, heartbeat, status, authorisation, start and stop transaction, meter values, firmware and diagnostics status, data transfer.
OCPP 2.0.1	Core flow through transaction events, status and meter values, plus security events, device reports and logs received and stored.
OCPP 2.1	The connection is negotiated as 2.1 and the core transaction flow reuses the 2.0.1 handlers. 2.1-only messages (V2X, DER control, battery swapping) are acknowledged, not acted on.

OCPP 1.6 and 2.x are not compatible with each other, which is why the server handles each version separately. Background: OCPP explained.

Scroll sideways to see the whole table

Remote control from the admin panel

• Start and stop a session on a connector, and see the live session: energy, power and cost as they accrue.
• Reset a charger (soft or hard) and unlock a connector with a stuck cable.
• Availability: take a connector out of service and bring it back.
• Trigger a message from the charger, such as a status or meter reading.
• Clear cache and read or change configuration keys.
• Raw commands: send any OCPP call the charger supports, for example a charging profile, and see the response. Raw commands are not restricted to a fixed list, so use them with care.

Reliability: no lost meter readings

Billing depends on meter values, so incoming messages are written to a durable queue before the charger receives its answer and applied in order afterwards. If the server restarts, queued messages are still there. Stations that go offline reconnect and replay what they buffered.

In a simulated test with 200 virtual OCPP 1.6 stations sending 150 messages per second on a shared 2-vCPU machine, the median acknowledgement time for MeterValues was about 2 ms with the queue, against about 5 to 6 ms when processing synchronously; the 95th percentile was 4 to 6 ms against 11 to 23 ms. This is a synthetic benchmark on shared hardware with simulated stations, not a promise for your site. We will repeat a test with your numbers during a pilot.

Security

• Each station authenticates with HTTP Basic credentials (the OCPP security profiles 1 and 2 approach). Run it behind TLS at your reverse proxy to get profile 2. Client-certificate authentication (profile 3) is not implemented.
• Message size limits, connection rate limits and keep-alive pings protect the endpoint.
• Team accounts in the admin panel use roles, two-factor sign-in and an audit log of who changed what.
• The OCPP message log records traffic per station for support and disputes, with configurable retention.

Scaling and operations

The server is a Node.js process backed by PostgreSQL 16 and Redis 7. You can run several instances behind a load balancer: Redis carries station presence and passes commands to the instance that holds the charger’s connection. Prometheus metrics and health checks are built in, and the whole stack runs with Docker Compose. We have not published capacity numbers beyond the simulation above.

What is still missing

• Automatic load management. You can send smart-charging profiles by hand; the platform does not yet balance a site’s power across connectors on its own.
• OCPP 2.1 features beyond the 2.0.1 core.
• Certificate-based station authentication and ISO 15118 Plug and Charge.
• OCPI roaming. A 2.2.1 module exists but is off by default and is not yet proven against third-party networks.

The CSMS is one part of the platform. Drivers use the app, pay through local payment providers, and you manage everything from one panel. See the platform overview or write to us below.