Le protocole OCPP 1.5 ne fonctionne pas en WebSocket. Il repose sur des échanges SOAP/XML transportés en HTTP, où chaque message est une requête indépendante. C'est la différence fondamentale avec l'OCPP 1.6 JSON décrit dans l'article Connecter une borne.

Cette particularité a deux conséquences concrètes, détaillées plus bas :

• il n'y a pas de connexion permanente entre la borne et Chargekeeper ;
• les commandes descendantes (celles que la supervision envoie à la borne : démarrage à distance, arrêt, redémarrage…) ne fonctionnent pas avec toutes les bornes — voir la section dédiée.

L'OCPP 1.5 est un protocole ancien, aujourd'hui compatible mais non recommandé. Privilégiez l'OCPP 1.6 JSON dès que la borne le permet. Le 1.5 reste utile pour superviser un parc existant qui ne peut pas être mis à jour.

Prérequis

Avant de commencer, assurez-vous que la borne respecte les conditions suivantes :

• Connexion réseau active — carte SIM (réseau mobile) ou connexion filaire (Ethernet)
• Saisie manuelle de l'URL du serveur OCPP possible, via le firmware, un fichier de configuration, une application fabricant ou un portail web
• Compatibilité OCPP 1.5 SOAP (parfois appelé OCPP 1.5 XML ou OCPP-S selon les fabricants)

Créer le jeton de connexion

Comme pour une borne 1.6, la connexion repose sur un jeton de connexion qui génère l'URL à renseigner dans la borne.

• Ouvrez le module Bornes
• Cliquez sur l'onglet Connecter une borne
• Cliquez sur Créer
• Renseignez les champs suivants :

En format SOAP, l'URL générée est toujours de type Rétro-compatible : elle porte l'identifiant de votre organisation et le jeton dans ses paramètres. Les types Cloud et Organisation ne concernent que le format JSON.

Options supplémentaires

Site associé par défaut — rattache automatiquement la borne à une zone lors de sa première connexion.

Date d'expiration — au-delà de cette date, le jeton ne permet plus d'enregistrer une nouvelle borne.

Choisir entre HTTPS et HTTP

Chargekeeper accepte les deux sur le point d'accès OCPP 1.5.

• Sécurisé (HTTPS) — à privilégier systématiquement.
• Non sécurisé (HTTP) — réservé aux bornes dont la pile TLS est trop ancienne pour négocier une connexion HTTPS moderne. Attention : le jeton circule alors en clair sur le réseau.

Renseigner l'URL dans la borne

Après enregistrement du jeton, copiez l'URL générée. Elle se présente sous cette forme :

https://ocpp-s.service-evse.com/OCPP15?TenantID=000000000000000000000001%26Token=0000000000000000000000ff

Collez l'URL telle quelle. Le %26 entre les deux paramètres est volontaire : c'est la forme encodée du caractère &, attendue par certaines bornes qui traitent mal le & dans un fichier de configuration. Chargekeeper accepte les deux écritures.

Renseignez-la dans le champ du serveur OCPP de la borne. La manière d'y accéder dépend du fabricant : portail web, application constructeur, interface locale ou fichier de configuration.

Vérifiez également que l'identifiant de la borne est renseigné — appelé Charge Box ID, ChargePoint Identity ou Charge Point ID selon les fabricants. C'est sous ce nom que la borne apparaîtra dans la supervision.

Redémarrez la borne pour qu'elle prenne en compte la nouvelle configuration.

Vérifier la connexion

À sa première connexion, la borne envoie un message Boot Notification et s'enregistre automatiquement dans Chargekeeper.

• Ouvrez le module Bornes — la borne doit apparaître dans la liste
• Consultez les logs OCPP pour confirmer la réception du Boot Notification, puis des Heartbeat

Si la borne n'apparaît pas, consultez la section Résolution des problèmes ci-dessous.

Particularités de l'OCPP 1.5 SOAP

Détection de déconnexion

En OCPP 1.6 JSON, la coupure de la connexion WebSocket signale immédiatement qu'une borne est hors ligne. En 1.5 SOAP, cette connexion permanente n'existe pas : la détection repose sur les messages Heartbeat.

Chargekeeper demande à la borne d'émettre un Heartbeat toutes les 60 secondes et considère la borne hors ligne lorsqu'elle a manqué trois Heartbeat consécutifs sans envoyer aucun autre message. Une borne débranchée apparaît donc hors ligne dans les minutes qui suivent, et non instantanément.

Commandes à distance : une limite importante

⚠️ En OCPP 1.5 SOAP, les commandes descendantes ne fonctionnent pas avec toutes les bornes. Vérifiez ce point borne par borne avant de vous engager sur des fonctions de pilotage à distance.

En OCPP 1.6 JSON, la borne garde une connexion ouverte en permanence : la supervision (le CPMS) y fait transiter ses commandes dans les deux sens, et le pilotage à distance fonctionne toujours.

En 1.5 SOAP, cette connexion n'existe pas. Pour envoyer une commande, le CPMS doit appeler la borne, c'est-à-dire ouvrir lui-même une connexion vers elle. Deux conditions doivent être réunies :

1. La borne doit annoncer son adresse de rappel. La norme prévoit qu'elle indique sa propre adresse — son endpoint — dans chacun de ses messages. Chargekeeper la mémorise et la met à jour à chaque échange. Mais beaucoup de firmwares 1.5 ne l'envoient pas, ou annoncent une adresse inutilisable.
2. Cette adresse doit être joignable depuis Internet. Une borne derrière une carte SIM opérateur, une adresse IP privée ou un pare-feu d'entreprise n'est pas atteignable, même si elle annonce correctement son adresse.

En pratique, la seconde condition écarte la majorité des installations : la plupart des bornes sont sur un réseau privé, sans redirection de port entrante.

Ce qui fonctionne toujours

Tout ce que la borne envoie d'elle-même, dans le sens montant : enregistrement à la première connexion, statuts des connecteurs, démarrage et arrêt des sessions par badge, index de consommation, Heartbeat. La supervision, la facturation et le reporting sont donc complets, même sans commandes descendantes.

Ce qui peut ne pas fonctionner

Tout ce que le CPMS envoie à la borne : démarrage et arrêt à distance, redémarrage, déverrouillage de connecteur, lecture et modification de la configuration, changement de disponibilité, réservation, mise à jour de firmware, récupération de diagnostics.

Comment savoir si ça fonctionne

Après la première connexion, lancez une commande simple depuis la fiche de la borne — une lecture de configuration par exemple, sans effet sur l'exploitation. Si elle reste sans réponse, la borne n'est pas joignable en descendant.

C'est une limite du protocole 1.5 lui-même, pas de Chargekeeper. Si le pilotage à distance est indispensable, la borne doit passer en OCPP 1.6 JSON.

Résolution des problèmes

La borne n'apparaît pas dans la supervision

• Vérifiez que l'URL a été copiée intégralement, jusqu'au dernier caractère du jeton
• Vérifiez que l'identifiant de la borne (Charge Box ID) est renseigné
• Vérifiez la connectivité réseau de la borne et l'ouverture du port sortant (443 en HTTPS, 80 en HTTP)
• Si la borne est ancienne, essayez un jeton en Non sécurisé : sa pile TLS peut être incapable de négocier une connexion HTTPS moderne

Certaines bornes modifient l'URL

Certains firmwares ajoutent automatiquement un caractère / à la fin de l'URL configurée, voire l'identifiant de la borne. Chargekeeper le tolère et extrait correctement les paramètres. Aucune action n'est nécessaire de votre côté.

La borne remonte ses sessions mais ne répond pas aux commandes

C'est le comportement attendu lorsque la borne n'annonce pas d'adresse de rappel exploitable, ou qu'elle n'est pas joignable depuis Internet. Voir Commandes à distance ci-dessus : le sens montant reste complet, seul le pilotage à distance est concerné.

Bonnes pratiques

• Privilégier OCPP 1.6 JSON dès que la borne le permet ; réserver le 1.5 aux parcs existants
• Préférer le chiffrement sécurisé et ne basculer en HTTP qu'en dernier recours
• Utiliser un jeton par contexte (installation, test, production)
• Vérifier la première connexion dans les logs OCPP avant de quitter le site
• Documenter les bornes 1.5 du parc : leurs commandes à distance dépendent de leur accessibilité réseau