FAQ

Trois prérequis pour connecter une borne de recharge :

• la borne est connectée de manière stable à internet (réseau filaire de préférence) ;
• la borne possède un outil d’administration accessible pour changer l’URL du CSMS ;
• la borne possède un firmware à jour avant la première connexion au CSMS.

Il est possible de mettre à jour la borne à distance seulement après la première connexion. Attention : une mise à jour de firmware peut entraîner des dysfonctionnements ou des régressions. Il est recommandé de toujours tester le firmware sur une borne de test.

Si la borne utilise le réseau local, les équipes IT doivent autoriser la sortie des bornes vers le domaine charge-angels.com (port TCP 443) et désactiver le pare-feu en sortie, ou ajouter en liste blanche les adresses IP de notre serveur (à demander à un administrateur).

Le réseau doit être filaire de préférence, pour éviter une limite de distance ou de débit. La latence réseau tolérée doit être inférieure à 500 ms.

Les bornes peuvent utiliser plusieurs modes de communication : LAN (Ethernet) ou WAN (Wi-Fi). Dans la plupart des cas, la borne dialogue par défaut avec le DHCP (Dynamic Host Configuration Protocol) du réseau local et se voit attribuer une adresse IP automatiquement ; dans les autres cas, une IP manuelle doit être définie dans la borne. La box internet (routeur) se connecte à internet via le fournisseur du client : ADSL, fibre ou GSM.

Si vous préférez le réseau 4G, il faut commander des cartes SIM M2M (dédiées IoT), avec l’itinérance de préférence. Pour le débit data, comptez 200 kBytes par point de charge (PDC).

• La configuration de l’APN dépend de l’opérateur.
• Il est préférable d’utiliser des cartes SIM avec option itinérance activée : le choix du meilleur réseau est effectué en temps réel. L’itinérance peut être France ou Monde, en fonction des besoins.
• Il faut en général 200 Mo de forfait data par point de charge en utilisation intensive.
• L’utilisation d’un VPN n’est pas utile si la borne communique en WSS.

ChargeAngels utilise une connexion WebSocket sécurisée (WSS) entre la borne et le backend. Nous supportons uniquement le protocole TLS 1.3 (TLS 1.2 étant déprécié). ChargeAngels supporte les certificats SSL de type RSA et ECDSA. Nous utilisons Node.js avec la bibliothèque uWebSockets.js pour la gestion des WebSockets.

• Créé en 2011, WebSocket (WS) désigne un protocole réseau de la couche application « bidirectionnel, asynchrone, full-duplex » entre client et serveur, normalisé par l’IETF dans la RFC 6455 et par le W3C.
• WebSocket permet d’ouvrir une connexion permanente full duplex entre le client et le serveur : le serveur peut envoyer des données à un client de sa propre initiative, à l’inverse du protocole HTTP.
• WebSocket Security (WSS) utilise, comme HTTPS, la couche de transport TLS pour chiffrer les communications : il est donc plus sécurisé.

Tels que décrits dans la spécification « OCPP 1.6 security whitepaper edition 3 », nous supportons :

• Security Profile 1 : WS avec authentification basique (utilisateur / mot de passe ou Authorization Key, au choix) ;
• Security Profile 2 : authentification basique ou WSS TLS avec le certificat racine du serveur (ISRG Root X1) ;
• Security Profile 3 : WSS TLS côté borne et côté serveur (testé, mais non officiellement productif).

Tests de l’OCA : les cas de test TC_085_CSMS (authentification basique, couple utilisateur / mot de passe valide) TC_086_CSMS (TLS, certificat côté serveur valide) et TC_087_CSMS (TLS, certificat côté client valide) sont validés avec l’outil de test de l’Open Charge Alliance.

Authorization Key : minimum 16 caractères et encodage hexadécimal, entre 20 et 40 caractères.

Il est conseillé de toujours tester la première connexion de la borne avec un Security Profile 1 (WS), puis 2 (WS et WSS), puis 3 (WSS).

Un Tenant est un sous-espace du domaine principal, par exemple cpo1.charge-angels.com.

• Si vous avez choisi la solution SaaS, vous devez organiser votre Tenant dans l’onglet « Organisation » du CSMS.
• Si vous avez choisi la solution Full Cloud, vous avez accès au « Master Tenant » et pouvez créer autant de « Cloud Tenants » que nécessaire.

Le Tenant possède une base de données utilisateur commune, dont la clé centrale est l’e-mail. Il peut être décomposé en plusieurs niveaux hiérarchiques : Entreprises, Sites et Zones.

• Les Sites peuvent être des zones géographiques différentes pour un seul et même client (exemple : des dépôts de bus).
• Les Sites peuvent aussi être des sous-clients différents, qui auraient une base de données d’utilisateurs commune.
• La Zone est un regroupement de bornes ; elle définit la topologie physique du lieu : une zone peut être égale à un TGBT ou à un abonnement (exemple : un TJ de 220 kVA).
• Le SmartCharging est séparé par Zone (puissance maximale déclarée au TGBT).

Un « Token » est une URL de connexion WSS utilisée pour que la borne se connecte aux serveurs du CSMS ChargeAngels. Le token est unique et propre à une Zone.

Lorsque votre organisation est créée, vous pouvez créer un ou plusieurs tokens de connexion au backend, depuis le menu « Borne » puis « Connectez une borne » : créez-le, ajoutez un titre, une date de validité et une Zone, puis sauvegardez.

Vous pouvez copier le token pour une utilisation ultérieure ou immédiate (par exemple « OCPP 1.6 JSON »). Il peut être communiqué aux équipes de déploiement des bornes sur le terrain. Pour des raisons de cybersécurité, ChargeAngels a choisi de créer des tokens dynamiques avec date de validité, contrairement aux autres CSMS.

Le token (ou URL) se compose de 4 parties

• le préfixe : HTTP / HTTPS / WS ou WSS ;
• « OCPP16 » ou « OCPP201 » en fonction de la version d’OCPP ;
• la première partie du jeton concerne l’identifiant unique du tenant ;
• la deuxième partie concerne l’identifiant du token lui-même, associé à une zone ;
• la dernière partie est le nom de la borne : le ChargeBoxID.

wss://charge-angels.com/OCPP16/<identifiant-du-tenant>/<identifiant-du-token>/BORNE-01

Une fois le token copié dans l’administration de la borne, celle-ci ouvre un socket en direction des serveurs du CSMS. La borne (ici BORNE-01) apparaît automatiquement dans le dashboard, sans aucune action à faire côté backend. Une fois la borne visible, modifiez ses attributs (puissance maximale, localisation, connecteurs…).

Dans l’administration de certaines bornes, l’URL et le ChargeBoxID sont séparés en plusieurs champs : « Host », « Port », « Path » (chemin) et « ChargeBoxID » (nom de la borne). Il faut parfois vérifier l’URL ainsi formée (en respectant les différents slashs).

Nommer ses bornes

Il est recommandé de fixer une convention de nommage pour le nom de la borne. Le ChargeBoxID est associé en base de données à toutes les informations de la borne et à ses historiques de recharge : vous ne pourrez pas le modifier par la suite sans perdre cet historique. Exemple de convention : « VILLE-LIEU-BORNE-01 ». Attention : le ChargeBoxID est limité à 48 caractères maximum (limite Gireve).

Une fois le token et le nom de la borne ajoutés, la borne pointe vers le tenant, le token et donc la zone concernée. Il faut parfois redémarrer la borne pour la prise en compte de ces paramètres. Tant que la borne n’apparaît pas dans le dashboard, c’est que l’URL est malformée ou que la borne est hors réseau : vérifiez les logs.

Expiration du token

La BORNE-01 devra être mise en service et connectée avec le token créé avant la date d’expiration de celui-ci, sinon le BootNotification OCPP sera rejeté. Lorsque la borne a été acceptée une première fois par le backend, le token est mémorisé en base : même après expiration, la borne pourra redémarrer sans problème.

Il est recommandé de conserver les tokens, même expirés : lors d’autres mises en service, il suffira de prolonger leur date de validité. En revanche, vous pouvez supprimer les tokens non productifs, ce qui évite les erreurs.

Il est conseillé de surveiller les logs de ChargeAngels lors des mises en service, et de les consulter régulièrement.

Certaines bornes nécessitent le certificat racine de notre serveur : ISRG Root X1 (Let’s Encrypt). Nous pouvons vous le fournir sur demande, mais vous pouvez aussi l’obtenir depuis une invite de commande Linux ou macOS en tapant la commande suivante :

curl https://letsencrypt.org/certs/isrgrootx1.pem

Copiez le certificat affiché dans la réponse (ISRG Root X1), collez-le dans un fichier texte, puis sauvegardez-le sous le nom « ISRG Root X1.crt ». Sauvegardez-le en local et dans la borne : au redémarrage, la borne utilisera ce certificat ainsi que l’URL WSS pour se connecter au backend.

Ce certificat est utilisé en OCPP avec le Security Profile 2 et le certificat côté serveur (Server Side Certificate).

Une fois la borne connectée au backend, il est possible de changer tous les paramètres OCPP à distance. Certains paramètres sont normalisés dans la spécification OCPP, d’autres sont optionnels, voire personnalisés (custom).

Liste des paramètres à vérifier en fonction de vos besoins :

Certaines bornes comportent un champ « CSMS URL » et « ChargeBoxID » : cela autorise le changement de l’URL du backend ou du nom de la borne à distance, sans avoir à entrer dans la configuration de la borne sur site.

Vous pouvez exporter tous les paramètres OCPP pour les comparer ultérieurement avec ceux d’autres bornes. Certaines clés sont disponibles uniquement en lecture et non en écriture.

La première chose à surveiller lors d’une mise en service est la stabilité des WebSockets. L’ouverture d’un WebSocket est à l’initiative seule de la borne et non du CSMS.

Les logs se consultent dans la section « Log » du CSMS, où vous pouvez filtrer par borne, par sévérité et par action. Deux familles de logs sont utiles : les logs WebSocket (connexion) et les logs OCPP (messages échangés), détaillés dans les deux questions suivantes.

Si les WebSockets ne sont pas stables (ouvertures et fermetures intempestives), la borne ne pourra pas démarrer (boot) correctement au travers d’OCPP et sera dans un état incertain.

Dans la section « Log », filtrez les actions WsServerConnectionOpen et WsServerConnectionClose.

• WsServerConnectionClose indique une fermeture du socket côté borne (à l’initiative de la borne), par exemple : Close > WS Connection ID 'FsRi9' closed with code '1000', reason: 'Normal closure'.
• Le CSMS n’a pas plus d’information sur la raison de cette coupure. Le plus souvent, elle est due à une coupure du réseau (l’horaire de fermeture et d’ouverture est alors le même pour toutes les bornes) ou de l’alimentation électrique.
• Vous pouvez surveiller le nombre de WsServerConnectionClose : il ne devrait pas y en avoir plus de quelques-uns par jour.

Le CSMS effectue un « ping » vers la borne toutes les 60 secondes ; si 2 pings échouent, nous fermons le WebSocket. La borne effectue également un ping de son côté toutes les 30 secondes vers notre serveur. La fréquence du ping peut être ajustée via le paramètre OCPP WebSocketPingInterval.

Dans la section « Log », vous pouvez filtrer sur votre borne et sur quelques actions simples, par exemple : OcppBootNotification, OcppStatusNotification, OcppStartTransaction, OcppStopTransaction, OcppMeterValues. Les logs se lisent de bas en haut (le plus récent correspond à la première ligne).

Quatre niveaux de sévérité existent, comme dans tous les systèmes informatiques :

• ERROR : critique, ne doit jamais apparaître ;
• WARNING : grave mais sans conséquence pour le fonctionnement ;
• INFO : informations lisibles (textuelles) ;
• DEBUG : informations de debug, avec les requêtes et réponses JSON.

En DEBUG, le détail des messages contient le sens des requêtes, avec la convention suivante :

• << = requête / réponse de la borne vers le backend ;
• >> = requête / réponse du backend vers la borne.

La même convention est utilisée pour le serveur JSON, OCPI, OICP, Batch ou vers les API externes (le backend à droite).

Les logs correspondant aux commandes OCPP JSON peuvent aussi être lus à un niveau plus bas, en consultant les messages WebSocket juxtaposés : WsClientMessage pour la requête et WsServerMessage pour la réponse, accompagnés d’un identifiant unique (UID) pour chaque message côté CSMS et côté borne. Par exemple :

Message > Send WS Message Request: '[2,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0","ClearChargingProfile",{"connectorId":1}]'

Message > Received WS Message: '[3,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0",{"status":"Unknown"}]'

Ce format est parfois requis pour communiquer avec les fabricants de bornes lors d’un débogage.

ChargeAngels possède une base de données utilisateur commune par Tenant. Les utilisateurs possèdent 3 niveaux de permissions (rôles) :

• Administrateur : tous les droits du Tenant ;
• Standard : droits relatifs aux clients finaux destinés à la charge de véhicules électriques ;
• Administrateur de Site : utilisateur « Standard » avec des droits d’administration relatifs à un ou plusieurs Sites.

Le détail des autorisations par rôle est décrit dans la documentation d’intégration, disponible sur demande.

Un quatrième rôle de type « Demo » est aussi disponible pour l’affichage public anonymisé. Un rôle spécifique existe également pour les communications entre serveurs (API) : il peut être activé sur un utilisateur générique, l’« utilisateur Technique », qui ne peut pas être utilisé pour se connecter depuis le frontend (application web ou mobile).

Les trois questions suivantes détaillent les règles générales, l’assignation aux sites et l’état des comptes.

Les nouveaux utilisateurs peuvent créer leur compte :

• via l’interface web, directement sur la page https://<sous-domaine>.charge-angels.com/auth/register ;
• via l’application mobile, après le scan du QR code de l’organisation pour les clients en mode « SaaS », ou directement à l’ouverture de l’application pour les clients en « Full Cloud ».

Dans les deux cas, ils doivent valider les conditions de licence « End-User Licence Agreement » (EULA), conformément au RGPD (Règlement Général sur la Protection des Données).

• L’e-mail constitue la clé unique d’un utilisateur en base de données.
• Pour des raisons de sécurité, les mots de passe sont chiffrés en base de données : ils ne sont pas visibles en clair, même pour les administrateurs.
• Un utilisateur qui se connecte 3 fois avec un mauvais mot de passe voit son compte bloqué ; seul un administrateur peut le débloquer sur demande.
• Un utilisateur qui oublie son mot de passe peut faire une demande automatique de renouvellement par e-mail, depuis l’application web (https://<sous-domaine>.charge-angels.com/auth/reset-password) ou depuis l’application mobile (« Mot de passe oublié ? »).
• Seul un administrateur peut élever les permissions d’un utilisateur « Basic » vers « Administrateur » ou « Basic / Administrateur de Site ». De même, un administrateur de Site peut désigner un autre administrateur de Site sur le ou les Sites auxquels il est assigné.

La base de données utilisateur étant commune au Tenant, l’administrateur peut décider de la stratégie d’assignation des utilisateurs par Site : soit le flag « Assignation automatique des nouveaux utilisateurs sur ce site » est activé sur tous les sites, soit il est désactivé.

1. Flag désactivé : le nouvel utilisateur ne voit aucune borne après la création de son compte. Il appartient à l’administrateur (ou à l’administrateur de Site) d’assigner cet utilisateur manuellement. Il pourra ensuite voir l’ensemble des points de charge du site et démarrer une session de charge.
2. Flag activé : le nouvel utilisateur est assigné à tous les sites où le flag est actif ; il peut voir l’ensemble des points de charge de ces sites et démarrer une session de charge. Il appartient alors à l’administrateur (ou à l’administrateur de Site) de désassigner l’utilisateur qui ne doit pas voir le ou les sites en question.

Notes :

• Tous les utilisateurs de type « Administrateur » sont par défaut assignés à l’ensemble des sites créés dans le Tenant.
• Un administrateur peut créer un utilisateur manuellement avec le mot de passe de son choix. Dans ce cas, il doit également l’assigner manuellement aux sites pour lesquels il aura des droits.
• Le flag « Ce site est public » ne concerne que le scénario de l’itinérance (Gireve / Hubject).

Il est également possible d’activer ou de désactiver, pour tout le Tenant, la stratégie de création des comptes des nouveaux utilisateurs, depuis la section « Paramètres techniques » / « Utilisateurs » :

• si activé : tous les nouveaux utilisateurs peuvent créer leur compte de manière automatique ;
• si désactivé : une alerte push et un e-mail vous sont envoyés pour décider de l’activation ou non de ce compte. Il faut ensuite vérifier l’assignation automatique sur le ou les sites, ou l’assigner manuellement, en fonction de la stratégie définie ci-dessus.

Si le client décide de créer plusieurs comptes client sur le même Tenant, il lui appartient de gérer correctement tous ses utilisateurs (anciens et nouveaux).

Il existe plusieurs niveaux d’état d’un compte utilisateur :

• Actif : activé, il bénéficie de l’ensemble des fonctionnalités du site ;
• Suspendu : compte rendu inactif par un administrateur, il peut être réactivé a posteriori ;
• Inactif : compte non utilisé depuis plus de 6 mois (aucune connexion à la plateforme) ;
• Verrouillé : blocage automatique après trois tentatives de mot de passe erronées ;
• En attente : en attente de validation du compte par un administrateur.

Un mécanisme automatique de vérification et de désactivation des comptes utilisateurs inactifs est en place sur la plateforme ChargeAngels, en respect de la réglementation européenne RGPD.

Fonctionnement

La tâche s’exécute chaque lundi à minuit (Europe/Paris). Elle cible uniquement les utilisateurs actifs avec le rôle Basic (les comptes techniques sont exclus). Le processus se déroule en deux étapes :

1. Avertissement (à 6 mois d’inactivité) : les utilisateurs qui ne se sont pas connectés depuis 6 mois reçoivent une notification d’avertissement, ce qui leur laisse le temps de se reconnecter pour éviter la désactivation.
2. Désactivation (à 7 mois d’inactivité) : si l’utilisateur ne s’est toujours pas reconnecté un mois après l’avertissement, son compte passe automatiquement au statut Inactif et une notification de changement de statut lui est envoyée.

Critères vérifiés : date de dernière connexion, date d’acceptation des CGU (EULA), date de la dernière transaction de recharge. Configuration actuelle : seuil d’inactivité de 6 mois, exécution chaque lundi à 00 h 00.

Il est possible de rendre une borne totalement ouverte ou très sécurisée en fonction des paramétrages dans ChargeAngels (Organisation / Zones), mais surtout en fonction des paramètres de la borne (et du modèle).

Lorsque le contrôle d’accès est désactivé côté ChargeAngels, quel que soit le paramétrage de la borne, ChargeAngels accepte tous les démarrages de transaction demandés par la borne. Dans ce cas, il est impossible de bloquer des utilisateurs en particulier, ni de facturer.

Lorsque le contrôle d’accès est activé, le comportement dépend du paramétrage de la borne : FreeVending, RFID, Autocharge ou Plug&Charge. ChargeAngels permet de gérer une infinité de tokens de type RFID, eMAID ou adresse MAC, de manière automatique, manuelle ou par import CSV.

• Un token est défini par Gireve comme une chaîne de 4 à 7 octets, soit 8 à 14 caractères hexadécimaux. Il est recommandé de suivre cette règle pour le bon fonctionnement de l’itinérance. Seuls les badges NFC/RFID de type MIFARE sont recommandés.
• Lorsqu’un nouvel utilisateur crée son compte via l’interface web (https://<sous-domaine>.charge-angels.com/auth/register) ou via l’application mobile, un badge virtuel de 4 octets est automatiquement créé et assigné à cet utilisateur.
• Il est possible de créer des tokens manuellement, un par un, ou par import CSV. Si le token est créé manuellement, il appartient à l’administrateur de l’assigner à un utilisateur.
• Un utilisateur peut avoir une infinité de tokens, dont un par défaut : c’est celui qui est proposé automatiquement au démarrage d’une session de charge.

Informations demandées à la création d’un token

• le Badge ID ou UID : le code inscrit à l’intérieur du badge RFID physique ;
• le numéro de badge : le numéro visible gravé sur le badge RFID ;
• la description (texte libre) ;
• l’utilisateur associé au badge ;
• le statut du badge ;
• badge par défaut : celui proposé automatiquement au démarrage d’une session de charge ;
• autoriser ce badge à démarrer plusieurs charges simultanément sur différentes bornes.

Comment ajouter un badge physique (ou virtuel eMAID) si vous ne connaissez pas l’UID ?

1. Dans la section « Logs », ajoutez un filtre sur votre borne et sur la sévérité ERREUR.
2. Dans le filtre « Action », recherchez l’action OcppAuthorize.
3. Passez votre badge sur la borne.
4. Un log en ERREUR apparaît, avec l’UID (idTag) dans le détail de l’erreur.

Mémorisez cet UID pour un usage ultérieur, ou rendez-vous dans le menu « Badge » pour l’ajouter. Il est également possible d’exporter l’intégralité des badges depuis le bouton d’export.

Import CSV

Un import est possible au format CSV, avec la virgule comme séparateur : créez un fichier au format XLS, avec les propriétés obligatoires id et visualID et les propriétés optionnelles description, limitKwh, email, firstName, name, siteIDs, puis sauvegardez-le au format CSV. Faites un essai avec quelques badges avant d’importer une liste de milliers de badges.

Les fabricants de bornes proposent en général des solutions de paiement par terminal de paiement électronique (TPE) comme celles-ci :

Schéma de principe : le POS est relié à la borne par le port série (MDB).

1. Le conducteur passe sa carte bancaire devant le terminal de paiement intégré à la borne (Nayax, Ingenico ou Payter).
2. Le backoffice du service de paiement bancaire vérifie et autorise la transaction de recharge.
3. Le terminal de paiement envoie un token prédéfini à la borne pour demande d’autorisation, via le protocole MDB.
4. La borne envoie une demande d’autorisation avec le token au backend de supervision et démarre la charge.

Si tout est configuré côté TPE / POS (cloud du fabricant), lors du passage d’une carte bancaire, la borne envoie un StartTransaction OCPP contenant un idTag. Ce tag doit être renseigné dans les paramètres OCPP de la borne : ce n’est pas un paramètre OCPP standard et il diffère selon les marques de bornes.

Ce tag doit également être référencé en tant que badge virtuel et sur un utilisateur virtuel (administrateur), pour que la supervision accepte la demande de charge. Cet utilisateur doit aussi être assigné aux sites correspondants.

Prérequis : la configuration de la tarification et du compte bancaire Stripe. Vous pouvez paramétrer la tarification indépendamment, sans activer la facturation.

Pour les flottes captives ou les flottes d’entreprise, vous pouvez communiquer directement à vos utilisateurs :

1. l’URL d’accès à la plateforme web : https://<sous-domaine>.charge-angels.com/auth/login ;
2. les QR codes de l’application mobile :

3. le QR code de votre « Organisation », qui est demandé lors de la création de compte. Pour le trouver, rendez-vous dans le menu « Paramètres techniques », puis « Afficher le QR code ». Mémorisez-le sous forme de fichier JPG : il vous servira à créer vos procédures utilisateur. Un modèle d’affiche à personnaliser et à coller sur vos bornes est disponible sur demande.
4. un QR code par connecteur : il est également possible d’en générer un par connecteur, pour démarrer une charge sans avoir à chercher la borne dans l’application mobile. La liste des QR codes peut être exportée pour chaque Site via le menu Organisation / Site.

Attention : les QR codes encodent l’URL complète des bornes (ChargeBoxID et identifiant du connecteur). Renommer une borne entraîne un changement de QR code : il faudra alors le remplacer.

La première chose à surveiller lors d’une mise en service est la stabilité des WebSockets. L’ouverture d’un WebSocket est à l’initiative seule de la borne et non du CSMS. Si les WebSockets ne sont pas stables (ouvertures et fermetures intempestives), la borne ne pourra pas démarrer correctement au travers d’OCPP et sera dans un état incertain.

Si une borne n’apparaît pas sur l’interface web (dashboard), les raisons peuvent être multiples :

• la borne n’est pas alimentée (coupure) ou dans un état indéterminé ;
• la borne n’est pas ou plus raccordée au réseau ;
• la borne passe par un réseau sécurisé (pare-feu sortant) ;
• la borne passe par un réseau local : routeur LAN ou WAN ;
• la connectivité à internet est insuffisante ;
• le firmware de la borne n’est pas à jour.

L’ordre du debug

1. Côté borne

• Vérifiez les connexions physiques : câbles et routeurs.
• Redémarrez au compteur (5 min) la borne et les organes de communication externes (routeurs).
• Vérifiez, si possible, les logs côté borne depuis l’administration du fabricant.

Il arrive souvent que les connexions RJ45 soient mauvaises ou mal câblées. Le meilleur test consiste à connecter un ordinateur à la place de la borne, avec les mêmes paramètres réseau (DHCP automatique ou IP fixe).

• Dans le cas d’une borne avec modem 4G, vérifiez que l’APN et l’utilisateur / mot de passe sont corrects, puis l’état du signal 4G, souvent accessible depuis la borne ou le routeur 4G externe.
• Effectuez la mise à jour du firmware avec la dernière version officielle disponible sur le site du fabricant.
• Essayez dans un premier temps de changer le token en WS (non sécurisé, port 80).
• Puis, si cela fonctionne, repassez en WSS (sécurisé, port 443).

2. Côté supervision, si tout est correct côté borne

• Vérifiez les logs côté supervision (interface web de préférence), comme décrit dans les questions sur les logs. Si aucune requête d’ouverture de WebSocket n’est reçue, c’est que la borne ne communique pas correctement, surtout si d’autres bornes sont déjà connectées sur le même espace cloud.
• Vérifiez également l’état du token (validité et révocation) depuis le menu « Borne / Connectez une nouvelle borne ».
• Vérifiez si la borne répond bien aux commandes OCPP (Reset, StartTransaction…) tout en consultant les logs du backend.

Quand et comment nous contacter ?

Si toutes les bornes ne répondent plus et que le réseau est hors de cause, il y a potentiellement un bug côté supervision. Dans ce cas, merci de nous contacter (catégorie « Demande de support ») avec le descriptif exact du problème : date de l’incident, reproductibilité, noms des bornes concernées, tests effectués, etc.

Si le problème semble plutôt lié aux bornes, sur une borne en particulier ou à la suite d’une mise à jour de firmware, collectez les logs côté borne et côté supervision et ouvrez un ticket auprès du fabricant.

Le debug est une prestation facturée chez ChargeAngels, sauf en cas de bug avéré et documenté côté supervision. Seules les bornes certifiées par ChargeAngels sont couvertes par notre contrat de support. Dans la majorité des cas, les bugs sont liés à un plantage de la borne, à un problème réseau ou à une mauvaise manipulation des utilisateurs.

Bonnes pratiques

• La meilleure approche consiste à avoir une borne « référence » à proximité de vos locaux, pour le debug et la reproduction de pannes ou d’erreurs. La mise à jour d’un firmware est une opération risquée, qui peut parfois entraîner un dysfonctionnement définitif de la borne. Sans borne de test dédiée, faites les tests sur une borne isolée et peu sollicitée.
• En cas de mise en service de bornes que vous ne connaissez pas, faites un test de mise en service avant la pose définitive.
• Pour les bornes en 4G, analysez au préalable la couverture du réseau 4G (il existe des appareils pour cela).
• Pour les tests fonctionnels, il existe des simulateurs de charge pour les bornes AC de type T2S chez Metrel. Nous recommandons également des tests avec un véhicule électrique réel.

La lecture des logs JSON ou d’un autre format nécessite des compétences en informatique. Les messages OCPP entre les bornes et notre serveur sont normalisés dans la spécification OCPP, dont nous recommandons la lecture au préalable : openchargealliance.org/my-oca/ocpp. Nous dispensons par ailleurs des formations sur ce protocole, ainsi que des formations opérationnelles (lecture des logs et debug), en plus de la qualification IRVE P2/P3.

Trois familles de problèmes reviennent le plus souvent. Elles sont détaillées dans les questions suivantes :

• problèmes de connexion de la borne au backend ;
• problèmes de finalisation de sessions : aucun StopTransaction reçu ;
• problèmes de finalisation de sessions : StopTransaction reçu, mais mauvais statut.

Symptôme : la borne n’apparaît pas dans le dashboard du CSMS ChargeAngels bien que le réseau fonctionne, ou vous recevez des requêtes WS/WSS mais elles sont en erreur.

Explications : l’ouverture d’un WebSocket est à l’initiative seule de la borne et non du CSMS. Si aucune requête WS ou WSS n’arrive côté supervision et que le réseau fonctionne (la borne peut sortir sur internet, par exemple vers le DNS de Google), c’est probablement que le paramétrage de l’URL dans la borne est faux, incorrect ou incomplet. Chaque marque ou modèle comporte des spécificités et demande parfois un outil spécifique pour paramétrer cette URL : application web, application mobile, application Windows dédiée, etc.

Solutions : nous recommandons de lire d’abord l’intégralité de cette FAQ, en particulier les questions sur les logs WebSocket. Le paramétrage de l’URL est à 99 % l’origine du problème, après le réseau : il faut donc appliquer une méthode séquentielle et itérative.

La malformation de l’URL a souvent plusieurs origines :

1. Certaines bornes ne supportent que WS : il est recommandé de commencer par là (qui peut le plus peut le moins).
2. Certaines bornes ne supportent WSS qu’après la dernière mise à jour du firmware.
3. Certaines bornes exigent une première connexion en WS, puis la bascule en WSS (Schneider, en fonction du firmware).
4. Certaines bornes supportent WSS mais uniquement TLS 1.2 et non TLS 1.3.
5. Certaines bornes exigent un profil de sécurité spécifique (Security Profile) : nous n’avons pas de profil spécifique, mais le niveau 2 est accepté avec n’importe quel mot de passe.
6. Certaines bornes exigent le certificat racine du CSMS (certificat Root CA).
7. Certaines bornes exigent le port 80 ou 443 : il faut alors l’ajouter dans l’URL.
8. Certaines bornes séparent le host, le port, le chemin (path) et le ChargeBoxID, puis concatènent l’URL WSS pour effectuer les appels sortants.
9. Certaines bornes ne proposent pas de ChargeBoxID : il faut alors l’ajouter à la fin de l’URL, sinon l’appel sera rejeté chez nous (ce champ est la clé principale dans notre base de données).
10. Certaines bornes ajoutent ou non un slash à la fin de l’URL (chez nous, il n’y a pas de limitation à ce sujet).
11. Certaines bornes tronquent l’URL, car trop longue (de moins en moins fréquent).

Symptôme : dans le menu Sessions / Historique, vous voyez des sessions fantômes, et il est impossible de stopper une session de recharge en cours. Log en erreur : Remote Stop Transaction has been rejected in 1.52s, reason 'Rejected'.

Séquence dans les logs :

EVSE <- CSMS : remoteStartTransaction avec transactionID
EVSE -> CSMS : accepted
EVSE -> CSMS : StartTransaction with tagID
EVSE <- CSMS : accepted
...
EVSE <- CSMS : remoteStopTransaction avec le même transactionID
EVSE -> CSMS : rejected   <- message d’erreur : vous êtes bloqué ici
EVSE -> CSMS : StopTransaction with same tagID
EVSE <- CSMS : accepted

Explications : la session est toujours en attente côté CSMS, quel que soit l’état réel du chargeur, puisque nous ne connaissons pas son état (aucun StopTransaction n’a été reçu). Par conséquent, le redémarrage de la borne n’a aucun effet sur la session en attente, tant que le CSMS ne reçoit pas le StopTransaction du chargeur avec le bon identifiant de transaction. Démarrer une autre session génère un autre TransactionID, c’est-à-dire une autre entrée dans notre base de données.

Solution : vous n’avez qu’une seule possibilité : sélectionner le bouton « Forcer l’arrêt » (Force Stop) disponible sur chaque session en cours, depuis l’interface utilisateur. Cela force l’arrêt côté CSMS.

Symptôme : dans le menu Sessions / Historique, vous voyez des sessions fantômes, ou un statut anormal de la borne (hors CHARGING / SUSPENDED / FAULTED / RESERVED).

Cas normal si le StopTransaction est reçu

• StopTransaction + AVAILABLE (FINISHING optionnel) : la transaction est stoppée et finalisée.
• FINISHING n’est pas requis : seuls AVAILABLE ou PREPARING sont vérifiés (on se sert de FINISHING pour le temps de stationnement).
• SUSPENDED, FAULTED et RESERVED n’ont aucune influence sur le processus.

Cas « anormaux » gérés automatiquement

1. StopTransaction reçu, mais jamais de StatusNotification après X minutes : « Force Stop » automatique par une tâche planifiée du CSMS (délai de 30 minutes).
2. Nouveau StartTransaction reçu sans StopTransaction au préalable : sans consommation, la transaction est supprimée ; avec consommation, un « Force Stop » automatique est appliqué.
3. StatusNotification AVAILABLE sans StopTransaction juste avant : la transaction reste active (pas d’action immédiate). Si le Stop arrive ensuite, la finalisation est normale ; s’il n’arrive pas, un « Force Stop » est appliqué par la tâche planifiée (30 minutes).
4. StatusNotification AVAILABLE avant le StopTransaction : le système crée artificiellement un StatusNotification à partir du statut actuel du connecteur (Available) et de l’horodatage du StopTransaction, pour calculer correctement l’inactivité supplémentaire.

Exemple de chronologie réelle :

T1 : Available reçu   -> pas d’action (pas de StopTransaction)
T2 : Stop reçu        -> détecte connecteur = Available
                       -> crée un StatusNotification synthétique
                       -> finalise la transaction

Solution : dans tous les autres cas que ceux exposés ci-dessus, vous pouvez stopper la transaction manuellement depuis les sessions « en cours », avec le bouton « Force Stop ».