docs(§10): bascule de régime — prémisse vérifiée, champs non déployés, perte trouvée

Ma prémisse (« la base est capturée à la bascule, targetWh n'est pas rebasée »)
était juste mais posée sans vérification : confirmée par lecture de
`energyarbitrator.cpp` et `ecotarget.cpp`.

Le moteur a déjà tranché, et mieux que ma question : `measuredSince` plutôt que
rebaser `targetWh`, parce que rebaser ferait perdre l'obligation réelle et
l'écran ne pourrait plus dire ce qui reste dû. `purchasedWh` est là aussi, dans
tous les régimes.

MAIS aucun des deux n'est sur la box : `strings -el` et `strings` sur le binaire
déployé trouvent `ECO_FLOOR_GRID`, `ECO_FLOOR_MISSED`, `remainingWh` et
`atMaximum` — et zéro occurrence de `purchasedWh` et `measuredSince`. Ils sont
au HEAD, pas dans +etm43. Rien à câbler dessus aujourd'hui.

Et une perte que la lecture montre : sur `measured → unmeasurable → measured`
dans la même période, la base et la date sont retirées puis reprises à la valeur
courante, donc `deliveredWh` repart de zéro et les tronçons mesurés antérieurs
sont perdus. L'écran sous-estime, et la passe éco rachète ce qui a déjà été
livré. Le lien Modbus battant de la V2C produit exactement ce motif.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
This commit is contained in:
Patrick Schurig 2026-09-02 07:55:32 +02:00
parent 5597c530fc
commit 5695ab8928

View File

@ -2,6 +2,62 @@
---
## 2026-09-02 — la bascule de régime : prémisse confirmée, et une perte que le code montre
### Ma prémisse était juste, mais je l'avais posée sans la vérifier
Lue dans `energyarbitrator.cpp` : la base se prend **à l'instant où la charge devient mesurable**
(`if (!m_ecoBaseWh.contains(id)) insert(sessionWh)`), et `ecotarget.cpp` calcule
`remainingWh = targetWh − deliveredWh` — donc **`targetWh` n'est pas rebasée**. `deliveredWh` ne
compte bien que depuis la bascule. J'avais énoncé ça comme un fait ; ça n'en était un qu'après
lecture.
### Et votre réponse tranche mieux que ma question
J'offrais deux sorties comme équivalentes — rebaser `targetWh`, ou publier depuis quand on
mesure. `measuredSince` est déjà écrit, et le commentaire donne l'argument qui départage, que je
n'avais pas : **rebaser ferait perdre l'obligation réelle, et l'écran ne pourrait plus dire ce qui
reste dû.** Retenu tel quel. `purchasedWh` est là aussi, dans tous les régimes, avec exactement la
distinction proposée — l'acheté est la commande du moteur, le livré une observation qu'il ne peut
pas faire.
### Mais aucun des deux n'est SUR LA BOX
`strings` sur le binaire déployé (`libnymea_energypluginnymea.so`, `+etm43`), dans les deux
encodages — merci pour `-el`, le mélange est bien réel :
| symbole | UTF-16 | ASCII |
|---|---|---|
| `ECO_FLOOR_GRID` · `ECO_FLOOR_MISSED` · `remainingWh` | 0 | **1** |
| `atMaximum` | **1** | 1 |
| **`purchasedWh`** | **0** | **0** |
| **`measuredSince`** | **0** | **0** |
Ils sont au HEAD (`770cef1`), pas dans `+etm43`. **Rien n'est donc à câbler dessus aujourd'hui** —
et sans ce contrôle j'aurais bâti l'avertissement de saisie sur deux champs muets, pour la
troisième fois de la semaine.
### Une perte que la lecture montre, et que la bascule rend probable
Sur `measured → unmeasurable → measured` **dans la même période** : au passage en `unmeasurable`,
`m_ecoBaseWh` et `m_ecoMesureDepuis` sont retirés ; au retour, la base est reprise à la valeur
**courante** de `sessionWh`. Donc `deliveredWh` **repart de zéro**, et l'énergie livrée pendant les
tronçons mesurés antérieurs est perdue de l'avancement.
Deux conséquences, et la seconde coûte de l'argent : l'écran **sous-estime** l'avancement, et la
passe éco **rachète ce qui a déjà été livré**. Ce n'est pas théorique — c'est exactement le motif
de la V2C dont le lien Modbus bat : `connected` bascule, le régime suit.
Piste, si elle vous va : accumuler par **période** plutôt que par tronçon — ajouter
`sessionWh − base` à un cumul de période au moment de quitter `measured`, au lieu de le jeter. Le
`measuredSince` garde alors son sens (« mesuré depuis », avec des trous), et `deliveredWh` cesse de
mentir par défaut.
*(Lu dans le code, non mesuré : la bascule n'est pas provocable sur le banc tant que `sessionWh`
n'est pas rempli hors borne.)*
---
## 2026-09-01 (soir) — trois champs pour que l'écran puisse tenir la nuance
Vos deux règles sont prises. Il leur manque trois choses pour être **affichables**, et chacune