0798b2937d
Deux correctifs issus de la même campagne (borne .103, banc .75, phaseCount = 3, 2026-08-28). Ils touchent les mêmes fonctions et sortent des mêmes relevés. 1. sessionEnergy — CONSTRUIT, pas câblé ------------------------------------------------------------------------------ La Trydan ne publie pas d'énergie de session. Son compteur ChargeEnergy (0x0BC4) est exact — son intégration recoupe currentPower à mieux d'un pour cent, deux fois de suite — mais il n'est pas conservé : le firmware le remet à zéro à chaque ARRÊT DE CHARGE, câble encore branché. Cycle mesuré : arrêt à t+1 s, remise à zéro à t+8 s, débranchement seulement à t+127 s. Le déclencheur est l'arrêt, pas le débranchement. C'est notre problème et pas celui du firmware : en pilotage par surplus, c'est notre propre arbitrage qui coupe au passage d'un nuage. Le HEMS effacerait donc sa propre mesure plusieurs fois par jour, et une nuit de recharge relue à 7 h vaudrait 0 — soit « rien livré », ce que la condition C1 de LM-1009 interdit d'afficher. accumulerEnergieDeSession() accumule les incréments avant chaque remise à zéro. Dans le plugin et pas dans le moteur : le plugin scrute à 30 s, le moteur à la minute — un incrément effacé entre deux lectures du moteur lui serait invisible. En sortie, le moteur et l'app reçoivent le contrat evcharger standard, sans cas particulier V2C à porter en aval. Même principe que le câblage d'energystorage sur la batterie SunSpec. Trois décisions, détaillées dans AGENTS.md § SESSION ENERGY : - RAZ à l'OUVERTURE de session, jamais à la fermeture. Après le départ de la voiture, sessionEnergy garde le total de la session terminée : la question « combien la nuit a-t-elle livré ? » se pose au matin, voiture déjà partie. Remettre à zéro au débranchement effacerait la réponse au moment précis où on la cherche. - Anti-clignotement STRUCTUREL, pas temporisé. Le débranchement doit être confirmé sur 3 polls RÉUSSIS consécutifs. updateFinished() n'est émis qu'après une séquence de lecture complète : une coupure WiFi GÈLE le compteur d'absences au lieu de le faire avancer. C'est la protection qu'il fallait contre le lien de ce matin (latence 2-4 s, 40 % de perte avant stabilisation). - Persistance sur deux supports. sessionEnergy en state « cached » ; le repère de reprise est la dernière valeur brute de chargeEnergy, elle aussi passée en « cached » — retirer cette propriété ferait repartir de zéro une recharge qui traverse un redémarrage, SANS QUE RIEN NE LE SIGNALE, d'où l'annotation en travers du code. Le drapeau « session ouverte » va dans pluginStorage(), écrit sur transition seulement (flash de la passerelle). Deux limites assumées plutôt que contournées : - Si un débranchement PUIS un rebranchement tiennent entièrement dans une coupure, la nouvelle session hérite du total de la précédente. La borne ne numérote pas ses sessions, et une RAZ de ChargeEnergy ne lève pas l'ambiguïté : elle survient aussi au sein d'une même session. Le choix inverse — repartir de zéro à chaque redémarrage — casserait le cas que ce correctif existe pour couvrir. - L'énergie livrée entre le dernier poll et l'arrêt de charge est perdue, bornée par un intervalle de poll. NON estimée par currentPower × Δt : on n'invente pas une mesure pour combler un trou de mesure. chargeEnergy reste publié à côté, sous son nom exact — sessionEnergy est la grandeur construite, chargeEnergy la mesure brute. Si les deux divergent un jour, on saura laquelle a menti. Seul le displayName change, « Session energy (diagnostic) » étant devenu mensonger. Ceci lève l'interdiction précédente (« ne pas exposer sessionEnergy », cf. evcc issue #28047), mais pas de la façon qu'elle envisageait : elle attendait une validation de fiabilité, la campagne a séparé exactitude (bonne) et conservation (nulle). 2. Power_L1/L2/L3 portent des AMPÈRES ------------------------------------------------------------------------------ La feuille V2C intitule 0x0BD9-0x0BDB « Power_Lx ». Mesuré : consigne 6 A → 5,9-6,0 lus ; consigne 10 A → 9,x-10 lus. Sous 230 V une puissance de phase vaudrait ~1 380 W, pas 5,9. Publiés en Watt, l'app affichait « 5,9 W » là où la borne dit « 5,9 A » — une unité qui ment, même famille que carBatteryLevel publié sous un nom de mesure. States renommés currentL1/L2/L3, unité Ampere. Les UUID ne changent PAS : l'identifiant a toujours porté des ampères, c'est le nom qui mentait. Les noms d'enum RegPower_Lx gardent en revanche l'intitulé du constructeur — c'est ainsi qu'on retrouve l'adresse dans la feuille — avec l'avertissement en commentaire. Bénéfice de bord : le déséquilibre entre phases, que ne donne aucune autre borne du catalogue, utile à la protection de surcharge par phase (LM-1006-1). 3. Observations de campagne consignées ------------------------------------------------------------------------------ - Latence de consigne asymétrique, du bon côté pour la sécurité : montée 6 → 10 A en ~30 s, descente 10 → 6 A en ~7 s. - maxChargingCurrent (consigne, 0x177D) et intensity (effet, 0x0BCD) diffèrent pendant la transition — même couple commandé/réel qu'allocatedW vs mechanism. Ne pas « corriger » l'un avec l'autre. - optimizerSuspended et conflictDetected étaient à True : la borne a son propre optimiseur et le HEMS le suspend. Second commandeur potentiel, à lire en diagnostic quand un écart consigne/effet n'est pas expliqué par la latence. - La ThingClass ne déclare que deux actions, maxChargingCurrent et power : phaseCount est un réglage de câblage, jamais une commande. Compile sans avertissement sous -Werror -Wall -Wextra. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A41CTzMvir1Y5ABPXW8xpB