etm-powersync-energy-plugin-etm/docs/DESIGN_HC_BATTERIE.md

Heures creuses pour la borne, batterie protégée pendant sa charge — lot e1 (2026-10-24)

Décisions de Patrick du 2026-10-24. Ce document décrit ce que le code fait, les preuves qui le rejouent, et ce qu'il ne fait pas. Code : etm/tariff/tariffconfig.*, etm/scheduler/rulebasedscheduler.cpp, etm/adapters/storagedischargeguard.*, etm/energyarbitrator.cpp (buildContext, update, applyDegradedMode).

1. Les heures creuses

Règle : les heures creuses sont la ou les zones au prix le plus bas d'un tarif à zones horaires (tou) dont les prix diffèrent (TariffConfig::zonesCreuses()).

• « HC » n'a pas de code : le libellé est une donnée de l'installateur. Le prix se compare.
• Plusieurs zones au même prix minimal sont toutes creuses (une nuit et un début d'après-midi saisis comme deux zones).
• Aucune heure creuse sans tarif, avec un tarif unique (fixed), ou avec des zones toutes au même prix. Dans ces trois cas rien de ce lot ne s'exécute : le moteur est celui d'etm74 (preuve decisions IDENTIQUE, et testWithoutOffPeakTheEngineIsEtm74).
• Lecture murale, minute absolue par minute (enHeuresCreuses(), prochaineBascule()), dans le fuseau de la box relu à chaque cycle. Les jours de 23 h et de 25 h sont exacts (nuit 22:00-06:00 de 7 h et de 9 h), épinglés sur des époques calculées hors de Qt.
• Le prix n'est toujours lu par aucune décision, et SurplusContext::tariff n'est toujours pas rempli : l'optimiseur ne reçoit rien de neuf. Les heures creuses vivent dans SurplusContext::offPeak, interne au moteur.

2. La borne : surplus le jour, complément en heures creuses

Modes concernés — ChargingModeEcoWithMinCurrent, ChargingModeEcoMinWithTargetTime, ChargingModeEcoWithTargetTime : ceux dont le besoin réseau peut attendre. EvAdapter le DÉCLARE (LoadNeeds::offPeakShift, offPeakMinPowerW = le plafond de cycle de la borne depuis le lot e2, son plancher au lot e1 — §8, D7), le scheduler le DÉCIDE (règle 2). ChargingModeEco ne demande jamais le réseau, ChargingModeNormal est piloté par l'utilisateur : tous deux sont inchangés.

	hors heures creuses	en heures creuses
minimum réseau (minPowerWAlways)	retiré — surplus seulement	le plafond de la borne (lot e2, §8 D7)
démarrage sous tolérance (EV_GRID_START)	refusé (le minimum par une autre porte)	inchangé
motif d'une consigne nulle	EV_WAITING_OFF_PEAK {at, startsAt, budgetW}	motifs ordinaires
motif de la consigne servie	—	EV_OFF_PEAK_FULL_POWER (lot e2, §8 D7)
échéance (EV_DEADLINE, proxy)	inchangée	inchangée

Le changement de comportement : une borne « Éco avec minimum » ne prend plus ses 6 A au réseau le soir. Elle charge au surplus tant qu'il y en a, puis attend 22:00. Le motif le dit : « Borne attend les heures creuses (22:00) — hors heures creuses, surplus seulement (… W) ». EV_WAITING_OFF_PEAK remplace SURPLUS_INSUFFICIENT, BELOW_MIN_POWER et BATTERY_RESERVE, parce que la cause de la consigne nulle n'est plus le manque de surplus. Le plafond de soutirage (DRAW_CAP), le refus (RECREDIT_SUSPENDED), la limite de phase, l'indisponibilité et les verrous gardent la tête : ils diraient la même chose en heures creuses.

En heures creuses, le plancher est servi au réseau par la passe éco (ECO_FLOOR_GRID), bornée par l'autorisation de soutirage ; le confort ajoute le surplus s'il y en a. Lot e2 : c'est désormais le plafond, sous EV_OFF_PEAK_FULL_POWER — §8, D7. La borne déclare un plafond écrêté par evPhaseAllowanceW() — en heures creuses par evOffPeakAllowanceW(), qui lui rend son courant mesuré moins 1 A (§8.2, D8) —, et verifyOverloadProtection() garde le dernier mot : l'invariant 2 tient sans rien ajouter.

L'échéance : la puissance nécessaire pour tenir une échéance reste celle du proxy amont, qui force la charge à pleine puissance au point de non-retour. Ce point est calculé sur l'échéance, pas sur la fin des heures creuses : une échéance trop proche peut donc encore se servir en heures pleines. Une échéance est une promesse de l'utilisateur, le tarif ne la rompt pas. Étaler la charge sur les heures creuses demanderait une énergie restante mesurée (LM-1009) : ce sera un lot à part (§8, D3).

Le refus d'EV_GRID_START hors heures creuses est confirmé (§8, D2) : seul le mode boost (ChargingModeNormal) charge tout de suite.

À 06:00, le minimum est retiré : une borne qui charge encore s'arrête (au premier cycle où son verrou d'enclenchement le permet, 300 s par défaut).

3. La batterie : décharge bloquée pendant la charge de la voiture en heures creuses

3.1 Ce que le modèle SunSpec 124 dit — et ce que le plugin écrit

Lu dans le plugin sunspec (integrationpluginsunspec.cpp, sunspecstoragelogic.*, froniusrules.*) et dans la définition du modèle 124 de libnymea-sunspec :

• StorCtl_Mod est un champ de bits — « Activate hold/discharge/charge storage control mode » : bit 0 CHARGE, bit 1 DiSCHARGE. Le bit active la limite correspondante, il n'« autorise » pas l'opération.
• OutWRte est la limite de décharge, en pourcentage de la puissance maximale (% WDisChaMax dans le modèle, « % de WChaMax » dans la documentation du plugin). 0 % vaut 0 W quelle que soit la référence : l'unité n'a pas d'incidence sur la valeur écrite ici, ni le facteur d'échelle InOutWRte_SF (que le plugin relit avant chaque écriture, AC-12).
• L'état enableDischarging du plugin est ce bit (readStates()), et l'action le pose par lecture-modification-écriture de StorCtl_Mod. L'état dischargingRate est OutWRte.
• Le contrat du plugin (AC-11, FroniusRules::planBatteryMode()) le confirme : NO_DISCHARGE = StorCtl_Mod = 2, OutWRte = 0 ; NORMAL = StorCtl_Mod = 0, OutWRte = 100.

Donc enableDischarging = false LÈVE la limite — il ne bloque rien. La séquence qui bloque réellement la décharge est dischargingRate = 0, puis enableDischarging = true. Le retour à l'automatisme est enableDischarging = false, puis dischargingRate = 100 (le maximum de l'état).

Le plugin permet de l'écrire, en deux actions. Chacune est un plan d'écriture complet (ordre imposé, relecture, minuteur de retour réarmé en dernier). Elles ne sont pas atomiques : le garde les enchaîne (la seconde part à la confirmation de la première), dans l'ordre qui rend chaque état intermédiaire sûr :

• pose : le taux d'abord. Tant que la limite est inactive, le taux est inerte ; quand elle s'active, il vaut déjà 0. Si la première écriture échoue, la seconde ne part pas — la limite reste inactive, la batterie en automatique ;
• levée : la limite d'abord, l'automatisme revient tout de suite ; le taux est remis au maximum pour qu'une limite réactivée plus tard ne reparte pas à 0 %.

FroniusRules::planBatteryMode(NO_DISCHARGE) écrirait les deux registres en une séquence, mais aucune action du plugin ne l'emprunte. L'exposer est décidé, dans le dépôt du plugin (§8, D6) ; le garde reste compatible avec les deux actions actuelles.

3.2 Quand

Heure creuse ET bornes qui tirent réellement ≥ 230 W (mesuré, toutes bornes, mode manuel compris) ET au moins une batterie pilotable. Sinon la batterie est rendue à son automatisme, et une consigne tenue est levée explicitement. La décision est prise par le rule-based à chaque cycle (RuleBasedScheduler::storageDecision()), y compris en ombre d'un optimiseur.

La batterie est bloquée au cycle où la voiture tire : au cycle de 22:00 la borne vient d'être commandée et lit encore 0 W, le blocage part à 22:01. Elle est rendue au cycle où la borne ne tire plus (fin de charge) ou à 06:00.

Ce que le blocage bloque : toute décharge, maison comprise. « Ne pas se décharger dans la voiture » ne s'exprime pas autrement sans asservir OutWRte à la consommation de la maison — une boucle de régulation que le lot ne fait pas. C'est le geste voulu (§8, D1), comme le blocage par une borne en mode boost (D4) et le seuil de 230 W (D5).

3.3 Pilotable, ou non

Par l'interface energystorage et les états présents — aucune ThingClass n'est nommée (StorageDischargeGuard::capacite(), question posée à la classe) :

cause	condition	effet
—	enableDischarging (booléen) et dischargingRate (0 admis) modifiables, revertTime ≥ 120 s	commandée
noDischargeControl	un des deux états absent ou non modifiable	lue comme avant, STORAGE_NOT_PROTECTED
noRevertTimer	pas de paramètre revertTime, ou 0	idem — un moteur arrêté la laisserait bloquée sans fin
revertTimerTooShort	revertTime < 120 s	idem — elle expirerait entre deux cycles

3.4 Le minuteur et le rafraîchissement

Chaque écriture du plugin se termine par InOutWRte_RvrtTms = revertTime (300 s sous Fronius, FroniusRules::DefaultRevertTimeSeconds). Le garde réécrit la séquence dès que la dernière a le tiers du minuteur (100 s) : à un cycle par minute, deux écritures sont espacées de 120 s, 180 s si un cycle manque — toujours sous 300 s. Il la réécrit aussi, sans attendre, si la batterie ne rapporte plus la limite (onduleur revenu seul à l'automatisme).

La sûreté est le minuteur, pas le moteur : si nymead s'arrête, plus rien ne réécrit, et le GEN24 reprend son automatisme au plus 300 s après la dernière écriture. Sous compteur muet (L2), le garde lève la limite explicitement. Au redémarrage, une limite à 0 % trouvée active est reprise (rafraîchie ou levée).

⚠️ Hypothèse non levée, et elle est du plugin : la sémantique du minuteur est documentée par le constructeur au chapitre général et illustrée sur le modèle 123, pas sur le 124 (AC-10 du plugin, « décision D4 non validée »). Les tests la modélisent ; seule une mesure sur un GEN24 réel la prouve.

3.4 bis Un onduleur qui refuse (suite du lot e1)

Un GEN24 dont « Allow Control » est désactivé répond 0x04 à toute écriture. Avant cette suite, la batterie ne rapportant jamais la limite, le garde reposait la séquence à chaque cycle, avec un qCWarning à chaque fois, toute la nuit.

• Espacement : 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, à compter de la pose refusée, avec une marge de 5 s pour la gigue d'un cycle par minute. Quinze minutes au plus : un réglage corrigé en cours de nuit est repris dans le quart d'heure.
• Fin de série : à la première séquence acceptée jusqu'au bout (taux puis limite), le rythme normal reprend (tiers du minuteur) ; ou à la levée, qui clôt la série — la pose suivante est une consigne neuve.
• La levée n'est jamais espacée : rendre l'automatisme part au cycle même où la décision tombe, série en cours ou non. Elle n'est pas répétée si elle est refusée (le minuteur de l'onduleur la fera) ; son refus reste un qCWarning.
• Journal : un seul qCWarning par série (« … REFUSÉE (…) : la décharge n'est PAS bloquée … »), les refus suivants et les nouvelles tentatives en qCDebug, et un qCInfo à l'acceptation qui clôt la série (« … ACCEPTÉE après N refus »).
• Télémétrie : pendant une série, held est faux — et dischargeBlocked avec lui — et la batterie publie refusedWrites (poses refusées d'affilée), refusedSince et nextAttemptAt. La décision reste STORAGE_DISCHARGE_BLOCKED : c'est ce que le moteur a décidé, l'exécution est ce qui échoue.

Pourquoi held faux plutôt que held vrai plus un drapeau : held et dischargeBlocked sont lus comme « la batterie ne se décharge pas ». Un client qui ignore un champ nouveau — c'est-à-dire tous les clients d'aujourd'hui — continuerait d'afficher une protection qui n'existe pas. Avec held faux, le client existant dit vrai sans changement, et le client à jour lit en plus pourquoi et jusqu'à quand. Le passage de dischargeBlocked à faux notifie, ce qu'un drapeau à côté n'aurait pas fait. Un refus se lit au cycle suivant la pose : le verdict de l'onduleur arrive après la publication du cycle qui a écrit, comme observed.

3.5 Sécurité et invariant 8 (« pas de boucle »)

La décision ne lit ni le budget ni la réserve, et n'y verse rien. Le budget reste compteur + PV mesurés. Les règles de réserve (rulebasedscheduler.cpp, « Prise en compte du stockage ») restent justes sous blocage :

• la nuit, batterie bloquée et sans PV : powerW ≈ 0, aucune branche ne modifie le budget, qui vaut −(import). Le blocage augmente l'import, le budget le constate : aucun surplus n'est fabriqué (testBlockedDischargeShowsAtTheMeterAndL4Decides, surplusW == −import) ;
• sous la réserve, le surplus positif est annulé : il n'y en a pas la nuit, la règle est sans effet ;
• au-dessus de la réserve et en charge (PV avant 06:00 l'été) : la charge de la batterie est rendue au budget. C'est vrai sous blocage aussi : bloquer la décharge ne touche pas la charge, et le GEN24 réduit sa charge pour couvrir une consommation nouvelle — ce qu'il ne peut plus couvrir vient alors du réseau, pas de la batterie, et le compteur le montre au cycle suivant ;
• en décharge (powerW < 0, si l'onduleur ignorait la consigne) : retranchée, comme avant — le sens prudent.

Le soutirage ajouté — ce que la batterie couvrait passe au réseau — se mesure au cycle suivant : la marge de soutirage du contexte (houseDrawMargin()) et verifyOverloadProtection() le lisent au compteur, et coupent la borne s'il dépasse (éprouvé avec une limite de 25 A). La borne coupée ne tire plus : la batterie est rendue au cycle d'après.

Oscillation possible, signalée : sur une installation au bord de sa limite de phase, la suite « bloquer → la phase dépasse → L4 coupe la borne → rendre → la batterie couvre → la borne redémarre » peut se répéter. Sa période est bornée par le verrou d'enclenchement de la borne (300 s), et L4 tient la sécurité à chaque tour.

Hystérésis de la réserve de 20 % : non touchée. Effet indirect seulement : la batterie ne se vide plus dans la voiture la nuit, elle passe plus souvent la réserve le matin.

4. Ce qui est publié

• Journal : [Arbitre] Batterie → Décharge de la batterie bloquée : la voiture charge en heures creuses (1380 W, jusqu'à 06:00), à chaque cycle où la question se pose ; [Batterie] … décharge BLOQUÉE et … RENDUE à l'automatisme aux transitions (qCInfo), le rafraîchissement en qCDebug, un refus d'écriture en qCWarning (règle 7-d) — une fois par série de refus pour la pose (§3.4 bis).
• Télémétrie (GetLoadTelemetry et LoadTelemetryChanged, même charge utile) : un bloc storage, absent sans heure creuse ou sans batterie — dischargeBlocked (ce que le moteur TIENT après le dispatch), decision {code, params}, et batteries[] avec ce qui est LU (observed.enableDischarging, observed.dischargingRate) ; pendant une série de refus, held faux et refusedWrites, refusedSince, nextAttemptAt. Une transition du bloc notifie.
• Motifs : EV_WAITING_OFF_PEAK, STORAGE_DISCHARGE_BLOCKED, STORAGE_AUTOMATIC (peak | evNotCharging | degraded), STORAGE_NOT_PROTECTED. Aucun n'est émissible par un optimiseur.
• Aucun flux sortant nouveau (invariant 10) : le garde parle au ThingManager, comme tous les adaptateurs.

5. Jamais

gridCharging, enableCharging, chargingRate ne sont jamais écrits, ni un dischargingRate négatif (charge forcée). La recharge de la batterie sur le réseau est l'offre Pro. Le test de la journée le vérifie sur toutes les écritures exécutées, et la contre-épreuve qui écrit gridCharging le fait rougir.

6. Preuves

Preuve	Ce qu'elle rejoue
testOffPeakIsTheCheapestZone (loadmodel)	la règle ; aucun / unique / prix égaux ; jours de 23 et 25 h
testOffPeakDemoDay	12 h, attente à 18 h, refus d'EV_GRID_START, reprise à 22:00, blocage à 22:01, minuteur tenu 88 cycles, levée à la fin de charge, aucune écriture interdite
testOffPeakEndsAtSixAndOnDstDays	arrêt et levée à 06:00, jours de 23, 24 et 25 h
testWithoutOffPeakTheEngineIsEtm74	trois formes sans heure creuse : minimum à 18 h, ni bloc ni écriture, trames identiques
testABatteryWithoutControlIsReadAsBefore	sans états, sans minuteur, absente
testBlockedDischargeShowsAtTheMeterAndL4Decides	invariant 8, soutirage mesuré, L4 coupe, levée
testAMeterSilenceHandsTheBatteryBack	L2 lève explicitement
testRefusedWritesAreSpacedAndNeverDelayTheRelease	onduleur qui refuse : poses à 0, 1, 3, 8, 18, 33, 48 min, un avertissement par série, held faux ; acceptation → rythme normal ; levée immédiate en pleine série, qui clôt la série
decisions	IDENTIQUE à la référence sans tarif

Les écritures sont lues à la frontière nymea (ThingManager::actionExecuted), et le GEN24 est modélisé dans le test (limiteTenue()), jamais dans le moteur ni dans le mock.

7. Ce que ce lot ne fait pas

• La recharge de la batterie sur le réseau ; toute optimisation par le prix (offre Pro).
• L'étalement d'une échéance sur les heures creuses (§2) — lot à part (§8, D3).
• Une action atomique « limite de décharge » dans le plugin (planBatteryMode(NO_DISCHARGE) existe et n'est pas exposée), et un état au nom moins trompeur que enableDischarging — décidés, faits dans le dépôt du plugin (§8, D6).
• La batterie comme charge rangée du waterfall (lot 3f, spec_loadmodel.md §14).

8. Décisions de Patrick (2026-10-24)

Les questions ouvertes du lot e1 sont tranchées. Chacune confirme le comportement décrit plus haut : aucune ne change le code.

#	Question	Décision du 2026-10-24
D1	Bloquer toute la décharge, maison comprise, pendant la charge de la voiture en heures creuses (§3.2) ?	Oui. C'est le geste voulu ; aucune régulation de OutWRte sur la consommation de la maison.
D2	Refuser EV_GRID_START hors heures creuses pour les trois modes concernés (§2) ?	Confirmé. En mode Éco, la borne attend les heures creuses ; seul le mode boost (ChargingModeNormal, piloté par l'utilisateur) charge tout de suite.
D3	Étaler une échéance sur les heures creuses (§2) ?	Plus tard, lot à part. Il demande une énergie restante mesurée (LM-1009).
D4	Une borne en ChargingModeNormal qui charge en heures creuses déclenche-t-elle le blocage (§3.2) ?	Oui, c'est le but : la mesure porte sur toutes les bornes, mode compris.
D5	Seuil de « la voiture charge réellement » : 230 W sur la somme des bornes (§3.2) ?	Accepté.
D6	Plugin SunSpec : une action « limite de décharge » en une séquence (planBatteryMode(NO_DISCHARGE)), et enableDischarging renommé ou redécrit (§3.1, §7) ?	Oui aux deux, dans le dépôt du plugin, à la charge de l'orchestrateur. Le garde ne change pas : il reste compatible avec les deux actions actuelles (dischargingRate puis enableDischarging).
D7	À quelle puissance la borne charge-t-elle en heures creuses (lot e2) ?	À la pleine puissance permise, et non plus au plancher. La session finit plus tôt, et la décharge de la batterie n'est bloquée que pendant ce temps-là : ensuite, elle couvre la maison pour le reste de la nuit. Détail en §8.1.
D8	(2026-10-25) Près de la limite de phase, la consigne de la borne alterne à chaque cycle (16, 7, 16, 7 A sous 25 A). Corriger avant la démo ?	Oui, maintenant. En heures creuses, le plafond de la borne lui rend ce qu'elle tire, mesuré, moins 1 A par phase. Détail en §8.2. Le même jour : la borne tenue au plancher en surcharge (L4 décide de couper) est confirmée ; les écarts 3 et 4 de §8.1 sont reportés.
D9	(2026-10-25, suite) L'écart 4 n'est pas qu'un défaut de publication : à l'aube, le surplus s'ajoute au plafond, qui porte la limite de phase. Borner la somme avant la démo ?	Oui, avant la démo. La somme éco + confort ne dépasse jamais declared.maxPowerW, et l'achat publié ne dépasse pas ce qui est réellement acheté. Détail en §8.3. La dérogation sans heure creuse, les phases étiquetées : plus tard, chacune dans son lot. Le compteur en retard sur la borne est accepté tel quel.

La mesure du minuteur de retour sur un vrai GEN24 (hypothèse AC-10 du plugin, §3.4) reste ouverte : elle relève du plugin et d'un essai sur matériel réel.

8.1 D7 — pleine puissance en heures creuses (lot e2)

Pourquoi. Au plancher (6 A, 1,4 kW en monophasé), une nuit de 22:00 à 06:00 livre au plus 11 kWh : une session de 10 à 25 kWh n'est pas finie au départ. Et la décharge de la batterie reste bloquée toute la nuit, puisque la voiture charge toute la nuit : la batterie est encore pleine le matin, et le surplus solaire part au réseau.

La règle. Dans les trois modes qui reportent en heures creuses (§2), le minimum servi au réseau en heures creuses est le plafond de cycle de la borne (declared.maxPowerW) :

• il porte le courant maximal de la borne, ses phases, et la limite de phase (evPhaseAllowanceW() ; depuis D8, evOffPeakAllowanceW(), §8.2) — rien n'est retiré de ces écrêtages ;
• il ne descend jamais sous le plancher : la limite de phase rabaisse la borne, elle ne la coupe pas ; couper reste le geste de verifyOverloadProtection() (L4), qui garde le dernier mot ;
• hors heures creuses, et sans heure creuse dans le tarif, rien ne change.

Par exemple : 3 680 W en monophasé 16 A, 11 040 W en triphasé 16 A.

Les phases. En heures creuses, une borne qui peut charger en triphasé charge en triphasé. La règle de bascule du manager est inchangée ; c'est le courant qu'on lui présente qui change. Hors heures creuses, c'est « courant de la borne + surplus ». En heures creuses, c'est la pleine puissance de la borne. Raison : la nuit, « courant + surplus » bride dans un cas précis — une batterie (non pilotable, ou pas encore bloquée) couvre la maison et la voiture, le compteur lit ≈ 0, et la référence vaut le courant que la borne tire déjà. À 6 A en monophasé, la règle garde le monophasé : 3,7 kW au lieu de 11. La limite de phase n'entre pas dans le choix, et c'est sans perte : par phase, elle borne pareil une monophasée et une triphasée, donc trois phases donnent toujours au moins autant.

Sécurité. Le plafond d'une borne porte déjà l'autorisation de soutirage, résolue sur les phases qu'elle occupe et multipliée par leur nombre. La passe éco ne lui oppose donc pas en plus la marge d'une phase de la maison (LM-1500-h, déjà appliquée en tête de passe et en passe confort). Sans cela, une triphasée serait servie à 7 A au lieu de 16. Une autre charge allumée la nuit réduit le plafond au cycle suivant ; sous le plancher, la borne est tenue au plancher, et L4 coupe au dépassement. Cette exemption ne vaut qu'en heures creuses : sans heure creuse, le plancher éco d'une borne reste écrêté par la marge de la maison, comme avant.

Surcharge au plancher — confirmé le 2026-10-25. En heures creuses, quand la limite de phase ne laisse plus le plancher, la stratégie tient la borne à son plancher (boundBy: floor) et L4 décide de la couper, comme pour la dérogation. On n'est pas revenu au « rien acheté » du lot e1.

Écarts ouverts (rien n'est changé ; décision du 2026-10-25 : plus tard, chacun dans son lot) :

• Écart 3 — le double écrêtage hors heures creuses. Sans heure creuse, le plancher éco d'une borne triphasée est encore comparé à la marge d'une phase de la maison (le double écrêtage que LM-1500-h refuse ailleurs). L'étendre changerait des décisions sans tarif : lot à part.
• Écart 4 — le partage achat/surplus en heures creuses. Corrigé pour la pleine puissance d'heures creuses (D9, §8.3). À l'aube, le surplus s'ajoutait au niveau éco : la consigne (estimatedPowerW) pouvait dépasser le plafond de cycle, et donc la limite de phase qu'il porte. La dérogation, elle, ne cumule pas (sa passe confort est sautée) ; son achat publié reste entier quand le soleil la finance en partie — c'est la conséquence comptable déjà écrite dans le code, et elle reste à reprendre avec la dérogation.
• L'oscillation près de la limite de phase était le troisième point de cette liste. Elle est corrigée : §8.2.

Fin de session. Le blocage de la décharge se lève sur la puissance mesurée des bornes, au seuil de 230 W (D5). Une borne commandée à 16 A dont la voiture ne prend plus rien (pleine, ou session arrêtée par le véhicule) ne tient donc pas la batterie bloquée.

Motif. EV_OFF_PEAK_FULL_POWER {gridW, maxW, phases, until, endsAt, o:boundBy} remplace, en heures creuses, ECO_FLOOR_GRID sur la borne. gridW est la puissance retenue, maxW la pleine puissance du matériel aux phases visées. boundBy n'est présent que si la protection de surcharge l'a rabaissée : phaseLimit (à ce que la limite laisse) ou floor (tenue au plancher, L4 décide de la suite). Rendu : « Borne charge à pleine puissance en heures creuses : 11040 W achetés au réseau (3 phases, jusqu'à 06:00) ».

Preuves. testOffPeakChargesAtFullPower, testOffPeakFullPowerSwitchesToThreePhases, testOffPeakFullPowerYieldsToThePhaseLimit ; les tests du lot e1 en heures creuses attendent désormais le plafond. Sans heure creuse, la preuve decisions est identique.

Lot futur, non implémenté — réserver seulement ce dont la maison a besoin jusqu'au soleil, d'après la prévision. Aujourd'hui la décharge est bloquée entière tant que la voiture charge (D1). Une version plus fine laisserait la batterie se décharger dans la voiture au-delà de ce que la maison consommera d'ici le retour du soleil — consommation de base prévue (BaseloadLog) et heure de la première production utile (prévision PV). Elle demande une prévision fiable des deux, et un pilotage de OutWRte plus fin qu'un tout-ou-rien : c'est un lot à part.

8.2 D8 — près de la limite de phase, la consigne se pose (2026-10-25)

Le défaut. Le plafond d'une borne était la place libre au compteur, sans lui rendre ce qu'elle tire (evPhaseAllowanceW()). Avec un compteur qui voit la borne, sa propre consommation lui retirait la place au cycle suivant, puis la lui rendait au cycle d'après. Mesuré en simulation, maison à 2 A par phase, borne 16 A, mono comme tri :

Limite	Avant (consigne cycle par cycle)	Après
25 A	16, 7, 16, 7… (11,5 A en moyenne)	16 A tenus
32 A	16, 14, 16, 14…	16 A tenus
16 A	14, 6, 8, 6, 8… (7 A en moyenne)	13 A tenus, 15 A au compteur

La règle. En heures creuses, et pour la pleine puissance du lot e2 seulement, le plafond est lu par EnergyArbitrator::evOffPeakAllowanceW() :

plafond par phase = limite − (tirage de la phase − courant mesuré de la borne) − 1 A, arrondi à l'ampère inférieur, × phases.

C'est la règle de l'échéance chez l'amont (adjustEvChargers()). Elle converge en un cycle : le résultat ne dépend plus de ce que la borne tirait, seulement de ce que tire le reste de la maison.

• Mesure, pas consigne. Le courant rendu est l'état currentPower de la borne, sur les phases où elle le mesure. Une voiture qui prend 10 A d'une borne commandée à 16 n'occupe que 10 A : lui rendre 16 lui ouvrirait 6 A de trop. Une borne sans mesure, à l'arrêt, ou qui bascule de phases (mesurées ≠ visées) ne rend rien, et la marge s'applique quand même.
• La marge : 1 A par phase. C'est celle de l'amont, pour la même raison : laisser à un appareil moyen allumé entre deux cycles la place de démarrer avant que L4 ait à couper. Elle couvre aussi l'écart entre la puissance annoncée par la borne et le courant lu au compteur (tension ≠ 230 V, ±3 % à 16 A, soit 0,5 A). L'arrondi à l'ampère inférieur garantit qu'elle n'est pas mangée par l'adaptateur, qui arrondit la consigne au plus proche. Plus grande, elle coûterait 230 W par phase toute la nuit, sans raison mesurée ; plus petite, elle ne couvrirait plus l'écart de mesure.
• La sécurité en dépassement tient. C'était la raison de ne rien rendre. Si une phase tire I > limite, dont E pour la borne, la place rendue vaut limite − (I − E) − 1 < E − 1 : la consigne baisse d'au moins 1 A par cycle, jusqu'à sortir du dépassement ou jusqu'au plancher, où la stratégie tient la borne et où L4 décide. Cela suppose que le compteur voie la borne — ce que L4 suppose déjà.
• Un compteur qui ne voit pas la borne ne la mène pas seule à la limite : le tirage de la maison sans la borne est écrêté à zéro, donc une phase vaut au plus sa limite moins la marge.
• Où. Seulement là où EvAdapter vise la pleine puissance d'heures creuses (trois modes, heure creuse en cours). Hors heures creuses et sans tarif, evPhaseAllowanceW() reste la règle, et les décisions sans tarif ne changent pas. En heures creuses, une dérogation sur la borne lit le même plafond (c'est le même declared.maxPowerW). Sans heure creuse, la dérogation garde l'ancienne règle : la faire passer par la même voie changerait son comportement sans tarif, et ce n'est pas décidé.

Hypothèses. Les phases de la borne sont celles du compteur (même hypothèse que L4 et que l'amont). Une borne qui annonce plus que ce que le compteur voit d'elle reçoit au plus 1 A sous la limite. Un compteur rafraîchi après la borne (borne qui monte, compteur pas encore) peut surestimer la place d'un cycle, dans la même limite ; L4, lui, lit le compteur en temps réel.

Preuves. testOffPeakFullPowerSettlesUnderThePhaseLimit (sept cas, douze cycles : la consigne se pose dès le premier cycle, la phase la plus chargée reste à 1 A au moins sous la limite ; un cas à 2,4 A de maison prouve l'arrondi) ; testOffPeakFullPowerYieldsToThePhaseLimit, réécrit avec un compteur qui voit la borne (mesure et non consigne, dépassement, plancher, coupure par L4) ; testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter (écrêtage à zéro) ; testOverloadProtectionEcoMode, hors heures creuses, inchangé. Dans testBlockedDischargeShowsAtTheMeterAndL4Decides, la borne en dépassement finit à son plancher (L4 la ramène de 16 à 13 A, la stratégie laisse 9 A, L4 la ramène à 6 A) au lieu d'être coupée : l'assertion attend désormais « plancher ou coupée ».

8.3 D9 — la somme éco + confort tient dans le plafond (2026-10-25, suite)

Le défaut (écart 4). En heures creuses, le niveau éco d'une borne vaut son plafond de cycle (declared.maxPowerW), 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. Mesuré en simulation : borne monophasée sur A, limite 16 A, maison à 2 A sur A, phases B et C exportant 1 500 W chacune. Le plafond vaut 13 A ; la consigne montait à 16 A, et la phase A à 18 A pour 16. Le partage publiait 2 990 W achetés quand le compteur n'en importait que 450.

La règle. Pour une borne servie à pleine puissance en heures creuses (EV_OFF_PEAK_FULL_POWER) :

• la passe confort sert le surplus dans le plafond, et non par-dessus ;
• l'achat cède ce que le surplus finance : achat = plafond − part confort, jamais négatif. La somme reste donc le plafond, et l'achat publié (gridW, draw.committedW, counts) est ce qui reste à acheter ;
• la part confort n'a pas de plancher : le plancher porte sur la somme, qui vaut le plafond, donc jamais moins que lui. Sans cela, un surplus sous le plancher serait refusé, ou démarré par EV_GRID_START — un second achat en plus du premier.

Le motif suit la règle de la part majoritaire : à l'aube, quand le surplus finance plus de la moitié du plafond, la décision publiée est celle du confort ; le niveau éco reste lisible dans levels. La marge de soutirage du reste de la cascade est décomptée comme avant (prudence inchangée). Hors heures creuses et sans tarif, rien ne change : la règle ne s'applique qu'aux bornes qui portent EV_OFF_PEAK_FULL_POWER.

Cas (simulation)	Avant	Après
Aube, 2 540 W de surplus	16 A, phase A à 18 A ; 2 990 W achetés	13 A, phase A à 15 A ; 450 W achetés, 2 540 W de surplus
Plein soleil, surplus > plafond	16 A	13 A ; 0 W acheté, 2 990 W de surplus
Nuit	13 A ; 2 990 W achetés	inchangé
Compteur aveugle aussi au total	13, 16, 16… A	13, 15, 15… A

Avec un compteur aveugle au total, le surplus est fabriqué par le recrédit : la consigne tient le plafond, mais le partage publié, lui, ne peut pas être juste — le compteur ne dit pas ce qui est acheté.

Preuves. testOffPeakFullPowerAtDawnStaysInTheCeiling (nuit, aube, plein soleil, quatre cycles chacun : consigne et phase, somme, achat ≤ import du compteur) ; testOffPeakFullPowerStaysUnderTheLimitOnABlindMeter, étendu au total aveugle. La garde de bascule de §8.2 est désormais éprouvée : testOffPeakFullPowerGivesNothingBackWhileSwitchingPhases (borne en monophasé à 10 A qui bascule en triphasé, maison à 12 A sur B, limite 25 A : 12 A, et B à 24 A ; sans la garde, 15 A et B à 27 A).