Lorsque vous voyez dans les journaux OCPP une ligne qui commence par [4, ...], vous savez qu'un message n'a pas pu être traité par l'autre partie. Ce type de message s'appelle CALLERROR. Un CALLERROR diffère d'un refus métier (comme un badge invalide) : il signale un problème technique dans le message lui-même ou dans son traitement. Cet article présente les codes d'erreur standard et l'endroit où regarder en premier pour chacun.

La structure d'un CALLERROR

Un CALLERROR est un tableau de cinq éléments : type de message (4), MessageId de la requête, code d'erreur, description courte et objet de détails. Exemple :

[4, "a1b2c3", "PropertyConstraintViolation", "connectorId out of range", {}]

Le code d'erreur provient d'une liste fixe définie dans la spécification OCPP. La description et les détails dépendent de l'implémentation ; le champ description est généralement l'indice le plus précieux pour comprendre le problème.

Codes d'erreur standard

NotImplemented

L'action demandée n'est pas du tout définie de l'autre côté. Vous pouvez par exemple recevoir cette réponse en envoyant TriggerMessage à une borne ancienne. Solution : vérifiez les profils pris en charge par la borne ou n'utilisez pas cette action pour elle.

NotSupported

L'action est reconnue mais pas prise en charge. En pratique, on la traite comme NotImplemented. Une borne qui ne prend pas en charge le profil Smart Charging peut par exemple répondre ainsi à SetChargingProfile.

InternalError

L'autre partie a compris le message, mais une erreur interne s'est produite pendant son traitement. Il s'agit généralement d'un bogue logiciel. S'il se répète, signalez-le au fabricant de la borne ou à l'éditeur du logiciel avec un extrait de journal.

ProtocolError

Le message ne respecte pas les règles d'OCPP ; par exemple, la charge utile manque ou la structure du tableau est cassée. Examinez le JSON brut : il s'agit souvent d'un problème simple comme un champ manquant ou une virgule en trop.

SecurityError

L'action a été refusée pour des raisons de sécurité. Elle peut apparaître, par exemple, lorsque la borne reçoit une requête qu'elle n'est pas autorisée à exécuter ou qu'un message est envoyé avant la fin de l'authentification.

FormationViolation

La charge utile est syntaxiquement incorrecte ; le JSON ne peut pas être analysé ou ne correspond pas à la structure attendue. Si vous écrivez votre propre intégration, vérifiez la génération du JSON.

PropertyConstraintViolation

La valeur d'un champ enfreint les règles ; par exemple, un numéro de connecteur inexistant ou une valeur de statut absente de la liste autorisée.

OccurrenceConstraintViolation

Un champ obligatoire manque, ou un champ est utilisé plus de fois que permis.

TypeConstraintViolation

Le type du champ est incorrect ; par exemple, un texte a été envoyé là où un nombre était attendu ("connectorId": "1" au lieu de "connectorId": 1).

GenericError

Une erreur générale qui ne correspond à aucun autre code. Il est indispensable de lire la description.

L'OCPP 2.0.1 et 2.1 ajoutent quelques codes, comme MessageTypeNotSupported et RpcFrameworkError, et certains noms s'écrivent légèrement différemment (par exemple FormatViolation). La logique reste la même.

CALLERROR ou refus métier

C'est la distinction la plus souvent confondue sur le terrain. Lorsqu'un badge RFID n'est pas reconnu, le CSMS n'envoie pas de CALLERROR ; il renvoie "idTagInfo": {"status": "Invalid"} dans un CALLRESULT. Si une demande de démarrage à distance ne peut pas être exécutée parce que la borne est occupée, la réponse est "status": "Rejected". Autrement dit :

  • CALLERROR : « Je n'ai pas pu traiter votre message. »
  • CALLRESULT + Rejected/Invalid : « J'ai compris votre message, mais je n'accepte pas votre demande. »

Connaître cette distinction permet de savoir immédiatement s'il s'agit d'une incompatibilité technique ou d'une règle métier.

Scénarios fréquents

  • Une nouvelle borne est connectée et certaines commandes renvoient NotImplemented : la borne ne prend pas en charge certains profils facultatifs. Désactiver ces commandes pour ce modèle dans le tableau de bord est la solution la plus propre.
  • Des erreurs FormationViolation sont apparues après une mise à jour du firmware : le fabricant a peut-être modifié le format d'un champ. Comparez les journaux avant et après la mise à jour.
  • PropertyConstraintViolation sur un connecteur précis : le nombre de connecteurs défini dans le tableau de bord ne correspond peut-être pas à celui déclaré par la borne.

Les erreurs d'état des connecteurs (comme Faulted et les valeurs errorCode) sont traitées séparément dans notre guide des codes d'erreur OCPP. Pour la structure générale de l'enveloppe des messages, voir la structure des messages OCPP.

Conseils pour un diagnostic rapide

Conservez chaque CALLERROR avec son message CALL. Tenir des statistiques par code d'erreur, nom d'action et modèle de borne montre quel problème se concentre sur quel modèle. Le logiciel OCPP d'Üreticy conserve tout le trafic OCPP dans des journaux consultables ; vous pouvez rapidement filtrer uniquement les erreurs d'un connecteur ou d'une borne.

Conclusion

Un CALLERROR signale un problème technique dans la communication OCPP. Lire le code d'erreur avec sa description révèle rapidement si le problème vient du format du message, d'une action non prise en charge ou d'une erreur interne de l'autre partie.