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

DESIGN — la commande perdue, et l'écart que personne ne mesure

(Ouvert le 2026-09-01, sur le premier constat de RELEVE_APP_20260831.md. Le design avant le code, comme pour le délestage et le §10.)

1. Le fait, tel qu'il a été mesuré

Coupure Modbus. La box journalise Restoring manual values of false 6 A trois secondes après. La borne, elle, reste à power: true, 7 A — la consigne que l'arbitre lui avait donnée au cycle d'avant. Le lien revient : rien ne réapplique. En mode manuel personne ne commande, donc l'écart est permanent.

4,4 kW réellement tirés, draw.committedW à 0, un budget de surplus de 2 349 W qui ignore ces watts.

2. Ce que le fait dit vraiment — et il est plus large que son titre

« Réappliquer la commande de l'arbitre » ne décrit pas le cas : en mode manuel, l'arbitre ne commande pas. Ce qui s'est passé est autre chose, et c'est pire :

1. Le proxy amont a voulu restaurer des valeurs manuelles (false 6 A) ;
2. l'écriture a échoué pendant l'indisponibilité ;
3. personne ne l'a rejouée ;
4. l'organe est resté sur une consigne dont plus aucun commandeur ne se réclame — ni l'arbitre, qui ne commande plus, ni le mode manuel, dont la consigne n'a pas atterri.

La troisième forme de la même famille. Après la télémétrie qui ne distinguait pas une issue de son contraire (ECS-111) et la valeur de retour qui faisait passer un refus pour un succès (ECS-415), voici l'exécution : une écriture perdue, un état sain en apparence, available à vrai, et personne pour savoir que la commande n'a jamais atterri.

3. Ce que le moteur a déjà — et ce qui manque

Pièce	État
Dernière consigne écrite, charges en watts	existe — m_currentSetpointW, m_currentStage
Dernière consigne écrite, bornes VE	MANQUE — EvAdapter ne garde que m_lastActionAt
Ce que l'organe FAIT	existe — EvCharger::maxChargingCurrent(), états du Thing
Ce que l'organe MESURE, et ce que ça vaut	existe — deviceMeasurement(), measurement.source (LM-1105/LM-1106)
Détection de la FIN d'une indisponibilité	MANQUE — le seul chemin est clearFault(), actionné par l'opérateur
Comparaison commandé / constaté	MANQUE — nulle part

Le constat porte sur les bornes, et c'est précisément là que la mémoire de la commande manque. Ce n'est pas un hasard : les adaptateurs de charges en watts gardent leur consigne parce qu'ils en ont besoin pour l'écrêtage de verrou ; la borne, elle, était pilotée par le proxy amont, qui n'a jamais eu à se relire.

4. LES DÉCISIONS

4.1 — Réappliquer, ou signaler ? Réappliquer automatiquement une consigne vieille de plusieurs minutes est un geste dangereux : le monde a changé pendant l'indisponibilité — le surplus, l'heure, l'échéance. Rejouer une décision périmée, c'est décider avec des données mortes, exactement ce que le mode dégradé L2 refuse de faire.

Recommandation : SIGNALER toujours, RÉAPPLIQUER jamais telle quelle. Au retour de disponibilité, le cycle normal reprend la main et décide sur des données fraîches — c'est déjà le bon comportement. Ce qui manque n'est pas le rejeu, c'est que l'écart soit dit tant qu'il dure. Et il dure indéfiniment quand personne ne reprend la main, ce qui est le cas du relevé.

4.2 — Que publie-t-on, et sous quelle forme ? Un écart n'a de sens que rapporté à ce qu'on sait de l'organe. Proposition : un objet command au niveau de la charge, publié seulement quand la comparaison est possible —

"command": { "expectedW": 1380, "observedW": 4400, "divergent": true, "since": "…" }

measurement.source conditionne ce que vaut cette comparaison, et doit donc la gouverner : contre none, il n'y a rien à comparer et l'objet est absent — pas divergent: false, qui affirmerait la concordance qu'on ne peut pas constater. Même règle que partout ailleurs ici.

4.3 — La COMPTABILITÉ : le diagnostic était à corriger, et le vrai défaut est plus grave.

MESURÉ le 2026-09-01, avant d'implanter. Le constat disait « un budget de surplus qui ignore ces watts ». Ce n'est pas ce qui se passe. Quand une charge consomme et obéit, la comptabilité est juste : sa conso est recréditée puis réallouée à elle-même, et les suivantes ne reçoivent que le surplus réel (mesuré : export 500 W, A à 4 400 W obéissante → B reçoit 500 W). Corriger cela aurait été corriger un non-défaut.

Le vrai défaut : le recrédit est un PRÊT consenti contre l'obéissance. Son hypothèse est écrite dans le code — « le budget est une mesure dont la conso de la charge a déjà été retranchée » — c'est-à-dire « je peux rendre ces watts parce que je peux les reprendre ». Rien ne vérifie que l'emprunteur rembourse.

Mesuré, le cas où la promesse est engagée : export 500 W, A consomme 4 400 W, plancher de A à 5 000 W. A est commandée à 0, et ses 4 400 W sont redistribués à B.

	si A obéit	si A n'obéit pas
A	tombe à 0	reste à 4 400 W
B	4 000 W réels	4 000 W fictifs
maison	4 000 W pour 4 900 de production	8 400 W pour 4 900 → 3 500 W importés

Et l'identité de réconciliation TIENT dans les deux cas — surplus + recrédit − alloué == restant. C'est ce qui distingue un prêt d'une erreur : la comptabilité est juste, c'est l'hypothèse sur laquelle elle repose qui n'est pas vérifiée. Aucun contrôle de cohérence ne pouvait donc l'attraper.

Ce qui change maintenant : l'obéissance est CONSTATABLE. command.divergent (étape 2) dit si la charge a suivi au cycle précédent. Le recrédit peut donc être conditionné — c'est la proposition, et elle demande une décision parce qu'elle a son propre risque : l'anti-clignotement existe pour une raison, et le suspendre trop vite ferait osciller une charge saine sur un écart transitoire. since est précisément ce qui permet de distinguer les deux.

Ce que le §4.3 d'origine proposait — retrancher la conso subie du budget — est SANS OBJET : elle en est déjà retranchée, par le compteur. La note est conservée ici pour que personne ne la réimplante en la croyant oubliée.

4.3-bis — l'ancienne formulation, conservée pour mémoire. draw.committedW à 0 pendant que 4,4 kW sont tirés n'est pas un défaut d'affichage : le budget de surplus est calculé sans ces watts, donc le moteur alloue de l'énergie qui n'existe pas. Une charge que l'arbitre ne commande plus mais qui consomme est de la consommation fixe, au même titre que la base de la maison — c'est exactement le raisonnement d'ECS-410 pour une charge gelée, appliqué à une cause nouvelle.

Recommandation : la retrancher du budget, sans l'allouer. Elle n'est pas servie, elle est subie. La compter comme allouée serait prétendre l'avoir décidée.

Sur 18 kVA c'est invisible ; sur 6 kVA c'est le disjoncteur. Et le délestage ne rattrape pas ce cas : il agit sur la marge MESURÉE, qui inclut bien ces 4,4 kW — donc il protège. Ce qui reste faux est le budget, qui promet un surplus déjà consommé.

4.4 — Faut-il un état « commande en vol perdue » distinct d'un défaut ? ECS-410/ECS-414 couvrent l'écriture qui échoue trois fois → défaut. Ici l'écriture a échoué pendant une indisponibilité, et la charge est ensuite redevenue disponible : le défaut se lève, la divergence reste. À trancher : est-ce un faultCode de plus, ou un état orthogonal ?

5. ORDRE DE TRAVAIL — deux étapes à comportement constant d'abord

Étape 1 — la MÉMOIRE de la commande, sans rien en faire. EvAdapter retient sa dernière consigne appliquée, comme les autres adaptateurs le font déjà. Publication seule, comportement constant. Sans cette pièce, aucune des suivantes n'est calculable.

Étape 2 — l'ÉCART publié, sans décider dessus. L'objet command, gouverné par measurement.source. C'est la moitié qui rend le défaut visible, et elle ne change aucune décision — même stratégie qu'à l'étape C du §10, où publier le régime a précédé de décider avec.

Étape 3 — la COMPTABILITÉ corrigée. La conso subie sort du budget. C'est ici que le comportement change, et c'est la seule étape qui le fasse.

Étape 4 — la reprise en main, si elle est jugée nécessaire après avoir vu les traces des étapes 2 et 3. Délibérément en dernier : c'est la seule qui commande du matériel, et on saura alors combien de fois le cas se produit réellement.

---

6. CRITÈRE DE TRI DES TRACES — écrit le 2026-09-05, AVANT d'avoir les données

Écrit avant exprès. Un critère rédigé après coup se plie aux résultats : on écarte ce qui gêne et on garde ce qui confirme, sans jamais mentir, et sans jamais pouvoir le prouver. Celui-ci est daté et poussé avant l'ouverture de la fenêtre d'observation. S'il doit changer ensuite, ce sera un commit visible, avec sa raison.

Pourquoi il faut un tri

Le journal de divergence (+etm56) a produit 14 épisodes en 24 h sur le banc, avant même le retour de la V2C. Aucun n'est exploitable :

08:05  DÉBUT "chauffe-eau" — attendu 3500 W, mesuré 1500 W
08:13  DÉBUT "chauffe-eau" — attendu  500 W, mesuré 1500 W
10:01  DÉBUT "chauffe-eau" — attendu 3000 W, mesuré 1500 W

ECS-Meter publie 1500 W en permanence, PAC-Meter 800 W — vérifié sur trois lectures espacées. Ce sont des simulateurs à valeur fixe. L'écart mesuré n'est donc pas une désobéissance : c'est la distance entre une consigne qui varie et un compteur qui ne varie pas. La divergence « finit » quand la consigne passe par 1500 W — une coïncidence arithmétique, pas une obéissance.

Dimensionner l'étape 4 là-dessus aurait été la dimensionner sur des divergences qui n'existent pas.

Le critère, en deux conditions

Une divergence n'est exploitable que sur une charge dont le compteur suit réellement la consigne. Deux conditions, et les deux sont nécessaires :

1. measurement.source ≠ none. Sans mesure propre, l'écart est calculé contre une estimation, et il ne dit rien de la charge.
2. Le compteur doit avoir VARIÉ sur la fenêtre, indépendamment de la consigne. Un compteur dont l'écart-type est nul sur la période n'est pas un compteur : c'est une constante déguisée, et tout écart contre lui est un artefact.

Ne PAS trier par nom de charge. Écarter chauffe-eau et pac-terrain nommément serait fragile de deux façons : ça se périme au premier renommage, et ça n'attrape pas la troisième charge à compteur fixe qu'on ajoutera sans y penser. Le critère porte sur une propriété observable de la donnée, pas sur une liste.

Les faux positifs de la V2C, et ils sont d'une autre nature

La V2C a un vrai compteur, donc elle passe le critère ci-dessus. Mais chaque perte de lien produira une divergence qui n'est pas une commande perdue : c'est une mesure absente.

Il faut donc distinguer deux affirmations que l'écart seul confond :

	ce que ça veut dire	geste
elle n'obéit pas	la commande est partie, la mesure la contredit	c'est le cas de l'étape 4
on ne sait pas si elle obéit	la mesure manque ou est périmée	rien à reprendre en main

C'est exactement la distinction none contre l'absence d'un champ, appliquée à un écart. Une mesure absente qui se lit comme une mesure à zéro produit une divergence maximale, et c'est le pire faux positif possible : il ressemble trait pour trait au cas qu'on cherche.

Concrètement, une divergence dont la mesure vaut 0 pendant que le lien est tombé doit être comptée à part, jamais avec les autres. Le relevé du 2026-08-30 le documente : à la perte du lien, la V2C publie currentPower 0 et ses booléens à false, tandis que sessionEnergy reste à sa dernière valeur (LM-1012-d). Le zéro est donc publié, pas absent — et rien dans l'objet command ne le distingue d'un zéro réel.

Conséquence à porter au lot, et à trancher avant de compter : command devrait pouvoir dire que son observedW n'est pas fiable, plutôt que de laisser déduire. C'est la même parade que progress.regime pour l'avancement. Tant qu'elle n'existe pas, le tri se fait à la main sur les traces, en croisant avec les pertes de lien du journal.

Ce qui sera compté, et ce qui ne le sera pas

• Compté : les épisodes sur une charge à compteur variable, hors fenêtres de perte de lien.
• Compté à part : les épisodes concomitants d'une perte de lien — ils mesurent la disponibilité, pas l'obéissance.
• Écarté : les épisodes sur une charge dont le compteur est constant sur la fenêtre.
• Le compte des écartés est publié aussi. Un tri dont on ne dit pas ce qu'il a jeté n'est pas un tri, c'est une sélection.

---

7. CONDITIONS DE LA FENÊTRE D'OBSERVATION — week-end du 2026-09-06

Noté pour que les traces de lundi soient lisibles. Rien n'a été restauré : la configuration ci-dessous reste en place tout le week-end.

Posé le	dimanche 2026-09-06 à 08:19 (Europe/Paris ; box et atelier à la même heure depuis la correction du 2026-09-05)
Charge	chauffe-eau
Changement	minEnergyWhPerDay 3000 → 2000, dailyDeadline inchangé à "12:00"
Vérification	76 clés comparées entre capture et relecture : 1 divergence attendue, 0 imprévue
Capture d'avant	conservée hors dépôt, scratchpad/loadconfig_AVANT_weekend.json
Moteur	1.15.2+etm56 · plugin générique 1.14.2+etm3
Symboles de débogage	libnymea1-dbgsym / libnymea-core-dbgsym arm64 laissés en place jusqu'à lundi — donc aucune couture supplémentaire pendant la fenêtre

Ce que l'écran montre à la pose, et pourquoi ce n'est pas un défaut

À 08:19, le palier éco est ECO_FLOOR_MET avec deliveredWh = 30 475 Wh pour une cible de 2 000, measuredSince = 2026-09-05T10:00:00Z. L'obligation est tenue vingt fois.

C'est arithmétiquement correct et sans intérêt : le compteur de l'ECS publie 1 500 W en permanence (cf. §6), donc deliveredWh monte de 1,5 kWh par heure que la charge soit commandée ou non. La période courante a basculé hier à 12:00 ; vingt heures plus tard, elle a « livré » 30 kWh.

La fenêtre utile est à 12:00, et elle dure ~80 minutes

À chaque bascule de période, la base d'avancement est reprise (LM-1013-c). deliveredWh repart de 0 face à une cible de 2 000 Wh sur 24 h — soit une cadence de 83 W, financée par le réseau si le surplus manque. Le compteur fixe la comble en 2000 / 1500 = 80 minutes, après quoi l'écran repasse à ECO_FLOOR_MET pour les 22,7 h restantes.

Donc deux fenêtres exploitables sur le week-end : dimanche 12:00 et lundi 12:00, ~80 min chacune, où l'on voit un vrai plancher éco, son financement et sa cadence. Le reste du temps, l'écran montre l'état « tenue » — qui est aussi une forme à valider.

Et c'est la cinquième forme d'homogénéité qui fixe ce plafond (INVENTAIRE_MOCK.md §7). Sur un banc dont le compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible modeste et un chemin d'achat longuement exercé : ce qui décide n'est pas la cible, c'est la constance du compteur. Choisir une cible qui tienne l'achat en éveil tout le week-end reviendrait à dépasser 36 kWh/jour — c'est-à-dire acheter au plafond, précisément ce qu'on voulait éviter. La contrainte est du banc, pas du moteur.

Coutures ajoutées le 2026-09-06 — à connaître pour lire les traces

heure	événement	effet sur les traces
11:47:23	crête PV du simulateur portée de 9 000 à 6 000 W (banc/cmd/peak, retenu, courtier 192.168.1.131)	moins de surplus, donc plus d'achat réseau pour tenir le plancher éco
~12:00	voiture branchée à la V2C (pluggedIn: true, lien connected, sessionEnergy 0,44 kWh)	la borne entre dans l'arbitrage

Aucun redémarrage de nymead dans les deux cas : ce ne sont pas des coutures de baseline, seulement des changements de régime du banc.

Ce que le passage à 6 kWc ne casse PAS, contrairement à ce que j'avais craint. Le seuil de démarrage de la borne est minPowerW = 4140 W (3 × 6 A × 230 V) et le surplus ne dépasse pas ~2 700 W à 6 kWc. J'en avais conclu que la borne ne démarrerait jamais. Faux : mesuré à midi simulé, elle passe en EV_GRID_START dès 2 140 W de budget, puis en SURPLUS_SETPOINT. Le chemin d'appoint réseau (§3g-2, acquisitionTolerance) existe précisément pour ce cas, et BELOW_MIN_POWER seul ne dit pas que la borne est bloquée — il dit que ce budget-là ne suffit pas.

Convention de signe du réseau — mesurée, pour lever une ambiguïté d'écran

Energy.GetPowerBalance.currentPowerAcquisition est négatif en injection, positif en soutirage — même convention que banc/etat/grid du simulateur. Vérifié le 2026-09-06 sur dix échantillons appariés dont un passage par zéro (−638 → +1939 W) : 10/10 de même signe, écart moyen ~90 W dû au décalage d'échantillonnage entre les deux sources.

De même, currentPowerProduction est négatif — c'est la convention nymea, énoncée dans l'interface smartmeterproducer : « currentPower is always from a consumer perspective. Thus it will be a negative value for producing devices. »

Un client qui afficherait « consommation réseau » sur un currentPowerAcquisition négatif inverse le sens : la valeur négative dit que l'installation injecte. Le signe porte la direction ; la valeur absolue seule ne la porte pas.

VERDICT de la fenêtre du week-end — 2026-09-06 : elle n'a rien produit d'exploitable

Établi au journal, pas déduit.

La V2C est restée HORS WATERFALL du samedi 18:00 au dimanche 11:46 — 1 066 cycles, tous portant la même ligne :

[Arbitre] Borne "V2C Trydan" hors waterfall (mode manuel ou aucun véhicule branché).
          "V2C Trydan" has no car assigned. Ignoring...

Elle n'a donc pas produit une seule trace sur toute la période visée. Ce n'était pas un battement de lien : le moteur ne la voyait ni en mode automatique, ni avec un véhicule branché. La voiture est devenue visible à 11:46 le dimanche — Executing action V2C Trydan to power: ON, Charging current: 7A — et non le samedi soir.

Puis huit cycles utiles, entre 11:47 et 12:08, sur le PV simulé à 9 kWc :

11:47  Démarrage : plancher 4140 W, dont  896 W SOUTIRÉS (3245 W de surplus, tolérance d'acquisition)
12:03  Démarrage : plancher 4140 W, dont 2000 W SOUTIRÉS (2140 W de surplus)
12:05  Surplus PV 6663 W — consigne 6663 W
12:08  Surplus PV 5598 W — consigne 5598 W

Puis plus rien, depuis le passage au PV réel : le banc est passé d'un simulateur à 9 kWc à une installation réelle de 2 kWc. Un champ de 2 kWc ne peut pas alimenter le plancher de 4 140 W qu'exige une borne triphasée à 6 A. La tolérance d'acquisition comblait l'écart tant que le budget valait 2 000 à 3 200 W ; à 670 W elle n'a plus rien à combler.

Bilan pour l'étape 4 : rien d'exploitable ce week-end.

charge	traces	statut
V2C	aucune — hors waterfall 1 066 cycles	rien à trier
chauffe-eau	nombreuses	écartées — compteur constant (1 500 W puis 0)
pac-terrain	quelques-unes	écartées — compteur constant (800 W puis 0)

Le critère de tri du §6 écarte tout ce qui reste. C'est un résultat, pas un échec : il dit que la fenêtre a été ouverte sur un banc qui ne pouvait pas la remplir, et il nomme les deux raisons — une borne hors arbitrage, et des compteurs qui ne mesurent pas.

Précondition pour la prochaine fenêtre : un compteur RÉEL sur une charge pilotée (TEST_TERRAIN.md §12), et une borne effectivement dans le waterfall — à vérifier au journal avant d'ouvrir, pas après.

---

8. PROTOCOLE DU RELEVÉ DU 2026-09-08 — écrit avant, comme le critère

La voiture revient vers 9 h. Ce qui suit est écrit avant de mesurer, pour la même raison que le critère de tri du §6 : un protocole rédigé après coup se plie à ce qu'on a vu.

Ce qu'on observe, et ce qui serait un résultat

1. progress.regime de la V2C — première bascule observable sur du réel.

sessionEnergy est construit par le plugin, donc le régime devrait sortir measured. Mais sur un lien qui perd 40 % de ses trames, il basculera. C'est l'observation qui compte le plus, parce que la dérogation en dépend entièrement : sa fin par measurementLost se déclenche sur ce signal, et on ne l'a jamais vu changer ailleurs qu'en test.

ce qu'on voit	ce que ça dit
measured en continu	le lien tient assez pour que la cible soit vérifiable — la dérogation par cible est utilisable
bascules measured ↔ unmeasurable	le cas nominal de cette borne : la fin par perte de mesure va se déclencher souvent, et il faudra savoir à quelle fréquence avant de promettre une dérogation par cible
unmeasurable en continu	la cible en énergie n'est pas servable ici, et seule la durée reste

Aucune de ces trois n'est un échec — chacune décide de ce qu'on peut promettre.

2. command.divergent — les premières traces qui passent le critère du §6.

Jusqu'ici, aucune trace n'était exploitable : compteurs constants des deux côtés (§7). Avec une borne qui charge vraiment et un compteur qui suit, le critère est enfin satisfait — measurement.source ≠ none et un compteur qui a varié.

Regarder d'abord les épisodes COURTS. Ce sont eux qui décident si l'étape 4 vaut le risque de rejouer une commande : un écart de trois minutes qui se referme seul ne justifie pas de commander du matériel sur une consigne ancienne ; un écart qui dure et ne se referme jamais, si.

Et se souvenir du biais du journal : grep -c compte des lignes, pas des transitions (PORTING_STATUS.md). Ici la ligne [Divergence] DÉBUT / FIN est émise aux transitions seulement — c'est le comptage juste, contrairement à error limit reached.

3. Min+PV lui-même : palier éco au minimum avec boundBy: minimum, palier confort alimenté par le surplus, et le recrédit visible dans recreditedW. Vérifié sur le chauffe-eau le 2026-09-07 ; reste à le voir sur la borne, où le tirage est dix fois plus grand.

Ce qui invaliderait le relevé

• Un redémarrage de nymead pendant la fenêtre : la base d'avancement se repose et measuredSince repart. Ne rien déployer pendant l'observation.
• Une bascule de fuseau : aucune n'est prévue, et il n'y en aura pas.