· Smart Home

Home Automation: Smart Home ohne Hersteller-Abhängigkeit

Amazons Alexa-Ecosystem, Google Home und Philips Hue App – alle schön, alle bequem, alle mit dem gleichen Problem: die Intelligenz liegt in der Cloud des Herstellers. Ich setze im eigenen Homelab auf lokale Technik. Für die Gerätesteuerung ist Home Assistant die naheliegende Zentrale.

Zuletzt aktualisiert:

Home Assistant Zigbee MQTT Automations lokal

Home Assistant als lokale Zentrale – warum kein Cloud-System?

Home Assistant ist Open-Source-Software, die auf dem eigenen Server oder einem Raspberry Pi läuft und als Zentrale für alle Smart-Home-Geräte dient. Über 3.000 Integrationen, aktive Community, keine Cloud-Abhängigkeit.

Was gegen reine Cloud-Systeme spricht:

  • Abschaltrisiko: Wer erinnert sich an Ikea Tradfri Cloud, Wink, SmartThings? Cloud-Dienste werden eingestellt. Lokale Systeme laufen weiter.
  • Datenschutz: Bewegungsprofile, Energieverbrauch, Anwesenheitsdaten – das will ich nicht auf fremden Servern.
  • Latenz: Ein lokal getriggertes Licht schaltet in Millisekunden. Cloud-Roundtrip bedeutet oft 200–800 ms Verzögerung.
  • Flexibilität: Home Assistant-Automationen sind deutlich mächtiger als was die Hersteller-Apps bieten.

Home Assistant läuft auf einem Mini-PC oder Raspberry Pi im Heimnetz, als Docker-Container oder auf dedizierten HA-Hardware-Geräten (Green, Yellow).

Protokolle und Geräte: Zigbee, Z-Wave, WLAN

Die Wahl des Protokolls beeinflusst Zuverlässigkeit, Datenschutz und Kosten erheblich:

  • Zigbee (meine Empfehlung): Mesh-Protokoll, kabellose Verbindung, sehr günstige Geräte (Aqara, Sonoff, Ikea). Benötigt einen Zigbee-Stick (z.B. SONOFF Zigbee 3.0 USB Dongle) und Zigbee2MQTT oder die ZHA-Integration in Home Assistant. Alle Daten bleiben lokal.
  • Z-Wave: Stabiler als Zigbee, teurer. Gut für Schlösser und Sicherheitsanwendungen. Lizenziertes Protokoll.
  • WLAN (ESPHome/Tasmota): Günstiger Einstieg, aber Netzwerküberlastung bei vielen Geräten möglich. ESPHome für eigene Microcontroller-Projekte exzellent. Shelly-Geräte laufen lokal und sind WLAN-basiert.

Mein Tipp: Mit Zigbee anfangen. Günstig (ein Zigbee-Stick reicht für 50+ Geräte), lokal, zuverlässig und riesige Kompatibilitätsliste.

KI im Smart Home: Automatisierungen die wirklich denken

Klassische Home-Automation-Regeln sind starr: „Wenn Bewegung UM 22:00, dann Licht an." Mit KI-Integration werden Automationen kontextsensitiv.

Ein möglicher Aufbau: n8n als Middleware zwischen Home Assistant und lokalen Sprachmodellen:

  • Natürlichsprachliche Steuerung ohne Cloud: Home Assistant sendet Sprachbefehle an ein lokales Modell per n8n-Webhook – kein Alexa, kein Google.
  • Intelligente Szenen: Das LLM entscheidet basierend auf Uhrzeit, Wochentag, letzter Aktivität und aktuellem Wetter, welche Szene „passt" – statt hartcodierter If-Else-Ketten.
  • Anomalie-Erkennung: Ungewöhnlicher Energieverbrauch wird erkannt und per Telegram gemeldet – mit einer natürlichsprachlichen Erklärung.

Das ist echtes KI-Automatisierungs-Potential im Heimbereich – und mit lokalen Modellen vollständig datenschutzkonform.

Was bei mir im Homelab dauerhaft läuft

Bei mir laufen ein Raspberry Pi 3, ein Pi 4 und ein Pi 5 im Dauerbetrieb, dazu ein Unraid-Server. Auf den Pis laufen Docker und Tailscale. Die Geräte erledigen feste Aufgaben, die man klassisch zur IoT-Seite zählen würde:

  • Gäste-WLAN auf dem Pi 4: hostapd auf 2,4 GHz, Kanal 11, eigenes Subnetz und eigene nftables-Regeln. Gäste kommen ins Internet, aber nicht ins Heimnetz. Ein- und ausgeschaltet wird es über einen Web-Schalter, der eine Statusdatei setzt. Der Pi fragt sie alle 10 Sekunden ab.
  • Wetter-Display: läuft ebenfalls auf dem Pi 4, mit log2ram gegen SD-Karten-Verschleiß.
  • 3,5-Zoll-Display am Pi 3: SPI-Display mit ILI9486-Controller über das Overlay tft35a.
  • Unraid: Medienserver mit Jellyfin und Dokumentenarchiv mit Paperless-ngx.
# Gäste-Subnetz: nur Internet, kein Heimnetz (vereinfacht) table inet gast { chain forward { type filter hook forward priority 0; iifname "<gast-wlan>" ip daddr <heimnetz> drop iifname "<gast-wlan>" oifname "<uplink>" accept } }

Die Konfigurationen aller Geräte werden jeden Tag um 02:30 gesichert, an mehrere Ziele, darunter ein Cloud-Speicher und ein NAS. Große Mediendaten laufen getrennt davon über einen rsync-Spiegel.

Praxiswerte aus der Werkstatt (Stand: Oktober 2026)

  • Konfig-Backup je Gerät: ca. 120–130 KB komprimiert, rund 1 MB unkomprimiert
  • Backup-Grenzen: Warnung ab 400 MiB, Abbruch ab 1 GiB
  • Medien-Spiegel: rund 43 GB, read-only, Upload tagsüber auf 5 MB/s gedrosselt
  • Jellyfin-Transcoding: 10,8-fache Echtzeit mit Intel QSV, 1,98-fach mit der CPU
  • Statusabfrage Gäste-WLAN: alle 10 Sekunden

Die Grenzen beim Backup haben einen Grund: Ein Konfig-Archiv, das plötzlich auf Hunderte Megabyte wächst, enthält fast immer Daten, die dort nicht hingehören.

Pannen im Homelab und was ich daraus geändert habe

  • Kaputte SD-Karte am Pi 3: Die alte Karte ist vermutlich durch Unterspannung gestorben. vcgencmd get_throttled zeigte 0x50005. Die Lehre: bei Abstürzen und Kartenfehlern zuerst das Netzteil prüfen.
  • Jellyfin brach die Wiedergabe ab: Beim Booten startete Docker auf dem Unraid-Server vor dem SMB-Mount. Der Container hatte ein Unterverzeichnis ohne Mount-Propagation eingebunden und sah danach nur einen leeren Ordner. Die Lehre: Bei Netzlaufwerken im Container zuerst prüfen, ob der Mount vor Docker steht.
  • 2.415 Tags in Paperless: Eine KI-Automatik durfte ungebremst Tags anlegen. Ich habe auf 40 aufgeräumt. Die Lehre: Eine KI-Automatik braucht eine feste Liste, aus der sie wählen darf.
  • Eigene IP ausgesperrt: Mein eigener Sicherheitsscanner löste auf dem Webserver ModSecurity aus. fail2ban sperrte daraufhin die dynamische Heim-IP für 7 Tage, und Statusmeldungen aus dem Heimnetz kamen nicht mehr an. Heartbeats und Jobs laufen jetzt über Tailscale statt über das öffentliche Netz.
  • Kernel-Oops im WLAN-Treiber: Der Treiber brcmfmac des Pi 4 ist einmal abgestürzt. Für ein Gäste-WLAN reicht das, für Dinge, die zuverlässig schalten müssen, würde ich Funk und Steuerung trennen.

Für Sensoren und Schaltaktoren ist MQTT der übliche Weg. Wenn ein Sprachmodell mitentscheiden soll, findest du unter lokale LLMs, was auf eigener Hardware machbar ist.

Häufige Fragen zur Home Automation

Empfehlung: Home Assistant auf einem Raspberry Pi 4 (oder als Docker-Container), ein Zigbee-USB-Stick, zwei oder drei günstige Zigbee-Steckdosen oder Lampen. Damit lernt man das System ohne großen Invest kennen. Die erste eigene Automation, die wirklich funktioniert, ist der Moment wo man nie mehr ohne sein will.

Der Einstieg ist günstig: Raspberry Pi 4 (~50€), Zigbee-Stick (~15€), erste Zigbee-Geräte ab 8–15€ pro Stück. Kein Abo, keine Cloud-Kosten. Im Vergleich zu Philips Hue oder Amazon-Ecosystem spart man auf Dauer deutlich – und hat deutlich mehr Funktionen.

Sehr wahrscheinlich ja. Home Assistant hat über 3.000 Integrationen – Philips Hue, IKEA, Shelly, Sonos, Fronius, Fritz!Box und hunderte weitere. Auch Cloud-verbundene Geräte können oft über lokale APIs oder Custom Integrations ohne Cloud-Roundtrip gesteuert werden.

Das ist ein zentraler Vorteil lokaler Systeme: Zigbee-Geräte und Home Assistant kommunizieren ausschließlich im lokalen Netzwerk. Licht, Heizung, Bewegungsmelder – alles funktioniert auch wenn das Internet ausgefallen ist. Cloud-basierte Systeme werden in diesem Fall oft komplett stumm.

Bei mir ja, mit zwei Voraussetzungen: ein ausreichend starkes Netzteil und Schutz der SD-Karte. Unterspannung hat bei mir eine Karte zerstört. Auf dem Pi 4 schreibt log2ram Logs in den RAM statt ständig auf die Karte. Die Konfiguration sichere ich täglich, damit ein Kartentausch kein Neuaufbau wird.

Fragen per WhatsApp