Gestion d’énergie & intégration EMS — FAQ
Une borne de recharge ne vit pas seule. Une habitation ou un bâtiment moderne dispose de panneaux solaires, d’une batterie, d’une pompe à chaleur, d’un ballon d’eau chaude, d’un système HVAC, d’éclairage, parfois d’une piscine — auxquels s’ajoutent un tarif d’électricité dynamique et un raccordement réseau limité. Bien recharger en 2026 est un problème de coordination, pas un problème de borne.
Cette FAQ explique comment les bornes Veton s’inscrivent dans ce paysage : un load management de base intégré pour les sites sans système de gestion d’énergie (EMS) complet, et une interface Modbus/TCP ouverte pour ceux qui en disposent.
Pourquoi utiliser un EMS externe ?
La meilleure décision de charge dépend d’informations dont la borne elle-même ne dispose pas. La production solaire actuelle, l’état de charge de la batterie, le moment où la pompe à chaleur va lancer un cycle de dégivrage, l’évolution du prix spot dans les quatre prochaines heures, le fait que le lave-vaisselle tourne, la limite de l’aboncement, l’heure à laquelle le client veut sa voiture prête demain matin. La borne ne voit qu’une pièce du puzzle : la voiture.
Un EMS externe voit l’ensemble. Il peut décider de ralentir la voiture pour permettre à la pompe à chaleur de finir un cycle d’eau chaude sur le solaire, ou au contraire de pousser la voiture à 11 kW pendant deux heures parce que le prix spot est négatif et que la batterie est pleine. Un « smart charging » qui ne vit que dans la borne ne peut pas prendre ce genre de décisions, car il ignore ce qui se passe dans le reste du bâtiment.
Un système qui sait tout vaut mieux que cinq applications qui savent chacune une chose. C’est la raison architecturale de placer l’EMS au-dessus de la borne, pas à l’intérieur.
Une appli contre plusieurs applis
Dans un projet premium, l’expérience utilisateur compte autant que le résultat énergétique. Une maison avec une appli pour la borne, une autre pour l’onduleur, une troisième pour la batterie, une quatrième pour la pompe à chaleur et une cinquième pour la domotique n’est pas finie — elle est fragmentée. Le client final devrait ouvrir une seule interface et voir une image cohérente.
C’est pour cela que Veton n’impose pas son propre cloud ou sa propre app aux installations qui disposent déjà d’une couche domotique ou EMS. Niko Home Control, Qbus, Loxone, KNX, Home Assistant, Xemex, LifePowr — tout système qui parle Modbus ou OCPP peut piloter une borne Veton nativement. Le client final garde son interface familière ; la borne devient une partie du bâtiment, pas un invité.
Et s’il n’y a pas d’EMS ?
La plupart des habitations n’ont pas d’EMS complet, et beaucoup n’en auront jamais. Pour ces installations, les bornes Veton intègrent leur propre load management de base :
- Limite de courant statique — réglable par borne via l’interface web locale ou l’application mobile, protège le raccordement du bâtiment.
- Équilibrage de groupe — jusqu’à 48 points de charge Veton équilibrés en un seul groupe sur un contrôleur Phoenix Contact CHARX, plusieurs groupes possibles.
- Application mobile et UI web locale — démarrer, arrêter, régler le courant max., consulter les sessions, gérer la liste blanche RFID — tout cela sans dépendre d’un cloud.
- Équilibrage dynamique optionnel — avec un compteur réseau externe (Carlo Gavazzi, Iskra, Inepro, Phoenix Contact série EEM), la borne peut réduire dynamiquement sa puissance lorsque le reste du bâtiment consomme davantage.
Cela suffit pour la majorité des sites résidentiels mono-borne et des petits sites tertiaires. Dès qu’un site ajoute solaire, batterie et pompe à chaleur et veut les coordonner, la bonne réponse est d’ajouter un EMS — pas de mettre plus de logique dans la borne.
Comment connecter mon propre EMS à une borne Veton ?
Les bornes Veton tournent sur un contrôleur Phoenix Contact CHARX qui expose une carte de registres Modbus/TCP documentée sur le port 502. Tout EMS qui parle Modbus/TCP peut lire les données de charge en temps réel et écrire le courant cible. Pas d’aller-retour cloud, pas de verrouillage propriétaire, pas de clé API.
Détails de connexion
- Protocole : Modbus/TCP
- Port : 502
- Unit ID / slave : 1
- Offset de connecteur :
numéro_connecteur × 1000(le connecteur 1 utilise les registres 1000–1999, le connecteur 2 les 2000–2999, etc.) - Valeurs 32 bits : deux registres, MSW d’abord, big-endian
Les registres dont un EMS a réellement besoin
Un EMS typique n’a besoin de lire qu’une poignée de registres pour prendre de bonnes décisions, et d’en écrire un seul pour les exécuter. La carte complète Phoenix Contact est étendue ; le sous-ensemble pratique pour la gestion d’énergie est court.
| Registre | Type | Signification |
|---|---|---|
| X232–X243 | lecture, 6×int32 | Tensions L1/L2/L3 (mV) et courants L1/L2/L3 (mA) |
| X244–X249 | lecture, 3×int32 | Puissance active (mW), réactive (mvar), apparente (mVA) |
| X250–X253 | lecture, int64 | Énergie totale délivrée (Wh) |
| X289–X292 | lecture, int64 | Énergie de la session (Wh) |
| X297 | lecture, uint16 | Courant de charge actuellement délivré (A) |
| X298 | lecture, uint16 | Capacité du connecteur (A) |
| X299 | lecture, ASCII | État du véhicule IEC 61851-1 (A1, B1, B2, C1, C2, …) |
| X300 | écriture, bool | Autorisation de charge (1 = autorisée, 0 = en pause) |
| X301 | écriture, uint16 | Courant de charge max. en A (plage 6–80) |
| X304 | écriture, bool | Disponibilité du connecteur |
| X306 / X307 | écriture, uint16 | Courant de repli watchdog (A) et timeout (s) |
| 167 | écriture, uint16 | Courant max. dynamique global pour le load management de groupe |
Pour une station à un connecteur, la boucle d’intégration est : lire X232–X299 toutes les quelques secondes, décider d’un courant cible en fonction du solaire, de la batterie, du prix et des autres charges, écrire X301 et rafraîchir le watchdog. Cela suffit pour réaliser le suivi PV, le load management dynamique et la charge pilotée par le prix depuis n’importe quel EMS.
Utilisez le watchdog
Configurez toujours le watchdog Modbus (X306 + X307). Si l’EMS ou le réseau tombe, la borne revient à un courant sûr après le timeout au lieu de maintenir la dernière valeur reçue. C’est la différence entre une intégration EMS sûre en production et une qui ne l’est pas.
Existe-t-il une implémentation de référence ?
Oui. Veton maintient une intégration Home Assistant ouverte qui utilise exactement les registres ci-dessus. Elle inclut un coordinator qui interroge la borne toutes les 5 secondes, un contrôleur EMS avec sept modes (solaire, capacité, tarif et combinaisons), l’intégration du compteur HomeWizard P1 et les prix EnergyZero day-ahead pour les Pays-Bas et la Belgique.
C’est un exemple fonctionnel d’EMS tiers pilotant une borne Veton via Modbus/TCP, écrit lisiblement pour que les installateurs et intégrateurs puissent reprendre les patterns dans Niko Home Control, Loxone, KNX, OpenHAB, ioBroker ou un automate sur mesure.
Et OCPP ?
OCPP est le bon protocole pour la relation avec une plateforme de charge : facturation, autorisation RFID, support à distance, reporting multi-sites. Ce n’est pas le bon protocole pour des décisions énergétiques en sous-seconde au sein d’un seul bâtiment. Pour cela, Modbus/TCP est plus rapide, plus simple et entièrement local.
La plupart des sites Veton bien conçus utilisent les deux : OCPP vers une plateforme de charge au choix du propriétaire, et Modbus vers l’EMS local pour la gestion d’énergie en temps réel. Les deux ne se gênent pas.
Sujets liés
Voir aussi load balancing, recharge solaire, OCPP local, EMS et gestion cloud, OCPP et plateformes de charge et puissance de charge et câbles.
