Teil 1 der Serie „Smart Home in der Praxis“. Die Teile 2 bis 5 holen die Wärmepumpe von der Hersteller-Cloud an die eigene Zentrale, Teil 6 stellt das eigene Energiemanagement vor, Teil 7 zeigt, wie Photovoltaik, Speicher und dynamische Strompreise zusammenspielen, und Teil 8 zieht Bilanz über 25 Automationen.
Mein Smart Home kennt aktuell 1744 Entitäten: Sensoren, Schalter, Lampen, Thermostate, Wechselrichter, Türkontakte, ein Gewächshaus. Der wichtigste Satz über dieses Setup ist aber ein anderer: Fast alles davon funktioniert auch dann, wenn das Internet ausfällt. Licht geht an, Heizung regelt, Automationen laufen. Das ist kein Zufall, sondern das Ergebnis einer Grundsatzentscheidung, um die es in diesem ersten Teil geht.
Die Zentrale: ein Server statt zwanzig Apps
Das Herz ist Home Assistant, eine Open-Source-Zentrale, die auf einem kleinen Rechner im Haus läuft. Sie spricht mit allem, was hier funkt und misst, und vereint es in einer Oberfläche. Ohne so eine Zentrale sieht der Alltag anders aus: eine App für die Lampen, eine für die Steckdosen, eine für die Heizung, eine für den Staubsauger. Und jede davon redet mit der Cloud ihres Herstellers.
Genau da beginnt das Problem. Ein Smart Home produziert intime Daten: wann du aufstehst, wann niemand zu Hause ist, in welchem Zimmer sich abends jemand bewegt, wie viel Strom du wann verbrauchst. Im Cloud-Modell verlassen diese Daten das Haus und landen auf Servern von einem Dutzend Firmen, deren Datenschutzerklärungen niemand liest. Im lokalen Modell bleiben sie da, wo sie entstehen.
Das zweite Argument heißt Abhängigkeit
Datenschutz ist der eine Grund, Verfügbarkeit der andere. Wer Cloud-Geräte kauft, kauft ein Versprechen, dass der Hersteller seine Server weiterbetreibt. Das prominenteste Gegenbeispiel lieferte 2022 der Smart-Home-Pionier Insteon: Die Firma schaltete ihre Cloud über Nacht und ohne Ankündigung ab, und funktionierende Hardware in tausenden Häusern wurde schlagartig nutzlos. Ähnliche Geschichten gibt es seitdem regelmäßig, meist leiser: Ein Hersteller stellt die App ein, verlangt plötzlich ein Abo oder streicht die Schnittstelle, über die das Gerät bisher steuerbar war.
Gegen all das ist ein lokales Setup immun. Mein ältester Zigbee-Sensor weiß nicht einmal, ob es seinen Hersteller noch gibt. Er funkt an die Zentrale, das reicht.
Zigbee, WLAN und ein bisschen Bluetooth
In der Praxis besteht das Setup aus mehreren Schichten, die alle lokal bleiben:
- Zigbee über die ZHA-Integration: das Arbeitstier für Batteriegeräte wie Tür- und Fenstersensoren, Bewegungsmelder, Temperaturfühler und Funkschalter. Ein einziger USB-Stick an der Zentrale spannt das Netz auf, die Geräte selbst kommen nie ins WLAN und schon gar nicht ins Internet.
- WLAN-Geräte mit lokaler Schnittstelle: Shelly-Module hinter Schaltern und in Verteilerdosen sowie Geräte mit der Open-Source-Firmware Tasmota, angebunden über MQTT. Beide sprechen direkt mit der Zentrale, ganz ohne Hersteller-Konto.
- Bluetooth über den offenen BTHome-Standard: kleine Temperatur- und Feuchtesensoren, die einfach in die Gegend senden; die Zentrale hört zu.
- Homematic IP für die Heizkörperthermostate, bewusst in der lokalen Variante mit eigener Zentrale im Haus statt über die Hersteller-Cloud.
Dazu kommen Integrationen aus der Community über HACS, den inoffiziellen Store für Home Assistant. Mehr dazu in den Teilen 6 und 7, wo sie die Hauptrolle spielen.
Ganz ohne Cloud geht es nicht
Ein reines Lokal-Dogma wäre gelogen. In diesem Haushalt hängen ein paar Geräte weiter an ihrer Hersteller-Cloud, weil es schlicht keinen lokalen Weg gibt. Typisches Beispiel sind Hausgeräte großer Marken. Das größte dieser Cloud-Geräte war lange die Wärmepumpe; wie sie nach dem Ausfall ihres Cloud-Gateways an die eigene Zentrale kam, erzählen die Teile 2 bis 5 dieser Serie. Die Wetterprognose kommt naturgemäß aus dem Netz, und Benachrichtigungen aufs Handy laufen über Push-Dienste. Der Unterschied ist die Richtung der Abhängigkeit: Fällt einer dieser Dienste aus, verliere ich Komfort am Rand. Das Haus selbst mit Licht, Wärme und Sicherheit läuft weiter.
Daraus ist eine einfache Kaufregel geworden: Vor jedem neuen Gerät steht die Frage, ob es lokal steuerbar ist. Wenn nicht, muss es schon sehr gute Gründe geben. Auch das BSI empfiehlt, bei Smart-Home-Geräten vor dem Kauf auf Update-Versorgung und Abhängigkeiten zu achten. Die konsequenteste Antwort darauf ist lokale Steuerbarkeit.
Wie man anfängt, ohne 1744 Entitäten zu brauchen
Der Einstieg ist kleiner, als die Zahl oben vermuten lässt: ein Raspberry Pi oder gebrauchter Mini-PC, darauf Home Assistant, dazu ein Zigbee-Stick und zwei, drei Sensoren. Mehr braucht der Anfang nicht. Danach wächst das System von allein, weil jedes Problem im Haushalt plötzlich wie ein Sensor-Problem aussieht. Wichtiger als Hardware ist die Grundsatzentscheidung vom Anfang: lokal zuerst. Sie lässt sich nachträglich nur mühsam korrigieren, denn gekaufte Cloud-Geräte bleiben Cloud-Geräte.
Im nächsten Teil wird es konkret: Die Wärmepumpe, ausgerechnet das teuerste Gerät im Haus, hing an einer Hersteller-Cloud, bis deren Gateway ausfiel. Warum die Antwort darauf ein 35-Euro-Board war und keine neue Cloud, erzählt Teil 2.
Quellen
- Home Assistant: Projekt-Website, Open-Source-Zentrale, Grundlage des beschriebenen Setups
- Home Assistant: ZHA-Integration, Zigbee direkt am eigenen Stick, ohne Hersteller-Bridge
- Home Assistant: Shelly-Integration, lokale Anbindung der Shelly-Module
- BTHome: Offener Bluetooth-Standard, herstellerunabhängiges Format für Bluetooth-Sensoren
- HACS: Home Assistant Community Store, Community-Integrationen jenseits des offiziellen Katalogs
- The Register: Smart home biz Insteon goes silent as cloud services stop, die Cloud-Abschaltung von 2022 als Lehrstück
- BSI: Smarthome sicher einrichten, Empfehlungen zu Kauf und Betrieb