157 lines
8.4 KiB
Markdown
157 lines
8.4 KiB
Markdown
# Plan — le planificateur des heures creuses
|
||
|
||
> Rédigé le 08/10/2026 à la demande du propriétaire, après la nuit du 07 au 08/10.
|
||
> **Statut : à valider. Aucune ligne de code n'est écrite pour ce chantier.**
|
||
|
||
## 1. Le problème
|
||
|
||
Depuis septembre, chaque incident a produit une règle de plus, écrite pour **une
|
||
fenêtre** ou **un véhicule** :
|
||
|
||
| règle | pour quel cas |
|
||
|---|---|
|
||
| P7 | voiture sur le réseau en HC de nuit |
|
||
| P12 + budget | voiture sur la batterie la nuit, arrêt au compteur |
|
||
| « sans EDF » / « complète » | choix manuel du soir, remis chaque jour à 12:00 |
|
||
| option A (04/10), puis son inverse (08/10) | voiture bloquée, puis non, quand EDF est fermé pour la batterie |
|
||
| voiture à midi (28/09, 06/10) | jour de départ JEEP, la batterie n'est pas du solaire |
|
||
| chauffe-eau jour faible (07/10) | eau chaude en HC sur EDF |
|
||
| charge maximale de midi (08/10) | batterie jour faible |
|
||
| la nuit prépare le soir (08/10) | batterie jour annoncé faible |
|
||
| courant ACM calculé (07/10) | 30 A fixes la nuit |
|
||
| consigne non tenue (07/10) | batterie à 3 A à midi |
|
||
|
||
Chaque règle est juste dans son cas. Les trous apparaissent **aux
|
||
croisements** : la HC de midi gérait la voiture, la nuit non ; le budget
|
||
voyait la batterie, pas la voiture ; le courant de la voiture n'a jamais été
|
||
pensé en fonction du temps restant. Cette nuit, la VW a attendu 01:24 → 05:14,
|
||
puis a chargé **à fond** de 05:17 à 07:24 parce qu'une correction est arrivée
|
||
tard. Le bon comportement était connu : **6 A dès 01:24, fini à 07:24**.
|
||
|
||
## 2. Le principe : une seule question, posée à chaque cycle
|
||
|
||
> **« Dans cette fenêtre d'heures creuses, qu'y a-t-il à donner, à qui, avant
|
||
> quand — et quelle puissance faut-il à chacun pour finir à temps, dans la
|
||
> limite de ce que l'abonnement laisse ? »**
|
||
|
||
Une fenêtre HC (nuit ou midi, sans distinction de code) a :
|
||
|
||
- une **ressource** : `P_libre(t) = 90 % × 12 kVA − maison (hors charges
|
||
pilotées)`, plus le solaire de jour (courant continu, en plus) ; bornée par les
|
||
140 A des deux MultiPlus et par 32 A à la borne ;
|
||
- une **fin** (07:24 ou 14:24) ;
|
||
- une liste de **besoins**, chacun avec une énergie, une échéance et une
|
||
priorité.
|
||
|
||
| besoin | énergie | échéance | d'où vient le chiffre |
|
||
|---|---|---|---|
|
||
| **batterie** | jusqu'à la cible du bilan (« tenir jusqu'à la prochaine HC », « préparer le soir », « charge maximale » les jours faibles) | fin de fenêtre | bilan, déjà calculé |
|
||
| **voiture branchée** | (100 − niveau) × capacité − déjà donné | min(fin de fenêtre, départ − marge) | niveau Uconnect (JEEP) ou saisi ; sinon « jusqu'au plein » avec la capacité mesurée |
|
||
| **chauffe-eau** (jour faible) | reprise mesurée (~2,1-2,3 kWh) | fin de fenêtre, BOOST | historique ECS |
|
||
| **voiture sur batterie** (ex-P12) | budget batterie au-dessus du plancher prudent | fin de fenêtre | bilan, déjà calculé |
|
||
|
||
**Allocation** (le cœur, une fonction pure) :
|
||
|
||
1. Pour chaque besoin, la puissance **minimale constante** qui finit à
|
||
l'échéance, plus une marge de 30 min (`énergie / (temps restant − 0,5 h)`).
|
||
C'est le « faible ampérage toute la nuit » : la VW à 6 A, la JEEP à 6-8 A.
|
||
2. Bornes physiques : voiture entre 6 A et 32 A (et sa propre limite ~16 A),
|
||
batterie ≤ 140 A, chauffe-eau tout ou rien.
|
||
3. Si la somme dépasse `P_libre`, on coupe selon un **ordre de priorité**
|
||
(à choisir par le propriétaire, voir §6) ; ce qui est coupé est reporté sur
|
||
le temps restant, donc la puissance remonte au cycle suivant.
|
||
4. Recalcul **à chaque cycle** : la maison qui monte (cuisine) réduit les
|
||
allocations, elle qui redescend les rend. Rattrapage automatique.
|
||
|
||
**Sorties**, toutes déduites du même plan, donc cohérentes par construction :
|
||
|
||
- courant de la borne (contrôleur EVCS) ;
|
||
- courant de charge de la batterie (ACM, DVCC) ;
|
||
- consigne réseau = maison + somme des allocations réseau ;
|
||
- contacteur : fermé pour **toute la fenêtre** dès qu'un besoin réseau existe
|
||
(engagement monotone, relâché à la fin de la fenêtre — la règle du 03/09, qui
|
||
ne crée pas d'oscillateur).
|
||
|
||
Ce qui disparaît : P7, la reprise réseau de nuit pour la voiture, l'option A et
|
||
son inverse, la règle voiture-à-midi dans sa forme actuelle, le courant
|
||
calculé de l'ACM (il devient une sortie du plan). Le choix « sans EDF /
|
||
complète » devient une **politique** du plan (« la voiture a-t-elle droit au
|
||
réseau en HC si personne d'autre n'en a besoin ? ») au lieu d'un interrupteur
|
||
qui pilote trois chemins différents.
|
||
|
||
Ce qui reste **inchangé** : toute la logique solaire de jour hors HC, les gardes
|
||
de sécurité (hystérésis 20/30, garde batterie en charge réseau bridée à 6 A,
|
||
plafonds BMS), le bilan (il fournit les énergies), le chauffe-eau hors HC.
|
||
|
||
## 3. Où il vit
|
||
|
||
- **Énergies et échéances : le bilan** (toutes les 5 min, il a la prévision et le
|
||
profil) publie un plan `input_text.evcs_plan_hc` : besoins, énergies,
|
||
échéances, priorités.
|
||
- **Allocation : le contrôleur** (toutes les 30 s, il a la maison en direct),
|
||
module pur `src/nodes/PLAN_HC.js`, appelé depuis `WINDOWS_SOURCEV2`.
|
||
- **ACM** : lit la part batterie du plan au lieu de recalculer.
|
||
|
||
## 4. Migration sans casser
|
||
|
||
1. **Ombre** (1 semaine) : le plan est calculé et publié à côté des décisions
|
||
réelles (`sensor.evcs_plan_hc_ombre` : « ce que j'aurais fait »), sans rien
|
||
commander. La revue du matin gagne un constat « écart entre le plan et le
|
||
réel » (ex. : voiture bloquée alors que le plan la chargeait à 6 A).
|
||
2. **Rejeu** sur les nuits historisées (`decision`, `mesure`, `session_charge`,
|
||
depuis le 04/09) : le plan aurait-il évité les incidents connus ?
|
||
3. **Bascule par besoin**, chacune derrière un interrupteur de retour arrière :
|
||
voiture de nuit d'abord, puis batterie (ACM), puis midi, puis chauffe-eau.
|
||
4. Retrait des anciennes règles une fois la bascule tenue deux semaines.
|
||
|
||
## 5. Critères d'acceptation (golden, avant toute bascule)
|
||
|
||
Les incidents réels deviennent les scénarios d'acceptation :
|
||
|
||
| incident | ce que le plan doit faire |
|
||
|---|---|
|
||
| 07→08/10, VW branchée, session de batterie | VW à 6 A de 01:24 à ~05:30, pleine avant 07:24 |
|
||
| 03→04/10, JEEP, budget 1,41 kWh | batterie protégée, JEEP sur réseau en HC à faible courant |
|
||
| 06/10 midi, JEEP départ 15:30 | réseau dès 12:24, JEEP finie avant 15:00 |
|
||
| 07/10 midi, jour faible, BOOST + cuisine | batterie au maximum que laisse l'abonnement |
|
||
| 05→06/10, JEEP départ 06:30, complète | JEEP finie à 06:00 à faible courant |
|
||
| nuit ensoleillée, rien à donner | contacteur ouvert, rien ne change |
|
||
|
||
## 6. Décisions à prendre par le propriétaire
|
||
|
||
1. **Ordre de priorité** quand l'abonnement ne suffit pas. Proposition :
|
||
sécurité batterie (plancher) > voiture avec départ dans la fenêtre >
|
||
batterie (cible) > chauffe-eau jour faible > voiture sans départ.
|
||
2. **Voiture dont le niveau est inconnu** (VW, ZERO sans saisie) : supposer
|
||
« vide » (capacité entière, le plan finit tôt) ou demander par WhatsApp
|
||
(l'arbitre, §7) ?
|
||
3. **Étaler ou finir tôt ?** Étaler (faible courant jusqu'à la fin − 30 min)
|
||
ménage la batterie de la voiture et l'abonnement ; finir tôt protège d'un
|
||
départ imprévu. Proposition : étaler, avec fin visée à **fin de fenêtre −
|
||
1 h** pour la voiture.
|
||
4. **« Sans EDF » garde-t-il un sens ?** Proposition : oui, comme politique —
|
||
« la voiture ne fait jamais fermer EDF à elle seule » — mais elle profite
|
||
toujours d'une session ouverte pour la batterie ou le chauffe-eau.
|
||
|
||
## 7. Et ce que le plan ne saura pas faire : l'arbitre
|
||
|
||
Le plan couvre les cas **prévus**. Pour le reste, l'arbitre encadré
|
||
(construit en parallèle, voir HANDOFF) : le code détecte une situation
|
||
incohérente en direct, publie une question à choix fermés, OpenClaw te
|
||
l'envoie, ta réponse est appliquée par le guichet d'ordres (liste blanche).
|
||
Chaque arbitrage est historisé ; un cas qui revient avec la même réponse
|
||
devient une règle du plan, après rejeu.
|
||
|
||
## 8. Effort estimé
|
||
|
||
| étape | contenu |
|
||
|---|---|
|
||
| A | `PLAN_HC.js` pur + 20 scénarios (dont §5) |
|
||
| B | publication du plan par le bilan + ombre dans le contrôleur + constat de revue |
|
||
| C | simulateur de rejeu sur les nuits historisées |
|
||
| D | bascule voiture de nuit, puis batterie, puis midi, puis chauffe-eau |
|
||
| E | retrait des anciennes règles, nettoyage des golden |
|
||
|
||
A + B : une session. C : une session. D et E s'étalent sur deux à trois semaines
|
||
d'observation.
|