Wer eine Reise tut, der kann was erzählen! Dies gilt umso mehr, wenn man mit einem Smart Home in ein neues Haus umzieht. Insofern haben sich durch die räumliche Veränderung in Sachen Smart Home etliche Chancen, Herausforderungen und technische Veränderungen ergeben, an denen ich Euch nun teilhaben lassen möchte.
Abschied von Britzingen
In unserem alten Haus hatte ich über die Jahre eine komfortable, aber auch leider sehr komplexe smarte Infrastruktur aufgebaut. Mir wurde bei den Vorbereitungen auf einen Verkauf des Hauses schnell bewusst, dass ein individuelles Smart Home eine echte Bürde darstellt; da kaum ein Käufer bereit oder in der Lage gewesen wäre, sich auf die Pflege meiner recht komplexen technischen Spielereien einzulassen. So war ich gezwungen, die liebevoll konfigurierten Komponenten weitgehend rückzubauen und – wo möglich – durch „dumme“ Schalter zu ersetzen. Das Problem hierbei war, dass einige Aktoren sich nur durch einen hohen baulichen Aufwand hätten ersetzen lassen – In diesen Fällen rüstete ich die Komponenten auf einen stand-alone Betrieb um und hinterließ für den Hauskäufer eine ausführliche Gebrauchsanleitung. (*Spoiler: es waren inzwischen dennoch einige Telefonate notwendig, z.B. als bei Maler-Arbeiten ein Funkschalter verloren ging, der mit mehreren Jalousien direkt gekoppelter war. Das Anlernen eines neuen Schalters ist leider nicht trivial).
______________________Ein Smart Home ist für den Hausverkauf eher eine Bürde, als ein Asset.
Der Neustart in Neckarbischofsheim
Im neuen Haus stand ich erneut vor der Aufgabe des ‚Retrofitting‘, also des naträglichen Einbaus meiner ca. 120 smarten Komponenten in die bereits vorhandene elektrische Infrastruktur. Natürlich sollte dies nicht zum Selbstzweck passieren, sondern jeweils eine spürbare Verbesserung darstellen. Kein einfacher Job.
Unser Haus, Baujahr 2006, hatte zwar bereits einige moderne Annehmlichkeiten, war jedoch in Sachen Klima und Licht eher rudimentär ausgerüstet. So gab es z.B. nicht in jeder Schalterdose einen Neutralleiter; manche Schaltungen waren sternförmig angelegt (landeten also im Sicherungskasten; leider großteils unbeschriftet), andere – offensichtlich nachgerüstet – waren im Zimmer verkabelt, endeten unterputz oder als loser Leiter irgendwo im Nichts.
Virtualisierung
Da ich einige meiner Steuergeräte („Zentralen“, „Hubs“) im alten Haus zurück lassen musste, stellte sich zwangsläufig die Frage nach Ersatz. Gleichzeitig war ich mit der Performance und Zuverlässigkeit z.B. des Mini-Computers RaspBerry Pi nicht mehr ganz zufrieden. Der Wartungsaufwand aufgrund zuletzt vier unterschiedlicher Minicomputer nebst jeweils eigenem Betriebssystem war ebenfalls nicht zu unterschätzen.
Beim Neustart habe ich daher konsequent auf Virtualisierung gesetzt. Als Grundlage diente ein leistungsstarker Mini-PC (ähnlich wie ein Intel NUC), auf dem ein ProxMox Server aufgesetzt wurde.
Aktuelle IST-Situation und Lektionen für die Zukunft
Den Neustart habe ich ebenfalls genutzt, um den Wildwuchs an Systemen zu verschlanken. So setze ich inzwischen ausschließlich auf Home Assistant als meine Smart Home Zentrale. Dieses System wird durch eine große Community gut gepflegt und bringt bereits Integrationen für die meisten Herteller mit. Eine App für das Smartphone erlaubt eine komfortable Bedinung dank frei gestaltbarer Benutzeroberfläche. Dank eines USB-Dongles ZBT‑1 vom gleichen Hersteller wird das Zigbee-Protokoll (für Philips Hue, Osram Smart+, etc.) nativ unterstützt und das System ist auch schon gerüstet für den übrgreifenden „Matter over Thread“ Standard.
Lediglich für meine Handvoll Homematic (IP) Komponenten wird noch eine separate (virtuelle) Zentrale auf Basis des RaspberryMatic Betriebssystems benötigt.
Schematische Darstellung meines neuen Smart-Homes
Im Vergleich zu meiner alten Lösung zeigt sich eine deutliche Struktur-Vereinfachung.
Die meisten Komponenten betreibe ich lokal, so dass mein Smart-Home auch offline weiter funktioniert. Hauptsächlich aus Bequemlichkeit nutze ich für machen Systeme aber immer noch die jeweilige Hersteller-Cloud, obwohl es meist sogar lokale Lösungen gäbe – z.B. indem eine veränderte Firmware aufgespielt wird oder der Hersteller-Code manuell eingegeben werden muss.
Lektionen für die Zukunft
Folgende Erkenntnisse würde ich aktuell einem Smart-Home Einsteiger mit auf den Weg geben
- Nutze so wenige Protokolle, wie möglich. Bevorzuge herstellerübergreifende Standards (wie Zigbee, Matter, Thread o.ä.). Für jedes zusätzliche Protokoll wird meist eine eigene Hardware-Zentrale oder eine Software-Integration benötigt. Somit erhöht sich die Komplexität und der Wartungsaufwand. Proprietäre (Funk-)Protokolle bringen außerdem die Gefahr mit sich, dass die Kompatibilität in Zukunft verloren geht. Was uns zum nächsten Punkt bringt…
- Prüfe vor dem Kauf einer neuen Komponente, ob diese gut mit deinem System zusammen arbeitet
die meisten Komponenten können irgendwie in ein System wie Home-Assistant integriert werden. Viele Hersteller kooperieren sogar offiziell mit Home-Assistant Foundation, so dass man von einer langfristigen Funktionalität ausgehen darf. Andere Komponenten können zumindest über eine Community-gepflegte (inoffizielle) Integration genutzt werden. Ob hier aber zeitgemäß und auch in Zukunft Updates geboten werden, hängt vom Engagement der (Hobby-)Programmierer ab… Und dann gibt es leider auch die unrühmlichen Ausnahmen, die sich gar nicht in ein Smart Home integrieren wollen, sondern nur über die proprietäre App benutzbar sind (z.B. einige Reolink-Kameras). Letztere sollte man nach Möglichkeit vermeiden. - Bevorzuge lokale Lösungen vor cloud-basierten Lösungen
Hersteller-Clouds bieten meist einen höheren Komfort, bergen aber einige Gefahren: so werden persönliche Daten über’s Internet geschickt und beim Ausfall der Server (Hersteller geht pleite, ändert seine Politik oder hat technische Probleme) können Komponenten ihre Funktion verlieren! - Virtualisiere deine Zentralen und Hubs!
Hierdurch verringert sich der Wartungsaufwand und es erhöht sich die Ausfallsicherheit. Man kann zum Beispiel Backups erstellen und „Watchdogs“ einsetzen, um (extern) den Absturz einer Zentrale festzustellen und einen entsprechenden Neustart zu initiieren.