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 plancher de la borne), 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 plancher de la borne, au moins
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
é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. La borne déclare un plafond écrêté par evPhaseAllowanceW(), 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).

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.