Nicht die Zentrale: Ein Edge-System für das Smart Home

Im ersten Beitrag, Ein Smart Home, das sich wie ein Zuhause anfühlt, ging es um eine einfache, aber folgenreiche Idee: Ein Haus soll nicht unbedienbar werden, nur weil ein Dashboard, ein Broker oder ein Server gerade neu startet. Die Lüftung entscheidet deshalb unmittelbar am Aktor, die Heizung kennt ihren lokalen Override und MQTT verbindet diese Bausteine, ohne eine Cloud zur Voraussetzung zu machen.

Inzwischen hat diese Idee eine deutlichere Softwareform bekommen. Ein Raspberry Pi 4 läuft als Edge-System auf einer schlanken Buildroot-Basis. Auf ihm arbeiten der MQTT-Broker Mosquitto und drei eigene Go-Dienste: console, governor und meterbridge. Das klingt zunächst wie eine kleine Zentrale. Genau das soll der Pi aber nicht sein. Er ist ein Koordinator an der Kante: nah genug an den Geräten und den zwei Zählern, klein genug für einen klaren Betrieb, aber nicht so mächtig, dass sein Ausfall die physische Grundfunktion des Hauses mitnimmt.

Dieser Unterschied bestimmt die Architektur stärker als die Wahl einzelner Bibliotheken oder Frameworks.

Ein Edge-Knoten, keine allwissende Zentrale

Der Raspberry Pi steht zwischen Feld und Hausnetz. Er nimmt die besondere Welt der SML-Zähler entgegen, verteilt MQTT-Nachrichten, bietet eine lokale Oberfläche an und liefert Daten für Prometheus. Die unmittelbar wirkenden Entscheidungen bleiben trotzdem bei den Feldgeräten: Taster, Timer, Feuchte-Boost, Heizungs-Hysterese, lokaler Override und Ventilschutz brauchen weder den Pi noch das WLAN. Die heute eingesetzten Shellys sind dabei konkrete Feldgeräte, nicht die Voraussetzung für dieses Architekturprinzip.

Die Rollen sind bewusst asymmetrisch:

Das ist eine absichtlich andere Lesart von Edge Computing: Der Edge-Knoten verschiebt nicht zwangsläufig alle Entscheidungen aus der Cloud an einen neuen zentralen Rechner. Er begrenzt Abhängigkeiten. Für jede Funktion wird gefragt: Muss sie jetzt physisch wirken, oder darf sie koordiniert werden?

Drei Dienste, drei unterschiedliche Risiken

console, governor und meterbridge hätten technisch in einem Prozess leben können. Alle drei sprechen MQTT, alle drei entstehen aus demselben Go-Modul, und auf einem Pi 4 wäre ein Monolith keineswegs zu groß. Die Trennung folgt daher nicht der Mode, aus jedem Paket einen Service zu machen. Sie folgt dem Blast Radius: Welcher Fehler darf welche Fähigkeit verlieren?

Die Namen beschreiben damit nicht technische Schichten, sondern unterschiedliche Folgen eines Fehlers. Ein Speicherleck im Dashboard soll keine Metering-Pipeline unterbrechen. Ein hängender USB-Port soll weder Szenen noch die Bedienung blockieren. Eine fehlerhafte Wetterantwort soll nicht verhindern, dass ein Temperaturwert als virtuelle Messgröße berechnet wird.

Die wichtigste Grenze verläuft allerdings außerhalb des Pi: zwischen koordinierender Software und dem Feldgerät. Fiele der gesamte Edge-Knoten aus, wären Dashboard, zentrale Szenen, Wetterdaten und neue Zählermesswerte weg. Der Taster im Bad startet aber weiterhin seinen zeitlich begrenzten Boost. Die Heizung reagiert weiterhin auf ihren lokalen Eingang. Das ist die relevante Degradierung im Alltag: weniger bequem, aber weder rätselhaft noch gefährlich.

MQTT ist das Rückgrat, nicht das Gehirn

Zwischen den Diensten existiert keine Go-Importbeziehung. console kennt weder Pakete aus governor noch aus meterbridge; auch die Feldlogik kennt keinen HTTP-Endpunkt des Pi. MQTT ist der einzige Anwendungsbus. Das erlaubt, jeden Teil einzeln neu zu starten, zu testen oder später zu ersetzen, solange sein fachlicher Vertrag stabil bleibt.

Der Vertrag besteht nicht nur aus Topic-Namen. Die vier Präfixe beantworten unterschiedliche Fragen:

Jedes state/-Topic hat genau einen Erzeuger. Der Shelly schreibt seinen gemessenen Relaiszustand, meterbridge seine dekodierte Energie, und eine Rule im governor darf nur ihren explizit konfigurierten virtuellen Wert schreiben. Das verhindert die klassische verteilte Unklarheit, bei der zwei Komponenten abwechselnd dieselbe Wahrheit behaupten.

Retained Messages wirken dabei wie ein sehr kleiner Wiederanlaufmechanismus. Wenn console neu startet, füllt sich ihr In-Memory-Snapshot aus den retained Zuständen. Wenn ein Shelly die Verbindung wieder aufbaut, erhält er den letzten dauerhaften Sollwert. Aus diesem Komfort darf jedoch keine falsche Gewissheit werden: Ein retained Wert ist kein Beweis für Aktualität. Deshalb prüfen Rules die maximale Frische ihrer Eingaben, Heizungsaktoren verwerfen alte Temperaturen, und die Wetterintegration markiert überalterte Vorhersagen.

Bedienung ist eine Absicht, kein Schaltbefehl

Die console ist die sichtbarste Komponente: ein serverseitig gerendertes HTML-/HTMX-Dashboard auf Port 8080, dazu ein MQTT-Monitor und der Prometheus-Endpunkt auf Port 8081. Intern teilt sie eine MQTT-Verbindung für Dashboard und Metrics. Das reduziert Ressourcen und vermeidet zwei leicht auseinanderlaufende Sichten auf denselben Bus.

Wichtig ist, was die UI nicht behauptet. Ein Klick bestätigt nicht, dass ein Relais geschaltet hat. Er bestätigt nur, dass Mosquitto eine erlaubte Publikation angenommen hat. Die fachliche Rückmeldung kommt anschließend als state/ vom verantwortlichen Feldgerät.

Dieses Muster wirkt klein, verhindert aber einen folgenreichen Architekturfehler: eine Weboberfläche als zweite Aktorlogik. console publiziert ausschließlich vorab konfigurierte Controls. Sie kann keinen beliebigen Topic-Pfad und keine freie Payload aus einem Formular heraus senden. Das macht ihre MQTT-ACL kleiner, das UI nachvollziehbarer und spätere Änderungen besser reviewbar.

Prometheus bleibt ebenfalls auf Abstand. console übersetzt nur explizit konfigurierte MQTT-Werte in Metriken; Prometheus scrapt sie vom Homeserver aus per HTTP. Der Zeitreihenspeicher hat weder MQTT-Zugang noch eine Möglichkeit, Aktoren zu steuern. Beobachtung kann damit ausfallen oder neu konfiguriert werden, ohne in einen Steuerpfad zu geraten.

Der Governor: zentrale Intelligenz ohne Fernsteuerung

Es gibt dennoch Aufgaben, die nicht sinnvoll in einem einzelnen Aktor wohnen. Der governor verarbeitet deklarative Rules, Szenen, Schedules, langlebige Jobs, begrenzte Webhooks und die optionale DWD-Wettervorhersage. Er berechnet zum Beispiel virtuelle Temperaturen für Räume ohne passenden direkten Sensor und Feuchteschwellen, die Innen- und Außenklima berücksichtigen.

Entscheidend ist die Richtung dieser Zusammenarbeit. Eine Rule im Governor liefert einen Wert oder eine Konfiguration, das Feldgerät bewertet ihn im lokalen Zusammenhang. Rules publizieren keine direkten cmd/-Topics für Relaisentscheidungen. Bei fehlenden, ungültigen oder zu alten Eingaben publiziert eine Rule lieber keinen neuen Wert, als eine alte Messung als aktuelle Erkenntnis fortzuschreiben.

Das ist ein nützlicher Mittelweg zwischen zwei Extremen. Eine vollständig zentrale Automation würde bei jedem Sensorwert einen Server zum Schalten brauchen. Ausschließlich lokale Logik könnte dagegen weder mehrere Datenquellen noch Wetter oder virtuelle Messpunkte sinnvoll zusammenbringen. Der Governor ist daher kein Ersatz für den Regler, sondern eine Aufschaltung: Er erweitert die Entscheidungsgrundlage, während das Feldgerät weiter für die unmittelbare Wirkung verantwortlich bleibt.

Szenen haben einen Besitzer

Bei Szenen ist die Grenze absichtlich anders geschnitten. console kennt die sichtbare ID, Bezeichnung, Beschreibung, Farbe und das Icon einer Szene. Sie kennt jedoch nicht deren Aktionsliste. Wählt jemand etwa „Heizung Winter“, publiziert Console ausschließlich den nicht-retained Trigger cmd/home/automation/scene/heizung-winter = run.

Der Governor besitzt die Szenendefinition. Er prüft die angeforderte ID, führt deren deklarierte Aktionen nacheinander aus und publiziert anschließend den letzten Lauf und sein Ergebnis als state/. Eine Szene darf dabei dauerhafte config/-Werte setzen, etwa Heizmodus und Solltemperatur, oder bewusst eine einmalige cmd/-Aktion auslösen, etwa Stoßlüften. Damit ist nicht die Oberfläche, sondern die zentrale Automation Eigentümerin der Wirkungskette.

Das Zusammenspiel bewahrt beide Seiten der Grenze: Die UI bleibt schlank und kann keine beliebige Aktionskette erfinden. Der Governor kann Szenen über Dashboard, Zeitplan, Job, MQTT-Trigger oder authentisierten Webhook auf denselben Ausführungspfad legen. Und ein Feldgerät bleibt weiterhin die Instanz, die einen erhaltenen Sollwert oder Befehl im lokalen Kontext umsetzt.

Wetter ist ein Vorsprung, keine Fernbedienung

Die DWD-Integration lädt MOSMIX-L beim Start und danach alle drei Stunden. Sie publiziert für den Standort Vorhersagen für die nächsten 3, 6, 12 und 24 Stunden unter forecast/: Temperatur, Niederschlagswahrscheinlichkeit, Wind sowie Zeitpunkt und Verfügbarkeit der Daten. Ist der Abruf gestört, kennzeichnet Governor die Vorhersage als stale oder error; Feldlogik, Szenen und andere Rules laufen unverändert weiter.

Der interessante nächste Schritt liegt bei der trägen Fußbodenheizung. Ihr Wärmeeintrag wirkt nicht sofort. Eine klar abgegrenzte, künftig ergänzte Governor-Rule könnte daher Außentemperatur und Vorhersage mit lokalen Messwerten verbinden und den Heizmodus oder Sollwert rechtzeitig als config/ vorbereiten. Bei einer erwarteten Abkühlung kann Wärme früher bereitstehen; bei einem sonnigen, milderen Tag kann unnötiges Nachheizen ausbleiben. Wohnkomfort und Energiesparen müssen dann kein Widerspruch sein.

Auch dann gilt: Wetterdaten erhöhen die Qualität einer Entscheidung, sie ersetzen keine lokale Regel. Fällt DWD oder die Verbindung dorthin aus, arbeitet die Heizung mit ihren letzten gültigen Konfigurationswerten und ihrer lokalen Hysterese weiter.

Meterbridge: Die Protokollgrenze gehört an den Rand

Die meterbridge ist der unscheinbarste Dienst und architektonisch vielleicht der klarste. Zwei optische Leseköpfe liefern serielle SML-Telegramme. Diese Welt aus Portnamen, Baudrate, Framing und OBIS-Kennzahlen soll nicht in Dashboard-Code, Regel-Engine oder Prometheus-Konfiguration einsickern.

Darum kapselt Meterbridge die gesamte Übersetzung:

Pro Zählpunkt arbeitet ein eigener Worker. Ein fehlender, blockierter oder fehlerhafter Port betrifft nur den jeweiligen Zählpunkt; der Worker versucht den Port mit Backoff erneut zu öffnen. Ungültige Frames überschreiben keinen letzten gültigen Wert. Für den Rest des Systems entsteht daraus eine einfache fachliche Schnittstelle: Leistung, Energie und Verfügbarkeit als MQTT-Zustände.

Das ist ein wiederkehrendes Muster für Edge-Software. Spezielle physische Protokolle werden dort übersetzt, wo sie auftreten. Hinter der Grenze sprechen die anderen Komponenten nur noch die gemeinsame Sprache des Systems.

Buildroot macht aus dem Pi eine Appliance

Der Raspberry Pi 4 ist kein vollwertiger Linux-Server, auf dem zufällig ein Smart Home läuft. Das Betriebssystem entsteht mit Buildroot für genau diese Aufgabe: Kernel, Root-Dateisystem, Toolchain und benötigte Pakete werden als kleines Embedded-Image definiert. Die drei Anwendungen werden als statisch gelinkte ARMv7-Go-Binaries gebaut. Eine Go-Installation oder ein umfangreicher Runtime-Baum auf dem Ziel sind nicht erforderlich.

Buildroot bringt hier bewusst auch eine andere Betriebsform mit als ein allgemeines Server-Linux: BusyBox-Init startet Mosquitto und danach die drei Dienste. Die Konfigurationen liegen getrennt unter /etc/smarthome/, die Binaries unter /usr/local/bin. Ansible übernimmt vom Notebook aus den kontrollierten Rollout: Es baut die ARMv7-Binaries, installiert Edge-Software und Mosquitto-Konfiguration auf dem Pi und rendert zugleich die passenden Shelly-Skripte aus dem Inventory.

Vor einem Neustart validiert der jeweilige Dienst seine Konfiguration. Das ist keine große Continuous-Delivery-Plattform, aber eine wirksame Betriebsregel: Eine fehlerhafte Dashboard-Definition, Rule oder Zählerzuordnung darf nicht erst durch einen abgestürzten Dienst auffallen.

Features wachsen an klaren Grenzen

Die Architektur ist nicht interessant, weil sie möglichst wenig kann. Sie schafft Platz für Funktionen, ohne dass jede neue Idee den Kern umbaut:

• Neue Dashboard-Kacheln und erlaubte Bedienaktionen gehören in die deklarative Console-Konfiguration, nicht in Shelly-Skripte.
• Neue virtuelle Werte, Szenen oder Zeitpläne gehören als prüfbare Governor-Konfiguration in die zentrale Automation.
• Neue Zähler erhalten in Meterbridge einen Port und eine fachliche Identität, ohne dass andere Dienste SML verstehen müssen.
• Neue Feldgeräte werden im Ansible-Inventory an Raum, Kanal, Sensor und Fachobjekt gebunden und anschließend gezielt ausgerollt.

Das ist der eigentliche Gewinn gegenüber einer großen, bequemen Blackbox: Nicht jede neue Funktion ist automatisch ein globales Risiko. Sie bekommt einen Ort, einen Vertrag, einen Besitzer und ein klares Fehlerbild.

Warum nicht einfach eine fertige Smart-Home-Zentrale?

Auf den ersten Beitrag gab es erfreulich viel positives Feedback. Es kamen aber auch berechtigte Fragen: Warum diese Komponenten selbst bauen, wenn mit Home Assistant, OpenHAB, ioBroker oder Node-RED längst starke Plattformen existieren?

Die kurze Antwort lautet nicht: weil vorhandene Software schlecht wäre. Im Gegenteil. Diese Projekte lösen jeweils reale Probleme und sind für viele Häuser die bessere Wahl. Wer schnell viele heterogene Geräte verbinden, ein fertiges Dashboard nutzen oder eine große Auswahl von Integrationen haben möchte, findet dort sehr leistungsfähige Werkzeuge.

Mein Ziel ist nur ein anderes. Ich möchte für dieses Haus die kleinstmögliche verständliche Lösung bauen: wenig Code, wenige Laufzeitabhängigkeiten, nachvollziehbare Lieferketten und möglichst wenige Protokolle. Wo immer es geht, ist MQTT die gemeinsame Sprache. Die Komponenten sind keine allgemeine Automatisierungsplattform, sondern genau die Funktionen, die dieses Haus heute braucht: lokale Feldlogik, Messaging, Bedienung, einige abgeleitete Regeln und eine klar begrenzte Protokollübersetzung für die Zähler.

Das wichtigste Kriterium ist die Rolle der Zentrale. In vielen Plattformen läuft die Automation in einem zentralen Dienst; die Feldgeräte sind vor allem Ein- und Ausgabepunkte. Hier ist es umgekehrt: Die Feldgeräte besitzen die Grundfunktion. Der Edge-Knoten ergänzt sie mit Komfort, Koordination und Beobachtung. Das macht die Lösung nicht universeller, aber für den gewählten Anwendungsfall robuster und leichter zu überschauen.

Die Tabelle ist keine Rangliste. Für ein Haus mit vielen proprietären Geräten oder dem Wunsch nach schneller Integration würde ich eine der etablierten Plattformen ernsthaft prüfen. Auch in diesem Projekt können sie später eine Rolle spielen, etwa als externe Visualisierung oder als zeitlich begrenzte Integrationshilfe. Entscheidend wäre dann, dass sie nicht unbemerkt die Grundfunktion der Aktoren übernehmen.

Der Verzicht auf eine große Zentrale ist deshalb kein Verzicht auf Features. Er ist eine Priorisierung: Erst wird die lokale Wirkung sauber definiert. Danach kommen Funktionen hinzu, deren Ausfall akzeptabel ist. Das Dashboard darf komfortabel sein. Eine Szene darf mehrere Wünsche bündeln. Eine Wetterregel darf eine Schwelle verbessern. Keine dieser Ergänzungen sollte aber darüber entscheiden, ob ein Taster im Bad noch funktioniert.

Lokale Integration darf kein Gnadenrecht sein

Shelly ist für mich ein positives Gegenbeispiel zu vielen cloudzentrierten Produkten. Die eingesetzten Geräte bieten WLAN, MQTT und lokale Skripte als normale Produktfunktion an. MQTT ist dort nicht eine widerwillige Nebenfunktion für Bastler, sondern ein direkter, dokumentierter Weg zu Zuständen, Befehlen und lokaler Automatisierung. Dadurch lassen sich die Geräte in eine eigene Architektur einbinden, ohne dass sie ihre lokale Funktion an eine fremde Plattform abgeben müssen. Genau diesen Anspruch sollten smarte Geräte zum Normalfall machen.

Der direkte Weg zum eigenen Gerät

Eine Waschmaschine, eine Heizung oder eine Lüftung stehen im eigenen Haus. Für die Bedienung am eigenen Standort sollte deshalb ein direkter Weg genügen: Gerät und lokale Oberfläche sprechen im LAN oder WLAN miteinander, ohne Konto, ohne externen Dienst und ohne Abhängigkeit von dessen Erreichbarkeit. Eine Cloud kann darüber hinaus Fernzugriff, optionale Analysen oder komfortable Dienste anbieten. Sie darf die lokale Grundfunktion nicht erst erlauben.

Das ist für mich persönlich ein Kaufkriterium. Ein „smartes“ Gerät, das sich nur über eine fremde App und einen externen Dienst steuern lässt, ist für mich nicht wirklich smart, sondern fernbedient. Ich kenne leider auch die andere Erfahrung: eine smarte Waschmaschine mit zäher Bedienung, auffälliger Werbung in der App und Updates zu ungünstigen Zeitpunkten. In der Familie haben zudem cloudzentrierte Heizungsanlagen renommierter Hersteller bereits für ähnliche Kopfschüttel-Momente gesorgt. Die konkreten Marken sind dabei nicht der Punkt. Das Muster ist es: Die Funktion im Haus wird schlechter, sobald zwischen Nutzer und eigenem Gerät zu viel Plattform liegt.

Warum MQTT ein guter gemeinsamer Nenner ist

Eine gute lokale Schnittstelle bringt allen Beteiligten Vorteile:

• Nutzer behalten eine direkte, schnelle und zuverlässige Bedienung ihres eigenen Geräts.
• Installateure und Integratoren können Anlagen nachvollziehbar verbinden, ohne auf fragile Cloud-Kopplungen angewiesen zu sein.
• Hersteller gewinnen Vertrauen, wenn ein Produkt auch nach Änderungen am Online-Angebot weiter sinnvoll nutzbar bleibt.
• MQTT über WLAN ist für viele Geräte ein klarer, dokumentierbarer und mit Standardwerkzeugen prüfbarer Integrationsweg.
• Lokale Steuerung reduziert unnötige externe Abhängigkeiten und vermeidet, dass einfache Hausfunktionen an Konto, App oder Backend hängen.

MQTT ist dafür kein Allheilmittel und auch kein Ersatz für eine sichere Geräteentwicklung. Aber für viele vernetzte Hausgeräte ist es ein sehr guter gemeinsamer Nenner: leichtgewichtig, ereignisbasiert, im lokalen Netz gut diagnostizierbar und ohne proprietäre Cloud-Brücke nutzbar. Ein klar dokumentiertes Topic-Modell samt Authentifizierung, Zugriffskontrolle und Versionsstrategie wäre für Integratoren wesentlich wertvoller als die nächste exklusive App-Integration.

Vertrauen entsteht durch Wahlfreiheit

Hersteller haben nachvollziehbare wirtschaftliche Interessen an Konten, Ökosystembindung und Telemetrie. Für Nutzer entsteht daraus aber eine berechtigte Frage nach Kontrolle und Datenminimierung. Betriebsdaten können nützlich sein, etwa für Diagnose, Wartung oder freiwillige Produktverbesserung. Sie sollten deshalb transparent, zweckgebunden und freiwillig erhoben werden. Niemand sollte sich fragen müssen, ob die Häufigkeit der eigenen Wäsche, Heizzyklen oder anderen Alltagsnutzung später in einen unerwarteten Kontext gestellt wird.

Ein Hersteller gewinnt nicht trotz lokaler Schnittstelle Vertrauen, sondern gerade durch sie. Wer lokale Bedienung, offene Dokumentation und freiwillige Cloud-Dienste anbietet, lässt Kunden die Wahl. Das ist langfristig überzeugender als sie durch einen unvermeidbaren Account an eine Plattform zu binden.

Probebetrieb und Ausblick

Mein Smart-Home-Projekt befindet sich nun im Probebetrieb und wird kontinuierlich ausgebaut. Der Raspberry Pi 4 bildet dabei nicht die neue Mitte des Hauses. Er ist seine Kante: ein kleiner, lokaler Knoten für Koordination und Übersetzung. Die Grundfunktion bleibt dort, wo sie wirken muss. Und genau deshalb darf die Software darüber wachsen, ohne dass das Haus von ihr abhängig wird.

Als Nächstes kommt die Beleuchtungssteuerung dazu, selbstverständlich wieder Local First. Wer möchte schon im Dunkeln sitzen, nur weil ein zentraler Dienst gerade nicht erreichbar ist? Geplant ist außerdem eine Wetterstation mit weiteren lokalen Messparametern. Daneben gibt es erste Ideen für eigene Hardware auf Basis von ESP32 und ESP8266: kleine, gezielt gebaute Komponenten, wo vorhandene Geräte keine passende lokale Schnittstelle oder Funktion anbieten.

Der Maßstab bleibt dabei unverändert: Eine Erweiterung muss im Alltag nützlich sein, ihre Zuständigkeit klar machen und im Fehlerfall sinnvoll degradieren.

Ein produktpolitischer Appell