PowerMgr in der Praxis: PV, Batterie, Kühlung und Hauszustand steuern

PowerMgr geht über eine Sammlung von Gerätetreibern hinaus. Der interessante Teil liegt in der Regelung: Aus Messwerten, Zuständen und Konfiguration entsteht im laufenden Betrieb eine Entscheidung, ob geladen, entladen, gekühlt, gelüftet oder eine Fahrzeugladung freigegeben wird.

Der erste PowerMgr-Artikel beschreibt, warum das System entstanden ist und welche Geräte es verbindet. Dieser zweite Teil schaut auf die praktische Steuerlogik.

Datenfluss

PowerMgr arbeitet mit mehreren Datenquellen, die unterschiedliche Bedeutung haben.

Der Stromfluss im Haus kommt aus Leistungsmessung, PV-Wechselrichter und Batterie-Inverter. Die Batteriedaten kommen vom Victron MultiPlus II und den Pylontech-Batterien. Wetterdaten kommen aus lokaler Wetterstation, Oko-Wetterstation-Sensoren und OpenWeather. Hauszustände wie Tür-/Fensterstatus oder manuelle Freigaben kommen über Homebridge und weitere Sensoren dazu.

Diese Werte landen nicht bloß in einer Oberfläche. Sie werden in den dynamischen Regeln verwendet. Im Repository ist diese Trennung gut sichtbar:

• dynamic/020-load-device-data.py lädt Gerätedaten.
• dynamic/025-health.py behandelt Health- und Fehlerzustände.
• dynamic/030-weather.py verarbeitet Wetterdaten.
• dynamic/040-homebridge-states.py liest Homebridge-Zustände.
• dynamic/050-door-window-sensor-handling.py bewertet Tür- und Fensterzustände.
• dynamic/070-proxon-timed.py trifft zeitabhängige Proxon-Entscheidungen.
• dynamic/080-proxon.py enthält zusätzliche Proxon-Gates.
• dynamic/110-evcc.py steuert EVCC.io-Modi.
• dynamic_threads/rules/010-energy-storage.py berechnet die ESS-Zielleistung.

Die Regeldateien sind dadurch klein genug, um einzelne Entscheidungen nachvollziehen zu können, ohne das ganze System in einer einzigen Datei zu verstecken.

Batterie und MultiPlus II

Die ESS-Regelung läuft im dynamischen Thread 010-energy-storage.py. Dort wird aus Netzleistung, Inverterleistung und geglätteten Werten ein Zielwert für den Batteriespeicher berechnet.

Ein wichtiger Punkt ist die Bedeutung der Vorzeichen. PowerMgr muss unterscheiden, ob das Haus gerade Leistung aus dem Netz bezieht, Leistung einspeist, die Batterie lädt oder die Batterie entlädt. Zusätzlich beeinflusst der Batterie-Inverter selbst die gemessene Leistung. Deshalb berechnet die Regel eine korrigierte reale Leistung:

p_real = power_phases_connected - p_inv

Danach wird dieser Wert geglättet und als p_real_lp verwendet. Aus diesem geglätteten Wert entstehen zwei Richtungen:

• corrected_charge_power: verfügbare Leistung zum Laden
• corrected_discharge_power: Bedarf, der durch Entladen gedeckt werden kann

Erst danach greifen Hysterese, Schrittbegrenzung, Mindestleistungen, SoC-Grenzen, Temperaturprüfung und Fallback-Regeln. Am Ende wird entweder Ladeleistung gesetzt, Entladeleistung gesetzt oder die Leistung auf null gestellt.

Diese Reihenfolge ist wichtig. Ohne Glättung und Begrenzung würde die Batterie auf jede kleine Schwankung reagieren. Ohne korrigierte Leistung würde der Regler teilweise auf Werte reagieren, die bereits durch den eigenen Inverter verfälscht sind.

Kühlung über die Proxon FTW-2

Die Proxon-Steuerung ist einer der sichtbarsten Teile von PowerMgr, weil sie Komfort und Energie direkt verbindet.

Die Datei COOLER_CONTROL.md dokumentiert die wichtigsten Kühlungs-Flags. Sie sind als Erlaubnis-Gates zu verstehen. Ein gesetztes Flag bedeutet nicht automatisch, dass die Kühlung gestartet werden muss. Es bedeutet nur, dass die Kühlung in diesem Zustand laufen darf, wenn alle anderen Bedingungen ebenfalls passen.

Für einen automatischen Start prüft dynamic/070-proxon-timed.py unter anderem:

• verfügbare Leistung oder Batterieunterstützung
• aktueller Kühlungszustand
• Intensivlüftung
• Außentemperatur
• erwartete Tagesmaximaltemperatur
• Proxon-Betriebsart
• Tür-/Fensterzustände
• Anwesenheit, falls konfiguriert
• Mindestabstand zwischen mechanischen Schaltvorgängen

Der mechanische Schaltabstand ist bewusst defensiv. Auch wenn die Konfiguration einen niedrigeren Wert erlauben würde, erzwingt der Code für den Proxon-Kühler mindestens 7200 Sekunden. Dadurch wird verhindert, dass die Anlage durch kurzfristige Leistungsschwankungen ständig ein- und ausgeschaltet wird.

Wenn die Batterie gerade lädt und cooler_run_while_battery_charge erlaubt ist, kann die Ladeleistung zur verfügbaren Kühlleistung addiert werden. Wenn die Batterie entlädt, startet die Kühlung nicht einfach deshalb. Ein Start über Batterie-Fallback ist nur möglich, wenn zusätzliche Bedingungen passen: SoC, verfügbare Entladeleistung, Außentemperatur, Raumtemperatur und die konfigurierten Leistungsgrenzen.

Das Ergebnis ist keine einfache Regel wie „bei Sonne kühlen“. PowerMgr versucht, Kühlung dann zu nutzen, wenn das Haus davon profitiert und die Energie dafür sinnvoll verfügbar ist.

Lüftung, Luftqualität und Hauszustand

Neben der Kühlung ist auch die Lüftung Teil des Systems. Der praktische Hintergrund ist Komfort und Luftqualität im Haus. Wenn die Luft abends schlecht ist, kann automatische Lüftung wichtiger sein als eine rein energetisch optimale Entscheidung.

PowerMgr verarbeitet dafür Hauszustände und Sensorinformationen gemeinsam mit den Energieflüssen. Tür- und Fenstersensoren sind dabei keine Dekoration. Eine offene Tür oder ein offenes Fenster kann beeinflussen, ob Kühlung oder Proxon-Zustände geschaltet werden sollen. Homebridge liefert außerdem Steuerflags, mit denen bestimmte Automatiken erlaubt, gesperrt oder manuell übersteuert werden können.

Damit bleibt das System lokal bedienbar. Automatik und manuelle Eingriffe schließen sich nicht aus; sie müssen aber im selben Regelpfad sichtbar sein, damit PowerMgr nicht gegen den tatsächlichen Zustand des Hauses arbeitet.

EVCC.io und Fahrzeugladung

Die Datei dynamic/110-evcc.py zeigt, wie PowerMgr die Fahrzeugladung in die restliche Energielogik einbindet.

EVCC.io bleibt dabei das System für die Ladesteuerung. PowerMgr entscheidet aber, wann ein Modus freigegeben oder deaktiviert wird. Dafür werden verfügbare Leistung, Homebridge-Freigaben, Batterie-Ladezustand, Proxon-Kühlung und Wallbox-Zustand berücksichtigt.

Wenn genug überschüssige Leistung vorhanden ist, kann PowerMgr den konfigurierten EVCC-Standardmodus setzen. Wenn Homebridge die Ladung sperrt oder die verfügbare Leistung zu gering wird, kann PowerMgr EVCC.io wieder auf off setzen. Zusätzlich gibt es Overwrite-Pfade, über die eine manuelle Ladefreigabe Vorrang bekommen kann.

Die Fahrzeugladung wird dadurch nicht isoliert betrachtet. Sie konkurriert mit Batterie, Kühlung und Hausverbrauch um dieselbe Energie.

Fehlerzustände und Decision-Logs

Ein System, das reale Geräte steuert, braucht nachvollziehbare Fehler- und Diagnosepfade.

PowerMgr trennt das Laden von Gerätedaten und die Bewertung der Health-Zustände. Ein Proxon-Lesefehler, ein Batterieproblem oder ein fehlender Wetterstationswert soll nicht still verschwinden. Gleichzeitig darf eine kurzzeitige Störung nicht automatisch wie ein bestätigter Gerätefehler behandelt werden, ohne dass später nachvollziehbar bleibt, was passiert ist.

Dafür gibt es zwei Ebenen:

• normale technische Logs über print_log(...)
• strukturierte Decision-Logs für Steuerentscheidungen

Die Decision-Logs enthalten Komponente, Ereignis, Ergebnis, Grund, Eingangsgrößen und Grenzwerte. Bei ESS-Entscheidungen stehen dort zum Beispiel Zielwert, letzter Wert, p_real_lp, unused_pv_lp, power_lp und SoC. Bei Proxon-Entscheidungen werden verfügbare Leistung, Batterieunterstützung, Temperaturwerte und Gründe wie pv_surplus oder battery_support sichtbar.

Das ist im Betrieb entscheidend. Wenn die Kühlung nicht startet, reicht ein „aus“ im Status nicht. Interessant ist, ob Leistung fehlte, die Betriebsart nicht passte, ein Fenster offen war, der Schaltabstand noch lief oder die Batteriegrenze erreicht wurde.

Warum die Regelung lokal bleibt

PowerMgr läuft lokal auf Embedded Linux und wird als Docker-Container betrieben. Das reduziert Abhängigkeiten von Cloud-Diensten und hält die Steuerung nah an den Geräten. Externe Dienste wie OpenWeather oder EVCC.io können eingebunden werden, aber die Grundlogik bleibt im eigenen System.

Für ein Energiemanagement im Haus ist das ein wichtiger Unterschied. Wenn PV, Batterie, Wärmepumpe, Lüftung und Fahrzeugladung zusammenhängen, reicht eine Sammlung loser App-Automatiken nicht aus. Die zentrale Regelung muss Zustände zusammenführen, Konflikte auflösen und begründen können, warum sie gerade nichts tut.

PowerMgr ist genau aus diesem Bedarf gewachsen: messen, bewerten, entscheiden, begrenzen und später erklären können, warum diese Entscheidung getroffen wurde.