From bf8d890c8e682c9ff2f1dee59bda053c18e01c26 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sun, 6 Sep 2026 08:20:33 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20conditions=20de=20la=20fen=C3=AAtre=20d?= =?UTF-8?q?'observation=20du=20week-end?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Posé dimanche 2026-09-06 à 08:19 (Europe/Paris) : chauffe-eau, minEnergyWhPerDay 3000 → 2000, dailyDeadline inchangé à 12:00. Discipline habituelle — capture sur disque avant écriture, 76 clés comparées, 1 divergence attendue, 0 imprévue — mais PAS de restauration : la configuration reste en place tout le week-end. Symboles de débogage laissés en place jusqu'à lundi, donc aucune couture supplémentaire pendant la fenêtre. Les deux dernières restent 06:53:30Z (fuseau) et 09:22:57 (installation des symboles), toutes deux du 2026-09-05. CE QUE L'ÉCRAN MONTRE À LA POSE, et pourquoi ce n'est pas un défaut. À 08:19 le palier est ECO_FLOOR_MET avec deliveredWh = 30 475 Wh pour une cible de 2 000. Arithmétiquement correct et sans intérêt : le compteur de l'ECS publie 1 500 W en permanence, donc deliveredWh monte de 1,5 kWh/h que la charge soit commandée ou non. La période a basculé hier à 12:00 ; vingt heures plus tard elle a « livré » 30 kWh. LA FENÊTRE UTILE EST À 12:00 et dure ~80 minutes. À la bascule, la base est reprise (LM-1013-c) : deliveredWh repart de 0 face à 2 000 Wh sur 24 h, soit une cadence de 83 W financée par le réseau si le surplus manque, que le compteur fixe comble en 2000/1500 = 80 min. Deux fenêtres sur le week-end — dimanche 12:00 et lundi 12:00. ET C'EST LA CINQUIÈME FORME D'HOMOGÉNÉITÉ QUI FIXE CE PLAFOND. Sur un banc dont le compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible modeste et un chemin d'achat longuement exercé : ce qui décide n'est pas la cible, c'est la constance du compteur. Tenir l'achat en éveil tout le week-end demanderait de dépasser 36 kWh/jour, c'est-à-dire acheter au plafond — précisément ce qu'on voulait éviter. La contrainte est du banc, pas du moteur. --- docs/DESIGN_COMMANDE_PERDUE.md | 43 ++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/DESIGN_COMMANDE_PERDUE.md b/docs/DESIGN_COMMANDE_PERDUE.md index 74be9f0..1615ccb 100644 --- a/docs/DESIGN_COMMANDE_PERDUE.md +++ b/docs/DESIGN_COMMANDE_PERDUE.md @@ -223,3 +223,46 @@ l'objet `command` ne le distingue d'un zéro réel. - **Le compte des écartés est publié aussi.** Un tri dont on ne dit pas ce qu'il a jeté n'est pas un tri, c'est une sélection. +--- + +## 7. CONDITIONS DE LA FENÊTRE D'OBSERVATION — week-end du 2026-09-06 + +Noté pour que les traces de lundi soient lisibles. **Rien n'a été restauré** : la configuration +ci-dessous reste en place tout le week-end. + +| | | +|---|---| +| **Posé le** | dimanche 2026-09-06 à **08:19** (Europe/Paris ; box et atelier à la même heure depuis la correction du 2026-09-05) | +| **Charge** | `chauffe-eau` | +| **Changement** | `minEnergyWhPerDay` **3000 → 2000**, `dailyDeadline` inchangé à `"12:00"` | +| **Vérification** | 76 clés comparées entre capture et relecture : 1 divergence attendue, 0 imprévue | +| **Capture d'avant** | conservée hors dépôt, `scratchpad/loadconfig_AVANT_weekend.json` | +| **Moteur** | `1.15.2+etm56` · plugin générique `1.14.2+etm3` | +| **Symboles de débogage** | `libnymea1-dbgsym` / `libnymea-core-dbgsym` arm64 **laissés en place** jusqu'à lundi — donc **aucune couture supplémentaire** pendant la fenêtre | + +### Ce que l'écran montre à la pose, et pourquoi ce n'est pas un défaut + +À 08:19, le palier éco est `ECO_FLOOR_MET` avec `deliveredWh` = **30 475 Wh** pour une cible de +2 000, `measuredSince` = `2026-09-05T10:00:00Z`. L'obligation est tenue vingt fois. + +**C'est arithmétiquement correct et sans intérêt** : le compteur de l'ECS publie 1 500 W en +permanence (cf. §6), donc `deliveredWh` monte de 1,5 kWh par heure que la charge soit commandée ou +non. La période courante a basculé hier à 12:00 ; vingt heures plus tard, elle a « livré » 30 kWh. + +### La fenêtre utile est à 12:00, et elle dure ~80 minutes + +À chaque bascule de période, la base d'avancement est reprise (`LM-1013-c`). `deliveredWh` repart +de 0 face à une cible de 2 000 Wh sur 24 h — soit une cadence de **83 W**, financée par le réseau +si le surplus manque. Le compteur fixe la comble en **2000 / 1500 = 80 minutes**, après quoi +l'écran repasse à `ECO_FLOOR_MET` pour les 22,7 h restantes. + +**Donc deux fenêtres exploitables sur le week-end** : dimanche 12:00 et lundi 12:00, ~80 min +chacune, où l'on voit un vrai plancher éco, son financement et sa cadence. Le reste du temps, +l'écran montre l'état « tenue » — qui est aussi une forme à valider. + +> **Et c'est la cinquième forme d'homogénéité qui fixe ce plafond** (`INVENTAIRE_MOCK.md` §7). +> Sur un banc dont le compteur ne suit pas la commande, on ne peut pas avoir à la fois une cible +> **modeste** et un chemin d'achat **longuement exercé** : ce qui décide n'est pas la cible, c'est +> la constance du compteur. Choisir une cible qui tienne l'achat en éveil tout le week-end +> reviendrait à dépasser 36 kWh/jour — c'est-à-dire acheter au plafond, précisément ce qu'on +> voulait éviter. La contrainte est du banc, pas du moteur.