OCPP, explained: the protocol your charger uses to talk to the world

If you own a smart EV charger, there is a good chance OCPP is running on it right now. You will not see it. No light, no notification. But every time your car plugs in, your charger and someone's backend are exchanging a quiet stream of messages • start session, meter reading, status change, stop session, repeat.

That is OCPP. The Open Charge Point Protocol. Once you understand what it does, a lot of the decisions around EV charging stop feeling arbitrary.

This piece is for anyone trying to make sense of the protocol • whether you are choosing a charger, building a backend, or wondering why your installer keeps asking about "the CSMS."

What OCPP is, in one paragraph

OCPP is an open communication standard. It defines how a charging station talks to a central management system over the internet. The protocol is owned by the Open Charge Alliance, a non-profit that publishes the spec for free. It has been around since 2009, and today it is the de facto standard for non-proprietary charger communication across Europe.

In other words: if your charger speaks OCPP, it can be operated by anyone whose backend also speaks OCPP. No lock-in to one vendor's cloud.

The two sides of an OCPP connection

OCPP is a client-server protocol over a persistent WebSocket connection.

• The charge point is the client. That is the physical hardware on your wall.
• The central system (CSMS) is the server. That is the backend in the cloud, somewhere.

When the charger boots, it opens a WebSocket to the CSMS and stays connected. Every event • a card swipe, a meter reading, a status change • is a JSON message sent over that socket. The CSMS can send messages back: start a session, stop a session, change a configuration, push a new firmware URL.

The connection is persistent and bidirectional. That matters more than it sounds.

What flows over the wire

A typical day for a residential charger looks something like this:

1. BootNotification • the charger announces itself when it powers on
2. StatusNotification • the connector changes from Available to Preparing
3. Authorize • someone presents an RFID card or starts via app
4. StartTransaction • the session begins, with a start meter value
5. MeterValues • the charger reports kWh delivered every minute or so
6. StopTransaction • the session ends, with a stop meter value and a reason
7. StatusNotification • back to Available

For our use case • registering home charging sessions as Emission Reduction Units (ERE) under the Dutch implementation of RED III • the meter values are everything. Each MID-certified kWh that flows through that socket is potentially a credit owed to the EV driver.

Why we run our own CSMS

There are two ways to integrate a charger with a backend like ours.

1. The vendor's cloud API. Tesla, Easee, Wallbox, Alfen, Zaptec and others publish HTTP APIs that expose session data. We use these where they exist.
2. OCPP directly. The charger connects to our CSMS at wss://ocpp.joulo.nl/{chargePointId}, and we collect the raw protocol traffic ourselves.

We run our own CSMS for the chargers that do not have a usable cloud API, or where the cloud API does not expose the data we need. It is built on Cloudflare Workers and Durable Objects: one DO per charge point, an embedded SQLite outbox for reliability, and every frame in and out archived to object storage. OCPP traffic is also evidence • a regulator or a customer can ask, two years from now, what the meter said at 14:03 on a Tuesday, and the answer needs to exist.

This is not glamorous infrastructure. It is the kind of thing that should work and never be thought about.

Where OCPP genuinely earns its place

A few things OCPP gets right.

Vendor-neutral. A charger from one manufacturer and a backend from another can interoperate, because they share a public spec. No NDA, no exclusive partnership, no waiting for a vendor to expose an API.

Real-time. A WebSocket is much closer to a live wire than a REST API polled every five minutes. Status changes propagate in milliseconds.

Granular. Every meter value is timestamped. Every status change has a reason code. Every transaction has a start and stop reading. For compliance work that matters: an ERE credit is not a monthly summary, it is a sum of authenticated meter readings.

Open. The spec is published. Anyone can read it, implement it, and verify another implementation against it.

Where it does not

OCPP is not perfect, and pretending otherwise wastes everyone's time.

One charger, one CSMS. A charge point can only be connected to one CSMS at a time. If a household wants both their EV app and their home energy app to see the charger, that is not how OCPP works. Repointing a charger to a different CSMS usually means editing the WebSocket URL in the installer menu • not a great user experience.

Vendor interpretation drift. The spec is one document. Real chargers implement it differently. Some report MeterValues every 60 seconds, some every 15. Some include the start meter in StartTransaction, some send it separately. Some return ConnectorErrorCode as NoError when idle, some omit it. You write the CSMS once and then spend months handling edge cases per vendor.

Versions. There is OCPP 1.5 (deprecated), 1.6J (today's workhorse), 1.6S (SOAP, effectively dead), and 2.0.1 (the future, slowly arriving). They are not drop-in compatible. Picking which to support is a real decision.

Insecure transport. Older firmware sometimes only speaks ws://, not wss://. Modern infrastructure refuses unencrypted WebSockets by default. We run a separate transport adapter for chargers stuck on the old transport • per-charger opt-in only, with IP pinning • but it is a workaround, not a long-term answer.

What to ask when you are choosing a charger

If you care about OCPP support • and for ERE registration in the Netherlands, you should • a few practical questions:

• Does it speak OCPP 1.6J, with a configurable backend URL?
• Does it have a MID-certified kWh meter? Required for ERE.
• Can it be repointed to a different CSMS later, or is it locked to the vendor's cloud?
• Does firmware update without losing its configuration?

Most modern chargers from established vendors check these boxes. Some do not, and the spec sheet does not always make that clear.

The boring conclusion

OCPP is a protocol. It is not a strategy, not a product, and not a moat. It is a way for a charger and a backend to agree on the meaning of "kilowatt-hour" and "session ID."

That sounds modest, and it is. But without an open protocol like this, every charger would be its own walled garden, and applications like ours • settling ERE credits across mixed-vendor home fleets, every quarter, automatically • would be impossible to build.

We are glad it exists. We run our own CSMS so we do not have to wait for anyone else to maintain it. And we keep it running quietly in the background, where good infrastructure belongs.

Read more

• OCPP API reference
• Check whether your charger qualifies