OCPP-berichten: complete referentie van 1.6 en 2.0.1

Wie stuurt wat: richting van berichten

Elk OCPP-bericht heeft een vaste richting. Berichten van de laadpaal naar het beheersysteem melden iets dat gebeurd is; berichten van het beheersysteem naar de laadpaal geven een opdracht.

Dit onderscheid bepaalt hoe je een probleem onderzoekt. Krijg je geen StatusNotification meer binnen, dan zwijgt de paal. Wordt een Reset niet uitgevoerd, dan komt de opdracht niet aan of wordt hij geweigerd — twee heel verschillende sporen.

// [MessageTypeId, UniqueId, Action, Payload]
[2, "d3f1a8", "Heartbeat", {}]

// Antwoord: [MessageTypeId, UniqueId, Payload]
[3, "d3f1a8", { "currentTime": "2026-08-12T09:14:22Z" }]

// Fout: [MessageTypeId, UniqueId, ErrorCode, ErrorDescription, ErrorDetails]
[4, "d3f1a8", "NotSupported", "Onbekende actie", {}]

// 2 = CALL (verzoek)  ·  3 = CALLRESULT (antwoord)  ·  4 = CALLERROR (fout)

OCPP 1.6 — Core-profiel (verplicht)

Het Core-profiel bevat de zestien berichten die elke OCPP 1.6-laadpaal moet ondersteunen. Hiermee kun je laden, autoriseren, uitlezen en resetten.

OCPP 1.6 — de vijf optionele profielen

De overige veertien berichten zitten in vijf optionele profielen. Welke een laadpaal ondersteunt, verschilt per merk, model en firmwareversie — vraag dit expliciet na voordat je functionaliteit belooft die erop leunt.

OCPP 2.0.1 — de zestien functieblokken

OCPP 2.0.1 groepeert berichten in functieblokken A tot en met P. De indeling is fijnmaziger dan de profielen van 1.6, waardoor je preciezer kunt afspreken wat een implementatie moet kunnen.

Blok B en N zijn de grootste verandering ten opzichte van 1.6. Blok B bevat het devicemodel, waarmee je een laadpaal kunt vragen welke componenten en variabelen hij heeft in plaats van dat per merk hard te coderen. Blok N maakt monitoring mogelijk waarbij de paal zelf meldt dat een waarde buiten de grenzen valt.

Wat je hiermee doet bij een koppeling

1. 1Vraag per laadpaalmodel op welke profielen (1.6) of functieblokken (2.0.1) worden ondersteund, inclusief firmwareversie.
2. 2Leg naast je functionele wensen welke berichten daarvoor nodig zijn. Load balancing zonder Smart Charging-profiel is niet te bouwen.
3. 3Test de berichten die je nodig hebt daadwerkelijk op één paal per model, voordat je uitrolt. Ondersteuning op papier en ondersteuning in de praktijk lopen regelmatig uiteen.
4. 4Log het ruwe berichtenverkeer aan beide kanten. Zonder de daadwerkelijke JSON blijft elke diagnose een vermoeden.
5. 5Let op DataTransfer. Fabrikanten stoppen daar functionaliteit in die buiten de standaard valt; die moet je apart in kaart brengen en werkt niet zomaar met een ander beheersysteem.

Dat laatste punt is de meest onderschatte bron van leveranciersafhankelijkheid. Een paal kan volledig OCPP-compatibel zijn en tóch alleen alle functies bieden binnen het platform van de fabrikant, omdat de rest via DataTransfer loopt.