From b1394bb681b7a0e971e7b3fb2bd2f3d223849a04 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Fri, 28 Aug 2026 14:54:40 +0200 Subject: [PATCH] =?UTF-8?q?docs(=C2=A711):=20la=20r=C3=A8gle=20d'affichage?= =?UTF-8?q?=20du=20compteur=20se=20lit=20sur=20source,=20jamais=20sur=20ad?= =?UTF-8?q?apter?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signalé en relayant +etm26 : « masqué dès que la charge mesure, sauf SG-Ready » formule la règle PAR MÉCANISME. La conclusion est bonne, la clé est fausse, et le contrat ne l'interdisait pas explicitement. L'exception SG-Ready est déjà DANS LA DONNÉE : un sg-ready publie `none`, donc « masquer quand source == device » ne le masque pas, sans qu'aucun client ait à connaître le mécanisme. Et brancher sur `adapter` se trompe sur un cas qui n'a rien de théorique : un relay-router à topologie MIXTE publie lui aussi `none` (LM-1105-a). Un client qui déciderait au mécanisme masquerait le champ sur un ECS qui ne peut être mesuré QUE par un compteur dédié. Un mécanisme est un mauvais indice de mesurabilité ; la source EST la mesurabilité. C'est LM-1106 pris par l'autre bout : le régime est publié POUR qu'il ne soit pas déduit. Le redéduire du mécanisme côté client remettrait dans l'app la déduction qu'on vient de retirer du moteur — et il faudrait la maintenir à chaque mécanisme ajouté. Aucun code, aucune sémantique déplacée : le contrat dit désormais ce qu'il laissait deviner. Pas de release. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015F7G5VeaPVSMeVNjiGj36p --- INTERFACE.md | 14 +++++++++++++- docs/BRIEF_depuis_plugin.md | 16 ++++++++++++++++ specs/spec_loadmodel.md | 16 ++++++++++++++++ 3 files changed, 45 insertions(+), 1 deletion(-) diff --git a/INTERFACE.md b/INTERFACE.md index 4eef59b..e9f80e9 100644 --- a/INTERFACE.md +++ b/INTERFACE.md @@ -417,7 +417,8 @@ charge — jamais ce qu'on lui **commande**. **autorisé partout** et **prioritaire** quand il est renseigné : un compteur posé exprès est le seul à pouvoir contredire un appareil qui se déclare. Ce qui change est qu'il cesse d'être une corvée là où le moteur peut déduire — un client avisé le **masque par défaut** sur les - charges dont `source` vaut déjà `device`, sans l'interdire. + charges dont `source` vaut déjà `device`, sans l'interdire. **Cette règle d'affichage se lit + sur `measurement.source`, jamais sur `adapter`** : voir la note sous `measurement`. - **Ni l'un ni l'autre n'est exclusif**, contrairement à `relays[]`. Ils mesurent, ils ne commandent pas : `validateSet()` les ignore, et deux charges peuvent partager une sonde de pièce ou un compteur de tableau divisionnaire. @@ -716,6 +717,17 @@ allocations irréconciliable avec `budget.allocatedW`. > pouvoir détecter un mensonge.** C'est ce qui justifie de laisser `meterThingId` **disponible** > sur une charge qui publie déjà sa puissance : masqué par défaut, jamais interdit. +> **Décidez sur `source`, jamais sur `adapter`.** « Masquer le compteur dédié sauf pour +> `sg-ready` » paraît équivalent et ne l'est pas : un `relay-router` à topologie **mixte** +> publie lui aussi `none`, et un client qui déciderait au mécanisme masquerait le champ sur un +> ECS qui ne peut être mesuré **que** par un compteur dédié. La règle sûre tient en une ligne — +> masquer par défaut quand `source == "device"`, proposer sinon — et elle couvre l'exception +> SG-Ready sans qu'aucun client ait à la connaître. +> +> C'est la raison d'être de `source` : le régime est publié **pour** qu'il ne soit pas déduit. +> Le déduire du mécanisme côté client remettrait dans l'app la déduction qu'on vient de retirer +> du moteur. + > **Migration depuis `measuredW`.** L'ancienne clé disparaît ; elle ne pouvait pas exprimer > trois états, et la doubler d'un second champ aurait obligé le client à joindre deux clés pour > lire une seule chose. `measuredW: X` devient `measurement: {source: …, powerW: X}` ; son diff --git a/docs/BRIEF_depuis_plugin.md b/docs/BRIEF_depuis_plugin.md index 221e9b9..b3c4d40 100644 --- a/docs/BRIEF_depuis_plugin.md +++ b/docs/BRIEF_depuis_plugin.md @@ -326,6 +326,22 @@ en panne », que rien ne séparait. > `meterThingId` reste **autorisé** sur une borne qui publie déjà : à masquer par défaut, pas à > interdire. +**Et une mise en garde sur la façon d'écrire cette règle chez vous : décidez sur +`measurement.source`, jamais sur `adapter`.** « Masqué dès que la charge mesure, sauf SG-Ready » +paraît équivalent et ne l'est pas — un `relay-router` à topologie **mixte** publie lui aussi +`none`, et vous masqueriez le champ sur un ECS qui ne peut être mesuré **que** par un compteur +dédié. La règle sûre tient en une ligne, et elle couvre l'exception SG-Ready sans que vous ayez +à la connaître : + +``` +si measurement.source == "device" → compteur dédié en réglage avancé (replié) +sinon → compteur dédié proposé, visible +``` + +C'est toute la raison d'être de `source` : le régime est **publié** pour ne pas être déduit. Le +redéduire du mécanisme côté app remettrait chez vous la déduction qu'on vient de retirer du +moteur — et vous la maintiendriez à chaque mécanisme ajouté. + ### Deux choses trouvées en implantant, qui changent ce que vous afficherez **`sg-ready` est `none` par CONSTRUCTION, pas par accident de matériel.** Un contact SG-Ready est diff --git a/specs/spec_loadmodel.md b/specs/spec_loadmodel.md index aee17b1..170ce07 100644 --- a/specs/spec_loadmodel.md +++ b/specs/spec_loadmodel.md @@ -1026,6 +1026,22 @@ dédié » se **masque par défaut** là où `source` vaut `device`, et se propo Il ne doit pas être *interdit* : ce serait fermer le cas ci-dessus, et casser le compteur de tableau divisionnaire couvrant plusieurs charges (LM-1104). +> **La règle de présentation se lit sur `source`, JAMAIS sur `adapter`.** La tentation est +> d'écrire « masqué sauf pour `sg-ready` », puisque LM-1105-b fait de ce mécanisme une +> exception. Mais l'exception est déjà **dans la donnée** : un `sg-ready` publie `none`, donc la +> règle « masquer quand `source == "device"` » ne le masque pas — sans qu'aucun client ait à +> connaître le mécanisme. +> +> Et brancher sur `adapter` se **trompe** sur un cas qui n'a rien de théorique : un +> `relay-router` à topologie **mixte** publie lui aussi `none` (LM-1105-a). Un client qui ne +> déciderait qu'au mécanisme masquerait le champ sur un ECS qui, précisément, ne peut être +> mesuré que par un compteur dédié. Un mécanisme est un mauvais indice de mesurabilité ; la +> source EST la mesurabilité. +> +> C'est LM-1106 pris par l'autre bout — le régime est publié **pour** qu'il ne soit pas déduit, +> et le déduire du mécanisme côté client remettrait dans l'app la déduction qu'on vient de +> retirer du moteur. + --- ## §12 — Le plancher de modulation