From e6a5f50467a1c64f4193897dbe5d17319b4f422c Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sun, 18 Oct 2026 13:54:11 +0200 Subject: [PATCH] =?UTF-8?q?docs(moteur):=20=C2=AB=20Comment=20le=20moteur?= =?UTF-8?q?=20d=C3=A9cide=20=C2=BB=20align=C3=A9=20sur=20le=20code=20des?= =?UTF-8?q?=20r=C3=A8gles?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Relu contre le moteur (main 61db6cf) : en temps réel la protection ne bride que les bornes, les autres charges sont délestées au cycle suivant ; cycle chaque minute ; repli à 90 s de silence du compteur, états sûrs. Ordre réel : mesure et marge de soutirage, échéances VE, réserve batterie, passe éco (demandes ponctuelles puis obligations étalées) avant la cascade confort ; recrédit, plancher, verrous et indisponibilité appliqués charge par charge ; une commande par charge. Retiré : « si l'installateur l'a autorisé » (aucune autorisation dédiée). Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01Ry3vBrJT1tHdxAaXdCWi6L --- docs/fonctionnalites/moteur.de.md | 101 +++++++++++++++---------- docs/fonctionnalites/moteur.en.md | 121 ++++++++++++++++++------------ docs/fonctionnalites/moteur.md | 98 +++++++++++++++--------- docs/optimiseur/index.de.md | 3 +- docs/optimiseur/index.en.md | 3 +- docs/optimiseur/index.md | 4 +- 6 files changed, 204 insertions(+), 126 deletions(-) diff --git a/docs/fonctionnalites/moteur.de.md b/docs/fonctionnalites/moteur.de.md index a3f238b..68f8f90 100644 --- a/docs/fonctionnalites/moteur.de.md +++ b/docs/fonctionnalites/moteur.de.md @@ -12,51 +12,76 @@ Integratoren; die folgenden Seiten erläutern die einzelnen Funktionen. Die Engine trennt Sicherheit und Verteilung. Es sind zwei getrennte Schleifen, mit unterschiedlichem Takt und unterschiedlicher Priorität. -- **Die Sicherheitsschleife, in Echtzeit.** Bei jeder Änderung der gemessenen Bilanz liest - sie den Strom jeder Phase am Netzanschlusszähler. Überschreitet eine Phase die - eingestellte Grenze, regelt sie die Verbraucher sofort ab ([Lastabwurf](delestage.md)) - und gibt wieder frei, sobald genug Reserve da ist. Sie wartet nicht auf den Zyklus und - hat Vorrang vor allem anderen. -- **Der Verteilungszyklus, etwa einmal pro Minute.** Er verteilt die verfügbare Leistung - auf die Verbraucher. Nur hier greift eine Strategie ein: die eingebauten Regeln oder, - falls angeschlossen, ein [Optimierer](../optimiseur/index.md). +- **Der Überlastschutz, bei jeder Messung.** Sobald sich die gemessene Bilanz ändert, + liest die Engine den Strom jeder Phase am Netzanschlusszähler. Überschreitet eine Phase + die eingestellte Grenze, senkt sie **sofort** den Ladestrom der Wallboxen und gibt ihn + wieder frei, sobald genug Reserve da ist. Die übrigen Verbraucher (Warmwasserbereiter, + Wärmepumpe, Relais) werden zu Beginn des nächsten Zyklus abgeworfen + ([Lastabwurf](delestage.md)). Dieser Schutz hat Vorrang vor jeder + Verteilungsentscheidung. +- **Der Verteilungszyklus, jede Minute.** Er verteilt die verfügbare Leistung auf die + Verbraucher, auf Basis der Minutenmessung der elektrischen Bilanz, und läuft sofort + erneut, wenn Sie eine Einstellung ändern. Nur hier greift eine Strategie ein: die + eingebauten Regeln oder, falls angeschlossen, ein [Optimierer](../optimiseur/index.md). -Antwortet der Netzanschlusszähler nicht mehr, setzt die Engine die Verteilung aus und geht -in den Sicherheits-Rückfall: ohne Messung keine Entscheidung. +**Schweigt der Netzanschlusszähler** (mehr als 90 s ohne Messwert), setzt die Engine die +Verteilung aus und bringt die Verbraucher in eine sichere Stellung: regelbare Verbraucher +auf 0 W, Relais offen, Wärmepumpe im Normalbetrieb, bereits ladende Wallboxen auf +Mindeststrom, kein neuer Verbraucher wird gestartet. Der Überlastschutz bleibt aktiv. Die +Verteilung setzt im Zyklus nach der Rückkehr des Zählers wieder ein. ## Die Regeln, in ihrer Reihenfolge In jedem Zyklus durchläuft die Engine dieselben Schritte, in derselben Reihenfolge. -1. **Messen.** Ausgangspunkt ist der Messwert des Netzanschlusszählers. Die Engine rechnet - hinzu, was die von ihr gesteuerten Verbraucher bereits aufnehmen: Ein laufender - Verbraucher wird nicht gegen sich selbst gerechnet. -2. **Berücksichtigen, was festliegt.** Ein gesperrter Verbraucher (Mindestlauf- oder - Mindeststillstandszeit, Wartezeit zwischen zwei Stromänderungen) behält seine - zugesagte Leistung, und sie wird vom Budget abgezogen. Ein nicht verfügbarer - Verbraucher erhält keinen Sollwert, sein Verbrauch wird aber weiter gezählt. -3. **Bedarfe mit Frist bedienen.** Eine tägliche Pflicht (etwa eine Mindestenergie für den - Warmwasserbereiter bis zu einer bestimmten Uhrzeit) oder eine einmalige Anforderung aus - der App kann, wenn die Frist naht und der Überschuss nicht gereicht hat, den Rest aus - dem Netz beziehen — sofern der Installateur das erlaubt hat. -4. **Den Überschuss kaskadiert verteilen.** Die Verbraucher werden in der von Ihnen - festgelegten **Priorität** bedient (1 = zuerst). Jeder erhält, was vom Budget übrig - ist, innerhalb seiner Grenzen, und das Budget wird entsprechend verringert. Es gibt - **ein einziges** Budget: Ohne es sähen drei Manager jeweils „2 kW Überschuss“ und - zögen zusammen 6. -5. **Abschalten, was nicht starten kann.** Unterhalb seiner Mindestleistung bleibt ein - Verbraucher aus, statt halb zu laufen. +1. **Messen.** Ausgangspunkt ist der Messwert des Netzanschlusszählers (Einspeisung und + Bezug). Daraus leitet die Engine auch den **Bezugsspielraum** ab: was die Anlage noch + aus dem Netz beziehen kann, ohne die Phasengrenze zu überschreiten. Kein Netzbezug, + gleich aus welchem Grund, geht darüber hinaus. +2. **Ladefristen bedienen.** Ein Fahrzeug, das bis zu einer bestimmten Uhrzeit geladen + sein muss, wird aus dem Netz bedient, außerhalb der Überschussverteilung. +3. **Die Batterie schützen.** Liegt ein Hausspeicher unter seiner Reserveschwelle, geht der + Überschuss zuerst an ihn: Die gesteuerten Verbraucher erhalten nichts davon. Oberhalb + der Schwelle zählt, was er aufnimmt, als verfügbarer Überschuss. Seine Entladung wird + nie als Überschuss gezählt. +4. **Zugesicherte Bedarfe („Eco“-Durchlauf).** Zuerst die **einmaligen Anforderungen** aus + der App („jetzt heizen“): Der Verbraucher erhält seine volle Leistung, unabhängig von + seinem Rang. Danach die **täglichen Pflichten**, etwa eine Mindestenergie für den + Warmwasserbereiter bis zu einer bestimmten Uhrzeit: Die Engine kauft das Fehlende aus + dem Netz, gleichmäßig bis zur Frist verteilt, und schaltet auf volle Leistung, wenn nur + noch die gerade nötige Zeit bleibt. Diese Bezüge bleiben im Bezugsspielraum. +5. **Den Überschuss kaskadiert verteilen („Komfort“-Durchlauf).** Die Verbraucher werden + in der von Ihnen festgelegten **Priorität** bedient (1 = zuerst). Jeder erhält, was vom + Budget übrig ist, innerhalb seiner Grenzen, und das Budget wird entsprechend + verringert. Es gibt **ein einziges** Budget: Ohne es sähen drei Manager jeweils „2 kW + Überschuss“ und zögen zusammen 6. Der Reihe nach, für jeden Verbraucher: + - was er bereits aufnimmt, wird ihm gutgeschrieben: Ein laufender Verbraucher wird + nicht gegen sich selbst gerechnet; + - unterhalb seiner Mindestleistung bleibt er aus, statt halb zu laufen, und das Budget + geht an den nächsten. Eine Wallbox kann dennoch mit einem kleinen Zuschuss aus dem + Netz starten, innerhalb der eingestellten Toleranz; + - ein **gesperrter** Verbraucher (Mindestlauf- oder Mindeststillstandszeit, Wartezeit + zwischen zwei Änderungen) behält seine aktuelle Leistung; + - ein **nicht verfügbarer** Verbraucher behält seine aktuelle Leistung, ohne neuen + Sollwert; sein Verbrauch wird weiter gezählt. +6. **Ein Befehl pro Verbraucher.** Zugesicherter Bedarf und Überschussanteil desselben + Verbrauchers werden zusammengeführt: Jeder Verbraucher erhält einen einzigen Sollwert, + mit seinem Grund. ### Die Grenzen jedes Verbrauchers Jeder Verbraucher hat vom Installateur eingetragene Grenzen, die **jede** Entscheidung einhält, gleich welche Strategie: -- eine **Unter-** und eine **Obergrenze** der Leistung (bzw. des Stroms bei einer Wallbox); +- eine **Unter-** und eine **Obergrenze** der Leistung. Bei einer Wallbox sind sie als + Strom angegeben (mal Anzahl der Phasen), und die Obergrenze wird zusätzlich durch die + Phasengrenze beschränkt; - **Sperren gegen Takten**: Mindestlauf- und Mindeststillstandszeit, Wartezeit zwischen - zwei Änderungen; + zwei Änderungen. Eine Wallbox hat eigene (Wartezeit zwischen Ein und Aus, Wartezeit + zwischen zwei Stromänderungen); - bei einer SG-Ready-Wärmepumpe: der Zustand wird nach der geschätzten Leistung jedes - Zustands gewählt, mit einer Mindesthaltedauer. + Zustands gewählt, mit Hysterese und Mindesthaltedauer. Der Sperrzustand wird nie durch + den Überschuss ausgelöst. ## Der Grund jeder Entscheidung @@ -68,20 +93,20 @@ Mindestleistung“, „Ladefrist“… Die Liste der Codes ist mit dem ## Die Messung, nie das Ergebnis der Steuerung -Der Überschuss wird aus der **Rohmessung** berechnet: Erzeugung und Zähler, so wie sie -gemessen werden. Nie aus der Nettobilanz nach der Steuerung: Die Engine würde sich selbst -lesen und schwingen. +Der Überschuss wird aus der **Rohmessung** des Netzanschlusszählers berechnet, so wie sie +gemessen wird. Nie aus einer nach der Steuerung neu berechneten Bilanz: Die Engine würde +sich selbst lesen und schwingen. ## Ohne Internet All das läuft auf der Box. Ohne Internet steuert die Engine, wendet die Sicherheit an und antwortet der App in Ihrem lokalen Netz. Nur die [PV-Prognose](prevision-pv.md) setzt -aus — und sie dient in der Community-Version nicht zur Entscheidung, ebenso wenig wie der -[eingegebene Tarif](../tarifs.md): Beide werden angezeigt und gespeichert, aber von den -Regeln nie verwendet. +aus. In der Community-Version fließen weder die Prognose noch der +[eingegebene Tarif](../tarifs.md) in die Entscheidungen der Regeln ein: Beide werden +angezeigt und gespeichert, aber nie zum Entscheiden verwendet. ## Und ein Optimierer? Ein Optimierer kann anhand der Prognosen einen Plan über mehrere Stunden vorschlagen. Er -ersetzt den Verteilungsschritt, **nie** die Sicherheitsschleife oder die Grenzen. Siehe +ersetzt den Verteilungsschritt, **nie** den Überlastschutz oder die Grenzen. Siehe Abschnitt [Optimierer](../optimiseur/index.md). diff --git a/docs/fonctionnalites/moteur.en.md b/docs/fonctionnalites/moteur.en.md index d0903d3..0ce2bc2 100644 --- a/docs/fonctionnalites/moteur.en.md +++ b/docs/fonctionnalites/moteur.en.md @@ -3,80 +3,105 @@ COMMUNITY The box's energy engine drives your loads on its own: EV chargers, water heater, -SG-Ready heat pump, relays. It is free software (GPL-3.0) and it is what decides in the -**Community** edition. This page describes its logic for installers and integrators; the -following pages detail each feature. +SG-Ready heat pump, relays. It is free software (GPL-3.0) and it is the one that decides +in the **Community** edition. This page describes its logic for installers and +integrators; the following pages detail each feature. ## Two loops, two priorities The engine keeps safety apart from allocation. They are two separate loops, running at different rates and with different priorities. -- **The safety loop, in real time.** On every change in the measured balance, it reads the - current of each phase at the grid meter. If a phase exceeds the configured limit, it - cuts loads back immediately ([load shedding](delestage.md)), then releases them once - there is headroom again. It does not wait for the cycle and overrides everything else. -- **The allocation cycle, about once a minute.** It shares the available power between - the loads. This is the only place a strategy acts: the built-in rules, or an - [optimizer](../optimiseur/index.md) if one is connected. +- **Overload protection, on every measurement.** As soon as the measured balance + changes, the engine reads the current of each phase at the grid meter. If a phase + exceeds the configured limit, it **immediately** lowers the current of the EV chargers, + then releases it when the margin returns. The other loads (water heater, heat pump, + relays) are shed at the start of the next cycle ([load management](delestage.md)). This + protection overrides any allocation decision. +- **The allocation cycle, every minute.** It shares the available power between the + loads, on the one-minute measurement of the electrical balance, and runs again right + away when you change a setting. It is the only place where a strategy comes in: the + built-in rules, or an [optimizer](../optimiseur/index.md) if one is connected. -If the grid meter stops answering, the engine suspends allocation and falls back to safety -mode: no measurement, no decision. +**If the grid meter goes silent** (more than 90 s without a reading), the engine suspends +allocation and puts the loads in a safe position: adjustable loads at 0 W, relays open, +heat pump in normal operation, chargers already charging brought down to minimum +current, no new load started. Overload protection stays active. Allocation resumes on the +cycle after the meter comes back. ## The rules, in order -On every cycle, the engine runs the same steps, in the same order. +On every cycle, the engine applies the same steps, in the same order. -1. **Measure.** The starting point is what the grid meter measures. The engine adds back - what the loads it drives are already drawing: a running load is not counted against - itself. -2. **Account for what is locked.** A load under a lock (minimum on or off time, delay - between two current changes) keeps the power it has committed, and that power is taken - out of the budget. An unavailable load receives no setpoint, but what it draws is still - counted. -3. **Serve needs with a deadline.** A daily obligation (for example a minimum energy for - the water heater before a given time) or a one-off request made from the app may, as - the deadline nears and the surplus has not been enough, take the remainder from the - grid — if the installer has allowed it. -4. **Cascade the surplus.** Loads are served in the **priority** order you set (1 = served - first). Each receives what is left of the budget, within its bounds, and the budget is - reduced accordingly. There is **one** budget: without it, three managers would each see - "2 kW of surplus" and draw 6 between them. -5. **Stop what cannot start.** Below its minimum power, a load stays off rather than - running at half. +1. **Measure.** The starting point is what the grid meter measures (export and import). + The engine also derives the **draw margin** from it: what the installation can still + take from the grid without exceeding the phase limit. No grid purchase, whatever its + reason, goes beyond it. +2. **Serve charging deadlines.** A vehicle that must be charged by a given time is served + from the grid, outside the surplus sharing. +3. **Protect the battery.** If a home battery is below its reserve threshold, the surplus + goes to it first: the controlled loads get none of it. Above the threshold, what it + absorbs counts as available surplus. Its discharge is never counted as surplus. +4. **Guaranteed needs ("eco" pass).** First the **one-off requests** made from the app + ("heat now"): the load gets its full power, whatever its rank. Then the **daily + obligations**, for example a minimum amount of energy for the water heater before a + given time: the engine buys the missing energy from the grid, spread evenly until the + deadline, and switches to full power when only the time strictly needed is left. These + purchases stay within the draw margin. +5. **Share the surplus in cascade ("comfort" pass).** Loads are served in the + **priority** order you set (1 = served first). Each receives what is left of the + budget, within its bounds, and the budget is decreased accordingly. There is **one** + budget: without it, three managers would each see "2 kW of surplus" and draw 6. In + turn, for each load: + - what it already consumes is given back to it: a running load is not counted against + itself; + - below its minimum power, it stays off rather than running at half power, and the + budget moves on to the next one. An EV charger may still start with a small top-up + from the grid, within the configured tolerance; + - a load under **lock** (minimum on or off time, delay between two changes) keeps its + current power; + - an **unavailable** load keeps its current power, with no new setpoint; what it + consumes is still counted. +6. **One command per load.** The guaranteed need and the surplus share of the same load + are merged: each load receives a single setpoint, with its reason. ### The bounds of each load Each load carries bounds entered by the installer, which **every** decision respects, whatever the strategy: -- a power **floor** and **ceiling** (or current, for an EV charger); -- **anti-flapping locks**: minimum on and off time, delay between two changes; -- for an SG-Ready heat pump: the state is chosen from the estimated power of each state, - with a minimum hold time. +- a power **floor** and **ceiling**. For an EV charger they are in current (times the + number of phases), and the ceiling is further capped by the phase limit; +- **anti-flapping locks**: minimum on and off time, delay between two changes. An EV + charger has its own (delay between on and off, delay between two current changes); +- for an SG-Ready heat pump: the state chosen from the estimated power of each state, + with hysteresis and a minimum hold time. The blocking state is never commanded by the + surplus. ## The reason for every decision -The engine takes no decision without stating why. Every decision carries a non-empty -**reason** (`decisionReason`): a stable code and its parameters, which the app displays in -your language — "surplus insufficient", "below minimum power", "charging deadline"… The -list of codes is published with the [optimizer protocol](../optimiseur/protocole.md#reponse). +The engine makes no decision without stating why. Every decision carries a non-empty +**reason** (`decisionReason`): a stable code and its parameters, which the app displays +in your language — "insufficient surplus", "below minimum power", "charging deadline"… +The list of codes is published with the +[optimizer protocol](../optimiseur/protocole.md#reponse). ## The measurement, never the result of control -Surplus is computed from the **raw measurement**: production and meter, as measured. Never -from the net balance after control: the engine would be reading itself, and oscillate. +The surplus is computed on the **raw measurement** of the grid meter, as measured. Never +on a balance recomputed after control: the engine would be reading itself and would +oscillate. ## Without internet -All of the above runs on the box. Without internet, the engine keeps driving the loads, -enforces safety and answers the app on your local network. Only the -[PV forecast](prevision-pv.md) stops — and it is not used for decisions in the Community -edition, any more than the [entered tariff](../tarifs.md): both are displayed and -recorded, never used by the rules. +Everything above runs on the box. Without internet, the engine controls, applies safety +and answers the app on your local network. Only the [PV forecast](prevision-pv.md) +stops. In the Community edition, neither the forecast nor the +[entered tariff](../tarifs.md) enters the decisions of the rules: both are displayed and +recorded, never used to decide. -## What about an optimizer? +## And an optimizer? -An optimizer can propose a plan over several hours, based on the forecasts. It replaces -the allocation step, **never** the safety loop or the bounds. See the +An optimizer can propose a plan over several hours, based on forecasts. It replaces the +allocation step, **never** the overload protection or the bounds. See the [Optimizer](../optimiseur/index.md) section. diff --git a/docs/fonctionnalites/moteur.md b/docs/fonctionnalites/moteur.md index 3a3ca92..29e1b6c 100644 --- a/docs/fonctionnalites/moteur.md +++ b/docs/fonctionnalites/moteur.md @@ -12,49 +12,75 @@ les pages suivantes détaillent chaque fonction. 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é. +- **La protection contre la surcharge, à chaque mesure.** Dès que le bilan mesuré change, + le moteur lit le courant de chaque phase au compteur de tête. Si une phase dépasse la + limite configurée, il réduit **immédiatement** le courant des bornes de recharge, puis + le relâche quand la marge revient. Les autres charges (chauffe-eau, pompe à chaleur, + relais) sont délestées au début du cycle suivant ([délestage](delestage.md)). Cette + protection prime sur toute décision de répartition. +- **Le cycle de répartition, chaque minute.** Il répartit la puissance disponible entre + les charges, sur la mesure d'une minute du bilan électrique, et repart aussitôt quand + vous changez un réglage. 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. +**Si le compteur de tête se tait** (plus de 90 s sans mesure), le moteur suspend la +répartition et met les charges en position sûre : charges réglables à 0 W, relais +ouverts, pompe à chaleur en fonctionnement normal, bornes déjà en charge ramenées au +courant minimum, aucune nouvelle charge démarrée. La protection contre la surcharge reste +active. La répartition reprend au cycle qui suit le retour du compteur. ## 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é. +1. **Mesurer.** Le point de départ est ce que mesure le compteur de tête (injection et + soutirage). Le moteur en tire aussi la **marge de soutirage** : ce que l'installation + peut encore prendre au réseau sans dépasser la limite de phase. Aucun achat au réseau, + quelle qu'en soit la raison, ne la dépasse. +2. **Servir les recharges à échéance.** Un véhicule qui doit être chargé pour une heure + donnée est servi sur le réseau, hors du partage du surplus. +3. **Protéger la batterie.** Si une batterie domestique est sous son seuil de réserve, le + surplus lui revient d'abord : les charges pilotées n'en reçoivent pas. Au-dessus du + seuil, ce qu'elle absorbe compte comme surplus disponible. Sa décharge n'est jamais + comptée comme du surplus. +4. **Les besoins garantis (passe « éco »).** D'abord les **demandes ponctuelles** faites + depuis l'application (« chauffer maintenant ») : la charge reçoit sa pleine puissance, + quel que soit son rang. Ensuite les **obligations quotidiennes**, par exemple une + énergie minimale pour le chauffe-eau avant une heure donnée : le moteur achète au + réseau ce qui manque, réparti régulièrement jusqu'à l'échéance, et passe à pleine + puissance quand il ne reste plus que le temps juste nécessaire. Ces achats restent dans + la marge de soutirage. +5. **Partager le surplus en cascade (passe « confort »).** 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. À son tour, pour chaque charge : + - ce qu'elle consomme déjà lui est rendu : une charge en marche n'est pas comptée + contre elle-même ; + - sous sa puissance minimale, elle reste arrêtée plutôt que de fonctionner à moitié, + et le budget passe à la suivante. Une borne de recharge peut toutefois démarrer avec + un petit complément pris au réseau, dans la tolérance réglée ; + - une charge sous **verrou** (durée minimale de marche ou d'arrêt, délai entre deux + changements) garde sa puissance du moment ; + - une charge **indisponible** garde sa puissance actuelle, sans nouvelle consigne ; ce + qu'elle consomme reste compté. +6. **Une seule commande par charge.** Le besoin garanti et la part de surplus d'une même + charge sont fusionnés : chaque charge reçoit une seule consigne, avec son motif. ### 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) ; +- un **plancher** et un **plafond** de puissance. Pour une borne de recharge, ils sont en + courant (multiplié par le nombre de phases), et le plafond est en plus limité par la + limite de phase ; - des **verrous anti-battement** : durée minimale de marche et d'arrêt, délai entre deux - changements ; + changements. Une borne de recharge a les siens (délai entre marche et arrêt, délai entre + deux changements de courant) ; - pour une PAC SG-Ready : l'état choisi selon la puissance estimée de chaque état, avec - une durée minimale de maintien. + une hystérésis et une durée minimale de maintien. L'état de blocage n'est jamais + commandé par le surplus. ## Le motif de chaque décision @@ -66,20 +92,20 @@ minimale », « échéance de recharge »… La liste des codes est publiée ave ## 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 +Le surplus est calculé sur la **mesure brute** du compteur de tête, telle qu'elle est +mesurée. Jamais sur un bilan recalculé 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. +[prévision PV](prevision-pv.md) s'interrompt. Dans la version Community, ni la prévision +ni le [tarif saisi](../tarifs.md) n'entrent dans les décisions des règles : tous deux +sont affichés et enregistrés, jamais utilisés pour décider. ## 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). +remplace l'étape de répartition, **jamais** la protection contre la surcharge ni les +bornes. Voir la section [Optimiseur](../optimiseur/index.md). diff --git a/docs/optimiseur/index.de.md b/docs/optimiseur/index.de.md index 8fbe1fb..3577c25 100644 --- a/docs/optimiseur/index.de.md +++ b/docs/optimiseur/index.de.md @@ -20,7 +20,8 @@ Abend lassen usw. - Die Engine führt nur das **aktuelle Zeitfenster** des Plans aus. Der Rest wird als Prognose angezeigt und im nächsten Zyklus neu angefragt. - Jeder Sollwert wird durch die Grenzen des Verbrauchers (Unter-, Obergrenze, Sperren - gegen Takten) und durch die **Sicherheitsschleife** in Echtzeit **gedeckelt**; diese + gegen Takten) und durch den **Überlastschutz** ([Wie die Engine + entscheidet](../fonctionnalites/moteur.md)) **gedeckelt**; diese bleibt bei der Engine und hat Vorrang vor allem. Ein Optimierer kann keine Sperre umgehen. - Jede Aktion muss ihren **Grund** tragen. Eine Aktion ohne Grund wird verworfen. diff --git a/docs/optimiseur/index.en.md b/docs/optimiseur/index.en.md index 80d0a72..92800c7 100644 --- a/docs/optimiseur/index.en.md +++ b/docs/optimiseur/index.en.md @@ -18,7 +18,8 @@ expected production peak, keep headroom for evening charging, and so on. - The engine only executes the **current slot** of the plan. The rest is shown as a forecast, and requested again on the next cycle. - Every setpoint is **capped** by the load's bounds (floor, ceiling, anti-flapping locks) - and by the real-time **safety loop**, which stays with the engine and overrides + and by the **overload protection** ([How the engine + decides](../fonctionnalites/moteur.md)), which stays with the engine and overrides everything. An optimizer cannot bypass a lock. - Every action must carry its **reason**. An action without one is rejected. - A malformed plan, or one that targets an unknown load, is rejected as a whole. diff --git a/docs/optimiseur/index.md b/docs/optimiseur/index.md index de15c0a..f5097bb 100644 --- a/docs/optimiseur/index.md +++ b/docs/optimiseur/index.md @@ -19,8 +19,8 @@ pic de production prévu, garder de la marge pour la recharge du soir, etc. - Le moteur n'exécute que le **créneau en cours** du plan. Le reste est affiché comme prévision, et redemandé au cycle suivant. - Chaque consigne est **plafonnée** par les bornes de la charge (plancher, plafond, - verrous anti-battement) et par la **boucle de sécurité** en temps réel, qui reste au - moteur et prime sur tout. Un optimiseur ne peut pas contourner un verrou. + verrous anti-battement) et par la **protection contre la surcharge** ([Comment le moteur + décide](../fonctionnalites/moteur.md)), qui reste au moteur et prime sur tout. Un optimiseur ne peut pas contourner un verrou. - Chaque action doit porter son **motif**. Une action sans motif est rejetée. - Un plan mal formé, ou qui vise une charge inconnue, est refusé en entier.