Chantier : modele solaire local abandonne, la mesure ne permet pas de le valider

Tentative de produire la forme horaire depuis la geometrie et les quatre
orientations reelles, pour eviter l'abonnement. Abandonnee pour trois raisons
cumulees.

Seules 4 heures de la journee sont exploitables (censure 0-4 % de 08 a 11 h,
puis 59 % a 12 h, 77 % a 13 h, 81 % a 14 h) : ajuster une forme journaliere sur
quatre heures propres n'est pas serieux. L'enveloppe n'est de plus pas une
courbe de journee valide — c'est le maximum horaire pris independamment sur des
jours differents, donc plus plate que n'importe quelle journee reelle. Enfin le
modele direct seul predit zero production matinale sur le plan ouest la ou la
mesure donne 14 % a 9 h : il manquait le rayonnement diffus, dont la fraction
ajustee part en butee sans converger, le modele restant trop pique sur midi
pour les quatre plans a la fois.

Decouverte utile : correspondance etablie entre entrees MPPT et orientations —
airtria_mppt1 = 10 PV sud-est (pic 11 h), v1 = 3 PV suiveur (pic 9 h),
RS450 tracker_solar_1/2/3 = 3 strings sud (pics 13-14 h), tracker_solar_4 =
string ouest (trainee jusqu'a 19 h). Chaque plan est donc confrontable a sa
propre mesure.

Consequence : l'abonnement Professional est le bon choix, pour une raison que
je n'avais pas identifiee en le deconseillant. Avec la cle, n8n interrogera
api.forecast.solar directement et obtiendra la courbe horaire complete, que
l'integration HA n'expose pas meme abonnee. Cette courbe remplacera a la fois
la forme et la magnitude dans RESOURCE_ESTIMATE.

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

docs/CHANTIER_BILAN_ENERGETIQUE.md

@@ -224,6 +224,49 @@ calcul en saison basse.
   Déclaré dans `configuration.yaml` (sauvegarde dans `SAVE_CONFIG/`),
   redémarrage HA effectué, aucune erreur au journal.
 
+## Modèle solaire local : tentative abandonnée (25/08)
+
+Objectif : produire la forme horaire à partir de la géométrie et des quatre
+orientations réelles, pour éviter un abonnement Forecast.Solar. **Abandonné**,
+pour trois raisons qui se cumulent.
+
+**Découverte utile au passage** : les entrées MPPT sont mesurées séparément et
+la correspondance est établie — `sensor.airtria_mppt1_yield_today` = les 10 PV
+sud-est (pic à 11 h), `sensor.v1_yield_today` = les 3 PV du suiveur (pic à 9 h),
+`tracker_solar_1/2/3` du RS 450/200 = les trois strings sud (pics 13-14 h),
+`tracker_solar_4` = le string ouest (longue traîne jusqu'à 19 h). Chaque plan
+peut donc être confronté à sa propre mesure — c'est ce qui a permis de trancher.
+
+1. **Seules 4 heures de la journée sont exploitables.** Taux de censure :
+   08 h 0 %, 09 h 0 %, 10 h 4 %, 11 h 4 %, puis **12 h 59 %, 13 h 77 %,
+   14 h 81 %**. Ajuster une forme journalière sur quatre heures propres n'est
+   pas sérieux.
+2. **L'enveloppe n'est pas une courbe de journée valide.** C'est le maximum
+   horaire pris indépendamment sur des jours différents : le pic de 8 h vient
+   d'un jour, celui de 11 h d'un autre. Le résultat est plus plat que n'importe
+   quelle journée réelle. Comparer un modèle de journée à cette référence n'a
+   pas de sens. *(Limitation qui vaut aussi, au second ordre, pour l'usage de
+   l'enveloppe comme forme dans `RESOURCE_ESTIMATE` — atténuée par le fait
+   qu'elle y est renormalisée sur la prévision du jour.)*
+3. **Le modèle a besoin de paramètres non ajustables sur ces données.** Un
+   modèle direct seul prédit zéro production le matin sur le plan ouest, alors
+   que la mesure donne 14 % à 9 h : il manquait le **rayonnement diffus**.
+   Ajouté, sa fraction part en butée de l'intervalle de recherche sans jamais
+   converger — le modèle reste trop piqué sur midi par rapport à la mesure, et
+   ce pour les quatre plans à la fois.
+
+**Conséquence** : l'abonnement Forecast.Solar Professional (souscrit le 24/08,
+70 €/an, 14 jours d'essai) est le bon choix, et pour une raison que je n'avais
+pas identifiée en le déconseillant. Avec la clé d'API, n8n interrogera
+directement `api.forecast.solar` et obtiendra la **courbe horaire complète**
+(`watt_hours_period`) pour les trois plans — ce que l'intégration HA n'expose
+pas, même abonnée, puisqu'elle ne publie que quatre capteurs résumés.
+
+Cette courbe remplacera **à la fois** la forme (enveloppe) et la magnitude
+(capteurs) dans `RESOURCE_ESTIMATE`, ce qui simplifiera le nœud au lieu de le
+compliquer. Les plans à déclarer : sud-est 135°/40°/4030 W (suiveur fusionné,
+930 W), sud 180°/35°/9300 W, ouest 270°/45°/2790 W.
+
 ## Backlog
 
 - [ ] **Doublon `unique_id: victron_vebus_dc_power`** — déclaré deux fois, avec