Un sujet plus en mode discussion dans un premier temps pour prendre la température : est-ce qu’une intégration « Borne de recharge de véhicule » intéresserait du monde ?
Plusieurs questions ensuite découlent de ce projet :
OK mais pour faire quoi ? Dans un premier temps, je pense que ce serait principalement pour de la « consommation » de données… mais peut-être pas suffisant ?
OK mais quel type d’intégration ?
Complètement intégrée à Gladys : Gladys porte le code de son côté… pas certain que ce soit une excellente idée, mais pourquoi pas dans l’absolu. C’est peut-être in-fine le plus intégré ?
En mode ocpp2mqtt : un peu comme zigbee et zwave : on s’appuie sur un autre projet qui fait office de CSMS et publie les messages sur un broker MQTT. Le Broker peut aussi servir pour envoyer les commandes à la borne. Dans ce mode là, la borne ne communique plus avec le serveur Cloud natif de la borne
En mode Relay 2 mqtt : dans ce mode là, un programme agit comme intermédiaire pour transmettre les messages sur le broker MQTT tout en laissant passer les messages au Cloud natif. Gladys ne peut, à priori, que recevoir des messages, pas en émettre à la borne (dans l’absolu si, mais désynchro avec le CSMS cloud… pas certain des impacts).
Via node-red ? auquel cas il n’y a rien à faire réellement dans Gladys, plus une question de tutoriel ? (je viens de penser à cette solution en écrivant le poste je le reconnais)
J’ai commencé quelques premières recherches, j’ai encore un peu de mal à bien identifier tout ce qu’on pourrait faire avec le protocole (sachant qu’il existe 2 / 3 version de celui-ci). Recevoir des data, ça semble plus ou moins OK. C’est plus en envoie de commande où je n’ai pas creusé ce qui peut être fait, mais dans l’idée, pourquoi pas. D’où ce post en fait : des personnes sont-elles intéressées ? Pouvoir remonter quelles infos ? Pour pousser quelles commandes ?
Pour les différentes options, il y a plus ou moins différentes manières de procéder :
Voilà, je n’ai pas de réponse, je n’ai pas de solution encore complètement claire… je viens prendre la température pour voir si il y a un intérêt ou pas.
Salut @Sescandell !
Je suis sûr que ça intéresserait du monde, et je pense que c’est un excellent candidat pour les futures intégrations externes dans Gladys
Vas-y chaud dans l’idée de tenter cette approche. Même sur un simple POC dans un premier temps.
J’ai une borne à disposition… Je vais commencer à explorer ce qui est de l’ordre du faisable en dehors de tout Gladys dans un premier temps pourme familiariser avec tout ceci.
Si certains ont la connaissance de ce protocole, faites signe, je suis preneur
C’est une idée précieuse. Plutôt que de l’intégrer pleinement à Gladys dès maintenant, une connexion via OCPP-to-MQTT pourrait être plus pratique ; elle facilite les tests et permet la mise en œuvre initiale de fonctionnalités telles que l’état de charge, la puissance de sortie, les niveaux d’énergie et le contrôle de démarrage/arrêt.
Une intégration native plus approfondie peut être envisagée une fois que les exigences d’utilisation spécifiques deviennent claires.
Petit état d’avancement (j’y vais quand même avec des pincettes sur le truc, j’ai pas trop envie de griller la borne… ni la voiture… encore moins la maison )
A date, j’ai une boucle relativement simple, en dehors de Gladys pour le moment. Mais grâce au projet GitHub - gyzod/ocpp2mqtt: OCPP <==> MQTT Gateway · GitHub & GitHub - ocpp-balanz/ocpp-2w-proxy: A 2 way OCPP proxy · GitHub j’ai pu monter une interface Web qui est capable de me montrer en temps réel l’état de ma borne.
L’idée du projet ocpp-2w-proxy est, comme son nom l’indique, de s’intercaler en tant que Proxy (une sorte de Man In The Middle) entre la borne et le serveur Cloud natif.
Ca permet ainsi de conserver le pilotage par l’application native. Dans mon cas, je constate que mon app Autel Charger reste 100% fonctionnelle (de ce que j’ai pu tester jusque là…). Mon MQTT reçoit aussi bien tous les messages. Ce qui permet de mettre à jour une interface web factice pour le moment.
Mon problème est dans le démarrage d’une charge. Le changement de configuration, l’arrêt, le refresh : tout fonctionne. Mais démarrer une recharge, pour le moment je suis bloqué.
Peut-être qu’une première étape va donc être de faire en sorte de voir l’état de la borne. On pourra creuser ensuite ce qui déconne.
Là où j’ai quelques réserves également, c’est qu’il a fallu modifier le code source des projets référencés pour que ça fonctionne. Je vais double vérifier ce point, c’est peut-être une erreur de ma part.
Rien de lié à Gladys dans l’immédiat, mais une fois que je suis certain que c’est OK : go pour le plugin
Si j’étais toi, je lancerais Claude sur le sujet avec toutes les informations de ce post
En 30 minutes tu as une intégration externe Gladys qui a de bonnes chances de fonctionner dès le premier essai, testable en 1 clic dans Gladys, et tu peux itérer à partir de là.
De bout en bout, je pense qu’aujourd’hui une intégration externe c’est moins d’une heure de travail, sans avoir besoin de rentrer dans l’API ni dans le code.
De mon côté les résultats que j’obtiens sont vraiment propres, souvent supérieur au travail qu’aurait fait un développeur humain car tous les edge case sont bien géré, ça vaut le coup d’essayer
Ce n’est pas tant une problématique de rapidité ou de prise en main des APIs : c’est pas encore ce step (ce point là ne m’inquiète pas, il sera vite traité par IA).
@Sescandell Pourquoi utiliser ocpp-2w-prxy et ocpp-2mqtt ?
Est-ce que l’IA ne pourrait pas réécrire directement toute cette stack dans l’intégration Gladys ? On éviterait ainsi d’être dépendants de ces projets externes, tout en gardant la maîtrise de l’implémentation, des évolutions et des corrections de bugs. Ça offrirait aussi plus de flexibilité sur le long terme, non ?
C’était une des pistes possibles aussi évoqué dans le poste initial. On est d’accord que quand tu dis « toute cette stack dans Gladys » on reste sur l’idée d’un « plugin externe via l’API pour autant » ?
La question revient à dire pourquoi chercher à redévelopper quelque chose qui existe déjà en soit. J’abuse, mais en gros tu demandes : pourquoi avoir choisit zigbee2mqtt plutôt que de le redévelopper ? Si des solutions sur le marché font le taffe, pourquoi vouloir les ré-implémenter. J’interprète mal la question ?
Si ces deux projets font le taffe, autant ne pas s’en priver. S’ils sont limitant je regarde pour une implémentation maison. Dans l’absolu j’ai presque envie de dire, en tant que « plugin externe » c’est un « détail d’implémentation » ?
J’ai pas encore d’avis tranché sur la question. En ce qui me concerne, je suis toujours en phase d’exploration sur le champ des possibles. Je pense que ce week-end je mettrai un coup sur ce point pour pousser une intégration.
Oui, c’est bien la question. Mais justement, quand je regarde ocpp-2mqtt, je vois un projet relativement simple et qui évolue assez peu.
Le dépôt compte 90 commits seulement, et une bonne partie concerne des mises à jour de documentation ou de CI. Au final, il n’y a pas énormément de logique métier.
ocpp-2w-proxy c’est encore pire, seulement 19 commits, dernière mise à jour il y a 5 mois.
C’est typiquement le genre de projet qu’une IA peut aujourd’hui réécrire en une trentaine de minutes. On s’évite ainsi une dépendance à un projet tiers qui évolue peu, tout en gardant la maîtrise du code et la possibilité de le faire évoluer ou de corriger rapidement les bugs.
À l’inverse, Zigbee2MQTT, c’est une tout autre échelle : plus de 6 400 commits, des centaines de contributeurs et un développement très actif. Là, il y a une vraie expertise accumulée et une énorme base de compatibilité avec les équipements Zigbee. Dans ce cas, il est beaucoup plus pertinent de s’appuyer sur leur travail plutôt que de vouloir tout réimplémenter.
Je n’ai pas écarté cette possibilité. J’y pensais en mode fork, mais on peut l’imaginer en mode « from scratch ».
Je teste la solution HA, pour voir si le problème que j’identifie est propre à ma borne ou à la lib’, et on voit ça
Du coup tu es parti en mode conteneur additionnel ? Franchement c’est clairement overkill je pense, tu aurais pu le faire en natif, dommage d’avoir une dépendance
J’aurais préféré ne pas en avoir besoin aussi. Mais, soit je rate quelque chose de la documentation, soit tu n’es pas complètement au fait de comment fonctionne OCPP.
Pour l’intégraiton OCPP, on a besoin qu’une nouvelle Websocket soit disponible. Les bornes se connectent à ce Websocket. L’idée de l’intégration là, c’est d’agir en tant que Man In The Middle pour pouvoir voir ce qu’il se passe. Sinon : c’est le flou total.
De la documentation, je lis trois choses :
les champs de manifest : qui ne parlent pas de capacité d’exposition de ports
le modèle de sécurité qui explique que le Docker vit dans un Network isolé
les containers compagnon : qui sont là pour pouvoir (entre autres) faire les ponts de protocole… pour moi on est typiquement dans ce cas là
Donc soit je rate une info, le container principale peut parfaitement ouvrir des ports et les rendre dispo sur le réseau, et dans ce cas-là je te rejoins, dis moi comment faire et je modifie sans aucun soucis. Soit ce n’est pas possible et donc ce n’est pas overkill
J’ai revérifié la spec : le container principal d’une intégration externe n’a volontairement aucun port publié, son seul canal entrant c’est la WebSocket sortante vers Gladys. Les ports publiés n’existent que sur les sous-containers déclarés dans containers[]. Donc pour de l’OCPP, où c’est la borne qui vient se connecter en client WS, le container compagnon c’est bien la seule option aujourd’hui. Pas overkill du tout donc
Après, rien ne t’oblige à utiliser une image tierce dans le sous-container, containers[].docker_image accepte aussi la tienne. Tu peux donc déclarer un sous-container qui fait tourner ton propre serveur OCPP si jamais tu veux limiter les dépendances externes !
)
On éviterait ainsi d’être dépendants de ces projets externes, tout en gardant la maîtrise de l’implémentation, des évolutions et des corrections de bugs. Ça offrirait aussi plus de flexibilité sur le long terme, non ?
