docs: relevé frais sur charge réelle — sessionEnergy corrigé, chargingState confirmé

Lien Modbus rétabli, Skoda en charge, valeurs en mouvement.

- `sessionEnergy` : notre doc était EN RETARD, pas contredite. La V2C la publie
  depuis le plugin +etm13 et elle bouge (15,8015 → 15,8405 kWh). L'écart avec
  `chargeEnergy` vaut 7,2044 kWh aux deux échantillons pris à deux heures
  d'écart — constant au dix-millième : c'est l'accumulateur du plugin, et il
  prouve l'accumulation que le code seul ne montrait pas. LM-1009 C1 reste vraie
  pour les bornes sans cet état ; la V2C n'en fait plus partie. La maquette ne la
  nomme donc plus dans l'exemple « non mesurable ».
- `chargingState` reste `Idle` sur un lien VIVANT, pendant que la borne tire
  4 372 W : ce n'est pas de la péremption, personne ne maintient le champ.

Et un constat qui n'est pas dû au WiFi : la box a journalisé « Restoring manual
values of false 6 A » trois secondes après la coupure ; la borne est restée à
`power: true`, 7 A, et le lien est revenu sans que rien ne réapplique. En mode
manuel personne ne commande, donc l'écart est permanent — 4,4 kW tirés,
`draw.committedW` à 0. Question posée au moteur.

Aucun avancement n'est affiché pour autant : c'est une décision (D1), pas une
mesure qui manquerait.

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-08-30 15:15:49 +02:00
parent 2c9cca042e
commit 7eefb93c6c
3 changed files with 83 additions and 13 deletions

View File

@ -2,6 +2,56 @@
---
## 2026-08-30 (soir, lien rétabli) — relevé frais : deux confirmations et une correction
### `chargingState` figé : confirmé sur lien VIVANT, ce n'est pas de la péremption
Le doute était permis tant que le lien Modbus était coupé. Il ne l'est plus : à 14:12, la
borne publie des valeurs **en mouvement** (`currentPower` 4 372 → 4 397 W, courants qui
bougent sur les trois phases) et `chargingState` vaut toujours **`ChargingStateIdle`**. Le
champ n'est pas en retard : **personne ne le maintient**, parce que l'arbitre a sorti la borne
du waterfall en mode manuel. La demande du point 1 tient donc telle quelle — absent plutôt que
figé.
### La box et le matériel divergent en mode manuel, et rien ne les réconcilie
`Restoring manual values of false 6 A 3 phases` a été journalisé à 12:15:34, **trois secondes
après** la perte du lien. La borne, elle, est restée sur ce que l'arbitre lui avait commandé au
cycle d'avant : `power: true`, **7 A**, et elle charge toujours à 4 372 W deux heures plus tard.
Le lien est revenu depuis, et **rien n'a réappliqué** les valeurs manuelles : en mode manuel
personne ne commande, donc l'écart entre ce que la box croit avoir posé et ce que la borne fait
est **permanent**.
Ce n'est pas une conséquence du bug WiFi : c'est ce que « le mode manuel ne commande pas »
implique dès qu'une commande se perd. **Question** : une entrée en mode manuel devrait-elle
réappliquer ses valeurs à la reconnexion du Thing ? Sans cela, une coupure d'une seconde suffit
à laisser une borne à un courant que plus personne n'a choisi, et le HEMS n'en sait rien —
`draw.committedW` reste à 0 pendant que 4,4 kW sont tirés.
### `sessionEnergy` : notre doc était en retard, corrigée sur relevé frais
Vous aviez raison — LM-1009 §C1 n'est pas contredite, elle ne s'applique simplement plus à
cette borne. Mesuré sur charge réelle, deux échantillons à deux heures d'écart :
| | 12:15 | 14:12 |
|---|---|---|
| `sessionEnergy` | 7,5147 kWh | 15,8015 → 15,8405 kWh, **en mouvement** |
| `chargeEnergy` | 0,3103 kWh | 8,5972 → 8,6361 kWh |
| écart | **7,2044** | **7,2044** |
**L'écart est constant au dix-millième sur deux heures** : c'est votre accumulateur, et il
porte les incréments d'avant la dernière remise à zéro. La remise à zéro n'a pas été surprise
en direct — mais l'accumulation, elle, est prouvée par cet écart, et elle ne se déduisait pas
du code.
Corrigé chez nous : la maquette ne nomme plus la V2C dans l'exemple « avancement non
mesurable » (le régime reste vrai pour les bornes sans cet état, `wallboxNoMeter` et l'une des
deux classes `wallbox`), et le modèle porte le relevé. **Aucun avancement n'est affiché pour
autant** : c'est une décision (D1 — en énergie livrée, et il n'y a pas encore d'écran qui la
porte), pas une mesure qui manquerait.
---
## 2026-08-30 (soir) — trois constats sur la borne, et deux d'entre eux FORGENT un fait
**Contexte, mesuré** : V2C Trydan, Skoda branchée et en charge (4 356 W, 3 phases), passage

View File

@ -325,7 +325,7 @@
<div class="load">
<div class="r1">
<span class="grip">⠿</span><span class="rank">3</span>
<div class="nm"><b>V2C Trydan</b><span>Borne de recharge · VE</span></div>
<div class="nm"><b>Borne sans compteur de session</b><span>Borne de recharge · VE</span></div>
<span class="sw"></span>
</div>
<div class="cmd">
@ -338,7 +338,8 @@
<span class="tag eco">ÉCO</span>
<div class="bd">
<b>Plancher servi — 2 600 W achetés au réseau</b>
<span>Avancement <em>non mesurable</em> : cette borne ne publie pas d'énergie de session.
<span>Avancement <em>non mesurable</em> : cette borne ne publie pas d'énergie de session
— c'est le cas de `wallboxNoMeter` et d'une des deux classes `wallbox` du banc.
<span class="pill nm">NON MESURABLE</span></span>
<div class="bar dash"></div>
<span>L'obligation est servie ; elle ne pourra jamais être annoncée <em>tenue</em>.</span>
@ -464,7 +465,7 @@
<div class="srv g">
<span class="rk">3</span>
<div class="bd"><b>V2C Trydan</b><span>Avancement non mesurable · au réseau</span></div>
<div class="bd"><b>Borne sans compteur de session</b><span>Avancement non mesurable · au réseau</span></div>
<div class="w">2 600 W<u>reste 0</u></div>
</div>
@ -499,7 +500,7 @@
<div class="srv nil"><span class="rk">2</span>
<div class="bd"><b>PAC banc</b><span>Demandeur · en attente</span></div><div class="w">0 W<u>reste 0</u></div></div>
<div class="srv nil"><span class="rk">3</span>
<div class="bd"><b>V2C Trydan</b><span>Demandeur · en attente</span></div><div class="w">0 W<u>reste 0</u></div></div>
<div class="bd"><b>Borne sans compteur de session</b><span>Demandeur · en attente</span></div><div class="w">0 W<u>reste 0</u></div></div>
<div class="srv nil"><span class="rk">4</span>
<div class="bd"><b>Plancher chauffant</b><span>Demandeur · en attente</span></div><div class="w">0 W<u>reste 0</u></div></div>
<div class="srv nil"><span class="rk">5</span>
@ -572,7 +573,11 @@
<div class="cat"><div class="h"><span class="tag eco">ÉCO</span><b>Avancement non mesurable</b><code>regime</code></div>
<div class="txt">« Servi · avancement non mesurable » — barre <em>hachurée</em>, aucun chiffre livré.</div>
<div class="why">Un régime, pas un motif : les trois régimes coexistent dans le même cycle sur des
charges différentes (LM-1009 C2). <b>Zéro serait un mensonge</b> ; l'absence est la vérité.</div></div>
charges différentes (LM-1009 C2). <b>Zéro serait un mensonge</b> ; l'absence est la vérité.
<br><b style="color:var(--green)">Corrigé le 2026-08-30</b> : l'exemple ne nomme plus la V2C
Trydan — elle <b>publie</b> `sessionEnergy` depuis le plugin `+etm13`, vérifié sur charge réelle
(15,80 → 15,84 kWh en mouvement). Le régime « non mesurable » reste vrai pour les bornes qui n'ont
pas cet état.</div></div>
<div class="sect">Niveau CONFORT <small>· toujours présent</small></div>

View File

@ -19,14 +19,29 @@
/// mais de `NymeaEnergy.GetChargingInfos` — les deux bornes y étaient en
/// `ChargingModeNormal`, `ChargingStateIdle`.
///
/// **`sessionEnergy` existe** sur les deux (4,229 kWh sur la V2C), et le renommage
/// `currentL1/L2/L3` **est déployé** — plus de `powerL1/L2/L3`. Ces deux champs ne sont pas
/// portés ici pour autant. Le plugin V2C `1.15.2+etm13` **construit** ce `sessionEnergy` —
/// il accumule les incréments de `chargeEnergy`, détecte les remises à zéro, et ne repart
/// qu'à l'ouverture d'une session — mais la trace qui le montre à l'œuvre (`chargeEnergy`
/// à zéro, `sessionEnergy` qui continue) **n'a pas été prise** : la campagne V2C est
/// arrêtée, la Trydan non-Pro étant inexploitable en WiFi. Elle se prendra sur une Trydan
/// Pro. **Aucun avancement n'est affiché avant elle** : LM-1009 §C1, cf. `LoadMechanism`.
/// **`sessionEnergy` existe** sur les deux, et le renommage `currentL1/L2/L3` **est
/// déployé** — plus de `powerL1/L2/L3`. Ces deux champs ne sont pas portés ici pour autant.
///
/// Le plugin V2C `1.15.2+etm13` **construit** ce `sessionEnergy` : il accumule les
/// incréments de `chargeEnergy`, détecte les remises à zéro, et ne repart qu'à l'ouverture
/// d'une session. **Relevé sur charge réelle le 2026-08-30** (Skoda branchée, lien rétabli),
/// deux échantillons à deux heures d'écart :
///
/// | | 12:15 | 14:12 |
/// |---|---|---|
/// | `sessionEnergy` | 7,5147 kWh | 15,8015 → 15,8405 kWh, en mouvement |
/// | `chargeEnergy` | 0,3103 kWh | 8,5972 → 8,6361 kWh |
/// | écart | **7,2044** | **7,2044** |
///
/// L'écart est **constant au dix-millième sur deux heures** : c'est l'accumulateur du
/// plugin, et il porte les incréments d'avant la dernière remise à zéro. La remise à zéro
/// elle-même n'a pas été surprise en direct, mais l'accumulation, elle, est prouvée par cet
/// écart — elle ne se déduisait pas du code.
///
/// **Aucun avancement n'est affiché pour autant** : c'est une décision (LM-1009 §D1 —
/// l'avancement se dit en énergie livrée, et il n'y a pas encore d'écran pour le porter),
/// plus une mesure manquante. LM-1009 §C1 reste vraie pour les bornes qui ne publient pas
/// `sessionEnergy` ; **la V2C n'en fait plus partie**.
library;
import 'energy_data.dart' show ChargingMode;