Each lesson explains one part of OCPP in two minutes and ends with an exercise on your own charger. The test server tells you right away whether you got it: no account and no data needed. It's a course, not a certification.
No charger at hand? Try the virtual charger in the dashboard tester.
The charger opens a WebSocket to a URL that ends in its identity, and asks for a subprotocol (ocpp1.6 or ocpp2.0.1). Almost every charger appends the identity itself: the URL field takes the address without it.
Why it matters: This is where most attempts fail: the identity written twice, an extra slash, the key pasted into the URL, or a subprotocol the server doesn't offer. The charger never even gets to speak OCPP.
The first thing it sends is a BootNotification with its vendor, model and firmware. The server answers Accepted and tells it how often to send a Heartbeat.
Why it matters: Without an accepted Boot the charger does nothing else; without heartbeats the server can't tell it's alive and marks it disconnected.
OCPP 1.6 defines security profiles: profile 2 is an encrypted connection (wss://) plus user and key (Basic Auth), with the identity as the user. It's the reasonable minimum for a charger on the internet.
Why it matters: Without encryption the key travels in the clear. Without a key, anyone who knows the identity can pose as the charger. Many chargers ship with the profile set to 0.
Every message carries its date and time. The charger takes it from the internet (NTP) or from the server.
Why it matters: With the clock off, sessions show the wrong time in reports and invoices, and a time-of-use tariff charges the wrong slot.
During a session the charger sends meter values. The one you bill on is the cumulative energy register: Energy.Active.Import.Register. MeterValueSampleInterval sets how often.
Why it matters: Without that register you can't bill for energy. With the interval at 900 s, a short session shows no energy until it ends: a charger we tested came like that from the factory.
The card is read (Authorize), the session starts (StartTransaction, with the starting meter) and ends (StopTransaction, with the final one). Then the connector goes back to Available.
Why it matters: Order matters: a charger we tested sent Available one second before StopTransaction, and the server treated the session as abandoned before getting its energy.
The server can ask the charger to start or stop a session (RemoteStartTransaction and RemoteStopTransaction in 1.6; RequestStart/StopTransaction in 2.0.1).
Why it matters: It's what QR payment, the dashboard's start button and any app rely on. If the charger rejects it, none of that works.
All seven green?
Your charger speaks OCPP the way it should: it will connect to any server that follows the standard, ours included. To move it to your account, swap the test code for your brand and enter the key the dashboard gives you.
Create accountBrand guides: where each setting lives · OCPP errors, one by one