From 89b78c6cf56d7e6fc9372c48a1ebebbc946a3a16 Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Mon, 12 Oct 2026 08:20:54 +0200 Subject: [PATCH] =?UTF-8?q?docs(pr=C3=A9vision=20PV):=20=C2=A728=20?= =?UTF-8?q?=E2=80=94=20d=C3=A9cisions=20du=202026-10-12?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Consigne, sans réécrire le reste : paramètres physiques par champ (coefficient de température, NOCT) sur le Thing plan openmeteo, qui applique la correction de température ; plafond AC = paramètre de site côté ems, appliqué après la somme des plans ; openmeteo publie en plus le GTI brut et temperature_2m horaire ; pas horaire conservé, 15 min avec le day-ahead ; §5 maintenu (conversion ∈ physics|fallback, rien d'appris dans le GPL) ; §11 maintenu (aucune décision sans lot dédié). Co-Authored-By: Claude Opus 5.5 --- docs/DESIGN_PREVISION_PV.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/DESIGN_PREVISION_PV.md b/docs/DESIGN_PREVISION_PV.md index f0dc5b6..aa84160 100644 --- a/docs/DESIGN_PREVISION_PV.md +++ b/docs/DESIGN_PREVISION_PV.md @@ -1319,3 +1319,37 @@ Le `performanceRatio` à **1,00** est bien visible, et bien borné : 13,4 kWh un septembre sur 2 kWc est **le haut de la fourchette**, pas au-delà. Il rend la prévision optimiste de l'ordre de 10 à 20 % — exactement ce qui avait été annoncé en le fixant, et il **s'ajoute** au plafond du §3 sans jamais l'expliquer. + + +--- + +## 28. Décisions du 2026-10-12 + +*Consignées telles que rendues (brief 1 du lot « protocole 1.1 »), à la suite du rapport du lot 0. +Rien de ce qui précède n'est réécrit ; aucune n'est implémentée à ce jour — ce sont des décisions, +pas un état du code.* + +1. **Les paramètres physiques PAR CHAMP vivent sur le Thing plan openmeteo** — coefficient de + température, NOCT — à côté de `tilt`, `azimuth`, `kwp` et `performanceRatio`. **C'est openmeteo + qui applique la correction de température.** Une seule source de vérité pour l'orientation et + la physique d'un champ : le doublon « Thing plan + store `ems` » relevé au lot 0 §1b est écarté. +2. **Le plafond AC est un paramètre DE SITE, côté `ems`**, appliqué **après la somme des plans**. + L'écrêtage onduleur porte sur ce que l'onduleur reçoit de tous ses champs, pas sur chacun : il + ne peut donc pas vivre sur un plan. +3. **openmeteo publie EN PLUS le GTI brut et `temperature_2m` horaire**, pour l'**enregistrement** + — de quoi refaire ou contrôler la conversion plus tard sans dépendre de ce qu'elle a produit. +4. **Pas horaire conservé.** Le **15 min viendra avec les prix day-ahead**, sans changement de + contrat : la grille est lue (`step`, §14.3), jamais supposée. +5. **§5 maintenu : aucune correction apprise dans le GPL.** `conversion` ∈ `physics` | `fallback` ; + le plugin GPL n'émet jamais `hybrid`. Un optimiseur qui corrige la prévision le déclare de son + côté (`OPTIMIZER_PROTOCOL.md` §6, `diagnostics.inputsUsed.pv`). +6. **§11 maintenu : la prévision n'entre dans aucune décision sans un lot dédié**, avec sa propre + décision écrite. Les décisions 1 à 4 améliorent la courbe ; elles ne la branchent sur rien. + +> **Ce que ces décisions déplacent, et qui n'est pas encore fait** : la correction de température +> et la publication du GTI brut / `temperature_2m` sont du travail **openmeteo** (dépôt +> `etm-powersync-plugins`) et un changement de forme du transport. **Si** `v` est incrémenté — la +> règle proposée au lot 0 §4 est de l'incrémenter à tout changement de forme — +> `ForecastStore::depuisTransport()` **refusera** la charge utile (`VERSION_x`) tant que ce dépôt +> n'aura pas appris à la lire : l'ordre de livraison est alors imposé, le lecteur avant ou en même +> temps que le producteur. Le plafond AC de site est du travail **`ems`**.