Home Assistant Apps: So erweiterst du dein Smart Home sinnvoll

Home Assistant wird nicht besser, weil immer mehr Apps installiert sind. Es wird besser, wenn eine konkrete Reibung verschwindet: Das Licht im Flur geht zuverlässig an, ein Fenster bleibt nicht unbemerkt offen, die Heizung läuft nicht für eine leere Wohnung.

Der häufigste Anfängerfehler ist deshalb keine falsche YAML-Zeile. Es ist die Reihenfolge. Erst werden Add-ons gesammelt, dann ein überladenes Dashboard gebaut und irgendwann festgestellt, dass weder Sicherung noch klare Zuständigkeiten existieren. Das lässt sich vermeiden.

Diese Strecke funktioniert für ein neues wie für ein gewachsenes System: zuerst eine kleine Automation, dann die passende Erweiterung, danach ein Dashboard, Benachrichtigungen und zuletzt ein belastbares Backup. Nicht umgekehrt.

Weiterführende Home-Assistant-Guides

1. Erst eine Automation, die im Alltag zählt

Starte nicht mit einer Liste von Add-ons. Starte mit einem Auslöser, den du täglich bemerkst. Ein guter erster Ablauf besteht aus einem klaren Signal, einer eindeutigen Bedingung und einer sichtbaren Aktion:

Bewegungsmelder im Flur meldet Bewegung.
Es ist dunkel genug.
Das Flurlicht schaltet ein und nach kurzer Zeit wieder aus.

Das ist klein genug, um es zu verstehen, und groß genug, um Fehler zu sehen. Wenn das Licht zu früh ausgeht, ist nicht „Home Assistant kaputt“. Dann fehlt wahrscheinlich eine saubere Präsenzlogik, die Nachlaufzeit ist zu knapp oder der Sensor sitzt falsch. Genau diese Rückmeldung brauchst du, bevor du zehn weitere Abläufe anlegst.

Nutze dafür zunächst die eingebaute Automationsoberfläche. Sie zeigt Trigger, Bedingungen und Aktionen getrennt. YAML ist sinnvoll, wenn du eine Konfiguration gezielt versionieren oder einen bereits verstandenen Ablauf präzise pflegen willst. Es ist kein Reifeabzeichen.

Eine praktische Regel: Eine Automation soll einen Satz als Zweck haben. „Flurlicht bei Bewegung im Dunkeln“ ist überprüfbar. „Intelligente Komfortsteuerung“ ist es nicht. Gib dem Ablauf einen Namen, prüfe den Trace nach dem ersten Auslösen und ändere nur einen Parameter pro Versuch. So erkennst du Ursache und Wirkung, statt mehrere Vermutungen gleichzeitig zu testen.

Erst wenn dieser Ablauf im Alltag funktioniert, ist die Frage nach Apps und Add-ons sinnvoll. Sie sind Werkzeuge für einen Bedarf, nicht Dekoration für die Seitenleiste.

2. Apps und Add-ons nach Bedarf auswählen

Home Assistant OS verwaltet Apps – die frühere Bezeichnung lautete Add-ons – über den App Store. Die offizielle Dokumentation unterscheidet dabei klar zwischen den mitgelieferten Repositories und Anwendungen, die Zugriff auf freigegebene Verzeichnisse erhalten.[1] Das ist der richtige Maßstab: Installiere nur, was eine Aufgabe übernimmt, die Home Assistant allein nicht sauber erledigt.

File Editor und Terminal & SSH: zwei Werkzeuge, zwei Grenzen

Der File Editor ist der richtige Einstieg, wenn du gezielt Dateien unter /config bearbeiten musst. Er ist ein einfacher Browser-Dateimanager mit Texteditor und prüft YAML beim Editieren auf Syntaxfehler.[1] Das macht ihn nützlich für nachvollziehbare Änderungen an Konfigurationen, Skripten oder kleinen Include-Dateien.

Er ist nicht die Einladung, wahllos an Systemdateien zu arbeiten. Die Option, das Basisverzeichnis zu verlassen, ist laut Home Assistant ausdrücklich ein Schutz gegen versehentliche Änderungen.[1] Lass sie aktiv, solange du keinen konkreten Grund hast. Für größere Konfigurationsbestände ist ein Editor am eigenen Rechner über eine kontrollierte Freigabe oft angenehmer; Home Assistant OS beschreibt dafür die Samba-App und die erreichbaren Standardordner.[1]

Terminal & SSH ist kein „Admin-Modus für alles“. Die App stellt ein Web-Terminal, die Home-Assistant-CLI und optionalen SSH-Zugang bereit, aber keinen direkten Zugriff auf das zugrunde liegende Host-Dateisystem.[1] Das ist eine wichtige Grenze. Nutze sie für Logs, den Status von Core oder Apps und die dokumentierten ha-Befehle. Installiere nicht auf Verdacht Pakete, ändere keine Container von Hand und kopiere keine Befehle aus Foren, deren Wirkung du nicht verstehst. Ein System, das nur noch über improvisierte Shell-Eingriffe läuft, ist schwer wiederherzustellen.

ZHA oder Zigbee2MQTT: nicht „besser“, sondern passend

Für Zigbee brauchst du einen Coordinator und ein stabiles Mesh. Ein Gerät kann nur in einem Zigbee-Netz hängen; der Wechsel zwischen ZHA und Zigbee2MQTT ist daher ein Migrationsprojekt, kein Schalter im Menü.[9]

ZHA ist die integrierte Home-Assistant-Variante. Sie bindet kompatible Zigbee-Geräte direkt über einen Coordinator an Home Assistant an und erzeugt bei der Einrichtung ein Zigbee-Netz.[9] Das ist die schlanke Wahl, wenn du möglichst wenig zusätzliche Komponenten pflegen willst. Für ein überschaubares Zuhause ist „weniger bewegliche Teile“ oft der beste Grund.

Zigbee2MQTT ist sinnvoll, wenn du bewusst dessen Geräte-Datenbank, Weboberfläche und MQTT-basierte Architektur nutzen willst. Es benötigt neben Adapter, Host und Zigbee-Geräten auch einen MQTT-Broker; die eigene Einstiegshilfe nennt Mosquitto als empfohlene Broker-Option.[4] Vor der Installation prüfst du deshalb den konkreten Adapter, seinen Pfad und die empfohlene Konfiguration. Ein USB-Verlängerungskabel kann bei Pairing-Problemen und Aussetzern helfen, weil es den Funkadapter von Störquellen entfernt.[4]

Die Entscheidung sollte früh fallen. Wer bereits ein stabiles ZHA-Netz mit vielen Geräten hat, gewinnt durch einen Wechsel nicht automatisch etwas. Wer ein neues Netz plant und die MQTT-Schicht bewusst einsetzen will, kann Zigbee2MQTT sauber von Anfang an aufsetzen. In beiden Fällen gilt: Netzbetriebene Zigbee-Geräte können als Router das Mesh erweitern; batteriebetriebene Endgeräte tun das nicht.[9]

ESPHome: für eigene Hardware, nicht als Ersatz für jede Integration

ESPHome ist dann stark, wenn ein fertiger Sensor oder Aktor nicht passt: ein eigener Temperaturfühler, ein Taster an einer bestehenden Leitung, ein Display oder ein Bluetooth-Proxy. Du beschreibst Komponenten in YAML; ESPHome baut daraus Firmware für den Mikrocontroller. Nach dem Flashen kann das Gerät per nativer ESPHome-API direkt mit Home Assistant sprechen.[10]

Die Grenze ist materiell, nicht softwareseitig: Ein ESP braucht Strom, Netzwerk, passende Pins, ein Gehäuse und eine sichere Verdrahtung. Bei Netzspannung endet das Bastelprojekt; dort gehören zugelassene Komponenten und fachgerechter Einbau hin. Außerdem verändert „Speichern“ in ESPHome kein Gerät: Erst ein Installationsvorgang kompiliert und überträgt die Firmware.[6]

Für das erste Projekt nimm etwas Harmloses und prüfbares, etwa einen batterielosen Raumtemperatursensor oder einen Taster. Die erste Installation erfolgt üblicherweise per USB, spätere Updates können per WLAN erfolgen.[6] Dokumentiere Gerätenamen und Einsatzort. Eine Kiste identischer ESP-Boards ohne eindeutige Namen wird später zur Fehlersuche.

Frigate: erst Kameras und Rechenweg klären

Frigate ist kein Add-on, das eine schlechte Kamera oder eine schwache Plattform wegzaubert. Die Hardware-Dokumentation empfiehlt Kameras mit H.264-Video und AAC-Audio für breite Kompatibilität; mehrere Substreams helfen, Aufnahme, Livebild und Erkennung mit unterschiedlichen Auflösungen zu betreiben.[5] WLAN-Kameras werden dort wegen weniger zuverlässiger Streams ausdrücklich nicht empfohlen, besonders wenn mehrere parallel laufen.[5]

Plane Frigate daher von der Kamera her: stabiler Stream, sinnvoller Bildausschnitt, Speicherstrategie und eine Rechenplattform, die Video-Decoding und Erkennung tragen kann. Für die Objekterkennung unterstützt Frigate verschiedene Detektoren, unter anderem Hailo, OpenVINO auf Intel-Hardware, Nvidia-GPUs und Google Coral.[5] Coral bleibt unterstützt, wird laut Frigate aber für neue Installationen grundsätzlich nicht mehr empfohlen, außer bei bestimmten Niedrigenergie- oder Hardware-Szenarien.[5]

Wichtig für bestehende Anleitungen: Baue keine neue Frigate-Automation auf dem alten MQTT-Event-Topic auf. Nutze die aktuelle Home-Assistant-Integration und deren bereitgestellte Entitäten oder Ereignisse, statt ein historisches MQTT-Beispiel blind zu übernehmen. Teste danach an der realen Kamera: Erkennt die Zone tatsächlich eine Person, löst sie nicht bei jedem Schatten aus und kommt die Meldung nicht mehrfach für dasselbe Ereignis? Erst dann ist eine Push-Benachrichtigung sinnvoll.

Node-RED und lokale Assist-Dienste: nur bei echter Komplexität

Node-RED ist eine flowbasierte Programmierumgebung mit Browser-Editor. Das Home-Assistant-Community-App-Projekt beschreibt das Prinzip als Verdrahtung von Geräten, APIs und Diensten über Nodes.[7] Das hilft bei verzweigten, gut zu visualisierenden Abläufen. Es ersetzt aber nicht die Planung: Ein unklarer Ablauf wird als buntes Node-RED-Diagramm nur schwerer zu warten.

Bleib bei Home-Assistant-Automationen, solange Ablauf, Bedingung und Aktion klar bleiben. Nimm Node-RED erst bei wiederkehrenden Verzweigungen, umfangreichem Fehlerpfad oder einer Logik, die du im Flow wirklich besser lesen kannst. Sichere dann auch die Flows und halte Zugangsdaten außerhalb exportierter Beispiele.

Lokale Sprachsteuerung mit Assist und Wyoming-Diensten ist ebenfalls kein Pflichtprogramm. Eine vollständig lokale Pipeline verarbeitet Mikrofon, Spracherkennung, Assist und Sprachausgabe auf eigener Hardware.[8] Speech-to-Phrase ist für einen begrenzten Satz an Haussteuerungsbefehlen sehr schnell; offene Aufgaben wie Einkaufslisten oder frei benannte Timer funktionieren damit nicht automatisch.[8] Whisper versteht offener, braucht aber deutlich mehr Rechenleistung: Die offizielle Anleitung nennt auf einem Raspberry Pi 4 ungefähr acht Sekunden für einen Befehl und auf einem Intel NUC unter einer Sekunde.[8] Piper ist die lokale Sprachausgabe.

Das ist gut für „Licht im Wohnzimmer an“ und vergleichbare Steuerung. Es ist kein lokaler Gesprächsassistent mit garantierter freier Sprache. Wenn die Hardware oder der Raum zu laut ist, wird die Grenze hörbar. Teste erst mit einem Handy als Eingabe, dann mit einem festen Sprachgerät.

home-assistant-apps-2026-beste-addons-einsteiger

3. Danach ein schlankes Dashboard bauen

Ein Dashboard ist eine Arbeitsfläche, keine Gerätesammlung. Wenn du beim Öffnen zwanzig Zustände siehst, aber die eine wichtige Handlung suchen musst, ist es zu voll.

Baue zuerst eine Startansicht für häufige Entscheidungen:

Licht und Beschattung der aktuellen Bereiche.
Temperaturen, offene Fenster und relevante Warnungen.
Eine klar benannte Szene für einen wiederkehrenden Zustand wie „Gute Nacht“.
Nur die Kameras, die du wirklich regelmäßig ansiehst.

Alles andere darf auf eine zweite Ansicht: Energie, Geräteverwaltung, Historie, Debugging. Das trennt Bedienung von Beobachtung. Ein Dashboard muss nicht jede Entität zeigen, um vollständig zu sein.

Gib Entitäten verständliche Namen und ordne sie Räumen zu, bevor du Karten verschiebst. „Temperatur Wohnen“ ist hilfreicher als ein technischer Gerätename. Vermeide Karten-Collections als Standardantwort auf jedes Layoutproblem. Die eingebauten Karten reichen weit, wenn die Daten und Namen sauber sind.

Prüfe die Ansicht auf dem Smartphone. Dort entscheidet sich, ob sie funktioniert: große Schalter für sofortige Aktionen, Zahlen nur dort, wo eine Zahl eine Entscheidung auslöst, und keine Seite, die horizontalen oder endlosen vertikalen Suchaufwand erzeugt.

4. Companion-Benachrichtigungen gezielt einsetzen

Die Companion-App macht das Smartphone zu mehr als einer Fernbedienung. Sie kann zusätzliche Sensoren bereitstellen, etwa Akku, Ladezustand, WLAN-Name und – je nach Plattform und Freigaben – weitere Gerätesignale.[3] Auf Android sind viele Sensoren nicht standardmäßig aktiv und müssen in der App gezielt eingeschaltet werden; die Aktualisierung hängt zudem von Betriebssystem und gewählter Frequenz ab.[3]

Das ist kein Argument, alles zu aktivieren. Jeder Sensor ist eine Datenschutz- und Wartungsentscheidung. Aktiviere nur Daten, die eine konkrete Automation brauchen. Ein gutes Beispiel: Eine Warnung, wenn du das Haus verlässt und ein Fenster offen bleibt. Schlechte Beispiele sind Dauerbenachrichtigungen über gewöhnliche Temperaturänderungen oder jede erkannte Bewegung.

Eine Benachrichtigung muss drei Fragen beantworten: Was ist passiert? Wo? Was soll ich jetzt tun? „Fenster im Arbeitszimmer offen, obwohl niemand zuhause ist“ ist brauchbar. „Binary sensor changed“ nicht.

Nutze zuerst eine einzelne Testmeldung aus der Automationsoberfläche. Prüfe Empfang bei gesperrtem Telefon, die richtige Zielperson und die Uhrzeit. Bei Kameraereignissen testest du zusätzlich, ob ein Vorschaubild oder ein Link tatsächlich erreichbar ist. Danach legst du eine Drosselung an: Ein reales Ereignis darf nicht zehn Meldungen erzeugen.

5. Automatische Backups einrichten – und den Restore testen

Backups sind der Punkt, an dem ein Bastelprojekt zu einem betreibbaren System wird. Die Backup-Integration kann Sicherungen für alle Installationsarten erstellen und wiederherstellen. Automatische Backups lassen sich in der Oberfläche konfigurieren; dafür musst du keine eigene Automation bauen.[2]

Die wichtige Unterscheidung: Ein erfolgreich angelegtes lokales Backup ist noch keine Wiederherstellungsstrategie. Home Assistant empfiehlt vor OS-Updates ein Backup außerhalb des Geräts, auf dem die Installation läuft, damit eine Wiederherstellung bei Problemen möglich bleibt.[1] Lege deshalb eine externe Backup-Location fest und prüfe, ob aktuelle Sicherungen dort wirklich ankommen.

Ein belastbarer Minimalplan sieht so aus:

Automatische Sicherung in der Oberfläche aktivieren.
Eine externe Backup-Location konfigurieren.
Eine Meldung auslösen, wenn das Backup-Ereignis fehlschlägt; die Integration stellt dafür Status und Fehlergrund bereit.[2]
Vor größeren Änderungen zusätzlich manuell sichern.
Einen Restore-Test durchführen.

Der Restore-Test ist kein theoretischer Schritt. Nimm ein frisches Backup und stelle es auf einer getrennten Testinstallation oder einer kontrollierten Ersatzumgebung wieder her. Prüfe danach mindestens: Home Assistant startet, zentrale Integrationen laden, eine bekannte Automation erscheint, und deine wichtigen Dashboards sind vorhanden. Notiere außerdem, wo Backup, Zugang zur Installation und die Wiederherstellungsanleitung liegen. Ein Backup, das nur existiert, aber niemand findet oder entschlüsseln kann, hilft im Ernstfall nicht.

Die sinnvolle Reihenfolge bleibt klein

Du brauchst keine Liste vermeintlicher Pflicht-Apps. Du brauchst einen nächsten, überprüfbaren Nutzen.

Baue eine Automation, die eine reale Routine verbessert.
Installiere Erweiterungen nur für den nächsten Bedarf: Dateieditor, Zigbee-Stack, ESPHome, Kameraanalyse, Flows oder Sprache.
Reduziere das Dashboard auf Entscheidungen.
Nutze die Companion-App für wenige, handlungsfähige Hinweise.
Automatisiere Backups und beweise mit einem Restore-Test, dass sie ihren Namen verdienen.

Damit wächst Home Assistant langsamer als eine Sammlung von Add-ons. Aber es bleibt verständlich. Und genau das macht es langfristig nützlich.