Verbrauchermodule und betriebsartabhängige Angebote ergänzen

docs/Schnittstelle.md

@@ -1,6 +1,6 @@
 # EMS-Schnittstelle
 
-Vertragsversion: `3.0`
+Vertragsversion: `4.0`
 
 Es gibt genau eine fachliche Empfangsmethode je Richtung:
 
@@ -13,7 +13,7 @@ public function VerbraucherdatenEmpfangen(array $daten): void;
 
 | Feld | Typ | Bedeutung |
 | --- | --- | --- |
-| `Version` | Text | Vertragsversion `3.0` |
+| `Version` | Text | Vertragsversion `4.0` |
 | `AbsenderID` | Ganzzahl | Sendende Symcon-Instanz |
 | `EmpfaengerID` | Ganzzahl | Empfangende Symcon-Instanz |
 | `Zeitpunkt` | Ganzzahl | Unixzeit in UTC |
@@ -23,118 +23,119 @@ public function VerbraucherdatenEmpfangen(array $daten): void;
 ```json
 {
   "Kopf": {
-    "Version": "3.0",
+    "Version": "4.0",
     "AbsenderID": 10001,
     "EmpfaengerID": 20001,
     "Zeitpunkt": 1788825600
   },
+  "Betriebsart": "PV",
   "Sollleistung_W": 1501
 }
 ```
 
-`Sollleistung_W` ist immer eine Ganzzahl und muss im aktuell gemeldeten Leistungsangebot liegen.
+`Betriebsart` ist `PV` oder `Peak`. `Sollleistung_W` ist eine Ganzzahl
+aus dem fuer diese Betriebsart gemeldeten Leistungsangebot oder `null`.
+
+`null` kuendigt nur die Betriebsart an. Der Verbraucher uebernimmt sie,
+berechnet sein Leistungsangebot neu und meldet es zurueck. Eine vorhandene
+Sollleistung wird dabei nur verworfen, wenn sie im neuen Angebot nicht mehr
+zulaessig ist.
 
 ## Verbraucher an Manager
 
 ```json
 {
   "Kopf": {
-    "Version": "3.0",
+    "Version": "4.0",
     "AbsenderID": 20001,
     "EmpfaengerID": 10001,
     "Zeitpunkt": 1788825602
   },
+  "Betriebsart": "Peak",
   "PrioritaetPV": 0,
   "PrioritaetPeak": 0,
-  "Leistungswerte_W": [
-    -3000,
-    -2000,
-    {"Von_W": -1000, "Bis_W": -500},
-    0,
-    100,
-    {"Von_W": 1000, "Bis_W": 2000},
-    3000
-  ],
-  "AenderungMoeglich": true,
+  "Leistungswerte_W": [0],
+  "AenderungMoeglich": false,
   "Verfuegbar": true,
-  "Istleistung_W": 1498.5,
-  "Leistungsquelle": 2,
+  "Istleistung_W": 0,
+  "Leistungsquelle": 1,
   "Zustand": [
     {
       "Kennung": "Sollleistung_W",
       "Art": "Sollwert",
-      "Wert": 1501,
+      "Wert": 0,
       "Einheit": "W"
     }
   ]
 }
 ```
 
-### Feste Regeln
+## Betriebsart-Synchronisation
 
-- Prioritaeten beginnen bei 0; eine kleinere Zahl bedeutet eine hoehere Prioritaet.
+1. Der Manager bestimmt `PV` oder `Peak`.
+2. Meldungen einer anderen Betriebsart werden nicht zur Verteilung verwendet.
+3. Der Manager sendet diesen Verbrauchern eine Betriebsart-Ankuendigung mit
+   `Sollleistung_W=null`.
+4. Jeder Verbraucher berechnet und meldet seine PowerSteps fuer diese
+   Betriebsart.
+5. Erst wenn alle aktiven Verbraucher synchronisiert sind, verteilt der Manager
+   Sollleistungen.
+
+Damit kann jeder Verbrauchertyp unterschiedliche Angebote fuer PV und Peak
+melden, ohne dass der Manager seine interne Geraetelogik kennen muss.
+
+## Feste Regeln
+
+- Prioritaeten beginnen bei 0; eine kleinere Zahl bedeutet hoehere Prioritaet.
 - `Leistungsquelle`: 0 nicht vorhanden, 1 berechnet, 2 gemessen.
 - Bei Leistungsquelle 0 ist `Istleistung_W` zwingend `null`.
-- Leistungsbereiche enthalten jeden ganzen Wattwert von `Von_W` bis `Bis_W` einschliesslich.
-- Die Leistungswerte sind aufsteigend, eindeutig und ueberschneiden sich nicht.
-- `Zustand` enthaelt immer den gemeinsamen Eintrag `Sollleistung_W` und daneben nur benoetigte geraetespezifische Eintraege.
-- Eine aktive Stoerung wird mit `Art=Stoerung` und `Wert=true` gemeldet; eine behobene mit `false`.
-- Verbraucher werden ausschliesslich im Manager zugeordnet. Der Verbraucher besitzt keine Manager-ID-Property.
+- Leistungsbereiche enthalten jeden ganzen Wattwert von `Von_W` bis `Bis_W`.
+- Leistungswerte sind aufsteigend, eindeutig und ueberschneiden sich nicht.
+- `Zustand` enthaelt immer `Sollleistung_W`.
+- Verbraucher werden ausschliesslich im Manager zugeordnet.
+- Der Verbraucher besitzt keine Manager-ID-Property.
 
 ## Technische Umsetzung in IP-Symcon
 
-Der Transport erfolgt über `IPS_RequestAction` mit JSON. `MessageSink` erkennt
-registrierte Änderungen; der empfangende Action-Handler prüft das Paket und
-ruft danach genau eine fachliche Empfangsmethode auf. Empfang und Neuberechnung
-werden intern entkoppelt, damit keine gegenseitige Endlosschleife entsteht.
+Der Transport erfolgt ueber `IPS_RequestAction` mit JSON. `MessageSink`
+erkennt registrierte Aenderungen. Empfang und Neuberechnung sind intern
+entkoppelt, damit keine gegenseitige Endlosschleife entsteht.
 
-Das PHP-Interface legt nur die Methode fest. Die folgenden gemeinsamen
-Symcon-Datenpunkte werden durch `VerbraucherBasisTrait` registriert.
+Das PHP-Interface legt nur die Empfangsmethode fest. Die gemeinsamen
+Symcon-Datenpunkte registriert `VerbraucherBasisTrait`.
 
 ### Gemeinsame Properties aller Verbraucher
 
 | Ident | Typ | Standard | Beschreibung |
 | --- | --- | --- | --- |
-| `PrioritaetPV` | Integer | `0` | Priorität ab 0; kleinere Zahl bedeutet höhere Priorität. |
-| `PrioritaetPeak` | Integer | `0` | Wie PV-Priorität, ohne fachliche Obergrenze. |
-| `Meldeintervall` | Integer | `10` | Vollständige Rückmeldung in Sekunden; muss grösser als 0 sein. |
-| `VorgabeTimeout` | Integer | `120` | Sollwert wird nach dieser Zeit ohne Erneuerung ungültig. |
-| `EinstellungenInVisu` | Boolean | `false` | Blendet lokale Einstellvariablen ein und macht sie geprüft bedienbar. |
-| `LoggingEin` | Boolean | `false` | Aktiviert das laufende Diagnoseprotokoll. Module können zusätzliche Diagnosevariablen getrennt einblenden. |
+| `PrioritaetPV` | Integer | `0` | Prioritaet in der Betriebsart PV |
+| `PrioritaetPeak` | Integer | `0` | Prioritaet in der Betriebsart Peak |
+| `Meldeintervall` | Integer | `10` | Vollstaendige Rueckmeldung in Sekunden |
+| `VorgabeTimeout` | Integer | `120` | Ablaufzeit einer Sollleistung |
+| `EinstellungenInVisu` | Boolean | `false` | Lokale Einstellungen in der Visualisierung |
+| `LoggingEin` | Boolean | `false` | Laufendes Diagnoseprotokoll |
 
 ### Gemeinsame Variablen aller Verbraucher
 
 | Ident | Typ / Zugriff | Beschreibung |
 | --- | --- | --- |
-| `Aktiv` | Boolean / bedienbar | Lokale EMS-Freigabe; Start `false`. |
-| `Istleistung` | Float / Anzeige | Aktuelle Leistung in W; nur zusammen mit `Leistungsquelle` gültig. |
-| `Leistungsquelle` | Integer / Anzeige | `0` nicht vorhanden, `1` berechnet, `2` gemessen. |
-| `Sollleistung` | Integer / Anzeige | Tatsächlich angenommene Vorgabe in W. |
-| `SollwertGueltig` | Boolean / Anzeige | Kennzeichnet eine aktuell gültige Vorgabe. |
-| `Verfuegbar` | Boolean / Anzeige | Verbraucher grundsätzlich für EMS-Steuerung verfügbar. |
-| `AenderungMoeglich` | Boolean / Anzeige | Neue Vorgabe darf momentan übernommen werden. |
-| `Stoerung` | Boolean / Anzeige | Mindestens ein Zustandseintrag der Art `Stoerung` ist aktiv. |
-| `Stoertext` | String / Anzeige | Zusammengefasste lesbare Störbeschreibung. |
+| `Aktiv` | Boolean / bedienbar | Lokale EMS-Freigabe; Start `false` |
+| `Istleistung` | Float / Anzeige | Aktuelle Leistung in W |
+| `Leistungsquelle` | Integer / Anzeige | 0 nicht vorhanden, 1 berechnet, 2 gemessen |
+| `Sollleistung` | Integer / Anzeige | Angenommene oder lokal erzwungene Vorgabe |
+| `SollwertGueltig` | Boolean / Anzeige | Aktuelle, nicht abgelaufene Vorgabe |
+| `Verfuegbar` | Boolean / Anzeige | Verbraucher grundsaetzlich verfuegbar |
+| `AenderungMoeglich` | Boolean / Anzeige | Neue Vorgabe darf uebernommen werden |
+| `Stoerung` | Boolean / Anzeige | Mindestens eine Stoerung aktiv |
+| `Stoertext` | String / Anzeige | Zusammengefasste Stoerbeschreibung |
 
-`Leistungswerte_W` und `Zustand` werden intern gehalten und direkt in die
-Nachricht geschrieben. Dafür werden keine zusätzlichen Symcon-Variablen
-angelegt. Der gemeinsame Zustandseintrag `Sollleistung_W` wird durch die Basis
-ergänzt. Während einer Lastwechselsperre meldet ein Verbraucher
-`AenderungMoeglich` als `false` und beschränkt `Leistungswerte_W` auf die aktuell
-gehaltene Leistung. Separate Felder wie `Idle` oder `IdleCounter` sind nicht
-Bestandteil des Vertrags.
+`Leistungswerte_W`, `Betriebsart` und `Zustand` werden intern gehalten
+und direkt in die Nachricht geschrieben.
 
 ## Zeitverhalten
 
-- Rückmeldung nach dem Start, bei relevanten Änderungen und zusätzlich alle
-  `Meldeintervall` Sekunden.
-- Laufende Vorgaben werden vom Manager standardmässig alle 60 Sekunden erneuert.
-- Nach `VorgabeTimeout` Sekunden ist eine nicht erneuerte Vorgabe ungültig.
-- Nach einem Neustart wird zuerst der Gerätezustand erfasst; eine alte Vorgabe
-  wird nicht ungeprüft wieder aufgenommen.
-
-## Obere Anschlüsse des Managers
-
-SDL/VGT, Prognose, Lizenzierung und Störüberwachung verändern den
-Manager-Verbraucher-Vertrag nicht. Ihr aktueller Diskussionsstand ist in
-[Obere-Anschluesse.md](Obere-Anschluesse.md) beschrieben.
+- Rueckmeldung nach Start, relevanten Aenderungen und alle `Meldeintervall`
+  Sekunden.
+- Laufende Vorgaben werden vom Manager standardmaessig erneuert.
+- Nach `VorgabeTimeout` ist eine nicht erneuerte Vorgabe ungueltig.
+- Nach einem Neustart wird keine alte Vorgabe ungeprueft aufgenommen.

docs/adr/0004-betriebsartabhaengige-leistungsangebote.md

@@ -0,0 +1,76 @@
+# ADR 0004: Betriebsartabhaengige Leistungsangebote
+
+## Kontext
+
+Der Nachrichtenvertrag 3.0 uebermittelte vom Manager nur
+`Sollleistung_W`. Verbraucher meldeten ein einziges Leistungsangebot und
+kannten die aktuelle Betriebsart nicht. Damit konnten Module keine
+unterschiedlichen PowerSteps fuer PV- und Peakbetrieb bereitstellen.
+
+Eine einfache Ergaenzung des Sollwertpakets reicht nicht aus: Beim Wechsel der
+Betriebsart besitzt der Manager zunaechst noch das Angebot der vorherigen
+Betriebsart. Eine sofortige Verteilung koennte deshalb einen Sollwert erzeugen,
+den der Verbraucher im neuen Modus ablehnen muss.
+
+## Entscheidung
+
+Der Vertrag wird inkompatibel auf Version `4.0` angehoben.
+
+- Managerdaten und Verbraucherdaten enthalten verpflichtend `Betriebsart`
+  mit dem Wert `PV` oder `Peak`.
+- `Sollleistung_W` in Managerdaten darf `null` sein.
+- `null` ist eine reine Betriebsart-Ankuendigung und kein Schaltbefehl.
+- Der Verbraucher uebernimmt die Betriebsart, berechnet sein Leistungsangebot
+  neu und meldet dieses mit derselben Betriebsart zurueck.
+- Der Manager verwendet nur Angebote seiner aktuellen Betriebsart.
+- Solange mindestens ein aktiver Verbraucher nicht synchronisiert ist, erfolgt
+  keine Verteilung.
+- Nach einem Betriebsartwechsel verwirft der Manager seinen Sollwertcache.
+
+Die konkrete Differenz zwischen PV- und Peakangebot bleibt Verantwortung des
+Verbrauchermoduls. Die derzeit implementierten Verbraucher uebernehmen die
+zustandsabhaengigen Enelix-1-Angebote gezielt:
+
+- Der einstufige Verbraucher bietet in Peak normalerweise `[0]`. Bei faelliger
+  Tagesmindestlaufzeit ist konfigurierbar, ob `[0, Nennleistung]` angeboten
+  oder nur die Nennleistung erzwungen wird.
+- Die Ladestation bietet in Peak mit Solarladen `[0]`, ohne Solarladen dagegen
+  `[0, ...Ladestufen]` an.
+- Der Warmwassererwaermer bietet unter seiner wirksamen Mindesttemperatur auch
+  in Peak `[0, ...Leistungsstufen]` an.
+- Der Pufferspeicher bietet im Peakbetrieb unabhaengig vom Zustand `[0]` an.
+- Technische Schaltsperren und ausstehende Rueckmeldungen duerfen das Angebot
+  weiterhin auf die aktuell gehaltene Leistung begrenzen.
+
+## Alternativen
+
+### Zwei Angebote gleichzeitig melden
+
+Separate Felder fuer PV- und Peak-PowerSteps wuerden den Umschalt-Handshake
+vermeiden. Sie verdoppeln jedoch alle Angebotsdaten und zwingen jedes Modul,
+beide Zustaende jederzeit parallel zu berechnen.
+
+### Betriebsart ohne Synchronisation senden
+
+Der Manager koennte Betriebsart und Sollleistung in einem Paket senden. Das
+erste Kommando nach einem Wechsel waere dann aus dem alten Angebot berechnet
+und koennte ungueltig sein.
+
+### Betriebsart aus einer Manager-Variable lesen
+
+Eine direkte Objektkopplung wuerde die definierte Schnittstelle umgehen,
+mehrere Manager erschweren und Verbraucher unnoetig an die Managerinstanz
+binden.
+
+## Folgen
+
+- Alle Manager und Verbraucher einer Installation muessen gemeinsam auf
+  Vertrag 4.0 aktualisiert werden.
+- Version 3.0 und 4.0 koennen nicht innerhalb derselben Managerzuordnung
+  gemischt werden.
+- Ein Betriebsartwechsel benoetigt mindestens einen zusaetzlichen
+  Nachrichtenumlauf.
+- Tests pruefen Vertragsvalidierung, Synchronisation und modulspezifische
+  Angebote fuer PV und Peak.
+- ADR 0001 bleibt als historische Entscheidung erhalten, wird fuer den
+  aktuellen Vertrag aber durch diese Entscheidung abgeloest.

docs/module/Ladestation-Stand-Alone/README.md

@@ -1,46 +1,63 @@
 # Ladestation Stand-Alone
 
-> Status: Diskussionsentwurf. Eigenständiges Verbrauchermodul mit direkter
-> Geräteanbindung; keine Beziehung zur Ladestation Gateway.
+> Status: Implementiert. Eigenstaendiges Verbrauchermodul mit direkter
+> Geraeteanbindung; keine Beziehung zur Ladestation Gateway.
 
-## Zusätzliche Variablen
+## Unterstuetzte Geraete
+
+| Geraetetyp | Status | Steuerung |
+| --- | --- | --- |
+| go-e Charger, alte API | `GET /mqtt?payload=` | `alw` und `amp` |
+| go-e Charger Gemini / Gemini flex | `GET /api/status` | `frc` und `amp` |
+| smart-me Pico | Pico-Charging-API | Load-Management-Current-API mit Basic Auth |
+
+Die Routen, Leistungsfaktoren und Erkennung wurden gezielt aus Enelix 1
+uebernommen. Zugangsdaten werden weder als Variable noch im Diagnoseprotokoll
+ausgegeben.
+
+## Verhalten
+
+- `FahrzeugVerbunden` entspricht bei go-e `car != 1` und bei Pico `State != 1`.
+- Die Phasenerkennung verwendet wie Enelix 1 die gemessene Ladeleistung:
+  ueber 7500 W sind dreiphasig, sonst einphasig.
+- Ein bereits verbundenes Fahrzeug gilt bei einem ermittelten Maximalstrom
+  unter 6 A als geladen.
+- PV mit Solarladen bietet `0 W` und alle Ladestufen von 6 A bis zum
+  konfigurierten Maximum an.
+- PV ohne Solarladen bietet ausschliesslich die Maximalleistung an.
+- Peak mit Solarladen bietet nur `[0]` an und stoppt die Ladestation.
+- Peak ohne Solarladen bietet `[0, ...Ladestufen]` an, damit der Manager die
+  Ladeleistung wie in Enelix 1 stufenweise reduzieren kann.
+- Ohne gueltige Manager-Vorgabe wird bei Solarladen mit 0 A und ohne
+  Solarladen mit maximaler Leistung gefahren.
+
+## Variablen
 
 | Ident | Typ / Zugriff | Beschreibung |
 | --- | --- | --- |
-| `FahrzeugVerbunden` | Boolean / Anzeige | Nur bei gültigem Gerätestatus aussagekräftig. |
-| `Fahrzeugstatus` | Integer / Anzeige | `0` unbekannt, `1` nicht verbunden, `2` bereit, `3` lädt, `4` voll, `5` Fehler. |
-| `Ladestrom` | Float / Anzeige | Aktueller Ladestrom in A. |
+| `FahrzeugVerbunden` | Boolean / Anzeige | Geraet meldet ein verbundenes Fahrzeug. |
+| `FahrzeugGeladen` | Boolean / Anzeige | Enelix-1-Erkennung unter 6 A. |
+| `Fahrzeugstatus` | Integer / Anzeige | `0` unbekannt, `1` getrennt, `2` bereit, `3` laedt, `4` geladen. |
+| `Ladestrom` | Float / Anzeige | Aus der gemessenen Leistung ermittelter Strom in A. |
 | `Phasenzahl` | Integer / Anzeige | `0` unbekannt, `1` einphasig, `3` dreiphasig. |
-| `Ladefreigabe` | Boolean / lokal bedienbar | Lokale Ladeerlaubnis zusätzlich zu `Aktiv`. |
-| `Solarladen` | Boolean / lokal bedienbar | Überschussorientiertes Laden ein/aus. |
+| `Ladefreigabe` | Boolean / bedienbar | Nur bei `EinstellungenInVisu`; lokale Ladeerlaubnis. |
+| `Solarladen` | Boolean / bedienbar | Nur bei `EinstellungenInVisu`; variable Ladestufen ein/aus. |
 
-## Zusätzliche Properties
+## Properties
 
-| Ident | Typ | Standard / Beschreibung |
-| --- | --- | --- |
-| `Ladefreigabe` | Boolean | `false`. |
-| `Solarladen` | Boolean | `true`. |
-| `MaximalerLadestrom` | Float | `0*` A; Installations- und Gerätegrenze. |
-| `Ladestromschritt` | Float | `1` A; muss vom Gerät unterstützt sein. |
-| `MindestEinzeit` | Integer | `0` s. |
-| `MindestAuszeit` | Integer | `0` s. |
-| `Geraetetyp` | Auswahl | `Unkonfiguriert`, `GoEAlt`, `GoEGemini` oder `SmartMePico`. |
-| `Geraeteadresse` | String | leer; nur für lokale Adapter. |
-| `GeraeteID` | String | leer; nur falls der Adapter eine ID benötigt. |
-| `Seriennummer` | String | leer; nur falls benötigt. |
-| `Benutzername` | String | leer; nur falls Anmeldung benötigt. |
-| `Passwort` | String | leer; vertraulich und nie als Variable/Diagnose anzeigen. |
+Neben den gemeinsamen Verbraucher-Properties werden Geraetetyp, Adresse,
+Pico-ID, Seriennummer, Zugangsdaten, maximaler Ladestrom, Abfrageintervall
+sowie die Startwerte fuer Ladefreigabe und Solarladen konfiguriert.
 
-Minimaler Ladestrom, frühere Umschaltabstände, Benutzervariable und externe
-Sollwert-Variable entfallen. Ladefreigabe und Solarladen erscheinen nur bei
-aktivem `EinstellungenInVisu` als bedienbare Variablen.
+Die gemeinsamen Verbraucher- und Diagnosevariablen entsprechen der
+EMS-Schnittstelle Version 4.0. `LoggingEin` steuert ausschliesslich das
+laufende Debug-Protokoll.
 
-## Zustand
+## Tests
 
-`Fahrzeugstatus`, `FahrzeugVerbunden`, `Ladefreigabe`, `Solarladen` und
-`Ladestrom_A` sowie `Ladefehler` und gerätespezifische Fehler.
-
-## Offene Punkte
-
-- Direkte Adapter und ihre noch gültigen API-Routen bei der Implementierung prüfen.
-- Lokalen Mindestladebedarf bei deaktiviertem Solarladen genau festlegen.
+Die Adaptertests verwenden einen injizierten Fake-HTTP-Transport. Dadurch
+werden fuer alle drei Geraetevarianten Statusantworten, URL, HTTP-Methode,
+Authentisierung und Steueraufrufe geprueft, ohne ein reales Geraet anzusprechen.
+Der Symcon-Funktionstest nutzt den internen, nicht im Konfigurationsformular
+sichtbaren `Testmodus` und prueft zusaetzlich Fahrzeug-/Phasenerkennung,
+die vier PV-/Peak-Angebote sowie die Umschaltung ueber den `Solarladen`-Button.

docs/module/Pufferspeicher/README.md

@@ -1,54 +1,144 @@
-# Pufferspeicher
+# Verbraucher Pufferspeicher
 
-> Status: Diskussionsentwurf.
+> Status: implementiert fuer IP-Symcon 8.0+ und den Enelix-2-Vertrag `4.0`.
 
-Regelt elektrische Heizstufen nach Pufferbedarf. Die Heizkurve verwendet einen
-Fusspunkt bei 20 °C Aussentemperatur und eine Steigung:
+Das Modul bindet elektrische Heizstufen eines Pufferspeichers an den
+Enelix-Manager an. Die Freigabe wird aus Puffer- und Aussentemperatur,
+Heizkurve, Hysterese, lokaler Aktivierung und aktueller Betriebsart berechnet.
 
-`Solltemperatur = FusspunktVorlauftemperatur + HeizkurvenSteigung × (20 - Aussentemperatur)`
+Es ist eine gezielte Adaption des Enelix-1-Moduls `Puffer_Speicher`.
+Leistungsstufen, Temperaturquellen, optionale PT1-Glaettung und Heizkurve
+wurden uebernommen und ueberarbeitet. Zyklische Altlogik, alte
+Kommunikationsvariablen, `Idle` und `PowerSteps` als Symcon-Variable wurden
+verworfen.
 
-Anschliessend wird auf Mindest- und Maximaltemperatur begrenzt.
+| Technisches Merkmal | Wert |
+| --- | --- |
+| Modulname | `VerbraucherPufferspeicher` |
+| Alias | `Pufferspeicher` |
+| Modul-ID | `{C92D5EEF-9632-47A5-9659-4B02BF40FBE9}` |
+| Enelix-Vertrag | `4.0` |
 
-## Zusätzliche Variablen
+## Regelverhalten
 
-| Ident | Typ / Zugriff | Beschreibung |
+Die Solltemperatur wird berechnet als:
+
+`FusspunktVorlauftemperatur + HeizkurvenSteigung * (20 - Aussentemperatur)`
+
+Anschliessend wird sie auf `HeizkurveMinimaltemperatur` und
+`HeizkurveMaximaltemperatur` begrenzt.
+
+Die Einschaltschwelle wird je nach `MindesttemperaturModus` bestimmt:
+
+- `Aus`: Solltemperatur minus Hysterese,
+- `Statisch`: konfigurierte absolute Mindesttemperatur,
+- `Differenz`: Solltemperatur minus konfigurierte Differenz.
+
+Es gilt:
+
+- im PV-Betrieb unter der Einschaltschwelle: `[0, ...Leistungsstufen]`,
+- im PV-Betrieb an oder oberhalb der Einschaltschwelle: `[0]`,
+- im Peakbetrieb unabhaengig von der Temperatur: `[0]`,
+- bei `Aktiv=false`: immer `[0]`,
+- bei ungueltigen Temperaturen: `[0]` und nicht verfuegbar.
+
+Der Pufferspeicher ist im Peakbetrieb damit pauschal gesperrt. Beim Wechsel in
+Peak wird eine aktive Stufe sicher ausgeschaltet.
+
+## Properties
+
+Die Properties erscheinen im Formular in dieser Reihenfolge.
+
+### Manager und Zeitverhalten
+
+| Ident | Standard | Beschreibung |
+| --- | ---: | --- |
+| `PrioritaetPV` | `0` | Prioritaet im PV-Betrieb |
+| `PrioritaetPeak` | `0` | Prioritaet im Peakbetrieb |
+| `Meldeintervall` | `10 s` | Vollstaendige Rueckmeldung |
+| `VorgabeTimeout` | `120 s` | Gueltigkeit einer Vorgabe |
+| `LastwechselSperrzeit` | `5 s` | Mindestzeit zwischen Lastwechseln |
+
+### Pufferspeicher
+
+| Ident | Standard | Beschreibung |
+| --- | ---: | --- |
+| `LeistungsStufen` | `[]` | Stufe, Leistung und Boolean-Schaltkontakt |
+| `PufferfuehlerVariableID` | `0` | Integer- oder Floatvariable |
+| `AussentemperaturVariableID` | `0` | Integer- oder Floatvariable |
+
+### Heizkurve
+
+| Ident | Standard | Beschreibung |
+| --- | ---: | --- |
+| `FusspunktVorlauftemperatur` | `35.0 C` | Vorlauf bei 20 C aussen |
+| `HeizkurvenSteigung` | `1.0` | Anhebung je Kelvin fallender Aussentemperatur |
+| `HeizkurveMinimaltemperatur` | `20.0 C` | Untere Sollwertbegrenzung |
+| `HeizkurveMaximaltemperatur` | `80.0 C` | Obere Sollwertbegrenzung |
+| `Hysterese` | `5.0 K` | Abstand zur Einschaltschwelle |
+| `MindesttemperaturModus` | `Aus` | Aus, statisch oder Differenz |
+| `Mindesttemperatur` | `20.0 C` | Wert im statischen Modus |
+| `MindesttemperaturDifferenz` | `5.0 K` | Wert im Differenzmodus |
+| `WaermepumpenSolltemperaturVariableID` | `0` | Optionale Quelle fuer die WP-Uebernahme |
+
+Der Button **Wert von Waermepumpe uebernehmen** berechnet den Fusspunkt so,
+dass die lokale Heizkurve beim aktuellen Aussenwert durch den aktuellen
+WP-Sollwert verlaeuft. Es entsteht keine dauerhafte Laufzeitkopplung.
+
+### Erweiterte Einstellungen
+
+| Ident | Standard | Beschreibung |
+| --- | ---: | --- |
+| `TemperaturMaxAlter` | `120 s` | Maximal zulaessiges Alter beider Messwerte |
+| `PuffertemperaturGlaetten` | `false` | Aktiviert PT1-Glaettung |
+| `ZeitKonstante` | `120 s` | PT1-Zeitkonstante |
+| `EinstellungenInVisu` | `false` | Gemeinsame Verbraucheroption |
+| `DiagnosevariablenAnzeigen` | `false` | Diagnosevariablen einblenden |
+| `LoggingEin` | `false` | Debug-Protokoll aktivieren |
+
+## Variablen
+
+Immer vorhanden:
+
+| Ident | Typ | Beschreibung |
 | --- | --- | --- |
-| `Puffertemperatur` | Float / Anzeige | Aktuelle Temperatur in °C. |
-| `Aussentemperatur` | Float / Anzeige | Heizkurveneingang in °C. |
-| `TemperaturenGueltig` | Boolean / Anzeige | Beide Quellen sind gültig. |
-| `Solltemperatur` | Float / Anzeige | Berechneter und begrenzter Sollwert in °C. |
-| `Heizbedarf` | Boolean / Anzeige | Bedarf unter Berücksichtigung der Hysterese. |
-| `AktiveStufe` | Integer / Anzeige | Stufenkennung; `0` bedeutet aus. |
-| `FusspunktVorlauftemperatur` | Float / lokal bedienbar | Wirksamer Parameter in °C. |
-| `HeizkurvenSteigung` | Float / lokal bedienbar | Anhebung pro K fallender Aussentemperatur. |
-| `Mindesttemperatur` | Float / lokal bedienbar | Untere Begrenzung in °C. |
-| `Maximaltemperatur` | Float / lokal bedienbar | Obere Begrenzung in °C. |
-| `Hysterese` | Float / lokal bedienbar | Ein unter Soll minus Hysterese, aus bei Soll. |
+| `Aktiv` | Boolean / bedienbar | Lokale Ein-/Aus-Freigabe |
+| `Puffertemperatur` | Float | Aktueller, gegebenenfalls geglaetteter Wert |
+| `Aussentemperatur` | Float | Heizkurveneingang |
+| `Solltemperatur` | Float | Berechneter und begrenzter Sollwert |
+| `Heizbedarf` | Boolean | Temperatur liegt unter der Einschaltschwelle |
 
-## Zusätzliche Properties
+Optional sichtbar sind die gemeinsamen Verbraucher-Diagnosevariablen sowie
+`AktiveStufe`, `BezogeneEnergie` und `TemperaturenGueltig`.
 
-| Ident | Typ | Standard / Beschreibung |
-| --- | --- | --- |
-| `FusspunktVorlauftemperatur` | Float | `0*` °C; Vorlauf bei 20 °C aussen. |
-| `HeizkurvenSteigung` | Float | `0*`; mindestens 0. |
-| `Mindesttemperatur` | Float | `0*` °C. |
-| `Maximaltemperatur` | Float | `0*` °C. |
-| `Hysterese` | Float | `1` K; grösser 0. |
-| `Leistungsstufen` | String/JSON | `[]`; Stufenkennung, Leistung in W und Ausgangsbelegung. |
-| `PuffertemperaturVariableID` | Integer | `0`; Temperaturquelle. |
-| `AussentemperaturVariableID` | Integer | `0`; Aussentemperaturquelle. |
-| `Mindestlaufzeit` | Integer | `0` s. |
-| `Mindeststillstand` | Integer | `0` s. |
+## Managerkommunikation
 
-Vier bisherige Heizkurventemperaturen, beide Heizkurvenquellen, Übernahmeaktion,
-Zeitplan und Zeitzone entfallen.
+Das Modul implementiert `VerbraucherSchnittstelle` und Vertrag `4.0`.
+Es uebernimmt zuerst die vom Manager angekuendigte Betriebsart, berechnet das
+passende Leistungsangebot und meldet es mit derselben Betriebsart zurueck.
+Erst danach wird eine Sollleistung angenommen.
 
-## Zustand
+Die Rueckmeldung enthaelt zusaetzlich:
 
-`Puffertemperatur_C` und `Aussentemperatur_C` als Istwerte,
-`Solltemperatur_C` als Sollwert, `Heizbedarf` als Status und `Fuehlerfehler` als
-Störung.
+- `Puffertemperatur_C`,
+- `Aussentemperatur_C`,
+- `Solltemperatur_C`,
+- `Heizbedarf`,
+- `AktiveStufe`,
+- `Fuehlerfehler` und `Schaltfehler`.
 
-## Offene Punkte
+## Sicherheit und Schaltung
 
-- Optionale Einbindung der Wärmepumpe beim Pufferheizen ausarbeiten.
+Die Kontakte werden Break-before-make geschaltet: zuerst alle aus, danach
+hoechstens eine Stufe ein. Ein Schaltfehler fuehrt zu einem Ausschaltversuch
+aller Kontakte und einer Stoerungsmeldung. Hardwareseitige Verriegelungen,
+Temperaturbegrenzer und Schutzorgane bleiben erforderlich.
+
+## Tests
+
+- `PufferspeicherReglerTest` prueft Heizkurve, Hysterese, Ein/Aus, Peak und
+  alle Mindesttemperatur-Modi.
+- `PufferspeicherModulstrukturTest` prueft Metadaten, Properties, Formular,
+  Vertrag und Schaltfolge.
+- Der standardisierte Symcon-Test prueft die reale Modulinstanz und ist im
+  gemeinsamen Manifest sowie in der Manager-Matrix registriert.

docs/module/README.md

@@ -1,7 +1,8 @@
 # EMS-Module und Modulentwürfe
 
-> Manager, Warmwassererwaermer und Verbraucher 1-Stufig sind als installierbare
-> IP-Symcon-Module umgesetzt. Die weiteren Ordner enthalten Besprechungsgrundlagen.
+> Manager, Warmwassererwaermer, Verbraucher 1-Stufig und Ladestation
+> Stand-Alone sind als installierbare IP-Symcon-Module umgesetzt. Die weiteren
+> Ordner enthalten Besprechungsgrundlagen.
 
 Alle steuerbaren Verbraucher verwenden die gemeinsamen Datenpunkte aus der
 [EMS-Schnittstelle](../Schnittstelle.md). In den Modul-READMEs stehen deshalb
@@ -15,7 +16,7 @@ nur zusätzliche Properties, Variablen, Zustände und offene Punkte.
 | [Pufferspeicher](Pufferspeicher/README.md) | Heizstufen nach Heizkurve |
 | [Verbraucher 1-Stufig](Verbraucher-1-Stufig/README.md) | Ein-/Aus-Verbraucher (implementiert) |
 | [Wärmepumpe](Waermepumpe/README.md) | Sperrkontakt oder SG Ready |
-| [Ladestation Stand-Alone](Ladestation-Stand-Alone/README.md) | Direkte Geräteanbindung |
+| [Ladestation Stand-Alone](Ladestation-Stand-Alone/README.md) | Direkte Geräteanbindung (implementiert) |
 | [Ladestation Gateway](Ladestation-Gateway/README.md) | Ladestation am Easee Gateway |
 | [Easee Gateway](Easee-Gateway/README.md) | Gemeinsame Easee-Kommunikation |
 

docs/module/Verbraucher-1-Stufig/README.md

@@ -1,12 +1,15 @@
 # Verbraucher 1-Stufig
 
-> Status: implementiert fuer IP-Symcon 8 und den Enelix-2-Vertrag `3.0`.
+> Status: implementiert fuer IP-Symcon 8 und den Enelix-2-Vertrag `4.0`.
 
-Das Modul schaltet einen elektrischen Ein-/Aus-Verbraucher. Im freien Zustand
-meldet es dem Manager das Leistungsangebot `[0, Nennleistung]`. Waerend einer
-Mindest-Ein- oder Mindest-Aus-Zeit, waehrend einer ausstehenden Rueckmeldung
-und bei lokal erzwungener Tagesmindestlaufzeit wird nur der aktuelle
-bestaetigte Leistungswert angeboten.
+Das Modul schaltet einen elektrischen Ein-/Aus-Verbraucher. Im frei
+schaltbaren Zustand meldet es bei PV `[0, Nennleistung]` und bei Peak `[0]`.
+Ist die Tagesmindestlaufzeit faellig, wird bei PV die Nennleistung erzwungen.
+Bei Peak ist konfigurierbar, ob `[0, Nennleistung]` angeboten oder die
+Nennleistung ohne Sperrmoeglichkeit erzwungen wird. Waerend einer
+Mindest-Ein- oder Mindest-Aus-Zeit sowie bei einer ausstehenden Rueckmeldung
+wird unabhaengig von der Betriebsart nur der aktuelle bestaetigte
+Leistungswert angeboten.
 
 ## Architekturentscheidung
 
@@ -27,7 +30,7 @@ Regelberechnung.
 ## Properties
 
 Zu den sechs gemeinsamen Verbraucher-Properties aus
-[`Schnittstelle.md`](../../Schnittstelle.md) kommen acht
+[`Schnittstelle.md`](../../Schnittstelle.md) kommen neun
 Modul-Properties hinzu.
 
 | Ident | Typ | Standard | Beschreibung |
@@ -37,6 +40,7 @@ Modul-Properties hinzu.
 | `SchaltkontaktInvertiert` | Boolean | `false` | Kehrt die Ein-/Aus-Semantik des Aktors um. |
 | `RueckmeldungVariableID` | Integer | `0` | Optionale Boolean-Rueckmeldung; `true` bedeutet physisch eingeschaltet. |
 | `Mindestlaufzeit` | Integer | `0` | Geforderte Laufzeit pro lokalem Kalendertag in Sekunden, maximal 86400. |
+| `PeakSperreBeiMindestlaufzeitAnbieten` | Boolean | `true` | Bietet bei faelliger Tagesmindestlaufzeit im Peakbetrieb zusaetzlich `0` als Sperre an. Bei `false` wird die Nennleistung lokal erzwungen. |
 | `Mindesteinschaltdauer` | Integer | `5` | Mindestzeit in Sekunden, die ein bestaetigter Ein-Zustand gehalten wird. |
 | `Mindestausschaltdauer` | Integer | `5` | Mindestzeit in Sekunden, die ein bestaetigter Aus-Zustand gehalten wird. |
 | `DiagnosevariablenAnzeigen` | Boolean | `false` | Legt gemeinsame und modulspezifische Diagnosevariablen an. |
@@ -126,15 +130,20 @@ beruecksichtigt. Nur der bestaetigte Ein-Zustand zaehlt.
 
 Ist die konfigurierte Tagesmindestlaufzeit noch nicht erreicht, wird der
 Verbraucher zum spaetestmoeglichen Zeitpunkt angefordert, an dem die
-Restlaufzeit bis Mitternacht noch erfuellt werden kann. Eine noch aktive
-Mindestausschaltdauer hat dabei Vorrang; eine unmoegliche Restlaufzeit kann
-nicht rueckwirkend nachgeholt werden.
+Restlaufzeit bis Mitternacht noch erfuellt werden kann. Im PV-Betrieb wird die
+Nennleistung dann lokal erzwungen. Im Peakbetrieb meldet das Modul bei
+aktivierter Property `PeakSperreBeiMindestlaufzeitAnbieten` wie Enelix 1
+`[0, Nennleistung]`, sodass der Manager zwischen Sperren und Nachholen der
+Laufzeit waehlen kann. Ist die Property deaktiviert, wird auch im Peakbetrieb
+nur die Nennleistung angeboten und lokal erzwungen. Eine noch aktive
+Mindestausschaltdauer hat Vorrang; eine unmoegliche Restlaufzeit kann nicht
+rueckwirkend nachgeholt werden.
 
 ## Managerkommunikation
 
 Das Modul implementiert
 `VerbraucherSchnittstelle::ManagerdatenEmpfangen()` und verwendet
-ausschliesslich Vertrag `3.0`. Der Verbraucher besitzt keine
+ausschliesslich Vertrag `4.0`. Der Verbraucher besitzt keine
 Manager-ID-Property. Er akzeptiert nur Manager, in deren manueller oder
 automatischer Verbraucherzuordnung seine Instanz aktiv eingetragen ist.
 

docs/module/Wassererwaermer/README.md

@@ -1,12 +1,12 @@
 # Verbraucher Warmwassererwaermer
 
-> Status: implementiert fuer IP-Symcon 8.0+ und den Enelix-2-Vertrag `3.0`.
+> Status: implementiert fuer IP-Symcon 8.0+ und den Enelix-2-Vertrag `4.0`.
 
 Das Modul bindet einen elektrischen Warmwasserspeicher mit einer oder mehreren
 exklusiven Leistungsstufen an den Enelix-Manager an. Der Manager kann nur eine
-der aktuell angebotenen Leistungen vorgeben. Lokale Schutz- und Komfortregeln
-fuer Mindesttemperatur, Maximaltemperatur, Zeitplan und Legionellenfunktion
-haben Vorrang vor einer Manager-Vorgabe.
+der aktuell angebotenen Leistungen vorgeben. Mindesttemperatur, Hysterese,
+Zeitplan und Legionellenfunktion bestimmen dabei zustands- und
+betriebsartabhaengig das Leistungsangebot.
 
 Das Modul ist eine gezielte Adaption des Enelix-1-Moduls
 `Boiler_x_Stufig`. Zyklische Altlogik und alte Kommunikationsvariablen wurden
@@ -20,7 +20,7 @@ ausschliesslich den Enelix-2-Nachrichtenvertrag.
 | Modul-ID | `{B7C54AF4-AD7D-4FE4-B75D-203693906251}` |
 | Modultyp | Geraeteinstanz (`3`) |
 | Funktionspraefix | `ENELIX` |
-| Enelix-Vertrag | `3.0` |
+| Enelix-Vertrag | `4.0` |
 
 ## Funktionsumfang
 
@@ -65,22 +65,22 @@ Eine Neuberechnung wird insbesondere ausgeloest durch:
 vollstaendige Rueckmeldung sicher. Die Lastwechselsperre verwendet einen
 einmaligen Timer und loest nach ihrem Ablauf genau eine Neuberechnung aus.
 
-Die Zielentscheidung folgt dieser Prioritaet:
+Die Zielentscheidung folgt der Enelix-1-Zustandsmatrix:
 
 1. Bei deaktivierter Instanz oder ungueltiger Temperatur ist der Verbraucher
    nicht verfuegbar und wird ausgeschaltet. Eine ungueltige Konfiguration wird
    bereits beim Uebernehmen mit Status `202` abgewiesen.
-2. Unterschreitet die Temperatur die wirksame Mindesttemperatur oder reicht die
-   verbleibende Zeit bis zum naechsten Zeitplanziel rechnerisch nicht aus, wird
-   die hoechste Leistungsstufe lokal erzwungen.
-3. Ab der wirksamen Maximaltemperatur wird ausgeschaltet.
-4. Im Bereich unmittelbar unter der Maximaltemperatur wird eine bereits aktive
-   Stufe bis zum Erreichen der Abschaltgrenze gehalten.
-5. In allen anderen Zustaenden darf der Manager zwischen `0 W` und allen
-   konfigurierten Leistungsstufen waehlen.
+2. Unter der wirksamen Mindesttemperatur sowie in der unteren Hysterese bei
+   aktiver Stufe gilt: PV erzwingt die Maximalleistung, Peak bietet
+   `[0, ...Leistungsstufen]` an.
+3. Ausserhalb dieses Mindesttemperaturbereichs bietet Peak nur `[0]` an.
+4. Im PV-Betrieb werden unterhalb von `Maximaltemperatur - Hysterese` alle
+   Stufen angeboten. In der oberen Hysterese gilt dies nur, solange bereits
+   eine Stufe aktiv ist.
+5. An oder oberhalb der wirksamen Maximaltemperatur wird ausgeschaltet.
 
-Lokale Zwangsvorgaben werden mit `AenderungMoeglich=false` und einem
-entsprechend eingeschraenkten `Leistungswerte_W` gemeldet.
+Eine erzwungene PV-Maximalleistung wird mit `AenderungMoeglich=false`
+gemeldet. Das Peak-Array bleibt dagegen durch den Manager waehlbar.
 
 ## Konfiguration
 
@@ -129,10 +129,11 @@ Stufe konfiguriert werden.
 
 Der jeweils naechste Zeitplaneintrag wird fuer heute oder den folgenden Tag
 ermittelt. Reicht die verbleibende Zeit bei maximaler elektrischer Leistung
-rechnerisch nicht mehr aus, wird sofort die hoechste Stufe angefordert. Die
-Berechnung verwendet Wasser mit `4186 J/(kg K)` und beruecksichtigt keine
-Speicher- oder Leitungsverluste. Fuer Datum und Uhrzeit gilt die in IP-Symcon
-eingestellte lokale Zeitzone.
+rechnerisch nicht mehr aus, wird das Zeitplanziel zur wirksamen
+Mindesttemperatur. Im PV-Betrieb wird dann die hoechste Stufe erzwungen, im
+Peakbetrieb werden alle Stufen angeboten. Die Berechnung verwendet Wasser mit
+`4186 J/(kg K)` und beruecksichtigt keine Speicher- oder Leitungsverluste. Fuer
+Datum und Uhrzeit gilt die in IP-Symcon eingestellte lokale Zeitzone.
 
 ### Erweiterte sonstige Einstellungen
 
@@ -179,14 +180,14 @@ nur erlaubt, wenn `EinstellungenInVisu=true` gesetzt ist.
 
 ## Hysterese und lokales Nachladen
 
-Sinkt die Temperatur unter die wirksame Mindesttemperatur, beginnt das lokale
-Nachladen mit der hoechsten Leistungsstufe. Es endet, sobald mindestens
-`Mindesttemperatur + Hysterese` erreicht ist. Oberhalb der wirksamen
-Maximaltemperatur wird ausgeschaltet.
+Sinkt die Temperatur unter die wirksame Mindesttemperatur, erzwingt PV die
+hoechste Leistungsstufe; Peak bietet dagegen Aus und alle Stufen an. In der
+unteren Hysterese bis `Mindesttemperatur + Hysterese` bleibt dieses Verhalten
+nur erhalten, solange bereits eine Stufe aktiv ist.
 
-Ist bereits eine Stufe aktiv und liegt die Temperatur bei mindestens
-`Maximaltemperatur - Hysterese`, wird diese Stufe bis zur Abschaltgrenze
-gehalten. Dadurch werden unnoetige Stufenwechsel kurz vor dem Ziel vermieden.
+Im PV-Betrieb werden unter `Maximaltemperatur - Hysterese` alle Stufen
+angeboten. Innerhalb der oberen Hysterese bleibt das Angebot nur bei einer
+bereits aktiven Stufe erhalten. An der Maximaltemperatur wird ausgeschaltet.
 
 ## Legionellenfunktion
 
@@ -196,8 +197,8 @@ Die Legionellenfunktion arbeitet zweistufig:
    wirksamen Maximaltemperatur. Der Manager kann die Aufheizung innerhalb des
    verbleibenden Zeitfensters ermoeglichen.
 2. Ab `LegionellenMaximalintervallTage` wird die Legionellentemperatur auch zur
-   wirksamen Mindesttemperatur. Die hoechste Stufe wird dadurch lokal
-   erzwungen, bis das Ziel erreicht ist.
+   wirksamen Mindesttemperatur. PV erzwingt dadurch die Maximalleistung; Peak
+   bietet das vollstaendige Stufenarray bis zum Ziel an.
 
 Erreicht die gueltige Speichertemperatur die Legionellentemperatur, wird der
 Zeitpunkt als erfolgreicher Abschluss gespeichert und das Intervall beginnt
@@ -268,7 +269,7 @@ Anzeigevariablen.
 
 Das Modul implementiert
 `VerbraucherSchnittstelle::ManagerdatenEmpfangen()` und verwendet den
-Enelix-2-Vertrag `3.0`. Es besitzt keine Manager-ID-Property. Zugelassen sind
+Enelix-2-Vertrag `4.0`. Es besitzt keine Manager-ID-Property. Zugelassen sind
 nur Manager, in deren manueller oder automatischer Verbraucherzuordnung die
 Instanz aktiv eingetragen ist.
 
@@ -382,7 +383,7 @@ PT1, Lastwechselsperre, Energieberechnung, thermische Prognose, Zeitplan und
 Legionellengrenzen.
 
 `WarmwassererwaermerModulstrukturTest.php` prueft Metadaten, Formular, alle 19
-Properties, ereignisbasierte Lastwechselsperre, Vertrag `3.0`, bedarfsgesteuerte
+Properties, ereignisbasierte Lastwechselsperre, Vertrag `4.0`, bedarfsgesteuerte
 Diagnosevariablen, Legionellentemperatur, Temperatursollwerte und
 Break-before-make-Schaltung.
 

docs/testing/README.md

@@ -42,7 +42,7 @@ werden, wenn sie vor dem Lauf nicht existierten.
 - `single`: genau die als Auswahl übergebenen Module
 - `affected`: die durch geänderte Pfade ermittelten Module
 
-Verfügbare Module: `Manager`, `VerbraucherEinStufig`, `Warmwassererwaermer`.
+Verfügbare Module: `LadestationStandAlone`, `Manager`, `VerbraucherEinStufig`, `Warmwassererwaermer`.
 
 Der Manager-Test enthält Manager ohne Verbraucher, jeden Verbrauchertyp einzeln und alle aktuell implementierten Verbrauchertypen gemeinsam.