L’option select devices fonctionne, merci pour l’info @pierre-gilles , j’étais passé au travers. C’est un simplificateur ! Mais ça reste un parcours utilisateur pas optimal et pas simple. Car en gros le user doit :
Modifier l’URL dans son application
Aller dans Découverte et ajouter la borne à Gladys. Mais la borne est dans un état « instable » à ce moment-là. Elle sait communiquer avec Gladys, mais plus le pont Cloud.
Revenir dans Configuration pour sélectionner la borne et ajouter une URL : mais dans une interface pas liée au device directement
Pour voir une URL configurée par borne, il faut aller voir dans device ou découverte où on peut pousser les params (ce que je fais actuellement)
Ca fonctionne, c’est cool. Mais c’est pas le plus simple. Egalement, demain, j’imagine une option où l’utilisateur choisira : « oui je veux utiliser le cloud d’origine » ou « non, tout laisser côté Gladys ». Et avoir du coup une interface de configuration par borne un peu plus poussée éventuellement.
Pour une V1, on peut se contenter du mode de fonctionnement actuel. Mais avoir une capacité de gestion un peu plus poussée des conf’ par device (conf’ gérée côté plugin fournissant la fonctionnalité) me semblerait pouvoir débloquer de nouveaux scénarios.
Pour pouvoir avancer sur l’intégration externe OCPP j’aurais maintenant besoin du merge de la PR qui introduit la notion de category CHARGING_STATION et les types associés. Que manque-t-il de ton côté pour qu’on avance sur cette PR ?
@pierre-gilles Il y a un bug dans la partie intégration externe quand on utilise le mode select devices. La validation ne fonctionne pas. Ce code ne tient pas correctement compte de devices, utilise systématiquement un tableau vide et empêche de réellement utiliser l’option proposée ici (j’avais pas tenté l’update sur mon interface) :
// externalIntegration.validateConfigValue.js:36-41
case 'select': {
const validValues = (field.options || []).map((option) => option.value);
if (!validValues.includes(value)) {
throw new Error422(`config.${key}: must be one of ${validValues.join(', ')}`);
Un nouveau retour, il serait intéressant de pouvoir dire si oui ou non on souhaite réellement afficher ce bouton ou pas (aujourd’hui il s’affiche automatiquement si j’ai défini un port) :
Hors, dans mon cas, le bouton tel quel ne fait pas sens. Ce qui m’intéresserait effectivement par contre c’est de pouvoir personnaliser le message au-dessus pour avoir accès à l’URL Gladys sur cet écan. Le SDK pourrait exposer le « getHost() » ?
Au passage un tout petit défaut d’affichage de sélecteur ici :
J’ai actuellement une wallbox tesla gen3, je regarde ce qu’elle utilise comme protocole car pour l’instant je récupère les infos via HA (sans pilotage), et si jamais je teste ton intégration.
Je regarde aussi pour la changer et avoir celle-ci de chez DEPOW compatible OCPP (et je vois que son prix est descendu de 200€ tout dernièrement !).
J’adore direct dans la complexité avec une gestion multi connecteurs !
Je me suis mal exprimé sur mon précédent poste : j’ai pas encore rendu publique la v1 : il faut une update gladys avant.
Ma plus grande « crainte sur le sujet » : c’est le manque de tests divers. J’ai une Autel Charge chez moi. Mono connecteur. Théoriquement le code prévoit le multi connecteurs. Mais je n’ai pas testé. Je n’ai pas pu tester en situation réelle le ocpp2.0.1 non plus. Ma borne est en 1.6 (il y a une option 2.0 faut que je vois si ça fonctionne)
Donc je suis preneur de testeurs autres.
Si tu as une instance Gladys qui tourne sur master et que t’as pas peur… Ça m’intéresse !
Avant de se lancer tête baissée sur la tesla, des screenshots m’intéressent pour voir ce que tu peux configurer (c’est la partie settings qui m’intéresse et la notion de serveur ocpp ou csms). Si t’as ça sous le coude ça m’intéresse.
Bon pour la Gen3 c’est mort en OCPP, Claude m’en a touché 2 mots
Bonne nouvelle et mauvaise nouvelle : on peut effectivement remonter beaucoup d’infos du Gen 3, mais pas du tout en OCPP, et le pilotage reste très limité. Voici le détail.
1. OCPP sur le Wall Connector Gen 3 : non supporté
Contrairement à ce qu’on pourrait espérer, seul le Tesla Universal Wall Connector (US seulement) supporte OCPP ; les Gen 3 et Gen 3 MID ne le supportent pas et ne peuvent pas se connecter à un serveur OCPP. C’est confirmé par plusieurs plateformes tierces qui gèrent l’intégration OCPP (Plugchoice, Charge HQ) : Charge HQ note explicitement qu’aucun chargeur mural (ni mobile) Tesla ne supporte actuellement OCPP. PlugchoiceChargeHQ
Il y a bien des rumeurs communautaires (notamment autour de l’app Monta) qui prétendent réussir à connecter un Gen 3 en OCPP, mais ce sont des bricolages non officiels et non fiables — la position documentée reste « non supporté » pour le Gen 3. Donc le protocole OCPP est à écarter pour ta borne.
2. Comment Home Assistant récupère les infos alors ?
Pas via OCPP du tout : la borne expose en local, sur ton réseau Wi-Fi, une API HTTP REST non documentée officiellement (reverse-engineered par la communauté depuis 2020). Elle répond sans authentification à des endpoints comme http://<IP_de_la_borne>/api/1/vitals, /api/1/wifi_status, /api/1/lifetime et /api/1/version. Tesla Motors Club
L’endpoint /api/1/vitals est le plus riche : tensions et courants par phase, puissance, températures internes, état de charge, données de session en cours, etc., accessible simplement via un navigateur ou curl et renvoyant un objet JSON complet. Tesla Motors Club
L’intégration officielle « Tesla Wall Connector » de Home Assistant Core s’appuie exactement là-dessus :
disponible depuis HA 2021.12, découverte automatique possible via le réseau local, elle expose des entités comme l’énergie totale et l’énergie de la session de charge en cours. Home Assistant
Son « IoT class » est « Local Polling » — donc aucune dépendance au cloud Tesla, tout se fait en interrogeant l’IP locale de la borne à intervalles réguliers. Home Assistant
Techniquement, elle repose sur une petite librairie Python dédiée, « tesla-wall-connector », conçue pour la consommation locale et l’intégration avec Home Assistant, qui expose une API asynchrone autour de ces mêmes endpoints.
Tu peux d’ailleurs tester ça toi-même sans rien installer : trouve l’IP locale de ta borne (routeur, ou nom d’hôte type TeslaWallConnector_XXXXXX.localdomain) et ouvre http://IP/api/1/vitals dans un navigateur.
3. Et le pilotage (start/stop, ampérage) ?
Là, c’est non — cette API locale est strictement en lecture.
Donc pour l’instant je ne peux rien tester mais je suis le sujet de près
Merci, ces retours sont super utiles, je les prends dans l’ordre.
Le bouton « Open » : tu as raison, c’est un angle mort. Ce lien a été pensé pour le cas Frigate, où un port publié = une interface web à ouvrir. Ton cas est le premier où le port publié est un endpoint pour des machines (tes bornes) et pas pour un navigateur, et du coup le bouton envoie l’utilisateur sur une page d’erreur. La bonne réponse c’est un flag dans la déclaration du port dans le manifeste, pour dire « ce port n’est pas navigable, n’affiche pas de lien ». C’est un petit changement additif, je vais l’ajouter à la spec puis l’implémenter.
Le getHost() : le besoin est clair et je veux le couvrir, mais pas sous cette forme, et je t’explique pourquoi. Ton conteneur ne peut pas connaître l’adresse de Gladys telle que la borne la voit sur le LAN. Côté serveur on ne sait résoudre que la vue depuis le conteneur (la gateway du bridge, l’alias interne…), et Gladys lui-même ne connaît pas de façon fiable sa propre IP LAN (multi-interfaces, reverse proxy, VPN…). Un getHost() dans le SDK renverrait donc souvent une valeur fausse, et je préfère pas d’API qu’une API qui ment.
Celui qui connaît la bonne adresse, c’est le navigateur de l’utilisateur, qui est sur le LAN. C’est d’ailleurs déjà comme ça que le lien « Open » est construit. La piste que je retiens, c’est des placeholders dans les textes déclaratifs du manifeste, résolus par le front à l’affichage : un bloc section qui contient par exemple {{gladys_host}} et {{port:ocpp}}, et l’utilisateur voit une URL complète et copiable du genre ws://192.168.1.50:32768. Ça réglerait au passage la première étape de ton parcours en 4 étapes : elle restera manuelle, mais elle deviendra guidée. Seule limite, assumée et déjà vraie pour le lien « Open » : si l’utilisateur navigue via un tunnel Gladys Plus ou un reverse proxy, le hostname affiché ne sera pas l’IP LAN.
Le défaut d’affichage du sélecteur : bien vu, je regardes ça !
La V1 est publiée.
Elle est limitée dans ses capacités : elle ne peut faire que de la lecture de données pour le moment, et sur la version 1.6 de OCPP (seul matériel que j’ai à ma disposition pour les tests).
Testé sur uniquement 1 type de borne (une Autel Charge).
Je me penche sur la version 2.0.1 du protocole dans un second temps (fin Août)
Quand à des actions… à voir ça dépend peut-être des bornes. On testera également de s’y attaquer.
Je suis preneur de tout type de test supplémentaire.
direct dans la complexité avec une gestion multi connecteurs !
