La classe trydan ne déclarait qu'evcharger + connectable. Ça la tenait hors de
EnergyManagerImpl::watchThing(), qui ne branche un Thing sur le journal
d'énergie que s'il déclare energymeter, smartmeterconsumer, smartmeterproducer
ou energystorage. Energy.GetThingPowerLogs ne REJETAIT pas la demande : il
rendait zéro ligne pour ce thingId, et l'app listait la borne en « sans
historique » alors que sa puissance instantanée était parfaitement lisible.
Deux bornes côte à côte, une seule avec un passé.
Au passage, le portier n'est pas `smartmeter` — cette interface est VIDE, aucun
state requis, la déclarer n'aurait rien produit. C'est `smartmeterconsumer` qui
compte, et elle exige totalEnergyConsumed.
Or la borne n'a pas de totalisateur : aucun registre de la carte Modbus V2C n'en
porte un, et ChargeEnergy (0x0BC4) est effacé à chaque arrêt de charge. Il est
donc CONSTRUIT, comme sessionEnergy, sur les mêmes incréments — et désormais par
la même règle unique, incrementEnergie(), partagée par les deux compteurs pour
qu'une correction ne puisse jamais s'appliquer à un seul. Contrairement à
sessionEnergy il ne se remet jamais à zéro et n'a aucune condition de session :
une recharge lancée à la main sur la borne, hors pilotage, y entre aussi.
Deux repères distincts (baseline / baselineTotale) et non un seul : la machine à
états de session sort par plusieurs chemins qui écrivent baseline sans
accumuler, un repère partagé ferait dépendre le total de l'ORDRE des deux
appels.
CE QUI A LEVÉ LE BLOCAGE « MONOTONE À VIE »
Le brief tenait ce totalisateur pour bloqué : la moindre perte se lirait comme
une consommation négative en aval. C'est trop strict, et vérifié : le moteur
tient son PROPRE compteur, se cale sur la première valeur sans l'ajouter à son
diff, et resynchronise explicitement quand le compteur d'un Thing recule
(« seems to have been reset »). Une perte côté plugin ne peut ni injecter de
négatif en aval, ni effacer le journal déjà écrit, ni produire une marche à
l'ajout du Thing. L'exigence réelle est « ne jamais reculer PENDANT une
exécution » — ce que le state "cached": true et le repère relu de chargeEnergy
au setup assurent.
Limite assumée, la même que sessionEnergy : l'énergie livrée entre le dernier
poll réussi et une RAZ de la borne est perdue, bornée par un intervalle de poll
(30 s). C'est pourquoi ce calcul vit dans le plugin et pas dans le moteur.
VÉRIFIÉ SUR LE BANC (.75, 1.15.2+etm14, 2026-09-08 10:57)
energylogs.sqlite, pour {4d1adafd-cafc-4813-93b1-ca8933ce71ab} :
- thingCache : ligne absente avant, créée après — c'est watchThing() ;
- thingPower : 0 ligne avant, puis une par minute comme les cinq autres Things.
À SAVOIR : sur un Thing déjà appairé, things.conf écrase le `logged: true` que
l'interface porte pour currentPower/totalEnergyConsumed (loggedStateTypeIds y
vaut déjà {connected}, {charging}, {power}). Le journal d'énergie du moteur ne
dépend PAS de ce réglage — la courbe marche sans y toucher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
executeAction écrêtait le haut avec master->maxIntensity() mais le bas avec un
littéral 6.0. Une borne déclarant un minimum de 8 A aurait donc reçu une consigne
de 7 A écrite telle quelle : au-dessus du littéral, en dessous de ce que la borne
honore. L'asymétrie datait de l'écriture initiale — la lecture du registre 0x0BD1
existait déjà, elle n'était simplement pas utilisée là.
Les deux extrémités passent maintenant par courantMinimalEffectif() /
courantMaximalEffectif(), qui retiennent la PLUS CONTRAIGNANTE des deux sources :
la borne peut être plus exigeante que l'IEC 61851, jamais moins — une lecture
aberrante à 0 ne doit pas ouvrir la voie à une consigne de 3 A. La borne haute est
refermée sur la basse pour la même raison : RegMaxIntensity dépend de la version de
firmware, et un intervalle inversé ferait échouer setStateMinMaxValues.
Le même couple sert aux DEUX usages, et c'est le point : ce qui est publié comme
min/max du state (lu par le curseur de l'app et par
EvCharger::maxChargingCurrentMinValue() côté moteur) et ce qui est écrêté à
l'écriture. Les faire diverger donnerait un curseur qui propose une valeur que
l'action transforme en pause — une commande sans effet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le commentaire disait déjà la propriété ; il ne disait pas qu'elle PORTE. Une
réécriture qui ferait avancer le compteur au timeout, ou le piloterait depuis un
minuteur, la casserait sans qu'aucun test ne le dise.
Ce qu'elle garantit : un faux débranchement est IMPOSSIBLE à fabriquer par une
coupure réseau. Ce n'est pas théorique — 70 % de polls perdus mesurés le
2026-08-28, 40 % encore le 2026-09-06. Un compteur piloté au timeout clôturerait
une session toutes les 90 secondes sur ce lien.
Et elle devient load-bearing au-delà de la session : les dérogations se terminent
au débranchement, et l'asymétrie que leur design exige — prompt à conclure la fin,
lent à conclure la poursuite — existe déjà ici. Quelqu'un y a pensé avant nous.
Tiré de la campagne V2C du 2026-08-28, mais écrit pour TOUTE borne — Keba,
go-e et les suivantes. Une demi-heure par borne, et le défaut ne se découvre
pas chez un client.
Trois questions dont aucune ne se lit dans la documentation :
1. sessionEnergy est-il publié, et QUAND est-il remis à zéro — au branchement,
à l'arrêt de la charge, ou jamais ? Une borne peut publier un compteur exact
et pourtant inutilisable, parce qu'il n'est pas conservé : c'est le cas de la
V2C, effacement à chaque arrêt de charge, câble encore branché. Ne se voit
qu'en débranchant. Séparer exactitude et conservation.
2. pluggedIn clignote-t-il ? Neuf secondes de faux débranchement mesurées sur la
V2C au redémarrage de la borne. Toute logique déclenchée par un débranchement
doit être confirmée sur plusieurs polls RÉUSSIS — et un poll en échec ne doit
pas compter comme une absence, sinon la coupure réseau fabrique le
débranchement qu'on filtrait.
3. currentPower est-il une mesure ou la consigne renvoyée ? Symptôme : une
valeur trop belle, qui suit la commande sans retard. C'est ce que
measurement.source distingue côté moteur (INTERFACE.md, LM-1105).
Deux pièges de lecture payés pendant la campagne, écrits pour n'être payés
qu'une fois : un délai de confirmation se compte en polls et non en secondes
(3 polls à 30 s = 60 s, pas 90) ; et sur lien dégradé la durée perd son sens
(à 70 % de perte, 3 polls réussis d'affilée demandent ~26 min en espérance).
tools/qualifier-borne.sh est le squelette : il suit le journal, n'imprime que
les transitions, horodate, et refuse de tourner si la catégorie de log du plugin
n'est pas active — sans quoi il tournerait en silence et on conclurait à tort
que la borne ne fait rien. Aucune adresse codée en dur (cf. § Miroir public).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A41CTzMvir1Y5ABPXW8xpB
Trois polls échoués d'affilée marquent la borne injoignable. Sur le lien
dégradé du 2026-08-28 (~70 % de perte), cela donne 12 bascules « unreachable »
en vingt minutes. Une borne qui disparaît toutes les deux minutes ne se pilote
pas, quel que soit le code : LM-1204-b, le plancher réel et EV_GRID_START
porteraient tous ce bruit.
Rien n'est changé dans le comportement — seulement documenté, parce que le
seuil ne PEUT PAS être tranché sur un lien malade. Le protocole tient en trois
étapes, à dérouler une fois le point d'accès rapproché : mesurer le taux de
polls avortés, compter les bascules sur la même fenêtre, puis conclure. Si les
bascules disparaissent, le seuil est bon et détecte vite une borne réellement
absente ; si elles persistent malgré un bon signal, c'est lui qui est trop
serré.
Le relever maintenant masquerait le vrai défaut au lieu de le corriger, et
retarderait d'autant la détection d'une borne vraiment partie.
Commentaire seul côté code : le .so n'est pas modifié, pas de redéploiement.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A41CTzMvir1Y5ABPXW8xpB
Les deux correctifs V2C de la campagne du 2026-08-28 : sessionEnergy construit
par accumulation, et les registres 0x0BD9-0x0BDB republiés en ampères.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A41CTzMvir1Y5ABPXW8xpB
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
Aucun registre de phases n'existe dans la carte Modbus V2C : la borne ne sait
pas dire si elle est câblée en mono ou en tri. La ThingClass ne le déclarait pas
non plus, et le repli du moteur pour un état absent est SILENCIEUX —
EvCharger::phaseCount() rend 1.
Sur une Trydan triphasée, cela publie un plancher de 1 380 W au lieu de 4 140
(6 A × 230 V × 1 au lieu de × 3) et convertit l'enveloppe allouée en un courant
trois fois trop élevé. La borne démarre, au mauvais courant, sans qu'aucun
journal ne le dise.
C'est la famille de défaut que le moteur vient de fermer en 3g-2 — un plancher
annoncé qui n'est pas celui qui gouverne le démarrage — rouverte côté plugin.
Trouvée la veille de la pose, en lisant la déclaration de classe plutôt qu'en
l'exécutant.
La valeur vient donc d'un RÉGLAGE (1 ou 3, défaut 1), recopié dans l'état que le
moteur lit, et réappliqué sur settingChanged pour qu'une borne recâblée se
corrige sans recréer le Thing. Le défaut 1 est celui du repli du moteur : une
installation qui ne renseigne rien se comporte exactement comme avant.
L'état porte minValue 1 / maxValue 3 — l'interface nymea evcharger définit
phaseCount avec ces bornes, et le validateur refuse la classe sans elles. S'y
conformer, c'est être lu par le moteur À TRAVERS l'interface, pas par une
convention propre au plugin.
Compile amd64 0 erreur / 0 warning.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj
Constaté en reconstruisant le banc le 2026-08-26. Le simulateur a été redémarré
sans batterie puis de nouveau avec, sans jamais rompre la connexion TCP. Le
plugin a continué de lire l'ancienne géométrie : `ProtocolError` toutes les 7 s
sur le modèle 124 disparu, puis — une fois la batterie revenue — un
`currentPower` FIGÉ à 0 pendant que les registres portaient StCha = 2000 W et
ChaSt = Charging. Trois minutes de `thingPower` à 0.0 sur une batterie en charge.
Un `systemctl restart nymead` force la redécouverte et la valeur repart
immédiatement à 2000,0 W. Le défaut n'est donc ni dans le signe ni dans le
mapping de D-9 : ceux-là sont justes et le prouvent dès que la découverte est
refaite. Il est dans le fait qu'une liaison thing↔modèle est établie une fois et
jamais reconsidérée — et le storage y est plus exposé que les autres things
parce qu'il dépend maintenant de TROIS modèles au lieu d'un.
Rare sur matériel, mais pas théorique : une mise à jour de firmware, ou une
batterie ajoutée à un hybride déjà appairé, produisent la même transition.
Le signal existe déjà et n'est pas exploité — le ProtocolError répété à une
adresse jusque-là valide dit que la chaîne a bougé.
Documenté, pas corrigé : cela touche au cycle de découverte, hors périmètre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y3gzsuwENJfJtvuNDT3xGn
Constaté au banc à 14:41:58 : l'avertissement « has a model 160 but no
StCha/StDisCha block » a été émis une fois, au démarrage, sur une machine dont
les deux blocs existent et dont le currentPower a ensuite suivi la batterie
correctement en charge, en décharge et au repos.
Cause. libnymea-sunspec crée les blocs répétés d'un modèle depuis
`initFinished`, émis pendant la PREMIÈRE lecture, juste avant `blockUpdated`.
Sur ce premier signal les blocs existent mais n'ont jamais été remplis : tous
les `IDStr` sont vides, rien ne se classe, et `hasBatteryBlocks()` répond faux.
Cette réponse est exacte et hors sujet — la question n'était pas « pas de
batterie » mais « pas encore lu ».
Ce que le faux positif coûtait. Ce n'est pas du bruit : le README dit à
l'exploitation de chercher cette ligne EN PREMIER pour distinguer une batterie
cassée d'une batterie non mesurable. Une ligne qui sort à chaque démarrage sain
ne distingue plus rien, et le diagnostic que ce lot venait d'installer était
mort-né.
Les deux questions sont maintenant posées séparément : `blocksAreIdentified()`
avant `hasBatteryBlocks()`. Sans identification, on se tait et on attend le tour
suivant — `readBlockData()` passe à chaque rafraîchissement de toute façon.
Le garde en double au moment du binding disparaît aussi : les deux updaters se
gardent eux-mêmes, un seul endroit à tenir à jour plutôt que deux qui peuvent
diverger.
Deux tests figent la distinction, dont un sur le cas où l'avertissement DOIT
sortir — un GEN24 sans batterie, lu, identifié, sans bloc batterie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y3gzsuwENJfJtvuNDT3xGn
Le relevé du 2026-08-26 a montré DCW_SF passant de -2 à -1 entre une batterie à
l'arrêt et une batterie en charge, sur le même onduleur, à quelques secondes
d'intervalle. Un DCW brut de 20000 vaut 200,0 W avec le premier facteur et
2000,0 W avec le second.
Ce que ça casserait est de la même famille que 86fb244 mais plus discret : pas
de dénormal, pas d'erreur Modbus, un appareil qui se déclare connected, et une
puissance simplement dix fois fausse. La propriété tient aujourd'hui parce que
libnymea-sunspec lit les 90 registres du modèle 160 en une transaction et relit
les facteurs du bloc fixe AVANT les blocs répétés — deux propriétés qui vivent
en amont, que rien dans le compilateur ne tient, et qu'une optimisation de la
lecture ferait sauter sans aucun signe extérieur.
Le commentaire est donc à l'endroit qui en dépend : au-dessus de
storageModuleReadings(), qui consomme dcPower(), avec un pointeur au site de
readBlockData() et sur le champ ModuleReading::dcPower.
Le README documente en outre le côté exploitation de D-9 : un onduleur qui
publie le 124 sans le 160 porte energystorage avec un currentPower figé à zéro,
avec les deux lignes de journal exactes à chercher et la commande pour les
trouver.
sunspecStorage déclarait `battery` mais pas `energystorage`. Les trois
consommateurs qui filtrent par cette interface ne la trouvaient donc pas : le
bilan de puissance de nymea (`currentPowerStorage`, celui que le CLIENT lit sur
son tableau de bord), la réserve de stockage de la recharge VE, et celle du
waterfall. Vérifié sans authentification dans `energylogs.sqlite` de .75 : la
colonne `storage` de `powerBalance` est à 0.0 sur toutes les lignes, pendant
que la batterie affiche 50 % et « Holding ». Elle n'était pas à zéro, elle
était invisible.
Ce n'était pas une ligne de JSON. `energystorage` exige `currentPower` (W,
signé) et `capacity` (kWh), qu'aucun des quatorze états ne portait, et les
déclarer sans les câbler aurait donné une batterie éternellement inerte — pire
que son absence, puisque la réserve lirait « ni charge ni décharge » au lieu de
« je ne sais pas ».
D'où viennent les deux états. Le modèle 124 ne porte AUCUNE puissance : WChaMax
est un maximum, StorAval est en ampères-heures. La puissance instantanée vit
dans le modèle 160, réparti sur deux blocs `StCha` et `StDisCha` dont le `DCW`
est un uint16 toujours positif, l'inactif à zéro. D'où
`currentPower = DCW[StCha] - DCW[StDisCha]`, positif en charge, conformément à
libnymea/interfaces/energystorage.json (« positive is 'consumed' »). C'est
l'INVERSE de la convention constructeur du contrat §4, et
`FroniusRules::batteryPower()` est réécrite comme la négation stricte de la
nouvelle `storageCurrentPower()` pour qu'aucune des deux ne dérive seule.
`capacity` vient de WHRtg du modèle 120, et l'état est laissé tranquille plutôt
que mis à zéro quand le nameplate ne l'implémente pas.
Le signe est MESURÉ, pas déduit. Banc .211 unité 1, consigne batterie imposée
par MQTT, registres relus en lecture seule :
+2000 W -> StCha 2000,0 W StDisCha 0,0 W ChaSt Charging
-1500 W -> StCha 0,0 W StDisCha 1500,0 W ChaSt Discharging
Le même relevé a montré `DCW_SF` passant de -2 à -1 entre repos et charge : le
facteur d'échelle n'est jamais mis en cache d'un relevé à l'autre.
Écart assumé, D-9 dans DIVERGENCES.md : `sunspecStorage` est partagé avec le
vendor générique, et les interfaces se déclarent par thingClass. Un appareil
générique publiant le 124 sans le 160 porte désormais `energystorage` avec un
`currentPower` figé à zéro. Les trois alternatives sont pires — une thingClass
Fronius distincte détruirait le Thing existant et son historique. Le plugin
avertit donc UNE FOIS par thing quand il ne trouve pas de source de puissance,
en distinguant « pas de modèle 160 » de « modèle 160 sans bloc batterie ». Ça ne
remplace pas la mesure, mais ça retire le silence.
La cohérence des unités avec l'interface est vérifiée à la COMPILATION par
nymea-plugininfocompiler : mettre `KiloWattHour` sur `currentPower` fait échouer
le build. Onze tests `test_D9_*` figent le reste.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y3gzsuwENJfJtvuNDT3xGn
Le message affirmait « le plugin lit de travers », vrai avant 1.15.2+etm9 et
faux depuis. L'outil sert à mesurer un APPAREIL, pas à juger une version : il
dit maintenant ce que lirait un lecteur gardant le défaut de la bibliothèque,
et rappelle depuis quelle version le vendor Fronius force big endian.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
byteOrder() renvoyait ByteOrderLittleEndian au motif qu'on « supposait le
défaut SunSpec ». La supposition confondait le défaut de la SPÉCIFICATION avec
celui de libnymea-sunspec, qui est son contraire : convertToUInt32 lit
registers.at(1) puis .at(0) en little endian. Garder ce défaut revient à lire
tous les float32 avec leurs deux mots permutés.
Mesuré le 2026-08-07 sur un Symo réel, en lecture seule : le compteur 213 sur
l'unité 200 sert Hz = 4248 0000, soit 50,0000 en big endian et 2,3777e-41 en
mots inversés. L'onduleur 113 concorde.
Le coût n'était pas un décalage mais une absurdité. Reproduit sur banc avec le
simulateur émettant l'ordre du matériel : un compteur important 2,7 kW rapporté
comme exportant 107 MW, et l'arbitre enclenchant toutes les charges sur un
« Surplus PV 107622496 W ». Le thing reste connected, sans erreur Modbus.
Conséquence sur l'ordre des correctifs : meterPowerSign() reste juste mais
n'est observable qu'une fois celui-ci appliqué — corriger le signe d'un
dénormal ne produit rien.
solarEdge force déjà big endian de son côté et le générique garde son paramètre
utilisateur : aucun des deux chemins n'est touché. test_AC_18 fige le
raisonnement plutôt que la seule valeur. Voir DIVERGENCES.md D-8.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Le garde de présence batterie demandait isFroniusChild(thing->id()), qui
résout le parent par myThings().findById(). Pendant le setup initial la
connexion n'est pas encore enregistrée : la recherche répond faux, le garde
est contourné, et l'enfant storage est créé alors qu'InBatV et StorAval sont
nuls. Constaté en boucle fermée sur le simulateur, avec la trace nymead
"Invalid parent thing id ... Not adding thing to the system".
Le garde interroge maintenant directement le thing de connexion que la
fonction tient déjà. Le signe compteur passe de même par le parentThing déjà
résolu, dont la non-nullité est garantie quelques lignes plus haut.
La suite logique ne pouvait pas attraper ce défaut : elle couvre la décision
pure, pas le câblage. Consigné en D-7.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
L'antidote AC-16 triphasé verrouille le chemin réellement emprunté par le
matériel terrain, reproduit sur le simulateur en profil Symo (onduleur
modèle 103, compteur modèle 203) : compteur à -500/-100/-100 W, que le
plugin etm6 rapportait en +500/+100/+100.
tools/read-model124.py relève en lecture seule le bloc storage d'un
onduleur, sans aucune dépendance à installer. Il sert à lever D-6 : le côté
« batterie présente » du discriminateur reste inféré faute d'un GEN24 équipé.
Sur le simulateur il montre pourquoi ni le SoC ni les consignes ne peuvent
servir de discriminateur : le bloc annonce un SoC de 50 %, un statut Holding
et WChaMax à 10 kW alors qu'InBatV et StorAval sont nuls.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deux défauts constatés sur le GEN24 des beaux-parents (Primo GEN24 3.0,
Smart Meter TS 65A-3, sans batterie).
Signe du compteur. onMeterBlockUpdated() négociait le signe de tous les
modèles compteur sans distinction de fabricant. Sur Fronius la négation est
fausse : le Smart Meter émet déjà dans la convention nymea. L'onduleur étant
monophasé, il sert de référence de direction : le plugin rapportait la phase
portant l'onduleur en soutirage et les deux autres en injection, ce qui est
impossible sans source. L'arbitre en concluait « Surplus insuffisant
(-842 W) » et laissait chauffe-eau et PAC éteints en plein export.
La décision vit dans FroniusRules::meterPowerSign() et n'est annulée que sous
une froniusConnection. Les vendors generic et solarEdge sont inchangés, ce
qu'un antidote verrouille. Les compteurs d'énergie sont corrects et ne sont
pas permutés.
Batterie fantôme. Un GEN24 hybride publie le modèle 124 sans batterie câblée,
d'où un enfant storage bloqué sur batteryCritical.
FroniusRules::hasBattery() exige une grandeur physique non nulle (InBatV ou
StorAval), le SoC étant écarté car 0 % ne se distingue pas d'une batterie
vide. Le côté « batterie présente » reste INFÉRÉ : voir D-6, à valider sur un
GEN24 équipé avant tout déploiement.
Suite logique : 50 tests verts, dont six antidotes AC-16 et AC-17.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records the new nymea-plugin-sunspec-etm01 binary package, the Fronius
vendor it carries, the storage setpoint corrections and the added
Build-Depends. The previous entry described an unrelated abbterra fix,
so the package would have shipped under a version that never mentioned
it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The plugin was added to PLUGIN_DIRS by the vendoring commit but never
packaged, so dh_missing found its .so in debian/tmp with nowhere to go
and aborted the whole source package: no .deb at all came out of
experimental-silo, not even for the four unrelated plugins.
Declares the binary package and adds libnymea-sunspec-dev to
Build-Depends. Upstream does not need that dependency because it builds
libnymea-sunspec from the same source tree; this repository vendors only
the plugin and links against the installed library.
Named with the -etm01 fork suffix rather than the upstream name, which
our own repository already publishes in stable and testing as a mirror
of 1.15.2. Same file path and same pluginId, hence Conflicts, Replaces
and Provides against nymea-plugin-sunspec so the two can never be
installed side by side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Building against a local sysroot rather than an installed
libnymea-sunspec-dev left the resulting binaries unable to find
libnymea-sunspec1 at run time: the sysroot is not in the dynamic
linker's cache, so -L alone is not enough and every test had to be
launched through LD_LIBRARY_PATH.
Only the NYMEA_SUNSPEC_PATH branch is touched. The package build resolves
the library through pkg-config and gets no rpath, as before.
Verified both ways: with NYMEA_SUNSPEC_PATH the binary carries a RUNPATH
to the sysroot, resolves libnymea-sunspec1 there and runs its 44 tests
with LD_LIBRARY_PATH unset; without it, no sunspec rpath is generated at
all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Where it should have landed in the first place. A change climbs the
chain: experimental-silo first, landing-silo once a nightly has proven
itself, main last. The previous merge put this straight into
landing-silo, one rung below stable, for work only ever verified against
the bench simulator and never on hardware.
Carries what landing-silo had wrongly received: the vendored SunSpec
plugin and the Fronius multi unit ID support, the three abbterra commits
the branch dragged in from the abbterra TCP line, and the two AGENTS.md
commits.
landing-silo goes back to main in the next step; nothing is lost, it all
lives here now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First content of the promotion chain. Brings the vendored SunSpec plugin,
the Fronius vendor and its multi unit ID support: one froniusConnection
thing now carries two SunSpecConnection objects, inverter and Smart Meter
on separate unit IDs behind the same host and port.
Verified before merging: 60 offline tests green, plus 8 green against the
bench SunSpec simulator in froniusgen24-sunspec mode.
Note: the branch was cut from the abbterra TCP line, so this merge also
brings three abbterra commits that were never in main.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The suite captured a stack local of initTestCase() by reference in two
lambdas that outlive it. Once the function returned they wrote into a
stack slot reused by later frames, corrupting the running test: a
QSignalSpy reported a phantom emission, reading its recorded arguments
segfaulted, and the count changed when unrelated locals were added. Both
observed failures came from that, not from the plugin. The two flags are
members now.
Covers the two remaining claims the offline suites cannot reach: a meter
slave ID of 0 opens no second connection against a real device, and
losing the meter connection leaves the parent connected and the inverter
data flowing, marking only the meter child disconnected.
That last test drives one explicit block read first. This bench replaces
the plugin timer with a null object, on purpose, so nothing would
otherwise ever mark a child connected and the cut would prove nothing.
Run against the bench simulator: 8 tests, 8 green. Each of the two
corrections was confirmed able to fail by reintroducing its pre-F3 form.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The whole point of keeping the meter connection in a hash of its own was
that not a line of the generic and solarEdge vendors would change.
Checks it rather than claiming it: a stored solarEdge connection, whose
behaviour no suite covered until now, must still end up with exactly one
connection, as must a generic one.
Also records the connection a discovery came from in
processDiscoveryResult() rather than in the discoveryFinished handler.
The initial setup calls it from a second handler on the same signal, so
recording it there made the orphan sweep depend on the order Qt happens
to invoke the two.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The two most certain defects of the multi unit ID work are invisible to
the offline suites, because they only appear once a discovery has
actually run: the orphan sweep deleting the children of the other
connection, and the aggregation of the connected state.
This suite mounts the plugin behind a real ThingManager against a real
device. It is deliberately not a testcase, so "make check" never runs
it, but it is still built so it cannot rot unnoticed. Without
SUNSPEC_TEST_HOST every test skips, and no address is written into the
repository: the address of a real installation is customer data.
NOT YET RUN against hardware. It needs the address of a GEN24 and, given
the polling rate guidance, a deliberate decision to point it at a
customer inverter.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
processDiscoveryResult() makes child things disappear when their model
is no longer announced. It used to confront them with the models of the
one connection that had just finished discovering, which is only half of
the picture on a thing carrying two: the inverter discovery would delete
the meter child, and the meter discovery the inverter and storage ones,
on every single reconnect.
The sweep now waits for every connection of the parent to have reported
a successful discovery, then confronts the children with the union of
their models. A grace period releases it if a connection never reports,
so a hung discovery cannot freeze the cleanup for good.
That grace period is inferred, not measured: it is set generously
because sweeping too late leaves a stale child showing as disconnected,
while sweeping too early deletes a thing of the user. Recorded as D-2 in
DIVERGENCES.md with what to measure to replace it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A GEN24 answers for the inverter on unit ID 1 and for its Smart Meter on
unit ID 200 by default, behind the same host and port. One thing now
carries two SunSpecConnection objects, the second one driven by the
meterSlaveId parameter that until now no line of C++ ever read.
The meter connection is created during setup but left idle: it is only
brought up once the primary connection has finished discovering, so the
two never handshake at the same time towards the same inverter. An
absent meter never fails the pairing, since a GEN24 without a Smart
Meter is a legitimate installation and the parameter has a non zero
default the user did not choose.
thingRemoved() and the reconfigure path now dispose of both connections
through a single entry point. Their else if chain used to stop at the
primary one, which left the meter connection outliving its thing with an
open socket and signals pointing at a destroyed Thing.
Child things look their model up across every connection of their
parent. The two connections of a GEN24 never announce the same model ID,
so no discriminator has to be persisted.
Adds a test suite instantiating the plugin behind a real ThingManager
with two connections. It lives in its own binary because the F1 suite
checks global call counters that extra configured things would falsify.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Takes the slave ID as an argument instead of reading it from the thing,
and takes whether it is the primary connection of that thing. Only the
primary one follows the network monitor, writes the connected state of
the thing and lands in m_sunSpecConnections; a secondary one lands in a
hash of its own.
Child things are updated per connection rather than per parent, resolved
from the model each child is bound to. With a single connection that is
every child of the parent, so nothing changes here yet.
No caller creates a secondary connection at this point: behaviour is
unchanged for all three vendors.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A GEN24 answers for the inverter on one unit ID and for the Smart Meter
on another, behind the same host and port. Isolate the decision to open
that second connection as a pure function, so it can be pinned down
without nymea, and leave the logging of the refusal to the caller.
Refuses a meter slave ID out of the 0..247 range, treats 0 as "no meter
on this connection" as documented, and refuses a meter slave ID equal to
the inverter one: a second socket on the same unit ID would rediscover
the very same models and duplicate every child thing. That last case is
reachable, since the discovery writes the scanned slave ID into the
thing parameter.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
AC-7 asks for the meterSlaveId parameter to be advanced. That property
does not exist on nymea 1.15.2 param types: the metadata verifier
rejects unknown fields, so adding it makes the whole plugin fail to
load rather than merely hiding a parameter.
Measured by loading the plugin JSON, with and without the flag, into a
PluginMetadata linked against the installed libnymea, rather than read
from an upstream tree that may differ from the package.
Also records the three other divergences the multi unit ID work runs
into, two of which predate it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
setupThing() only knew about sunspecConnection and solarEdgeConnection, so a
froniusConnection thing fell into the final Q_ASSERT_X. In a release build the
assert is compiled out, setupThing() returns without calling info->finish(),
and the pairing hangs until the setup times out - with no message at all. In a
debug build nymead dies on the assert instead.
Take the same branch as the two vendors that already work: createConnection()
already reads the slave ID and picks the byte order for froniusConnection, so
no new logic is needed.
postSetupThing() and thingRemoved() are unchanged on purpose. The former only
special cases solarEdgeConnection, for the battery search a Fronius must not
run, and registers the refresh timer for every thing. The latter is keyed on
m_sunSpecConnections, which createConnection() now populates for Fronius as
well.
Makes the four cases of tst_sunspecplugin pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The existing suite only exercises free functions and the plugin JSON, so it
cannot see whether a thing class is dispatched at all. A thing class missing
from the dispatch in setupThing() falls into the final Q_ASSERT_X: in a debug
build the process dies, in a release build the assert is compiled out and
setupThing() returns without ever calling info->finish(), leaving the pairing
stuck with no message.
Split the tests into two suites. The logic one keeps its former scope and its
single dependency on libnymea-sunspec. The new one instantiates the plugin
behind the real ThingManager of libnymea-core and a faked HardwareManager, so
the dispatch of setupThing(), postSetupThing() and thingRemoved() is covered.
No network access takes place: the faked monitor is never reachable, so the
plugin never attempts a Modbus connection.
The four new cases fail: froniusConnection is not dispatched yet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds a fronius vendor and a froniusConnection thing class alongside the
generic sunspec and solarEdge ones, following the SolarEdge mechanism but
none of its workarounds - no proprietary battery block and no PV
production computed by difference, since the GEN24 exposes model 160.
FroniusRules holds the vendor decisions as pure functions:
- discovery only keeps devices announcing Fronius as manufacturer;
- the byte order is the SunSpec default, not the forced big endian that
is specific to SolarEdge, and no endianness parameter is exposed;
- meterSlaveId defaults to 200, 0 meaning no meter on this connection;
- a hard 7 s floor on the poll interval. Polling faster can push the
inverter offline towards the vendor portal, and recovery needs an
AC+DC power cycle on site, so this is a guard in the code rather than
a configurable default;
- the registers the inverter accepts and then silently ignores are
refused before anything reaches the wire;
- the six HEMS battery modes map onto ChaGriSet, StorCtl_Mod, InWRte and
OutWRte, negative meaning charge;
- model 160 blocks are classified by IDStr, never by index: on a three
or four MPPT inverter the battery blocks are not in position 3 and 4.
Storages under a Fronius connection default revertTime to 300 s.
Setpoints now reread the scale factor before writing and read the written
registers back afterwards, reporting a mismatch through a new
controlHealthy state - the only defence against writes that are accepted
and then ignored without a Modbus exception.
Byte order and the revert timer semantics on model 124 are inferences, not
measurements; see specs/fronius-sunspec.md, H-2 and H-3.
setInOutWRteRvrtTms() existed but was never called. InOutWRte_RvrtTms is
the delay after which the inverter drops the setpoint and resumes its
native behaviour. Left at 0, a setpoint stays active indefinitely, HEMS
stopped, network lost or process crashed included - the battery stays
where the last command put it.
Add a per-thing revertTime parameter, 0..28800 s, defaulting to 0 so the
generic vendor keeps its current behaviour, and route every setpoint
through SunSpecStorageLogic::planSetpoint(). The plan orders the writes -
ChaGriSet, StorCtl_Mod, then the rates - and appends the revert timer
last, so the timer never starts counting against a setpoint that has not
been written yet.
Writes are issued sequentially rather than in parallel: the order is part
of the contract with the hardware.
onStorageBlockUpdated() fed chargingRate from wChaGra() and dischargingRate
from wDisChaGra(). Those are the gradients, in percent of WChaMax per
second, and read only on several inverters. The matching actions write
InWRte and OutWRte, in percent of WChaMax. The user wrote one quantity and
read back another.
Feed the two rate states from inWRte() and outWRte(), and keep the
gradients under names that cannot be mistaken for setpoints:
chargeGradient and dischargeGradient, read only.
enableDischarging was never reconciled either, while enableCharging was.
It stayed frozen on the last written value and drifted silently as soon as
the inverter changed StorCtl_Mod on its own. Reconcile both flags.
The mapping moves into SunSpecStorageLogic so it can be exercised on a
register dump without a running nymea.
chargingRate and dischargingRate map onto InWRte and OutWRte of model 124,
which are int16 setpoints ranging from -100.00 to +100.00 percent of
WChaMax. Declaring them as 0..100 makes a forced charge structurally
inexpressible: nymea rejects the negative action parameter before it ever
reaches the plugin.
Also fixes the default value, which was the boolean false on an int state.
One test per AC of specs/fronius-sunspec.md, named test_AC_<n>_<what>.
Definition criteria (value ranges, thing classes, defaults) are checked by
re-reading integrationpluginsunspec.json. Behaviour criteria run either on
a model 124 register dump fed to the real libnymea-sunspec model, or on the
pure logic units the plugin is about to grow.
All red at this point: sunspecstoragelogic and froniusrules do not exist
yet, so the suite does not compile. That is the expected starting state.
AC-1..AC-4 are the four upstream anomalies of the generic sunspec vendor
(setpoint range, read/write mismatch on the rate states, enableDischarging
never reconciled, revert timer never written).
AC-5..AC-15 are the Fronius-specific behaviour: manufacturer filter, byte
order, connection parameters, polling floor, forbidden writes, the HEMS
intent to register table, scale factor reread, readback verification and
the model 160 block classification.
Points the design contract leaves open are recorded as explicit working
hypotheses (H-1..H-6) rather than blocking on them.
Vendor the sunspec plugin into this repo so the Fronius work and the
upstream storage fixes can live here. Sources only: build artefacts and
generated plugininfo headers are excluded.
libnymea-sunspec is deliberately NOT vendored - the plugin must stay
rebasable on upstream nymea, so it links against libnymea-sunspec-dev.
sunspec.pri resolves it via pkg-config, with a NYMEA_SUNSPEC_PATH
override for a local sysroot, mirroring modbus.pri.
See sunspec/VENDORED.md.
Follow-up to the etm1 fixes, driven by live debugging against a real ABB
Terra AC 7 kW behind a Waveshare RS485->TCP gateway (<ip-lan>, slave 2):
- etm3: disable TCP auto-discovery (createMethods = "user" only). Discovery
blind-scans the LAN and SIGSEGVs nymead as soon as any Modbus device answers
:502 with an exception response. The crash is in the generated reachability
handler (abbterramodbustcpconnection.cpp:2062 dereferences the check-reachable
reply after it is freed); it could not be fixed from the discovery code alone.
A gateway's slave id can't be discovered anyway, so manual add is required.
- etm2: still defer/guard AbbTerraTcpDiscovery::cleanupConnection() teardown
(kept for correctness even though discovery is now off by default).
- etm4: setupTcpThing() never called connectDevice(), so manual setup hung until
timeout. Start the connection when the network monitor reports the device.
- etm5: decode the serial-number and firmware register fields as BCD per ABB
spec §5.1 (0x46 = week 46, not 70; 0x22 = 22 kW). The binary reading rejected
real chargers ("does not match the ABB Terra AC Modbus register map").
Verified end to end: charger adds cleanly (TACW7-4-4624-S0034), states poll and
actions execute, no SIGSEGV. The underlying discovery/generated-code crash is
tracked separately.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two coupled fixes so the ABB Terra AC can be added over Modbus TCP:
- Restore checkReachableRegister ("serialNumber") in the register JSON.
The libnymea-modbus 1.15 code generator *requires* it — without it the
connection classes (abbterramodbustcpconnection.h) are never generated and
the plugin fails to build. Reverts the false lead in 4fa06df. The register
is valid: mbpoll confirms holding reg 16384 (uint64) responds at slave 2.
- Fix a use-after-free in AbbTerraTcpDiscovery::cleanupConnection() that
SIGSEGV'd nymead during network discovery whenever any Modbus device on the
LAN answered on :502 with an exception (e.g. "illegal data address"). The
method is invoked from several of the connection's own signals; it now
bails out on the second (re-entrant) call and disconnects the connection's
signals before disconnectDevice(), so the teardown can no longer re-enter
while the QModbusReply "finished" handler is still dereferencing the reply.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
