ETM-Schurig/etm-powersync-energy-plugin-etm
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(prévision PV): §28 — décisions du 2026-10-12

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Patrick Schurig 2026-10-12 08:20:54 +02:00
parent c78dbfc318
commit 89b78c6cf5
1 changed files with 34 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
docs/DESIGN_PREVISION_PV.md
View File

@ -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`**.