From 78f7fa23a99a92b2200ace7d8e15c1f289211ce0 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Thu, 3 Sep 2026 06:54:45 +0200 Subject: [PATCH] =?UTF-8?q?docs(=C2=A710):=20+etm49=20=E2=80=94=20`purchas?= =?UTF-8?q?edWh`=20marche,=20et=20deux=20champs=20se=20contredisent?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sonde sur le banc (obligation déclarée puis retirée, restauration « 0 écart »). Vérifié : les cinq symboles dans le binaire déployé, tous en UTF-16 ; `progressMeasurable` bien dans `GetLoadConfig` en `r:` ; `progressUnmeasurableCause` absent quand il n'y a pas de cause ; et `purchasedWh` qui accumule SOUS `unmeasurable` — 0 → 43,12 Wh, ~648 W, cohérent avec `gridW`, donc recoupable par l'écran. Mais `progressMeasurable: true` et `regime: "unmeasurable"` sortent sur la MÊME charge au même cycle, et le code dit pourquoi : `progressMesurable()` teste ce que le MATÉRIEL permet (compteur désigné qui compte l'énergie), tandis que `sessionMeasurable` — qui décide du régime — n'est posé que dans `evadapter.cpp`. Sur toute charge non-VE, l'un dit oui et l'autre non. Conséquence : l'avertissement de saisie, qui se déclenche sur `progressMeasurable == false`, restera muet exactement sur les charges achetées à l'aveugle. Nous ne le câblons pas sur ce champ, et l'app ne peut pas rattraper — à la saisie la charge n'est pas dans `loads[]`, donc son régime n'existe pas. Statut sans reproche : l'escalade est toujours là en +etm49 (`remainingWh` figé, `gridW` 645 → 654). Le taux constant est retenu, pas déployé. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw --- docs/BRIEF_plugin_depuis_maquettes.md | 60 +++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md index 6747445..08b22d3 100644 --- a/docs/BRIEF_plugin_depuis_maquettes.md +++ b/docs/BRIEF_plugin_depuis_maquettes.md @@ -2,6 +2,66 @@ --- +## 2026-09-03 — `+etm49` à la sonde : `purchasedWh` marche, et deux champs se contredisent + +Obligation déclarée puis retirée sur le banc (`chauffe-eau`, 4 000 Wh avant 12:00, sept cycles, +capture disque → restauration depuis le fichier → *« 0 écart, clé par clé »*). + +### Ce qui est vérifié + +Les cinq symboles sont dans le binaire déployé, **tous en UTF-16** — ASCII à zéro partout, le +mélange que vous signaliez. `progressMeasurable` est bien dans **`GetLoadConfig`**, en `r:`, sur +les quatre charges, et `progressUnmeasurableCause` **absent** quand il n'y a pas de cause : la +bonne forme. + +**`purchasedWh` fonctionne, et sous `unmeasurable`** — c'est le point qui comptait : + +``` +0 → 10,78 → 21,41 → 32,25 → 43,12 Wh (≈ 10,8 Wh/min, soit ~648 W : cohérent avec gridW) +``` + +Il se recoupe donc avec `gridW × temps`, ce qui donne à l'écran un contrôle interne gratuit. +`measuredSince` et `measuredGaps` sont absents — correct, rien n'est mesuré ici. + +### Mais `progressMeasurable: true` et `regime: "unmeasurable"` sur la MÊME charge + +Le chauffe-eau porte `progressMeasurable: true` en configuration **et** `progress.regime: +"unmeasurable"` en télémétrie, au même cycle. Ce n'est pas une course : les deux champs répondent +à deux questions différentes, et le code le dit. + +| | ce que le champ teste | où | +|---|---|---| +| `progressMeasurable` | **le matériel le permet** — borne avec `sessionEnergy`, ou compteur désigné qui compte l'énergie | `nymeaenergyjsonhandler.cpp::progressMesurable()` | +| `regime` | **le moteur le fait** — `sessionMeasurable`, posé **uniquement** dans `evadapter.cpp` | `surpluscontext.h` (défaut `false`) | + +Sur toute charge non-VE, le premier dit *oui* et le second dit *non*. C'est le quatrième maillon +mort, vu de l'autre bout. + +**Et la conséquence défait la règle pour laquelle le champ a été créé** : l'avertissement de saisie +se déclenche sur `progressMeasurable == false`, donc il **restera muet exactement sur les charges +dont l'obligation sera achetée à l'aveugle**. L'installateur ne sera pas prévenu dans le seul cas +où il fallait le prévenir. + +**Nous ne câblons donc pas l'avertissement sur ce champ**, et l'app ne peut pas rattraper : à la +saisie, la charge n'est pas encore dans `loads[]`, donc son `regime` n'existe pas — c'est +précisément pourquoi le signal devait vivre en configuration. + +Deux sorties, et la première est celle qu'on préfère : + +1. **Remplir `sessionWh` depuis le compteur désigné** pour les charges non-VE — les deux champs + s'accordent alors d'eux-mêmes, et le régime devient `measured` là où le câblage le permet ; +2. en attendant, faire dire à `progressMeasurable` **ce que le moteur fait**, pas ce que le + matériel permet, avec une cause qui nomme le manque. Mieux vaut un installateur prévenu par + une limite du moteur qu'un installateur non prévenu par une promesse de câblage. + +### Statut, sans reproche + +L'escalade est toujours là en `+etm49` — `remainingWh` figé à 4 000, `gridW` 645 → 654 sur sept +cycles. Le taux constant a été retenu mais n'est pas déployé ; c'est cohérent avec ce que vous +annonciez (la perte du tronçon d'abord). Noté pour ne pas le remesurer comme une découverte. + +--- + ## 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