DEUX DEMANDES DE PATRICK.
1. Une barre de navigation sous les onglets, à la place de la puce de date :
‹ 3 sept. → 9 sept. › Aujourd'hui
Le libellé suit la granularité de l'onglet — « 9 sept. 2026 », « 3 → 9 sept. »,
« sept. 2026 », « 2026 » — parce que dire « jour » en montrant une semaine est
exactement l'erreur que les onglets faisaient avant d'être corrigés.
Le sélecteur existait déjà dans la barre du haut, mais il permettait de sauter
à un jour, pas de reculer d'une semaine puis d'une autre. Or lire une
consommation, c'est presque toujours la comparer à la période précédente : ce
geste-là doit coûter un appui, pas l'ouverture d'un calendrier et le calcul
mental de la date d'avant.
La flèche « suivant » est GRISÉE, pas masquée : une commande qui disparaît
laisse chercher où elle est passée, une commande grisée dit « il n'y a rien
après ». Et elle est bornée au présent — sans ça on part dans un futur où la
box n'a rien, avec un graphe vide qui ne dit pas qu'il l'est PARCE QU'on est
allé trop loin.
2. Le sous-titre « le bloc orange est partagé : ce qui a été produit ET gardé »
est supprimé.
Et une variable morte retirée avec sa raison : le soutiré n'est pas relu de
`totalAcquisition` mais dérivé de `consommation − autoconsommé`. Le relire
ferait une pile dont les segments ne rejoignent pas leur sommet dès qu'un
compteur dérive — un trou dans la barre que personne ne saurait lire.
L'identité des compteurs se vérifie ailleurs, sur le bilan du jour, où elle a
une phrase pour se dire.
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
LA DATE PASSE ENTRE LA LÉGENDE ET LE TRACÉ (demande de Patrick). Sa place n'est
pas cosmétique : elle QUALIFIE ce qu'on regarde, donc elle doit se lire avant le
graphe, pas se trouver après lui. Sous les deux cartes, elle arrivait une fois
la lecture faite — et sur trois jours, une courbe lue sans sa date est une
courbe lue de travers.
Posée sur les DEUX cartes : elles partagent le cadrage, mais si on défile
jusqu'à ne voir que la seconde, elle doit se suffire. Une carte qui dépend d'une
autre pour être comprise ne tient pas dès qu'on la regarde seule.
🔴 ET L'ÉCHELLE SUIT DÉSORMAIS LA FENÊTRE, PAS TOUT LE JEU CHARGÉ.
Vu à l'écran : axe à 11,9 kW pour une fenêtre qui ne dépasse pas 2,5 — les
courbes rampaient au ras de l'abscisse, et la production était purement
invisible. Une pointe d'avant-hier écrasait le détail d'aujourd'hui.
C'est le passage à 72 h qui l'a créé, et c'est lui qui l'a rendu visible : sur
24 h, fenêtre et jeu de données avaient presque la même amplitude, donc le
défaut ne pouvait pas se voir. Élargir le glissement sans rééchelonner faisait
une loupe qui déplace le cadre sans grossir — exactement ce qu'il devait éviter.
Corrigé sur les deux graphes : cadrer l'un sur la fenêtre et l'autre sur tout
les rendrait incomparables.
Captures : docs/captures/2026-09-09_energie-plage-sous-legende.png
docs/captures/2026-09-09_energie-echelle-fenetre.png
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Demande de Patrick : élargir le glissement. 72 h chargées au quart d'heure, la
fenêtre en montre 12 — on remonte donc sur trois jours sans changer d'onglet.
TROIS CHOSES QUE CE CHANGEMENT RENDAIT NÉCESSAIRES.
La taille de fenêtre était « la moitié du jeu de données ». Avec 24 h ça donnait
12 h ; avec 72 h ça en aurait donné 36, et la fenêtre aurait grandi avec les
données au lieu de rester une fenêtre. Elle est fixée en DURÉE : la densité de
lecture ne dépend plus de la profondeur chargée.
La fenêtre s'ouvre sur le plus RÉCENT. Calée au début, elle aurait montré
avant-hier soir à l'ouverture — la seule vue dont personne n'a besoin en
premier.
Et la plage visible porte sa DATE : « 8/9 21:00 → 9/9 09:00 ». Sur 24 h,
« 09:00 » désignait sans ambiguïté ce matin ; sur trois jours, c'est l'un de
trois matins, et l'axe n'affiche que des heures. Sans cette ligne, l'écran
répondait à côté de la question « c'était quand ? ».
Et les étiquettes des deux BORDS de l'axe sont retirées : fl_chart en pose une à
`min` et à `max` en plus de celles de l'intervalle, et elles se superposaient à
leur voisine — « 20:4500 » à gauche, « 08:1509:00 » à droite. J'avais corrigé le
bord gauche sans penser que le droit avait le même défaut : la recherche
auto-confirmante, appliquée à un axe. On ne perd rien, la ligne de plage donne
les deux bornes exactes avec leur jour.
Vérifié à l'écran : fenêtre 21:15 → 09:00 à l'ouverture, ligne de plage et
indice de geste présents.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
TROIS DEMANDES DE PATRICK.
1. Le soutiré passe du rouge au BLEU. Avec l'orange partagé sur les deux barres,
le rouge rendait l'image trop chaude — et le bleu est déjà la couleur de la
maison partout ailleurs. Il ne reste d'orange que le bloc partagé, celui qui
doit se voir.
2. Second graphe en vue barres : « Où est passée la consommation » — une barre
empilée par période, une couleur par charge déclarée, plus le reste du foyer
qui ferme la barre à la consommation totale.
L'énergie vient du compteur cumulé de chaque appareil (`totalConsumption`),
jamais d'une intégration de la puissance — intégrer supposerait la puissance
constante entre deux échantillons. Vérifié à la sonde avant d'écrire : ECS
80,8 kWh et PAC 43,1 kWh sur la fenêtre, avec des deltas journaliers réels.
Une charge dont le compteur n'a pas bougé donne 0 kWh, qui est une MESURE.
Une charge dont le cumul manque à une borne n'a PAS de part. Les deux se
ressemblent à l'écran et ne disent pas la même chose. Et un compteur qui
recule est une remise à zéro, pas une consommation négative : la part est
refusée plutôt que rendue absurde.
🔴 3. LE « 6/9 » EN DOUBLE N'ÉTAIT PAS UN DÉFAUT DE L'APP. C'est la trace de
notre propre bascule de fuseau du 2026-09-06 : la frontière de journée de la
box a glissé d'une heure, et l'historique porte deux échantillons pour le
06/09 — 00:00 et 01:00. Le graphe affichait fidèlement une « journée » d'une
heure à côté de journées entières.
La couture est PERMANENTE : elle est dans les données passées, pas dans une
requête. Tout écran qui compare des périodes doit grouper par période civile,
jamais par indices consécutifs. Aucune énergie n'est perdue — la tranche
d'une heure est absorbée dans sa journée.
Et une étiquette d'axe illisible : fl_chart en pose une à `min` en plus de
celles de l'intervalle, et les deux se superposaient — « 20:4500 ». Deux heures
imprimées l'une sur l'autre ne se lisent ni l'une ni l'autre.
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Les onglets portaient chacun le nom d'un cran EN DESSOUS de leur plage : « Jour »
montrait 7 jours, « Semaine » 28, « Mois » 365. Quatre étiquettes, quatre
mensonges — et la journée que le premier promettait n'était nulle part.
L'onglet « Année » manquait, puisque c'est « Mois » qui la montrait.
Heures 24 h au ¼ h courbes, axe glissable
Jour 00:00 -> 24:00 barres, au pas horaire
Semaine 7 jours barres, au jour
Mois 30 jours barres, au jour
Année 365 jours barres, au mois
LES BARRES. Deux barres par période, chacune empilée, et le segment
« autoconsommé » est LE MÊME des deux côtés, à la même couleur :
Production = autoconsommé + exporté
Consommation = autoconsommé + soutiré
Deux barres simples diraient laquelle est la plus haute ; celles-ci disent où
est passée la différence — la question qu'on se pose devant un bilan.
Pas de diagramme divergent, et la raison est propre à ce dépôt : la box publie
déjà `production` avec un signe négatif, défaut qui nous a coûté deux écrans et
trois jours. Dessiner la production sous l'axe rendrait une capture correcte
indiscernable de ce bug.
L'énergie vient des CUMULS, jamais des puissances : chaque barre est une
différence de compteurs. Une période dont une borne ne publie pas ses cumuls n'a
pas de barre — pas une barre à zéro. Et la fenêtre demandée déborde d'un
échantillon avant le début, sans quoi la première barre n'a pas de prédécesseur.
Quatre défauts trouvés à l'écran, tous invisibles au test :
- `barGroups` était OUBLIÉ. Les groupes étaient calculés, `maxY` en découlait,
donc l'axe montait à la bonne hauteur — et aucune barre n'était dessinée. Tout
ce qui entoure les données avait l'air correct ;
- « 80.0kWh » ne tenait pas dans 46 px et se coupait en « 80.0kW / h ». Une
unité coupée en deux lignes se lit comme une autre unité ;
- une plage de 7 jours partant de 08:12 coupe deux journées en deux : deux
barres portaient « 6/9 » et la semaine en comptait huit. Toutes les vues en
barres se calent maintenant sur minuit ;
- les notes par consommateur s'affichaient sous les barres, où aucun
consommateur n'est tracé.
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Demande de Patrick. Fait par FENÊTRE glissante (minX/maxX) plutôt qu'en faisant
défiler le graphe entier : l'échelle en kW reste visible pendant le geste, alors
qu'un défilement horizontal l'emporterait hors du champ au moment où on en a
besoin.
⚠️ On borne minX/maxX, on ne DÉCOUPE pas les données : découper renumérotrait
les index, et l'axe du bas — qui lit `_data[x.round()]` — désignerait alors les
mauvaises heures. Les séries restent entières, la fenêtre ne fait que cadrer.
96 points au quart d'heure sur 24 h : tout montrer écrase le détail, et il n'y a
alors rien à faire glisser. La fenêtre en montre la moitié.
Trois détails qui vont avec :
- le geste convertit des pixels en points d'échantillon, donc glisser d'une
largeur d'écran déplace d'une fenêtre entière quelle que soit la densité ;
- la fenêtre est bornée aux données — glisser dans le vide ferait croire qu'il
n'y a rien à cet endroit, alors qu'il n'y a pas d'endroit ;
- l'espacement des étiquettes se calcule sur ce qui est VISIBLE : le calculer
sur le jeu entier en placerait trois, mal réparties.
Le détecteur de geste n'est posé que sur les vues glissables : envelopper un
graphe qui ne glisse pas volerait le défilement vertical de la page pour rien.
Et l'indice ne sort que là où le geste existe.
Les deux graphes partagent le même cadrage — comparer deux fenêtres différentes
n'aurait aucun sens.
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Décision de Patrick, réaffirmée : « tu gardes tout, seulement le bouton boost on
supprime ».
Je l'avais écrit et posé quelques heures plus tôt, en lisant « le bouton de
boost : ouvre-le quand tu veux » dans un message du moteur comme un feu vert —
alors que la décision produit était déjà prise en sens inverse. Un avis
technique sur la faisabilité ne révise pas un arbitrage de produit ; il fallait
demander, pas inférer.
Retiré : l'usage de `EvBoostButton` sur l'écran de la borne, son import, et le
helper `_entreeTelemetrie` devenu orphelin.
Gardé, sur instruction explicite : le widget, `setLoadDerogation` /
`clearLoadDerogation`, le modèle `Derogation` / `DerogationEnded` et leurs 19
tests. Ce n'est pas de la donnée fabriquée comme `DayPlan.demo()` — c'est la
lecture d'un contrat réel, testée, qui ne s'affiche nulle part et ne peut donc
rien afficher de faux. Le jour où le boost revient, il se rebranche en trois
lignes.
Vérifié à l'écran : « Mode de recharge · lu : Min+PV », trois boutons Manuel /
PV / Min+PV, Min+PV allumé parce que c'est ce que la box porte. Rien d'autre.
Capture : docs/captures/2026-09-08_ev-trois-modes.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Vu à la capture du bouton de boost : la note « le mode de recharge se règle
depuis la tuile Borne EV des favoris » est visible trois centimètres au-dessus
des boutons de mode, dans le même défilement. Les boutons ont été déplacés ici
le 2026-08-28 et la phrase ne l'avait pas suivi — elle envoyait chercher ce qui
est sous les yeux.
Capture des trois modes et du bouton d'action :
docs/captures/2026-09-08_ev-modes-et-boost.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le lot complet côté app, écrit sur le contrat vérifié dans Introspect sur .75 en
1.15.2+etm61 : SetLoadDerogation { loadId, durationS, o:targetWh } /
ClearLoadDerogation { loadId }, et derogationEnded[] { cause, loadId,
o:restoredMode } au niveau de la trame.
CE QUI EST UN BOUTON D'ACTION, PAS UN MODE. Une dérogation se superpose au mode
courant et s'efface ; elle ne le remplace pas. La mettre dans le sélecteur
ferait croire qu'on en sort en choisissant autre chose.
UNE DURÉE, TOUJOURS. Bornée [60, 21600] côté moteur. L'écran n'offre AUCUNE
option « jusqu'à annulation » — pas parce que l'appel échouerait, mais parce que
la promesse serait mauvaise : une dérogation qui ne sait pas dire quand elle
finit ne devrait pas exister (LM-1500). Le filet reste armé même avec une cible,
parce qu'une cible repose sur un instrument et qu'un instrument peut se taire.
L'ÉTAT NE SE LIT PAS DANS LE MODE. Si la borne était en manuel, le moteur force
Eco le temps de la dérogation : GetChargingInfos montrerait alors un mode que
personne n'a choisi. La vérité est sur la charge —
LoadTelemetryEntry.enDerogation.
Trois refus d'inventer, chacun figé par un test :
- entrée de télémétrie absente -> le bouton se TAIT. « Pas d'entrée » n'est pas
« pas de boost », c'est « on ne sait pas » ;
- échéance dépassée alors que la box annonce encore la dérogation -> on la NOMME
au lieu de rabattre à « 00:00 » : c'est une contradiction entre deux champs de
la même trame, et le zéro l'effacerait ;
- cause de fin inconnue -> aucun libellé. Une box plus récente peut en publier
une septième ; lui coller la phrase d'une autre serait pire.
Et `EnergyErrorInvalidParameter` sur l'arrêt ne crie pas au refus : la
dérogation a pu finir seule pendant l'appui, et une course que l'utilisateur ne
peut pas éviter n'est pas une erreur à lui montrer.
⚠️ boundBy a DEUX catalogues : drawCap|loadCeiling sur la dérogation, mais
« minimum » sur ECO_FLOOR_GRID — relevé sur la V2C aujourd'hui. Même nom, sens
différent : aucune traduction partagée.
⚠️ Écrit d'après le contrat, PAS observé : DEROGATION_ACTIVE, endsAt et boundBy
ne sont pas dans Introspect (les params d'une décision sont une carte libre), et
aucune dérogation n'a tourné pendant une sonde. Tous les champs restent
nullables. Noté aussi qu'Introspect SOUS-DÉCLARE — il annonce draw{committedW}
seul alors que la box publie authorisedW/binding/bindingPhase/perPhaseBound —
donc son silence ne prouve rien.
La feuille de choix défile : 47 px de débordement trouvés par le test sur une
surface courte, donc réels sur un téléphone à police agrandie.
358 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
DayPlan.demo() fabriquait vingt-quatre heures de flux : une gaussienne solaire
et des coefficients écrits en dur — solToEcs = excédent × 0,35, solToVe × 0,3,
solToBatt × 0,15, battToHouse = déficit × 0,55 — sous le titre « Plan de la
journée · aujourd'hui », sans la moindre mention. Y compris une batterie
alimentant la maison à partir de 17 h, sur une installation qui n'a pas de
batterie.
Cinquième après les deux MPPT, les 38 % de PAC, les 82 % de part solaire et le
SOC à 62 %. Même réponse à chaque fois : il n'y a rien derrière.
Un plan suppose de savoir ce qui VA arriver — il demande une prévision PV et une
source tarifaire, dont aucune n'existe. La carte reviendra avec elles.
Le code de fabrication part AVEC la carte : DayPlan, HourlyFlow, WeatherPoint,
WeatherKind et le painter sont supprimés, pas mis de côté. Un générateur de
données plausibles laissé dans le dépôt se rebranche — c'est exactement ce qui
s'est passé quatre fois déjà.
339 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Décision de Patrick : trois modes suffisent — Manuel, PV, Min+PV. Le boost n'est
pas un quatrième mode, c'est la dérogation (+etm61).
LE FAIT. Le bouton écrivait `ChargingModeNormal`, qui sort la borne de
l'arbitrage et lui restitue ses valeurs manuelles stockées —
manualChargingEnabled, manualMaxChargingCurrent, manualDesiredPhaseCount. Sur
.75 elles valaient false / 6 A / 3 phases : mesuré le 2026-09-08 à 11:09:51,
l'appui a ARRÊTÉ la charge et armé un verrou de 300 s. Pas une régression —
c'est ce que Normal a toujours fait. C'est le nom qui mentait.
Renommé jusque dans le code (`ChargingMode.boost` -> `ChargingMode.manuel`), pas
seulement sur l'étiquette : un identifiant faux reste un piège pour le prochain
lecteur, et c'est précisément ce qui a duré des mois ici. L'ordre met Manuel en
tête, parce que ChargingModeNormal est aussi le mode d'office d'une borne
détectée.
ET LE RENOMMAGE NE SUFFISAIT PAS. « Manuel » dit QUI commande, pas ce que la
borne va faire : tant que l'app n'offre pas de régler ces valeurs stockées, le
mode veut dire « ce qui traînait la dernière fois ». Passer en manuel demande
donc confirmation, et la confirmation dit la conséquence — la charge peut
s'arrêter — AVANT, pas après.
⚠️ La confirmation ne se déclenche pas sur un ré-appui du mode déjà en place :
une confirmation qu'on apprend à cliquer sans lire ne protège plus de rien. Un
test le fige.
Vérifié sur .75 (1.15.2+etm61) : SetLoadDerogation et ClearLoadDerogation sont
dans Introspect, avec derogationEnded / durationS / restoredMode. Le contrat de
la dérogation est écrit dans CLAUDE.md — durée obligatoire bornée [60, 21600],
état lu dans decision.code == "DEROGATION_ACTIVE" et jamais dans le mode, fin au
niveau de la trame avec six causes. Aucun bouton de boost n'est écrit : c'est le
lot suivant.
Et une sonde pour le moteur, faite au passage : la V2C est bien restée en
ChargingModeNormal et elle est ABSENTE de loads[] — hors arbitrage. Leur
hypothèse est confirmée sans redémarrage.
339 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
La V2C et la borne simulée, toutes deux en `ev`, recevaient exactement le même
violet : indiscernables dans l'empilement, et la légende répétait la même
pastille. Vu à l'écran dès qu'une seconde borne est apparue.
`EtmTokens.nuance` décline sur le RANG dans le domaine, donc une troisième borne
prend sa teinte sans qu'on déclare quoi que ce soit. Le décalage porte sur la
LUMINOSITÉ, pas sur la teinte : glisser la teinte finirait par heurter le
domaine voisin, l'éclaircir garde la famille lisible.
⚠️ La série est bornée à quatre, et c'est explicite plutôt que subi : au-delà,
l'écart ne se voit plus, et prétendre distinguer huit nuances d'un même violet
serait une promesse que l'œil ne tient pas. Le rang 3 et le rang 9 rendent la
même couleur — le signe qu'il faut alors autre chose que la couleur pour
identifier, et c'est un choix d'écran, pas un réglage de palette. Un test le
fige.
La couleur est calculée à UN endroit, partagé par le tracé et la légende : deux
sources de couleur, c'est une légende qui finit par désigner la mauvaise bande.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
CARTES. Elles lisaient `energyData.dayProductionWh`, qui porte en réalité le
compteur CUMULÉ depuis l'origine : « Production 62946.74… » au-dessus d'un
graphe de 24 h. Et « Gains 8789.84 € » n'avait aucune source — un prix du kWh
que personne n'a saisi. Elles lisent maintenant DailyBalance, comme le tableau
de bord, et chaque taux porte son dénominateur (« 22 % sur 1,1 kWh produits »).
Mise en page reprise de la maquette validée.
V2C. `powersync-plugin-v2c 1.15.2+etm14` lui a ajouté `smartmeterconsumer` :
vérifié à la sonde, elle rend 1 point contre 45 aux autres, son historique
commençant à 10:57. Le filtre d'alignement précédent l'aurait sortie du TRACÉ en
la laissant dans la LÉGENDE — le défaut qu'on venait de corriger sur l'autre
graphe. L'alignement passe donc par instant, et une série ne contribue que là
où elle a des points.
Avant son premier point, sa consommation est comptée dans le reste du foyer :
le total reste juste, seule la RÉPARTITION est incomplète, et c'est ce que dit
la note. Trois états, trois phrases — « pas d'historique », « mesurée depuis
HH:MM », « 0 W mesuré » — et aucune ne se dessine comme une autre.
Et le commentaire de fetchThingPowerLogs est corrigé deux fois : il était
périmé, et il nommait le mauvais portier. `smartmeter` est une interface VIDE
qui ne conditionne rien ; c'est `smartmeterconsumer` qui décide, via
EnergyManagerImpl::watchThing().
🔴 SIMULATION. L'écran faisait `if (!connected) startSimulation()` au montage.
Monté avant que la WebSocket soit établie — le cas normal — il basculait tout le
service en démo et n'en ressortait jamais. Vu à l'écran, box joignable : une
sinusoïde orange et un SOC à 75 % sur une installation SANS batterie. Rien ne
distinguait ces données inventées des vraies : ni couleur, ni mention, ni forme.
La fabrication sans même l'étiquette qui la blanchit.
Le tableau de bord avait retiré la même chose pour la même raison : la démo est
un CHOIX, pris depuis l'écran Installations, jamais un repli silencieux. L'écran
attend maintenant la connexion et se rattrape dès qu'elle arrive.
Captures : docs/captures/2026-09-08_energie-cartes-journalieres.png
docs/captures/2026-09-08_energie-empilement-v2c.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Validé par Patrick. Sa proposition — production en jaune, autoconso en orange,
et des traits pleins — partait d'un bon constat, mais la couleur ne pouvait pas
régler le problème : superposées, autoconsommation et production sont égales au
watt près dès que rien n'est exporté, et deux traits pleins superposés n'en
laissent voir qu'un, quelles que soient leurs teintes. Le défaut est
géométrique, pas chromatique — et le pointillé posé avant n'était qu'un
contournement.
Empilées, le recouvrement devient impossible :
jaune PV -> réseau (exporté) ┐
orange PV -> maison (autoconsommé) ┘ sommet = production totale
La production cesse d'être une courbe : elle EST le haut de la pile. Quand rien
n'est exporté la bande jaune a une hauteur nulle — vrai, et lisible d'un coup
d'œil. L'export devient une SURFACE au lieu d'un écart à mesurer à l'œil entre
deux traits.
Vérifié à l'écran : l'orange porte le fond de la journée, le jaune ne sort que
sur l'épisode d'export de fin d'après-midi.
Deux détails qui vont avec :
- `_aire` ne courbe pas (`isCurved: false`) — une spline peut passer sous zéro
entre deux points, et une bande d'énergie sous l'axe affiche une grandeur qui
n'existe pas ;
- les lignes n'ont plus de remplissage par défaut : un voile à 7 % recouvrait
les bandes et faussait leurs teintes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
« SOC % » figurait en dur dans la légende du premier graphe. Sur une
installation sans batterie — celle du banc — l'écran annonçait donc une série
qu'aucune donnée ne pouvait remplir. Même défaut que partout ailleurs (montrer
ce qu'on n'a pas), pris par la légende au lieu du tracé.
Le titre, le sous-titre et l'entrée de légende suivent maintenant la présence
d'une batterie, et la note d'absence passe SOUS ce graphe-ci : c'est là que le
SOC aurait été tracé, donc c'est là qu'il manque.
`_sansBatterie` exige que les Things soient chargés : tant qu'ils ne le sont
pas, « pas de batterie » et « on ne sait pas encore » sont indiscernables, et
annoncer l'absence trop tôt serait une absence côté APP présentée comme une
absence côté BOX.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Maquette validée par Patrick (couleurs comprises). Deux graphes, et trois
défauts d'affichage trouvés en chemin — dont deux à l'écran seulement.
GRAPHE 1 — les trois « on ne voit pas » avaient trois causes.
production : publiée NÉGATIVE (−103 W). La magnitude est prise AU RENDU, pas
au transport : le champ reste brut (§7.1), et `.abs()` est licite sur une
production, dont le signe ne porte aucune information — contrairement au
réseau, où le signe dit le sens (d'où gridImportW/gridExportW là-bas).
autoconsommation : `production − export` clampé à 0, donc TOUJOURS zéro avec
une production négative. Même racine, corrigée par la même magnitude.
SOC : correctement absent — aucune batterie sur l'installation. Ce qui
manquait, c'était de le DIRE ; c'est maintenant une note sous le graphe.
⚠️ Et un deuxième empêchement, vu seulement à l'écran : le signe réparé, la
production restait invisible SOUS l'autoconsommation. Tant que rien n'est
exporté les deux sont égales au pixel près, et la verte était tracée par
dessus. L'autoconso passe en pointillé — des tirets sur la bande ambre disent
« tout est consommé sur place », leur décrochage dit l'export. Deux courbes
qui coïncident doivent pouvoir se VOIR coïncider.
⚠️ Ce correctif en créait un autre : le SOC était aussi vert pointillé. Sur
une installation AVEC batterie les deux auraient été indiscernables — collision
qu'aucun banc sans batterie ne pouvait montrer. Le SOC passe en indigo.
GRAPHE 2 — qui consomme, empilé.
`Energy.GetThingPowerLogs`, et la liste des appareils vient de GetLoadConfig :
chaque charge déclarée porte son `meterThingId`, son label et son domaine —
vérifié renseigné sur les quatre charges de .75. Rien n'est deviné d'un nom
d'appareil.
Un appareil demandé sans réponse sort dans `sansHistorique` et est NOMMÉ sous
le graphe, jamais tracé à zéro : la V2C ne déclare pas `smartmeter`, donc elle
n'a pas de passé — ce qui n'est pas « elle n'a rien tiré ».
Le RESTE du foyer est licite ici, contrairement au Sankey qui l'avait fait
interdire : chaque part est un compteur dédié et le total est le compteur du
foyer, donc la soustraction ne porte que du mesuré. Et un reste NÉGATIF n'est
pas raboté — c'est la preuve qu'un sous-compteur n'est pas dans le périmètre
du total, et l'écraser effacerait la seule chose qui le dise.
🔴 Le signe des sous-compteurs n'est PAS vérifié : les trois lisent 0 W à tous
les pas, donc aucun échantillon non nul n'existe. Le compteur PV publie en
négatif — rien n'autorise à supposer. La valeur est transportée brute et
`signeIndetermine` le dit à l'écran.
Couleurs par consommateur ajoutées au thème (pac ambre, ecs sarcelle, ev
indigo) : distinctes des couleurs de FLUX, qui disent d'où vient l'énergie, là
où celles-ci disent qui la prend.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Quatre demandes de Patrick. Sondé sur .75 avant de dessiner quoi que ce soit :
Energy.GetThingPowerLogs répond, six Things demandés, cinq répondent.
TRAÇABLE : Maison (dérivée Grid+PV), PAC-Meter, ECS-Meter, Simulated wallbox —
tous quatre en smartmeterconsumer, tous à 0 W aujourd'hui sauf Grid et PV.
PAS D'HISTORIQUE : V2C Trydan. Sa classe `trydan` ne déclare pas l'interface
`smartmeter`, donc elle est ABSENTE de GetThingPowerLogs — la borne simulée, qui
la déclare, répond. Sa puissance instantanée reste lisible, sa courbe n'existe
pas. Une ligne à zéro dirait « elle n'a rien tiré », ce qui est autre chose.
AUCUNE SOURCE : la batterie. Aucun Thing ne porte battery / energystorage /
batterymonitor. Donc ni SOC ni charge/décharge — et le « Batterie 0 % » du
tableau de bord est un zéro forgé de plus (EnergyData.batterySOC vaut 0 par
défaut et personne ne l'écrase). À corriger dans le même lot.
HORS NYMEA : la météo. Aucun Thing météo ; Open-Meteo serait un appel externe.
Et les trois « on ne voit pas » du premier graphe ont trois causes distinctes,
dont deux partagent une racine : `production` est publiée NÉGATIVE, donc la
courbe est sous l'axe ET `selfConsumptionPower` (production − export, clampé à
0) rend zéro à tous les pas. Le SOC, lui, est correctement absent.
Le signe se corrigera au RENDU, jamais au transport : la magnitude est vérifiée
(identité sur 97 échantillons sur 97), mais un .abs() dans `fetchPowerBalanceLogs`
effacerait la trace du défaut et masquerait un vrai zéro le jour d'un changement
de convention.
Maquette publiée : https://claude.ai/code/artifact/f90d71d0-b876-4477-9231-4089d521b8ea
Aucune ligne de code écrite — quatre décisions attendent Patrick.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Troisième face du même mode : la prémisse fausse n'est pas dans le code testé,
elle est dans ce qui l'entoure. Jeu d'essai trop homogène, deux horloges au même
décalage, contexte de montage trop lâche — même constante.
Et la leçon de découverte, à côté de « qu'est-ce que ce contrôle aurait attrapé
s'il avait échoué ? » : le chemin des flèches a été trouvé en cherchant comment
OBSERVER un correctif, pas en cherchant le défaut. Se demander « par quel chemin
puis-je voir ça ? » fait apparaître des chemins que « comment je casse ça ? » ne
fait pas apparaître.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
La barre d'action passe en pied d'écran fixe (`bottomNavigationBar`), parce
qu'un correctif juste mais hors du champ reste inaccessible : le geste se fait
en haut de la liste, la barre était un écran entier plus bas. C'est le défaut
d'hier sous une autre forme — cause de disposition au lieu de cause de logique.
`bottomNavigationBar` plutôt qu'une superposition : il RÉDUIT la hauteur du
corps au lieu de le recouvrir, donc rien ne se cache derrière la barre.
⚠️ ET LE DÉPLACEMENT A CASSÉ L'ÉCRAN. Le `Column` d'`ImpactSaveBar` était en
`MainAxisSize.max` — le défaut. Dans un `ListView` la hauteur disponible est
infinie et le Column se contente de ses enfants : le défaut ne pouvait pas se
voir. En pied d'écran la contrainte est lâche mais BORNÉE, le Column a pris
toute la hauteur, le corps a été écrasé à zéro. Écran vide sous une barre
géante, vu en release sur appareil — les 319 tests étaient verts.
Un widget qui ne se contraint pas lui-même hérite du contexte : le déplacer
change ses contraintes, donc sa taille, sans qu'une ligne de son code ait bougé.
Le test ajouté monte la barre dans un `bottomNavigationBar` et mesure sa
hauteur. Éprouvé par son contraire : sans `mainAxisSize: min` il rend 600 sur
600 et échoue. Aucun test précédent ne pouvait mordre — tous montaient la barre
dans une hauteur infinie, où `max` se comporte comme `min`.
Vérifié sur appareil, chemin des flèches : brouillon réel -> barre en bas avec
Annuler/Enregistrer, corps intact ; ordre rétabli -> « L'ordre est revenu à
celui de la box » avec le seul « Terminer » ; Terminer -> barre absente. Banc
inchangé, aucune écriture.
Et la note gardée sur `draftIsNoOp` : « rien à enregistrer » veut dire « rien
par rapport à ce que tu as vu ». Comparer à l'état vivant conclurait à la place
de l'utilisateur sur des faits qu'il n'a pas vus. Le référentiel de la
CONCLUSION et celui de l'ÉCRITURE sont deux choses, et il faut les deux.
Capture : docs/captures/2026-09-08_barre-en-pied-terminer.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le brouillon sans effet se produit aussi par les FLÈCHES d'une carte, pas
seulement par le glissement : descendre une charge puis la remonter. Les flèches
se tapent, donc l'état est atteignable à l'entrée synthétique — là où le
glisser-déposer ne l'est pas.
Vérifié sur appareil : après les deux taps, la barre affiche « L'ordre est
revenu à celui de la box — il n'y a rien à enregistrer. » avec le seul bouton
« Terminer », et « Modifications en attente » a disparu. Le tap sur Terminer
referme l'état.
Banc rendu intact : `reorderWithinGroup` et `discardDraft` ne font que poser et
retirer le brouillon — aucune écriture, ce que la barre annonçait elle-même
(« rien n'est parti vers la box »). Vérifié dans le code avant de conclure.
⚠️ Noté au passage, sans rien y changer : l'ordre des rangs sur .75 a bougé
entre ma sonde de ce matin (chauffe-eau au rang 2) et maintenant (Simulated
wallbox au rang 2). Ce n'est pas le fait de l'app. Je ne sais pas de qui, et je
ne le devine pas.
Et une propriété à connaître : `draftIsNoOp` compare le brouillon à la dernière
lecture de l'app, pas à l'état vivant de la box. C'est le bon référentiel pour
« j'ai décidé de ne rien changer » — l'utilisateur conclut sur ce qu'il a vu —
et l'écriture, elle, relit toujours frais.
Capture : docs/captures/2026-09-08_brouillon-sans-effet-terminer.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Relevé à uiautomator sur le banc (Redmi Note 9S, 3 domaines, 4 charges, blocs
dépliés) :
viewport de la liste 1 912 px
Véhicule électrique (2 charges) 1 355 px
Eau chaude sanitaire (1 charge) 1 171 px
Chauffage (1 charge) 1 029 px
Le doigt parcourt la hauteur de chaque bloc dépassé. D'où :
échange de deux blocs voisins au pire 1 355 px < 1 912 -> passe
remonter de deux rangs d'un coup 2 526 px > 1 912 -> impossible
Le défaut est donc DÉJÀ atteignable à quatre charges, contrairement à ce qu'on
m'a attribué : ce n'est pas cinq charges qui l'ouvrent, et ce n'est pas un seuil
en nombre de charges du tout. Il se compte en pixels, et une charge de plus dans
un domaine déjà servi ne coûte pas la même chose qu'un domaine de plus.
Ce qui le rend peu grave n'est pas son inaccessibilité mais son contournement :
deux échanges voisins successifs font le même déplacement, et replier les blocs
aussi.
Et la citation de favorites_screen.dart est corrigée. L'écran utilise bien
CustomScrollView + SliverReorderableList, mais ce n'est pas un précédent
transposable : là-bas la liste est plate et posée directement dans les slivers.
Ici elle est deux composants plus bas — il faudrait que ControllableLoadsSection
cesse de rendre une Column pour émettre des slivers, donc changer le contrat du
widget et convertir tout le corps de roles_devices_screen. Un montage à écrire,
pas à copier.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le geste sans repli de cet écran — déplacer une plage — puis le geste inverse
laissaient un brouillon qui rend exactement la configuration de la box. L'écran
le traitait comme n'importe quel brouillon, et n'offrait plus pour en sortir que
des portes mal nommées. Quatre messages, tous faux au même instant :
la barre « Modifications en attente »
la sortie d'écran « vos changements n'ont pas été envoyés »
adopter un rang « enregistrez ou annulez vos modifications »
retirer une charge idem
Il n'y avait plus rien à enregistrer, ni rien à perdre.
`draftIsNoOp` nomme l'état : un brouillon dont les charges utiles brutes, clés
triées, sont identiques à celles de la box — ce qui couvre l'ordre ET un patch
de champ. `hasSubstantiveChanges` garde désormais les trois portes ; la barre,
elle, continue de s'afficher, parce que c'est là qu'est la sortie.
Elle dit maintenant « L'ordre est revenu à celui de la box — il n'y a rien à
enregistrer » et n'offre qu'un geste, « Terminer ». Pas « Enregistrer » :
réécrire tout l'ensemble pour n'y rien changer reconstruirait les charges et
réarmerait les verrous, au prix de zéro.
⚠️ Le remède n'est PAS d'effacer le brouillon dès qu'il devient sans effet : la
barre disparaîtrait sous le doigt à l'instant où l'utilisateur repose la plage,
et « j'ai décidé » redeviendrait « il ne s'est rien passé ». Un état se conclut,
il ne s'évapore pas. Un test le fige.
Et la note sur le glissement est REPRISE. J'y affirmais un défaut ; le test au
doigt montre que le réordonnancement fonctionne, liste dépliée comprise. Le
mécanisme du shrinkWrap reste écrit — il est probablement juste — mais comme une
LIMITE CONNUE non reproduite, avec le protocole en trois gestes (A témoin,
B discriminant, C cause), le contournement (replier les blocs) et le remède
nommé. On ne réécrit pas un écran qui marche sur la foi d'une lecture de code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le moteur soupçonnait un ReorderableListView en conflit avec un défilement
parent. C'est exact, et le mécanisme se lit dans le code sans avoir à toucher
l'écran :
roles_devices_screen.dart:113 body: ListView(...) <- le parent défile
controllable_loads_section:104 ReorderableListView.builder(
shrinkWrap: true,
physics: NeverScrollableScrollPhysics())
En `shrinkWrap`, le viewport de la liste vaut la hauteur de son contenu : son
`maxScrollExtent` est NUL. Or l'auto-défilement du glisser-déposer agit sur le
Scrollable de la liste réordonnable, jamais sur un parent. Il n'a donc nulle
part où aller, et le ListView extérieur n'est pas prévenu.
Conséquence : on ne réordonne que ce qui tient à l'écran en même temps. Un bloc
de domaine déplié fait plus d'un écran, donc le geste qui compte — remonter un
domaine par-dessus un autre — est justement celui qui ne peut pas aboutir.
Replier les blocs le rend possible : contournement immédiat, et contrôle qui
prouve le diagnostic.
Remède structurel : un seul Scrollable, CustomScrollView + SliverReorderableList
— le montage déjà en place dans favorites_screen.dart. PAS fait tant que le
geste n'est pas éprouvé au doigt : l'entrée synthétique ne reproduit pas un
appui-glissé, donc aucun test de ce dépôt ne peut montrer ce défaut ni prouver
sa correction.
Et une piste abandonnée plutôt que remontée : j'ai soupçonné les écritures de
l'app d'effacer `rankOrigin`. Faux — l'aller-retour est verbatim sur les charges
utiles brutes (LIRE -> PATCHER -> RÉÉCRIRE), rien n'est reconstruit depuis le
modèle typé.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Deux défauts vus sur appareil après installation, tous deux d'affichage.
1. « mesuré depuis 16:37 » à 06:15, pour un `measuredSince` de la VEILLE. Le
lecteur comprend 16:37 aujourd'hui — une heure qui n'est pas encore arrivée —
et « 2,5 kWh achetés » juste à côté devient incompréhensible avec elle.
Même défaut que l'heure UTC, d'un cran plus haut : là on perdait le fuseau,
ici le jour. `heureLisible` rend « HH:MM » dans la journée du lecteur,
« hier HH:MM » la veille, « le JJ/MM à HH:MM » au-delà — et la comparaison
porte sur le jour civil, pas sur 24 h : à 00:05, un instant de 23:50 est hier
même s'il a quinze minutes.
2. « Autoconsommation · sans production » rendu à la moitié de la taille
d'« Autonomie » à côté. Cause : un FittedBox reçoit des contraintes de
largeur infinies, donc son enfant tient sur une ligne aussi large qu'il veut
et c'est tout le bloc qui rétrécit — `maxLines: 2` n'y sert à rien.
Rallonger le texte d'un suffixe rapetissait donc le NOM de la grandeur, qui
est ce qu'on lit en premier. Le motif passe sur sa propre ligne.
Les tests qui figeaient « HH:MM » dérivent maintenant de `heureLisible`, la
fonction même de l'écran — un attendu recomposé à la main aurait gelé la forme
d'avant, exactement comme les « 03:42 » en dur de vendredi.
Captures : docs/captures/2026-09-08_taux-sans-production.png
docs/captures/2026-09-08_instant-hier.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
+etm58 posé (au-delà de +etm57 annoncé). Trois vérifications.
1. ANCRAGE DES INSTANTS : livré et observable. Les trois champs ISO de la trame
portent le marqueur Z, `command.since` compris —
`{divergent, expectedW, observedW, since: "2026-09-07T14:37:00Z"}`.
2. MIN+PV : livré. La voiture a chargé toute la journée sans jamais quitter
ChargingModeEcoWithMinCurrent, et deux comptages sans source commune
concordent à 4 % :
surplus MAX du jour 536 W — 0 quart d'heure sur 71 au-dessus de 4140
fenêtre 08:45 -> 15:15 16,2 kWh dont 14,2 au-dessus de la base (539 W)
sessionEnergy de la V2C 1,06 -> 14,72 kWh, soit +13,7 kWh
Le surplus n'ayant jamais dépassé 536 W, tout a été acheté au réseau : c'est
le plancher demandé.
3. `boundBy` : ABSENT, et cette absence ne prouve rien — le seul ECO_FLOOR_GRID
de la trame est celui du chauffe-eau, dont le plancher vient d'une obligation
quotidienne et non d'un minimum matériel ; et la borne est sortie de loads[]
(pluggedIn: false). Un `grep -c boundBy` valant 0 aurait fait conclure
« non livré » à l'instant où la mesure prouve le contraire. À revoir voiture
branchée.
Et une affirmation de CLAUDE.md devenue FAUSSE, corrigée : le plafond de
soutirage du §10 existe désormais —
"draw": { "authorisedW": 6000.4, "committedW": 103.2, "remainingW": 5897.2,
"binding": "connection", "bindingPhase": "A", "perPhaseBound": true }
`binding` nomme ce qui contraint et `bindingPhase` la phase qui mord : le
plafond se dit donc avec sa source, la condition qu'on avait posée pour
l'afficher. Aucun écran ne le lit encore, et rien n'est câblé — l'écran du §10
n'est pas validé.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le moteur donne le bon signal : `boundBy`, dans `ECO_FLOOR_GRID.params`,
n'apparaît que sur un moteur qui sert effectivement le minimum (+etm57). C'est
donc lui qui répond à « le plancher est-il servi ici ? », et pas le mode ni une
version annoncée.
Absent ne veut PAS dire « pas de plancher » : il veut dire « moteur antérieur à
+etm57 ». Même règle que levels[] vide ou counts absent — l'absence date la box,
elle ne décrit pas le cycle.
Mesure « avant » prise aujourd'hui, sans quoi un boundBy toujours absent après
livraison serait indiscernable d'un champ jamais ajouté :
powersync-energy-plugin-nymea 1.15.2+etm56 posé
boundBy : 0 occurrence dans toute la trame
ECO_FLOOR_GRID.params : atMaximum, gridW, regime, remainingS, remainingWh,
targetWh — les six clés connues, pas une de plus
Le bouton Min+PV reste tel quel (Patrick). Aucun code conditionnel écrit : le
champ n'est pas observable, et « sonder avant de câbler » vaut aussi pour un
marqueur de présence.
+etm57 portera aussi le correctif d'ancrage des instants — à sa pose, resonder
les champs ISO pour vérifier le marqueur Z partout.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Sémantique voulue (Patrick, 2026-09-07) : Min+PV charge toujours au minimum de
la borne, acheté au réseau s'il le faut, et ajoute le surplus par-dessus. 400 W
d'injection sur un plancher de 4 140 W donnent 4 540 W.
Mesuré sur .75, voiture branchée et borne joignable : la borne ne reçoit qu'un
niveau `comfort`, aucun niveau `eco`, décision `SURPLUS_INSUFFICIENT`,
`chargingEnabled: false`. ChargingModeEcoWithMinCurrent se comporte exactement
comme ChargingModeEco.
Le mécanisme existe déjà — `ECO_FLOOR_GRID`, ce que le chauffe-eau fait dans la
même trame : plancher servi, acheté au réseau, compté dans draw.committedW,
surplus distribué au-dessus par comfort. Il n'est pas câblé sur la borne.
Et le blocage noté depuis longtemps (« minCurrent n'existe nulle part ») n'en
est pas un : la valeur est sur la box, dans la classe du Thing —
maxChargingCurrent.minValue = 6 A, phaseCount = 3, soit les 4 140 W attendus.
Aucun champ de contrat à ajouter, et rien à saisir côté app : une limite
matérielle se lit sur le matériel.
Pourquoi ça n'a pas été vu : sur ce banc le surplus n'atteint jamais le
plancher — 0 quart d'heure sur 97 le 2026-09-06, meilleur 2 214 W — donc les
deux modes rendent le même rien et ne se distinguent par aucune observation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
APK reconstruit et posé. La box publie `measuredSince: 2026-09-07T04:33:28Z` ;
l'écran affiche 06:33, l'attendu dérivé par `.toLocal()`. L'APK précédent, sur
la même box et le même téléphone tous deux en Europe/Paris, affichait 04:33 —
la preuve que l'écart ne devait rien au fuseau de la box.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le contrat porte désormais la règle : tout horodatage publié est en UTC avec son
marqueur, ou en epoch. Trois champs, deux formats, rien ne l'exigeait.
`instantDeLaBox` (lib/models/box_instant.dart) devient l'unique lecteur pour ce
que la box publie — epoch ou ISO, marqué ou nu — et requalifie la forme nue en
UTC avant de rendre l'heure du lecteur. Politique valable pour la BOX seule :
`Installation.lastSeen` est écrite en local sans marqueur et relue pareil, donc
la lire en UTC la décalerait. Deux héritages opposés sous une même forme, d'où
l'absence délibérée d'un « parser une date » unique.
Le `.toLocal()` posé hier dans telemetry_text est retiré : le modèle est seul
propriétaire de la conversion. Le rejouer serait sans effet mais laisserait
croire qu'elle peut manquer ailleurs.
CORRECTION. J'avais écrit que le défaut avait survécu « parce que box et
téléphone partageaient l'heure ». C'est faux, et la fausseté est utile : l'écart
est entre UTC et l'APPAREIL, donc visible sur tout téléphone hors UTC+0 quel que
soit le fuseau de la box. Mesuré ce matin avec les deux en Europe/Paris — la box
publie 04:33:28Z, l'APK d'hier affiche « 04:33 », il fallait lire 06:33. La
bascule en Europe/London n'a pas donné la visibilité, elle a donné le MOTIF de
regarder. La version fausse fait conclure « les fuseaux coïncident, donc c'est
réglé » et laisse le défaut en place.
`GetVariableLoadState` n'existe pas sur .75 (absente d'Introspect) et l'app ne
lit aucun `since` : rien à corriger de ce côté. Le champ existe en revanche dans
GetLoadTelemetry — `loads[].command {divergent, expectedW, observedW, since}` —
et il porte bien le Z, vérifié à la sonde. Aucun écran ne le consomme encore.
Contrôle négatif de la ligne d'horloge : même binaire qu'hier, box repassée en
Europe/Paris, la ligne a disparu sous le champ d'échéance.
docs/captures/2026-09-07_fuseau-box-paris-ligne-absente.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Signalé sur appareil de nuit : tuile Autoconsommation « — · pas mesurable »,
sur une installation dont les quatre compteurs marchent.
D'où vient le nombre : la tuile lit `DailyBalance`, pas `GetEnergyRatios`.
`selfConsumptionRate` y rend `null` dès que `productionKwh <= 0` — production
nulle depuis minuit, donc 0/0.
Le « — » est JUSTE et ne bouge pas. Un « 0 % » affirmerait qu'aucune production
n'a été autoconsommée : une phrase sur une production qui n'existe pas, soit un
zéro forgé de plus. Ce qui était faux, c'est le motif écrit dessous — il
accusait la mesure là où il n'y avait simplement rien à mesurer.
Les deux causes d'un taux absent sont désormais séparées :
- pas de bilan (échantillons, cumuls, compteur en recul) → « pas mesurable » ;
- dénominateur nul → « sans production » / « sans consommation ».
C'est la distinction habituelle du dépôt prise par l'autre bout : d'ordinaire on
empêche une absence de se dire zéro ; ici on l'empêche d'accuser la mesure.
Mesuré sur .75 au même instant : production 0 W, `selfConsumptionRate` absent de
GetEnergyRatios sur trois relevés, `autonomyRate: 0` présent — la box fait la
même distinction, sur la même arithmétique.
Le premier jet du test asserait `find.text('0 %'), findsNothing` : il mordait
sur le 0 % de l'Autonomie, qui est une mesure. Corrigé en le voyant échouer, et
la raison est dans le test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Trouvé sur appareil pendant la bascule volontaire de .75 en Europe/London, en
capturant la ligne d'horloge de l'échéance : la box publie
`measuredSince: "2026-09-06T14:38:00Z"` et l'écran affichait « mesuré depuis
14:38 » — ni l'heure de la box (15:38 BST), ni celle du téléphone (16:38 CEST).
L'heure de personne.
`DateTime.tryParse` d'une chaîne en `Z` rend un DateTime `isUtc: true` ; lire
`.hour` sans `toLocal()` donne l'heure UTC. Le défaut est identiquement
invisible tant que box et appareil partagent l'offset : il a fallu DEUX fuseaux
pour qu'il se voie, et c'est la couture ouverte pour la capture qui l'a montré.
Deux natures d'heure, désormais séparées dans CLAUDE.md :
- un RÉGLAGE (`dailyDeadline`) est lu par la box → on nomme son horloge ;
- un INSTANT (`measuredSince`) est absolu → il se rend chez le lecteur, sans
mention.
Les deux tests qui gardaient « 03:42 » en dur gelaient l'heure UTC et validaient
le défaut : leur attendu se dérive maintenant de `.toLocal()`. Le contrôle
négatif ne mord que hors UTC, et le test le dit au lieu de laisser lire un vert
comme une preuve.
Capture de la ligne d'horloge : docs/captures/2026-09-06_fuseau-box-london.png
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Établi le 2026-09-06 : deux tentatives de réordonnancement par `input swipe` puis
`input motionevent`, aucun mouvement — et la conclusion « le glisser-déposer est
cassé » aurait été fausse. Le même geste au doigt, le matin même, avait produit
une écriture qui a tenu.
`input swipe` interpole une trajectoire linéaire ; un appui-glissé réel comporte
une phase de maintien que Flutter attend avant d'armer le glissement.
Ce qui rend le piège coûteux est que l'échec RESSEMBLE à un défaut : la poignée
capte le geste — la liste ne défile pas, ce qu'elle ferait s'il passait à travers
— et rien ne bouge. Un réordonnancement se vérifie donc au doigt, ou pas du tout ;
ce qu'`adb` peut vérifier, c'est le résultat relu dans `GetLoadConfig`.
Même famille que le `finally` qui défait l'action au lieu de restaurer l'état :
l'outil répond, et sa réponse ne parle pas de ce qu'on croit mesurer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Troisième tentative sur le même symptôme, et la bonne : le détail de consommation
croise la TÉLÉMÉTRIE (la mesure) et la CONFIGURATION (le domaine), et ni l'un ni
l'autre n'était attaché ailleurs que sur l'écran des rôles. Sur le tableau de
bord, `telemetry` était null ET `entries` vide.
Les deux correctifs précédents ne traitaient que la configuration — la moitié que
le premier diagnostic avait désignée. C'est la recherche auto-confirmante en
version « je n'ai regardé qu'un provider » : j'ai vérifié la partie que je venais
d'écrire, jamais l'autre, et l'écran a redit trois fois la même chose.
La donnée était pourtant sans ambiguïté à chaque étape : `chauffe-eau` → `ecs`,
`pac-terrain` → `heating`, et `{powerW: 0, source: "meter"}` sur les deux. Rien
ne manquait côté box ; tout manquait côté app, à l'endroit où on va chercher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Le correctif précédent — charger au montage — n'a rien changé, vérifié à l'écran :
PAC et « Eau chaude » affichaient toujours « non publié » alors que la box publie
`{powerW: 0, source: "meter"}` pour les deux.
La raison est le moment : l'écran se construit avant que la connexion soit
établie, l'appel échoue en silence, et RIEN ne réessaie. Le tick existait, mais à
cinq minutes.
Deux accroches donc, et la première suffit dans le cas normal : un chargement dès
que la box devient joignable (une seule fois, gardé par un drapeau), et un
rattrapage sur le tick si la configuration est encore vide.
C'est la troisième fois aujourd'hui que le même motif se présente — une absence
côté APP présentée comme une absence côté BOX — et la deuxième fois qu'un
correctif à ce motif échoue parce qu'il était posé au mauvais instant. Le
symptôme se corrige où la donnée manque ; la cause vit dans le moment où on va la
chercher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
La recherche auto-confirmante : après avoir corrigé le signe du solaire, la
vérification cherchait `pvPower.abs` — donc la ligne qu'on venait d'écrire, ce
qui a caché la seconde occurrence, non corrigée. On cherche la GRANDEUR, jamais
le correctif.
Le contrôle vrai par construction : `deliveredWh + remainingWh == targetWh` ne
peut pas échouer sous `unmeasurable`, et l'afficher comme « identité OK » ferait
lire un feu vert sur le régime qu'elle ne contrôle pas.
La parade est commune : qu'est-ce que ce contrôle aurait attrapé s'il avait
échoué ? Si la réponse est « rien », il décore — et il coûte plus qu'aucun
contrôle, parce qu'il occupe la place de celui qui aurait mordu.
Avec le corollaire rencontré deux fois le même jour : une absence côté APP
présentée comme une absence côté BOX. Avant d'écrire qu'une chose n'est pas
publiée, vérifier qu'on est allé la chercher.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Deux défauts trouvés en vérifiant la correction précédente à l'écran.
1. « -1.3 kW · Solaire » dans « Production — détail ». La correction du
2026-09-05 n'avait redressé QUE le nœud de la vue d'ensemble : la même
grandeur est rendue à deux endroits, et le grep qui avait servi cherchait
`pvPower.abs` — donc il montrait la ligne déjà corrigée et cachait l'autre.
Un test couvre désormais le détail, en éprouvant l'ABSENCE du signe.
2. PAC et « Eau chaude » affichaient « non publié » alors que la box publie
`{powerW: 0, source: "meter"}` pour les deux. `LoadConfigProvider.load()`
n'était appelé que par l'écran des rôles : sur le tableau de bord la
configuration est vide, aucun `domain` ne se rattache, et la carte reste sans
valeur. Une absence CÔTÉ APP présentée comme une absence côté box — le défaut
qu'on venait de corriger, reproduit un cran plus loin, et trompeur de la même
façon : on en conclurait que la box ne publie rien.
Vérifié à l'écran entre les deux : « non publié » est lisible dans les cercles,
« Autres » a disparu, et le détail production ne montre plus d'onduleurs
fabriqués mais « Détail par source non publié par cette box ».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Les silences qu'on traque se taisent ; celui-ci se DÉCLARE, et c'est ce qui le
protège. « PAC 1,5 kW » valait 38 % de la consommation du foyer, marqué « estimé »
et cerclé de pointillés : le nombre était faux, la mention était vraie, et la
mention a rendu le nombre acceptable assez longtemps pour survivre à l'arrivée de
vrais compteurs publiant zéro.
Le remède est le problème : marquer une invention la rend tolérable, donc pérenne.
Une valeur qu'on ne mesure pas ne se marque pas, elle ne s'affiche pas.
Avec les deux corollaires du lot : « non publié » plutôt qu'une part, et pas de
RESTE sans mesure exhaustive — un reste suppose de connaître la somme des parts.
Et la couche cachée, apportée par le moteur : `ECS-Meter` et `PAC-Meter` sont des
Things generic-energy appairés à la main, dont la puissance est SAISIE. Le total
dont l'écran tirait ses parts agrégeait donc déjà des valeurs tapées — deux
inventions superposées, dont la seconde est invisible depuis l'app, qui lit
`source: "meter"`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Signalé sur banc, et les deux vues détaillées inventaient.
CONSOMMATION — PAC = 38 % de la maison, eau chaude = 18 %, autres = 22 %. Des
ratios posés à la maquette, marqués « estimé »… et affichés tels quels le
2026-09-06 alors que les compteurs ECS et PAC publiaient `{powerW: 0, source:
meter}`. Un compteur à zéro dit « rien ne chauffe » ; l'écran répondait 720 W.
La mention « estimé » était le problème autant que le remède : sous un nombre
inventé, elle le rend acceptable. Les branches viennent désormais de
`GetLoadTelemetry.measurement`, par domaine, et une charge sans mesure publiée
affiche « non publié ». « Autres » disparaît — c'était un reste calculé sur des
parts inventées, donc inventé lui aussi : sans mesure exhaustive, il n'y a pas de
reste connu.
PRODUCTION — « Onduleur 1 » et « Onduleur 2 » portaient chacun la MOITIÉ de la
production, avec l'état `ok`, donc sans même la marque « estimé » des branches de
consommation. Deux appareils qui n'existent nulle part : le banc n'a qu'un seul
compteur de production. La vue dit maintenant « détail par source non publié par
cette box ».
Et un débordement introduit en chemin, attrapé en test : « non publié » ne tient
pas dans un nœud dimensionné pour « 1.2 kW » — 7 px de trop, donc du texte coupé
sur l'appareil. `FittedBox(scaleDown)`, comme pour l'étiquette des tuiles.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
`double d(String k) => (m[k] as num?)?.toDouble() ?? 0.0` : un champ manquant
devenait 0,0 au décodage, deux bornes à zéro donnaient une différence à zéro, et
l'écran affichait « 0,0 kWh · Vers réseau » comme une mesure. C'est le zéro forgé
que nous traquons depuis une semaine, cette fois de NOTRE côté.
Le cas est réel et n'attend pas sa cause : un compteur racine parfaitement en
place, la puissance instantanée qui arrive, et les cumuls qui n'arrivent pas.
`PowerBalanceEntry.totalsPresent` porte la distinction, et `fetchDailyBalance`
refuse de présenter comme mesure un bilan bâti là-dessus — au même titre qu'un
compteur corrompu. « Rien échangé aujourd'hui » et « la box ne publie pas ses
cumuls » sont deux états, et le second n'a pas le droit de porter le premier.
Le repli à 0 reste, pour ne pas propager des nullables dans tout l'écran Énergie,
mais il est désormais ACCOMPAGNÉ du fait qu'il est un repli.
Et `abs()` sur la production devient un choix DOCUMENTÉ plutôt qu'un correctif
tacite : la production n'est pas signée, c'est le compteur qui l'est, donc la
valeur absolue masquerait un compteur câblé à l'envers dont le signe serait la
seule trace. Le correctif appartient à la source. On la garde en connaissance de
cause — un signe faux se voit tous les jours, un câblage inversé ne se voit
jamais — et on ne revient pas en arrière sans savoir ce que la box publiera.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Signalé sur banc après changement de matériel : Fronius SunSpec retiré, Eastron
SDM72 posé en rootMeter et SDM120 en compteur de production. L'écran affichait le
SDM72 dans les DEUX rôles, avec « auto · lecture seule » — donc sans moyen de le
corriger.
La box était juste (`GetRootMeter` rend bien le SDM72) et les interfaces
distinguaient les deux sans ambiguïté :
Grid / sdm72 : energymeter, smartmeter, connectable
PV / sdm120Producer : smartmeterproducer, smartmeter, connectable
C'est notre liste qui ne discriminait pas : le rôle solaire acceptait
`energymeter`, `meter` et `smartmeter` — portées par TOUT compteur, réseau
compris — et ignorait `smartmeterproducer`, la seule qui dise « ce compteur
mesure une production ».
Deux corrections, la seconde tenant même si une future classe déclare des
interfaces trop larges :
- le rôle solaire exige désormais une interface de production ;
- le Thing acté comme compteur RACINE n'est plus candidat à aucun autre rôle.
Reste ouvert, et c'est le vrai fond du signalement : une détection automatique
ne devrait pas être un cul-de-sac. Les lignes de compteur n'ont aujourd'hui
AUCUN geste — pas de sélecteur, quel que soit l'état. Le badge « lecture seule »
est honnête, mais une inférence fausse doit pouvoir se corriger.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Europe/Berlin et Europe/Paris ne divergeront jamais : la ligne d'échéance restera
muette, et à raison — elle qualifie une horloge, et deux fuseaux au même décalage
donnent la même heure. Avertir parce que les NOMS diffèrent alors que les HEURES
coïncident serait le bruit que la condition existe pour éviter.
Mais une plage tarifaire suit le FOURNISSEUR, pas la box : « même décalage, autre
autorité » y reste une divergence réelle, et le jour où l'un des deux change de
règle d'heure d'été, la plage bouge sans que la box ait bougé. Le lot tarifaire
aura donc besoin d'une comparaison de provenance et d'un fuseau de référence
publié avec la configuration tarifaire.
Noté dans la doc du getter, là où quelqu'un ira le réutiliser.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
« 12:00 heure de la box (Europe/London) — pas celle de cet appareil », et non
« Fuseau : Europe/Paris » : sous un champ, un intitulé de réglage laisse croire
qu'on choisit le fuseau DE CETTE échéance. Il n'y en a qu'un, il est système, et
il déplace d'un coup toutes les heures murales de l'installation — échéances,
frontière de la journée de reporting, et demain les plages tarifaires
(LM-1005-b-iii).
Affichage CONDITIONNEL : seulement quand les deux horloges divergent. C'est la
règle déjà appliquée deux fois cette semaine — ligne des ratios instantanés,
avertissement « partiel » du bilan — et sa raison tient en une phrase : un texte
permanent cesse d'être lu le jour exact où il devient vrai.
La divergence se DÉDUIT de ce que la box publie, sans base de fuseaux :
`periodStartedAt` est minuit de l'installation en epoch, donc rendu dans le
fuseau de l'appareil il tombe sur 00:00 si et seulement si les deux partagent le
même décalage. Exact pour l'instant présent, y compris les jours à 23 ou 25
heures — et c'est justement pourquoi nous avions demandé cette frontière plutôt
qu'un nom IANA.
Quatre silences testés : fuseaux identiques, échéance vide, box qui ne publie pas
la date, et l'intitulé « Fuseau : » qui ne doit jamais apparaître.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
L'obligation était déjà posée, et déjà à 2 000 Wh avant 12:00. État relevé à
08:55 pour que les traces de lundi soient lisibles.
Et une confirmation gratuite : `measuredSince` = 10:00 UTC = 12:00 Europe/Paris,
soit l'échéance d'hier — la base a bien été reprise à la bascule de période. Avec
`deliveredWh` = 31,4 kWh ≈ 21 h × 1 500 W, la fenêtre « hier 12:00 → maintenant »
se recoupe au watt près. Troisième invariant vérifiable de l'extérieur, après
Σ counts == targetW et gridW == remainingWh / remainingS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Deuxième passage sur appareil, écran des charges. Trois défauts, dont deux de
notre fait et un que les fixtures ne pouvaient pas produire.
1. LA FRACTION ÉTAIT ÉCRITE DEUX FOIS — `ECO_FLOOR_MET` porte déjà livré et
cible dans son motif, et la ligne d'avancement les réécrivait dessous :
« Plancher atteint — 29,9 kWh sur 3,0 kWh livrés » puis « 29,9 kWh sur 3,0
kWh livrés · mesuré depuis 10:00 ». C'est le défaut de la ligne des ratios de
la veille, refait à l'identique : déclencher sur ce qu'on SAIT plutôt que sur
ce qui se VOIT. La ligne ne garde plus que ce que le motif ne dit pas.
2. « X SUR Y » N'EST PAS UNE FRACTION une fois le plancher dépassé — le compteur
continue de courir après que l'obligation est tenue, et le numérateur finit à
dix fois le dénominateur. Aucune fixture ne le montrait : toutes avaient un
livré inférieur à la cible. Reformulé « 3,0 kWh dus, 30,2 kWh livrés ».
3. LE PARENT NE DOMINAIT PAS — à taille et graisse égales, l'allocation et les
deux niveaux se lisaient comme trois lignes sœurs, et les pastilles colorées
tiraient l'œil davantage que la commande qu'elles expliquent : le contresens
exact que la forme doit empêcher (LM-1003). L'allocation passe en 13,5 gras,
les pastilles perdent leur fond, et un filet vertical rattache chaque niveau
à la commande.
Vérifié à l'écran après correction, et le repli l'était déjà : V2C et Simulated
wallbox tiennent sur une seule ligne, sans étiquette orpheline ni vide résiduel.
Et le signe du solaire est CONFIRMÉ, ce qui n'avait pas pu l'être hier faute de
production : la box publie -4 376 W, l'écran affiche « 4.4 kW ».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Passage sur le Redmi contre `.75`. Aucun des trois n'était visible en test.
1. LA PRODUCTION S'AFFICHAIT NÉGATIVE — « -8.9 kW · Solaire » sous 9 kW de
soleil. `currentPowerProduction` est publié négatif par nymea et le service
garde les signes bruts par politique ; la carte imprimait la valeur telle
quelle. Ce qui rend le défaut net plutôt qu'opinable : la même carte
normalisait DÉJÀ le réseau et la batterie par `.abs()` — la branche solaire
était la seule oubliée, donc un oubli et non une convention.
2. LE LIBELLÉ SE COUPAIT AU MILIEU DU MOT — « Autoconsommat / ion », alors que
le commentaire du code disait vouloir l'éviter. La cause n'est pas la
longueur mais l'ÉCHELLE du texte : police système au-dessus de 100 %, et
`maxLines: 2` ne protège de rien puisque Flutter coupe un mot long sans
espace, sans même afficher l'ellipse. `FittedBox(scaleDown)` garde le mot
entier et ne fait rien quand la place suffit.
3. MA LIGNE DES RATIOS RÉPÉTAIT LES TUILES — « Instantané depuis 09:23 —
autoconsommation 52 %, autonomie 54 % » sous des tuiles affichant 52 % et
54 %. Les deux chemins étaient corrects et les valeurs coïncidaient vraiment
(bilan 51,8/54,1 sur 00:00→16:45, box 51,9/53,7 depuis 09:23). Rien de faux,
et illisible quand même : je déclenchais sur l'ORIGINE, alors qu'un lecteur
compare des NOMBRES. La ligne sort désormais quand l'origine diffère ET que
l'écart dépasse 2 points ; le relevé du jour est devenu un test.
Vérifié à l'écran après correction : le libellé tient sur une ligne, la ligne des
ratios se tait. Le signe, lui, N'A PAS pu être revu — la production du banc était
retombée à 0 W à 17:03, et `abs(0) == 0`. Une correction qu'on ne peut pas voir
demande une garde qui se voit : `flux_signe_test.dart` la pose.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Les tuiles disent la JOURNÉE, par différence de compteurs sur la fenêtre publiée.
La nouvelle ligne dit ce que la BOX publie, qui part de la baseline — et elle ne
s'affiche QUE lorsque cette origine diffère du début de journée.
Le cas est arrivé de lui-même : `nymead` redémarré à 09:23, sonde à 09:26, et la
box publiait 100 % d'autoconsommation. Vrai sur trois minutes ; absurde intitulé
« aujourd'hui ». La ligne le rend lisible — « Instantané depuis 09:23 » — au lieu
de le laisser passer pour la journée.
Vérifié avec le MODÈLE de l'app et non à l'œil sur le JSON : `ratios_check.dart`
importe `EnergyRatiosSnapshot` (idiome de `measurement_check.dart`) et rend
`baselineRepriseEnJournee: true`, ratios couvrant 3 minutes. Le banc est passé en
Europe/Paris entre-temps, et `periodStartedAt` suit sans que le code bouge —
c'est l'intérêt d'une frontière publiée.
Quand les deux coïncident, rien n'est ajouté : une phrase permanente cesse d'être
lue, comme un avertissement permanent.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Sondé avant de câbler (`+etm56`) : `periodStartedAt` = 1788562800 = 00:00 Londres
= 01:00 Paris, `measuredSince` = 07:04 Londres, `timeZone` = Europe/London. Sept
heures d'écart entre les deux bornes.
- `EnergyRatiosSnapshot` — les deux instants et le fuseau. `baselineRepriseEnJournee`
dit quand les ratios de la box ne parlent que depuis un redémarrage : c'est le
silence que `measuredSince` existe pour fermer, et quand les deux coïncident —
le cas normal — il n'y a rien à dire de plus ;
- `fetchEnergyRatios()`, et `fetchDailyBalance()` qui prend désormais la frontière
publiée. Repli sur minuit local pour une box antérieure, écrit comme tel.
Et un effet de bord attrapé avant qu'il ne parte : `startsLate` comparait à minuit
du TÉLÉPHONE. Avec la frontière de la box, il aurait crié « partiel » tous les
jours sur un bilan complet — un avertissement permanent cesse d'être lu. Il se
compare maintenant à `periodStart`, porté par le bilan, et un test fige le piège.
Les taux journaliers de `DailyBalance` sont donc corrigés du même geste : ils se
calculent déjà par différence de compteurs sur la fenêtre, c'était la fenêtre qui
était fausse.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Lot configuration. La section « Obligation quotidienne » porte l'énergie due, son
échéance, et l'avertissement qui rend la déclaration honnête.
Pourquoi à la saisie : au résultat l'heure est passée, l'achat a eu lieu. Et sous
`unmeasurable` l'obligation ne peut JAMAIS être close — ni annoncée tenue (R6
interdit `ECO_FLOOR_MET`), ni chiffrée dans son manque (`missingWh` absent).
`ECO_FLOOR_MISSED` sort tous les jours par construction. Un mécanisme dont le
succès est inobservable et l'échec quotidien ne doit pas, en plus, dépenser en
silence.
Et c'est une consigne : les trois causes portent trois gestes — rattacher un
compteur (le plus fréquent, réparable), en mettre un qui totalise l'énergie, ou
constater que c'est le matériel. Une cause inconnue se dit sans inventer de
geste.
Le coût est CHIFFRÉ, pas estimé : le taux est constant depuis +etm55, donc le
total acheté vaut exactement la cible.
Trois silences délibérés, chacun testé : aucune obligation déclarée (personne ne
paiera), `progressMeasurable` absent (box antérieure à +etm49 — on ne conclut pas
d'une absence), et le nom du fuseau tant que l'app ne l'a pas lu. L'échéance dit
en revanche qu'elle est à l'heure de l'INSTALLATION, ce qui est vrai sans le
fuseau.
Revérifié à la sonde avant d'écrire, plutôt que cru : `progressMeasurable: true`
et `regime: measured` sortent bien sur la même charge — la contradiction du
2026-09-03 est fermée.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
Premier lot d'écran, sur des champs tous posés (+etm55) et tous vus à la sonde.
L'allocation reste le parent ; les niveaux en sont la décomposition. Une charge
reçoit UNE commande par cycle quelles que soient les passes (LM-1003) : deux
lignes décrivent une seule décision.
- `EcoProgress` — regime, targetWh, deliveredWh (absent sous `unmeasurable`,
jamais 0), purchasedWh (publié dans TOUS les régimes : c'est la commande du
moteur, donc un fait connu sans mesure), measuredSince, measuredGaps ;
- `LoadLevel` gagne `decision` et `progress` : chaque passe porte son motif.
Lire la racine seule afficherait « rien fait » sur une charge qui achète —
relevé du 2026-09-01 05:47, `SURPLUS_INSUFFICIENT` en racine et 767 W achetés
au niveau éco ;
- `ecoDecisionText` / `ecoProgressText` : les phrases des trois motifs éco et de
leurs quatre causes. Aucun nom de paramètre n'est deviné — `cause`,
`missingWh`, les quatre valeurs et `measuredGaps` sont vérifiés dans le binaire
posé. Seule la FORME de `measuredGaps` reste non observée, donc on n'en lit que
la présence ;
- garde R6 à l'écran : `ECO_FLOOR_MET` sous `unmeasurable` est DÉNONCÉ comme une
incohérence de la box, pas rendu. Servie oui, tenue jamais.
Deux interdits écrits dans le code, pas seulement dans la maquette : sous
`unmeasurable` on n'annonce pas que l'achat va s'intensifier (le taux est
constant depuis +etm55), et `atMaximum: false` n'y veut pas dire « on n'est pas
au plafond » mais « il n'y a aucun étalement, donc rien qui puisse cesser ». Un
booléen à false se lit spontanément comme rassurant.
Les charges utiles des tests viennent de `.75` — le cas éco-servi/confort-en-
attente du 2026-09-01, le cas mesuré du 2026-09-04 — pas d'une lecture de
contrat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
+etm55 vérifié (posé le 04/09 18:21:08). Le taux constant est en ligne : la
maquette porte le bon chiffrage — ×4,75 sur une fenêtre quotidienne, facteur
ln(T·P/E) + 1 — et les deux interdits du régime `unmeasurable` : ni annoncer que
l'achat va s'intensifier, ni lire `atMaximum: false` comme « tout va bien », qui
signifie qu'il n'y a aucun étalement, donc rien qui puisse cesser.
La troisième nature d'heure murale touche du code livré : `fetchDailyBalance()`
et la baseline des ratios prennent minuit du TÉLÉPHONE, alors qu'une journée de
reporting suit l'installation. Sur `.75` en Europe/London vue d'un téléphone
français, entre minuit et 1 h l'app compte une journée que la box compte encore
dans la précédente.
L'app ne peut pas le corriger seule : `System.GetTime` publie un nom IANA, et un
décalage ne s'en déduit pas sans base de fuseaux — qu'il faudrait embarquer pour
recalculer une frontière que la box connaît, et qui resterait fausse les jours de
changement d'heure. Demandé au moteur : publier le DÉBUT de la journée de
reporting en cours, en epoch, à côté du fuseau. La divergence est écrite aux deux
endroits du code en attendant.
Noté sans conclure : le banc n'a aucune charge `unmeasurable`, donc la loi est
déployée mais pas exerçable de bout en bout.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
