//
Kolumne
13 Min. Lesezeit

Jenseits von Alexa – lokale Smart-Home-Plattformen und die Frage nach der Kontrolle

Kolumne

Im vorherigen Artikel habe ich beschrieben, was Alexa & Co. im Hintergrund treiben – die ständigen Cloud-Anfragen, die Telemetrie, die Verknüpfung von Sprachdaten mit Werbeprofilen, der Smart TV, der sich nachts selbst weckt. Am Ende stand die Frage: Gibt es Alternativen, die nicht nur filtern, sondern die Abhängigkeit auflösen?

Die Antwort ist ja. Und sie ist vielfältiger, als viele denken.

Dieser Artikel ist der versprochene Folgebeitrag. Er behandelt die Plattformen, die ein Smart Home lokal und ohne Cloud-Abhängigkeit betreiben können – und warum es dabei am Ende weniger darauf ankommt, welches System man wählt, als dass man überhaupt eines wählt.

Warum überhaupt eine Plattform?

Wer ein Smart Home aufbaut, trifft früh eine Entscheidung: Läuft alles über einen Hersteller und seine Cloud, oder läuft es über eine eigene Zentrale, die lokal arbeitet? Die erste Variante ist der bequeme Weg. Philips Hue mit der Hue-Bridge, Bosch Smart Home mit dem Controller, Homematic IP mit der CCU3 – alles funktioniert out of the box, alles ist in einer App steuerbar, alles ist – zumindest teilweise – cloud-abhängig.

Die zweite Variante ist der Weg der Plattform. Eine zentrale Software, die auf eigener Hardware läuft, Geräte aller Hersteller integriert, Automatisierungen lokal ausführt und keine Cloud zwingend benötigt. Das ist mehr Arbeit. Aber es ist der einzige Weg, der die Kontrolle im eigenen Haus behält.

Genau das ist der Punkt, der im Artikel Alexa & Co. – die stille Abhängigkeit im Wohnzimmer angesprochen wurde: Ein Smart Home, das primär über Alexa-Routinen läuft, ist faktisch eine Außenstelle von Amazons Infrastruktur. Eine lokale Plattform kehrt dieses Verhältnis um. Die Hardware gehört dem Nutzer. Die Steuerung auch.

Home Assistant – der pragmatische Einstieg

Home Assistant ist inzwischen die am weitesten verbreitete Open-Source-Plattform für Smart Home. Python-basiert, monatliche Releases, über 2.000 Integrationen, eine aktive Community, die auf GitHub über 70.000 Sterne bringt. Wer heute mit einem lokalen Smart Home beginnt, kommt an Home Assistant kaum vorbei.

Stärken:

  • Geräteerkennung – Home Assistant erkennt viele Geräte automatisch im Netzwerk. Wer einen Zigbee-Stick anschließt, einen Shelly einbindet oder einen Matter-Controller aktiviert, sieht die Geräte oft ohne manuelle Konfiguration.
  • Lovelace-Dashboard – die Benutzeroberfläche ist flexibel, per Drag-and-Drop anpassbar und auch auf dem Smartphone nutzbar. Native Apps für iOS und Android existieren.
  • Automatisierungen – visuell über den Editor, per YAML für Fortgeschrittene, optional auch über Node-RED für komplexe Flows.
  • Integrationen – von Zigbee über Z-Wave, MQTT, KNX, Matter, Thread bis zu Homematic, Shelly, Hue, Sonoff, Frigate, MQTT, Modbus – praktisch jedes Protokoll und jeder Hersteller ist abgedeckt.
  • Add-on-System – im Home Assistant Operating System lassen sich Add-ons wie Mosquitto MQTT Broker, Node-RED, ESPHome, MariaDB oder Pi-hole direkt aus der Oberfläche installieren.
  • Energie- und Verbrauchsmanagement – seit 2021 gibt es ein eingebautes Energy Dashboard, das Stromverbrauch, PV-Erzeugung, Batteriespeicher und Wärmepumpen zusammenführt.

Schwächen:

  • Ressourcenbedarf – im Idle ca. 300 MB RAM, für Sprachverarbeitung deutlich mehr. Ein Raspberry Pi 3 reicht knapp, ein Pi 4 oder 5 ist die bessere Wahl, für Voice brauchts einen Mini-PC.
  • YAML – wer tiefere Anpassungen will, kommt an YAML-Konfiguration nicht vorbei. Das ist nicht schwierig, aber eine eigene Syntax, die gelernt sein will.
  • Breaking Changes – monatliche Releases bringen gelegentlich Änderungen, die bestehende Konfigurationen anpassen erfordern. Wer nicht aktualisiert, verpasst Sicherheitsupdates. Wer aktualisiert, muss manchmal nachbessern.

Sprachsteuerung lokal: Home Assistant bietet mit dem Assist-Pipeline eine vollständig lokale Sprachsteuerung. Wake-Word-Erkennung (openWakeWord), Speech-to-Text (Whisper), Text-to-Speech (Piper), Intent-Verarbeitung – alles läuft auf der eigenen Hardware. Die Genauigkeit ist nicht auf Alexa-Niveau, aber funktional. Mehr dazu weiter unten.

ioBroker – der Baukasten für Bastler

ioBroker ist die zweite große Plattform im deutschsprachigen Raum. Node.js-basiert, modular aufgebaut, mit einer Adapter-Architektur, die jeden Dienst und jedes Gerät als separates Modul anbindet. Wer JavaScript kann, fühlt sich hier schnell zuhause.

Stärken:

  • Adapter-Baukasten – über 500 Adapter für Geräte, Dienste und Protokolle. Jeder Adapter ist ein eigenes npm-Paket, das sich unabhängig installieren und aktualisieren lässt.
  • JavaScript-Engine – Automatisierungen lassen sich direkt in JavaScript schreiben. Wer programmieren kann, hat hier mehr Kontrolle als in jedem visuellen Editor.
  • Datenpunkt-Zentrum – ioBroker ist konsequent datenpunktorientiert. Jeder Zustand, jeder Sensorwert, jeder Schaltzustand ist ein Datenpunkt, den man lesen, schreiben und überwachen kann. Das ist technisch sauber und für komplexe Logiken vorteilhaft.
  • Multi-Instanz – ioBroker lässt sich auf mehrere Server verteilen, was für größere Installationen oder redundante Setups relevant ist.
  • Vis – die Visualisierung lässt sich frei gestalten, von einfachen Kacheln bis zu komplexen Dashboards mit eigener Logik.

Schwächen:

  • Lernkurve – ioBroker ist weniger „out of the box” als Home Assistant. Wer keine Programmierkenntnisse hat, tut sich schwerer.
  • Dokumentation – vieles ist auf Deutsch, was im deutschsprachigen Raum vorteilhaft ist, international aber eine Hürde darstellt. Manche Adapter sind schlecht dokumentiert.
  • Oberfläche – die Administrationsoberfläche ist funktional, aber nicht so intuitiv wie Home Assistant. Vis ist mächtig, aber aufwendig einzurichten.
  • Sprachsteuerung – ioBroker hat keinen nativen lokalen Sprachassistenten. Alexa- und Google-Adapter existieren, binden aber eben genau die Cloud-Dienste ein, die man vermeiden will. Wer lokal sprechen will, braucht Umwege über Home Assistant oder Rhasspy.

Fazit zu ioBroker: Wer JavaScript spricht, komplexe Logiken baut und ein deutschsprachiges Umfeld schätzt, findet in ioBroker eine mächtige Plattform. Wer einfach starten will, ist mit Home Assistant besser bedient.

FHEM – der Perl-Veteran

FHEM ist das älteste der hier behandelten Systeme. Perl-basiert, seit über 15 Jahren im Einsatz, mit über 430 Modulen und einer Community, die besonders im Homematic- und EnOcean-Umfeld stark ist. FHEM ist nicht modern, nicht hübsch, nicht einsteigerfreundlich – aber es ist stabil, mächtig und bewährt.

Stärken:

  • Stabilität – FHEM-Installationen laufen oft jahrelang ohne Neustart. Wer ein System sucht, das einfach funktioniert und nicht ständig aktualisiert werden will, ist hier richtig.
  • Homematic- und EnOcean-Unterstützung – FHEM hat historisch eine der tiefsten Anbindungen an diese Protokolle. Wer eine Homematic-Installation mit CCU betreibt und mehr will, findet in FHEM die logische Erweiterung.
  • Ereignisbasierte Architektur – FHEM ist konsequent ereignisgetrieben. Jeder Gerätezustand, jeder Sensorwert löst notify-Definitionen aus, die wiederum Befehle senden. Das ist technisch elegant und extrem flexibel.
  • Lokalität – FHEM war lokal, bevor lokal ein Verkaufsargument war. Keine Cloud, keine Telemetrie, keine Fernsteuerung. Wer will, kann FHEM komplett offline betreiben.

Schwächen:

  • Perl – FHEM ist in Perl geschrieben, und die Konfiguration erfolgt in FHEM-eigener Syntax, die an Perl angelehnt ist. Wer Perl nicht kennt, hat eine steile Lernkurve.
  • Oberfläche – das Standard-Webfrontend ist funktional, aber optisch auf dem Stand der frühen 2010er. Es gibt alternatives Frontends (FHEM Tablet UI, smartVISU, LCars), aber alle erfordern manuelle Einrichtung.
  • Community – die FHEM-Community ist aktiv, aber überschaubar geworden. Viele Entwickler sind zu Home Assistant gewechselt. Neue Module erscheinen seltener.
  • Sprachsteuerung – FHEM hat keinen nativen lokalen Sprachassistenten. Alexa- und HomeKit-Anbindungen existieren, sind aber Cloud-Abhängig.

Fazit zu FHEM: Wer Homematic oder EnOcean im Haus hat, Perl nicht scheut und ein stabiles System sucht, das nicht jeden Monat aktualisiert werden will, findet in FHEM eine ernsthafte Option. Wer neu einsteigt, wird mit Home Assistant oder ioBroker glücklicher.

openHAB – das Java-Fundament

openHAB ist die vierte Plattform, die man kennen sollte. Java-basiert, mit einer Architektur, die auf strikter Trennung von Bindings (Geräteanbindungen), Things (Geräte) und Items (Datenpunkte) setzt. openHAB ist formeller strukturiert als Home Assistant oder ioBroker, was Vor- und Nachteile hat.

Stärken:

  • Protokollvielfalt – openHAB hat native Unterstützung für KNX, Modbus, EnOcean, BACnet – Protokolle, die im gewerblichen und industriellen Bereich relevant sind. Wer ein KNX-Haus hat, findet hier eine der besten Anbindungen.
  • Architektur – die strikte Trennung von Bindings, Things und Items ist sauber und nachvollziehbar. Wer aus der Softwareentwicklung kommt, schätzt diese Struktur.
  • Open-HAB-Cloud – optional und selbst hostbar. Wer Fernzugriff will, ohne Daten an Dritte zu geben, kann die eigene Cloud-Instanz betreiben.
  • Matter-Unterstützung – openHAB hat Matter-Integration, wenn auch nicht so aggressiv wie Home Assistant.

Schwächen:

  • Lernkurve – die formelle Architektur ist konsequent, aber einsteigerunfreundlich. Wer von Home Assistant kommt, empfindet openHAB als umständlich.
  • Geschwindigkeit – Java-basiert, was auf schwacher Hardware spürbar ist. Ein Raspberry Pi 3 ist grenzwertig, ein Pi 4 oder besser empfehlenswert.
  • Community – kleiner als die von Home Assistant, was bei Problemen bedeutet, dass man länger nach Lösungen suchen muss.
  • Matter-Adoption – langsamer als bei Home Assistant. Wer auf Matter setzt, ist bei Home Assistant besser aufgehoben.

Fazit zu openHAB: Wer KNX, Modbus oder andere gewerbliche Protokolle nutzt, findet in openHAB eine ernsthafte Plattform. Wer ein reines Verbraucher-Smart-Home aufbaut, ist mit Home Assistant besser bedient.

Weitere Optionen

Neben den vier großen Plattformen gibt es weitere, die für bestimmte Anwendungsfälle relevant sind:

  • Domoticz – extrem ressourcenschonend, läuft auf einem Pi Zero mit 50 MB RAM. Wer ein minimalistisches System für eine kleine Wohnung sucht, findet hier eine schlanke Lösung.
  • Gladys Assistant – konsequent auf Privatsphäre ausgelegt, ohne jede Cloud-Funktion. Weniger Integrationen als Home Assistant, dafür radikal lokal.
  • Jeedom – französische Plattform, im deutschsprachigen Raum weniger verbreitet, aber mit einer aktiven Community und Plugin-System.
  • Homebridge – keine eigenständige Plattform, sondern eine Brücke, die Nicht-HomeKit-Geräte in Apples HomeKit integriert. Wer primär im Apple-Ökosystem lebt, aber Geräte anderer Hersteller nutzen will, findet hier eine Lösung. Homebridge läuft lokal, ist aber kein vollwertiger Automatisierungs-Server.

Der eigene Alexa-Ersatz: Sprachsteuerung lokal

Wer Alexa ersetzen will, ohne auf Sprachsteuerung zu verzichten, braucht drei Komponenten: Wake-Word-Erkennung, Speech-to-Text und Intent-Verarbeitung. Home Assistant bietet alle drei lokal an, zusammengefasst im sogenannten Assist-Pipeline.

Hardware-Optionen für Voice-Satelliten:

  • M5Stack Atom Echo – ein winziger ESP32-basierter Lautsprecher mit Mikrofon, ca. 13 Euro. Läuft mit ESPHome-Firmware, die direkt aus dem Browser geflasht wird. Wake-Word-Erkennung läuft auf dem Gerät, Audio wird an Home Assistant gestreamt. Die Audioqualität ist bescheiden, der Formfaktor genial. Wer Voice in mehreren Rämen ausprobieren will, ohne viel Geld auszugeben, beginnt hier.
  • Home Assistant Voice Preview Edition – die offizielle Voice-Hardware des Home-Assistant-Teams. Basiert auf einem XMOS XU316-Chip mit dedizierter Audio-Verarbeitung, besserem Mikrofon, Grove-Port für Sensoren, 3,5-mm-Klinkenanschluss für externe Lautsprecher. Kostet deutlich mehr als der Atom Echo, liefert aber auch spürbar bessere Erkennungsqualität. Ich habe beide ausprobiert – der Atom Echo ist ein guter Einstieg, die Voice PE ist die ernsthafte Alternative.
  • ESP32-S3-Box – eine weitere Option, die ESPHome unterstützt und etwas mehr Audio-Power bietet als der Atom Echo.
  • Rhasspy – eine eigenständige Open-Source-Sprachplattform, die nicht an Home Assistant gebunden ist. Läuft auf Raspberry Pi, kann aber auch mit Home Assistant gekoppelt werden. Wer nicht Home Assistant nutzt, aber trotzdem lokal sprechen will, findet hier eine Option.

Was funktioniert, was nicht:

Lokale Sprachsteuerung ist nicht Alexa. Die Wake-Word-Erkennung ist zuverlässig, solange das Wake-Word klar ist („Okay Nabu” funktioniert gut). Die Spracherkennung ist brauchbar für Standardbefehle („Schalte das Licht im Wohnzimmer an”, „Setze die Heizung auf 21 Grad”), stößt aber bei komplexen Sätzen oder Dialekt an Grenzen. Wer Alexa gewohnt ist, muss seine Erwartungen anpassen.

Aber – und das ist der entscheidende Punkt – kein Audiosignal verlässt das Haus. Keine Aufnahme wird gespeichert. Kein Profil wird gebildet. Keine Werbung wird ausgespielt. Die Sprachsteuerung gehört dem Nutzer, nicht dem Konzern.

Warum es egal ist, welches System man wählt

Hier kommt die eigentliche Aussage dieses Artikels: Es spielt keine Rolle, ob Home Assistant, ioBroker, FHEM oder openHAB.

Alle vier Systeme haben gemeinsam, was zählt:

  • Lokaler Betrieb – alle laufen auf eigener Hardware, ohne zwingende Cloud.
  • Offenheit – alle sind Open Source, alle können geprüft, angepasst und selbst gehostet werden.
  • Geräteintegration – alle unterstützen Zigbee, Z-Wave, MQTT, Homematic und die gängigen Protokolle.
  • Automatisierung – alle bieten ereignisbasierte Automatisierung, zeitgesteuerte Aktionen, Logik-Verknüpfungen.
  • Unabhängigkeit – alle funktionieren auch dann, wenn Amazon, Google oder Apple ihre Server abschalten.

Die Unterschiede liegen in der Philosophie, nicht im Ergebnis:

  • Home Assistant ist pragmatisch: schnell eingerichtet, viele Integrationen, große Community, moderne Oberfläche.
  • ioBroker ist technisch: JavaScript-basiert, datenpunktorientiert, für Entwickler gedacht.
  • FHEM ist traditionell: Perl-basiert, extrem stabil, für Homematic- und EnOcean-Nutzer eine Bank.
  • openHAB ist formell: Java-basiert, sauber strukturiert, für KNX und gewerbliche Protokolle stark.

Wer sich für eines entscheidet, entscheidet sich für eine Arbeitsweise, nicht für ein Prinzip. Das Prinzip ist bei allen gleich: lokale Kontrolle, offene Software, keine Cloud-Abhängigkeit.

Die philosophische Frage

Letztlich ist die Wahl der Plattform eine philosophische Frage. Sie beantwortet, wie man zur Technik steht:

  • Vertraue ich Cloud-Diensten, solange sie funktionieren? Dann reicht Alexa, Hue mit Bridge, Bosch Smart Home. Bequem, aber abhängig.
  • Will ich verstehen, was in meinem Haus passiert? Dann führt kein Weg an einer lokalen Plattform vorbei.
  • Will ich bereit sein, wenn der Stecker gezogen wird? Dann ist eine lokale Plattform die Konsequenz aus dem Was-wäre-wenn-Szenario.
  • Will ich Sprachsteuerung, ohne Daten preiszugeben? Dann ist Home Assistant mit lokalem Voice-Pipeline die Antwort.

Im Digitalen Manifest steht es so: „Technik soll uns dienen. Nicht wir ihr.” Auf das Smart Home übertragen heißt das: Die Plattform ist Werkzeug. Das Smart Home ist Mittel zum Zweck. Der Zweck ist ein Zuhause, das funktioniert, weil ich es verstehe und kontrolliere – nicht, weil ein Konzern es erlaubt.

Fazit

Es gibt nicht das eine richtige Smart-Home-System. Es gibt viele. Und genau das ist die gute Nachricht.

Wer heute beginnt, findet mit Home Assistant die ausgereifteste, einsteigerfreundlichste und am breitesten unterstützte Plattform. Wer programmieren kann und deutsche Dokumentation schätzt, findet in ioBroker einen mächtigen Baukasten. Wer Homematic hat und Stabilität über Komfort stellt, findet in FHEM einen verlässlichen Begleiter. Wer KNX oder gewerbliche Protokolle nutzt, findet in openHAB die passende Struktur.

Welche man auch wählt – am Ende steht ein Smart Home, das lokal läuft, das keine Daten an Konzerne sendet, das funktioniert, wenn das Internet ausfällt, und das vor allem eines ist: meins.

Die Frage ist nicht, ob man Alexa ersetzen kann. Die Frage ist, ob man es will. Und wenn ja: die Alternativen sind da. Sie sind ausgereift, sie sind offen, sie sind lokal. Man muss sie nur nutzen.

Quelle und Hinweis

Dieser Artikel ist der direkte Folgebeitrag zu Alexa & Co. – die stille Abhängigkeit im Wohnzimmer und knüpft an die dort skizzierten Alternativen an. Weitere Bezüge bestehen zum Was-wäre-wenn-Szenario und zum Digitalen Manifest.

Die beschriebenen Eigenschaften der Plattformen basieren auf den offiziellen Projektseiten, der aktuellen Dokumentation und eigenen Erfahrungen mit Home Assistant (inkl. M5Stack Atom Echo und Home Assistant Voice Preview Edition). Die Einordnung von ioBroker, FHEM und openHAB orientiert sich an den jeweiligen Projektbeschreibungen und Community-Diskussionen.

Quellen

Ähnliche Artikel