OCPP reference
The Open Charge Point Protocol, documented the way you actually need it while implementing: what each message carries, what the values mean, and where the spec is easy to read wrongly.
OCPP 1.6 message reference
All 28 messages, grouped by feature profile. The version most deployed hardware speaks. Flat configuration keys, three-message transactions, and security left to the deployment.
OCPP 2.0.1 message reference
All 64 messages, grouped by functional block. Restructures configuration, transactions and security. Increasingly what new procurement specifies.
OCPP error codes
The 16 ChargePointErrorCode values, what each means, what usually causes it, and whether it needs a site visit or clears on its own.
OCPP 1.6 vs 2.0.1
Where each 1.6 message went, the device model that replaced flat configuration, the new security profiles, and what migrating actually costs.
What OCPP is
OCPP — the Open Charge Point Protocol — is how an EV charger talks to the backend that manages it. The charger opens a WebSocket to a Charging Station Management System, and from that point everything is JSON messages in both directions: the charger reporting status, meter readings and transactions; the backend authorizing users, pushing configuration and controlling power.
It is maintained by the Open Charge Alliance, and it is the reason a charger from one manufacturer can be operated by a network built by someone else.
The version most deployed hardware speaks is 1.6, published in 2015 and still dominant. 2.0.1 restructures configuration, transactions and security, and is increasingly what new procurement specifies. Both run over the same transport and neither can read the other's messages.
How this reference is organised
There is one page per message, for both versions: 28 in OCPP 1.6 and 64 in OCPP 2.0.1. Where an action exists in both — BootNotification, Authorize, SetChargingProfile and many others — each version gets its own page, because the payloads differ even where the name survives.
1.6 groups its messages into 6 feature profiles, which are the unit of conformance: Core is mandatory, the rest are optional, and a charger states which it implements. Those profiles are Core, Firmware Management, Local Auth List Management, Reservation, Smart Charging, Remote Trigger.
2.0.1 replaces profiles with 16 functional blocks, and adds whole areas that 1.6 had no answer for — Security, Display Message, Tariff and Cost. The version comparison covers what actually changes.
Every message page carries the same structure: what the message is for, the request and response fields with types and requiredness, every enumerated value, a complete OCPP-J frame you can paste into a test, and the implementation notes — the parts that are technically in the spec but easy to miss until they cost you a week.