Bonjour,
J’ai récemment fait l’acquisition d’une borne de recharge SmartEVSE pour recharger mon véhicule électrique.
J’avais dans l’idée d’utiliser mon tore de soutirage (valeur positive), injection (valeur négative) utiliser sous HA pour informer le smartEvse et piloter le courant de charge.
Avec l’aide de Gemini, je galère a faire prendre en compte la valeur de ce tore pour le SmartEvse.
Connaissez vous un tuto ou guide qui explique comment installer et piloter le smartEvse sous HA.
Merci.
PS : j’ai déjà installé l’intégration SmartEvse
Salut,
si tu partageais les entités mises à disposition par ton intégration ça pourrait aider pour à te répondre.
Les IA donnent l’impression qu’elle savent tout mais très souvent dans des cas concrets ça sort des grosses bêtises.
Effectivement les IA ca ne fait pas tout, mais quand on part de rien (je ne connaissais pas du tout le smartEVSE), ca pousse aux bonnes questions et on peut ainsi challenger l’IA qui s’occupe de la partie fastidieuse de l’écriture du code. Moi je me suis concentrer sur lui donner les bonnes spécifications technique et j’ai abouti à ce code qui sur le papier répond à mon besoin, a savoir :
- Piloter par l’ajustement du courant de charge, la recharge de mon VE en priorisant le surplus solaire
- surveiller en permanence la puissance consommée pour rester dans le cadre de que qu’autorise mon abonnement ENEDIS
- avoir un mode boost « intelligent ». C’est a dire qu’il priorise la charge au solaire, mais en vérifiant le respect de la puissance disponible quelques soit la configuration de la conso de ma maison
- avoir la main sur le plafond du courant de charge piloté par la borne
- en cas de faible surplus solaire (<6A) passage en mode PAUSE de la borne au bout de 5mn. Ceci évite de décoller le contacteur si baisse de puissance solaire pendant une durée de 5mn.
- mettre la borne en OFF (décollage de contacteur de puissance) si la baisse de surplus s’étend au delà de 5mn
- comptage de nbr de cycle M/A du contacteur de puissance pour vérification du comportement de la borne et éventuellement détecté des fréquences qui seraient néfastes pour le chargeur de la voiture
Voila les 7 pts de mon cahier des charges que j’ai exposé à GEMINI.
J’ai un peu galéré au début car je n’ai pas de tore raccordé directement au smartEVSE. J’envoi l’info de la conso d’un tore qui existe dans ma maison via MQTT et qui assure déjà la mesure du soutirage/injection. Il a été assez difficile de faire « accepter » cette info à la borne. GEMINI ne m’a pas proposée que des idées pertinente, mais m’a poussé dans des réflexions que je n’aurai peut être pas envisagé seul. C’est comme cela que que j’imagine l’apport des IA (c’est mon point de vue).
Reste plus qu’a observer le comportement réel de la charge sur plusieurs jours pour vérifier que :
- Mes spec techniques sont bonnes
- les codes réalisent des 4 automatisations crées réalisent bien ces spec technique
Idéalement, si tu pouvais partager ce que tu as fait et ce que permet l’intégration SmartEVSE, ça pourrait aider le prochain qui recherche la même chose. 
Je n’ai pas encore partagé les codes car je ne veux pas publier des codes non validés et suite à mes premiers test ce soir, j’ai bien fait car le dialogue entre MQTT et la borne ne semblent pas fonctionner correctement. La borne reçois bien les ordres envoyés par HA via MQTT, mais ne les interprète pas. Donc très déçu du résultat.
Je suis un peu coincé, car il me manque des informations essentielles sur le fonctionnement intrinsèque à la borne.
J’aurai besoin d’info de type :
- prérequis et type de fonctionnement pour chaque mode (SMART/NORMAL/SOLAR)
- nécessité ou pas de passer par l’intégration (j’ai lu tout et son contraire sur ce point)
- dans l’idéal, l’analyse fonctionnelle de chaque option de tous les menus
Donc dans l’état c’est pas gagné 
Hello, je vais recevoir un module SmartEVSE dans la semaine avec le même optique, je pensais partir sur le pilotage du SmartEVSE via EVCC, SmartEVSE n’est pas supporté en natif mais je pensais essayer en creant un custom charger, Je suis sur Claude qui dis aussi pas mal de c****rie mais m’a finalement sorti un truc qui a l’air pas mal. Je vais suivre le sujet et updater si je trouve une solution viable de mon coté
Super, on va pouvoir partager nos galères pour arriver a piloter ce contrôleur via nos outils.
Mon objectif perso est de le piloter via HA en créant mes propos modes.
Il me faudrait pouvoir avoir une définition claire des entités pilotage via MQTT, ce que je n’ai pas a ce jour. J’ai demandé au support smartEvse, j’attends leur réponse.
Question : dans ton projet as tu prévu le SmartBox pour la gestion des tores directement par le contrôleur ou comptes tu utiliser le mode API dans le menu EV METER pour transmettre au smartEvse la valeur de la conso de ta maison ?
alors j’ai:
- Un Shelly pro 3EM qui remonte la production + La conso / surplus sur HA
- EVCC qui tourne sur HA (petit tool très puissant qui gère a la perfection la charge des voitures en fonction de surplus avec plein d’options)
- EVCC récupere la prod solaire et surplus directement depuis le Shelly
- Dans EVCC je compte setup un “user-defined” chargeur avec une config MQTT qui en théorie devrais récupérer les info du SmartEVSE et pousser la charge et les changement d’amperage
Si je comprend bien je vais avoir une approche différente de toi, moi je délégue la “logique” à EVCC et toi tu veux que le SmartEVSE garde sa logique et juste lui envoyer les info de HA.
SmartEVSE pour moi c’était un moyen d’avoir une borne “pilotable” MQTT ready pour pas cher, je ne compte a prioris pas utiliser sa logique interne.
J’ai le code ready j’attend juste le module demain ou mercredi
A l’origine (quand j’ai acheté le smartEvse), je souhaitais le gérer entièrement en esclave, mais après 3j de tentative d’envoi de cmd mqtt pour son pilotage je me suis résigné car dès que je passe l’option EV METER en mode API (nécessaire pour que le smartEvse accepte de déléguer la gestion à HA) il se met en erreur de communication que je ne suis pas arriver a résoudre.
Ce que j’ai compris :
Pour le rendre totalement esclave de HA, il faut mettre l’option API dans le menu EV METER. C’est la config obligatoire pour une gestion par HA, mais dans ce mode il refuse de valider la commande. Je suis donc coincé pour le moment.
Une fois que tu feras très premiers essais sur moi si tu es bien obligé de mettre cette option API et si tu as pu les cette erreur de com, ça m’aidera.
On se tient au courant (pas le même que pour charger la voiture 
)
Moi je pensais d’après la doc et un github de quelqu’un qui a fait ça (mais je ne peux pas coller de liens ici a prioris) qu’il fallait le mettre en mode normal, ensuite HA peut lire la data et envoyer des ordres, je me base sur la page de doc “mqtt api” sur le github de SmartEVSE
D’après la doc du EV meter, le mode api d’EV meter c’est juste pour lui donner la data d’un CT via MQTT, il n’attendra que de la data de conso, pas de commande.
Donne a Gemini la doc github a lire et demande lui de revoir la copie en fonction de la doc ça devrait le guider, EV Meter n’a rien avoir avec MQTT api d’après la doc
Tu peux pas mettre le lien, même en texte brut ?
edit: je viens de vérifier la doc et c’est bien ça, l’EV Meter c’est juste pour envoyer de la data de pince CT, le SmartEVSE ne prendra pas de commande par la.
Voila ma config “non verifié” EVCC (installé sur HA) si tu veux essayer, il te faut un broker MQTT sur HA si tu ne l’a pas deja mais j’imagine que oui. J’ai fait commenter le code par Claude pour aider 
En bas tu as 200w de résiduel c’est pour que mon routeur de chauffe eau puisse se lancer et prendre la priorité, tu peux le virer.
#Connexion au broker MQTT (Mosquitto installé sur le même Pi que HA)
mqtt:
broker: localhost:1883 # adresse du broker, localhost car sur le même Pi
user: ton_user # user créé dans Mosquitto
password: ton_password # password correspondant
#Statut de la borne : est-ce qu’une voiture charge ?
#On lit la puissance de charge — si > 0 = charge en cours (C), sinon = connectée/pause (B)
#On ne peut pas distinguer A (pas de voiture) de B (voiture connectée) via ce topic
#Ce n’est pas un problème : le SmartEVSE empêche le courant sans voiture de toute façon
status:
source: mqtt
topic: SmartEVSE-XXXX/EVChargePower
timeout: 30s # erreur si pas de message depuis 30s
jq: ‹ if (. | tonumber) > 0 then « C » else « B » end ›
#Est-ce que la charge est activée ?
#Même topic que status — si puissance > 0, la charge est active
enabled:
source: mqtt
topic: SmartEVSE-XXXX/EVChargePower
timeout: 30s
jq: ‹ (. | tonumber) > 0 › # retourne true/false
#Activer ou mettre en pause la charge
#mode 1 = Normal (EVCC contrôle), mode 4 = Pause (pilot signal maintenu, pas de courant)
#NE PAS utiliser mode 0 (Off) — coupe le pilot signal et casse la détection de statut
enable:
source: mqtt
topic: SmartEVSE-XXXX/Set/Mode
payload: ‹ {{if .enable}}1{{else}}4{{end}} ›
#Régler le courant de charge
#EVCC envoie des ampères (ex: 10A), le SmartEVSE attend des déci-ampères (ex: 100)
#donc on multiplie par 10 et on formate en entier
maxcurrent:
source: mqtt
topic: SmartEVSE-XXXX/Set/CurrentOverride
payload: ‹ {{ printf « %.0f » (mulf .maxcurrent 10) }} ›
#Puissance de charge en temps réel (W) — utilisée par EVCC pour ses calculs
power:
source: mqtt
topic: SmartEVSE-XXXX/EVChargePower
timeout: 30s
#Énergie totale chargée (kWh) — le SmartEVSE publie en Wh, on divise par 1000
energy:
source: mqtt
topic: SmartEVSE-XXXX/EVTotalEnergyCharged
timeout: 30s
scale: 0.001 # Wh → kWh
#Réserve 200W de surplus pour l’ARSUN (routeur solaire ballon ECS)
#EVCC ne déclenchera la charge Tesla que si le surplus dépasse 200W + minimum 6A (~1380W)
#En pratique c’est le seuil 6A qui domine, les 200W sont la pour que l'ARSUn puisse démarrer tout de même au besoin
residualPower: 200
Super, merci.
J’ai bien mosquito installé, donc pas de souci.
Je suis dans la même config que toi, j’ai également un routeur solaire pour l’ECS, donc ton option m’interesse.
Je regarde ce code pour l’intégrer avec mes entités et reviens vers toi.
https://github.com/SmartEVSE/SmartEVSE-3/blob/master/docs/configuration.md#mqtt-api
dans le tas tu as de la data qui remonte vers EVCC que tu pourra enlever aussi, par contre jette un oeil a EVCC tout de même car c’est super bien fait et tu n’aurais pas a gérer la logique de charge du coup
Salut,
Bon après une belle de journée de travail à peaufiner le code (en challengeant fortement GEMINI et CLAUDE), à fabriquer un simulateur physique pour faire croire à la borne que la voiture est branché et prête à charger, à créer les boutons de simulation du soutirage/injection et autres pour avoir les conditions les plus réalistes possibles et enfin tester tous les cas d’usage en lien avec mon cahier des charges, j’ai (je pense) obtenu ce que je veux (en tout cas la simul rend ce résultat) , à savoir :
- une position OFF ou rien ne se passe quoi qu’il arrive
- un démarrage de la charge uniquement si l’injection réseau atteint 1380W (6A)
- un ajustement du courant de charge pour chercher à chaque nouvelle info du compteur soutirage/injection, le 0W (le plus délicat à mettre au point)
- un délai ajustable de mise en PAUSE de la charge si compteur dit soutirage
- un délai ajustable de mise en OFF de la charge si compteur dit soutirage
- un comptage de nbr de cycle de charge avec reset manuel possible
- un Tdb pour la surveillance du pilotage
le tout en seulement 2 automatisations que je peux te partager si cela t’intéresse.
PS : finalement j’ai réussit a rendre totalement esclave la borne. Je ne l’équiperai donc pas du module de gestion des tores via RS485. Je n’utilise que les modes OFF/NORMAL/PAUSE
As-tu reçu la tienne ?
top ! Moi la SmartEVSE arrive aujourd’hui mais j’ai un probleme de Shelly pro 3em au passage:
Un peu HS mais je ke met quand même si ça peut aider quelqu’un
J’ai acheté le pro 3EM CT63 qui viens avec une pince CT « triple » sauf que je comptais l’installer en mode monophasé pour mesurer 3 phases différentes (solaire, maison, chauffe eau) donc j’ai acheté par dessus les pinces shelly individuelle, qui sont en 120A, sauf que bien sur les pinces 120A ne sont pas compatible avec le Shelly pro3em CT63 (elle se branchent, fonctionne, mais la valeur est fausse) car le pro 3Em CT63 bien qu’ayant a prioris le même hardware que le pro3EM as un software different qui ne prend que des pinces 50A ou la pince triple, bref j’ai recommandé un PRO 3EM classique, qui devrait avoir la bonne lecture des pinces 120A
Je vais quand même installer le SmartEVSE pour essayer je te dirais
- Reçu et branché le SMartEVSE
- Setup le wifi et MQTT avec l’ip du PI et identifiants de Mosquito
- Configuré EVCC sur le pi pour qu’il prenne la main sur le SmartEVSE (avec pas mal de test et erreurs, grosse utilisation de MQTT Explorer, petit soft qui permet de capter le mqtt et faire des test de publications etc pour voir quelles commandes passent / marchent)
Voila la config final d’EVCC sur le Raspberry pi qui marche pour moi.
Pourquoi EVCC:
- Gratuit
- Gestion de charge: Off / 100% Solaire / Solaire + minimum de charge sur HC si pas assez de solaire / Charge forcée
- Charge 100% solaire intelligente qui évite le on/off intempestif,
- Interface et options (visualisation des mesures de production solaire, charges, surplus etc, état de la voiture, etat de charge, historique de charge, gestion de priorité, gestion de marge de production a laisser, timers, prévision météo, charge sur heures d’electricité verte, charge sur HC, et d’autres, c’est très poussé)
# --- CHARGER STATUS (READ) ---
# Combines two MQTT signals to determine the IEC 61851 charging status:
# A = no vehicle, B = vehicle connected, C = charging
status:
source: combined
# "plugged" determines if a vehicle is physically connected to the cable
plugged:
source: mqtt
broker: localhost:1883
user: [xxx]
password: [xxx]
topic: SmartEVSE/8810/EVPlugState # published by SmartEVSE: "Connected" or "Disconnected"
timeout: 30s # error if no message received within 30s
quote: true # wrap raw string in quotes before passing to jq (not JSON)
jq: '. == "Connected"' # returns true if vehicle is plugged in
# "charging" determines if current is actually flowing
charging:
source: mqtt
broker: localhost:1883
user: [xxx]
password: [xxx]
topic: SmartEVSE/8810/State # published by SmartEVSE: "Charging", "Ready to Charge", etc.
timeout: 30s
quote: true
jq: '. == "Charging"' # returns true if actively charging
# --- CHARGER ENABLED STATE (READ) ---
# Reads the current operating mode to determine if charging is enabled.
# SmartEVSE publishes "Normal" when EVCC has control, "Pause" when charging is suspended.
# Using Mode instead of ChargeCurrent avoids false positives
# (ChargeCurrent stays at 160 even when paused).
enabled:
source: mqtt
broker: localhost:1883
user: [xxx]
password: [xxx]
topic: SmartEVSE/8810/Mode # published by SmartEVSE: "Normal", "Pause", "Solar", etc.
timeout: 30s
quote: true
jq: '. == "Normal"' # returns true only when in Normal (EVCC-controlled) mode
# --- CHARGER ENABLE/DISABLE (WRITE) ---
# Sends a mode command to the SmartEVSE to start or pause charging.
# mode=Normal: EVCC takes control of the charging current
# mode=Pause: charging is suspended but pilot signal is maintained (vehicle stays connected)
# Note: never use mode=Off — it cuts the pilot signal and breaks status detection
enable:
source: mqtt
broker: localhost:1883
user: [xxx]
password: [xxx]
topic: SmartEVSE/8810/Set/Mode # write topic for mode commands
payload: '{{if .enable}}Normal{{else}}Pause{{end}}' # Normal to start, Pause to stop
# --- MAX CHARGE CURRENT (WRITE) ---
# Sets the maximum charging current in response to available PV surplus.
# EVCC sends amperes (e.g. 10A), but SmartEVSE expects deci-amperes (e.g. 100).
# The value is multiplied by 10 and formatted as an integer.
maxcurrent:
source: mqtt
broker: localhost:1883
user: [xxx]
password: [xxx]
topic: SmartEVSE/8810/Set/CurrentOverride # write topic for current override
payload: '{{ printf "%.0f" (mulf .maxcurren 10) }}' # multiply by 10: 10A → "100"
Super !
On voit que cette borne se paramètre très bien également avec EVCC.
On a plus qu’à utiliser pendant quelques temps et faire un retour d’expérience pour voir le niveau de satisfaction obtenue.
1 « J'aime »
Graphe de ma 1er charge en condition réelle et avec un météo qui alterne entre éclaircie et passage nuageux bien marqué.
L’analyse GEMINI de ce garph.
C’est un excellent retour ! Merci pour le partage de ce graphique, il est très parlant et confirme que votre logique de régulation est saine.
Voici l’analyse de ce que l’on observe sur ces premières heures de charge réelle :
1. Précision du suivi (Ligne Bleue vs Jaune)
On voit très nettement que la courbe bleue (consommation voiture) « colle » à la courbe jaune (production PV).
- Entre 10h00 et 11h00, la régulation est très active pour compenser l’instabilité de la production (probablement des passages nuageux).
- À partir de 12h30, la production devient plus stable et massive (autour de 5 kW), et la voiture sature ou suit parfaitement le plateau.
2. Gestion du talon et de l’injection (Ligne Rouge)
La courbe rouge reste globalement très proche de la ligne du 0 W, ce qui est l’objectif ultime de l’autoconsommation.
- On note quelques pics négatifs (injection vers le réseau) lors des chutes brutales de production : c’est le temps de réaction normal de l’automation et de la borne pour ajuster le courant de charge.
- Le fait que la ligne rouge ne s’envole pas dans le positif (soutirage) prouve que votre « Priorité Régulation » fonctionne : vous ne tirez pas sur le réseau pour charger.
3. Les observations clés
- Stabilité à 6A : On voit un palier bleu très stable autour de 11h15 - 11h45. La voiture consomme environ 1400-1500 W, ce qui correspond bien au seuil minimal de 6A. Malgré une production jaune fluctuante mais supérieure, la régulation semble avoir trouvé son rythme de croisière.
- Réactivité : Les pics de consommation de la voiture (bleu) descendent instantanément quand la production (jaune) chute. Votre boucle de rétroaction est efficace.
Ce qu’il faut surveiller ce soir (Mode Pause/Stop)
Comme vous l’avez souligné, le test crucial reste la fin de journée :
- Le passage en Pause : Lorsque la courbe jaune passera durablement sous le seuil des 1400 W (environ), l’automation doit envoyer l’ordre de pause.
- L’hystérésis : Vérifiez si la borne ne « pompe » pas (allumage/extinction répété) si la production oscille juste autour du seuil.
- Le Stop final : Si la batterie atteint votre condition d’arrêt (
sensor.scenic_battery_level > 80%) ou si le soleil se couche totalement.
Le résultat est déjà très satisfaisant pour un premier essai en conditions réelles. Votre installation est maintenant techniquement capable de transformer votre surplus solaire en kilomètres de façon dynamique !
