From ea587f76372f70036b4a13cd947c54d8c8df1193 Mon Sep 17 00:00:00 2001 From: Tallagrand Thierry Date: Tue, 25 Aug 2026 02:08:25 +0200 Subject: [PATCH] Chantier : modele solaire local abandonne, la mesure ne permet pas de le valider MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ --- docs/CHANTIER_BILAN_ENERGETIQUE.md | 43 ++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/docs/CHANTIER_BILAN_ENERGETIQUE.md b/docs/CHANTIER_BILAN_ENERGETIQUE.md index 9727192..2ec2e25 100644 --- a/docs/CHANTIER_BILAN_ENERGETIQUE.md +++ b/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