Le plancher du soir vient de l energie a couvrir, plus d un niveau fixe

grep evcs_balance sur les deux workflows de decision renvoyait 0 depuis la mise
en service du bilan le 26/08 : il calculait l heure de croisement, l energie a
couvrir et le SOC requis, et personne ne l ecoutait. Le 03/09 a 19:44 les deux
nombres coexistaient dans le meme systeme — evening_soc_start_min a 85 %, un
niveau qui ne sait rien de la nuit, contre evcs_balance_required_soc a 99,7 %,
l energie a couvrir jusqu au croisement de 9 h. A SOC 94 le premier autorisait
la charge, le second disait que la batterie ne passerait pas la nuit seule.

Le plancher de demarrage du soir vaut desormais max(regle, bilan). Sens unique
delibere : le bilan peut durcir, jamais relacher. L assouplir — il dira souvent
moins de 85 % par forte prevision d ete — autoriserait des charges qui n ont pas
lieu aujourd hui, decision distincte a valider pour elle-meme. Le max rend au
passage la garde robuste sans borne ni ecretage : une valeur nulle, negative ou
aberrante ne peut pas relacher le plancher.

Portee demarrage : le plancher de maintien reste min(...), donc a 80 %, et
aucune charge en cours n est coupee. L abondance P6 continue de primer, etant
une preuve mesuree que la ressource depasse ce que le systeme absorbe.

Gardes : fraicheur inferieure a 30 min (six cycles du bilan), horodatage futur
rejete, statut ok, valeur finie. Sinon regle historique. Aucun nouveau toggle :
evcs_balance_enabled a OFF arrete les ecritures du bilan, balance_last_run se
fige, la fraicheur expire et le plancher retombe seul sur 85 % en une
demi-heure — un helper de plus aurait fait doublon.

Gabarit complet re-rendu contre HA : 195 champs, JSON valide, aucun null.
parseAdvisorRunToMs reutilise, l advisor et le bilan publiant le meme format.

Golden 66 -> 70. Quatre mutations — bilan ignore, Math.max remplace par une
affectation directe, garde de fraicheur supprimee, garde de statut supprimee —
font tomber chacune exactement un scenario, et un different a chaque fois.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

HANDOFF.md

@@ -2720,3 +2720,104 @@ repli). Restauration → 66/66.
 
 ---
 *Document mis a jour le : 03/09/2026 (~21:45) — provocation solaire gagee sur le mode des chargeurs, golden 66/66, deploye*
+
+## 38. Session du 03/09/2026 (suite) — Le plancher du soir cesse d'etre un niveau fixe
+
+### Le constat, enfin traite
+`grep evcs_balance` sur les deux workflows de decision renvoyait **0** depuis la
+mise en service du bilan (26/08). Il calculait l'heure de croisement,
+l'energie a couvrir et le SOC requis, et personne ne l'ecoutait.
+
+Le 03/09 a 19:44, les deux nombres coexistaient dans le meme systeme :
+
+| source | valeur | nature |
+|---|---:|---|
+| `evening_soc_start_min` | **85 %** | un NIVEAU, fixe, qui ne sait rien de la nuit |
+| `evcs_balance_required_soc` | **99,7 %** | l'ENERGIE a couvrir jusqu'au croisement de 9 h |
+
+SOC 94 : le premier autorisait la charge, le second disait que la batterie ne
+passerait meme pas la nuit toute seule. La charge du soir a fait passer le
+manque de 0,86 a 2,21 kWh.
+
+### Le correctif (deploye 03/09 22:18, golden 70/70)
+Dans `BATTERY_CLOUD_LOCKS.js`, le plancher de DEMARRAGE du profil
+`evening_high_soc` devient :
+
+```js
+eveningSocStartFloorPct = Math.max(params.eveningSocStartMin, params.balanceRequiredSocPct)
+```
+
+**SENS UNIQUE, ET C'EST DELIBERE.** Le bilan ne peut que RENFORCER le plancher,
+jamais l'abaisser. L'assouplir — il dira souvent moins de 85 % par forte
+prevision d'ete — autoriserait des charges qui n'ont pas lieu aujourd'hui :
+c'est une decision distincte, avec ses propres risques, qui doit etre validee
+pour elle-meme et non glissee dans ce correctif. Corollaire agreable : le `max`
+rend la garde robuste **sans borne ni ecretage** — une valeur nulle, negative ou
+aberrante ne peut pas relacher le plancher.
+
+**PORTEE : demarrage.** Le plancher de maintien reste
+`min(profileSocHoldFloor, ...)`, donc inchange a 80 % : relever le plancher de
+demarrage ne coupe aucune charge en cours. Troisieme fois de suite que la
+distinction demarrage/maintien est ce qui rend un correctif sur.
+
+**L'abondance P6 continue de primer** (PV moyen ≥ 4 kW ET batterie a ≥ +20 A) :
+c'est une PREUVE MESUREE que la ressource depasse ce que le systeme absorbe,
+donc le cas ou la voiture est effectivement gratuite.
+
+### Gardes et repli
+- fraicheur ≤ **30 min** (six cycles du bilan, qui tourne toutes les 5 min),
+  avec rejet d'un horodatage dans le futur de plus de 5 min ;
+- `evcs_balance_status` exactement `ok` ;
+- valeur numerique finie.
+Sinon : regle historique inchangee.
+
+**Aucun nouveau toggle : le kill-switch existe deja.**
+`input_boolean.evcs_balance_enabled` a OFF arrete les ecritures du bilan
+(`BUILD_HA_CALLS` : `if (!enabled) return []`), `balance_last_run` se fige, la
+garde de fraicheur expire et le plancher retombe seul sur 85 % en une
+demi-heure. Un helper de plus aurait fait doublon.
+
+### Chaine technique
+`HA_SNAPSHOT_TEMPLATE` : +`balance_required_soc`, +`balance_energy_to_cover_kwh`,
++`balance_status`, +`balance_last_run` (gabarit complet re-rendu : **195 champs,
+JSON valide, aucun null**). `INPUT_PARSE` : `params.balance*`, en reutilisant
+`parseAdvisorRunToMs` — l'advisor et le bilan publient le meme format
+`DD/MM HH:mm`. `HA_SERVICE_CALLS_OUTPUT` : trace
+`Plancher soir=X% (BILAN, Y kWh a couvrir)`, emise uniquement quand le bilan
+durcit le plancher — sans elle, un blocage un soir de SOC 94 % est
+incomprehensible a la lecture du logbook.
+
+### Golden 66 → 70
+Les quatre scenarios ont un VRAI excedent (PV 2000 W, maison 1000 W) et des
+chargeurs qui se retiennent : les gardes de §36 et §37 sont passantes, le
+plancher est le SEUL discriminant.
+
+| scenario | SOC | bilan | attendu |
+|---|---:|---|---|
+| `bilan-plancher-soir-durci` | 94 | 99,7 %, frais | pas de charge |
+| `bilan-plancher-soir-ne-relache-pas` | 70 | 60 %, frais | pas de charge (85 % reste maitre) |
+| `bilan-perime-regle-historique` | 94 | 99,7 %, vieux de 2 h | charge |
+| `bilan-statut-degrade-regle-historique` | 94 | 99,7 %, statut non ok | charge |
+
+Mutation, quatre directions — bilan ignore / `Math.max` remplace par une
+affectation directe / garde de fraicheur supprimee / garde de statut supprimee :
+**chacune fait tomber exactement UN scenario, et un different a chaque fois.**
+Chaque garde a donc son test dedie, aucun ne couvre pour un autre.
+Restauration → 70/70.
+
+### Observation
+A 20:15 le bilan demandait 99,7 % (11,66 kWh a couvrir) ; a 22:15, **81,9 %**
+(8,98 kWh). Le plancher suit la nuit qui s'ecoule — ce qu'un niveau fixe ne fait
+pas, et c'est tout l'interet.
+
+### Reste ouvert
+- La **cible du matin** (`night_target_soc`) reste sur la regle des paliers
+  35/55/85, deduite du TOTAL de demain et aveugle a l'heure d'arrivee de
+  l'energie. Le 03/09 : 35 % cote controleur contre 99,7 % cote bilan. C'est le
+  meme defaut que celui corrige ici, sur l'autre bout de la nuit.
+- Le workflow d'hysteresis ne lit toujours aucun helper du bilan : ses seuils
+  `grid_soc_on`/`grid_soc_off` (20/30) restent des niveaux fixes (§11.8.A).
+- `houseSpikeDetected` reste structurellement faux (§35).
+
+---
+*Document mis a jour le : 03/09/2026 (~22:25) — plancher du soir issu du bilan energetique, golden 70/70, deploye*