OCPP server development
Building an OCPP 1.6 server and the platform around it
What the protocol handles, what it takes to work with chargers you did not build, and where these projects tend to stall.
The evidence on this page is one project: an OCPP 1.6 server the principal wrote solo while employed at an IoT product company, before Pebble Logic was founded.
What the protocol handles
OCPP 1.6 is the open protocol between a charge point and the central system that manages it. The charger announces itself, reports its status, asks whether a driver is authorized, reports when a transaction starts and stops and what the meter read, and accepts commands back. Everything an operator knows about a charger, and everything they can do to it remotely, passes through that exchange.
The server is only part of the job. Around it sits the platform: a data model for sessions and users, an API, and a frontend for operators. On the project described here, the principal researched the protocol and wrote the OCPP 1.6 server from scratch, then built that platform as sole engineer: a Flask and PostgreSQL REST API and a React frontend.
Third-party charger interoperability
Working with hardware you do not manufacture is the point of an open protocol, and it is also where the work is. Chargers from different vendors are written against the same specification by different teams. A central system has to be strict enough to keep its records consistent and tolerant enough to work with a charger it has not seen before.
The server described here interoperated with third-party chargers the company did not build. That was the requirement that made the protocol necessary in the first place.
RFID authorization
A driver presents a card at the charger, the charger sends the card's identifier to the central system, and the central system decides whether a session may start. That decision is where account status and business rules live, so it belongs in the platform rather than in each charger.
RFID authorization was part of the platform, so drivers could start a session at the charger.
Session and usage tracking
Each charging session is a transaction with a start, a stop, and meter readings in between. Usage tracking turns those into records an operator can bill and report from. Charge-complete notification tells the driver the session has ended.
The platform tracked usage for billing and reporting and sent charge-complete notifications. When the data behind a fleet outgrows a single database, the storage design becomes the next problem: the principal also rebuilt a commercial solar monitoring platform serving more than 40,000 installations, sustaining more than 9,000 database inserts per second on a partitioned PostgreSQL and Redshift split routed by date range.
Where these projects stall
- The protocol itself
- Most application developers have never written a protocol server, and the OCPP server is usually the first part of the platform that has to work. On the charging platform described here, nobody on the team had worked with the protocol before.
- Hardware you did not build
- Interoperability is established against the chargers you will actually deploy, not against a simulator. Getting real third-party units on the bench early is cheaper than finding the differences in the field.
- Scope that is really a standards question
- OCPP sits beside a wider energy standards landscape, and charging projects drift into it. It is worth deciding early which of those questions belong to the software and which belong to a test lab.
On standards
Our implementation experience is OCPP 1.6 specifically. IEEE 2030.5 and CSIP, SunSpec Modbus, IEEE 1547, UL 1741 SA and SB, and CPUC Rule 21 are working knowledge: we can talk through where a product sits in that landscape, but we have not implemented them, tested to them, or earned credentials in them.
Where to start
Device Telemetry and Protocol Review
$7,500 fixed / two weeks
Credited in full against a build engagement of $25,000 or more started within 90 days.
Telemetry requirements captured with you, candidate device-to-platform protocols evaluated against them, OCPP among them where charging is in scope, a recommended telemetry architecture, a capacity projection at target fleet scale, a risk register, and a scoped estimate for the build that follows. One device type or product line, one revision round.
It is an engineering review, not a compliance or certification service.
Tell us about the chargers
Send a short description of the hardware, the platform you have now or the one you need, and the milestone you are working toward.