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.

PowerMgr: Mein selbst gebautes Energie- und Smart-Home-System

PowerMgr ist mein eigenes Home-Energy-Management-System. Es verbindet Photovoltaik, Batteriespeicher, Wechselrichter, Wärmepumpe, Wetterdaten, Sensoren und Smart-Home-Schnittstellen zu einem lokalen System, das Messwerte sammelt und daraus Steuerentscheidungen ableitet.

Der Kern läuft auf einem kleinen Embedded-Linux-System mit Armbian und Docker. Das ist bewusst unspektakulär: kein proprietärer Smart-Home-Computer, keine komplette Neuverkabelung des Hauses, sondern ein dauerhaft laufender Linux-Rechner, der vorhandene Geräte einbindet und die relevanten Daten an einer Stelle zusammenführt.

Ausgangslage

Beim Hausbau war Smart Home zwar grundsätzlich ein Thema, praktisch fehlten aber viele der Dinge, die später wirklich wichtig wurden. Ein zusätzlicher Smart-Home-Computer hätte mehrere tausend Euro gekostet. Damit wären aber noch keine elektrischen Rollos, Tür- und Fenstersensoren, Heizungs- oder Kühlungssteuerungen und keine sinnvolle Einbindung der Energieanlage vorhanden gewesen.

Später kamen Angebote von Ingenieurbüros dazu, die das Haus für den Betrieb mit Batteriespeicher und Energiemanagement deutlich umfassender umgebaut hätten. Die Größenordnung lag im fünfstelligen Bereich bis etwa 25.000 EUR. Der technische und finanzielle Nutzen passte für mich nicht zusammen: Das Haus hätte teuer umgebaut werden müssen, obwohl viele Geräte bereits vorhanden waren und nur miteinander sprechen mussten.

PowerMgr entstand deshalb aus einem sehr konkreten Ziel: Vorhandene Hardware weiterverwenden, offene oder zumindest lokal kontrollierbare Schnittstellen nutzen und daraus ein System bauen, das zum realen Haus passt.

Warum Eigenbau?

Das Problem war nicht, dass es keine Smart-Home-Produkte gab. Das Problem war, dass die verfügbaren Lösungen die eigentlichen Energiefragen nicht gut genug beantworteten.

Für mich ging es nicht darum, eine Lampe per App einzuschalten. Das System sollte verstehen, wann Energie erzeugt, gespeichert, verbraucht oder ins Netz eingespeist wird. Daraus sollten Entscheidungen entstehen:

• Soll die Batterie geladen oder entladen werden?
• Ist genug PV-Leistung übrig, um die Kühlung zu starten?
• Muss die Lüftung laufen, weil die Luft im Haus schlecht ist?
• Soll eine Fahrzeugladung freigegeben, gedrosselt oder gestoppt werden?
• Sind Türen oder Fenster offen, obwohl die Kühlung aktiv werden soll?
• Welche Daten müssen in HomeKit, Grafana oder einer mobilen App sichtbar sein?

Dafür war ein klassisches Smart-Home-System zu oberflächlich. Ein reines Energiemonitoring hätte dagegen nur angezeigt, was passiert, aber nicht aktiv gesteuert. PowerMgr sitzt genau dazwischen: Es ist kein universelles Smart-Home-Framework, sondern eine lokale Steuerung für das eigene Haus und die eigene Energieanlage.

Systemüberblick

PowerMgr ist ein Python-Projekt mit Docker-Betrieb. Im Repository liegen unter anderem ein Dockerfile, eine docker-compose.yml, Konfigurationsdateien, ein Webinterface, dynamische Regeldateien und Module für die angebundenen Geräte.

Die wichtigste Struktur ist nicht eine einzelne große Steuerdatei, sondern die Trennung nach Aufgaben:

• powermgr.py startet den Hauptprozess.
• lib/ enthält Geräteanbindungen und gemeinsame Infrastruktur.
• dynamic/ enthält Regeldateien, die im Betrieb ausgewertet werden.
• dynamic_threads/ enthält länger laufende Regelpfade, zum Beispiel für die ESS-Leistungssteuerung.
• html/ stellt Webinterface und Statusseiten bereit.
• conf/ enthält Beispielkonfiguration und Betriebsparameter.

Die dynamischen Regeldateien werden nach ihrem dreistelligen Präfix sortiert ausgeführt. Dadurch ist der Ablauf im Betrieb nachvollziehbar: erst Grunddaten laden, dann Gesundheitszustände bewerten, Wetter und Homebridge-Status einlesen, anschließend Proxon, Shelly, EVCC und andere Steuerpfade behandeln.

Eingebundene Geräte und Datenquellen

PowerMgr bindet mehrere sehr unterschiedliche Systeme zusammen.

Die Photovoltaikseite wird unter anderem über einen StecaGrid-Wechselrichter ausgelesen. Das Modul lib/stecagrid.py liest die aktuelle AC-Leistung und schreibt die Daten für die spätere Auswertung nach InfluxDB.

Der Batteriespeicher wird über einen Victron MultiPlus II und Pylontech-Batterien eingebunden. Das Modul lib/energy_storage.py liest Inverter- und Batteriedaten, überwacht Zustände und stellt Funktionen bereit, um Lade- und Entladeleistungen zu setzen.

Die Zimmermann Proxon FTW-2 wird angezeigt und gesteuert. PowerMgr kann Betriebsart, Kühlung, Lüftung, Heizelemente und weitere Zustände berücksichtigen. Die Regeln dafür liegen unter anderem in dynamic/070-proxon-timed.py, dynamic/080-proxon.py und dynamic/090-proxon-t300.py.

Wetterdaten kommen aus einer eigenen Wetterstation, optionalen Oko-Wetterstation-Sensoren und OpenWeather. Das ist wichtig, weil Energieentscheidungen im Haus nicht nur vom aktuellen Stromwert abhängen. Für Kühlung und Lüftung spielen Außentemperatur, Tagesmaximaltemperatur, Raumtemperaturen und verfügbare PV-Leistung zusammen.

Zusätzlich sind Homebridge, Shelly-Geräte, Tür-/Fenstersensoren und EVCC.io angebunden. Dadurch werden Hauszustände, manuelle Freigaben und Fahrzeugladung Teil derselben Entscheidungslogik.

Vom Messen zum Steuern

PowerMgr sammelt nicht nur Daten. Das System entscheidet im Betrieb, ob eine Aktion sinnvoll ist.

Ein einfaches Beispiel ist die Kühlung. Wenn genug PV-Leistung verfügbar ist, die Außentemperatur hoch genug ist, die Tagesprognose passt, Türen und Fenster geschlossen sind und die Proxon in der passenden Betriebsart läuft, kann PowerMgr die Kühlung einschalten. Wenn die Batterie gerade lädt, kann diese Ladeleistung je nach Konfiguration als verfügbare Leistung mitgezählt werden. Wenn die Batterie entlädt, kann die Kühlung unter bestimmten Komfort- und SoC-Grenzen weiterlaufen oder durch Batterie-Fallback unterstützt werden.

Das ist der entscheidende Unterschied zu einer starren Zeitsteuerung. Die Anlage reagiert auf Hauszustand, Energiefluss und Komfortbedingungen.

Betrieb und Beobachtbarkeit

Der Betrieb ist lokal und nachvollziehbar aufgebaut. Das Webinterface zeigt Statusdaten, Konfiguration und Diagnoseinformationen. Zusätzlich schreibt PowerMgr Messwerte nach InfluxDB, sodass sie in Grafana ausgewertet werden können.

Für Steuerentscheidungen gibt es ein eigenes Decision-Logging. Neben dem normalen Textlog hält PowerMgr strukturierte Ereignisse im Speicher und stellt sie über diese Endpunkte bereit:

/decision_log
/decision_log.json

Damit lässt sich später sehen, was passiert ist und warum es passiert ist. Bei der Kühlung kann zum Beispiel sichtbar werden, ob PV-Überschuss, Batterieunterstützung, geöffnete Fenster, Wallbox-Ladung oder Temperaturgrenzen die Entscheidung beeinflusst haben. Bei der Batterie wird sichtbar, welcher Zielwert berechnet wurde und welche Eingangsgrößen beteiligt waren.

Ergebnis

Der praktische Nutzen liegt in der Eigenverwendung des erzeugten Stroms. Zu Beginn lag die eigene Nutzung der PV-Erzeugung nur grob bei 10 bis 15 Prozent. Im aktuellen Ausbau liegt sie nach eigener Messung bei etwas über 70 Prozent.

Das ist kein abstrakter Optimierungswert. Es bedeutet, dass mehr selbst erzeugter Strom im Haus bleibt: für Grundlast, Batterie, Kühlung, Lüftung, Heizelemente oder Fahrzeugladung. Gerade bei niedriger Einspeisevergütung ist das wichtiger als eine möglichst schöne Smart-Home-Oberfläche.

PowerMgr ist deshalb für mich weniger ein Smart-Home-Projekt im klassischen Sinn. Es ist ein lokales Energie- und Betriebsleitsystem für ein konkretes Haus.