testWaterfallChargerGetsNothingBackInOverload : phases du compteur
aveugles à la borne, 24 A sur A pour un seuil de 22,5 A. La stratégie tient
la borne à son plancher (1 380 W) ; sans la garde de dépassement
d'evPhaseAllowanceW(), elle lui rendait 2 530 W pendant le dépassement.
Aucun test existant ne rougissait sans cette garde.
Au passage, deux formulations retirées des commentaires (garde publique).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Une borne qui ne publie pas ses courants par phase (V2C Trydan :
currentL1..3) avait meteredPhases() vide, et le plafond d'heures creuses
ne lui rendait rien de ce qu'elle tire : il la lisait comme une charge de
la maison sur sa phase, et la consigne alternait chaque nuit (16, 6, 13,
6 A sous 25 A et 10 % de marge ; 6 A tenus avec 8 A de plus sur A).
evAttributableDraw() : le currentPower de la borne est attribué aux phases
que le moteur lui suppose déjà (phasesForCount(), la phase A en
monophasé, comme chargerPhaseKey() pour L4), un tiers par phase en
triphasé. Seulement si c'est sûr : aucun état par phase publié, autant de
phases annoncées que visées (pas de triphasée avec voiture monophasée, pas
de bascule), une ou trois phases. Sinon rien, comme avant.
Question 5 du lot délestage triphasé : hors heures creuses,
evPhaseAllowanceW() rend aussi ce tirage, moins 1 A, hors dépassement
(16, 9, 16, 9 A → 16 A tenus). En dépassement, la place libre reste la
règle. Le calcul est mis en commun avec evOffPeakAllowanceW()
(evCeilingGivingBackDraw()).
run : le scénario 1 phase 32 A alternait 19/20 A sous la limite de phase
et tient 20-21 A ; ses points de charge passent de 80/85/87 à 81/86/88 %
(88 est la valeur de l'amont), 100 % à l'échéance inchangé.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mock : classe chargerUnmetered, une borne qui mesure sa puissance mais
publie ses courants sous currentL1..3 (comme le plugin V2C Trydan), jamais
sous currentPhaseX. EvCharger::meteredPhases() y est vide ; aucune borne du
mock ne produisait ce cas.
- testOffPeakUnmeteredChargerSettlesUnderThePhaseLimit : heures creuses,
limite 25 A, marge 10 %, borne non mesurée (mono sur A, tri) ; rouge :
16, 6, 13, 6, 13… A, et 6 A tenus avec le lave-vaisselle.
- testUnmeteredChargerGivesNothingBackWhenUnsure : triphasée avec voiture
monophasée, courants par phase publiés et nuls ; vert (témoin).
- testWaterfallChargerSettlesUnderThePhaseLimit (question 5) : hors heures
creuses ; rouge : 16, 9, 16, 9… A (maison légère), 16 A puis coupée par
L4 à 26 A pour 25 (maison chargée).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Six fonctions nouvelles. Hors elles, 94 lignes changent dans 8 fonctions, toutes expliquées :
- seuil à 22,5 A pour 25 A (marge de 10 %) : draw.authorisedW −575 W, dépassements et marges
DRAW_CAP au seuil (testSheddingLogKeepsTheLastEpisodes, testSheddingLogCoversEveryMechanism,
testL4ShedsAPacAndSaysItForcedTheLock, testWorstPhaseBindsWhenPhasesAreUnbalanced) ;
- entrées de test déplacées pour la marge, et thresholdA publié
(testOverloadProtectionReasonOnTheCharger, testOverloadProtectionOnAManualChargerIsLogged) ;
- testBlockedDischargeShowsAtTheMeterAndL4Decides : le plafond d'heures creuses descend avec le
seuil, la borne passe de 16 à 6 A ;
- testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter (marge nulle) : phases aveugles à la borne,
relevées au niveau du total ; consignes inchangées.
run et toutes les autres fonctions : identiques.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Tests de l'algorithme amont (charging, simulation::run) et famille « heures creuses à pleine
puissance » : marge nulle, posée explicitement au point d'appel. Ils figent une arithmétique
contre la limite ; la marge déplace le seuil sans toucher à ce calcul.
- testWorstPhaseBindsWhenPhasesAreUnbalanced : marge et plafond au seuil (22,5 A pour 25 A).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La marge que le compteur laisse sous le seuil ne bornait que la cascade du rule-based. Sous un
optimiseur qui demande le maximum, ce que la protection venait de retirer revenait au cycle
suivant, dès que le compteur repassait sous la limite : 32,2 A pendant une minute sur
l'installation d'essai, après un délestage du chauffe-eau.
bornerOptimiseurAuSoutirage(), avant le dispatch : une consigne d'optimiseur ne fait monter une
charge que de la marge libre (pire phase, consommée dans l'ordre du créneau). Elle ne réduit
rien — c'est la protection qui réduit. L'engagé d'une borne est sa dernière commande tenue, si
bien que le dispatch ne défait plus, dans le même cycle, ce que la protection vient de faire.
Une consigne écrêtée publie DRAW_CAP et clamped, plus le motif de l'optimiseur (défaut 5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décision du 2026-10-27 : le moteur vise 90 % de la limite de phase — 27 A pour 30 A — pour le
plafond qu'il déclare et alloue, et pour le seuil où la protection agit. Réglable de 0 à 25 %,
persistée avec la limite (phaseSafetyMarginPercent), publiée par GetPhasePowerLimit et
PhasePowerLimitChanged (même charge utile : limite, marge, effectivePhaseLimit), écrite par le
paramètre optionnel de SetPhasePowerLimit. Le seuil atteint DrawCap, la protection amont et sa
reprise, la limite de prepareInformation(), les deux allowances du proxy, et le phaseLimitA
envoyé à l'optimiseur. OVERLOAD_THROTTLED porte thresholdA quand la marge n'est pas nulle.
Défaut 2 : sur l'installation d'essai, les courants par phase publiés étaient en retard sur le
total (29,1 A lus pour 32,3 A importés par phase) et la protection a attendu 1 min 45. Les phases
somment au total : la plus chargée en porte au moins le tiers. tiragesCoherentsAvecLeTotal()
relève les phases quand leur somme est sous le total, jamais ne les abaisse ; c'est la lecture de
la protection, de sa reprise, du journal de ses gestes et de la cascade.
Tests existants mis à jour : les dépassements se mesurent au seuil (22,5 A pour 25 A).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- testOverloadLeavesTheChargerItsPhases (3 cas) et testAnUnassignedCarTakesItsPhasesAway :
une borne triphasée sans voiture, ou dont la voiture monophasée est désassignée, comptée sur
une phase — 3 680 W alloués et attendus pour 16 A × 3.
- testOverloadReactsToTheTotalWhenPhasesLag : des courants par phase en retard sur le total
retardent la protection.
- testPhaseSafetyMargin : la marge de 10 % (décision du 2026-10-27).
- testTheDrawCapHoldsAgainstAnOptimizerAtMaximum (refoptimizer) : sous un optimiseur qui
demande le maximum, ce que la protection a retiré revient au cycle suivant.
- Témoins verts sur etm76 : testSheddingOpensTheRelaysUnderMinOn (le délestage franchit minOn
et ouvre les relais) et testCommandDivergenceSeesAPhaseCountError (×3 vu en régime établi).
- Optimiseur de référence : mode over-limit (toute consigne en watts à 50 kW).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La justification de ProgressionMinW cite la négociation la plus lente
par son document (DESIGN_COMMANDE_PERDUE.md §9.1) plutôt que comme un
relevé. Dans les tests, « banc » désignait le scénario : mot remplacé.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contre la référence d'etm75, 29 fonctions changent, toutes par le
verdict de l'écart commande/mesure ou ce qui en découle :
- 21 par `command.divergent` seul (marches suivies et premières
commandes qui ne divergent plus ; mesures remises à la main par le
harnais qui divergent) ;
- `run` : `expectedW` de la borne commandée par le proxy (mémoire de
commande tous émetteurs) et 46 cycles de gel sous arrêt verrouillé ;
- 7 où la garde de refus mord enfin : datée à l'horloge murale, elle
était inerte dans toute la suite de simulation.
Plus les 6 fonctions de test nouvelles. Détail dans le rapport du lot.
run-decisions.sh check : IDENTIQUE (24 415 lignes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rejouerBorne() partait de l'horloge murale, comme le test de
reproduction devait le faire tant que l'écart était daté à l'horloge
murale. Le moteur n'en dépend plus, et l'enregistreur `decisions` date
les cycles : la référence n'était pas reproductible à la milliseconde
près. Mêmes chiffres de rejeu avec une date fixe.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testARealRefusalIsStillSeen — borne figée sous une consigne à la hausse :
refus au cycle qui suit la commande, comme avant le correctif ; montée
qui progresse puis cale : latence tant qu'elle se rapproche, refus au
cycle où elle cale ; descente suivie de 500 W seulement : refus au cycle
suivant, la progression n'excuse jamais une descente.
testWattLoadsFollowedOrRefusedUnderAMeter — relais et consigne continue
sous compteur dédié : marche suivie dans les deux sens sans refus ; refus
réel vu au deuxième cycle (la latence par défaut de 60 s n'est pas
dépassée par un cycle de 60 s) ; sans compteur, rien ne change.
testSgReadyDivergenceIsPublishedOnly — sous compteur dédié, une PAC qui
monte en minutes n'est pas divergente, une PAC qui ne démarre pas l'est ;
son recrédit (puissance déclarée) n'en dépend pas.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La borne retenait la consigne VOULUE par son adaptateur, et seulement
quand le waterfall la commandait. Deux faux refus en sortaient :
- une coupure refusée par le verrou de marche/arrêt (300 s) laissait la
borne à 6 A pendant qu'on attendait 0 W ;
- une borne rabaissée par la protection L4, ou commandée par le proxy
(échéance, spot), restait jugée contre la dernière consigne du
waterfall.
La mémoire de commande est posée par EnergyArbitrator::
executeChargingAction(), point unique de tous les émetteurs, avec ce qui
a PASSÉ les verrous et l'instant de la commande.
Pendant que l'arrêt est verrouillé, la borne déclare lockMinPowerW =
courant minimal × 230 × phases, comme un relais sous minOn : le
waterfall gèle ces watts (LOCK_MIN_ON) au lieu de les prêter.
Le verrou borne la SOMME éco + confort : la part confort n'est relevée
que de ce que la passe éco ne couvre pas déjà. Sans cela, une borne
servie à 6 A en éco sous arrêt verrouillé recevait 12 A (trouvé par la
preuve decisions, aucun test ne le voyait).
Tests : testLockedStopFreezesTheMinimumAndIsNoRefusal,
testALockedStopDoesNotAddToTheEcoFloor, et une garde L4 dans
testOverloadProtectionReasonOnTheCharger.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'écart était jugé APRÈS le dispatch, entre la consigne qui venait de
partir et la mesure de la précédente, puis consommé au cycle suivant
avant d'être rejugé. Toute marche de consigne suivie par la borne se
lisait donc comme un refus vieux d'un cycle (60 s, au-delà des 30 s /
7 s de la borne) : recrédit suspendu, coupure, et une boucle de trois
cycles sous un surplus constant (~1,5 kW exportés en moyenne).
jugerCommande() rend désormais UN jugement par cycle, au début du cycle,
lu par le recrédit et par la télémétrie :
- la commande EN VIGUEUR contre la mesure fraîche ; s'ils concordent
(max(200 W, 15 %)), l'épisode se referme ;
- l'ouverture est datée à l'instant de la commande, en temps de cycle,
et non plus à l'horloge murale de la dernière publication ;
- le sens est celui que la commande demande à la charge, et non plus
deviné au niveau de la mesure ;
- en montée seulement, une mesure rapprochée de la commande de plus de
200 W depuis le cycle précédent est une latence. La descente n'a
jamais cette excuse.
command.divergent publie ce verdict ; expectedW et observedW restent
les nombres de la publication.
Le test de reproduction inverse ses assertions « DÉFAUT » : sur trois
rampes (instantanée, 30 s / 7 s, 120 s), 13 A tenus dès le premier
cycle, aucune suspension, export de 10 W dès que la borne a rejoint sa
consigne.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Borne monophasée 6-16 A, 3 000 W de surplus constant. L'écart commande/mesure
est jugé après le dispatch, entre la consigne qui vient de partir et la mesure
de la précédente, puis consommé au cycle suivant par qualifierRefus() avant
d'être rejugé. Une marche suivie se lit donc comme un refus vieux d'un cycle,
au-delà des 30 s / 7 s de la borne : recrédit retenu, coupure (bloquée par le
verrou de 300 s, 6 A tirés pour 0 attendu), puis 7 A, puis 13 A, et ainsi de
suite. La borne tire 1 495 W en moyenne sur 3 000.
Trois rampes : consigne atteinte au pas suivant, 30 s / 7 s, 120 s. Les deux
premières donnent la même trace, cycle pour cycle.
Le test FIGE le défaut. Le correctif devra inverser les deux assertions
marquées « DÉFAUT ». Aucune ligne du moteur n'est modifiée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Elle remplace celle de e775f66, qui portait des ThingId bruts dans
shedding.open et des dates murales dans un test : le `check` n'y était pas
reproductible. Deux enregistrements successifs sont identiques (cmp).
Contre 76bf482 : les 85 fonctions communes sont identiques, sauf 12 lignes
dans 3 fonctions, où seuls le motif et le journal changent ; leurs actions
sont identiques.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le passage en mode manuel ne restitue rien quand la borne est déjà dans
l'état de l'usager : il n'arme donc aucun verrou à l'heure réelle. Le
scénario peut reprendre une date fixe, et la référence `decisions` se
reproduit à l'octet près.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hors épisodes de protection, IDENTIQUE à 76bf482 : les 85 fonctions
communes sont identiques octet pour octet, sauf trois. Celles-là gardent
leurs actions (things, proxy) identiques ; seuls le motif des bornes tenues
(OVERLOAD_THROTTLED, sans niveaux) et le bloc shedding changent :
testL4ShedsAPacAndSaysItForcedTheLock (1 ligne),
testBlockedDischargeShowsAtTheMeterAndL4Decides (2),
testOffPeakFullPowerYieldsToThePhaseLimit (9). Quatre fonctions nouvelles.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- borne abaissée, coupée, puis reprise par le cycle : une entrée au journal,
et une fermeture qui notifie sans autre cause (contre-épreuve : un cycle
identique ne notifie rien) ;
- borne en mode manuel, hors de loads[] : l'épisode s'ouvre et se ferme par
notification, et la reprise amont le referme ;
- relais et SG-Ready délestés pendant 20 minutes : une entrée par charge,
avant et après dans le langage de chaque mécanisme ;
- 21 épisodes : le plus ancien sort.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Borne : executeChargingAction() devient virtuel (marque [ETM], corps amont
inchangé). L'arbitre laisse partir la consigne, puis la lit. Une baisse ou
une coupure de la protection de surcharge ouvre la tenue, et la borne
publie OVERLOAD_THROTTLED {fromA, toA, cut, overshootW, limitA, o:phase}.
La tenue se lève quand le cycle reprend la borne, ou quand la reprise
amont lui rend son courant manuel. Les verrous de la borne sont lus : un
geste refusé n'est pas publié comme un délestage.
- Cascade : shedWaterfallForOverload() note chaque délestage au journal,
avant et après lus sur runtimeView(). Rien d'autre ne change.
- Télémétrie : bloc shedding {revision, open}, absent tant que rien n'a été
délesté. Sa révision déclenche LoadTelemetryChanged à l'ouverture et à la
fermeture d'un épisode.
- RPC : NymeaEnergy.GetSheddingLog, même droit que GetLoadTelemetry (table
des droits et compte sans droit mis à jour).
Aucune consigne, aucun émetteur, aucun verrou ne change (invariant 2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans tarif à heures creuses, IDENTIQUE à b1c0ade : 81 fonctions, octet
pour octet, `run` compris. En heures creuses :
- testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter : 7 → 13 lignes
(variante au total aveugle ajoutée) ;
- testOffPeakFullPowerSwitchesToThreePhases : le recrédit de 1 380 W,
refusé sous le plancher triphasé, est servi en confort dans le plafond ;
achat 11 040 → 9 660 W, consigne totale inchangée (11 040 W) ;
- deux fonctions nouvelles : testOffPeakFullPowerAtDawnStaysInTheCeiling
(13 lignes), testOffPeakFullPowerGivesNothingBackWhileSwitchingPhases (2).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
En heures creuses, le niveau éco d'une borne à pleine puissance vaut son
plafond de cycle, qui porte la limite de phase. À l'aube, la passe confort
lui ajoutait le surplus, et seul le courant maximal de la borne écrêtait
la somme : borne monophasée sur A, limite 16 A, plafond 13 A, 2 540 W de
surplus — 16 A servis, la phase A à 18 A. L'achat publié valait 2 990 W
quand le compteur n'importait que 450 W.
Pour une borne qui porte EV_OFF_PEAK_FULL_POWER :
- la passe confort sert le surplus DANS le plafond ;
- l'achat cède ce que le surplus finance (gridW, drawCommittedW,
draw.committedW) : la somme reste le plafond ;
- la part confort n'a pas de plancher : il porte sur la somme, qui vaut
le plafond. Sinon un surplus sous le plancher serait refusé, ou démarré
par EV_GRID_START, un second achat en plus du premier.
Hors heures creuses et sans tarif, rien ne change.
Tests : testOffPeakFullPowerAtDawnStaysInTheCeiling (nuit, aube, plein
soleil : 13 A, achat 2 990 / 450 / 0 W, achat ≤ import du compteur) ;
testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter étendu au total
aveugle (13, 15, 15… au lieu de 13, 16, 16…) ;
testOffPeakFullPowerGivesNothingBackWhileSwitchingPhases, la garde de
bascule enfin éprouvée (12 A, phase B à 24 A ; sans elle 15 A, B à 27 A).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans tarif à heures creuses : 79 fonctions, 24 056 lignes identiques
octet pour octet à d62365f. En heures creuses, deux fonctions changent
(testBlockedDischargeShowsAtTheMeterAndL4Decides, 2 cycles ;
testOffPeakFullPowerYieldsToThePhaseLimit, réécrit), plus les deux
nouvelles. check et ETM_DECISIONS_TRACES=1 check : IDENTIQUE
(24 168 lignes ; 22 254 lignes de trace).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Près de la limite de phase, la consigne d'une borne à pleine puissance
alternait à chaque cycle : le plafond était la place libre au compteur,
sans lui rendre sa propre consommation. Maison à 2 A par phase, borne
16 A : 16, 7, 16, 7 A sous 25 A ; 16, 14 sous 32 A ; 14, 6, 8, 6 sous 16 A.
En heures creuses, et pour la pleine puissance du lot e2 seulement, le
plafond est lu par EnergyArbitrator::evOffPeakAllowanceW() : limite moins
le tirage de la phase sans la borne, moins 1 A, à l'ampère inférieur. La
règle de l'échéance chez l'amont (adjustEvChargers()). Elle converge en
un cycle : 16 A tenus sous 25 et 32 A, 13 A sous 16 A.
- Courant rendu MESURÉ (currentPower), sur les phases où la borne le
mesure ; rien rendu pendant une bascule ou sans mesure.
- Tirage de la maison sans la borne écrêté à zéro : une borne qui
annonce plus que ce que le compteur voit reste à 1 A sous la limite.
- En dépassement, le plafond vaut au plus le courant mesuré moins 1 A :
il baisse à chaque cycle, jusqu'au plancher, où L4 décide.
- Hors heures creuses et sans tarif : evPhaseAllowanceW(), inchangée.
Tests : testOffPeakFullPowerSettlesUnderThePhaseLimit (sept cas, douze
cycles) et testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter, nouveaux ;
testOffPeakFullPowerYieldsToThePhaseLimit réécrit avec un compteur qui
voit la borne (mesure et non consigne, dépassement, plancher, L4) ;
testBlockedDischargeShowsAtTheMeterAndL4Decides : en dépassement, la
borne finit au plancher (L4 16 → 13 A, stratégie 9 A, L4 6 A) au lieu
d'être coupée.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
72 fonctions sans borne en heures creuses : 23 812 lignes identiques octet
pour octet à la référence de b144c09. Changent, en heures creuses : les six
fonctions du lot e1 qui ont une borne (ECO_FLOOR_GRID 1 380 W →
EV_OFF_PEAK_FULL_POWER 3 680 W, et leur compteur d'entrée, qui inclut
désormais ce que la borne tire) ; s'ajoutent les trois fonctions du lot e2.
check et ETM_DECISIONS_TRACES=1 check : IDENTIQUE (24 068 lignes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décision de Patrick du 2026-10-24. Dans les trois modes qui reportent en
heures creuses (Éco avec minimum, Éco min + échéance, Éco avec échéance) :
- le minimum servi au réseau en heures creuses est le PLAFOND de cycle de
la borne (declared.maxPowerW), plus son plancher. Il porte le courant
maximal, les phases et la limite de phase, et ne descend jamais sous le
plancher : la stratégie rabaisse, L4 coupe. 3 680 W en monophasé 16 A,
11 040 W en triphasé 16 A ;
- les phases se choisissent sur la pleine puissance, plus sur « courant +
surplus » (EnergyArbitrator::enHeuresCreuses(), lu par EvAdapter). La nuit,
une batterie qui couvre la maison et la voiture met le compteur à 0, et la
règle de bascule gardait le monophasé : 3,7 kW au lieu de 11 ;
- la passe éco n'oppose plus à cette borne la marge d'UNE phase de la maison
(LM-1500-h, déjà appliquée en tête de passe et en confort) : son plafond
porte déjà l'autorisation, sur ses phases. Restreint aux heures creuses ;
- motif EV_OFF_PEAK_FULL_POWER {gridW, maxW, phases, until, endsAt,
o:boundBy phaseLimit|floor}, rendu en français, à la place
d'ECO_FLOOR_GRID sur la borne.
Hors heures creuses et sans heure creuse dans le tarif : rien ne change.
Le blocage de la décharge se lève toujours sur la puissance MESURÉE (230 W) :
une borne commandée à 16 A dont la voiture ne prend plus rien le lève.
Tests : testOffPeakChargesAtFullPower, testOffPeakFullPowerSwitchesToThreePhases,
testOffPeakFullPowerYieldsToThePhaseLimit. Les tests du lot e1 en heures
creuses attendent le plafond, et leur compteur inclut ce que la borne tire
désormais (TirageHcW) — sinon il fabriquait un surplus.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les 77 fonctions existantes donnent 23 950 lignes identiques octet pour
octet à la référence de 2cde57c (cmp, lignes de la nouvelle fonction
retirées). La référence s'étend des 96 lignes de
testRefusedWritesAreSpacedAndNeverDelayTheRelease ; check : IDENTIQUE
(24 046 lignes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un onduleur qui refuse la consigne (GEN24 sans « Allow Control », exception
0x04) la voyait reposée à chaque cycle, avec un qCWarning à chaque fois,
toute la nuit, et `held` la publiait comme tenue.
- Une pose refusée (taux ou limite) ouvre une série de refus : la pose
suivante attend 1, 2, 5, 10 puis 15 min au plus (marge de 5 s pour la
gigue du cycle). La série se clôt à la première séquence acceptée
jusqu'au bout (retour au tiers du minuteur) ou à la levée.
- La levée n'est jamais espacée : elle part au cycle même où la décision
tombe, série en cours ou non.
- Journal : un seul qCWarning par série, les refus suivants en qCDebug, un
qCInfo à l'acceptation qui clôt la série.
- Télémétrie : pendant une série, `held` est faux (et `dischargeBlocked`
avec lui), et la batterie publie o:refusedWrites, o:refusedSince,
o:nextAttemptAt. `held` faux plutôt qu'un drapeau à côté : un client qui
ignore le champ nouveau ne doit pas afficher une protection absente.
Mock : propriété dynamique `refuserEcritures` sur la batterie pilotable.
Test testRefusedWritesAreSpacedAndNeverDelayTheRelease ; les six
contre-épreuves (espacement, avertissement, held, levée, deux fins de
série) le font rougir.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans elles, l'enregistrement est identique octet pour octet à la référence de
c5c3203 (23 799 lignes, cmp). Les 151 lignes ajoutées sont celles des six
scénarios d'heures creuses (testOffPeakDemoDay, …EndsAtSixAndOnDstDays,
testWithoutOffPeakTheEngineIsEtm74, testABatteryWithoutControlIsReadAsBefore,
testBlockedDischargeShowsAtTheMeterAndL4Decides,
testAMeterSilenceHandsTheBatteryBack). Deux enregistrements successifs
identiques.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La journée de la démo relit la télémétrie par la frontière RPC pendant le
blocage : le bloc passe la validation du schéma déclaré (o:storage), et le Get
rend ce qui a été publié.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Décisions de Patrick du 2026-10-24. Sans heure creuse dans le tarif saisi
(aucun tarif, tarif unique, prix tous égaux), rien de ceci ne s'exécute.
LA BORNE — modes « Éco avec minimum », « Éco min + échéance », « Éco avec
échéance » (EvAdapter déclare needs.offPeakShift ; le scheduler décide) :
- hors heures creuses : surplus seulement. Le minimum réseau est retiré,
EV_GRID_START aussi (le minimum par une autre porte). Motif
EV_WAITING_OFF_PEAK {at "22:00", startsAt, budgetW}, rendu « … attend les
heures creuses (22:00) ». Le plafond de soutirage et le refus gardent la tête.
- en heures creuses : le plancher de la borne est servi au réseau (passe éco,
bornée par l'autorisation de soutirage). L'échéance reste au proxy, inchangée.
- Eco et Normal ne sont pas touchés.
LA BATTERIE — StorageDischargeGuard exécute, le rule-based décide (y compris en
ombre d'un optimiseur) :
- heure creuse ET bornes qui TIRENT ≥ 230 W (mesuré) ET batterie pilotable :
dischargingRate = 0 PUIS enableDischarging = true (StorCtl_Mod bit DiSCHARGE
= limite active, OutWRte = 0 : la séquence NO_DISCHARGE du plugin) ;
rafraîchi au tiers du minuteur de retour (revertTime) ;
- sinon : levée EXPLICITE, enableDischarging = false puis dischargingRate au
maximum. L2 lève aussi. Une limite à 0 % trouvée active au démarrage est
reprise (rafraîchie ou levée).
- jamais gridCharging, enableCharging, chargingRate, ni un taux négatif.
- générique : interface energystorage et états présents. Sans les états
(noDischargeControl), sans minuteur (noRevertTimer) ou minuteur < 120 s
(revertTimerTooShort) : non commandée, STORAGE_NOT_PROTECTED.
- publié : bloc `storage` de la télémétrie (dischargeBlocked, decision,
batteries[] avec ce qui est LU), absent sans heure creuse ou sans batterie ;
ligne « [Arbitre] Batterie → … » au journal.
Le blocage ne verse rien au budget : surplus = compteur + PV (invariant 8),
le soutirage ajouté se mesure au cycle suivant, L4 garde le dernier mot.
Mock : classe controllableStorage (états modifiables du sunspecStorage,
paramètre revertTime). Tests : journée de la démo, 06:00 sur jours de 24/23/25 h,
etm74 sans heure creuse, batteries non pilotables ou absente, soutirage et L4,
repli L2 — les écritures lues à la frontière nymea (actionExecuted), l'onduleur
modélisé hors du moteur. Le commentaire du test §11 est réécrit comme il le
demandait.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TariffConfig::zonesCreuses() : les zones au prix minimal d'un tarif à zones
horaires dont les prix diffèrent. Aucun tarif, tarif unique ou prix tous
égaux : aucune heure creuse. Le libellé ne décide pas — « HC » n'a pas de
code, le prix se compare.
enHeuresCreuses() et prochaineBascule() lisent l'heure murale minute
absolue par minute, comme importSeries() : bascules exactes les jours de
23 h (nuit de 7 h) et de 25 h (nuit de 9 h, 02:30 deux fois creuse),
épinglées sur des époques calculées hors de Qt (zoneinfo).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deux fonctions, par la connexion de sonde :
- testAnInvalidContextIsRefusedWithItsProblems : un GetPlan de contexte invalide
({"timestamp": "valeur-sonde:7Qz9"}) → -32602 à son id, connexion gardée ; la session de sonde
jugée par le validateur publié contre le contrat EMBARQUÉ (--responses-only) : forme exigée
d'un optimiseur qui s'annonce 1.3 ou plus, AVERTISSEMENT seulement pour un 1.2 ; le contrôle
doit avoir eu lieu (GetPlan.error.data compté) ; garde indépendante : la valeur reçue n'est
pas dans error.data, quelle que soit la version.
- testTheTokenIsCheckedBeforeTheMajor : token faux et autre majeure → -32001 puis fermeture ;
-32602 d'un optimiseur 1.2 averti ; SKIP sans token attendu.
Éprouvé contre l'optimiseur de référence : 1.3 conforme (11 verts + 1 SKIP sans token, 3/3 avec
token) ; old-data annoncé 1.3 refusé, annoncé 1.2 averti ; echo-value refusé en 1.3 comme en 1.2 ;
major-first refusé en 1.3, averti en 1.2 ; référence annoncée 1.2 verte sans avertissement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tools/etm-powersync-schema-check :
- lit methods[].errors[].x-etm-data-schema : error.data d'une réponse error de ce code est jugé
contre ce schéma (audité comme les autres) ; exigé à partir de x-etm-data-required-from, la
version étant celle que l'optimiseur annonce dans SON Handshake ; en deçà, écart écrit en
AVERTISSEMENT, sans effet sur le code de sortie ; version inconnue = celle du contrat ;
- truncated n'accompagne que 50 problèmes exactement ;
- aucune valeur reçue recopiée dans error.data : écart dès 1.2 (règle de 1.2). Le contrôle ne
porte que sur les valeurs qu'un chemin conforme ne peut pas contenir — il ne peut pas accuser
un chemin conforme (domain « battery » / params.battery) ;
- --error (un objet error, avec --request et --handshake) et --responses-only (session de sonde,
requêtes fautives à dessein) ; RÉSUMÉ compte les avertissements.
Tests : forme exigée en 1.3 et avertie en 1.2 sur de vraies sessions de l'optimiseur de
référence (normal, old-data, echo-value × 1.3, 1.2), forme ligne à ligne, recopie sans faux
positif, contre-épreuve « sans x-etm-data-schema, rien n'est jugé ». Les cinq nouveaux tests
échouent avec le validateur précédent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contrat (docs/etm-powersync-optimizer-protocol.openrpc.json) :
- composants InvalidContextData, ContextProblem, ContextProblemCode : error.data du -32602 de
GetPlan = {"problems":[{path, problem}]}, 1 à 50 problèmes, truncated au-delà, chemin depuis
params (motif), nature dans une liste fermée (missing, type, range, format, enum, constraint),
formes fermées : aucune valeur reçue ne peut s'y glisser ;
- x-etm-data-schema et x-etm-data-required-from (1.3) sur cette erreur ;
- Handshake : token faux et autre majeure dans le même handshake → -32001, le token d'abord ;
- tolérance : error.data jamais lu par le moteur.
Prose (docs/OPTIMIZER_PROTOCOL.md) : v1.3, changelog §0 avec la compatibilité 1.2 ↔ 1.3, §2
(un lot reçu par le moteur reste sans réponse, à dessein), §3 (le token d'abord), §7 (forme
d'error.data, et ce que le moteur en fait : rien), annexes A, D, E, G. Blocs générés régénérés.
Générateur : un `|` dans une cellule (alternative d'un motif) est échappé ; une forme de
l'optimiseur fermée à dessein dit pourquoi (x-etm-closed-why) au lieu de « émise par le moteur ».
Test ajouté, vérifié échouant avec l'ancien générateur.
Moteur : version annoncée au handshake 1.3 (OptimizerProtocol::ProtocolVersion,
OptimizerClient::kProtocolVersion). Rien d'autre ne change dans le client. Tests qui citent la
version mis à jour (optimizerclient, socketscheduler, test du validateur).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
appendConfig() ne borne que l'entrée ajoutée, mais validateSet() (THING_SHARED) et
validateRanks() (RANK_DUPLICATE) citaient en entier les libellés des deux entrées en
conflit — dont une héritée, sans borne. provisionEvChargerConfig() journalise cette phrase.
Les libellés y passent par libellePourMotif() : 64 caractères au plus (leftChars, jamais au
milieu d'une paire), suivis de « … ». Le motif publié (faultParams) ne change pas.
Test : testInheritedLabelIsCutInSetRefusals — héritée de 300 caractères ; l'ajout d'une borne
refusé sur THING_SHARED puis sur RANK_DUPLICATE : motif exact inchangé, phrase avec les 64
premiers caractères et sans le libellé entier.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Même défaut que I-1, dans les avertissements de chargement ajoutés par Q7 : l'identifiant hors
règle et l'échéance illisible étaient cités en noquote(). Avant Q7, un client pouvait les
persister avec un saut de ligne (ni l'id ni l'échéance n'étaient bornés), et la lecture du
fichier fabriquait alors une fausse ligne de journal.
Ces valeurs passent par citee() : entre guillemets, échappées par QDebug (même rendu
qu'avant pour une valeur ordinaire). L'avertissement LIBELLÉ TROP LONG, qui cite l'identifiant
dans sa phrase, perd son noquote().
Test : testInheritedValuesAreEscapedInTheJournal charge un fichier dont l'id et l'échéance
valent "x\n[NymeaEnergy] FAUX" : les trois avertissements partent, citent la valeur échappée,
et aucun message n'ajoute de ligne commençant par [NymeaEnergy].
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le refus écrivait, en noquote(), la phrase détaillée du refus : elle cite mode, domaine,
rankOrigin, adaptateur, relays[].thingId, échéance et libellé tels que saisis. Un saut de ligne
dans l'un d'eux fabriquait une fausse ligne de journal (etm72 l'échappait par `<< why`).
Le journal ne porte plus que la phrase rendue depuis le motif (renderFr), comme SetTariff :
cause et endroit, un identifiant seulement s'il est bien formé. Échapper le détail aurait
suffi contre l'injection, pas contre le volume : relays[].thingId n'est pas borné.
La cause système d'un WRITE_FAILED, que seul le détail portait, est désormais écrite par
LoadConfigStore::commit() dans une ligne à part (chemin et erreur du fichier, aucune saisie).
Test : testSetLoadConfigRefusalIsPublished envoie dix refus dont un champ vaut
"x\n[NymeaEnergy] FAUX" et vérifie, message par message (JournalCapture::messages()), que le
refus est journalisé et qu'aucun message n'ajoute de ligne commençant par [NymeaEnergy].
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les 69 fonctions existantes rendent un enregistrement identique, octet pour
octet, à la référence précédente (inchangée depuis fae7101). Les seules
lignes ajoutées sont celles de testSetLoadConfigRefusalIsPublished et de
testAutoProvisionedLabelIsCutNeverRefused. Après régénération : check
IDENTIQUE (71 fonctions, 23 728 cycles), traces activées comprises.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Avec les traces actives, la ligne d'un cycle recopiait la requête GetPlan
même quand le client ne l'avait pas écrite (ligne de plus de 1 Mio,
request-too-long) : environ 1 Mio par cycle jusqu'au plafond journalier,
pour une requête que personne n'a reçue, et que le rejeu aurait renvoyée.
- La ligne porte alors `requestBytes` (taille de la ligne, octets) à la
place de `request` ; sa réponse reste l'erreur request-too-long. Même
règle pour la requête qui SERAIT partie sans optimiseur.
- La décision « part ou ne part pas » est celle du client :
OptimizerClient::getPlanLine(), extraite de requestPlan() sans changer
son comportement, est lue par la trace — pas une seconde estimation.
- Le commentaire « la requête RÉELLEMENT envoyée » est corrigé, la doc de
la ligne de trace (optimizertrace.h) aussi.
Preuve : testARequestNotSentIsTracedBySizeOnly (avec et sans optimiseur ;
contre-épreuve : la requête envoyée est recopiée).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testInheritedOutOfRuleConfigWhatGetPlanSends : une configuration écrite sur
disque avant la règle (identifiant « ballon test », échéances « 07:00 » et
« 7:00 ») est chargée par un store neuf et signalée. Lu sur le faux
optimiseur : l'identifiant hors règle part tel quel ; l'échéance lisible part
avec ses energyTargets (contre-épreuve) ; l'échéance illisible ne part ni
brute ni résolue, minEnergyWhPerDay part encore. La requête est jugée
conforme au contrat embarqué (LoadNeeds.dailyDeadline impose
^[0-9]{2}:[0-9]{2}$, que « 7:00 » violait).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Écart « important » de la relecture d'etm72. provisionEvChargerConfig()
prenait le nom du Thing pour libellé et réécrivait l'ensemble complet : un
nom de plus de 256 caractères, ou un libellé hérité trop long sur une AUTRE
entrée, refusait l'ajout, et la borne restait arbitrée sans rang réglable.
- Le libellé est le nom coupé à 256 points de code (LoadConfigStore::
leftChars), jamais au milieu d'une paire de substitution.
- L'ajout passe par appendConfig() : les bornes de saisie ne portent que
sur l'entrée apportée. L'écriture cliente, elle, reste refusée tant que
l'hérité n'est pas raccourci (règle d'etm72 inchangée).
- Le journal nomme la borne par ce libellé coupé.
Preuve : testAutoProvisionedLabelIsCutNeverRefused (nom de 300 caractères,
emoji en 256e position, hérité de 300 caractères sur une autre entrée).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testSetLoadConfigRefusalIsPublished : l'introspection déclare o:fault et
o:faultParams à côté d'energyError ; un succès rend toujours energyError
seul ; chacune des vingt causes atteignables rend EnergyErrorInvalidParameter,
fault LOAD_CONFIG_REFUSED et les faultParams attendus, sans rien changer à
GetLoadConfig ni au fichier, octet pour octet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le refus garde EnergyErrorInvalidParameter et gagne, comme SetTariff, un
`fault` LOAD_CONFIG_REFUSED et des `faultParams` : une cause par motif
existant (ID, LABEL, DEADLINE, MODE, DOMAIN, RANK_ORIGIN, RANK_ORIGIN_AUTO,
ADAPTER, FIELD_*, SG_READY_STATE_2, ID_DUPLICATE, THING_SHARED,
RANK_DUPLICATE, WRITE_FAILED, STORE_UNAVAILABLE) et l'endroit (index, id
quand il est bien formé, field, state, indexes/ids, rank, length/max,
position). Jamais le libellé. Les deux champs sont déclarés optionnels dans
le schéma ; un succès rend exactement ce qu'il rendait.
- id : 1 à 128 caractères de [A-Za-z0-9._{}-], refusé à l'écriture ;
hérité hors règle, chargé tel quel et signalé.
- needs.dailyDeadline : vide ou HH:MM (00:00-23:59), refusé à l'écriture ;
hérité illisible, l'entrée est chargée, l'échéance retirée de la mémoire
(ni l'arbitre ni l'optimiseur ne la reçoivent) et signalée.
- Les bornes de saisie passent avant la réconciliation de rankOrigin, dont le
motif cite le libellé.
- appendConfig() : l'ajout par le moteur ne borne que l'entrée ajoutée.
- leftChars() coupe en caractères sans couper une paire de substitution ;
l'id d'un motif n'est plus coupé par QString::left().
- Au chargement, chaque libellé trop long est signalé, pas seulement le
premier ; loadconfigstore.h dit « n'écarte rien au chargement ».
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
testTheSessionMatchesTheContractOffUtc : le moteur sous Europe/Berlin,
cadencé en heure locale comme en production, du 2026-10-25 02:58 CEST au
retour à 02:00 CET. Aucun échec de requête, et la session passe
tools/etm-powersync-schema-check --semantic contre le contrat embarqué.
Contre-épreuve, correctif retiré : 8 rpc-error (le constat VM), et le
validateur seul refuse chaque params.timestamp sur son motif `pattern`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Constat VM du 2026-10-21 (Europe/Berlin) : l'optimiseur conforme refusait
chaque GetPlan, -32602 sur params.timestamp. `instant()` écrivait
toString(Qt::ISODate), qui n'émet aucun décalage pour une heure locale —
celle de currentDateTime(), donc de ctx.timestamp en production. Les
goldens, construits en UTC ou à décalage fixe, ne pouvaient pas le voir.
Le décalage de l'instant reçu est désormais rendu explicite : une heure
locale garde l'heure du site (+02:00), une heure UTC reste en Z. Il est lu
sur l'instant, donc 02:30 la nuit du retour à l'heure d'hiver sort +02:00
puis +01:00. Goldens inchangés.
Tests (loadmodel) : cinq fuseaux dont un négatif et un à la demi-heure,
été et hiver, tous les instants du contexte ; la nuit des deux changements
d'heure, minute par minute. Vérifiés échouant sans le correctif.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le libellé part tel quel dans chaque GetPlan. Rien ne le bornait : une saisie de plus de
1 Mio suffisait à faire dépasser la limite de ligne du protocole. La borne arrête la
saisie en amont ; le refus d'émission du client (commit précédent) reste le filet.
- LoadConfigStore::validateLabels(), appelée en tête de setConfigs() : un libellé de plus
de 256 points de code Unicode → refus en bloc, rien n'est modifié ; SetLoadConfig rend
EnergyErrorInvalidParameter et journalise le motif en français, qui nomme la charge par
son id et donne la longueur, jamais le libellé. Placée AVANT isValid() parce que les
motifs suivants citent le libellé.
- Même partage que les rangs (LM-1209-a-bis) : load() ne l'applique pas. Un libellé plus
long déjà persisté est chargé tel quel, ni tronqué ni écarté, et signalé ; la première
écriture devra le raccourcir.
- Test : testLabelIsBoundedOnWriteNeverOnLoad (256 accepté, 257 refusé sans modification
en mémoire ni sur disque, configuration héritée conservée entière).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ferme l'écart Q7 trouvé au lot protocole 1.2. Une requête GetPlan dont la ligne
dépasserait maxLineBytes n'est plus écrite sur le socket : OptimizerClient::requestPlan()
sérialise d'abord, rend l'identifiant, puis émet planFailed(id, "request-too-long") au
tour de boucle suivant. L'échec compte (règle des échecs consécutifs, §7), la connexion
est conservée, et le journal le dit une fois par connexion, avec la taille, jamais le
contenu. Avant : la ligne partait, l'optimiseur la jetait, et la requête finissait en
délai dépassé sans que la cause se voie.
Le handshake n'est pas contrôlé : sa ligne est bornée par construction (token de 4 096
octets au plus, 24 Kio une fois échappé).
- knownErrorCodes() : + request-too-long ; LastErrorCode du contrat régénéré
(--enums-from), blocs générés de la prose régénérés.
- OPTIMIZER_PROTOCOL.md §0/§2 et x-etm-transport : l'écart connu devient la règle tenue.
Pas de changement de version.
- Tests : testARequestOverTheLineLimitIsNeverSent remplace le XFAIL (aucun octet émis,
limite exacte éprouvée des deux côtés), testARequestTooLongIsLoggedOncePerConnection,
testARequestTooLongCountsAsAFailure (socketscheduler).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
