Einleitung: Die Ausgangslage
Home-Automation war lange ein Konzept, mit dem ich mich nicht auseinandersetzt habe. Bis Arbeitskollegen anfingen, davon zu erzählen.
Diese Gespräche waren informativ und detailliert - erzeugten bei mir aber auch eine erste Hürde: zu viel Komplexität, zu viel spezialisiertes Wissen erforderlich. Mein erster Gedanke: „Das ist für mich wahrscheinlich zu viel."
Dann kam eine längere Recherchephase. Verschiedene Systeme, ihre Ansätze, ihre Vor- und Nachteile. Dabei wurde mir ein zentrales Problem deutlich: Die meisten Systeme sind cloudbasiert. Deine Daten liegen auf Servern eines Anbieters. Du nutzt das System, aber kontrollierst nicht, wo und wie deine Daten gespeichert werden.
Das hat mich bewogen, eine andere Route zu suchen: Open Source. Systeme, deren Code offen einsehbar ist. Systeme, bei denen ich die Kontrolle über meine Daten behalte und sie lokal betreiben kann.
Diese Suche führte mich zu Home Assistant.
Die erste Hürde: Hardware und Virtualisierung
Hardware-Entscheidungen
Der erste konkrete Schritt: Welche Hardware brauche ich?
Ein vollwertiger PC mit Monitor kam nicht in Frage. Ein Mini-PC - ein NUC (Next Unit of Computing) - schien die richtige Größe zu sein. Die Auswahl war aber größer als erwartet: Prozessoren, RAM, Stromverbrauch, Preis.
Die Lösung als günstiger Einstieg war ein NUCi5 von Kleinzeigen mit den Specs:
- Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz
- 8GB RAM
- 1 TB NVMe
Dazu kam ein strategischer Überlegung: In Zukunft könnte ich weitere Projekte auf diesem System umsetzen wollen. Ein Dateiserver. Andere selbstgehostete Anwendungen.
Das führte zu der Frage: Wie isoliere ich verschiedene Projekte voneinander? Wie verhindere ich, dass ein Update in einer Anwendung die anderen beeinträchtigt?
Diese Frage führte mich zu Virtualisierung - ein Konzept, das ich aus beruflicher IT-Welt kannte, aber noch nie selbst angewendet hatte.
Proxmox als Virtualisierungslösung
Ich recherchierte verschiedene Virtualisierungslösungen und stieß auf Proxmox - eine Open Source Virtualisierungsplattform mit großer Community.
Proxmox ermöglicht es, auf einem einzigen NUC mehrere isolierte Umgebungen zu schaffen. Jede Anwendung läuft in ihrem eigenen Container. Sie beeinflussen sich nicht gegenseitig.
Damit war klar: Ich baue nicht einfach nur eine Anwendung. Ich schaffe eine Infrastruktur - die Basis, auf der ich in Zukunft weitere Projekte umsetzen kann.
Der praktische Vorteil dieser Isolation: Sollte es bei einer Anwendung Probleme geben, kann ich diese neu aufsetzen, ohne dass andere Systeme davon betroffen sind. Das reduziert das Risiko erheblich und half mir bereits bei der initialen Instalation, die nicht gleich klappte.
Praktische Umsetzung
Die nächsten Schritte waren praktischer Natur: NUC ins Heimnetzwerk integrieren. Sicherstellen, dass Home Assistant stabil erreichbar ist. Entscheiden, welche Ports geöffnet werden.
Das waren keine großen technischen Hürden, aber eine Reihe von Details, die ich selbst recherchieren musste.
Das ist ein wichtiger Punkt: Man muss nicht alles im voraus wissen. Man muss bereit sein, die einzelnen Schritte zu gehen und Fragen zu stellen.
Das erste funktionierende System: Daten sammeln und visualisieren
Das Problem: Daten ohne Kontext
Home Assistant war installiert, der NUC lief. Aber jetzt?
Home Assistant allein ist eine Verwaltungsoberfläche. Sie braucht Daten, um sinnvoll zu sein. Und sie braucht eine Möglichkeit, diese Daten verständlich zu machen.
Ich installierte InfluxDB - eine Datenbank, die spezialisiert auf Sensordaten ist. Hier landen alle Messwerte strukturiert mit Zeitstempel: Temperatur, Luftfeuchte, Energieverbrauch.
Dann installierte ich Grafana - ein Visualisierungstool, das diese Rohdaten in Graphen umwandelt.
Die Visualisierung ändert alles
InfluxDB speichert Daten, Grafana holt sie sich und visualisiert sie. Ich musste mich eine Weile mit den Variablen und "Verarbeitungsoptionen" von Grafana beschäftigen. Doch nach einer Weile sah ich auf meinem Bildschirm nicht nur Tabellen mit Zahlen - ich sah Kurven, Muster, Zusammenhänge.
Ich konnte sehen, wie die Temperatur im Schlafzimmer über den Tagesverlauf reagiert. Wie die Luftfeuchte auf Wetterverhältnisse antwortet. Wie sich nachts die Außentemperatur auf die Innentemperatur auswirkt.
An diesem Punkt war mein initiales Ziel erreicht: Sensoren liefern Daten. Eine Datenbank speichert sie. Ein Visualisierungstool zeigt sie mir und ich konnte die äußeren lokalen Klimadaten mit den Messwerten meiner Wohnung verknüpfen.
Optimierung der Datenquellen
Das erste Problem: Datenqualität
Die ersten Sensoren, die ich einband, waren meine bestehenden Temperatur- und Luftfeuchtigkeitssensoren. Ein BLE-Empfänger auf einem ESP32-Mikrocontroller sammelte diese Daten. Ich bestellte eine handvoll Controller ukd lernte, wie man sie mit der entsprechenden Software flasht. Danach bekamen die nackten Sensoren noch ein schlichtes Gehäuse und wurde an neuralgischen Punkten in der Wohnung verteilt.
Technisch funktionierte alles. Aber die Datenqualität war suboptimal:
- Die Sensoren sende alle paar Sekunden einen Wert → Das erzeugt Rauschen in den Graphen
- Ein anderer Sensor zeigte vier Dezimalstellen an → Mehr Genauigkeit als nötig
- Die Sensor-Namen waren kryptisch →
sensor_5a8fstatt aussagekräftigen Namen
Die Daten waren vorhanden, aber nicht optimiert.
Template-Sensoren als Lösung
Template-Sensoren schafften Abhilfe. Ein Template-Sensor ist ein virtueller Sensor, den ich selbst definiere, basierend auf echten Sensoren.
Mit Template-Sensoren kann ich:
- Die Datenrate reduzieren (nur jeden 5. Wert speichern statt alle paar Sekunden)
- Die Messgenauigkeit anpassen (auf zwei Dezimalstellen runden)
- Aussagekräftige Namen vergeben (sensor_wohnzimmer_temperatur statt sensor_5a8f)
- Korrekturberechnungen durchführen (z.B. eine fehlerhafte Messung korrigieren)
Das war ein wichtiger Lernpunkt: es kommt nicht auf die Masse an Daten an, sondern auf die Qualität.
Erweiterung: Kontext und Kontrolle
Kontext durch externe Daten
Mit den Basis-Sensoren wollte ich das System erweitern. Ich integrierte Wetterdaten von Met.no über einen Template-Sensor, der eine API anzapft.
Plötzlich hatte ich nicht nur Daten aus meinem Zuhause, sondern auch Kontext der Außenwelt.
Das macht einen Unterschied: Wenn die Innentemperatur sinkt, kann ich jetzt sehen, ob das an der Außentemperatur liegt oder an meinen Verhaltensweisen (Fenster offen).
Kontrolle durch Aktoren
Dann kam der nächste Schritt: der Sonoff Zigbee-Stick. Damit konnte ich Matter-kompatible Geräte einbinden - nicht nur Sensoren, sondern auch Schalter und Mess-Steckdosen:
- Mess-Steckdosen (um Stromverbrauch zu messen)
- Schaltsteckdosen (um Geräte zu schalten)
Das System wurde damit von einer reinen Beobachtungslösung zu einer aktiven Infrastruktur, die auf ihre Umgebung reagieren kann.
Was sich durch dieses Projekt geöffnet hat
Die technische Seite
Ich habe gelernt, wie Virtualisierung funktioniert. Wie Datenbanken und Visualisierungswerkzeuge zusammenarbeiten. Wie man Sensoren einbindet. Wie man Systeme isoliert und wartet.
Der Perspektivwechsel
Aber die wichtigere Erkenntnis ist eine andere: Ich bin kein reiner Konsument mehr.
Früher: „Mein Smart Home müssen andere bauen. Ich zahle, sie installieren, ich nutze."
Jetzt: „Ich baue das selbst. Nicht als Profi. Aber als jemand, der bereit ist, die einzelnen Schritte zu lernen und sie zusammenzusetzen."
Das hat sich auch auf andere Bereiche ausgeweitet. Virtualisierung war ein abstraktes Konzept. Jetzt habe ich es umgesetzt. Ich verstehe das Grundkonzept und sehe das Potenzial für weitere Projekte. Das ist nicht mehr Theorie - das ist nun Erfahrung.
Und es hat zu neuen Ideen geführt: Wenn ich Home Assistant aufgesetzt habe, warum nicht auch andere selbstgehostete Anwendungen? Ein Dateiserver. Ein Paperless-System für Dokumentenverwaltung. Alles auf der gleichen Infrastruktur, alles isoliert, alles unter meiner Kontrolle.
Das reizt mich am Homo Creator-Ansatz: nicht als Fertig-Experte starten, sondern als jemand, der willens ist, die einzelnen Teile zu lernen und sie zusammenzusetzen.
Ausblick: Der nächste Schritt
Bis hier habe ich ein System, das beobachtet, speichert und visualisiert. Das funktioniert und ist wertvoll.
Der nächste logische Schritt sind Automationen:
- Wenn die Temperatur sinkt, soll die Heizung reagieren
- Wenn die Luftfeuchte kritisch wird, soll eine Benachrichtigung erfolgen
- Wenn die Sonne untergeht, sollen die Lichter angehen
- Wenn ich nicht zuhause bin, sollen Sicherheitsfunktionen aktivieren
Das ist der Punkt, wo ein Smart Home von einer Messlösung zu einem reaktiven System wird.
Aber auch diesen Schritt freue ich mich, an der Umsetzung der einzelnen Komponenten zu lernen.