Référence OCPP
L’Open Charge Point Protocol, documenté comme on en a réellement besoin pendant l’implémentation : ce que porte chaque message, ce que signifient les valeurs, et les endroits où la spécification se lit facilement de travers.
Référence des messages OCPP 1.6
Les 28 messages, groupés par feature profile. La version que parle la majorité du matériel déployé. Clés de configuration à plat, transactions en trois messages, et sécurité laissée au déploiement.
Référence des messages OCPP 2.0.1
Les 64 messages, groupés par functional block. Restructure la configuration, les transactions et la sécurité. De plus en plus ce que spécifient les nouveaux appels d’offres.
Codes d’erreur OCPP
Les 16 valeurs de ChargePointErrorCode : ce que chacune signifie, ce qui la provoque habituellement, et si elle impose un déplacement sur site ou se résorbe seule.
OCPP 1.6 face à 2.0.1
Où est passé chaque message 1.6, le modèle d’équipement qui a remplacé la configuration à plat, les nouveaux profils de sécurité, et ce que coûte réellement une migration.
Ce qu’est OCPP
OCPP — l’Open Charge Point Protocol — est la façon dont une borne de recharge parle au backend qui la gère. La borne ouvre une connexion WebSocket vers un système de gestion de bornes, et à partir de là tout se fait en messages JSON dans les deux sens : la borne rapporte son statut, ses relevés de compteur et ses transactions ; le backend autorise les utilisateurs, pousse la configuration et pilote la puissance.
Il est maintenu par l’Open Charge Alliance, et c’est la raison pour laquelle une borne d’un fabricant peut être exploitée par un réseau construit par quelqu’un d’autre.
La version que parle la majorité du matériel déployé est la 1.6, publiée en 2015 et toujours dominante. La 2.0.1 restructure la configuration, les transactions et la sécurité, et elle est de plus en plus ce que spécifient les nouveaux appels d’offres. Les deux circulent sur le même transport, et aucune ne sait lire les messages de l’autre.
Comment cette référence est organisée
Il y a une page par message, pour les deux versions : 28 en OCPP 1.6 et 64 en OCPP 2.0.1. Lorsqu’une action existe dans les deux — BootNotification, Authorize, SetChargingProfile et beaucoup d’autres — chaque version a sa propre page, car les charges utiles diffèrent même quand le nom survit.
La 1.6 regroupe ses messages en 6 profils fonctionnels, qui sont l’unité de conformité : Core est obligatoire, le reste est optionnel, et une borne déclare ceux qu’elle implémente. Ces profils sont Core, Firmware Management, Local Auth List Management, Reservation, Smart Charging, Remote Trigger.
La 2.0.1 remplace les profils par 16 blocs fonctionnels, et ajoute des domaines entiers auxquels la 1.6 n’avait aucune réponse — sécurité, messages d’affichage, tarification et coûts. La comparaison des versions détaille ce qui change réellement.
Chaque page de message suit la même structure : à quoi sert le message, les champs de requête et de réponse avec leurs types et leur caractère obligatoire, chaque valeur énumérée, une trame OCPP-J complète que vous pouvez coller dans un test, et les notes d’implémentation — ces parties qui figurent techniquement dans la spécification mais qu’il est facile de manquer jusqu’à ce qu’elles vous coûtent une semaine.