docs(banc): prédiction ECS-306 et commutations — publiée AVANT la mesure
Horodatée 2026-08-09, commitée avant tout profil lancé. Une reconstruction analytique publiée après la mesure ne vaut rien ; publiée avant, elle est falsifiable et le commit en fait foi. Prédiction principale, binaire : sur un point à budget_charge = 3200 W (surplus −300 W, palier verrouillé à 3500), +etm2 retient le palier 3000 et annonce un résidu de +200 W — la charge sonde de rang 3 s'allume ; +etm3 force 3500 par lockMinPowerW et annonce −300 W — elle reste éteinte. Si la sonde s'allume sous +etm3, le raisonnement est faux. Prédiction secondaire, tout aussi engageante : la PAC de rang 2 ne changera PAS d'état entre les deux versions (200 W comme −300 W sont sous P3 = 1500 W). Sans la charge sonde, ce relevé aurait conclu « aucun effet observable » — à tort. Raison sous-jacente établie avant mesure : les Things sont des relais GPIO, leur ThingClass n'expose pas currentPower, donc RelayRouter::telemetry() retombe sur le nominal commandé et currentPowerW == palier commandé en permanence. La divergence entre les deux versions ne peut donc apparaître qu'en import net. Volet 2 : comptage attendu R500=7, R1000=3, R2000=1 sur un aller ; la transition 1500→2000 bascule les trois relais à elle seule (3 des 11). Piège prédit — le cliquet : sans plateaux à surplus NÉGATIF, le palier ne redescend jamais et le relevé serait vide. Protocole et ordre d'exécution inclus, dont la vérification obligatoire que +etm2 relit bien la configuration écrite par +etm3 avant de lancer le profil. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Patrick Schurig
parent
1996d7da7c
commit
793b76b6f7
122
docs/RELEVE_ECS306.md
Normal file
122
docs/RELEVE_ECS306.md
Normal file
@ -0,0 +1,122 @@
|
||||
# Relevé banc — ECS-306 et commutations par relais
|
||||
|
||||
Dépôt : `etm-powersync-energy-plugin-etm` · Banc : `192.168.1.75` (`nymea-dev-rpi`)
|
||||
Installation émulée : `specs/spec_ecs.md` §4.0 (INST-100), cf. INST-104.
|
||||
|
||||
> **Ce document est publié AVANT la mesure.** La section « Prédiction » est
|
||||
> horodatée du **2026-08-09** et commitée avant tout profil lancé. Une
|
||||
> reconstruction analytique publiée après coup ne vaut rien ; publiée avant, elle
|
||||
> est falsifiable. Les résultats viendront s'ajouter en dessous, sans jamais
|
||||
> réécrire la prédiction — si elle est fausse, elle reste, et c'est le
|
||||
> renseignement utile.
|
||||
|
||||
---
|
||||
|
||||
## 1. Dispositif
|
||||
|
||||
Trois charges, un seul budget de surplus, cascade par rang ascendant.
|
||||
|
||||
| Charge | Rang | Adaptateur | Paliers / états | Verrous |
|
||||
|---|---|---|---|---|
|
||||
| `chauffe-eau` | 1 | `relay-router` — Relay1/2/3 (500/1000/2000 W) | 0…3500 W, 8 valeurs | `minOnS`/`minOffS` = 60 s (300 s pour le volet 1, cf. §3) |
|
||||
| PAC SG-Ready | 2 | `sg-ready` — Relay4/5, codé en dur | P3 = 1500 W, P4 = 3000 W | `minStateHoldS` = 300 s |
|
||||
| `sonde-residu` | 3 | `relay-router` — Relay6, **1 relais, 100 W** | 0 / 100 W | `minOnS`/`minOffS` = 10 s |
|
||||
|
||||
**La sonde est un instrument de mesure, pas une charge.** Aucune résistance n'est
|
||||
câblée sur Relay6 : le relais claque, rien ne consomme. Ce qu'elle rend
|
||||
observable est une **décision d'allocation** — le résidu que le waterfall laisse
|
||||
à la charge suivante — et non une puissance. Son palier à 100 W est choisi très
|
||||
au-dessous de l'écart attendu (500 W) pour que le basculement soit franc.
|
||||
|
||||
Pilotage du surplus : `banc/cmd/manual {"grandeur":"pv","mode":true,"value":<W>}`
|
||||
sur le broker `192.168.1.131`, `modele.py:178`. `banc/cmd/pause` fige l'horloge du
|
||||
modèle et rend le profil reproductible.
|
||||
|
||||
---
|
||||
|
||||
## 2. Prédiction — 2026-08-09, avant mesure
|
||||
|
||||
### Pourquoi la télémétrie ne discrimine pas
|
||||
|
||||
Les Things sont des relais **GPIO** : leur ThingClass n'expose pas `currentPower`.
|
||||
`RelayRouter::telemetry()` retombe donc sur le **nominal commandé**
|
||||
(`relayrouter.cpp:113-114`), et `currentPowerW == palier commandé` en permanence.
|
||||
|
||||
Conséquence : `budget_charge = budget + palier_courant`. Tant que le budget reste
|
||||
positif, les deux versions choisissent le même palier et laissent le même résidu.
|
||||
**La divergence n'apparaît qu'en import net**, budget signé négatif.
|
||||
|
||||
### Volet 1 — point de fonctionnement discriminant
|
||||
|
||||
Surplus 3600 W jusqu'à ce que le chauffe-eau atteigne 3500 W et arme `minOn`,
|
||||
puis chute à **−300 W** maintenue.
|
||||
|
||||
```
|
||||
budget_charge = −300 + 3500 = 3200
|
||||
```
|
||||
|
||||
| | Palier retenu | Résidu annoncé | PAC (rang 2) | Sonde (rang 3) |
|
||||
|---|---|---|---|---|
|
||||
| **`+etm2`** | 3000 (plus haut ≤ 3200) | **+200 W** | état 2 (200 < P3) | **ALLUMÉE** (100 ≤ 200) |
|
||||
| **`+etm3`** | 3500 (forcé par `lockMinPowerW`) | **−300 W** | état 2 | **ÉTEINTE** (100 > −300) |
|
||||
|
||||
Sous `+etm2`, le routeur écrête malgré tout à 3500 W (verrou interne) : **500 W
|
||||
sont consommés de plus que comptés**, et ce sont ces 500 W que la sonde révèle.
|
||||
|
||||
**Prédiction falsifiable : la sonde s'allume sous `+etm2`, reste éteinte sous
|
||||
`+etm3`. Si elle s'allume sous `+etm3`, le raisonnement est faux.**
|
||||
|
||||
Prédiction secondaire : **la PAC ne changera pas d'état** entre les deux
|
||||
versions — 200 W comme −300 W sont tous deux sous P3 = 1500 W. Le volet 1 ne
|
||||
montrera donc rien sur la PAC ; c'est la sonde qui porte la démonstration. Sans
|
||||
elle, ce relevé aurait conclu « aucun effet observable » à tort.
|
||||
|
||||
### Volet 2 — commutations par relais
|
||||
|
||||
Balayage complet 0 → 3500 W puis retour, plateaux ≥ 90 s (`minOnS` = 60 s).
|
||||
|
||||
Comptage attendu sur un aller simple :
|
||||
|
||||
| Relais | Commutations | Part |
|
||||
|---|---|---|
|
||||
| R500 | **7** | bit de poids faible |
|
||||
| R1000 | **3** | |
|
||||
| R2000 | **1** | |
|
||||
| **total** | **11** | |
|
||||
|
||||
La transition **1500 → 2000 W** (`{R500,R1000}` → `{R2000}`) bascule **les trois
|
||||
relais**, soit **3 des 11** commutations à elle seule. C'est la seule du câblage
|
||||
dans ce cas.
|
||||
|
||||
**Piège prédit — le cliquet.** `currentPowerW` valant le nominal commandé, le
|
||||
budget rendu à la charge inclut toujours son propre palier : un profil qui ne
|
||||
fait que **décroître en surplus positif** ne fera jamais redescendre le palier.
|
||||
Il faut des plateaux à **surplus négatif** pour provoquer la descente, sinon le
|
||||
chauffe-eau reste à 3500 W du début à la fin et le relevé est vide.
|
||||
|
||||
---
|
||||
|
||||
## 3. Protocole
|
||||
|
||||
Deux campagnes **séparées**, jamais fusionnées : si un résultat surprend, il faut
|
||||
pouvoir dire lequel des deux réglages en est la cause.
|
||||
|
||||
**Volet 1** — `minOnS` du chauffe-eau porté à **300 s** le temps de l'essai, pour
|
||||
élargir la fenêtre d'observation. Écart de réglage assumé et déclaré ; remis à
|
||||
60 s après.
|
||||
|
||||
**Volet 2** — `minOnS` à 60 s, plateaux ≥ 90 s, avec plateaux à surplus négatif.
|
||||
|
||||
**Ordre d'exécution** : `+etm3` étant déjà installé, mesurer l'**après** d'abord,
|
||||
puis descendre en `+etm2`, refaire le même profil, puis remonter en `+etm3`.
|
||||
|
||||
**Vérification obligatoire au retour en `+etm2`** : relire paliers et rangs par
|
||||
`NymeaEnergy.GetLoadConfig` **avant** de lancer le profil. La configuration a été
|
||||
écrite par `+etm3` ; si `+etm2` la rejetait — silencieusement ou non — on
|
||||
mesurerait deux dispositifs différents sans le voir.
|
||||
|
||||
---
|
||||
|
||||
## 4. Résultats
|
||||
|
||||
*(à compléter après mesure — ne pas modifier les sections ci-dessus)*
|
||||
Loading…
x
Reference in New Issue
Block a user