Ein Smart Home, das sich wie ein Zuhause anfühlt

Nach dem Duschen noch einmal aufstehen, weil der Lüfter weiterrauscht: kein Drama, aber eine dieser kleinen Reibungen, die sich mit der Zeit bemerkbar machen.

Bei uns kam eine zweite hinzu: Lag draußen Rauch in der Luft, führte der schnellste Weg zum Abschalten der Lüftung an den Sicherungskasten.

Der Anlass für dieses Smart Home war also denkbar unspektakulär. Unsere kontrollierte Wohnraumlüftung arbeitet mit drei getrennten Ablufteinheiten - je eine in beiden Bädern und eine in der Küche. Jede läuft im Grundbetrieb und kann für Duschen oder Kochen in einen Boost geschaltet werden. Das Haus wurde 2014 klassisch verdrahtet: drei eigenständige Geräte, keine gemeinsame Steuerleitung, kein Bussystem. Bislang hatte jede Einheit nur ihren lokalen Wippschalter für den jeweiligen Boost.

Damit war das Ziel klar: Die Lüftung sollte Feuchtigkeit selbst erkennen, weiterhin lokal bedienbar sein und sich im Ausnahmefall schnell abschalten lassen. Keine Technik um der Technik willen, sondern ein bisschen weniger Reibung im Alltag.

Der wichtigste Grundsatz: Das Haus bleibt handlungsfähig

Die Architektur folgt deshalb einem einfachen Gedanken: Was unmittelbar im Haus wirken muss, entscheidet möglichst nah an der Hardware. Ein Aktor, der eine Lüftung schaltet, soll seine Grundfunktion auch dann beherrschen, wenn Dashboard, Broker oder WLAN gerade nicht erreichbar sind. Der Home Controller macht Zustände sichtbar und übermittelt Wünsche; er ist bewusst keine unersetzliche Schaltzentrale.

Das ist Local First nicht als Etikett, sondern als Fehlerstrategie. Fällt der Broker aus, arbeiten Taster und Feuchteautomatik weiter; startet das Dashboard neu, füllen retained MQTT-Nachrichten seinen Arbeitsspeicher wieder. Fällt ein Smartmeter-Port kurz aus, verbindet sich das Gateway neu, ohne andere Funktionen zu beeinträchtigen. Jeder Ausfall bleibt damit auf die Komfortschicht begrenzt, die er tatsächlich betrifft.

Shelly war für diesen ersten Schritt passend, weil die Geräte WLAN, MQTT, lokale JavaScript-Automatisierung und BLE-Sensoren zusammenbringen. Entscheidend war nicht die Marke, sondern die Eigenschaft: Die Lösung braucht weder ein Herstellerkonto noch eine proprietäre Zentrale, um ihre Kernaufgabe zu erfüllen. Die dokumentierten Geräte-Schnittstellen, MQTT-Einstellungen und Script-Funktionen machen diese lokale Integration überhaupt erst belastbar.

Drei Lüfter, drei kleine Controller

Hinter jedem der vertrauten Taster arbeitet heute ein Shelly 2PM Gen4 mit zwei Ausgängen: einer schaltet den Grundbetrieb, der andere den Boost. Von außen bleibt die Geste vertraut. Im Inneren wird aus einem einfachen Schalter jedoch eine Bedienung, die den Kontext kennt.

Ein kurzer Tastendruck startet den Boost für zehn Minuten. Ein weiterer Druck verlängert ihn schrittweise, aber nie unbegrenzt: Nach spätestens einer Stunde kehrt die Einheit in ihren definierten Zustand zurück. Ein langer Druck beendet den Boost. Wird der Taster vier Sekunden gehalten, ändert sich der Grundlüftungswunsch an dieser Einheit und wird, wenn der Broker erreichbar ist, an die beiden anderen weitergegeben. So wird aus dem früheren Gang zum Sicherungskasten eine bewusst gewählte Hausfunktion - ohne den lokalen Schalter zur Fernbedienung eines Servers zu degradieren.

Im Bad kommt ein Shelly BLU H&T als BTHome-Sensor hinzu. Er misst Temperatur und Luftfeuchtigkeit; steigt die Feuchte deutlich oder schnell, fordert das Script den Boost an. Eine Hysterese sorgt dafür, dass kleine Schwankungen nicht zu nervösem Schalten führen. Manueller Timer und Feuchteautomatik sind dabei zwei unabhängige Gründe für denselben Ausgang: Endet der Timer, während das Bad noch zu feucht ist, läuft der Boost weiter. Erst wenn kein Grund mehr besteht, endet er.

Gerade darin zeigt sich die eigentliche Qualität der Verteilung. Über MQTT kann eine Entscheidung bequem im Haus geteilt werden, etwa die Lüftung bei Rauch in der Außenluft auszuschalten. Fällt der Broker aus, fehlen diese hausweiten Abkürzungen. An jeder einzelnen Einheit funktionieren Taster, Timer und Feuchteregelung trotzdem weiter.

Fünf kleine Bausteine statt einer großen Blackbox

Die Architektur besteht aus vier bewusst schlank gehaltenen Komponenten. Jede hat eine Aufgabe, die sich erklären und im Fehlerfall gezielt prüfen lässt.

Ein Inventory, das die Wirklichkeit beschreibt

Eine der wichtigsten Entscheidungen steckt in Ansible. Das Inventory ist nicht nur ein Adressbuch, sondern modelliert ausdrücklich die Verbindung zwischen physischer und fachlicher Welt:

Das verhindert einen typischen Smart-Home-Fehler: Bedeutungen aus Hostnamen, IP-Adressen oder Kanälen zu erraten. Ein Shelly kann mehrere Ausgänge haben, ein Heizkreis mehrere Zonen versorgen und ein Sensor an einem anderen Ort messen als sein Gateway steht. Im Inventory sind diese Beziehungen ausdrücklich, prüfbar und versioniert.

Aus dieser Quelle rendert Ansible pro Gerät ein passendes, kompaktes JavaScript-Script. Ausgänge, Sensor-IDs, Schwellwerte, Timer und fachliche MQTT-Topics stammen aus dem Inventory; anschließend überträgt Ansible das Ergebnis über die Geräte-API und startet es definiert neu. Änderungen bleiben damit nachvollziehbar, reviewbar und gezielt ausrollbar - und nach Monaten ist noch verständlich, warum etwas wo angeschlossen ist.

Die Standardkonfiguration des jeweiligen Aktors wird als Konstante direkt in das generierte Script eingebettet. Der Shelly hat nach dem Ausrollen alles bei sich, was er für seine Grundfunktion benötigt: kein Abruf beim Home Controller, kein Warten auf den MQTT-Bus, keine Konfiguration, die nur in einem Browser-Tab existiert. Das macht die lokale Logik zugleich selbstständig und deterministisch.

MQTT als kleine, klare Sprache

MQTT ist hier nicht nur ein Transportweg, sondern eine klar definierte Sprache. Die drei Namespaces beantworten drei unterschiedliche Fragen:

Diese Trennung ist klein, aber wirkungsvoll. Ein Dashboard kann keinen beobachteten Zustand fälschen, weil es nie nach state/ schreibt. Ein Lüftungs-Boost wird nach einem Reconnect nicht versehentlich wiederholt, weil er unter cmd/ nicht retained ist. Ein saisonaler Heizungswunsch überlebt hingegen Neustarts, weil er unter config/ retained bleibt.

Auch die Topic-Namen bleiben fachlich. state/home/heating-circuit/<circuit> spricht über einen Heizkreis und nicht über switch:0 eines bestimmten Geräts. Technische Diagnose wie RSSI oder Verfügbarkeit liegt getrennt unter state/device/. Dadurch darf sich Hardware ändern, ohne dass die fachliche API zerbricht.

Ein Broker, der nicht im Weg steht

Auf dem Home-Server verteilt Eclipse Mosquitto die MQTT-Nachrichten. Für diese Aufgabe ist der Broker genau richtig: klein, sparsam im Ressourcenbedarf, mit einer überschaubaren textbasierten Konfiguration und im Betrieb erfreulich unspektakulär. Er nimmt Nachrichten entgegen, liefert sie an interessierte Komponenten aus und hält die ausdrücklich als retained markierten Zustände für neu verbundene Teilnehmer bereit. Mehr Anwendungslogik soll er nicht tragen.

Wer mich und meine anderen Artikel kennt, wird sich vielleicht fragen: „Matthias, Du nimmst keinen Pulsar dafür?“ Nein - jedenfalls nicht zwischen drei Lüftern, ein paar Sensoren und dem Home Controller. Apache Pulsar ist ein ausgezeichnetes Event-Backbone, wenn Retention, Replays, Multi-Tenancy oder skalierbare Backend-Verarbeitung gebraucht werden. Warum MQTT und Pulsar sich dort sinnvoll ergänzen, beschreibe ich in MQTT trifft Pulsar: Eine pragmatische Bridge für moderne IoT-Architekturen. Im Haus wäre Pulsar für den aktuellen Zweck aber zusätzlicher operativer Footprint ohne zusätzlichen Alltagsnutzen. Einen passenden Baustein zu wählen, ist oft die anspruchsvollere Entscheidung als den leistungsfähigsten.

Was das Haus heute selbst erledigt

Die Lüftung war der Anfang. Danach kam die Heizung dazu: Fußbodenheizung, träge Stellantriebe, eine noch trägere Wärmepumpe und nach dem Sommer gelegentlich ein Ventil, das lieber festsaß als wieder loszulaufen. Die Automatisierung kann diese Physik nicht wegzaubern. Sie kann aber zeigen, was gerade passiert, und die Aktoren zuverlässig bewegen.

• Lüftungsaktoren unterscheiden Grundlüftung und Boost, verbinden manuelle Bedienung mit Feuchteregelung und bleiben pro Einheit funktionsfähig.
• Bluetooth-LE-Sensoren messen die Raumtemperaturen und stellen sie als MQTT-Zustände für Anzeige, Automatisierung und Monitoring bereit.
• Heizungsaktoren kennen Sollzustand, Istzustand und lokalen Override. Im Sommer bewegt ein zeitlich gestreuter Ventilschutz die Ventile regelmäßig.
• Shelly-EMs und ein kleines Go-basiertes SML-Gateway veröffentlichen Leistung und Zählerstände. Das Gateway verarbeitet gültige OBIS-Werte und verbindet sich nach Portfehlern selbstständig neu.

Das Smartmeter Gateway läuft auf einem Raspberry Pi im Verteilerkasten. Zwei USB-IEC-Infrarot-Leseköpfe lesen dort die Zähler über USB aus. Auf dem Pi läuft ein schlankes Buildroot-System zusammen mit dem Go-Binary: Es liest SML an den seriellen Schnittstellen, validiert und dekodiert die OBIS-Werte und brückt sie als MQTT-Zustände ins Hausnetz. So bleibt die Protokollübersetzung direkt an der physischen Schnittstelle, während im übrigen System normale MQTT- und Prometheus-Daten ankommen.

Der Home Controller sieht all das, wird aber nicht zur zweiten Wahrheit. Er hält nur Werte mit Zeitstempel im Arbeitsspeicher. Nach einem Reconnect liefern retained Nachrichten wieder eine aktuelle Sicht. Die Oberfläche nutzt eingebettetes HTML, CSS und HTMX; auch der MQTT-Monitor aktualisiert sich lokal über kleine HTTP-Fragmente. Das resultierende Go-Binary braucht zur Bedienung keinen Internetzugang.

Beobachtbarkeit, die ihren Namen verdient

Prometheus ist kein nachträglicher Zusatz, sondern Teil der Architektur. Der Home Controller exportiert nur ausdrücklich konfigurierte state/-Werte. Das verhindert, dass zufällige Topics oder technische Interna zu einer unkontrollierten Metrikflut werden. Name, Einheit, Typ, Labels und Skalierung sind deklarativ festgelegt.

So entstehen Daten für sinnvolle Fragen statt für eine Datensammlung um ihrer selbst willen: Wie entwickelt sich der Energiebedarf? Wann und wie lange läuft eine Lüftung? Welche Änderung hat wirklich geholfen? Das Smartmeter Gateway stellt Leistung als Gauge und Gesamtenergie als Counter bereit. Beide Go-Dienste bleiben bewusst klein und lassen sich auf x86_64 wie ARMv7 ausliefern.

Nicht gegen Plattformen, sondern für passende Grenzen

Cloud-Plattformen sind bequem beim Einstieg. Sie bringen jedoch oft Kontobindung, Internetabhängigkeit, Herstellerwechselrisiko und eine schwer nachvollziehbare Kette aus Integrationen mit. Auch eine vollständig lokale, zentralisierte Instanz verlagert jede Regelentscheidung in einen einzelnen Dienst. Dieses Projekt wählt bewusst einen anderen Kompromiss:

Das ist keine Absage an Home Assistant, OpenHAB oder Cloud-Produkte. Sie sind starke Werkzeuge, besonders wenn viele heterogene Integrationen, Sprachassistenten oder fertige Dashboards im Vordergrund stehen. Für dieses Haus ist der Fokus ein anderer: Die Grundfunktionen sollen von einer Komfortschicht unabhängig bleiben. Duschen, Rauch, klemmende Ventile und ein Netzwerkausfall warten nicht darauf, dass eine zentrale Instanz gerade verfügbar ist.

Die eigentliche Stärke: Änderungen bleiben beherrschbar

Eine Architektur beweist sich nicht am ersten Tag, sondern bei der nächsten Änderung. In diesem Projekt hat jede typische Änderung einen eindeutigen Ort:

• Ein neuer Sensor, Raum oder Ausgang wird im Inventory gebunden und nur auf die betroffenen Shellys ausgerollt.
• Eine neue Dashboard-Kachel oder Bedienmöglichkeit wird in der Controller-Konfiguration beschrieben, nicht in die Aktorlogik eingebaut.
• Ein neuer Zähler bekommt im Gateway eine fachliche Identität und einen seriellen Port.
• Ein dauerhafter Wunsch wird als retained config/ formuliert, eine Aktion als nicht-retained cmd/.

Das macht Betrieb und Fehlersuche angenehm konkret. Fehlt ein Wert in der UI, lautet die Frage nicht „Was macht die Plattform?“, sondern: Publiziert der Erzeuger einen retained State? Ist der Broker erreichbar? Ist der Wert veraltet? Hat der Controller die Messung ausdrücklich konfiguriert? Jede Schicht liefert eine klare Antwort.

Was als Nächstes kommen darf - und was nicht

Die Architektur ist absichtlich offen genug für weitere Funktionen: Beleuchtung oder einzelne Szenen können dazukommen, wenn sie eine wiederkehrende Handlung spürbar vereinfachen. Eine Szene ist dann kein bunter Knopf, sondern eine klar benannte, nachvollziehbare Absicht - mehrere Zustände für eine konkrete Situation zu setzen, ohne jedes Gerät einzeln bedienen zu müssen.

Der Maßstab bleibt derselbe wie bei der Lüftung: Welches Problem verschwindet dadurch, und funktioniert die Lösung im Alltag besser als der bisherige Schalter? Ein zusätzlicher Aktor braucht selbst Energie, erhöht die Zahl der Komponenten und will betrieben werden. Eine Deckenleuchte im Lagerraum nur fernzuschalten, wäre dafür meist ein schlechter Tausch. Dort, wo Bedienung, Sicherheit, Energieeinsicht oder Barrierefreiheit wirklich gewinnen, ist die Erweiterung dagegen sinnvoll. Das Haus soll nützlicher werden, nicht bloß mehr Technik enthalten.

Ein Haus, das sich nicht fremd anfühlt

Technik im Haus sollte Selbstbestimmung stärken, nicht neue Abhängigkeiten schaffen. Dieses Projekt begann nicht mit dem Wunsch nach einer App, sondern mit einem nachlaufenden Lüfter, Rauch in der Außenluft und einer Heizung, deren Zustand niemand wirklich kannte.

Daraus ist kein Produkt von der Stange geworden, sondern eine nachvollziehbare Grundlage, die dem Haus gehört und mit ihm wachsen darf. Sie reagiert lokal, bleibt verständlich und arbeitet auch dann weiter, wenn außerhalb der eigenen vier Wände gerade nichts verfügbar ist. Genau so soll sich ein Smart Home anfühlen: hilfreich, aber nie fremd.