Navigation : « EMS — moteur à règles » (pages de fonctionnalités, précédées de « Comment le moteur décide »), « Optimiseur » (Présentation, Protocole, Contrat, Écrire un optimiseur), « API » (ex-« Référence »). Aucun fichier existant déplacé : les URL publiées restent valides. Protocole : prose courte qui renvoie à OPTIMIZER_PROTOCOL.md du moteur pour le sens ; tableaux, listes fermées et règles nommées générés depuis le contrat. Contrat servi tel quel (copie octet pour octet). reference.md, resté un bouchon, devient l'accueil de la section API. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
86 lines
4.5 KiB
Markdown
86 lines
4.5 KiB
Markdown
# Comment le moteur décide
|
|
|
|
<span class="badge community">COMMUNITY</span>
|
|
|
|
Le moteur d'énergie de la box pilote seul vos charges : bornes de recharge, chauffe-eau,
|
|
pompe à chaleur SG-Ready, relais. Il est libre (GPL-3.0) et c'est lui qui décide dans la
|
|
version **Community**. Cette page décrit sa logique pour l'installateur et l'intégrateur ;
|
|
les pages suivantes détaillent chaque fonction.
|
|
|
|
## Deux boucles, deux priorités
|
|
|
|
Le moteur sépare la sécurité de la répartition. Ce sont deux boucles distinctes, qui ne
|
|
tournent pas au même rythme et n'ont pas la même priorité.
|
|
|
|
- **La boucle de sécurité, en temps réel.** À chaque variation du bilan mesuré, elle lit
|
|
le courant de chaque phase au compteur de tête. Si une phase dépasse la limite
|
|
configurée, elle réduit immédiatement les charges ([délestage](delestage.md)), puis
|
|
relâche quand la marge revient. Elle n'attend pas le cycle et prime sur tout le reste.
|
|
- **Le cycle de répartition, environ une fois par minute.** Il répartit la puissance
|
|
disponible entre les charges. C'est le seul endroit où une stratégie intervient : les
|
|
règles intégrées, ou un [optimiseur](../optimiseur/index.md) s'il est branché.
|
|
|
|
Si le compteur de tête ne répond plus, le moteur suspend la répartition et passe en repli
|
|
de sécurité : sans mesure, il ne décide pas.
|
|
|
|
## Les règles, dans l'ordre
|
|
|
|
À chaque cycle, le moteur applique les mêmes étapes, dans le même ordre.
|
|
|
|
1. **Mesurer.** Le point de départ est ce que mesure le compteur de tête. Le moteur y
|
|
rajoute ce que consomment déjà les charges qu'il pilote : une charge en marche n'est
|
|
pas comptée contre elle-même.
|
|
2. **Tenir compte de ce qui est figé.** Une charge sous verrou (durée minimale de marche
|
|
ou d'arrêt, délai entre deux changements de courant) garde sa puissance engagée, et
|
|
celle-ci est retirée du budget. Une charge indisponible ne reçoit aucune consigne, mais
|
|
ce qu'elle consomme reste compté.
|
|
3. **Servir les besoins à échéance.** Une obligation quotidienne (par exemple une énergie
|
|
minimale pour le chauffe-eau avant une heure donnée) ou une demande ponctuelle faite
|
|
depuis l'application peut, quand l'échéance approche et que le surplus n'a pas suffi,
|
|
prendre le complément sur le réseau — si l'installateur l'a autorisé.
|
|
4. **Répartir le surplus en cascade.** Les charges sont servies dans l'ordre de
|
|
**priorité** que vous avez fixé (1 = servie en premier). Chacune reçoit ce qui reste du
|
|
budget, dans ses bornes, et le budget est décrémenté d'autant. Le budget est **unique** :
|
|
sans lui, trois gestionnaires verraient chacun « 2 kW de surplus » et en tireraient 6.
|
|
5. **Arrêter ce qui ne peut pas démarrer.** Sous sa puissance minimale, une charge reste
|
|
arrêtée plutôt que de fonctionner à moitié.
|
|
|
|
### Les bornes de chaque charge
|
|
|
|
Chaque charge porte des bornes saisies par l'installateur, que **toute** décision
|
|
respecte, quelle que soit la stratégie :
|
|
|
|
- un **plancher** et un **plafond** de puissance (ou de courant, pour une borne) ;
|
|
- des **verrous anti-battement** : durée minimale de marche et d'arrêt, délai entre deux
|
|
changements ;
|
|
- pour une PAC SG-Ready : l'état choisi selon la puissance estimée de chaque état, avec
|
|
une durée minimale de maintien.
|
|
|
|
## Le motif de chaque décision
|
|
|
|
Le moteur ne prend aucune décision sans en dire la raison. Chaque décision porte un
|
|
**motif** (`decisionReason`) non vide : un code stable et ses paramètres, que
|
|
l'application affiche dans votre langue — « surplus insuffisant », « sous la puissance
|
|
minimale », « échéance de recharge »… La liste des codes est publiée avec le
|
|
[protocole optimiseur](../optimiseur/protocole.md#reponse).
|
|
|
|
## La mesure, jamais le résultat du pilotage
|
|
|
|
Le surplus est calculé sur la **mesure brute** : production et compteur, tels qu'ils
|
|
sont mesurés. Jamais sur le bilan net après pilotage : le moteur se lirait lui-même et
|
|
oscillerait.
|
|
|
|
## Sans internet
|
|
|
|
Tout ce qui précède tourne sur la box. Sans internet, le moteur pilote, applique la
|
|
sécurité et répond à l'application sur votre réseau local. Seule la
|
|
[prévision PV](prevision-pv.md) s'interrompt — et elle ne sert pas à décider dans la
|
|
version Community, pas plus que le [tarif saisi](../tarifs.md) : tous deux sont affichés
|
|
et enregistrés, jamais utilisés par les règles.
|
|
|
|
## Et un optimiseur ?
|
|
|
|
Un optimiseur peut proposer un plan sur plusieurs heures, à partir des prévisions. Il
|
|
remplace l'étape de répartition, **jamais** la boucle de sécurité ni les bornes. Voir la
|
|
section [Optimiseur](../optimiseur/index.md).
|