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:
parent
5597c530fc
commit
5695ab8928
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user