# Prévision de production PV — une série, et elle est révisée > Ouvert le 2026-09-08. **Design avant code, rien d'implémenté.** > Cadrage donné par Patrick. Les constats météo viennent de l'agent openmeteo et sont > **repris tels quels** : ils sont mesurés, pas supposés. ## 1. La frontière, et pourquoi elle tombe là | | responsabilité | |---|---| | plugin **openmeteo** | **météo pure** — irradiance, température, couverture. Rien de photovoltaïque | | **ems** (ici) | les **plans PV** (crête, orientation, inclinaison), la **conversion**, l'**appel API**, et l'**historique** | Le plugin météo ne connaît pas l'installation ; l'installation ne se déclare pas dans un plugin météo. Et c'est ici que vivent déjà la configuration persistée, le compteur de production et la frontière RPC — donc ici que la série peut être servie à l'app sans traverser une troisième maison. ### Pourquoi ce n'est pas un état nymea **Le besoin n'est pas de décider, c'est d'afficher** : la courbe prévue d'aujourd'hui et de J+1, superposée à la production réelle. - **Aucun état nymea ne porte une série.** Un état est une valeur à un instant. - **`suggestLogging` ne construit que du passé.** Il enregistre ce qu'un état a valu. **Une prévision porte sur des heures qui ne sont pas arrivées** — il n'y a rien à enregistrer, il y a quelque chose à **écrire d'avance**. C'est le même geste que le logging natif pour les compteurs, à ceci près qu'il regarde devant. ## 2. LE POINT DE CONCEPTION — la table est BITEMPORELLE **Une prévision est révisée.** Celle de 8 h pour 15 h n'est pas celle de 14 h pour 15 h. La table n'est donc **pas** « valeur par heure ». Elle est **« valeur par heure, telle que prévue à tel moment »** : ```sql CREATE TABLE forecastPv ( targetAt INTEGER NOT NULL, -- epoch UTC de l'heure VISÉE issuedAt INTEGER NOT NULL, -- epoch UTC de l'ÉMISSION de cette prévision forecastWh REAL NOT NULL, model TEXT, PRIMARY KEY (targetAt, issuedAt) -- la CLÉ EST LA PAIRE ); ``` **La clé est la paire, et c'est tout le lot.** Avec `targetAt` seul, chaque rafraîchissement écrase le précédent : on perd les révisions, donc la comparaison prévu/réalisé — c'est-à-dire exactement ce qu'on veut montrer, et ce dont optimiseur ETM aura besoin. > C'est la même distinction que `measuredSince` : **quand on a mesuré**, et **ce qu'on a mesuré**. > Deux dates, deux questions, et les confondre en perd une. ### Conséquence de contrat : « prévu » ne veut rien dire sans HORIZON Dès que les révisions coexistent, « la prévision pour 15 h » est ambiguë. Toute lecture doit nommer son horizon, et l'écran aussi : | lecture | requête | ce qu'elle répond | |---|---|---| | **courante** | pour chaque `targetAt`, la ligne de `issuedAt` maximal ≤ maintenant | « ce qu'on prévoit en ce moment » | | **veille** | `issuedAt` le plus proche de J−1 à heure fixe | « la prévision de la veille valait-elle quelque chose ? » | | **à H−1** | `issuedAt` le plus proche de `targetAt − 1 h` | « la meilleure estimation possible » | Les trois répondent à des questions différentes. Publier « prévu » sans dire laquelle laisse le client en choisir une au hasard, et deux écrans montrent deux courbes pour le même jour. ## 3. Ce que la conversion IGNORE — cinq facteurs, tous optimistes Repris de l'agent openmeteo, mesuré : 1. l'**ombrage**, 2. l'**encrassement**, 3. la **température de module**, 4. l'**écrêtage onduleur**, 5. les **salissures**. **Les cinq vont dans le même sens.** Ce n'est donc pas un bruit qui se compense : c'est un **biais systématique et signé**. La conversion ne produit pas une estimation, elle produit un **plafond**. > **À écrire dans le contrat, pas seulement ici.** Une courbe présentée comme « production > prévue » et systématiquement au-dessus du réel se lit comme une installation qui sous-performe. > L'utilisateur cherchera une panne qui n'existe pas — et il aura raison de chercher, puisque > l'écran lui aura affirmé une chose fausse. ## 4. La dispersion d'ensemble ne QUALIFIE PAS la production Le réflexe serait de publier la dispersion des membres d'ensemble comme un indice de confiance. **C'est exactement l'inverse qu'il faut faire.** Elle est **anticorrélée au biais** : un ciel clair et stable donne la **dispersion la plus basse** au moment précis où la **perte thermique est la plus forte** — donc où l'erreur de conversion est la plus grande. > **Un indicateur de confiance anticorrélé à l'erreur est pire que pas d'indicateur.** Il est le > plus rassurant exactement quand il se trompe le plus. Il ne s'agit pas d'un indicateur > imparfait qu'on affinerait : il pointe dans la mauvaise direction, et l'affiner l'empire. Elle peut être **stockée** (elle décrit le ciel, et optimiseur ETM en fera peut-être quelque chose). Elle ne doit **jamais être publiée comme une qualité de la prévision de production**. *(Famille des modes d'érosion d'`AGENTS.md` : l'instrument dont le silence ressemble à un résultat. Ici, c'est l'instrument dont la confiance ressemble à une garantie.)* ## 5. Ce qui est HORS GPL — et ce que le GPL doit publier pour que l'autre existe **Comparer prévu à mesuré pour en tirer une correction est un apprentissage**, donc hors GPL. Mais la conséquence est constructive, et c'est elle qui justifie la table bitemporelle : > **Le GPL n'apprend pas ; il rend l'apprentissage POSSIBLE.** La table `(targetAt, issuedAt)` > est l'interface entre les deux. Sans elle, optimiseur ETM n'aurait pas la matière — et l'écraser à chaque > révision détruirait cette matière pour toujours, sans que rien ne le signale. Le GPL publie donc la série et le réalisé côte à côte, **sans les rapprocher**. Le rapprochement est le produit. ## 6. Cadence — une heure, et le raisonnement est celui du polling d'une borne Les modèles se rafraîchissent **au mieux toutes les heures**. Interroger plus souvent brûle du quota sans rien apporter : ce n'est pas une donnée neuve, c'est la même donnée relue. Le quota (10 000 appels/jour/IP) est très loin — **et ce n'est pas l'argument**. L'argument est le même que pour la borne : *on ne polle pas plus vite que la chose n'a de nouveau à dire*. Une cadence justifiée par « on a le droit » est une cadence qu'on ne sait pas défendre. ## 7. Le NOM porte la protection **Préfixe `forecast` partout**, sans exception : `forecastProductionW`, `forecastIssuedAt`, `forecastHorizonS`. Jamais `productionW`, jamais une valeur de `measurement.source`, jamais un champ qu'une somme puisse mêler à du mesuré. > **C'est la règle qui a coûté le plus cher ces trois semaines.** Un nombre qui ne dit pas d'où > il vient finit toujours par être lu comme une mesure — et une prévision lue comme une mesure > est un mensonge que personne n'a écrit. --- ## 8. Ce que j'ajoute au cadrage ### 8.1 Une heure n'est pas une heure — le piège du 6 septembre, à nouveau `targetAt` doit être un **instant absolu en UTC**, jamais un libellé d'heure locale. Un `2026-10-25 02:00` local existe **deux fois** et un `2026-03-29 02:00` n'existe **pas** : indexer par heure murale corrompt silencieusement la série deux fois par an, et l'erreur se voit un jour où personne ne regarde. Concrètement : demander `timezone=UTC` à l'API, stocker des epochs, **convertir au rendu seulement**. C'est la distinction déjà tranchée le 2026-09-07 — *un réglage est une chaîne qu'on interprète, un instant est absolu* — appliquée à une série entière au lieu d'un champ. **Et la vérification qui mord** : deux jours de 23 h et 25 h dans les données de test, avec la somme quotidienne comparée au nombre de lignes. Une série indexée en heure murale y perd ou double une heure, et rien d'autre ne le montre. ### 8.2 Rétention — la table grandit en heures × révisions 48 h d'horizon × 24 révisions/jour ≈ **1 150 lignes par jour**, ~46 ko/jour, ~17 Mo/an. Tenable sur la cible, **mais pas indéfiniment**, et une table qui ne dit pas quand elle purge finit par le décider toute seule un jour de disque plein. Proposition : **7 jours de révisions complètes**, puis effondrement à **deux lignes par heure visée** — la **première** (horizon le plus long) et la **dernière avant l'heure** (meilleure estimation). Garder les deux bouts conserve les deux seules questions qui se posent : *« la veille valait-elle quelque chose ? »* et *« que pouvait-on savoir de mieux ? »*. N'en garder qu'une détruit la révision, c'est-à-dire l'objet du lot. ### 8.3 Où vit le stockage : chez nous, pas dans `energylogs.sqlite` `energylogs.sqlite` appartient à l'amont, qui en migre le schéma. Y ajouter une table nous exposerait à une migration qui ne nous connaît pas. Un fichier à nous, à côté de `energy-load-configuration.json`, avec **notre** numéro de schéma. ### 8.4 L'absence n'est pas un zéro Pas de réseau, API en erreur, plan PV non déclaré : **aucune ligne**. Jamais `0 Wh`, qui se lirait « on prévoit une nuit ». La courbe publiée porte des **trous**, et l'écran doit savoir les afficher comme tels. Même règle que partout ici, et c'est la plus souvent oubliée quand la donnée est une série : un trou dans une courbe demande un effort de rendu, un zéro n'en demande aucun — et c'est pour ça qu'on écrit des zéros. ### 8.5 Les plans PV sont une CONFIGURATION, donc ils se versionnent Crête, orientation, inclinaison sont saisis par l'installateur, comme les rangs de charge. Même famille que `LoadConfigStore` : store persisté, RPC de lecture/écriture, validation au **refus** et non à la correction silencieuse. **Et un plan qui change périme la conversion, pas la météo.** L'historique doit donc retenir *sous quel plan* une prévision a été convertie — sinon un recâblage rend toute la série antérieure incomparable **sans que rien ne le dise**. C'est la même erreur que le plancher de borne qu'on aurait stocké au lieu de le dériver, déplacée dans le temps. --- ## 9. Ce qu'il me manque pour écrire le code 1. **La convention d'indexation, avec ses PARAMÈTRES.** Elle est rétrograde et mesurée — je la reprends. Mais une convention d'indexation dépend de la requête qui l'a produite (variables demandées, `timezone`, horaire vs quart-horaire). Reprendre la conclusion sans ses prémisses, c'est hériter d'un fait vrai sous des conditions qu'on ne saura pas reproduire. **L'énoncé exact et les paramètres de l'appel mesuré**, et je m'aligne dessus. 2. **Où se déclarent les plans PV** : un nouveau store à nous (ma proposition, §8.5), ou des champs sur le Thing onduleur ? 3. **La position du banc** — latitude/longitude. Elles conditionnent l'appel, et une prévision convertie sur la mauvaise position est fausse d'une façon parfaitement crédible. ## 10. Étapes proposées, à comportement constant d'abord **A** — le store des plans PV et son RPC. Rien n'appelle l'API ; la configuration existe et ne décide de rien. **B** — l'appel Open-Meteo et la table bitemporelle, **sans publication**. La série se remplit et s'observe au banc, y compris en travers d'un changement d'heure. **C** — la publication RPC de la courbe, avec son horizon nommé et ses trous. **D** — la superposition au réalisé, **côte à côte et sans rapprochement**. Le pas **D** est celui qui touche à la frontière avec le produit, et il arrive quand la série est déjà vérifiable.