# Module - Techniker

# Modul DeltaT

# Technische Anleitung: Modul Umschaltlogik (Delta-T)

## 1. Funktion des Moduls

Dieses Modul dient zur intelligenten Steuerung eines Umschaltventils zwischen zwei Wärmequellen (z.B. Pufferspeicher A und Pufferspeicher B). Es wählt automatisch oder manuell, welche der beiden Wärmequellen für den Heizbetrieb genutzt wird.

## 2. Konfiguration und Parameter

Die Funktion des Moduls wird über die folgenden Einstellungen in der Benutzeroberfläche angepasst.

### 2.1. Betriebsmodus

Mit diesem Parameter wird die grundlegende Arbeitsweise des Moduls festgelegt.

- **Auto: Primär geführt:** Automatikmodus für Systeme mit einer Haupt- und einer Hilfsquelle (z.B. Wärmepumpe und Ölkessel). Die Umschaltung erfolgt streng nach den Freigaben der übergeordneten Kaskadensteuerung.
- **Auto: Delta-T:** Automatikmodus für Systeme mit zwei gleichberechtigten Quellen. Es wird immer die wärmere der beiden Quellen genutzt.
- **Manuell Master A:** Erzwingt die Nutzung von Quelle A.
- **Manuell Master B:** Erzwingt die Nutzung von Quelle B.

### 2.2. Einstellungen für "Auto: Delta-T"

Dieser Parameter ist nur relevant, wenn der Betriebsmodus `Auto: Delta-T` gewählt ist.

- **Hysterese Delta-T:** Definiert, um wie viel Grad eine Quelle wärmer sein muss als die andere, bevor das Ventil umschaltet. Dies verhindert ein ständiges Schalten bei sehr ähnlichen Temperaturen.

### 2.3. Allgemeine Einstellungen

- **Primärer Master:** Legt fest, welche der beiden Quellen (Master A oder Master B) im Modus `Auto: Primär geführt` bevorzugt werden soll.
- **Ventil invertieren:** Kehrt die elektrische Ansteuerung des Umschaltventils um.
  - **Aus:** Normal (Signal für Quelle B)
  - **Ein:** Invertiert (Signal für Quelle A)

---

## 3. Wichtige Systemkonfiguration

Damit das Modul korrekt funktioniert, müssen die zugewiesenen Master-Module (typischerweise Pufferspeicher) und deren Wärmeerzeuger korrekt konfiguriert sein. Nur so werden die Ein- und Ausschalthysteresen der jeweiligen Puffer korrekt beachtet.

### 3.1. Primärer Master (z.B. Puffer der Wärmepumpe)

- **Puffer-Modul:** Der Betriebsmodus dieses Puffers **muss** auf **`Automatik Gleitend`** eingestellt sein, damit es eine korrekte Wärmeanforderung an seinen Master (die Wärmepumpe) stellt.
- **Wärmeerzeuger-Zuweisung:** Die Wärmepumpe muss als Master des Puffer-Moduls zugewiesen sein.

### 3.2. Sekundärer Master (z.B. Puffer des Ölkessels)

- **Puffer-Modul:** Der Betriebsmodus dieses Puffers **muss** auf **`Automatik Gleitend`** stehen.
- **Wärmeerzeuger-Zuweisung:** Der sekundäre Wärmeerzeuger (z.B. Ölkessel) **muss** als **`MasterB`** dieses Puffer-Moduls zugewiesen sein. **`MasterB`** muss auf den primären Wäreerzeuger stehen.
  - **Wichtiger Hinweis:** Diese Zuweisung dient als rein informativer Link für die Regelung, damit sie die Systemstruktur kennt. Der Puffer im Modus "Automatik Gleitend" wird selbst keine Anforderung an den Ölkessel stellen. Die Ansteuerung des Ölkessels erfolgt ausschließlich durch die `Modul_Kaskade`.

Die Missachtung dieser Einstellungen führt zu Fehlfunktionen in der Anforderungskette.

---

## 4. Funktionsweise der Automatik-Modi

### Modus "Auto: Primär geführt"

Dieser Modus ist für eine Haupt-Wärmequelle (z.B. Wärmepumpe) konzipiert, die bei Bedarf von einer zweiten Quelle (z.B. Ölkessel) unterstützt wird. Die Logik kombiniert die Freigabe-Signale der zentralen `Modul_Kaskade` mit einer intelligenten, temperaturbasierten Logik zur optimalen Wärmenutzung.

#### Anforderungslogik

Die Anforderung von Wärme an die übergeordneten Master (Pufferspeicher) folgt strikt der aktuellen Ventilstellung, um sicherzustellen, dass nur der Wärmeerzeuger angefordert wird, der auch tatsächlich genutzt wird.

*   Steht das Ventil auf **Master A**, wird die Systemanforderung nur an Master A weitergeleitet.
*   Steht das Ventil auf **Master B**, wird die Systemanforderung nur an Master B weitergeleitet.
*   Besteht keine Systemanforderung (`Anforderung = 0°C`), wird auch keine Anforderung weitergeleitet.
*   Im **Initialzustand** (direkt nach dem Start), wenn noch keine Quelle aktiv ausgewählt wurde, wird die Anforderung an den eingestellten **primären Master** gesendet.

Der Master (z.B. ein Puffer-Modul im Automatik-Modus) entscheidet dann selbstständig, ob er aufgrund der Anforderung seinen eigenen Wärmeerzeuger (z.B. Wärmepumpe) starten muss.

#### Umschaltlogik 

Die Logik zum Umschalten des Ventils wird nur ausgeführt, wenn eine aktive Heizanforderung im System vorliegt.

*   **Wechsel zu Sekundär:** Das Modul schaltet vom primären auf den sekundären Master um, wenn eine der folgenden Bedingungen erfüllt ist:
    1.  Der sekundäre Wärmeerzeuger wird von der Kaskade aktiviert.
    2.  Die Temperatur des sekundären Speichers ist hoch genug, um die Anforderung passiv (ohne laufenden Generator) zu decken (definiert durch `Umschalthysterese`).

*   **Zurückschalten zu Primär:** Das Modul schaltet vom sekundären Master zurück auf den primären, wenn **beide** der folgenden Bedingungen erfüllt sind:
    1.  Der primäre Wärmeerzeuger wird von der Kaskade (wieder) aktiviert.
    2.  Die Temperatur des sekundären Speichers kann die Anforderung nicht mehr passiv decken.

*   **Initialisierung:** Beim Start wählt das Modul den primären Master, wenn dessen Generator aktiv ist. Andernfalls wählt es den sekundären Master, falls dieser aktiv ist oder bereits passiv die Wärme bereitstellen kann. Sind beide inaktiv, wird der primäre Master als Standard gewählt.

### Modus "Auto: Delta-T"

Dieser Modus ist ideal für zwei gleichwertige Wärmequellen. Es wird immer die Quelle mit der höheren Temperatur genutzt.

*   **Funktionsprinzip:** Das Modul vergleicht kontinuierlich die Temperaturen von Quelle A und Quelle B.
*   **Umschaltung:** Es schaltet das Ventil immer auf die Quelle, die um den Wert der `Hysterese Delta-T` wärmer ist als die andere.

# Modul Power 2 Heat

# Technische Anleitung: Modul Power-2-Heat

## 1. Funktion des Moduls

Dieses Modul dient zur intelligenten Steuerung eines stufenlos regelbaren Heizstabs (oder eines ähnlichen elektrischen Verbrauchers). Sein Hauptzweck ist die Maximierung des Eigenverbrauchs von überschüssiger Energie, typischerweise von einer Photovoltaik-Anlage.

Das Modul überwacht kontinuierlich den Energieüberschuss am Netzanschlusspunkt des Gebäudes. Basierend auf diesem Wert regelt es die Leistung des Heizstabs so, dass der überschüssige Strom direkt in Wärme umgewandelt wird, anstatt ihn ins öffentliche Netz einzuspeisen.

## 2. Konfiguration und Parameter

Die Funktion des Moduls wird über die folgenden Einstellungen in der Benutzeroberfläche angepasst.

### 2.1. Betriebsmodus

Mit diesem Parameter wird die grundlegende Arbeitsweise des Moduls festgelegt.

*   **Aus:** Das Modul ist komplett deaktiviert. Der Heizstab wird nicht angesteuert.
*   **Manuell:** Der Heizstab wird mit einer fest eingestellten Leistung betrieben. Die Automatik ist deaktiviert. Dies ist nützlich für Testzwecke oder eine erzwungene Ladung.
*   **Automatik:** Das Modul regelt die Leistung des Heizstabs automatisch, basierend auf dem verfügbaren PV-Überschuss.

### 2.2. Grundeinstellungen

Diese Parameter definieren die Hardware des Heizstabs.

*   **Maximale Leistung:** Die elektrische Nennleistung des Heizstabs in Watt (W).
*   **Spannung bei max. Leistung:** Die Steuerspannung (üblicherweise 10.0 V), bei der der Heizstab seine maximale Leistung erreicht.
*   **Minimale Spannung:** Die Steuerspannung (üblicherweise 1.0 V oder 2.0 V), ab der der Heizstab beginnt, Leistung aufzunehmen.

### 2.3. Regelungsparameter (nur für Automatik-Modus)

Diese Einstellungen beeinflussen, wie sensibel und schnell die Automatik auf Änderungen im Stromnetz reagiert.

*   **Sicherheits-Offset:** Ein Leistungspuffer in Watt (W), der immer als Überschuss im Netz verbleiben soll. Dies ist die wichtigste Einstellung, um einen Strombezug aus dem Netz sicher zu vermeiden. Ein Wert von 50-100 W ist typisch.
*   **Toleranzband:** Ein kleiner Leistungsbereich um den Sicherheits-Offset in Watt (W). Befindet sich der aktuelle Überschuss innerhalb dieses Bandes, findet keine Regelung statt. Dies verhindert ein ständiges, nervöses Regeln bei kleinen Schwankungen.
*   **Max. Erhöhung pro Zyklus:** Begrenzt, wie schnell die Leistung des Heizstabs pro Regelungszyklus erhöht werden darf (in Watt). Dies sorgt für ein sanftes Hochfahren und verhindert ein Überschwingen.
*   **Reduktionsfaktor:** Ein Faktor, der bestimmt, wie aggressiv die Leistung bei einem Netzbezug reduziert wird. Ein höherer Wert führt zu einer schnelleren Reduktion.
*   **Regelzyklus:** Die Zeit in Sekunden, wie oft die Automatik die Leistung neu berechnet und anpasst.

### 2.4. Manuelle Vorgabe (nur für Manuell-Modus)

*   **Manuelle Leistung:** Die gewünschte Heizleistung als Prozentsatz der maximalen Leistung (0-100%).

---

## 3. Funktionsweise der Automatik

Im Automatik-Modus versucht das Modul, den Netzbezug bei `0 W` zu halten, indem es den Heizstab als regelbaren Verbraucher nutzt.

*   **Szenario 1: PV-Überschuss steigt**
    *   Wenn die PV-Anlage mehr Strom produziert als das Haus verbraucht, entsteht ein Überschuss, der ins Netz fließen würde.
    *   Das Modul erkennt diesen Überschuss und erhöht langsam die Leistung des Heizstabs, bis der Überschuss (abzüglich des Sicherheits-Offsets) aufgebraucht ist.

*   **Szenario 2: Verbrauch im Haus steigt oder PV-Leistung sinkt**
    *   Wenn ein großer Verbraucher im Haus eingeschaltet wird (z.B. Herd) oder Wolken aufziehen, würde Strom aus dem Netz bezogen.
    *   Das Modul erkennt diesen drohenden Netzbezug sofort und reduziert die Leistung des Heizstabs drastisch, um den Bezug zu kompensieren und die Netzstabilität zu wahren.

## 4. Energiezählung

Das Modul protokolliert den Energieverbrauch des Heizstabs. In der Visualisierung können die folgenden Werte eingesehen werden:

*   **Verbrauch Heute:** Die seit Mitternacht verbrauchte Energie in Wattstunden (Wh).
*   **Verbrauch Gestern:** Die am Vortag verbrauchte Energie.
*   **Verbrauch Gesamt:** Der gesamte, seit Inbetriebnahme oder dem letzten Reset verbrauchte Energie.

# Energie Manager

# Technische Anleitung: Energy Manager

## 1. Funktion des Moduls

Der Energy Manager ist die zentrale Intelligenz zur Optimierung des Energieverbrauchs im System. Seine Hauptaufgabe ist es, basierend auf externen Signalen wie Strompreisen, PV-Überschuss oder Smart-Grid-Signalen, eine von vier Betriebszuständen für das gesamte Heizsystem vorzugeben.

Diese Zustände, bekannt als "Smart-Grid-Ready" (SG-Ready) Level, signalisieren den anderen Modulen (z.B. Wärmepumpe, Boiler), ob sie Energie sparen, normal arbeiten, den Verbrauch erhöhen oder den Betrieb sogar zwingend starten sollen.

## 2. Konfiguration und Parameter

Die Funktion des Moduls wird über die folgenden Einstellungen in der Benutzeroberfläche angepasst.

### 2.1. Betriebsmodus

Dieser Parameter legt fest, welche externe Quelle zur Bestimmung des Systemzustands herangezogen wird.

*   **AUS:** Der Energy Manager ist deaktiviert. Das System läuft immer im Zustand `Normalbetrieb`.
*   **SG Ready:** Der Zustand wird über zwei digitale Eingänge (SG_1 und SG_2) bestimmt, wie es dem Industriestandard "SG-Ready" entspricht.
*   **Marktpreis:** Der Zustand wird basierend auf dem aktuellen Strompreis (z.B. von einer Strombörse wie aWATTar) bestimmt. Günstige Preise führen zu einem erhöhten Betrieb, teure Preise zu einer Reduktion.
*   **PV-Überschuss:** Der Zustand wird basierend auf dem Stromüberschuss der Photovoltaik-Anlage geregelt. Das Ziel ist, den Eigenverbrauch zu maximieren.

### 2.2. Einstellungen für Modus "Marktpreis"

Diese Parameter definieren, wie auf unterschiedliche Strompreis-Niveaus reagiert werden soll. Sie weisen jedem Preislevel einen der vier SG-Ready-Zustände zu.

*   **Bei "sehr günstigem" Preis:** Welcher Zustand soll aktiviert werden? (Empfehlung: `Zwangseinschaltung`)
*   **Bei "günstigem" Preis:** Welcher Zustand soll aktiviert werden? (Empfehlung: `Einschaltempfehlung`)
*   **Bei "normalem" Preis:** Welcher Zustand soll aktiviert werden? (Empfehlung: `Normalbetrieb`)
*   **Bei "teurem" Preis:** Welcher Zustand soll aktiviert werden? (Empfehlung: `Reduzierter Betrieb`)
*   **Bei "sehr teurem" Preis:** Welcher Zustand soll aktiviert werden? (Empfehlung: `Sperre`)

### 2.3. Einstellungen für Modus "PV-Überschuss"

*   **PV_Surplus_Threshold_Boost:** Schwellenwert in Watt (W), ab dem ein PV-Überschuss als ausreichend für eine Anhebung (Boost) gewertet wird. (Standard: 2000W)
*   **PV_Surplus_Threshold_Normal:** Schwellenwert in Watt (W), unter den der Überschuss fallen muss, um wieder in den Normalbetrieb zurückzukehren. (Standard: 300W)
*   **PV_Delay_Boost_Minutes:** Zeitverzögerung in Minuten, für die der Überschuss stabil über der Boost-Schwelle liegen muss, bevor die Anhebung aktiviert wird. (Standard: 15 Min)
*   **PV_Delay_Normal_Minutes:** Zeitverzögerung in Minuten, für die der Überschuss stabil unter der Normal-Schwelle liegen muss, bevor die Anhebung deaktiviert wird. (Standard: 15 Min)
*   **Mittelungs-Zyklen:** Anzahl der Messzyklen, über die der PV-Überschuss gemittelt wird. Dies glättet kurzfristige Schwankungen (z.B. durch schnell ziehende Wolken).
*   **Zähler-Einbauort:** Legt fest, was der Stromzähler misst:
    *   **Netzanschlusspunkt (Standard):** Misst Netzbezug (positiv) oder Einspeisung (negativ). Das System berechnet daraus den echten Überschuss unter Berücksichtigung des aktuellen Wärmepumpenverbrauchs.
    *   **Nur PV-Erzeugung:** Misst nur die Leistung der PV-Anlage. Der gesamte Wert wird als Überschuss angenommen.

---

## 3. Funktionsweise der Modi

### 3.1. Modus "SG Ready"

Das Modul liest zwei digitale Eingänge aus und setzt den Systemzustand gemäß der SG-Ready-Spezifikation:

| Eingang 1 | Eingang 2 | Resultierender Zustand | Beschreibung |
|---|---|---|---|
| 0 | 0 | `Normalbetrieb` | Standardbetrieb ohne Einschränkungen. |
| 0 | 1 | `Einschaltempfehlung` | Das System sollte, wenn möglich, den Verbrauch erhöhen (z.B. Puffer stärker laden). |
| 1 | 0 | `Sperre` | Das System sollte den Betrieb für eine bestimmte Zeit unterbrechen, um das Netz zu entlasten. |
| 1 | 1 | `Zwangseinschaltung`| Das System muss den Verbrauch zwingend starten (MANDATORY_BOOST), um überschüssige Energie aus dem Netz aufzunehmen. |

### 3.2. Modus "Marktpreis"

Das Modul empfängt die aktuellen Strompreise und ordnet sie einer Preiskategorie zu (z.B. "günstig", "teuer"). Anschließend setzt es den Systemzustand auf den Zustand, den der Benutzer für diese Preiskategorie konfiguriert hat.

### 3.3. Modus "PV-Überschuss"

1.  **Messen:** Das Modul liest die aktuelle Leistung am Zähler. Wenn am Netzanschlusspunkt gemessen wird, wird der aktuelle Verbrauch der Wärmepumpe herausgerechnet, um ein "Schwingen" der Regelung zu vermeiden (Potentialberechnung).
2.  **Mitteln:** Der Messwert wird über die eingestellte Anzahl an Zyklen geglättet.
3.  **Hysterese & Zeitverzögerung:**
    *   Übersteigt der (negative) Messwert die **Boost-Schwelle** für die Dauer der **Einschaltverzögerung**, wechselt das System in den Zustand `Zwangseinschaltung` (MANDATORY_BOOST).
    *   Fällt der Wert unter die **Normal-Schwelle** für die Dauer der **Ausschaltverzögerung**, wird wieder auf `Normalbetrieb` geschaltet.
    *   Liegt der Wert zwischen den Schwellen, bleibt der aktuelle Zustand erhalten und die Zeitverzögerungs-Timer werden angehalten.
4.  **Bereitstellen:** Der gemittelte Überschusswert wird anderen Modulen (wie `ModulPower2Heat`) zur Verfügung gestellt.

## 4. Ausgabe und Wirkung auf Module

Das primäre Ergebnis des Energy Managers ist der Server `SG_State`. Alle anderen Module im System, die energie-optimiert arbeiten können, reagieren auf diesen Zustand.

### Wirkung der SG-Ready-Zustände

| Zustand | Temperatur-Offset | Puffer | Boiler | Heizkreis |
|---|---|---|---|---|
| `Normalbetrieb` (0) | 0 | Normal | Normal | Normal |
| `Sperre` (1) | Absenkung | **Ladesperre** | **Ladesperre** | Absenkung |
| `Einschaltempfehlung` (2) | Anhebung | Anhebung | Anhebung | Anhebung |
| `Zwangseinschaltung` (3) | Boost | **Erzwungene Ladung** | **Erzwungene Ladung** | Anhebung |
| `Reduzierter Betrieb` (4) | Absenkung | Absenkung | Absenkung | Absenkung |

**Zwangseinschaltung (MANDATORY_BOOST):** Puffer und Boiler starten eine Ladung auch dann, wenn die normale Hysterese-Startbedingung noch nicht erreicht ist. Die Ladung startet, sobald die Temperatur unter der (durch den Boost-Offset angehobenen) Solltemperatur liegt. Die Abschaltung erfolgt weiterhin normal bei Erreichen der Solltemperatur.

**Sperre (LEGACY_LOCKOUT):** Puffer und Boiler werden aktiv an einer Ladung gehindert. Laufende Ladungen werden gestoppt. Beim Heizkreis wirkt nur die Temperatur-Absenkung, da dieser keine Ladepumpe hat.

# Modul Wärmepumpe

# Technische Anleitung: Modul Wärmepumpe (Acond)

## 1. Funktion des Moduls

Dieses Modul dient der Ansteuerung und Regelung einer Acond Wärmepumpe. Es fungiert als Schnittstelle zwischen der übergeordneten Systemlogik (Heizanforderungen, Kaskaden-Management) und der spezifischen Steuerung der Wärmepumpe über Modbus.

Das Modul empfängt eine Soll-Temperatur vom System und regelt die internen Komponenten der Wärmepumpe (Kompressor, Pumpe) so, dass diese Temperatur effizient erreicht wird. Es stellt zudem Betriebsdaten, Leistungs- und Energiewerte zur Visualisierung und für andere Systemmodule bereit.

## 2. Konfiguration und Parameter

Die Funktion des Moduls wird über die folgenden Einstellungen in der Benutzeroberfläche angepasst.

### 2.1. Betriebsmodus

*   **Modus:** Legt die grundlegende Arbeitsweise fest.
    *   `Aus`: Die Wärmepumpe ist deaktiviert.
    *   `Manuell`: Manuelle Steuerung (derzeit nicht implementiert, verhält sich wie `Aus`).
    *   `Automatik`: Die Wärmepumpe reagiert auf Heizanforderungen aus dem System.
    *   `Nur Heizstab`: Ausschließlich der elektrische Heizstab wird für die Wärmeerzeugung verwendet. Der Kompressor der Wärmepumpe bleibt dauerhaft abgeschaltet. Dieser Modus ist z.B. bei einem Kompressor-Defekt sinnvoll oder bei extremen Außentemperaturen, bei denen der Wärmepumpenbetrieb nicht mehr möglich ist. Kühlbetrieb ist in diesem Modus nicht verfügbar.

### 2.2. Kaskaden- & Bivalenz-Einstellungen

Diese Parameter steuern das Verhalten der Wärmepumpe im Zusammenspiel mit anderen Wärmeerzeugern.

*   **Kaskaden-Priorität:** Legt die Priorität der Wärmepumpe fest, wenn mehrere Wärmeerzeuger verfügbar sind. Eine niedrigere Zahl bedeutet eine höhere Priorität (z.B. `1` ist höher als `2`).
*   **Bivalenztemperatur:** Die Außentemperatur, unter der die Wärmepumpe gesperrt wird und ein anderer Wärmeerzeuger (z.B. ein Heizstab oder Ölkessel) übernehmen muss.
*   **Maximale Temperatur:** Die maximale Vorlauftemperatur, die die Wärmepumpe im Kaskadenbetrieb anstreben soll.

### 2.3. Regelungsparameter (Heizen)

Diese Einstellungen definieren, wie die Wärmepumpe ihre Leistung im Heizbetrieb anpasst.

*   **Rücklauf-Delta-T:** Die gewünschte Temperaturdifferenz zwischen Vor- und Rücklauf. Die interne Pumpe wird so geregelt, dass dieser Wert erreicht wird.
*   **PID-Reglermodus:** Bestimmt die Kernstrategie, nach der die Leistung des Verdichters geregelt wird.
    *   `Drehzahl`: Der Regler passt die **Verdichterdrehzahl** direkt an, um die Soll-Rücklauftemperatur zu erreichen. Dies ist eine einfache und robuste Regelungsart.
    *   `Thermische Leistung`: Der Regler ermittelt basierend auf der Rücklauftemperatur eine **Soll-Wärmeleistung in Watt**. Ein zweiter, unterlagerter Regler passt dann die Verdichterdrehzahl so an, dass die Wärmepumpe exakt diese Wärmeleistung abgibt. Dies ermöglicht eine präzisere Leistungsdosierung.
    *   `Elektrische Leistung`: Dieser Modus ist für zukünftige Erweiterungen vorgesehen (z.B. für die Anbindung an einen Energy Manager) und aktuell nicht implementiert.

### 2.4. Drehzahl-Kennlinie (Speed Points)

Die Leistung der Wärmepumpe ist stark von der Außentemperatur abhängig. Über vier Kennlinienpunkte (`SP1` bis `SP4`) wird die minimale und maximale Kompressordrehzahl in Abhängigkeit von der Außentemperatur festgelegt. Das System interpoliert zwischen diesen Punkten, um die optimale Drehzahl für die jeweilige Witterung zu finden.

*   **SPx Temperatur:** Die Außentemperatur für diesen Kennlinienpunkt.
*   **SPx Min. Drehzahl:** Die minimale Kompressordrehzahl bei dieser Temperatur.
*   **SPx Max. Drehzahl:** Die maximale Kompressordrehzahl bei dieser Temperatur.

### 2.5. Laufzeit-Einstellungen

*   **Mindestlaufzeit:** Die minimale Zeit in Minuten, die der Kompressor nach dem Start laufen muss. Verhindert schädliches Takten.
*   **Mindeststandzeit:** Die minimale Zeit in Minuten, die der Kompressor nach dem Abschalten ausgeschaltet bleiben muss.

### 2.6. Silent-Modus

Ermöglicht einen zeitgesteuerten, geräuschreduzierten Betrieb (z.B. nachts).

*   **Silent-Modus aktiv:** Aktiviert oder deaktiviert die Funktion.
*   **Startzeit / Stoppzeit:** Definiert den Zeitraum, in dem der Silent-Modus aktiv ist.

---

## 3. Funktionsweise der Automatik

1.  **Anforderung:** Das Modul erhält eine Heizanforderung (Soll-Vorlauftemperatur) von der übergeordneten Regelung (z.B. von einem Heizkreis oder Pufferspeicher).

2.  **Freigabe:** Das Modul prüft, ob die Freigabebedingungen erfüllt sind:
    *   Die Außentemperatur liegt über der eingestellten `Bivalenztemperatur`.
    *   Die `Mindeststandzeit` seit dem letzten Lauf ist abgelaufen.

3.  **Regelung:**
    *   Die Wärmepumpe startet. Die `Mindestlaufzeit` beginnt.
    *   Der **Kompressor** wird je nach gewähltem `PID-Reglermodus` entweder über die Drehzahl oder die thermische Leistung geregelt, um die geforderte Rücklauftemperatur zu erreichen. Die erlaubte Leistung wird dabei dynamisch aus der Kennlinie anhand der aktuellen Außentemperatur ermittelt.
    *   Die interne **Pumpe** wird gleichzeitig so geregelt, dass die eingestellte Spreizung (`Rücklauf-Delta-T`) zwischen Vor- und Rücklauf eingehalten wird.

4.  **Abschaltung:** Die Wärmepumpe schaltet ab, wenn keine Heizanforderung mehr besteht. Die `Mindeststandzeit` beginnt.

## 4. Kaskadenbetrieb

Im Zusammenspiel mit anderen Wärmeerzeugern meldet das Modul kontinuierlich seinen Status an die Kaskadenlogik:

*   **Priorität:** Die eingestellte Priorität.
*   **Betriebsbereitschaft (`EnergyLow`):** Das Modul meldet, ob es aktuell ineffizient läuft (z.B. weil die Temperaturdifferenz am Verdampfer zu gering ist). Die Kaskade kann dann entscheiden, einen anderen Wärmeerzeuger zu nutzen.
*   **Kosten pro kWh:** Basierend auf dem aktuellen Strompreis und dem Wirkungsgrad (COP) berechnet das Modul die Kosten für eine erzeugte Kilowattstunde Wärme. Dies ermöglicht der Kaskade eine ökonomische Entscheidung.

# Update-Info v1.6.8b (Installateure)

> Quelle: `Stations/Dokumentation/Update_Info_v1.6.8b_Installateure.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# Update-Information v1.6.8b — Wichtiges Stabilitäts-Update Wärmepumpen-Kommunikation

**An:** Installateure und Servicepartner
**Betrifft:** Alle OneKey-Anlagen mit ACond-Wärmepumpe (Modbus-Anbindung)
**Priorität:** Hoch — Update wird für alle betroffenen Anlagen empfohlen
**Version:** v1.6.8b (Hotfix auf v1.6.8a)

---

## Welches Problem wird behoben?

Bei Anlagen mit ACond-Wärmepumpe konnte die Kommunikation zwischen Regelung und
Wärmepumpe in einen dauerhaft blockierten Zustand geraten. Das Tückische daran:
Die Anlage wirkte äußerlich normal.

**So äußerte sich der Fehler:**

- Die Wärmepumpen-Istwerte (Vorlauf-, Rücklauf-, Außentemperatur, Leistung)
  **frieren ein** und aktualisieren sich nicht mehr.
- Die Wärmepumpe **reagiert nicht mehr auf Anforderungen** der Regelung
  (kein Start bei Wärmebedarf, kein Stopp, keine Betriebsartwechsel).
- Es wird **kein Kommunikationsalarm** angezeigt — die Verbindung erscheint
  in der Anzeige als „online".
- Die Überwachungsfunktion der Regelung erkannte zwar den fehlenden Datenfluss
  und versuchte automatische Neustarts (Wärmepumpen-Steuerung, danach Regelung) —
  diese halfen je nach Situation aber nicht dauerhaft, sodass sich **wiederholte
  selbsttätige Neustarts der Regelung** häufen konnten.
- Zuverlässig half bisher nur ein **manueller Neustart der Regelung**
  (spannungsfrei schalten).

**Auslöser** war eine seltene Abfolge interner Zustände nach Kommunikations-
störungen oder Konfigurationsänderungen (z. B. nach Internet-/Netzwerkausfall,
Geräteneustart oder Übernahme geänderter Einstellungen). Trat diese Abfolge ein,
blieb die Modbus-Datenübertragung deaktiviert, obwohl die Netzwerkverbindung
selbst in Ordnung war.

## Was ändert das Update?

Die interne Ablaufsteuerung der Wärmepumpen-Kommunikation wurde an vier Stellen
abgesichert:

1. Nach jeder Deaktivierung/Reaktivierung des Wärmepumpen-Moduls wird die
   Kommunikation garantiert vollständig neu aufgebaut.
2. Die Initialisierung der Wärmepumpe kann nicht mehr endlos hängen bleiben —
   nach spätestens 2 Minuten wird automatisch ein Fehler erkannt und die
   Wiederherstellung eingeleitet (jetzt **mit** sichtbarem Kommunikationsalarm).
3. Im laufenden Betrieb stellt die Regelung die Datenübertragung zyklisch
   selbst sicher (Selbstheilung).
4. Die automatische Wiederherstellung nach Kommunikationsfehlern greift jetzt
   in allen Fällen, auch bei widersprüchlichen internen Statusanzeigen.

**Ergebnis:** Der Blockade-Zustand kann nicht mehr entstehen. Kommunikations-
störungen (z. B. Netzwerkprobleme, Neustart der Wärmepumpe) werden erkannt,
gemeldet und heilen sich nach Behebung der Ursache selbstständig — ohne
manuellen Neustart. Auch die wiederholten selbsttätigen Neustarts der Regelung
entfallen damit.

## Für welche Anlagen ist das Update relevant?

- **Alle Anlagen mit ACond-Wärmepumpe** (Modbus-TCP-Anbindung), unabhängig von
  der Wärmepumpen-Firmware.
- Besonders dringend bei Anlagen, die bereits eines der oben beschriebenen
  Symptome gezeigt haben (eingefrorene Werte, unerklärliche Neustarts,
  „Wärmepumpe reagiert nicht").
- Anlagen ohne ACond-Wärmepumpe sind nicht betroffen; das Update schadet dort
  aber nicht.

## Durchführung des Updates

1. Update **v1.6.8b** auf die Regelung einspielen (gewohnter Update-Weg:
   Fernupdate bzw. vor Ort).
2. Die Regelung startet mit dem Update neu — ein bereits blockierter Zustand
   wird dadurch automatisch mit behoben. Es sind **keine weiteren Schritte**
   und keine Neukonfiguration nötig; alle Einstellungen bleiben erhalten.

**Hinweis:** Während des Updates/Neustarts (wenige Minuten) ist die Anlage im
Regelbetrieb unterbrochen. Heizung und Warmwasser laufen danach automatisch
weiter.

## Kontrolle nach dem Update (ca. 5 Minuten)

1. **Istwerte prüfen:** Wärmepumpen-Werte (Vorlauf/Rücklauf/Außentemperatur)
   ändern sich wieder laufend — Werte dürfen nicht statisch stehen bleiben.
2. **Funktionstest:** Bei anstehendem Wärmebedarf startet die Wärmepumpe bzw.
   nimmt Betriebsartwechsel an.
3. **Alarmliste prüfen:** Kein anstehender Wärmepumpen-Kommunikationsalarm.
   (Tritt ein solcher Alarm künftig auf, liegt eine echte Störung vor —
   Netzwerkverbindung und Wärmepumpe prüfen. Nach Behebung verschwindet der
   Alarm von selbst.)

## Rückfragen

Bei Auffälligkeiten nach dem Update (insbesondere erneut eingefrorene Werte
oder wiederholte selbsttätige Neustarts) bitte mit Anlagennummer und Zeitpunkt
an den technischen Support melden.

# Modbus-Wärmepumpe: Verhalten bei WAN-Ausfall

> Quelle: `Stations/Dokumentation/Anleitung_Modbus_WP_WAN_Ausfall.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# Anleitung: Modbus-Wärmepumpe stockt nach WAN-/Internet-Ausfall

Technischer Leitfaden für Service/Entwicklung. Beschreibt Symptom, Ursache und die im
Projekt umgesetzten Gegenmaßnahmen sowie deren Verifikation.

## Symptom

- Energiemanager / Cloud-Funktion läuft, dann fällt das Internet aus (z. B. ISP-Störung).
- Danach **stockt die lokale Modbus-TCP-Kommunikation zur Wärmepumpe (ACond)**.
- Die Verbindung wirkt teils noch „OK", es fließen aber keine Daten mehr.
- **Nur ein vollständiger SPS-Neustart** stellt die Kommunikation wieder her.
- Modbus im Debug zu deaktivieren/aktivieren hilft **nicht**.

## Ursache (zwei Ebenen)

**1) Auslöser (WAN):** Alle TCP-Verbindungen (lokaler Modbus **und** Cloud-MQTT/HTTP) teilen
sich denselben OS-Socket-/Filedescriptor-Pool (unterliegendes Linux, kein Zugriff). Bei
WAN-Ausfall versucht der MQTT-Client dauerhaft, den Cloud-Broker
`mqtt.onekey.1sinq.de:8883` (TLS, per Hostname → DNS) zu erreichen. Über einen langen Ausfall
summieren sich Reconnect-/DNS-/TLS-Versuche und zehren am gemeinsamen Socket-Pool.

**2) Warum nur Neustart hilft (der eigentliche Defekt):** In der Library-Klasse
`_TCPIP_CLIENT` (`CyclicCall`) geht eine Verbindung bei fehlgeschlagener Socket-Allokierung
(`OS_TCP_USER_SOCKET() < 0`, typisch bei erschöpftem Pool) nach `_STATE_ERROR`. Dieser
Zustand war ein **toter Endzustand**: kein Retry, und das `DelConn`-Flag wurde nicht geprüft.

Konsequenz: Die Verbindung bleibt dauerhaft hängen. `DelConnection()` (= das, was ein
Disable im Debug auslöst) wird ignoriert; bei `cMaxConnections = 1` schlägt ein erneutes
`AddConnection()` mit `TCP_CLT_ERR_MAX_CONN` fehl. Der Zustand ist Member-Variable und
überlebt jedes Klassen-Disable/Enable — nur ein voller SPS-Neustart (Reinit von Objekt +
OS-Stack) räumt auf.

## Umgesetzte Gegenmaßnahmen

### Fix A — `_TCPIP_CLIENT` selbstheilend (Hauptfix)

Datei: `Stations/Terminal/LSL/Class/_TCPIP_CLIENT/_TCPIP_CLIENT.st` (markiert mit `// OneKey-Patch`)

- In `_STATE_MAIN_SOCK` wird beim Allokierungsfehler ein Zeitstempel gesetzt.
- `_STATE_ERROR` ist aus der fatalen Init-Fehlergruppe herausgelöst und **recoverbar**:
  berücksichtigt `DelConn` **und** versucht nach 5 s Backoff erneut
  (`→ _STATE_IDLE → _STATE_MAIN_SOCK`, fordert einen neuen Socket an).
- Echte Init-Fehler (`_STATE_ERROR_ALLOCATING_MEMORY` / `_CREATING_MUTEX` / `_CREATING_TASK`)
  bleiben absichtlich terminal.

Wirkung: Jede `_TCPIP_CLIENT`-Verbindung (inkl. lokaler Modbus-WP) erholt sich automatisch,
sobald wieder Sockets frei werden — ohne SPS-Neustart. Disable/Enable wirkt wieder.

> Hinweis: `_TCPIP_CLIENT` ist Sigmatek-Library-Code und wird von **allen** TCP-Verbindungen
> genutzt. Der Patch ist minimal und markiert; bei einem Library-Update kann er überschrieben
> werden → Bug ist an Sigmatek gemeldet (siehe unten).

### Fix B — Reconnect-Churn senken (Trigger entschärfen)

Datei: `MQTT/mqtt_conf/mqtt_client.xml`

- `Reconnection/max_interval` 30 → 120 s. Reduziert bei langem WAN-Ausfall die Anzahl der
  Reconnect-/DNS-/TLS-Versuche und damit den Druck auf den gemeinsamen Socket-Pool.
- Trade-off: Nach WAN-Rückkehr dauert der nächste MQTT-Versuch bis zu 120 s (lokale Regelung
  ist davon nicht betroffen).
- Der Broker bleibt per Hostname adressiert — die TLS-Zertifikatsprüfung benötigt den
  Hostnamen, eine feste IP ist daher keine Option.

> Fix B ist eine Entschärfung, keine Heilung: Der eigentliche Socket-/fd-Leak liegt in der
> Sigmatek-MQTT/TCP/SSL-Library + Linux-OS und ist von uns nicht behebbar.

### Fix C — Connect-Timeout (Socket-Halte­zeit begrenzen)

Datei: `Stations/Terminal/LSL/Class/_TCPIP_CLIENT/_TCPIP_CLIENT.st` (markiert mit `// OneKey-Patch`)

- `_STATE_CONNECT` hatte keinen oberen Timeout: ein unbeantwortetes SYN (typisch bei WAN-Ausfall)
  hielt den Socket bis zum OS-Default (~1–2 min). Jetzt wird die Connect-Startzeit gemerkt und ein
  hängender Connect nach `cConnectTimeout` (Default **20 s**) aktiv abgebrochen → der Socket wird
  sofort wieder frei (`_STATE_CLOSE_MAIN_SOCK` schließt ihn real).
- Wirkung: Bei WAN-Ausfall belegen Cloud-Reconnects den gemeinsamen Pool deutlich kürzer →
  geringerer Erschöpfungs-Druck. Greift den eigentlichen Socket-Fresser an der Wurzel an.

### Fix D — Reboot-Eskalation als letzter Schutz

Datei: `Stations/Terminal/LSL/Class/AcondModbusWatchdog/AcondModbusWatchdog.st`

Da der fd-Leak in der Library selbst nicht behebbar ist, fängt der Watchdog den Endzustand ab —
als feste Eskalationsleiter, ohne zu unterscheiden, ob ACond oder SPS schuld ist (von außen
nicht erkennbar). Die Position auf der Leiter überlebt den SPS-Reboot über den retentiven
`RebootCounter`:

1. **Stufe 1:** Kommunikation tot > `ComTimeout` (Default 5 min) → HTTP-Reset der ACond (wie bisher).
2. **Stufe 2:** Bleibt die Kommunikation trotz ACond-Reset > `RebootTimeout` (Default 2 min) tot →
   **sauberer SPS-Reboot** über `255::DiagnoseClass1.Reboot` (OS-Reboot, **nicht** der
   CMD_RESET-Pfad, der die ET-0710 crasht). Ein Reboot re-initialisiert den OS-Socket-Stack und
   behebt damit den Sigmatek-seitigen Fall.
3. **Stufe 3:** Ist die Kommunikation nach dem SPS-Reboot weiterhin > `ComTimeout` tot →
   nochmals ACond-Reset und **sofort danach** ein zweiter SPS-Reboot (beide Steuerungen starten
   gemeinsam frisch) — ohne Verifikationswartezeit und ohne Karenz.
4. **Schluss:** Bleibt die Kommunikation auch danach tot → keine weiteren Aktionen, nur noch
   Dauer-Alarm (`Status` = 4).

Schleifenschutz gegen Dauerfehler: `RebootCounter` (retentiv) zählt die Reboots; ab `MaxReboots`
(Default 2) wird **nicht** mehr rebootet (= Schluss-Stufe). `MinRebootInterval` (Default 1 h) wirkt
als Mindest-Betriebszeit vor dem **ersten** Reboot: Die SPS rebootet nicht, solange sie selbst erst
kürzer als diese Zeit läuft (Flatter-Schutz; der ACond-Reset der Stufe 1 kommt trotzdem sofort).
Sobald die Kommunikation wieder gesund ist, werden alle Zähler zurückgesetzt — die Leiter läuft
also nur bei durchgehendem Fehler bis zum Ende durch.

> Konfigurierbar (Server-Channels): `RebootTimeout`, `MinRebootInterval`, `MaxReboots`. Beobachtbar:
> `RebootCounter` (extern/Visu lesbar) sowie `Status` im Online-Debug (0=OK, 1=ACond-Reset,
> 2=Reboot-Prüfung, 3=Reboot ausgelöst, 4=Alarm). Hinweis: `Status` ist `WriteProtected` und erhält
> im aktuellen Codegen keinen externen Lese-Pointer — für eine Visu-Anzeige müsste der Channel
> entsprechend angepasst werden (vorbestehender Effekt, nicht reboot-relevant).

### Fix E — Enable-Sackgasse in der `ACond_Heatpump`-Statemachine

Datei: `Stations/Terminal/LSL/Class/ACond_Heatpump/ACond_Heatpump.st`

Am Gerät beobachteter Klemm-Zustand, den auch die Watchdog-Eskalation (Stufe 1, ACond-Reset)
nicht heilen konnte: `EnableReadRegister`/`EnableWriteRegister` = 0 bei `ModbusOnline` = 1,
`HPOnline` = 0, **kein** Kommunikationsalarm, eingefrorene Istwerte. Die Modbus-Function-Objekte
(`ACond_ReadInputRegisters`/`ACond_WriteHoldingRegister`) waren dauerhaft disabled — nur ein
SPS-Reboot half (die Enables starten mit DefValue = 1 neu).

**Ursache (vier zusammenwirkende Lücken):**

1. Der `WPActive = 0`-Skip in `CyWork` nullte die Enables, ließ aber die Statemachine in ihrem
   letzten Zustand eingefroren stehen. Da die Enables **nur** in der Init-Leiter (`Heatpump_Init`)
   wieder gesetzt werden, blieben sie nach einer Re-Aktivierung (`WPActive` 0 → 1, z. B. Boot-Race,
   Config-Übernahme, kurzes Modul-Deaktivieren) dauerhaft 0, wenn die FSM bereits hinter Init stand.
2. `_HeatpumpInit_SetInitData` hatte **keinen Timeout**: Traf Lücke 1 mitten in der Init-Leiter,
   wartete der Zustand ewig auf `SetHPMode(Off)` — das ohne Write-Enable nie fertig wird.
3. In `_HeatpumpMain_Init` unterdrückt `GetHPErrors` Alarm **und** Recovery komplett — die
   Sackgasse war dadurch unsichtbar (kein `Alarm_HPCommunication`) und unerreichbar für
   `Reset_ComError`.
4. Die Error-Recovery verlangte `HPOnline = FALSE`; mit stale `HPOnline = TRUE` wurde
   `Reset_ComError` jeden Zyklus gelöscht, bevor er konsumiert wurde (zweite, latente Sackgasse).

**Umgesetzte Korrekturen:**

- `WPActive = 0`-Skip pinnt die FSM jetzt auf `_HeatpumpMain_Init`/`_w4ModbusOnline` (inkl.
  frischer Timeout-Basis, `HPOnline := FALSE`) → nach jeder Re-Aktivierung läuft garantiert die
  volle Init-Leiter inkl. Enable-Setzen.
- `_HeatpumpInit_SetInitData` bekam einen 120-s-Timeout (→ Error → reguläre Recovery) und
  assertet die Enables jeden Zyklus.
- `_HeatpumpMain_Active` assertet die Enables jeden Zyklus (Selbstheilung; „Active ⇒ Enables an"
  gilt jetzt per Konstruktion).
- Error-Recovery in `GetHPErrors` ist von `HPOnline` entkoppelt und stampt die Timeout-Basis neu.

Wirkung: Der Zustand „Komm tot, alles sieht online aus, nur Reboot hilft" kann strukturell nicht
mehr entstehen; die Watchdog-Stufe 1 (ACond-Reset) ist wieder in allen Fällen wirksam, weil jeder
TCP-Abriss zuverlässig in die Recovery-Schleife führt.

## Bug-Report an Sigmatek

Der Library-Defekt ist dokumentiert in
`Stations/Dokumentation/Bugreport_TCPIP_CLIENT_STATE_ERROR.md` (inkl. Code-Stellen,
Reproduktion und Korrekturvorschlag). Dieser sollte an Sigmatek übermittelt werden, damit der
Fix dauerhaft in die Library einfließt.

## Verifikation am Gerät (ohne OS-Zugriff, via LASAL-Debug)

1. WAN-Ausfall simulieren (Internet trennen), Wärmepumpe lokal weiterlaufen lassen.
2. Im Debug am Modbus-`_TCPIP_CLIENT` beobachten:
   - `pActConn^.FSM_TCP` — tritt `_STATE_ERROR` auf?
   - `LastError` — Hinweis auf Socket-/`MAX_CONN`-Fehler?
3. WAN wiederherstellen. **Erwartung mit Fix A:** Die Verbindung löst sich nach ≤ 5 s Backoff
   selbst und nimmt die Modbus-Kommunikation wieder auf — **ohne SPS-Neustart**.
4. `ComDiagnosis_MQTT` zur Beobachtung der MQTT-Reconnect-Aktivität.

## Hinweis zum Stale-`IsConnected`-Fall

Der `AcondModbusWatchdog` erkennt den Komm-Verlust nicht über `IsOnline`/`IsConnected` allein,
sondern über den **Datenfluss** (Modbus-Callback-Zähler bewegt sich + `cIsOnline`). Damit ist auch
der Stale-Fall abgedeckt, in dem `IsConnected` fälschlich TRUE bleibt (Socket halb-offen), aber keine
Antworten mehr kommen: Bleibt der Callback-Zähler stehen, greift die Eskalation (Tier 1 → Tier 2).
Am Gerät verifizieren, dass der Callback-Zähler im realen Fehlerfall tatsächlich stehen bleibt.

# ACond v4.3.3.25: IDE-Anleitung

> Quelle: `Stations/Dokumentation/ACond_v4.3.3.25_IDE_Anleitung.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# ACond Modbus v4.3.3.25 - IDE Aenderungen

Alle Aenderungen die im LASAL CLASS IDE gemacht werden muessen (DECLARATION-Bereich).
Die IMPLEMENTATION-Aenderungen (Code-Logik) sind bereits in den .st-Dateien.

## 1. ACond_ReadInputRegisters

### 1.1 Define aendern
- `D_Acond_ReadInputRegister_NoOfRegister` von `44` auf `82`

### 1.2 Array vergroessern
- `aRxData : ARRAY [0..43] OF INT` aendern auf `ARRAY [0..81] OF INT`

### 1.3 Neue Variablen
| Name | Typ | Init |
|------|-----|------|
| `bExtendedRegisters` | `BOOL` | `TRUE` |
| `uiExceptionCount` | `UINT` | `0` |

### 1.4 t_bd_HPStatus Bits umbenennen
| Bit | Alt | Neu |
|-----|-----|-----|
| 14 | Bit14 | `SG1` |
| 15 | Bit15 | `SG2` |
| 16 | Bit16 | `SG_Ready_Modbus_Enabled` |

### 1.5 Neue Server-Channels (WriteProtected=true, Retentive=false)

| Name | Typ | Beschreibung |
|------|-----|-------------|
| `ExtendedRegisters` | `SvrCh_BOOL` | Firmware v4.3.3.25+ erkannt |
| `HPComponentStatus` | `SvrCh_DINT` | Komponentenstatus Bitfeld |
| `FanSpeedPercent` | `SvrCh_DINT` | Luefterdrehzahl % |
| `EEV_Steps` | `SvrCh_DINT` | Expansionsventil % |
| `ActSuctionTemp` | `SvrCh_DINT` | Sauggastemperatur x10 |
| `ActDischargeTemp` | `SvrCh_DINT` | Heissgastemperatur x10 |
| `CompressorHours` | `SvrCh_UDINT` | Kompressor Betriebsstunden |
| `CompressorMinutes` | `SvrCh_DINT` | Kompressor Minuten |
| `FanHours` | `SvrCh_UDINT` | Luefter Betriebsstunden |
| `FanMinutes` | `SvrCh_DINT` | Luefter Minuten |
| `ReverseValveHours` | `SvrCh_UDINT` | Umschaltventil Stunden |
| `ReverseValveMinutes` | `SvrCh_DINT` | Umschaltventil Minuten |
| `PrimaryPumpHours` | `SvrCh_UDINT` | Primaerpumpe Stunden |
| `PrimaryPumpMinutes` | `SvrCh_DINT` | Primaerpumpe Minuten |
| `Bivalence1Hours` | `SvrCh_UDINT` | Bivalenz1 Stunden |
| `Bivalence1Minutes` | `SvrCh_DINT` | Bivalenz1 Minuten |
| `Bivalence2Hours` | `SvrCh_UDINT` | Bivalenz2 Stunden |
| `Bivalence2Minutes` | `SvrCh_DINT` | Bivalenz2 Minuten |
| `CoolingEnergySum` | `SvrCh_UDINT` | Kuehlenergie Summe x10 kWh |
| `ElecCoolingEnergySum` | `SvrCh_UDINT` | Elektr. Kuehlenergie Summe x10 |
| `CoolingEnergyDay` | `SvrCh_DINT` | Kuehlenergie Tag x10 |
| `ElecCoolingEnergyDay` | `SvrCh_DINT` | Elektr. Kuehlenergie Tag x10 |
| `CompressorSwitchCount` | `SvrCh_UDINT` | Kompressor Schaltzyklen |
| `SG_ReadyType` | `SvrCh_DINT` | SG Ready Typ (0-3) |
| `MaxPowerConsKW` | `SvrCh_DINT` | Max. Leistungsaufnahme kW x10 |
| `MaxPowerConsPercent` | `SvrCh_DINT` | Max. Leistungsaufnahme % |
| `EndOfHeatingTemp` | `SvrCh_DINT` | Heizgrenze x10 C |
| `ActAirAvgTemp` | `SvrCh_DINT` | Mittlere Aussentemp x10 C |

---

## 2. ACond_WriteHoldingRegister

### 2.1 Define aendern
- `D_Acond_WriteHoldingRegister_NoOfRegister` von `20` auf `24`

### 2.2 Arrays vergroessern
- `aTxData : ARRAY [0..19] OF INT` aendern auf `ARRAY [0..23] OF INT`
- `aRxData : ARRAY [0..19] OF INT` aendern auf `ARRAY [0..23] OF INT`

### 2.3 Neue Variable
| Name | Typ | Beschreibung |
|------|-----|-------------|
| `bExtendedRegisters` | `BOOL` | Wird von ACond_Heatpump gesetzt |

### 2.4 t_bd_HPControl Bits umbenennen
| Bit | Alt | Neu |
|-----|-----|-----|
| 14 | Bit14 | `SG1` |
| 15 | Bit15 | `SG2` |
| 16 | Bit16 | `SG_Ready_Modbus_Enable` |

### 2.5 Neue Server-Channels
| Name | Typ | Beschreibung |
|------|-----|-------------|
| `SG_ReadyType` | `SvrCh_DINT` | SG Ready Typ (0-3) |
| `MaxPowerConsKW` | `SvrCh_DINT` | Max. Leistungsaufnahme kW x10 |
| `MaxPowerConsPercent` | `SvrCh_DINT` | Max. Leistungsaufnahme % |

---

## 3. ACond_Heatpump

### 3.1 Neue Read-Server-Channels (WriteProtected=true)
| Name | Typ |
|------|-----|
| `HPComponentStatus` | `SvrCh_DINT` |
| `FanSpeedPercent` | `SvrCh_DINT` |
| `ActSuctionTemp` | `SvrCh_DINT` |
| `ActDischargeTemp` | `SvrCh_DINT` |
| `CompressorHours` | `SvrCh_UDINT` |
| `CompressorMinutes` | `SvrCh_DINT` |
| `CoolingEnergySum` | `SvrCh_UDINT` |
| `CoolingEnergyDay` | `SvrCh_DINT` |
| `CompressorSwitchCount` | `SvrCh_UDINT` |
| `ActAirAvgTemp` | `SvrCh_DINT` |
| `EndOfHeatingTemp` | `SvrCh_DINT` |
| `SG_ReadyType_Act` | `SvrCh_DINT` |
| `SG1_Status` | `SvrCh_DINT` |
| `SG2_Status` | `SvrCh_DINT` |
| `FirmwareExtended` | `SvrCh_BOOL` |

### 3.2 Neue Write-Server-Channels
| Name | Typ | Beschreibung |
|------|-----|-------------|
| `SetSG_ReadyType` | `SvrCh_DINT` | SG Ready Typ setzen |
| `SetSG1` | `SvrCh_BOOL` | SG1 Bit setzen |
| `SetSG2` | `SvrCh_BOOL` | SG2 Bit setzen |

---

## 4. ModulWaermepumpe_Acond

### 4.1 Neue Server-Channels (Visualized=true, WriteProtected=true)
| Name | Typ |
|------|-----|
| `FanSpeedPercent` | `SvrCh_DINT` |
| `ActSuctionTemp` | `SvrCh_DINT` |
| `ActDischargeTemp` | `SvrCh_DINT` |
| `CompressorHoursACond` | `SvrCh_UDINT` |
| `CoolingEnergySum` | `SvrCh_UDINT` |
| `CoolingEnergyDay` | `SvrCh_DINT` |
| `CompressorSwitchCount` | `SvrCh_UDINT` |
| `ActAirAvgTemp` | `SvrCh_DINT` |
| `EndOfHeatingTemp` | `SvrCh_DINT` |
| `HPComponentStatus` | `SvrCh_DINT` |

---

## 5. Verkabelung im IDE (Client -> Server)

Nach dem Anlegen der Server-Channels muessen die Client-Verbindungen hergestellt werden:

### ACond_Heatpump -> ACond_ReadInputRegisters
Der Client `ReadInputRegister` ist bereits verbunden. Die neuen Server-Channels in
ACond_ReadInputRegisters werden automatisch ueber den bestehenden Client erreichbar.

### ACond_Heatpump -> ACond_WriteHoldingRegister
Der Client `WriteHoldingRegister` ist bereits verbunden. Die neuen Server-Channels
werden automatisch erreichbar.

### ModulWaermepumpe_Acond -> ACond_Heatpump
Der Client `WpConBase` ist bereits verbunden. Die neuen Server-Channels in
ACond_Heatpump werden automatisch ueber den bestehenden Client erreichbar.

### ACond_WriteHoldingRegister.bExtendedRegisters
Diese Variable muss von ACond_Heatpump befuellt werden. Optionen:
- Als Client-Channel von ACond_ReadInputRegisters.ExtendedRegisters lesen
- Oder als einfache Variable direkt in ACond_Heatpump setzen und durchreichen

---

## Reihenfolge der IDE-Aenderungen

1. **ACond_ReadInputRegisters** - Defines, Array, Variablen, BDINT-Bits, Server-Channels
2. **ACond_WriteHoldingRegister** - Defines, Arrays, Variable, BDINT-Bits, Server-Channels
3. **ACond_Heatpump** - Server-Channels (Read + Write)
4. **ModulWaermepumpe_Acond** - Server-Channels (Visualized)
5. Kompilieren und testen

# ACond Alarmliste

> Quelle: `Stations/Dokumentation/Acond_Alarm_List.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# Acond Wärmepumpe - Alarm- und Warnungsliste

Dieses Dokument listet alle Fehler- und Warnungscodes der Acond Wärmepumpe auf und weist ihnen eine eindeutige Alarmnummer für das HMI-System zu.

Das Nummernschema ist wie folgt aufgebaut:
*   **Basis-Fehler:** 5000er Nummernkreis (5000 + Original-Code)
*   **Basis-Warnungen:** 6000er Nummernkreis (6000 + Original-Code)
*   **Treiber-Fehler:** 7000er Nummernkreis (7000 + Original-Code)

---

## Basis-Fehler (HPBasicErrorCode)

| Original-Code | Neue Alarm-Nr. | Typ | Client-Kanal im Handler | Deutscher Text (Vorschlag) | Beschreibung (Englisch) |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 1 | **5001** | Fehler | `cAlarm_Basic_1_FlowLow` | Störung: Durchfluss zu gering | FLOW THROUGH HEAT EXCHANGER IS LOW |
| 2 | **5002** | Fehler | `cAlarm_Basic_2_DefrostingTooLong` | Störung: Abtauvorgang zu lang | DEFROSTING TOO LONG |
| 3 | **5003** | Fehler | `cAlarm_Basic_3_HighPressure` | Störung: Hochdruckfehler | HIGH PRESSURE |
| 4 | **5004** | Fehler | `cAlarm_Basic_4_LowPressure` | Störung: Niederdruckfehler | LOW PRESSURE |
| 5 | **5005** | Fehler | `cAlarm_Basic_5_OutletTempLow` | Störung: Vorlauftemperatur zu niedrig | OUTLET TEMPERATURE LOW |
| 6 | **5006** | Fehler | `cAlarm_Basic_6_CompressorRunningFault`| Störung: Kompressor Lauffehler | COMPRESSOR RUNNING FAULT |
| 7 | **5007** | Fehler | `cAlarm_Basic_7_SuctionTempHigh` | Störung: Sauggastemperatur zu hoch | SUCTION TEMPERATURE HIGH |
| 8 | **5008** | Fehler | `cAlarm_Basic_8_SuctionTempLow` | Störung: Sauggastemperatur zu niedrig | SUCTION TEMPERATURE LOW |
| 9 | **5009** | Fehler | `cAlarm_Basic_9_TooManyDefrosts` | Störung: Zu viele Abtauvorgänge | TOO MANY DEFROSTS |
| 11 | **5011** | Fehler | `cAlarm_Basic_11_FanRunningFault` | Störung: Ventilator Lauffehler | FAN RUNNING FAULT |
| 12 | **5012** | Fehler | `cAlarm_Basic_12_SensorsBlocked` | Störung: Sensoren blockiert | SENSORS BLOCKED |
| 13 | **5013** | Fehler | `cAlarm_Basic_13_HeatingDhwTooLong` | Störung: WW-Bereitung zu lang | HEATING DHW TOO LONG |
| 14 | **5014** | Fehler | `cAlarm_Basic_14_DischargeTempHigh` | Störung: Heißgastemperatur zu hoch | DISCHARGE TEMPERATURE HIGH |
| 23 | **5023** | Fehler | `cAlarm_Basic_23_DriverHardwareFault` | Störung: Treiber Hardwarefehler | Driver HARDWARE FAULT |
| 25 | **5025** | Fehler | `cAlarm_Basic_25_DriverSystemFault` | Störung: Treiber Systemfehler | Driver SYSTEM FAULT |
| 29 | **5029** | Fehler | `cAlarm_Basic_29_CompressorFault` | Störung: Treiber Kompressorfehler | driver COMPRESSOR FAULT |
| 30 | **5030** | Fehler | `cAlarm_Basic_30_PfcFault` | Störung: Treiber PFC-Fehler | driver PFC FAULT |
| 31 | **5031** | Fehler | `cAlarm_Basic_31_MicroelectronicsFault`| Störung: Treiber Mikroelektronik-Fehler | driver MICROELECTRONICS FAULT |
| 40 | **5040** | Fehler | `cAlarm_Basic_40_RoomTempSensor` | Störung: Fühler Raumtemperatur | P05 ROOM TEMPERATURE SENSOR |
| 41 | **5041** | Fehler | `cAlarm_Basic_41_OutdoorTempSensor` | Störung: Fühler Außentemperatur | P04 OUTDOOR TEMPERATURE SENSOR |
| 42 | **5042** | Fehler | `cAlarm_Basic_42_OutletWaterSensor` | Störung: Fühler Vorlauf | P02 OUTLET WATER TEMPER. SENSOR |
| 43 | **5043** | Fehler | `cAlarm_Basic_43_DhwSensor` | Störung: Fühler Warmwasser | P06 DOMESTIC HOT WATER SENSOR |
| 44 | **5044** | Fehler | `cAlarm_Basic_44_SuctionLineSensor` | Störung: Fühler Saugleitung | P03 SUCTION LINE TEMPER. SENSOR |
| 45 | **5045** | Fehler | `cAlarm_Basic_45_ReturnWaterSensor` | Störung: Fühler Rücklauf | P01 RETURN WATER TEMPER. SENSOR |
| 46 | **5046** | Fehler | `cAlarm_Basic_46_EvaporatorTempSensor` | Störung: Fühler Verdampfer | P07 EVAPORATOR TEMPERATURE SENSOR |
| 47 | **5047** | Fehler | `cAlarm_Basic_47_Room2TempSensor` | Störung: Fühler Raum 2 | P09 ROOM 2 TEMPERATURE SENSOR |
| 48 | **5048** | Fehler | `cAlarm_Basic_48_SolarCollectorSensor`| Störung: Fühler Solarkollektor | P08 SOLAR COLLECTOR TEMPER. SENSOR |
| 49 | **5049** | Fehler | `cAlarm_Basic_49_PoolTempSensor` | Störung: Fühler Pool | P10 POOL TEMPERATURE SENSOR |
| 50 | **5050** | Fehler | `cAlarm_Basic_50_PeripheralUnitFailure`| Störung: Peripheriegerät | PER peripheral unit failure |
| 51 | **5051** | Fehler | `cAlarm_Basic_51_MixingValveSensor` | Störung: Fühler Mischer | P11 MIXING VALVE TEMPERATURE SENSOR |
| 52 | **5052** | Fehler | `cAlarm_Basic_52_LowPressureSensor` | Störung: Niederdrucksensor | P15 LOW PRESSURE SENSOR |
| 53 | **5053** | Fehler | `cAlarm_Basic_53_HighPressureSensor` | Störung: Hochdrucksensor | P16 HIGH PRESSURE SENSOR |
| 54 | **5054** | Fehler | `cAlarm_Basic_54_DischargeLineSensor` | Störung: Fühler Heißgasleitung | P13 DISCHARGE LINE TEMPER. SENSOR |
| 60 | **5060** | Fehler | `cAlarm_Basic_60_SuctionTempDefrostLow`| Störung: Sauggastemp. bei Abtauung zu niedrig | A18 SUCTION TEMP. DURING DEFROST.LOW |

---

## Basis-Warnungen (HPBasicErrorCode)

| Original-Code | Neue Alarm-Nr. | Typ | Client-Kanal im Handler | Deutscher Text (Vorschlag) | Beschreibung (Englisch) |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 100 | **6100** | Warnung | `cWarn_Basic_100_OutletTempLow` | Warnung: Vorlauftemperatur zu niedrig | W07 OUTLET TEMPERATURE LOW |
| 101 | **6101** | Warnung | `cWarn_Basic_101_RoomTempLow` | Warnung: Raumtemperatur zu niedrig | W01 ROOM TEMPERATURE LOW |
| 102 | **6102** | Warnung | `cWarn_Basic_102_ReturnWaterTempLow` | Warnung: Rücklauftemperatur zu niedrig | W02 RETURN WATER TEMPERATURE LOW |
| 103 | **6103** | Warnung | `cWarn_Basic_103_OutletWaterTempHigh` | Warnung: Vorlauftemperatur zu hoch | W00 OUTLET WATER TEMPERATURE HIGH |
| 104 | **6104** | Warnung | `cWarn_Basic_104_ReturnWaterTempHigh` | Warnung: Rücklauftemperatur zu hoch | W04 RETURN WATER TEMPERATURE HIGH |
| 105 | **6105** | Warnung | `cWarn_Basic_105_SuctionTempLow` | Warnung: Sauggastemperatur zu niedrig | W05 SUCTION TEMPERATURE LOW |
| 106 | **6106** | Warnung | `cWarn_Basic_106_DefrostingTooLong` | Warnung: Abtauvorgang zu lang | W12 DEFROSTING TOO LONG |
| 107 | **6107** | Warnung | `cWarn_Basic_107_CondensingTempHigh` | Warnung: Kondensationstemperatur zu hoch | W06 CONDENSING TEMPERATURE HIGH |
| 108 | **6108** | Warnung | `cWarn_Basic_108_InvalidIP` | Warnung: IP Adresse ungültig | W09 IP ADDRESS IS NOT VALID |
| 109 | **6109** | Warnung | `cWarn_Basic_109_DhwSanitationTooLong`| Warnung: Legionellenschutz zu lang | W11 DHW SANITATION TOO LONG |
| 110 | **6110** | Warnung | `cWarn_Basic_110_EevTooOpen` | Warnung: EEV zu weit geöffnet | W16 EEV TOO OPEN |
| 111 | **6111** | Warnung | `cWarn_Basic_111_SuperheatLow` | Warnung: Überhitzung zu niedrig | SH1 SUPERHEAT LOW |
| 112 | **6112** | Warnung | `cWarn_Basic_112_MaxCompStarts` | Warnung: Max. Kompressorstarts erreicht | W08 MAX. NUMBER OF COMP. STARTS |
| 113 | **6113** | Warnung | `cWarn_Basic_113_EvaporatingTempLow` | Warnung: Verdampfungstemperatur zu niedrig | W17 EVAPORATING TEMPERATURE LOW |
| 114 | **6114** | Warnung | `cWarn_Basic_114_StorageTankLow` | Warnung: Speichertemperatur zu niedrig | W10 TEMPERATURE OF STORAGE TANK LOW |
| 115 | **6115** | Warnung | `cWarn_Basic_115_SdCardFault` | Warnung: SD-Kartenfehler | W14 SD CARD FAULT |
| 116 | **6116** | Warnung | `cWarn_Basic_116_TooManyRestartsPlc` | Warnung: Zu viele Neustarts der Steuerung | W13 TOO MANY RESTARTS OF PLC |
| 117 | **6117** | Warnung | `cWarn_Basic_117_BigDiffReturnDhw` | Warnung: Große Differenz Rücklauf/WW | W15 BIG DIFFRENCE-RETURN AND DHW TEMPERATURE |

---

## Treiber-Fehler (HPDriverErrorCode)

| Original-Code | Neue Alarm-Nr. | Typ | Client-Kanal im Handler | Deutscher Text (Vorschlag) | Beschreibung (Englisch) |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 1 | **7001** | Fehler | `cAlarm_Driver_1_UCurrentSensorFault` | Störung: Stromsensor Phase U | comp. U current sensor fault |
| 2 | **7002** | Fehler | `cAlarm_Driver_2_VCurrentSensorFault` | Störung: Stromsensor Phase V | comp. V current sensor fault |
| 3 | **7003** | Fehler | `cAlarm_Driver_3_WCurrentSensorFault` | Störung: Stromsensor Phase W | comp. W current sensor fault |
| 4 | **7004** | Fehler | `cAlarm_Driver_4_PfcCurrentSensorFault` | Störung: PFC Stromsensor | PFC current sensor fault |
| 5 | **7005** | Fehler | `cAlarm_Driver_5_IpmTempSensorFault` | Störung: IPM Temperatursensor | IPM temperature sensor fault |
| 6 | **7006** | Fehler | `cAlarm_Driver_6_PfcTempSensorFault` | Störung: PFC Temperatursensor | PFC temperature sensor fault |
| 7 | **7007** | Fehler | `cAlarm_Driver_7_DltSensorFault` | Störung: DLT Sensor | DLT sensor fault |
| 8 | **7008** | Fehler | `cAlarm_Driver_8_CommLost` | Störung: Kommunikationstreiber | Communication lost |
| 9 | **7009** | Fehler | `cAlarm_Driver_9_EepromFault` | Störung: EEPROM Fehler | EEPROM fault |
| 10 | **7010** | Fehler | `cAlarm_Driver_10_ACOvercurrent` | Störung: AC Überstrom | AC overcurrent |
| 11 | **7011** | Fehler | `cAlarm_Driver_11_ACOvervoltage` | Störung: AC Überspannung | AC overvoltage |
| 12 | **7012** | Fehler | `cAlarm_Driver_12_ACUndervoltage` | Störung: AC Unterspannung | AC undervoltage |
| 13 | **7013** | Fehler | `cAlarm_Driver_13_DCOvervoltage` | Störung: DC Überspannung | DC overvoltage |
| 14 | **7014** | Fehler | `cAlarm_Driver_14_DCUndervoltage` | Störung: DC Unterspannung | DC undervoltage |
| 15 | **7015** | Fehler | `cAlarm_Driver_15_HpLpSwitch` | Störung: Hoch-/Niederdruckschalter | HP/LP switch |
| 16 | **7016** | Fehler | `cAlarm_Driver_16_InputLossOfPhase` | Störung: Phasenausfall | input loss of phase (not in 1ph product) |
| 17 | **7017** | Fehler | `cAlarm_Driver_17_IpmOverheat` | Störung: IPM Überhitzung | IPM overheat (17) |
| 18 | **7018** | Fehler | `cAlarm_Driver_18_IGBTOverheat` | Störung: IGBT Überhitzung | IGBT overheat |
| 19 | **7019** | Fehler | `cAlarm_Driver_19_CompressorCode` | Störung: Kompressor-Code | compressor code |
| 20 | **7020** | Fehler | `cAlarm_Driver_20_CompHwOvercurrent` | Störung: Kompressor HW Überstrom | Comp. HW overcurrent |
| 21 | **7021** | Fehler | `cAlarm_Driver_21_CompUPhaseOvercurrent`| Störung: Kompressor Phase U Überstrom | comp. U phase overcurrent |
| 22 | **7022** | Fehler | `cAlarm_Driver_22_CompVPhaseOvercurrent`| Störung: Kompressor Phase V Überstrom | comp. V phase overcurrent |
| 23 | **7023** | Fehler | `cAlarm_Driver_23_CompWPhaseOvercurrent`| Störung: Kompressor Phase W Überstrom | comp. W phase overcurrent |
| 24 | **7024** | Fehler | `cAlarm_Driver_24_CompLossOfPhase` | Störung: Kompressor Phasenausfall | Comp. loss of phase |
| 25 | **7025** | Fehler | `cAlarm_Driver_25_CompLostStator` | Störung: Kompressor Statorverlust | Comp. lost stator |
| 26 | **7026** | Fehler | `cAlarm_Driver_26_CompStartupFailure` | Störung: Kompressor Startfehler | Comp. startup failure |
| 28 | **7028** | Fehler | `cAlarm_Driver_28_CompOverload` | Störung: Kompressor Überlast | Comp. Overload |
| 29 | **7029** | Fehler | `cAlarm_Driver_29_CompDtOvertemperature`| Störung: Kompressor DT Übertemperatur | Comp. DT overtemperature |
| 31 | **7031** | Fehler | `cAlarm_Driver_31_CompIpmDesatProtection`| Störung: Kompressor IPM Entsättigung | Comp. IPM desat. Protection |
| 32 | **7032** | Fehler | `cAlarm_Driver_32_CompLostRotor2` | Störung: Kompressor Rotorfehler 2 | Comp. lost rotor2 |
| 33 | **7033** | Fehler | `cAlarm_Driver_33_CompLostRotor3` | Störung: Kompressor Rotorfehler 3 | Comp. lost rotor3 |
| 34 | **7034** | Fehler | `cAlarm_Driver_34_PfcHwOvercurrent` | Störung: PFC HW Überstrom | PFC HW overcurrent |
| 35 | **7035** | Fehler | `cAlarm_Driver_35_PfcSwOvercurrent` | Störung: PFC SW Überstrom | PFC SW overcurrent |
| 36 | **7036** | Fehler | `cAlarm_Driver_36_PfcOvervoltage` | Störung: PFC Überspannung | PFC overvoltage |
| 37 | **7037** | Fehler | `cAlarm_Driver_37_AdFault` | Störung: AD-Wandler Fehler | AD fault |
| 38 | **7038** | Fehler | `cAlarm_Driver_38_WrongAddressing` | Störung: Falsche Adressierung | wrong addressing |
| 39 | **7039** | Fehler | `cAlarm_Driver_39_CommErrorDriverPlc` | Störung: Kommunikation Treiber/SPS | Communication error between driver and PLC |

# ModulSolar Feststoff-Erweiterung: IDE-Anleitung

> Quelle: `Stations/Dokumentation/IDE_Anleitung_ModulSolar_Feststoff_Erweiterung.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# IDE-Anleitung: ModulSolar_ext um Feststoffkessel-Modus erweitern

Diese Schritte werden in der **LASAL CLASS 2 IDE** durchgeführt, da sie die DECLARATION-Region der Klasse betreffen, die nicht direkt im Quelltext editiert werden darf (sie wird vom Codegen überschrieben).

Nach Abschluss aller IDE-Schritte kann die zugehörige Logik im IMPLEMENTATION-Bereich ergänzt werden (siehe Abschnitt 5).

---

## 1. Neue Server-Channels anlegen

Klasse `ModulSolar_ext` öffnen, im Reiter **Server** folgende Kanäle hinzufügen:

| Name | Typ | Retentive | Initialize | Default | Kommentar |
|---|---|---|---|---|---|
| `P_QuellenTyp` | DINT | File | Ja | 0 | 0 = Solar, 1 = Feststoffkessel |
| `P_RL_Soll` | DINT | File | Ja | 60 | Sollwert Rücklauf-Mindesttemperatur (°C) |
| `P_RL_Hyst` | DINT | File | Ja | 3 | Hysterese Rücklauf-Anhebung (K) |
| `P_MischerLaufzeit` | DINT | File | Ja | 140 | Mischer-Laufzeit gesamt (Sekunden) |
| `P_MischerInvert` | DINT | File | Ja | 0 | 0 = normal, 1 = Motorrichtung invertiert |
| `P_MinKesselTemp` | DINT | File | Ja | 60 | Mindesttemperatur für Pumpenfreigabe (°C) |
| `RL_Ist` | DINT | – | Nein | – | Rücklauf-Ist-Temperatur (Read-Only Status) |
| `MischerPosition` | DINT | – | Nein | – | Mischer-Position 0-100% (Status) |
| `MischerState` | DINT | – | Nein | – | -1 = ZU, 0 = AUS, 1 = AUF |

Wichtig:
- Visualized = true (damit die Werte im UI verfügbar sind)
- WriteProtected = false bei den `P_*`-Parametern
- Bei `RL_Ist`, `MischerPosition`, `MischerState`: WriteProtected = true (nur Anzeige)

## 2. Hardware-Zuordnungen (I/O)

In der Klassen-Eigenschaft `ConfigClass` oder analog zu `In1_Assignment`/`Out1_Assignment` zwei zusätzliche Konstanten anlegen:

- `In4_Assignment` (UINT) – Rücklauffühler (analog)
- `Out5_Assignment` (UINT) – Mischer AUF (digital)
- `Out6_Assignment` (UINT) – Mischer ZU (digital)

Falls keine freien I/O-Plätze vorhanden sind: zwei vorhandene Outputs (z. B. Out3/Out4) umwidmen, dann muss aber die Manuell-Bedienung in `CyWork` entsprechend angepasst werden.

## 3. Struktur `Datenstruct` erweitern (`types.h`)

Datei `Stations/Terminal/LSL/Include/types.h` öffnen, Struct `Datenstruct` (ab Zeile 256) ergänzen:

```
Datenstruct : STRUCT
  ...   // bestehende Felder
  QuellenTyp       : USINT;   // 0 = Solar, 1 = Feststoff
  RL_Soll          : USINT;
  RL_Hyst          : USINT;
  MischerLaufzeit  : USINT;
  MischerInvert    : USINT;
  MinKesselTemp    : USINT;
END_STRUCT;
```

Achtung: Beim Hinzufügen am Ende ist die Größenänderung neutral für bestehende Module. Beim Einfügen in der Mitte würden alle Default-Tabellen verschoben.

## 4. `DefaultValueSolar`-Tabelle erweitern

In `ModulSolar_ext.st`, Funktion `DefaultValueSolar` (in der TAB-Region) die neuen Felder ergänzen:

```
00000$USINT,   //QuellenTyp        --> 0 = Solar (Default)
00060$USINT,   //RL_Soll           --> 60 °C
00003$USINT,   //RL_Hyst           --> 3 K
00140$USINT,   //MischerLaufzeit   --> 140 s
00000$USINT,   //MischerInvert     --> 0 = normal
00060$USINT,   //MinKesselTemp     --> 60 °C
```

## 5. Logik-Implementierung in IMPLEMENTATION-Region

Nach den obigen Schritten kompilieren (`batch.Compile(prj)`), dann den Logik-Code aus `Code_Vorlage_Holzofen_Mode.md` (im selben Verzeichnis) übernehmen:

1. `CyWork` – Modus-Verzweigung am Anfang des Automatik-Zweigs
2. Neue Methode `MischerCtrlRL()` ergänzen
3. `InitSolarDaten` – neue Parameter aus Tabelle übernehmen
4. `GetRetentiveJson` / `SetRetentiveJson` – JSON-Serialisierung erweitern
5. `LoginToDataLog` – neue Messwerte registrieren

## 6. Test

1. Kompilieren: Sigmatek LASAL Class IDE → Build → muss ohne Warnings durchlaufen
2. Download auf Test-PLC HZS 771 (.52)
3. Solar-Modus (P_QuellenTyp = 0): Verhalten muss identisch zur Vorversion sein
4. Feststoff-Modus (P_QuellenTyp = 1): Pumpe nur ab `P_MinKesselTemp`, Mischer reagiert auf `RL_Ist`

## 7. Sicherheitshinweis

Beim ersten Inbetriebnehmen des Feststoff-Modus an einer realen Anlage:
- Mischer manuell auf "AUS" testen (kein Stromfluss)
- `P_MischerLaufzeit` zunächst niedrig (z. B. 30 s) konfigurieren
- Endlagenschalter / mechanische Endanschläge prüfen
- Rücklauffühler-Plausibilität verifizieren (Realwerte 30-70 °C)

# Release Notes ModulSolar v2.2

> Quelle: `Stations/Dokumentation/Release_Notes_ModulSolar_v2_2.md` im onekey-Repo (Stand der Übernahme: 2026-07-26). Bei Codeänderungen dort zuerst aktualisieren.

# Release Notes – ModulSolar_ext v2.2

## Was wurde geändert

### Behobene Fehler (Solar-Modus)

1. **Pumpe stoppte während der Anlaufphase**
   Die Solarpumpe lief beim Einschalten nur für einen kurzen Moment an und fiel dann für 10 Sekunden auf 0 zurück, bevor der PID-Regler übernahm. Jetzt hält die Pumpe während der gesamten Anlaufphase die konfigurierte Startdrehzahl.

2. **Falsche Regelungsrichtung des PID**
   Bei zu heißem Kollektor reduzierte der PID-Regler bislang die Drehzahl, statt sie zu erhöhen. Dies führte im Extremfall zu Stagnationsrisiko. Die Regelungsrichtung wurde umgekehrt: Heißer Kollektor → höhere Pumpendrehzahl, kühler Kollektor → niedrigere Drehzahl.

3. **Falsche Drehzahl an Pumpe (interner Skalierungsfehler)**
   Durch einen Doppelschreib-Vorgang im PID-Pfad konnte der Pumpenausgang in Sekundenbruchteilen sprunghaft auf falsche Werte gehen. Behoben.

4. **Reset der Ausgänge beim Wechsel in Automatik**
   Beim Umschalten von Manuell auf Automatik wurden die digitalen Ausgänge (Relais 1–4) versehentlich zurückgesetzt. Der Reset findet jetzt nur noch beim Umschalten auf "Aus" statt.

5. **Pumpen-Betriebsstundenzähler nach Neustart auf 0**
   Der absolute Stundenzähler der Pumpe wurde nach einem Neustart nicht aus dem retentiven Speicher wiederhergestellt. Behoben.

6. **Speicher-Maximaltemperatur nach Werks-Reset auf 0**
   Nach Zurücksetzen auf Werkseinstellungen blieb der Parameter "Maximaltemperatur Speicher" auf 0, wodurch die Pumpe permanent gesperrt war. Der Default wurde auf 90 °C gesetzt.

7. **Pumpe bei Sensorausfall lief mit verzögerter Abschaltung**
   Bei Ausfall eines Fühlers (Kollektor oder Speicher) lief die Pumpe noch bis zu 5 Sekunden weiter. Sie wird jetzt sofort gestoppt.

### Neue Funktionalität

8. **Feststoffkessel-Modus (optional)**
   Das Modul kann zusätzlich zur Solarthermie auch einen Festbrennstoffkessel (Holz, Pellets) regeln, inklusive Rücklauf-Anhebung über einen 3-Wege-Mischer. Aktivierung über den neuen Parameter **Quellen-Typ**.

   Details: siehe Modul-Doku `ModulSolar.md`, Abschnitt 6.

## Migrations-Hinweis: Pumpen-Polarität

**Wichtig für Bestandsanlagen.**

Der Parameter **Pumpen-Polarität** (`P_InvertPWM`) hatte vor diesem Release eine inkonsistente Doppelbedeutung – er hat sowohl die Hardware-Polarität als auch die Regelungsrichtung "geheilt". Praktisch musste der Parameter bei allen Solarpumpen auf `1` stehen, damit die Anlage überhaupt funktionierte.

Ab v2.2 hat der Parameter ausschließlich seine korrekte Bedeutung:

| Wert | Bedeutung |
|---|---|
| **0** | Normale Pumpe: 0 V = Stillstand, 10 V = Maximum |
| **1** | Invertierte Pumpe: 10 V = Stillstand, 0 V = Maximum (z. B. Wilo Yonos PARA) |

**Bei Inbetriebnahme an einer Bestandsanlage muss dieser Wert einmalig überprüft und ggf. geändert werden.** Die meisten Anlagen mit Standardpumpen werden von `1` auf `0` zurückgesetzt werden müssen.

### Empfohlene Vorgehensweise

1. Vor dem Update aktuellen Wert von `P_InvertPWM` notieren
2. Update einspielen
3. Pumpentyp prüfen (Datenblatt der Pumpe)
4. Polarität entsprechend setzen
5. Im Manuell-Modus testen: Bei 50 % Solldrehzahl muss die Pumpe etwa halb laufen
6. Auf Automatik umschalten

## Technische Hinweise (Service)

- Modulbase: unverändert bei 1.8
- DECLARATION-Region nicht angefasst, alle Änderungen ausschließlich in IMPLEMENTATION
- Default-Tabelle (`DefaultValueSolar`): MaxTemp von 0 auf 90 geändert
- Neue Datenstruktur-Felder für Feststoff-Modus: siehe `IDE_Anleitung_ModulSolar_Feststoff_Erweiterung.md`

## Build-Information

- Erstellt für Modulbase 1.8
- Kompatibel mit allen HZS-Plattformen, die ModulSolar_ext unterstützen
- Empfohlen für Test-PLC: HZS 771 (.52)