diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md index cb4430e..f6a0c0c 100644 --- a/docs/BRIEF_plugin_depuis_maquettes.md +++ b/docs/BRIEF_plugin_depuis_maquettes.md @@ -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 diff --git a/docs/mockups/deux_passes_eco_confort_mockup.html b/docs/mockups/deux_passes_eco_confort_mockup.html index a2169b5..27fb8bc 100644 --- a/docs/mockups/deux_passes_eco_confort_mockup.html +++ b/docs/mockups/deux_passes_eco_confort_mockup.html @@ -325,7 +325,7 @@
⠿3 -
V2C TrydanBorne de recharge · VE
+
Borne sans compteur de sessionBorne de recharge · VE
@@ -338,7 +338,8 @@ ÉCO
Plancher servi — 2 600 W achetés au réseau - Avancement non mesurable : cette borne ne publie pas d'énergie de session. + Avancement non mesurable : cette borne ne publie pas d'énergie de session + — c'est le cas de `wallboxNoMeter` et d'une des deux classes `wallbox` du banc. NON MESURABLE
L'obligation est servie ; elle ne pourra jamais être annoncée tenue. @@ -464,7 +465,7 @@
3 -
V2C TrydanAvancement non mesurable · au réseau
+
Borne sans compteur de sessionAvancement non mesurable · au réseau
2 600 Wreste 0
@@ -499,7 +500,7 @@
2
PAC bancDemandeur · en attente
0 Wreste 0
3 -
V2C TrydanDemandeur · en attente
0 Wreste 0
+
Borne sans compteur de sessionDemandeur · en attente
0 Wreste 0
4
Plancher chauffantDemandeur · en attente
0 Wreste 0
5 @@ -572,7 +573,11 @@
ÉCOAvancement non mesurableregime
« Servi · avancement non mesurable » — barre hachurée, aucun chiffre livré.
Un régime, pas un motif : les trois régimes coexistent dans le même cycle sur des - charges différentes (LM-1009 C2). Zéro serait un mensonge ; l'absence est la vérité.
+ charges différentes (LM-1009 C2). Zéro serait un mensonge ; l'absence est la vérité. +
Corrigé le 2026-08-30 : l'exemple ne nomme plus la V2C + Trydan — elle publie `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.
Niveau CONFORT · toujours présent
diff --git a/lib/models/ev_charger_live.dart b/lib/models/ev_charger_live.dart index 765b21a..5d7ecdf 100644 --- a/lib/models/ev_charger_live.dart +++ b/lib/models/ev_charger_live.dart @@ -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;