Teil 6 der Serie „Smart Home in der Praxis". Die Teile 2 bis 5 haben die Wärmepumpe an die eigene Zentrale geholt. Jetzt kommt die Instanz, die daraus ein System macht: ein selbst gebautes Energiemanagement. Teil 7 zeigt das PV-Setup dahinter, Teil 8 zieht Bilanz.
Energiemanagement in Home Assistant beginnt fast immer gleich: eine Automation fürs Überschussladen, eine für den Warmwasser-Boost, eine für die Nachtentladung des Speichers - und zwei Jahre später pflegt man ein Dutzend Automationen, die sich gegenseitig nicht kennen, aber dieselben Geräte schalten. Bei mir kam ein Ausfall dazu: Als die Wärmepumpe ihre Cloud-Anbindung verlor, lagen die Energie-Automationen still, und beim Wiederaufbau wollte ich das Geflecht nicht noch einmal.
Daraus ist HEMS geworden, ein Home Energy Management System als eigene Home-Assistant-Integration - installierbar über HACS, quelloffen auf GitHub, MIT-Lizenz. Dieser Beitrag erzählt die Entwurfsentscheidungen; die vollständige Dokumentation samt aller Konfigurationsparameter steht im Repository.
Warum kein fertiges Werkzeug
Für Home Assistant gibt es mit EMHASS einen ausgewachsenen Energie-Optimierer, der die Verteilung als mathematisches Optimierungsproblem löst. Das ist das richtige Werkzeug, wenn stündlich wechselnde Strompreise gegen Prognosen abgewogen werden müssen. Mein Fall ist einfacher: fester Strompreis, keine Einspeisevergütungs-Akrobatik, ein klares Ziel - Autarkie zuerst, das Netz ist Rückfallebene, nie Optimierungsziel.
Bei so einer Zielfunktion schlägt Nachvollziehbarkeit die mathematische Eleganz. HEMS rechnet deshalb mit einer Heuristik: ein rollierender Plan in 15-Minuten-Slots über 24 bis 48 Stunden, und in jedem Slot eine feste, erklärbare Reihenfolge - Warmwasser-Grundbedarf zuerst, dann der Hausverbrauch, dann je nach Prognoselage Komfort-Warmwasser, Speicher oder E-Auto, und was übrig bleibt, wird eingespeist. Wenn das System etwas Unerwartetes tut, lese ich die Regel, die es getan hat - statt einen Löser zu befragen, warum sein Optimum so aussieht.
Rollen statt Entity-IDs
Die zweite Entscheidung: Der Planner kennt keine Hersteller und keine Entity-IDs, nur Rollen. Konfiguriert wird komplett über die Oberfläche:
| Rolle | Beispiel bei mir |
|---|---|
| Zähler (genau einer) | Hauptzähler, Momentanleistung am Netzanschluss |
| Prognosefläche | drei PV-Dachflächen Ost, Süd, West |
| Speicher | drei Batteriespeicher, je Phase einer |
| Wärmespeicher | der Warmwasserspeicher |
| Schaltbare Last | die Wärmepumpe, mit Taktschutz |
| Modulierbare Last | die Wallbox, über den Ladestrom |
Mehrere Speicher verschmelzen zu einem virtuellen Gesamtspeicher; Sollwerte verteilen sich proportional zur freien Kapazität. Ein vierter Akku ist eine neue Instanz im Konfigurationsdialog, keine Codeänderung. Und weil die Rollen abstrakt sind, läuft dieselbe Integration auch mit ganz anderer Hardware - genau deshalb ist sie als eigenes Repository veröffentlicht statt als Sammlung meiner Automationen.
Eine Prognose, die aus dem eigenen Haus lernt
Jede Planung steht und fällt mit zwei Fragen: Was liefert die Sonne noch, und was verbraucht das Haus? Für die erste aggregiert HEMS beliebig viele Prognoseflächen (etwa aus Forecast.Solar). Für die zweite lernt es den Verbrauch aus der eigenen Historie: aus 28 Tagen Langzeitstatistik entsteht ein 24-Stunden-Lastprofil je Wochentagstyp - Werktage ticken anders als Wochenenden. Solange die Historie dafür noch nicht reicht, greift eine Fallback-Kette bis hinunter zur konfigurierten Grundlast. Daraus entstehen die Größen, mit denen der Plan rechnet: erwarteter Überschuss, Nachtdefizit, Sonnenfenster.
Beobachten vor Steuern
Die wichtigste Eigenschaft von HEMS ist, was es standardmäßig nicht tut: schalten. Der Modus hat drei Stufen - beobachten (Standard) rechnet Empfehlungen und zeigt sie nur an, auto schreibt sie zusätzlich auf konfigurierte Steuer-Entitäten, aus ist der Kill-Switch ohne jeden Schreibzugriff. Wer die Integration einrichtet, schaut dem Planner erst tagelang zu und vergleicht seine Empfehlungen mit dem eigenen Bauchgefühl, bevor irgendein Gerät ihm gehorcht.
Auch im Auto-Modus bleibt der ausführende Teil bewusst konservativ: Er schreibt nur auf explizit konfigurierte Entitäten, nur bei tatsächlicher Wertänderung, nie auf eine unbekannte Empfehlung, und ein Fehler an einem Gerät reißt die anderen nicht mit. Schaltbare Lasten haben einen Taktschutz mit Mindestlauf- und Mindestpausenzeiten - eine Wärmepumpe verzeiht vieles, aber kein minutenweises Ein und Aus. Und ein Sanity-Check meldet Konfigurationsfehler, bevor sie zu Fehlschaltungen werden.
Die Details, die der Alltag lehrt
Drei Beispiele dafür, was zwischen Konzept und Version 1.0 dazukam, weil der Betrieb es erzwungen hat:
- Ein Ladedeckel schont die Akkus. Kalendarische Alterung ist bei hohem Ladestand am größten - also hält HEMS die Speicher tagsüber bei 78 Prozent und lädt erst in den letzten Stunden vor Sonnenuntergang per Rampe auf 100, sodass sie möglichst wenig Zeit voll verbringen. Reicht der erwartete Restertrag dafür nicht mehr, fällt der Deckel sofort - lieber voll in die Nacht als geschont und leer.
- Sprünge lösen Neuberechnung aus. Regulär rechnet HEMS jede Minute. Springt der Netzsaldo um mehr als 800 Watt - Wolkenkante, Herd an -, wird sofort neu gerechnet statt bis zum nächsten Takt zu warten; ein Cooldown verhindert Update-Stürme.
- Das Ziel ist umschaltbar. Ein Auswahlfeld wechselt zur Laufzeit zwischen Eigenverbrauch, echter Nulleinspeisung und Vollladen - samt der ehrlichen Fußnote in der Doku, wo die physikalischen Grenzen liegen.
Sichtbar wird all das in einem eigenen Seitenleisten-Panel mit Lastfluss-Diagramm und einer Plan-Karte, die die nächsten Stunden zeigt: wann der Speicher entlädt, wann Warmwasser geladen wird, wie sich der Ladestand voraussichtlich entwickelt.
Grenzen und Ausblick
HEMS ist bewusst als Phasenprojekt angelegt: Beobachten und Empfehlen sind stabil, die Aktuierung ist optional zuschaltbar, und als nächste Ausbaustufe ist eine Simulation geplant, die die eigene Vergangenheit mit virtuellen Akkugrößen durchrechnet - was hätte ein vierter Speicher wirklich gebracht, in Kilowattstunden und Euro statt im Prospekt. Die Wärmepumpe aus den Teilen 2 bis 5 hängt als Rolle mit im System.
Wer das nachbauen oder einfach nur zusehen lassen will: Das Repository enthält Installation, alle Parameter mit Erklärung und die Dashboard-Karten. Rückmeldungen und Messwerte aus anderen Setups sind ausdrücklich willkommen - das Rollenmodell ist genau dafür da.
Teil 7 zeigt als Nächstes die Anlage, an der das alles hängt: Photovoltaik auf drei Dachflächen, drei Speicher - und was dynamische Strompreise daran ändern würden.
Quellen
- GitHub: hahems - die Integration samt vollständiger Dokumentation und Konzeptpapier
- GitHub: EMHASS - der Energie-Optimierer, gegen den die Heuristik-Entscheidung fiel
- HACS: Home Assistant Community Store - Installationsweg für Custom Integrations
- Forecast.Solar: PV-Prognosedienst - Quelle der Flächenprognosen im Beispiel-Setup
- Home Assistant: Projekt-Website - die Plattform, auf der alles läuft