La prevision se juge sur la date qu elle decrit, plus sur son age

Nuit du 07 au 08/09 : 32 calculs du bilan sur 120 en statut degrade, tous entre
00 h et 03 h, avec « aucun croisement PV/conso sur l'horizon, 47,6 kWh a
couvrir ». Le controleur, qui exige statut=ok, retombait sur le palier de 35 % —
d'ou une cible du matin oscillant entre 35, 78,8 et 85 % au lieu de decroitre.

Cause immediate : plus aucune publication de prevision de 23:45 a 04:30. Le
noeud d'appel porte neverError, donc les executions restaient en success ; la
reponse etait « socket hang up », et le noeud d'ecriture vers Home Assistant
rendait 0 item la nuit contre 1 en journee — le .17 etait lui aussi injoignable,
si bien que le message d'echec ne pouvait meme pas etre publie.

Mais le defaut qu'on controle est ailleurs : les courbes sont publiees sans leur
date, et PARSE_FORECAST prend days[0] pour « aujourd'hui ». Vrai a l'instant de
la publication, faux des qu'on passe minuit sans rafraichir. A 00:45 le bilan a
donc lu comme journee en cours celle du 7, dont toutes les heures etaient
passees.

Une courbe est desormais utilisable si elle DECRIT le jour dont on a besoin, pas
si elle est recente : une prevision publiee a 23:45 pour le 8 reste exacte a
03:00, la nuit il n'y a rien a reactualiser. La date part dans
evcs_balance_forecast_day0, et RESOURCE_ESTIMATE distingue trois cas — a jour,
decalee d'un jour (la courbe du lendemain devient celle du jour, l'enveloppe
mesuree reprend la main pour demain), perimee. Helper absent : ancienne garde
d'age, comportement inchange.

Le rapport de nuit signale un trou de plus de deux heures dans les
publications. Il lit la base sur l'autre NAS, seul temoin qui survit quand le
.17 est injoignable. Verifie sur la nuit ecoulee : 285 minutes.

Tests 44 -> 48. Les quatre scenarios partagent la meme heure — 00:45, l'instant
du decrochage — et les memes courbes : seule la date change. Quatre mutations,
chacune sur un jeu different, chaque scenario ayant la sienne.

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

HANDOFF.md

@@ -5593,3 +5593,95 @@ n'est jamais parti dans le depot.
 
 ---
 *Document mis a jour le : 08/09/2026 — acces API Grafana retabli, rectification sur la cause des 401*
+
+
+## 61. Session du 08/09/2026 — La prevision se juge sur la date qu'elle decrit
+
+### Le symptome
+Nuit du 07 au 08/09, **32 calculs du bilan sur 120 en statut « degrade »**,
+tous entre 00 h et 03 h, avec ce motif :
+
+> « Aucun croisement PV/conso sur l'horizon : 47,6 kWh a couvrir → SOC requis
+> 100 %. ⚠ chiffre indicatif, pas une exigence datee. »
+
+Le controleur exige `statut = ok` pour suivre le bilan (§39) : a ces moments-la
+il retombait sur le palier de 35 %, d'ou une cible du matin qui oscillait entre
+35, 78,8 et 85 % au lieu de decroitre proprement.
+
+### La panne, et ce qu'elle a revele
+`input_text.evcs_balance_forecast_updated` s'arrete a **23:45** et ne reprend
+qu'a **04:30** — 4 h 45. Pendant ce temps le workflow s'executait bien quatre
+fois par heure **en « success »**, parce que le noeud d'appel porte
+`neverError: true` et `onError: continueRegularOutput`.
+
+Reponse reelle de l'API pendant la fenetre : `socket hang up`. Et ce n'etait pas
+que Forecast.Solar — le noeud `Execute HA Service Forecast` rendait **0 item**
+la nuit contre 1 en journee : **Home Assistant lui aussi etait injoignable**
+depuis n8n, si bien que le message d'echec ne pouvait meme pas etre publie.
+Deux autres workflows ont eu des erreurs dans la meme fenetre. Cause racine de
+l'indisponibilite reseau **non etablie** ; ce n'est pas la sauvegarde de 399 Go,
+qui s'est terminee le 07 a 12:04. Une seule occurrence en quatre jours.
+
+⚠️ **Ce que l'on controle, c'est la REACTION a cette panne, et elle etait
+fautive.** Les courbes sont publiees dans `evcs_balance_forecast_today` et
+`_tomorrow` **sans leur date**. `PARSE_FORECAST` prend `days[0]` comme
+« aujourd'hui » : vrai a l'instant de la publication, **faux des qu'on passe
+minuit sans rafraichir**. A 23:45 « today » etait la courbe du 7 ; a 00:45 le
+bilan l'a lue comme celle du 8, journee dont toutes les heures etaient passees
+— d'ou « aucune production sur l'horizon ». En temps normal le rafraichissement
+de minuit corrige en quinze minutes et personne ne voit rien.
+
+### Le correctif
+**Une courbe est utilisable si elle DECRIT le jour dont on a besoin, pas si
+elle est recente.** Une prevision publiee a 23:45 pour le 8 reste exacte a
+03:00 : la nuit, il n'y a rien a reactualiser.
+
+- `BUILD_HA_CALLS_FORECAST` publie `input_text.evcs_balance_forecast_day0`
+  (la date de la courbe « today ») ;
+- le gabarit du bilan la lit ;
+- `RESOURCE_ESTIMATE` remplace la garde d'age de 60 min par une garde de date,
+  avec trois cas : `a_jour` (lecture directe), `decalee_d_un_jour`
+  (publication d'avant minuit : la courbe « tomorrow » EST celle du jour, et
+  l'enveloppe mesuree reprend la main pour le lendemain), `perimee`
+  (au-dela : repli enveloppe).
+
+⚠️ **REPLI** : `forecast_day0` absent ou illisible → ancienne garde d'age.
+Tant que le helper n'existe pas cote Home Assistant, le comportement est
+strictement inchange. C'est ce qui permet de deployer le code avant le helper.
+
+### Visibilite de la panne
+Le rapport de nuit signale desormais un trou de plus de deux heures dans les
+publications de prevision. Il lit la table `prevision` sur **l'autre NAS** :
+c'est le seul temoin qui survit quand le .17 est injoignable. Verifie sur la
+nuit ecoulee : la requete rend bien 285 minutes.
+
+### Tests 44 → 48
+Les quatre scenarios partagent la meme heure — **00:45, l'instant exact du
+decrochage** — et les memes courbes : seule la date publiee change, ce qui les
+rend probants.
+`prevision-decalee-apres-minuit` (le cas reel : day0 = la veille → la courbe du
+lendemain devient celle du jour, 30 kWh redeviennent visibles) ·
+`prevision-a-jour-lecture-directe` (contrefactuel) ·
+`prevision-vieille-mais-du-bon-jour` (publiee cinq heures plus tot mais datee du
+jour : utilisable — **l'ancienne garde d'age la refusait**) ·
+`prevision-perimee-de-deux-jours` (repli enveloppe).
+
+Un attendu existant passe de 4 a 5 ecritures (`forecast-perimetre-respecte`) :
+la date est publiee a cote des courbes, et le perimetre `evcs_balance_*` reste
+respecte.
+
+Preuve par mutation, quatre directions, **chacune tombant sur un jeu different**
+et chaque scenario ayant la sienne : decalage non corrige · cas decale non
+reconnu · retour a la garde d'age (3 scenarios) · courbe perimee utilisee quand
+meme.
+
+### A FAIRE AVANT QUE LE CORRECTIF AGISSE
+1. Creer le helper `input_text.evcs_balance_forecast_day0` dans
+   `/mnt/ARCH3/docker/HA/packages/evcs_energy_balance.yaml`, a cote de
+   `evcs_balance_forecast_today`, puis `input_text.reload` — aucun redemarrage.
+2. Pousser les deux workflows : `evcs-solar-forecast-v1.json` (publie la date)
+   et `evcs-energy-balance-v1.json` (la lit).
+L'ordre n'a pas d'importance grace au repli.
+
+---
+*Document mis a jour le : 08/09/2026 — prevision jugee sur sa date et non son age, tests 48/48, en attente de deploiement*