Note de conception. Aucun code, aucun champ, aucune entrée au modèle de
charges : elle existe pour que la porte reste ouverte.
Le §14a EnWG permettra au gestionnaire de réseau d'imposer un plafond de
puissance au point de livraison, que l'EMS répartit ensuite librement sur les
appareils. C'est le même mécanisme que le délestage exigé par LM-1006, avec
une source de commande différente. Il y a donc trois sources pour un seul
mécanisme : le disjoncteur de branchement (physique, permanent), le §14a
(externe, sur ordre, temporaire), et le plancher éco du §10 (implicite, celui
qu'on s'impose en décidant de soutirer).
Ce que la note demande, et c'est tout : quand le délestage général sera écrit,
ne pas l'écrire comme « la protection de surcharge » mais comme « appliquer un
plafond de soutirage ». La source est un paramètre, pas une hypothèse enfouie
dans le nom de la fonction. Cela tient dans une signature aujourd'hui ; ce
serait une refonte dans deux ans.
Deux propriétés sont vraies des trois sources et ne coûtent rien à tenir dès
l'écriture :
- Le plafond le plus contraignant l'emporte, et on doit pouvoir dire LEQUEL
a mordu. C'est l'exigence qui sépare déjà BELOW_MIN_POWER de
SURPLUS_INSUFFICIENT : un client bridé doit lire « gestionnaire de réseau »
et non « protection de surcharge ». Deux causes, deux gestes — l'une se
subit, l'autre s'attaque en délestant ou en revoyant l'abonnement.
- Le plafond survit à la panne du HEMS. Vrai du disjoncteur par
construction ; ce sera une obligation légale pour le §14a, où la coupure
totale est interdite mais le plafond doit tenir. C'est une contrainte sur
degradedMode, et ce n'est pas celle qu'on aurait devinée : le repli L2
d'aujourd'hui est conçu pour NE RIEN INITIER, pas pour continuer à faire
respecter une borne qu'un tiers a imposée. Autant le concevoir là-dessus
maintenant que le découvrir en certification.
Referme au passage une référence pendante : LM-1006-1 était cité par §13 sans
avoir jamais été défini.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj
Le relevé machine du 2026-08-26 l'énonçait sans détour : « tant que ceci n'est
pas traité, la transplantation ne commande rien ». L'arbitre décidait,
publiait un motif juste, et adjustEvChargers() commandait autre chose une
milliseconde plus tard. Ce lot ferme les trois points que le banc a ouverts.
1. UNE CHARGE, UN COMMANDEUR
Les actions EV du waterfall sont enfin DISPATCHÉES — elles ne l'étaient pas du
tout : m_loadAdapters ne contient pas les bornes, et applyActionsToAdapters()
s'arrêtait là. Et les bornes ainsi commandées sortent du chemin proxy par deux
crochets virtuels posés dans l'amont, interrogés à deux moments du cycle où la
réponse n'est pas la même : evSurplusPlannedByWaterfall() avant le plan (à qui
la borne appartient-elle), evCommandedByWaterfall() après (qu'a-t-il commandé).
Sans cette distinction, une borne servie par l'échéance ne serait plus
commandée du tout.
Le jeu des bornes commandées est NOMMÉ par le scheduler (Plan::waterfallEvIds).
Le redéduire ailleurs — « motif différent d'EV_DEADLINE », « financement au
surplus » — dériverait du vrai au premier motif ajouté, et EV_GRID_START porte
justement funding=Grid tout en venant du waterfall. Il est vidé à l'entrée du
mode dégradé : le waterfall ne commandant plus, il ne peut plus revendiquer.
chargingState, que posait adjustEvChargers(), est repris par l'arbitre pour
les bornes qui n'y passent plus — sinon l'app afficherait « en charge » une
borne que l'arbitre vient d'éteindre.
2. evFloorW() REND L'EXIGENCE RÉELLE, ET LA TOLÉRANCE DEVIENT VISIBLE
Le plancher valait `min × acquisitionTolerance × 230 × phases` : 2 070 W
annoncés pour une borne qui en exige 4 140. Le waterfall allouait 2 828 W,
l'adaptateur refusait d'enclencher sous 6 A, et 2 828 W étaient retirés du
budget pour personne. Ce sont deux grandeurs différentes : le plancher est ce
que la borne EXIGE, la tolérance est la part qu'on accepte de ne pas couvrir.
La tolérance n'est pas supprimée pour autant — un réglage documenté (défaut
0,5) qui devient inerte sans le dire est un silence ambigu, et tout le parc
verrait son VE démarrer deux fois plus tard sans explication. Elle devient un
seuil de démarrage EXPLICITE : motif EV_GRID_START {budgetW, floorW, gridW},
funding=Grid, et une comptabilité qui se partage — budgetW dans
budget.allocatedW, gridW dans budget.evReservedW, budgetW + gridW ==
allocatedW.
C'est une brèche assumée dans le financement réseau que DESIGN_3g §3.1 déférait
à 3f. Elle est bornée par construction, pas par discipline : surplus réel exigé
(budgetW > 0), tout le budget restant consommé donc AU PLUS UNE borne par
cycle, et le plafond de la protection de surcharge s'applique avant. Écrite en
toutes lettres dans DESIGN_3g §3.1-bis.
3. LE RANG D'UNE BORNE EST CONFIGURABLE
Il vit là où vivent tous les rangs : LoadConfig.priority (LM-1206/LM-1207). Pas
de second système de priorité — un classement propre aux bornes ne saurait pas
exprimer « VE1 > ECS > VE2 », et deux classements qui ne peuvent pas
s'interclasser sont un défaut, pas deux fonctionnalités. ChargingInfo ne porte
donc aucun champ de rang.
Toute borne détectée reçoit d'office une entrée « evcharger », portant le rang
et RIEN d'autre : ses limites viennent du Thing et changent avec la voiture
branchée. Création journalisée, une ligne par borne, à la création seulement —
une écriture que personne n'a demandée doit laisser une trace. Le tri devient
TOTAL : à rang égal, l'identifiant départage, donc laquelle démarre est
reproductible même avant tout réglage.
L'entrée SURVIT à la disparition de son Thing : borne remplacée, ThingId
changé, appareil déposé. Elle reste publiée available: false / faultCode:
THING_MISSING / motif LOAD_UNAVAILABLE, et ne retient aucun budget. La
supprimer d'office rendrait « borne remplacée » indistinguable de « borne
jamais configurée ».
CORRIGE UNE RUPTURE D'INVARIANT DE 3g-1, non signalée à l'époque : en faisant
entrer les bornes dans loads[], 3g-1 publiait des charges qui ne figuraient
dans AUCUNE GetLoadConfig — la charge fantôme que le lot B-bis avait
supprimée, réapparue par l'autre bout. L'app s'appuie sur cet invariant pour
résoudre libellé, domaine et rang. L'auto-provisionnement le rétablit par
construction.
ÉPROUVÉ
- testEvChargerRankDecidesWhoCharges : deux bornes, un budget qui ne paie
qu'un plancher, la seconde refusée avec BELOW_MIN_POWER {budgetW: 620,
minPowerW: 1380}, et l'inversion du rang change la borne servie. C'est la
moitié ARBITRAGE de LM-1204-b. Couvre aussi l'aller-retour neutre par la
frontière RPC et l'inclusion loads[] ⊆ GetLoadConfig.
- testEvGridStartIsAnnouncedAndBounded : le motif chiffre le soutirage, la
comptabilité se réconcilie, une seule borne soutire par cycle.
- testEvChargerConfigOutlivesItsThing : l'entrée survit, publiée en défaut.
- testEvChargerConfigIsRankOnly / RefusesPayloads / ClaimsItsThing.
Deux points de contrôle de `run` bougent, dans un seul scénario et par une
cause unique : la conversion watts→ampères se fait désormais après
l'allocation, et l'arrondi tombe parfois de l'autre côté. 14 des 16 scénarios
sont identiques au bit près, et ce qui compte est inchangé dans les deux —
la voiture est à 100 % à l'échéance.
Suite complète : simulation 27/27, charging 16/16, loadmodel 16/16,
spotmarket 7/7. Build amd64 0/0.
RIEN N'A TOURNÉ SUR MACHINE. docs/RECAP_3g2.md dit ce qui reste à éprouver au
banc — dont LM-1204-b avec deux bornes réelles, la Terra AC étant vérifiée
absente du réseau (ARP INCOMPLETE depuis le banc lui-même).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017TVywtayEeoRJ2yWUW4iZj
Le vrai sujet n'était pas le banc mais le défaut d'usine. Une fois la règle batterie
dans le budget, un seuil à 0,9 gèle toute l'installation sous 90 % de SOC — ni ECS, ni
PAC, ni borne — sans erreur et sans panne. Personne ne s'en apercevait tant que la règle
ne touchait que le VE.
Le réglage confondait une CIBLE et une RÉSERVE. Une cible est ce qu'on aimerait
atteindre, une réserve ce sous quoi on ne descend pas ; la règle « sous ce niveau, rien
d'autre n'est servi » a une sémantique de réserve et était défaultée comme une cible.
0,2 protège l'autonomie du soir sans confisquer la journée, et un installateur qui veut
« la batterie d'abord » monte la valeur délibérément — maintenant que l'écran l'expose.
BATTERY_RESERVE publie le surplus RETENU, pas seulement le SOC : « 3 200 W retenus » se
comprend là où « batterie à 47 % » se subit.
LM-1203-b inscrit la nuance qui ne se déduit pas du code : sous la réserve le budget est
annulé, pas réduit.
Vérifié au passage, comme demandé : evReservedW devra filtrer sur funding == Grid après
la seconde moitié — spot market et échéance restent au proxy, minCurrent et idle
disparaissent. Il reste correct tel quel tant que le VE n'est pas dans la cascade.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPUo3RMr8SzK6qbFtfBm8H
Défini avec Patrick quand le banc a reçu une seconde borne. Il n'est PAS exerçable
avant 3g, et c'est le point : nonEvLoads filtre etmvariableload | relay-router |
sg-ready, l'EV est décidé en proxy AVANT le waterfall, donc les deux bornes ne
partagent aucun budget et leur rang n'a aucun sens.
Le piège que Patrick signale est réel et il a une réponse observable : une wallbox
simulée peut obéir à une consigne sous son plancher là où du matériel refuserait. Le
discriminant est le MOTIF publié, que seul le scheduler peut émettre —
BELOW_MIN_POWER prouve que l'arbitre a refusé et qu'aucune commande n'est partie,
SURPLUS_SETPOINT avec setpointW < minPowerW prouve l'inverse, et une borne à 0 W sans
motif de plancher signifie que c'est le matériel qui a refusé, donc que le test ne
prouve rien.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPUo3RMr8SzK6qbFtfBm8H
Deux champs optionnels de même forme sur LoadConfig — o:meterThingId, o:sensorThingId —
et leur publication en télémétrie. Rien d'autre : l'arbitre ne s'en sert pas pour
décider, et le §12 comme le §10 restent à faire.
« Aucun effet sur les décisions » est vrai par CONSTRUCTION, pas par discipline : les
adaptateurs ne voient jamais ces Things. attachMeasurements() les résout au moment de
publier, dans les deux chemins de télémétrie — y compris le mode dégradé, où un
exploitant veut précisément voir ce que la charge fait pendant que l'arbitre ne décide
plus rien.
measuredW est publié À CÔTÉ de allocatedW et jamais fondu dedans : l'un est ce que le
waterfall a alloué, l'autre ce qu'un compteur a vu. Les confondre rendrait la somme des
allocations irréconciliable avec budget.allocatedW — et injecter une mesure en retard
sur la commande réintroduirait l'oscillation que le recrédit a supprimée.
claimedThingIds() les exclut, et l'exclusion est maintenant commentée sur place : LM-201
vaut pour ce qui commande, ceux-ci mesurent. Sans ce commentaire, la symétrie avec
relays[] invitait à les ajouter — ce qui ferait refuser un compteur divisionnaire
partagé ou une sonde de pièce commune.
spec 0.2.1 : la précondition de livraison du §10 (extension du délestage au waterfall,
même lot ou avant, jamais après) est écrite comme CONDITION et non comme conseil — la
protection de surcharge ne déleste que les bornes, et des planchers éco qui
s'additionnent un matin sans soleil sur un branchement 6 kVA feraient disjoncter
l'installation. Et LM-1008 tranche la cible de confort : saisie en degrés, frontière de
l'arbitre en énergie, conversion à la couche domaine — et aucune conversion nécessaire
aujourd'hui, un comparateur suffit, c'est l'arrêt qui compte et pas le dosage.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPUo3RMr8SzK6qbFtfBm8H
Trois manques du modèle, spécifiés AVANT implémentation. Rien à coder tant que
Patrick n'a pas relu.
§10 — Besoin à deux niveaux (LM-1000+). L'éco n'est pas un champ nouveau : c'est
`needs {dailyDeadline, minEnergyWhPerDay}` promu au rang de plancher. Deux passes sur
la MÊME liste ordonnée, soit un ordre lexicographique sur (niveau, rang) — dérivé du
rang existant, donc pas un second système de priorité ; la paire
prioritéEco/prioritéConfort est rejetée explicitement. Deux règles que la conception
appelle et que le brief ne demandait pas : une seule commande par charge et par cycle
(sinon deux commutations dans le même cycle, du court-cycling fabriqué par l'arbitre),
et un recrédit anti-clignotement attribué une seule fois.
La frontière est nommée : la passe 1 n'est pas bornée par le surplus mais par une
AUTORISATION DE SOUTIRAGE, objet distinct que le rule-based rendra binaire et le MILP
continu. Et deux couplages sans lesquels la conception est fausse : la limite de
raccordement — les planchers éco s'additionnent sur le disjoncteur, et la protection
de surcharge ne déleste aujourd'hui QUE les bornes — et l'ordre de service apparent,
qu'un plancher de rang 4 passant devant un confort de rang 1 rend contre-intuitif.
§11 — Compteur et sonde (LM-1100+). Sélection par interface nymea, jamais par plugin.
Le compteur vérifie, il ne décide pas : ne pas l'injecter au budget, il est en retard
sur la commande et la charge est déjà comptée au compteur racine — décomposition, pas
source. Un écart de mesure ne pose PAS available:false : ce serait retirer le service
sur un doute de mesure. Et ni le compteur ni la sonde ne sont exclusifs, contrairement
aux relais : LM-201 ne s'applique pas à ce qui mesure, donc validateSet() ne doit pas
les inclure dans son contrôle d'unicité.
§12 — Le plancher (LM-1200+). Le domaine de la consigne devient {0} ∪ [min, max], un
ensemble discontinu. Déclaré pour etmvariableload seul ; dérivé pour les deux autres —
même règle qu'au lot D pour stagesW. La règle d'allocation qui compte : sous le
plancher, allouer 0 et TRANSMETTRE le budget, sinon une charge de rang 1 bloque tout
le waterfall en gardant un budget qu'elle ne peut pas utiliser. Décision arrêtée : la
priorité porte sur la borne, pas sur la voiture ; pas de priority dans ChargingInfo,
qui ne saurait pas exprimer « VE1 > ECS > VE2 ».
§13 — Ordre recommandé, et ce n'est PAS celui de l'énoncé : §11 d'abord (additif,
risque nul, et la sonde constitue l'historique sans lequel les seuils du §10 ne se
règleront jamais — le différer coûte du temps CALENDAIRE, pas du développement), puis
§12 (contenu, débloque 3g puis l'unification du rang), puis §10 en dernier — et son
délestage général dans le même lot, pas après.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPUo3RMr8SzK6qbFtfBm8H
LM-201 est la règle qui manquait sous LM-200. Une charge existe quand il y a un canal de
commande DISTINCT pour un service. Elle repose la question du domaine, que 0.1.3 posait mal :
une PAC air/eau fait chauffage, rafraîchissement et ECS — le domaine ne décrit donc pas la
MACHINE, il décrit CE QU'ON ARBITRE.
Conséquences : PAC + ECS sans ballon séparé = UNE charge (heating), pas de charge ecs — le
SG-Ready commande la machine entière et la répartition appartient à sa régulation ; ballon
séparé = charge distincte, il a son propre canal ; PAC qui fait du froid = toujours une seule
charge, ce qui change est la saison, pas la configuration.
La règle explique l'exclusivité de validateSet() (LM-302-b / ECS-110-b) : deux charges sur un
canal unique se contrediraient, et le budget compterait la même puissance deux fois. Le refus
existait avant la règle ; la règle dit enfin pourquoi il est juste.
LM-202 : thermostats et zones ne sont pas des charges. Un thermostat ouvre une vanne, il ne
porte pas la consommation. Les déclarer produirait des entrées à 0 W dans le waterfall pendant
que la PAC est comptée ailleurs. Ils décrivent où va la chaleur, pas combien on en achète —
leur écran, leur namespace, jamais LoadConfig.
Enforcement LM-200 tranché : avertissement au journal, PAS de refus dans isValid(). Mais
l'avertissement n'a pas encore de prédicat — voir le rapport de session. Keyé sur domain seul
il crierait sur des installations correctes (heating + relay-router = chauffage résistif ;
hvac + relay-router = VMC). Son discriminant est typeAppareil (§8-1), valeur thermodynamique.
Spécifié ici, implémenté avec lui.
§8-5 : heating vs hvac reste OUVERT et ne se saura qu'en dessinant la PAC communicante, où les
consignes ECS et chauffage sont enfin séparées. D'ici là o:domain garde son rôle actuel,
sans force normative — ne construire aucune règle dessus.
INTERFACE_etmvariableload.md (canonique) : §4-bis et §4-ter ajoutés, côté app. C'est l'app qui
guide au moment du choix, et c'est le seul endroit fiable — elle sait quel appareil
l'installateur déclare, le moteur ne le sait pas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HajXLUczEyZd22JeewRfff
La PAC ne se pilote qu'en SgReady (contacts SECS de signalisation, 4 états normés) ou en
COMMUNICANT via un plugin nymea. Ni Relay ni Variable : le premier couperait l'alimentation
du compresseur et lui retirerait son autorité sur son propre cycle (dégivrage, retour
d'huile, temporisation) ; le second suppose un cadran en watts qu'un compresseur n'est pas.
LM-101 disait « le domaine ne détermine pas le mécanisme et réciproquement » — vrai du
couplage de CONCEPTION, faux lu comme une liberté de combiner. Précisé.
Piège nommé au passage : les contacts SG-Ready SONT des relais (K1/K2 au banc sont deux
things power), mais ils signalent au lieu de porter la charge. Voir des relais dans une
config ne dit rien du mécanisme qui convient.
Le mécanisme communicant, encore appelé ModbusSetpoint ici, porte un nom trop étroit : ce
qui le définit est qu'un thing nymea porte le modèle de la machine, pas le transport.
§8 point 5 : faire du domaine un discriminant de validation est une décision de contrat,
pas un correctif — trois options pesées, non tranchée.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HajXLUczEyZd22JeewRfff
Le bloc d'enregistrement codé en dur d'energypluginnymea.cpp est supprimé, avec
registerSgReadyAdapter(), la table m_sgReadyAdapters et claimedRelays(). Il n'existe plus
aucun chemin d'enregistrement en dur : m_loadAdapters est la table UNIQUE des charges
arbitrées, et toutes ses entrées viennent de LoadConfigStore.
Contrat : loads[] de GetLoadTelemetry est désormais INCLUS dans GetLoadConfig, par
CONSTRUCTION et non par discipline. La règle de détection publiée à +etm14 — « un loadId sans
équivalent dans GetLoadConfig est une charge non configurable » — est retirée d'INTERFACE.md :
elle n'avait qu'un porteur, pac-terrain, qui vient de disparaître. Aucun configurable:false
n'est ajouté, il n'aurait plus rien à signaler. L'inclusion ne vaut que dans ce sens : une
charge enabled:false est configurée sans être publiée.
SÉCURITÉ — repli L2 d'une PAC de configuration, trou ouvert par LM-300 et refermé ici. Le
repli envoyait un Setpoint(0) à toute la table et un State(2) à une table séparée réservée à
la PAC en dur ; une PAC construite depuis la CONFIG vivant dans la première recevait donc une
action que SgReadyAdapter rejette d'entrée, et rien d'autre — elle restait en état 4 sous
compteur muet quand SAFETY.md §L2 exige l'état 2. Le motif DEGRADED_L2 s'affichait
correctement : seule l'écriture manquait. Le repli lit maintenant supportedKinds (LM-301-b).
ECS-411/-411-b au SG-Ready : l'état de départ est relu sur les contacts, avec relevé contact
par contact et l'issue — y compris quand l'issue est l'état neutre. ECS-412 au minStateHold :
armement paresseux au démarrage à froid, jamais permanent.
Harnais de test : JournalCapture se chaînait sur elle-même (récursion infinie à croissance
quadratique dès la deuxième capture vivante, donc OOM) ; tm/owner non initialisés sur trois
sites de freshSetup().
Vérifié sur .75 avant publication — docs/RELEVE_LOTBbis.md. Suites : simulation 85,
charging 74, spotmarket 44, zéro échec, un processus par test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HajXLUczEyZd22JeewRfff
Le principe dégagé par les tests d'ECS-411 puis d'ECS-414 ne vit pas sous ECS-414 :
il vaut pour tout mécanisme, présent et futur. Il est donc inscrit en LM-104
(spec_loadmodel.md §1), ECS-411 et ECS-414 n'en étant que deux applications.
Les deux moitiés sont indissociables, et c'est l'omission de la seconde qui piège :
supposer « contact fermé » puis en déduire « donc rien à écrire » transforme une
hypothèse de prudence en masquage de panne. La prudence porte sur ce qu'on DIT de
l'installation, jamais sur ce qu'on lui ENVOIE.
Consigne aussi : le tableau ECS-110 (les deux Q_ASSERT de sgreadyadapter sont
supprimés, l'échéance prospective est tombée), la charge utile sg-ready réellement
implémentée en LM-300, et le statut de spec_loadmodel.md — §3 n'est plus une intention.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deux documents normatifs, préalables au lot AGENTS.md qui les référence.
spec_ecs.md 0.4.3 — spécification ECS multi-palier, écrite après audit du code :
- 0.4.1 : statut réel des binaires de test, portée du point de gouvernance
AGENTS.md, citation de règle dans ECS-306, recouvrement ECS-411/ECS-412 ;
- 0.4.2 : étape 2 « type domaine » → « noyau de calcul » (collision avec LM-100) ;
- 0.4.3 : ECS-110 étendu — la validation ne doit pas reposer sur Q_ASSERT,
absent du binaire release (QT_NO_DEBUG).
spec_loadmodel.md 0.1.1 — modèle de charges (domaine × mécanisme), intention de
conception. Ne déclenche aucun travail.
Aucun code touché.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
