Heizungsautomatisierung (ioBroker)

Ich hab über’s letzte Jahr alle meine Raumthermostate in der Wohnung gegen smarte Varianten ausgetauscht (ich hab welche von der Firma Meross¹ genommen) – das Ziel war (neben Spieltrieb als solchem) natürlich Bequemlichkeit und weniger Heizkosten.

Heute will ich mal zusammenschreiben, wohin das mittlerweile eskaliert ist und was es nun alles kann.

Ausgangslage und Ziel

In einem typischen Haushalt sind Heizpläne, Anwesenheit, offene Fenster und Sonderfälle (Urlaub, Ferien, Krankheit, Homeoffice usw.) schwer über einen einzigen Heizplan zu erschlagen. Die Standard-Lösung der gewählten Thermostate war zwar nett, aber am Ende immer zu simpel. Man kann einen Wochenplan festlegen und natürlich manuell am Thermostat eingreifen und den Wochenplan übersteuern. Toll fand ich, dass man einstellen konnte, dass nach 1, 2 oder 4 h jeweils zum Automatikplan zurückgekehrt werden soll. Trotzdem war das zu unflexibel.

Im ersten Verbesserungsschritt hatte ich Fenstersensoren angebracht und ein einfaches

• Fenster auf → 15 °C einstellen
• Fenster zu → Thermostat auf AUTO (also Wochenplan) stellen

implementiert.

Aber auch das ist am Ende zu unterkomplex. Wie erstellt man einen Wochenplan, der immer passt, ohne ständig zu viel zu heizen? Kinder haben Schule, Kinder haben Ferien, Kinder sind krank, Erwachsene sind bei der Arbeit (manchmal im Homeoffice), Erwachsene sind auch mal krank – Familie ist außer Haus (tagsüber), Familie ist verreist. Das alles passt einfach nicht in einen Wochenplan, und ständig umdefinieren will man den auch nicht.

Ziel meiner Heizungssteuerung war daher etwa das hier:

• Komfort: Die Räume sollen zur richtigen Zeit die passende Temperatur haben.
• Effizienz: Unnötiges Heizen soll vermieden werden (Fenster offen, niemand zu Hause, Nachtabsenkung).
• Robustheit: Das System soll stabil laufen, im Zweifel also lieber ein Fallback auf den „Normal-Plan“ oder auf 20 °C, als abstürzen und gar nichts mehr steuern.
• Transparenz: Informationen sollen als States einfach sichtbar sein (für Historie, Feintuning und Fehlersuche).
• Erweiterbarkeit: Neue Regeln/Signale sollen integrierbar sein, ohne alles neu zu bauen.

ioBroker + JavaScript

Die ganze Welt macht mittlerweile HomeAssistant, aber ich hab hier eine relativ umfangreiche ioBroker-Installation – und auch wenn ich immer noch mit dem Gedanken spiele, auf HA umzusteigen, so hab ich das jetzt erst mal in ioBroker reingecodet.
Mittel der Wahl war hier ein einfaches JavaScript im Scripting-Adapter, das alle seine Persistenzbedürfnisse über States im normalen ioBroker-State-Tree abfackelt.

Ein Orchestrator, mehrere Manager

Das System ist bewusst modular aufgebaut. Es gibt einen zentralen Controller, der regelmäßig (Intervall ist 60 s) alle Räume aktualisiert. Die eigentliche Intelligenz ist auf spezialisierte „Manager“ verteilt.

• Jeder Baustein hat eine klare Verantwortung.
• Konfiguration, Sensoren und Aktoren sind entkoppelt.
• Komplexe Wechselwirkungen (z.B. Fensterkontakt pausiert manuellen Override) sind an genau einer Stelle definiert.

Die Manager sind diese:

• Thermostat-Manager (steuert die Thermostate)
• Schedule-Manager (verwaltet die Zeitpläne)
• PreHeating-Manager (steuert das Vorheizen)
• Window-Manager (greift ein, wenn sich Fenster öffnen oder schließen)
• Kalender-Manager (verwaltet den Einfluss von Kalendereinträgen, Schulfrei, Feiertage)
• Präsenz-Manager (verwaltet den Einfluss der generellen Anwesenheit in der Wohnung)
• Manueller-Override-Manager (steuert den Einfluss von manuellen Eingriffen an den Thermostaten)
• Bewegungs-Manager (verwaltet den Einfluss von Bewegungsmelder-Signalen in einzelnen Räumen)

Wie das alles zusammenspielt, dazu gleich mehr.

⚙️ Zeitpläne mit 15-Minuten-Granularität

Die Basis ist ein Zeitplan pro Raum. Die Zeitpläne sind in 15-Minuten-Schritten gedacht, damit typische Heizprofile gut abgebildet werden können, ohne dass es beliebig fein (und damit schwer wartbar) wird.

Die Pläne liegen in einfachen JSON-Dateien, die man mit jedem Editor einfach anpassen kann – einmal konfiguriert ist das aber kaum noch nötig. Zuletzt jetzt zum Schulhalbjahr, als sich der Stundenplan der Kids geändert hat.

heizungssteuerung_iobroker/
├── heizungssteuerung.js          # Hauptskript mit allen Modulen
└── heating/
    └── config/
        ├── rooms.json             # Raumkonfiguration
        ├── global-settings.json   # Globale Einstellungen
        ├── calendar-profiles.json # Kalender-Keywords und Prioritäten
        └── schedules/             # Zeitpläne pro Raum
            ├── wohnzimmer.json
            ├── kueche.json
            ├── bad.json
            ├── kinderzimmer.json
            ├── arbeitszimmer.json
            └── schlafzimmer.json

Wichtige Eigenschaften:

• Pro Wochentag und Modus kann ein eigener Satz von Zeitblöcken existieren.
• Fehlt ein Modus, wird auf „normal“ zurückgefallen.

⏱️ Vorheizen (Look-Ahead) statt „erst ab Startzeit“

Jetzt kommen wir zu den ersten smarten Sachen: Ein klassischer Zeitplan schaltet die Zieltemperatur erst zur Startzeit hoch. In der Praxis ist der Raum dann aber erst viel zu spät warm, weil so eine Heizung (vor allem eine Fußbodenheizung) ziemlich träge ist. Ich hab aber gleich am Anfang, bei der Benutzung der eingebauten Thermostat-Schedules gemerkt, dass es mich nervt, beim Erstellen des Zeitplans nicht

„Ich will es montags in einer Arbeitswoche morgens um 6:30 Uhr im Bad schön warm haben, also 21,5 °C“

zu denken, sondern

„Ich will es montags in einer Arbeitswoche morgens um 6:30 Uhr im Bad schön warm haben, also 21,5 °C, die Heizung braucht dafür vermutlich 1 h, aber das kommt ja auch drauf an, wie weit es in der Nacht wirklich abgekühlt ist – ach fuck it – heizen ab 4:30 Uhr.“

Meine Steuerung verwendet daher ein Look-Ahead-Konzept:

• Es wird nicht nur der aktuelle Sollwert aus dem Zeitplan betrachtet, sondern auch die nächste geplante Sollwertänderung.
• Anhand einer konfigurierbaren Aufheizrate pro Raum (in Kelvin pro Stunde) wird berechnet, wie viele Minuten Vorlauf nötig sind.
• Wenn dieser Zeitpunkt erreicht ist, wird auf die Zieltemperatur geschaltet.
• Eine „Session“ für Vorheizen wird zu Ende verfolgt, damit kurzfristige Schwankungen nicht zu hektischem Hin-und-Her führen.
• Am Ende schreibt das System nach der Aufheizphase einen Log-Eintrag, in dem es die tatsächliche Aufheizrate des Raumes vermerkt – so kann ich später schauen, ob meine pro Raum konfigurierten Werte einigermaßen hinkommen.

Ergebnis: Ich muss beim Erstellen oder Ändern meiner Zeitpläne nur darüber nachdenken: „Wann soll es wo wie warm sein?“ – die Steuerung kümmert sich dann darum, dass das auch so kommt.

📆 Modus-Logik: Kalender, Ferien, Anwesenheit

Wie schon oben erwähnt, haben viele Haushalte Sondertage, an denen der Normalplan nicht passt. Deshalb wird ein aktueller Betriebsmodus ermittelt. Davon gibt es mehrere.

Typische Signale dafür sind in meinem System:

• Kalender/iCal: Ereignisse mit Keywords in einem Familienkalender, z.B. „Urlaub“, „krank“, „Homeoffice“
• Schoolfree/Ferien: Ein gesondertes Signal (kommt aus dem ioBroker-Schoolfree-Adapter) kann den Modus „ferien“ aktivieren.
• Der Feiertags-Adapter in ioBroker hat eine ähnliche Wirkung.
• Generelle An- oder Abwesenheit in der Wohnung

Konzept: Prioritäten

• Wenn mehrere Signale gleichzeitig passen, entscheidet ein Prioritätensystem.
• So lassen sich Konflikte einfach auflösen (z.B. soll „Urlaub“ „Ferien“ übersteuern).

In der Praxis läuft das also etwa so:

Ich trage in unserem Familienkalender ein, wann wir verreisen. Das Stichwort „Urlaub“ triggert hierbei eine tiefe Absenkung, weil wir ja wirklich längere Zeit weg sind. Dass gleichzeitig Ferien sind (oder vielleicht auch ein Feiertag), ist dabei egal, weil „Urlaub“ die höhere Priorität hat. Andere Stichworte im Kalender, die ich benutze, sind z.B. „Kinder krank“. Das hat ein tagsüber geheiztes Kinder- und Wohnzimmer statt einer Vormittagsabsenkung zur Folge. Ein weiteres wäre „alle krank“, was ein tagsüber geheiztes Wohn- und Kinderzimmer, aber ein abgesenktes Arbeitszimmer zur Folge hätte. Analog gibt es „Eltern krank“.

Schulfrei oder Feiertage (beides über Adapter in ioBroker bekannte Events) haben entsprechende Auswirkungen. Manchmal hat die Schule auch einfach beweglichen Ferientag oder wegen Schneechaos zu (das weiß ioBroker nicht, weil es sehr schulspezifisch sein kann), dafür schreibe ich dann einfach „Ferien“ oder „Schulfrei“ in den Kalender. Ach ja: „Ferien“ und „Urlaub“ sind in dem System nicht das Gleiche – Ferien bedeutet „Kinder tagsüber zu Hause“, „Urlaub“ hingegen heißt, wir sind weggefahren.

Der globale Anwesenheitsstatus, den ioBroker über HomeKit über unsere Smartphones ermittelt, triggert eine leichte Absenkung der Temperatur, sobald alle Leute die Wohnung verlassen. Die Rückkehr bringt das System wieder in den Zeitplan-Modus zurück. Das mag oft – wenn man z.B. nur kurz ein Kind in den KIGA bringt und danach ins Homeoffice zurückkehrt – sinnfrei sein, aber das System kann ja nicht vorher wissen, ob ich gleich wieder zurück bin oder den ganzen Tag im Schwimmbad bleibe. Vielleicht baue ich hier analog zu den Fenstern auch noch eine Verzögerung ein… mal sehen. Das bringt mich zu den Fenstern.

🪟 Fensterkontakte: Verzögerung und Zonen-Logik

Fenster-offen-Heizlogik ist ein Klassiker, aber in der Praxis hatte ich mit der oben beschriebenen einfachen Logik zwei Stolpersteine:

1. Flattern: Kontakte wechseln kurzfristig hin und her – wir haben z.B. den Biomüll vorm Fenster stehen, oder lagern einige Dinge an die man manchmal ran muss, auf der Terasse. Da wird also regelmäßig mal kurz für 30 s ein Fenster in der Küche geöffnet oder eine Terassentür geht kurz auf und wird dann sogleich wieder geschlossen. Dann jedes Mal sofort der Heizung Bescheid zu geben wäre Quatsch, aber wenn ernsthaft gelüftet wird, dann sollte man die Heizung schon runterdrehen.
2. Zonen: Ein Fenster in der Küche kann auch einen offenen Wohnbereich betreffen, andersrum genauso – das System muss also ein Mapping von mehreren Fensterkontakten zu mehreren Heizungsthermostaten verstehen.

Ich hab das in etwa so umgesetzt:

• Verzögerung: Erst wenn ein Fenster länger als 3 Minuten offen ist, wird reagiert.
• Zonen-Awareness: Mehrere Räume können zu einer Zone zusammengefasst werden; ein offenes Fenster in der Zone reduziert dann alle betroffenen Räume.
• Ein offenes Fenster hat hohe Priorität: Das System setzt die Zieltemperatur auf einen Mindestwert, andere Sonderschaltungen stehen hinter einem offenen Fenster immer zurück.

🌡️ Manuelle Overrides: Nutzerwunsch respektieren, aber mit Fallback

Wenn jemand händisch am Thermostat dreht (ich bin ja hier nicht allein, das muss also familienkompatibel sein), soll das nicht sofort wieder vom System „zurückgedreht“ werden. Gleichzeitig soll ein manueller Eingriff nicht tagelang aktiv bleiben, weil so etwas einfach vergessen wird. Da hat mir diese Funktion, die die Thermostate schon von sich aus hatten, gut gefallen – allerdings musste ich sie noch erweitern. Die Originalfunktion ist bei einem manuellen Eingriff nach einer einstellbaren Zeit auf das reguläre Programm zurückgefallen. Jetzt geht es so:

• Das System unterscheidet eigene Steuervorgänge von manuellen Eingriffen.
• Manuelle Eingriffe laufen nach einer konfigurierbaren Zeit automatisch aus.
• Wenn ein Fenster geöffnet wird, wird der Override pausiert, es wird also abgesenkt. Geht das Fenster wieder zu, wird der Override fortgesetzt (wenn denn noch Zeit übrig war).
• Optional kann in regelmäßigen Abständen geloggt werden, wie lange der Override noch aktiv ist, damit man das System in der Kennenlernphase im Blick behalten kann.

Somit können typische Fälle wie „Mir ist aber trotzdem kalt“ oder „Ich hab heute Abend Gäste und wir gehen jetzt noch gar nicht ins Bett“ einfach manuell abgedeckt werden. Nach einigen Stunden fällt das System ohne weiteren Aufwand wieder in den Regelbetrieb zurück – es kann also nichts vergessen werden.

🏃‍♂️ Bewegungs-Boost (Motion): autmatischer Komfort ohne Dauerheizen

In meinem Arbeitszimmer, wo ich viele Werktage im Homeoffice verbringe, habe ich schon seit Längerem einen Bewegungsmelder, um meine Anwesenheit dort zu detektieren. Das war (und ist) bisher für einen smart geschalteten Luftfilter im Einsatz und kann mir hier nun auch wieder dienen – und zwar, um folgendes Problem zu lösen:

Das Ende eines Arbeitstags ist auch immer irgendwie schwer vorherzusagen. Meist so gegen 18 Uhr. Aber eben nicht immer. Manchmal sitze ich länger, am Dienstag ist gegen 21 Uhr noch Podcast-Aufnahme – aber die wird manchmal auf Mittwoch oder Donnerstag verschoben. Daher hab ich optional vorgesehen, dass ein eventuell im Raum vorhandener Bewegungs- oder Präsenzmelder auch eine Wärmeanforderung für den Raum auslösen kann.

• Bestätigung: Bewegung oder Anwesenheit muss für eine gewisse Zeit anhalten, bevor der Boost aktiv wird. Damit will ich verhindern, dass eine Heizung angemacht wird, wenn man nur mal eben kurz in den Raum geht, um etwas zu holen oder nach dem Drucker zu schauen o.ä.
• Toleranz: Einmal aktiviert sollen kurzzeitige Lücken in der Anwesenheitserkennung den Heiz-Boost nicht sofort deaktivieren. Klassische IR-Bewegungsmelder haben mit Leuten, die ruhig an einem Schreibtisch sitzen und tippen oder lesen, auch gern mal ein Erkennungsproblem. (Beamtenwitz hier einfügen) – man geht auch mal auf die Toilette, zur Tür oder einen Kaffee holen. Das System sollte also entspannt reagieren, nicht hektisch.
• Vorrangregel: Der Boost wird nur aktiviert, wenn er die Zieltemperatur wirklich erhöhen würde. Würde ein aktiver Zeitplan ohnehin einen höheren Wert vorgeben, so hat das natürlich Vorrang.
• Blocker: Bei einem aktiven manuellen Eingriff durch Bewohner oder einem offenen Fenster wird kein Boost aktiviert – diese Regeln haben Priorität.

Damit kann ich im Arbeitszimmer eigentlich alle Homeoffice-Tage gegen 18 Uhr enden lassen, das wirkliche Ende der Heizphase ergibt sich dann automatisch, wenn ich aus dem Raum gehe. Ganz ohne Tagesplan wollte ich den Raum aber auch nicht laufen lassen, weil ich dann ja nicht vom morgendlichen Vorheizen profitieren könnte.

🧾 Laufzeit-States: Beobachtbarkeit und Integration

Um das System am Anfang erst mal zu debuggen und kennenzulernen, hab ich von Anfang an viele States in den State-Tree geschrieben, und das System kann im Debug-Mode viele seiner Entscheidungen strukturiert loggen. So waren die meisten Fehler schnell gefunden, und man kann immer herauskriegen, warum ein Setting gerade so ist, wie es ist.

• Global: aktueller Modus, Anwesenheit, letzter Update-Zeitstempel
• Pro Raum: Zieltemperatur, Ist-Temperatur, Fensterstatus, aktives Profil
• Zusatzzustände: z.B. ob Motion-Boost oder Manual Override aktiv ist
• Beginn einer Aufheizung mit Rechnung, wie es dazu kommt
• Ende einer Aufheizung mit erzielter Aufheizrate vs. konfigurierte Aufheizrate

Damit sind auch Feintunings einfach machbar, um das System weiter zu verbessern.

Zusammenfassung, Regeln und Prioritäten (vereinfacht)

In der praktischen Entscheidungslogik gelten grob diese Regeln:

1. Fenster offen → Zieltemperatur auf Minimum (Override wird pausiert, Motion wird beendet).
2. Manual Override aktiv → Nutzer-Sollwert gilt (solange Fenster nicht offen).
3. Look-Ahead/Vorheizen → ggf. früher auf nächsten Sollwert gehen.
4. Anwesenheit → wenn abwesend und nicht vorheizen, Temperatur reduzieren.
5. Motion-Boost → nur, wenn er höher ist als der aktuelle Sollwert.
6. Ergebnis → Zieltemperatur an Heizung schicken und Runtime-States aktualisieren.

Wichtig war mir einfach: Fenster und manueller Eingriff haben die höchste Prio. Ich will nicht aus dem Fenster heizen, und ich will nicht, dass man sich vom System verarscht fühlt, wenn man eine Einstellung vornimmt und das System die dann ignoriert. Der Rest sortiert sich logisch zusammen.

Grenzen und bewusste Entscheidungen

• Sensorqualität: Ohne vernünftige Ist-Temperaturwerte kann der Look-Ahead nicht sinnvoll arbeiten. Ich lese daher die Ist-Werte aus den gleichen Thermostaten aus. Ich hab zwar noch andere Thermometer in den Räumen ansprechbar, allerdings weichen die Werte immer (je nach Position im Raum, Höhe über dem Boden oder Nähe zu Geräten, Türen oder Fenstern) etwas ab – und das ergibt bei der Steuerung Chaos.
• Heizdynamik: Diese Aufheizraten sind vereinfacht (lineares Modell). Das ist absichtlich pragmatisch. Ich hab dazu im Vorfeld ein paar Beobachtungen gemacht. Ich hab zum Beispiel über eine Reise kürzlich im Dezember die Wohnung auf nahezu 15 Grad auskühlen lassen und dann beim Wiederaufheizen alle Räume aufgezeichnet. In den Graphen kann man die Aufheizrate schön erkennen, allerdings sieht man auch eine Startverzögerung, bis sich überhaupt etwas tut. Die ist aber auch nicht konstant – je nachdem, wie ausgekühlt das gesamte System insgesamt ist. Hier musste einfach Pragmatik her – das funktioniert auch im Alltag genau genug, da muss man nicht übertreiben.

Fazit

Das Ganze ist jetzt seit einigen wenigen Wochen im Einsatz, und ich beobachte fleißig, wie es sich verhält – und vor allem, ob es Wehklagen oder Beschwerden aus der Familie gibt. Bislang ist allerdings erfreuliche Stille von dieser Seite: Das System macht, was es soll – die Wohnung ist immer warm, wenn man es erwartet, und im Nachgang kann ich auf den Grafana-Charts sehen, wie die einzelnen Steuerungen ineinandergegriffen haben.

Dazu hier am Schluss noch ein Beispiel.

Ich muss mal gucken ob ich das Repo öffentlich stelle, aktuell sind da alle unsere Zeitpläne einfach so drin - das müsste ich wohl noch aufräumen. Falls jemand den Code haben will, einfach kurz anschreiben. Falls die eine oder andere Strategie auch bei Euch passen könnte, wünsche ich schonmal: Viel Spaß beim home smart machen.