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

src/nodes/BATTERY_CLOUD_LOCKS.js

@@ -393,10 +393,69 @@ const nightPreferredSourceMode = nightPrev.nightPreferredSourceMode || 'blocked'
 // =====================================================
 // PROFILE-BASED THRESHOLDS
 // =====================================================
+// =====================================================
+// PLANCHER DU SOIR : UN NIVEAU FIXE, REMPLACE PAR L'ENERGIE A COUVRIR (03/09/2026)
+// =====================================================
+// `evening_soc_start_min` = 85 % est une tentative de dire « garde de quoi
+// passer la nuit ». C'est un NIVEAU, pris a un instant, et il ne sait rien de
+// la nuit qui vient : ni sa duree, ni la consommation a couvrir, ni l'heure a
+// laquelle le solaire prendra le relais.
+//
+// Le bilan energetique calcule exactement cela et le publie —
+// `evcs_balance_required_soc`, deduit de l'energie a couvrir jusqu'au
+// croisement production/consommation. Personne ne le lisait : `grep
+// evcs_balance` sur les deux workflows de decision renvoyait 0.
+//
+// Le 03/09 a 19:44, les deux nombres coexistaient dans le meme systeme :
+// plancher du soir 85 % (SOC 94, donc charge autorisee) contre SOC requis
+// 99,7 % pour tenir jusqu'au croisement de 9 h. La charge du soir a fait
+// passer le manque de la nuit de 0,86 a 2,21 kWh.
+//
+// SENS UNIQUE, ET C'EST DELIBERE : le bilan ne peut que RENFORCER le plancher,
+// jamais l'abaisser (Math.max). L'assouplir — le bilan 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 : le max rend la garde robuste sans borne ni ecretage — une
+// valeur nulle, negative ou aberrante ne peut pas relacher le plancher.
+//
+// PORTEE : plancher de DEMARRAGE. Le plancher de maintien reste
+// min(profileSocHoldFloor, ...) donc inchange a 80 % : relever le plancher de
+// demarrage ne coupe aucune charge en cours.
+//
+// L'abondance P6 continue de primer : PV moyen >= 4 kW ET batterie qui monte a
+// >= +20 A est une PREUVE MESUREE que la ressource depasse ce que le systeme
+// absorbe — le cas ou la voiture est effectivement gratuite.
+//
+// REPLI : lecture absente, statut non 'ok', ou bilan plus vieux que six de ses
+// cycles => regle historique inchangee. Le kill-switch existe deja et n'a pas
+// besoin d'etre double : `input_boolean.evcs_balance_enabled` a OFF arrete les
+// ecritures du bilan, `balance_last_run` se fige, et le plancher retombe seul
+// sur 85 % en une demi-heure.
+const BALANCE_MAX_AGE_MIN = 30;
+const balanceAgeMin =
+  params.balanceLastRunMs !== null && params.balanceLastRunMs !== undefined
+    ? (nowMs - params.balanceLastRunMs) / 60000
+    : null;
+const balanceFresh =
+  balanceAgeMin !== null &&
+  balanceAgeMin >= -5 &&
+  balanceAgeMin <= BALANCE_MAX_AGE_MIN;
+const balanceEveningFloorUsable =
+  balanceFresh &&
+  params.balanceStatusOk &&
+  Number.isFinite(params.balanceRequiredSocPct);
+
+const eveningSocStartFloorPct = balanceEveningFloorUsable
+  ? Math.max(params.eveningSocStartMin, params.balanceRequiredSocPct)
+  : params.eveningSocStartMin;
+const eveningFloorFromBalance =
+  balanceEveningFloorUsable && eveningSocStartFloorPct > params.eveningSocStartMin;
+
 const profileSocStartFloor =
   context.profile === 'morning_solar' ? params.morningSocMin :
   context.profile === 'midday_hc_or_solar' ? params.middaySocMin :
-  context.profile === 'evening_high_soc' ? params.eveningSocStartMin :
+  context.profile === 'evening_high_soc' ? eveningSocStartFloorPct :
   params.socStartMin;
 
 // P6 ABONDANCE : PV moyen élevé + batterie en charge franche => le plancher SOC
@@ -1058,6 +1117,14 @@ return [{
       profileBatteryDischargeFloorA,
 
       // Excedent solaire (03/09/2026) : la grandeur qui autorise un demarrage.
+      // Plancher du soir issu du bilan energetique (03/09/2026).
+      eveningSocStartFloorPct,
+      eveningFloorFromBalance,
+      balanceRequiredSocPct: params.balanceRequiredSocPct,
+      balanceEnergyToCoverKwh: params.balanceEnergyToCoverKwh,
+      balanceAgeMin: balanceAgeMin === null ? null : Math.round(balanceAgeMin * 10) / 10,
+      balanceEveningFloorUsable,
+
       solarSurplusW,
       solarSurplusProvocationOk,
       solarSurplusStartOk,

src/nodes/HA_SERVICE_CALLS_OUTPUT.js

@@ -394,6 +394,14 @@ if (batteryPolicy.batterySoftBreachNow) {
     `Batt souple ${round1(batteryPolicy.batterySoftBreachMinutes)}/${round1(batteryPolicy.batterySoftToleranceMinutes)}min`
   );
 }
+// Idem : visible seulement quand le bilan energetique DURCIT le plancher du
+// soir. Sans cette trace, un blocage de charge un soir de SOC 94 % est
+// incomprehensible a la lecture du logbook.
+if (safeguards.eveningFloorFromBalance) {
+  reason.push(
+    `Plancher soir=${round1(safeguards.eveningSocStartFloorPct)}% (BILAN, ${round1(safeguards.balanceEnergyToCoverKwh)}kWh a couvrir)`
+  );
+}
 reason.push(`Cap=${derived.physicalCapA}A`);
 reason.push(`Ref=${round1(derived.currentReferenceA)}A`);
 reason.push(`Target=${round1(desiredCurrentA)}A`);

src/nodes/HA_SNAPSHOT_TEMPLATE.json.tpl

@@ -139,6 +139,11 @@
   "advisor_night_target_soc": states("input_number.evcs_advisor_night_target_soc"),
   "advisor_status": states("input_text.evcs_advisor_status"),
   "advisor_last_run": states("input_text.evcs_advisor_last_run"),
+
+  "balance_required_soc": states("input_number.evcs_balance_required_soc"),
+  "balance_energy_to_cover_kwh": states("input_number.evcs_balance_energy_to_cover_kwh"),
+  "balance_status": states("input_text.evcs_balance_status"),
+  "balance_last_run": states("input_text.evcs_balance_last_run"),
   "allow_grid_hc_midday": states("input_boolean.victron_evcs_allow_grid_hc_midday"),
   "probe_enabled": states("input_boolean.victron_evcs_probe_enabled"),
 

src/nodes/INPUT_PARSE.js

@@ -439,6 +439,13 @@ const params = {
   advisorStatusOk: cleanText(input.advisor_status).toLowerCase() === 'ok',
   advisorLastRunMs: parseAdvisorRunToMs(cleanText(input.advisor_last_run)),
 
+  // BILAN ENERGETIQUE (03/09/2026). Meme format d'horodatage que l'advisor
+  // ("DD/MM HH:mm"), d'ou la reutilisation du parseur.
+  balanceRequiredSocPct: num(input.balance_required_soc, NaN),
+  balanceEnergyToCoverKwh: num(input.balance_energy_to_cover_kwh, NaN),
+  balanceStatusOk: cleanText(input.balance_status).toLowerCase() === 'ok',
+  balanceLastRunMs: parseAdvisorRunToMs(cleanText(input.balance_last_run)),
+
   // Duree de la fenetre d'etablissement. Valeur mesuree le 31/08/2026 : le
   // transitoire de fermeture dure ~150 s (import 1985 -> 25 W et 2600 -> 52 W,
   // deux campagnes), on prend 180 s de marge. Reglable sans redeploiement via