OCPP 1.6 Messages principaux. Les 6 messages qui font tourner chaque borne

OCPP 1.6 compte environ 30 types de messages. En pratique, six d'entre eux gèrent à peu près 90% de tout. Comprenez ces six-là et vous comprenez comment la recharge VE fonctionne au niveau protocole.

1. BootNotification

Le tout premier message après connexion. La borne s'annonce :

{
  "chargePointVendor": "Acme",
  "chargePointModel": "FastCharge-50",
  "chargePointSerialNumber": "SN-2024-001",
  "firmwareVersion": "2.3.1"
}

Le backend répond Accepted, Pending ou Rejected. Si une borne reçoit Pending en boucle, c'est presque toujours un problème de configuration côté backend. la borne existe mais n'a pas été activée dans le CSMS.

2. Authorize

L'utilisateur présente un badge RFID, l'appli envoie un token, ou la borne lit une carte bancaire. Dans tous les cas, la borne demande : "Cette personne a-t-elle le droit de charger ?"

Rendering diagram...

Réponses possibles : Accepted, Blocked, Expired, Invalid, ConcurrentTx (ce badge est déjà en charge ailleurs).

Un détail qui sauve des déploiements : les backends intelligents poussent une Liste d'Autorisation Locale vers la borne, pour que même sans internet, les badges connus puissent démarrer des sessions. J'ai vu des sites où la 4G était assez instable pour que 20% des tentatives d'autorisation échouent sans liste locale. Avec elle, zéro échec.

3. StartTransaction

Une fois autorisé, la borne démarre une transaction :

{
  "connectorId": 1,
  "idTag": "RFID-ABC123",
  "meterStart": 1000,
  "timestamp": "2026-01-07T14:30:00Z"
}

Le backend répond avec un transactionId. Ce numéro lie chaque MeterValues et le StopTransaction final. Sans lui, la facturation s'effondre.

4. StopTransaction

La session se termine. l'utilisateur débranche, l'appli envoie un arrêt, une erreur survient :

{
  "transactionId": 42,
  "meterStop": 15000,
  "timestamp": "2026-01-07T16:45:00Z",
  "reason": "EVDisconnected"
}

Raisons d'arrêt : EVDisconnected, Remote, Local, PowerLoss, EmergencyStop. Chacune compte pour la facturation et l'audit.

Si la borne perd internet pendant une session, elle doit stocker le StopTransaction hors ligne et l'envoyer quand la connexion revient. C'est non-négociable. sans ça, vous perdez du chiffre d'affaires à chaque coupure réseau. J'ai vu des opérateurs perdre des milliers d'euros par mois à cause de bornes qui laissaient tomber silencieusement des StopTransaction parce que la file d'attente hors ligne n'était pas correctement implémentée.

5. MeterValues

Pendant qu'une session est active, la borne envoie des mesures d'énergie périodiques :

{
  "connectorId": 1,
  "transactionId": 42,
  "meterValue": [{
    "timestamp": "2026-01-07T15:00:00Z",
    "sampledValue": [
      {"value": "7500", "measurand": "Energy.Active.Import.Register", "unit": "Wh"},
      {"value": "11.2", "measurand": "Power.Active.Import", "unit": "kW"},
      {"value": "16.1", "measurand": "Current.Import", "unit": "A"}
    ]
  }]
}

C'est ce qui alimente l'écran "charge en cours" dans les applis. Le compteur de kWh qui monte en temps réel ? Ce sont des MeterValues qui arrivent toutes les 30 à 60 secondes.

6. StatusNotification

La borne signale les changements d'état du connecteur :

Le cycle complet

Rendering diagram...

Six messages. C'est le coeur d'OCPP 1.6. Les ~24 types restants servent au contrôle à distance, à la gestion du firmware, aux diagnostics et à la configuration. mais ces six-là sont ce que votre backend traitera des milliers de fois par jour.