Wenn das Haus für ein paar Tage leer steht, sollen Heizung, Speicher und Kameras nicht einfach nur weiterlaufen wie sonst. In meinem aktuellen Home-Assistant-Setup greifen deshalb drei Bereiche ineinander: Der Kalender setzt die Heizung in einen kontrollierten Abwesenheitsmodus, Strom wird möglichst in günstigen Zeitfenstern genutzt und die Sicherheitslogik fasst relevante Kameraereignisse zusammen.

Im Video zeige ich den Stand, den ich über mehrere Monate aufgebaut habe. Dazu gehören meine Wolf-Gastherme, Better Thermostat, EcoFlow-Speicher, Tibber-Daten, Reolink-Kameras und Alarmo. Der wichtigste Teil ist aber nicht die Zahl der Integrationen. Es sind die Freigaben, Rückmeldungen und Fallbacks dazwischen. Genau dort entscheidet sich, ob aus einer hübschen Automation ein belastbarer Ablauf wird.

Code-Hinweis: Die Beispiele zum Video liegen in meinem öffentlichen GitHub-Repository. Dort sind nur anonymisierte Entity-IDs enthalten. Das Paket ist ein anpassbares Beispiel und kein 1:1-Export meines Hauses. Lies vor dem Einbau die dokumentierten Grenzen.

Abwesenheit beginnt bei mir im Kalender

Für Reisen verwende ich keinen zusätzlichen Urlaubs-Schalter, den ich irgendwann vergesse. Ein Eintrag im Familienkalender bekommt die Markierung [Heizung]. Home Assistant prüft diese Termine und setzt die Better-Thermostat-Räume während des definierten Fensters auf den Eco-Modus. Der Heizkreis der Wolf-Therme kann separat auf Standby wechseln. Warmwasser und Raumheizung behandle ich dabei bewusst getrennt.

Das öffentliche Beispiel beginnt das Abwesenheitsfenster um 15 Uhr am ersten Tag und beendet es um 8 Uhr am letzten Tag. Dadurch kann das Haus vor der Rückkehr wieder auf Temperatur kommen. Das sind meine Zeitpunkte, keine allgemeingültigen Vorgaben. Lokale Zeitzone, ganztägige Kalendereinträge und das exklusive Enddatum eines Kalendertermins müssen zum eigenen Kalender passen.

Wichtiger als der Trigger ist die Rückmeldung: Die Automation wartet nach einem Schreibbefehl darauf, dass das Thermostat-Preset oder der Wolf-Select den erwarteten Zustand meldet. Erst danach setzt sie einen Ownership-Merker. Beim Rückweg wird nur zurückgestellt, was die Automation vorher selbst übernommen hat. Der kommentierte YAML-Baustein für die Kalender-Abwesenheit zeigt den vollständigen Ablauf.

Wärmebedarf statt blindem Brennerstart

In der Übergangszeit habe ich an meiner Anlage zeitweise 50 bis 100 Brennerstarts pro Tag gesehen. Mein Ansatz dagegen ist ein gewichteter Wärmebedarf. Jeder Raum liefert ein Signal aus Solltemperatur, Isttemperatur und Heizaktion. Räume mit zwei Heizflächen können stärker gewichtet werden. Zwei Wärmeflächenpunkte reichen für einen Startwunsch; alternativ greift ein Komfortpfad, wenn ein Raum mindestens zwei Grad unter seinem Soll liegt.

Ein Haltesignal verhindert, dass der Bedarf sofort verschwindet, sobald der erste Raum warm ist. Dazu kommen Zeitfilter: Das Startsignal muss stabil sein, ebenso das Komfortdefizit. Fehlende oder unplausible Sensordaten zählen nicht einfach als Wärmebedarf. Sie machen einen Raum ungültig und begrenzen, wann die Logik überhaupt freigeben darf.

Im Repository ist dieser Teil absichtlich als Shadow ausgeführt. Er berechnet und visualisiert den Bedarf, schaltet aber keinen Kessel. Für eine physische bedarfsgeführte Wolf-Regelung fehlen im veröffentlichten Beispiel noch der sichere Aktorpfad, ein eigener Freigabeschalter, der Zustands-Readback und Tests mit der echten Anlage. Die Heizungsdokumentation trennt diesen Shadow sauber von der Kalender-Automation.

Sicherheitshinweis: Heizkurve, Vorlauf, Brennersperren und Kesselparameter gehören nicht in eine Automation, nur weil Home Assistant die passende Entität anbietet. Einstellungen müssen zur Anlage passen und im Zweifel mit einem Heizungsfachbetrieb abgestimmt werden. Auch Frost- und Feuchteschutz brauchen einen unabhängigen Rückfallweg, wenn Home Assistant, MQTT oder ein Thermostat ausfällt.

Strompreis als Freigabe, nicht als Selbstzweck

Meine EcoFlow-Speicher lasse ich derzeit weitgehend über den KI-Plus-Modus des Herstellers arbeiten. Home Assistant liest die Daten aus und macht Lade- und Entladeleistung sichtbar. Im Video ist zu sehen, wie das System günstige Stunden nutzt. Die veröffentlichte YAML steuert den Speicher jedoch nicht. Sie trennt lediglich positive und negative Leistung und bildet daraus Energiesensoren.

Aktiv nutze ich den Preis für die Wallbox. Ein Template markiert ein Zeitfenster als günstig, wenn der Strompreis unter 0,20 Euro pro Kilowattstunde liegt oder der aktuelle Wert zu den günstigsten 25 Prozent des Tages gehört. Im Beispiel lautet die Logik vereinfacht:

guenstig = preis_eur_kwh < 0.20
           oder intraday_price_ranking <= 0.25

Das Preis-Template im Repository prüft zusätzlich, ob Preis und Ranking numerisch und plausibel sind. Die Wallbox bekommt nur dann eine Ladeerlaubnis, wenn das Auto angeschlossen ist, mindestens eine bekannte Person zu Hause ist und die manuelle Freigabe aktiv ist. Ein unbekannter oder nicht verfügbarer Freigabestatus wird nicht als Zustimmung behandelt.

Eine bereits laufende Ladung stoppt im Beispiel nicht allein wegen eines späteren Preisanstiegs. Das verhindert hektisches Ein- und Ausschalten an einer Tarifgrenze. Ob dieses Verhalten zum eigenen Auto, zur Wallbox und zum Tarif passt, muss jeder selbst entscheiden. Die Energie-Dokumentation beschreibt auch die Grenzen der Kostenschätzung. Sie ist keine abrechnungsfeste Messung.

Wie sich der EcoFlow STREAM AC 5000 mit einem dynamischen Tarif verhält, habe ich bereits ausführlicher im Artikel EcoFlow STREAM AC 5000 im Test beschrieben. Für die Visualisierung der PV- und Hausdaten nutze ich weiterhin die Solar Energy Card.

Kameraereignisse als kurze Episoden auswerten

Bei der Haussicherheit bleiben die Reolink-Kameras und der NVR zuerst eigenständig. Aufnahmen sollen nicht davon abhängen, ob Home Assistant oder ein externer Analysedienst gerade erreichbar ist. Home Assistant ergänzt diese Ebene: Wenn eine Kamera eine Person oder ein Tier erkennt, kann eine Automation in festen Abständen Snapshots sichern und sie zu einer Episode zusammenfassen.

Das spart gegenüber einer dauerhaften Videoanalyse Daten und Rechenzeit. Im Video beschreibe ich einen Ablauf, bei dem der externe Dienst erst nach Abschluss einer Episode benachrichtigt wird. Im öffentlichen Repository sind die Snapshot-Automationen, die lokale Medienpflege, der Abschluss-POST und ein Validator für die Metadaten enthalten. Ein fertiger KI-Dienst ist dort ausdrücklich nicht enthalten. Authentifizierung, Wiederholungsversuche, Deduplizierung, Bildtransfer und Modellaufruf müssen für einen echten Ende-zu-Ende-Betrieb ergänzt werden.

Die Kamera-Dokumentation erklärt den Datenfluss für sechs Zonen. Sie nennt auch einen Punkt, den man leicht übersieht: Dateien unter /media sind für angemeldete Home-Assistant-Benutzer über die Media Source erreichbar. Dateirechte allein trennen diese Inhalte nicht zwischen den HA-Konten.

Alarmo bleibt eine eigene Schutzebene

Für die Alarmanlage setze ich weiterhin auf Alarmo. Präsenzsensoren sind für mich als Auslöser geeigneter als reine Kamera-Bewegungssensoren, weil Pixeländerungen und Wetter bei Kameras zusätzliche Fehlalarme erzeugen können. Der Nachtmodus schaltet Innenaufnahmen und weitere Hausfunktionen. Bei einem Alarm können Beleuchtung und vorhandene Sirenen reagieren.

Auch hier bleibt das veröffentlichte Beispiel bewusst eng: Es beobachtet den Alarmo-Zustand triggered, schließt bei bestätigter Abwesenheit eine geschlossene Tür mit Readback ab und steuert definierte Aufnahme-Schalter. Es schaltet Alarmo weder scharf noch unscharf und enthält keinen Entriegelungsbefehl. Sensorzuordnung und Alarmmodi bleiben in der Alarmo-Oberfläche.

Was ich aus dem Gesamtaufbau mitnehme

Die drei Bereiche brauchen unterschiedliche Fehlerstrategien. Bei der Heizung muss ein Ausfall in einen sicheren und für das Gebäude verträglichen Zustand führen. Bei der Wallbox bedeutet ein unbekannter Preis oder eine fehlende Freigabe: nicht neu laden. Bei den Kameras muss die lokale Aufzeichnung weiterlaufen, auch wenn die Zusammenfassung ausfällt.

Deshalb sind die YAML-Dateien im Repository nicht nur nach Heizung, Energie und Sicherheit sortiert. Jeder Baustein nennt seine Abhängigkeiten und seine Sicherheitsgrenze. Das vollständige Paket und einzelne Dateien dürfen nicht parallel installiert werden. Vor echten Aktorbefehlen gehören angepasste Entity-IDs, Secrets, ein Konfigurationscheck und Tests mit deaktivierten Freigaben dazu.

Wer zuerst die grundlegenden Muster hinter meinen Automationen prüfen möchte, findet sie auch in meinen Home-Assistant-Best-Practices für Automationen, Zigbee und Kameras. Der neue Aufbau geht einen Schritt weiter: Er verbindet Kalender, Tarifdaten und Ereignisse miteinander, ohne jedem Sensor sofort das Recht zu geben, ein reales Gerät zu schalten.