etm-powersync-energy-plugin-etm/docs/PREPA_BANC_20260828.md

Préparation du banc — arrivée V2C Trydan + Skoda Enyaq, 2026-08-28

Écrit la veille, depuis le code et le banc, pour que rien de ceci ne se découvre avec la borne au mur. Le banc tourne 1.15.2+etm24.

Deux blocages trouvés la veille, et les deux étaient silencieux — ils ne produiraient aucune erreur, seulement des chiffres faux.

✅ ÉTAT AU SOIR DU 27 : la box est PRÊTE. Le plugin V2C 1.15.2+etm12 est construit en arm64, posé, et la ThingClass trydan se charge avec phaseCount (§2.1 corrigé). Le blocage §2.2 est un refus assumé, pas une tâche. Il ne reste que le câblage et l'appairage — §6.

⚠️ CORRECTION DU 28, APRÈS-MIDI — ce document a été dépassé par le déploiement du matin

Relevé Integrations.GetThings sur .75, borne appairée et sous tension. Trois affirmations de ce document ne sont plus vraies, et deux d'entre elles décrivaient des blocages qui n'en sont plus :

Ce que le document dit	Ce que la borne publie le 28
§2.1 — la classe déclare powerL1/L2/L3	currentL1/L2/L3 — 5,86 / 5,94 / 6,02 A. Le renommage (unité Ampère) est déployé ; les anciens noms ont disparu
§6.4 — poser phaseCount = 3 reste à faire	fait : l'état vaut 3 sur la Trydan
§2.2 — sessionEnergy n'est délibérément pas exposée	elle l'est : sessionEnergy = 4,229 kWh

Mais la levée du §2.2 n'est PAS acquise, et c'est le point à ne pas lire trop vite. Au moment du relevé, sessionEnergy valait exactement chargeEnergy — 4,229419231414795 des deux côtés. C'est précisément ce qu'on attend d'une session sans interruption : l'égalité ne distingue pas une grandeur construite d'un simple alias du registre 0x0BC4 ChargeEnergy, dont le retrait par evcc reste la raison du refus initial.

Le test qui tranche est nommé : une remise à zéro de chargeEnergy — elle survient à l'arrêt de la charge, pas au débranchement, mesurée le 28 au matin (0,3456 kWh → 0, 119 s avant que le câble ne bouge) — avec un sessionEnergy qui, lui, continue. Tant qu'elle n'est pas observée, la condition C1 de LM-1009 reste entière et l'app n'affiche aucun avancement de charge.

🔴 28 au soir — la campagne s'arrête, la trace ne viendra pas de cette borne

La Trydan non-Pro est en WiFi ESP32 sans repli filaire, et le lien s'est révélé inexploitable à deux mètres du point d'accès : 70 % de scrutations avortées, 12 bascules en injoignable en vingt minutes. Le modèle sort du catalogue ETM ; seule la Trydan Pro, qui a un port Ethernet, y reste.

Ce qui reste acquis de la journée est acquis : le champ existe, il est construit par le plugin (1.15.2+etm13 — incréments accumulés, remises à zéro détectées, redémarrage à l'ouverture de session), currentL1/L2/L3 est déployé, phaseCount vaut 3. Ce qui n'est pas acquis reste non acquis : la remise à zéro observée avec un sessionEnergy qui continue. Elle se prendra sur une Trydan Pro, et l'app n'affiche aucun avancement jusque-là.

---

1. Ce qui n'est pas encore sur la box

✅ FAIT le 27 au soir. powersync-plugin-v2c 1.15.2+etm12 est construit en arm64 et posé par deploy.sh. Vérifié sur la box : la ThingClass trydan est chargée, interfaces evcharger, power, connectable, appairage par address/port ou découverte.

Le .deb du canal powersync-testing ne convenait PAS : il n'existe qu'en amd64 (powersync-plugin-v2c 1.15.2+etm1 amd64), et l'index arm64 du canal ne porte que abbb2x et eastron. Un paquet amd64 ne s'installe pas sur le Pi. D'où la construction croisée.

Le travail v2c n'était pas sur une branche feature/v2c-trydan — il est déjà sur fix/fronius-meter-sign-and-battery-presence, et v2c figure dans le .pro.

Statut du plugin, à connaître : son propre brief le déclare « Partiel — PAS dans la matrice beta validée. Ne pas promettre tant que non testé sur borne réelle. » Demain EST ce test.

---

2. LES DEUX BLOCAGES

2.1 phaseCount n'existe pas — et le moteur supposera 1 phase

La ThingClass trydan déclare connected, pluggedIn, charging, power, maxChargingCurrent, currentPower, powerL1/L2/L3 et une série d'états de diagnostic.

Périmé le 28 : ce sont désormais currentL1/L2/L3, en ampères, nom et unité corrigés côté plugin — les anciens powerL1/L2/L3 étaient des ampères mal nommés, et aucun écran ne doit porter de conversion héritée de ce temps-là. Elle ne déclare pas phaseCount. Et il n'existe aucun registre de phases dans la carte Modbus V2C (0x0BC2–0x0BD5, 0x177A–0x1783) : le nombre de phases n'est pas lisible sur la borne.

EvCharger::phaseCount() retombe alors sur 1 quand l'état est absent (evcharger.cpp:147). Conséquences en chaîne, toutes silencieuses, sur une Trydan triphasée :

Grandeur	Calculée	Réelle	Effet
minPowerW (plancher publié)	6 × 230 × 1 = 1 380 W	6 × 230 × 3 = 4 140 W	l'arbitre croit pouvoir démarrer à 1 380 W
conversion W → A	P / (230 × 1)	P / (230 × 3)	consigne 3× trop haute, écrêtée à maxA

C'est exactement la famille de défaut que 3g-2 vient de fermer (relevé 3g-1 §3.4 : un plancher annoncé qui n'est pas celui qui gouverne le démarrage), rouverte par le plugin au lieu du moteur. Elle ne se verrait pas : la borne démarrerait, à un courant faux, et le waterfall allouerait un budget qu'elle ne consomme pas.

DÉCIDÉ (Patrick, la veille) : saisie à l'appairage. La Trydan du banc est triphasée — câbler en monophasé ferait tester autre chose que l'installation réelle, et le défaut est précisément celui que 3g-2 vient de fermer : silencieux, la borne démarre au mauvais courant.

✅ CORRIGÉ ET POSÉ — etm-powersync-plugins-modbus 1.15.2+etm12, commit 371eff6.

phaseCount est un réglage (settingsType, valeurs 1 ou 3, défaut 1), recopié dans un état que le moteur lit, et réappliqué sur settingChanged — une borne recâblée se corrige sans recréer le Thing. Vérifié sur la box : phaseCount type=Uint min=1 max=3 défaut=1.

Ce que le validateur de plugin a appris au passage : l'interface nymea evcharger définit phaseCount avec ses bornes (1 à 3), et refuse la classe qui l'omet. S'y conformer n'est pas une formalité — c'est ce qui fait lire l'état par le moteur à travers l'interface, plutôt que par une convention propre au plugin.

Le défaut est 1, comme le repli du moteur : une installation qui ne renseigne rien se comporte exactement comme avant le correctif. Donc le réglage doit être posé à 3 à l'appairage — c'est l'étape 5 du §6, et c'est le seul geste qui reste sur ce point.

Le repli « câbler en monophasé » est ÉCARTÉ : il ferait tester une installation qui n'est pas celle du client. Le correctif se fait avant le câblage.

2.2 sessionEnergy n'est délibérément PAS exposée — et c'est LM-1009 qui en dépend

⚠️ PÉRIMÉ LE 28 SUR LE FAIT, PAS SUR LE FOND. La borne publie sessionEnergy (4,229 kWh) depuis le déploiement du matin. Mais elle publie la même valeur que chargeEnergy, ce qui ne prouve pas que la première survive là où la seconde est remise à zéro — voir le bandeau de tête. Tout ce qui suit reste donc à lire comme la raison du refus, et comme la validation qui reste à faire.

Le registre existe : 0x0BC4 ChargeEnergy, kWh de la session. Mais le brief du plugin l'interdit explicitement : « NE PAS exposer en sessionEnergy », et la liste des interdits porte « Exposer sessionEnergy depuis ChargeEnergy sans validation matérielle ».

La raison est bonne et vient d'ailleurs : evcc a RETIRÉ son interface ChargeRater pour la Trydan (evcc-io/evcc#28047) — remontée d'énergie session jugée peu fiable côté firmware. ChargeEnergy reste donc un état de diagnostic.

Conséquence directe sur l'attendu de demain : « sessionEnergy sur matériel réel » n'est pas franchissable avec la V2C telle qu'elle est. Ce n'est pas un oubli, c'est un refus documenté — et c'est demain qu'il peut être levé, parce que la validation demande précisément ce qu'on aura : une borne réelle et un compteur de référence.

Ce que demain permet à la place, et qui a de la valeur :

• Valider ChargeEnergy contre une référence — intégrer currentPower de la borne sur une charge complète et comparer au kWh annoncé. C'est la validation matérielle que le brief exige, et elle débloque sessionEnergy pour de bon. Si l'écart est faible et stable, le câblage se fait ensuite en une ligne de JSON.
• Exercer la condition C1 de LM-1009 pour de vrai : une borne sans sessionEnergy doit dégrader visiblement. On aura le cas sur du matériel, dès le premier jour, sans le fabriquer. Et le piège à guetter est nommé : « pas mesurable » ne doit pas s'afficher « 0 kWh livré ».

---

3. La Skoda Enyaq — aucun plugin, donc voiture manuelle

Aucune intégration Skoda / VW nulle part dans l'espace de travail (recherche sur skoda|enyaq|weconnect : zéro résultat). L'Enyaq ne rapportera pas son état de charge.

Elle sera donc un Thing genericCar — voiture simulée, batteryLevel inscriptible — ce qui la place exactement sur le chemin décrit par LM-1009 : le moteur intègre la puissance de la borne, applique un facteur de pertes, divise par la capacité déclarée, et réécrit lui-même batteryLevel. Le pourcentage affiché demain sera une intégration, pas une lecture.

À saisir à la création (rien de tout ceci n'est deviné par le moteur) :

Réglage	Valeur	Pourquoi
capacity	capacité utile réelle de l'Enyaq (~58 / 77 kWh selon version)	divise l'énergie intégrée → une capacité fausse fausse tout le pourcentage
minChargingCurrent	6 A	entre dans max(borne, voiture) du plancher
phaseCount	3 (Enyaq charge en triphasé 11 kW)	plafonne le nombre de phases visé — c'est evTargetPhases() qui le lit
batteryLevel initial	l'état réel au branchement, saisi à la main	point de départ de l'intégration ; faux au départ = faux pour toute la session

C'est la démonstration vivante de LM-1009 : trois des quatre valeurs ci-dessus sont saisies à la main, et le pourcentage affiché en dépend entièrement. À noter dans le relevé.

---

4. Appairage de la V2C

• Transport : Modbus TCP, port 502. Il lui faut une adresse sur le LAN 192.168.1.0/24.
• Découverte : la ThingClass déclare createMethods: ["discovery", "user"] — découverte automatique ou saisie manuelle. Paramètres : macAddress, address, hostName, port.
• IP de test documentée : 192.168.1.127. Libre ce soir — vérifié, aucune machine ne répond à cette adresse.
• Le piège de la Terra AC, à ne pas rejouer : une borne qui ne répond pas à l'ARP tourne en ThingSetupStatusInProgress indéfiniment. Premier geste après câblage, avant nymea : ping depuis le banc, puis nc -z 192.168.1.127 502. Si l'ARP ne répond pas, le problème est réseau, pas logiciel.
• Registre à ne jamais écrire : Dynamic (0x177E) — casse la télémétrie de la borne. La neutralisation propre passe par PauseDynamic (0x1783).

---

5. Ce qui devient franchissable demain

Attendu	Franchissable ?	Condition
LM-1204-b — deux bornes en ligne	OUI	V2C + wallbox simulée. Le critère qui justifie 3g depuis le début, enfin exerçable sans la Terra AC.
Le plancher réel — négociation de courant, délai d'établissement, véhicule qui refuse	OUI	et c'est ce qu'aucune wallbox simulée ne prouvera jamais
minPowerW sans véhicule branché	OUI	depuis +etm24 la borne est hors arbitrage — vérifier qu'elle n'apparaît pas dans loads[] et que le journal le dit
EV_GRID_START	PEUT-ÊTRE	il faut que le budget tombe dans [plancher × 0,5 ; plancher[. À guetter, pas à fabriquer
sessionEnergy sur matériel réel	ATTENDU RETIRÉ (Patrick, la veille) — le refus V2C est documenté, pas un oubli	remplacé par deux choses, §2.2 : ré-examiner ChargeEnergy borne et référence en main, et exercer C1 de LM-1009 sur ce cas réel plutôt que sur un cas fabriqué
sessionEnergy survit-elle à une interruption ? (ajouté le 28)	REPORTÉ — Trydan Pro	le champ est construit par le plugin, mais l'observation qui le prouve (remise à zéro de chargeEnergy, sessionEnergy qui continue) n'a pas pu être prise : lien WiFi inexploitable, campagne arrêtée le 28 au soir. Rien n'est acquis, et l'app n'affiche aucun avancement

---

6. Liste de contrôle — ce qui reste

Fait le 27 au soir : construire le plugin arm64 · décider et implémenter phaseCount · poser le plugin. Le moteur tourne 1.15.2+etm24, le plugin 1.15.2+etm12, et rien n'a bougé côté arbitrage après le redémarrage (chauffe-eau 3 500 W, pac-terrain 3 000 W, degradedMode: false).

1. Câbler la borne, lui donner 192.168.1.127.
2. ping + nc -z 192.168.1.127 502 depuis le banc, avant d'ouvrir nymea. C'est le geste qui distingue un problème réseau d'un problème logiciel — la Terra AC a coûté une session faute de l'avoir fait.
3. Appairer la Trydan, vérifier connected: true et un currentPower qui bouge.
4. Poser phaseCount = 3 dans les réglages du Thing. Fait — vérifié le 28 : l'état phaseCount de la Trydan vaut 3. Le défaut est 1 ; sans ce geste, le plancher publié sera de 1 380 W au lieu de 4 140. C'est le seul point où l'oubli est silencieux — à vérifier par le minPowerW publié en télémétrie, pas de mémoire.
5. Créer la voiture genericCar avec les quatre réglages du §3 — dont capacity réelle et batteryLevel de départ, saisis à la main.
6. Associer voiture ↔ V2C, mode ChargingModeEco, et poser les rangs des deux bornes (par défaut elles arrivent toutes à 1 — cf. RELEVE_3g2.md §3.2).
7. Relevé : distinguer machine / test / lecture, comme RELEVE_LOTD.md l'exige.