Home Assistant installieren: Schritt für Schritt

Warum das lokal läuft und nicht in einer Cloud

Die meisten Smart-Home-Geräte reden nicht mit deinem Haus, sondern mit einem Rechenzentrum ihres Herstellers. Das funktioniert, solange es den Hersteller gibt, solange er den Dienst betreibt und solange er die App weiter pflegt. Fällt eines davon weg, ist der Bewegungsmelder an der Wand ein Stück Plastik mit Batterie. Genau das ist in den letzten Jahren mehrfach passiert, und es trifft immer die, die am meisten investiert haben.

Home Assistant dreht die Richtung um: Die Logik liegt bei dir, die Geräte sprechen mit einem Rechner in deinem Netz, und die Herstellercloud ist bestenfalls eine von mehreren Anbindungen. Das Projekt gehört seit 2024 der gemeinnützigen Open Home Foundation, hat mehr als tausend Integrationen und erscheint monatlich in einer neuen Version. Die aktuelle heißt 2026.8.

Für Betriebe kommt ein Punkt dazu, der im privaten Umfeld nur bequem ist und geschäftlich zur Pflicht wird. Anwesenheitserkennung, Kameras im Lager, Zutritt zur Werkstatt: Das sind personenbezogene Daten, und sobald sie in einer Cloud außerhalb der EU landen, brauchst du dafür eine Rechtsgrundlage, einen Auftragsverarbeitungsvertrag und einen Eintrag im Verzeichnis der Verarbeitungstätigkeiten. Bleiben die Daten im Haus, ist die ganze Frage deutlich kleiner.

Vier Installationsarten, und warum nur noch zwei zur Wahl stehen

Fast jede Anleitung im Netz beschreibt vier gleichwertige Wege: OS, Container, Core und Supervised. Das war bis Ende 2025 richtig. Im Mai 2025 hat das Projekt Core und Supervised abgekündigt, mit einer Frist von sechs Monaten, und seit Release 2025.12 werden dafür weder Fehlerberichte angenommen noch Images gebaut. Gleichzeitig sind die 32-Bit-Architekturen i386, armhf und armv7 weggefallen, was einen Raspberry Pi 2 oder einen sehr alten Mini-PC endgültig ausschließt.

Der Unterschied zwischen den beiden verbliebenen Varianten ist eine einzige Schicht: der Supervisor. Er sitzt zwischen Betriebssystem und Home Assistant, verwaltet die Apps als eigene Container und macht die Ein-Klick-Updates sowie die vollständigen Backups möglich. Home Assistant OS bringt ihn mit, die Container-Variante hat ihn nicht. Deshalb fehlt dort der App-Store, und deshalb installierst du Mosquitto, Zigbee2MQTT oder ESPHome dort als eigene Container.

Wenn schon ein Docker-Host im Haus steht, ist das kein Nachteil, sondern Gewohnheit. Die offizielle Compose-Datei ist kurz, und zwei Zeilen darin sind nicht optional:

services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    restart: unless-stopped
    privileged: true
    # Ohne Host-Netzwerk sieht die Erkennung im LAN nichts: mDNS und SSDP
    # laufen über Multicast, und das überlebt keine Docker-Bridge.
    network_mode: host
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    environment:
      TZ: Europe/Berlin

Alle Schritte ab hier beschreiben Home Assistant OS, also den empfohlenen Weg. Für die Container-Variante entfallen die Abschnitte zum Image und zu den Apps, der Rest, also Onboarding, Netzwerk, Automatisierung und Fernzugriff, ist identisch.

Auf welcher Hardware

Home Assistant ist genügsam. Die entscheidende Frage ist nicht die Rechenleistung, sondern der Datenträger: Die Datenbank schreibt jeden Zustandswechsel jedes Geräts mit, und das bringt eine gewöhnliche SD-Karte nach ein bis zwei Jahren um. Ein Ausfall kündigt sich dabei nicht an, das System wird einfach langsam und startet eines Morgens nicht mehr.

Wenn du nicht basteln willst, hört die Entscheidung bei der ersten Zeile auf. Die Home Assistant Green kommt fertig installiert, hat den Speicher fest verbaut und kostet 179 Euro. Für alle anderen ist ein Raspberry Pi 5 mit NVMe-Aufsatz die Kombination mit dem besten Verhältnis aus Aufwand und Ruhe. Der Rest dieser Anleitung geht von einem Raspberry Pi aus, weil der Weg dort die meisten Schritte hat.

Eine Position, an der niemand sparen sollte, ist das Netzteil. Ein Raspberry Pi 5 zieht unter Last mehr, als ein Handy-Ladegerät liefert, und bei Unterspannung drosselt der Prozessor, während USB-Geräte einfach verschwinden. Die Fehlersuche führt dann stundenlang durch Logs, in denen nichts steht. Nimm das offizielle Netzteil, und häng den Datenträger nicht an den USB-Anschluss eines Monitors.

Schritt 1: Das Image auf die Karte schreiben

Der bequeme Weg ist der Raspberry Pi Imager von raspberrypi.com. Dort führt der Pfad über Betriebssystem wählen zu Other specific-purpose OS, dann Home automation, dann Home Assistant. Achte auf die Zeile für dein Modell: Pi 4 und Pi 5 haben getrennte Images, und das falsche bootet nicht.

Wer lieber sieht, was passiert, schreibt die Karte auf der Kommandozeile. Das hat den Vorteil, dass du die Prüfsumme vergleichen kannst, bevor du 20 Minuten auf einen Bootvorgang wartest, der an einem halben Download scheitert.

# Aktuelles Image für den Raspberry Pi 5 holen (HAOS 18.2)
curl -LO https://github.com/home-assistant/operating-system/releases/download/18.2/haos_rpi5-64-18.2.img.xz

# Prüfsumme gegen die Angabe auf der Release-Seite vergleichen
shasum -a 256 haos_rpi5-64-18.2.img.xz

# Zielgerät suchen. Alle anderen externen Datenträger vorher abziehen.
diskutil list
diskutil unmountDisk /dev/disk4

# rdisk statt disk: ungepuffert und dadurch um ein Vielfaches schneller.
# Fortschritt zeigt BSD-dd nur auf Ctrl-T, das ist normal.
xz -dc haos_rpi5-64-18.2.img.xz | sudo dd of=/dev/rdisk4 bs=4m
sync

curl -LO https://github.com/home-assistant/operating-system/releases/download/18.2/haos_rpi5-64-18.2.img.xz
sha256sum haos_rpi5-64-18.2.img.xz

# NAME, SIZE und MODEL zusammen lesen: die Größe ist die Kontrolle.
lsblk -o NAME,SIZE,MODEL

# conv=fsync sorgt dafür, dass dd erst zurückkehrt, wenn wirklich alles
# auf der Karte steht, und nicht schon im Schreibpuffer des Kernels.
xz -dc haos_rpi5-64-18.2.img.xz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync

Schritt 2: Erster Start und Onboarding

Karte einlegen, Netzwerkkabel in denselben Switch wie dein Rechner, Strom dran. Der erste Start richtet im Hintergrund das Dateisystem ein und lädt die Container nach. Auf einem Pi 5 ist die Oberfläche laut Dokumentation innerhalb einer Minute erreichbar, in der Praxis solltest du beim allerersten Mal ein paar Minuten mehr einplanen.

Aufgerufen wird sie unter homeassistant.local. Wer sich fragt, wo die gewohnte :8123 geblieben ist: Seit 2026.8 verwenden neue Installationen von Home Assistant OS den Standard-Port 80, damit man sich keine Portnummer mehr merken muss. Bestehende Installationen behalten ihren Port, und die Container-Variante bleibt ebenfalls auf 8123, weil dort typischerweise ein Reverse Proxy oder ein zweiter Dienst auf derselben Maschine sitzt.

Das Onboarding selbst sind vier Bildschirme. Zuerst legst du ein Konto an, und genau hier sitzt die Abzweigung, die man leicht übersieht: Statt Mein Smart Home erstellen kannst du hier ein Backup wiederherstellen. Das ist der offizielle Weg für einen Hardwarewechsel, und wer ihn kennt, zieht später von der SD-Karte auf eine SSD um, ohne irgendetwas neu einzurichten. Danach folgen der Standort, aus dem Zeitzone, Einheiten und Währung abgeleitet werden, und die Frage nach anonymen Nutzungsdaten, die standardmäßig aus ist.

Nach dem Klick auf Fertig landest du auf der neuen Übersicht, die seit 2026.2 die Standardansicht für alle neuen Installationen ist. Sie zeigt in einer eigenen Karte, welche Geräte im Netz gefunden wurden, und genau dort geht es weiter.

Schritt 3: Dauerhaft erreichbar bleiben

homeassistant.local ist eine mDNS-Adresse. Sie wird nicht von einem Server aufgelöst, sondern per Zuruf im lokalen Netz, und das funktioniert genau so lange, wie jedes beteiligte Gerät mitspielt. Ältere Android-Versionen tun es nicht zuverlässig, Gastnetze blocken Multicast, und über eine VLAN-Grenze hinweg kommt gar nichts an. Der Effekt ist immer derselbe: Auf deinem Rechner klappt es, auf dem Tablet in der Küche nicht.

Die Lösung liegt nicht in Home Assistant, sondern im Router. Trag dort eine DHCP-Reservierung für die MAC-Adresse deines Geräts ein. Home Assistant bekommt dann bei jedem Start dieselbe Adresse, ohne dass du im Gerät selbst eine feste IP konfigurierst. Das ist der ruhigere Weg: Eine statisch eingetragene Adresse, die eines Tages nicht mehr zum Netz passt, sperrt dich aus der Oberfläche aus, und dann brauchst du eine Tastatur am Gerät. Die Reservierung im Router lässt sich dagegen jederzeit von jedem anderen Rechner aus korrigieren.

Wenn du den Port ändern willst oder musst, geht das seit 2026.8 unter Einstellungen, System, Netzwerk. Der Umweg über die configuration.yaml ist dafür nicht mehr nötig, und die Sicherung dahinter ist praktisch: Eine Änderung, die dich aussperren würde, wird nach fünf Minuten ohne Bestätigung zurückgenommen.

Schritt 4: Die ersten Geräte, und der Unterschied zwischen Integration und App

Zwei Begriffe in der Oberfläche klingen ähnlich und meinen etwas völlig anderes. Eine Integration ist die Verbindung zu einem Gerät oder Dienst: dein Wechselrichter, deine Lampen, der Kalender. Eine App ist ein eigenständiges Programm, das neben Home Assistant läuft, etwa ein MQTT-Broker oder ein Dateimanager. Bis Anfang 2026 hießen die Apps „Add-ons", und weil neue Nutzer regelmäßig das eine installierten, wenn sie das andere brauchten, wurden sie mit Release 2026.2 in Apps umbenannt. Technisch hat sich dabei nichts geändert, es sind weiterhin Container unter dem Supervisor.

Die meisten Integrationen findest du gar nicht selbst, sie melden sich. Was nicht von allein auftaucht, fügst du unter Einstellungen, Geräte und Dienste hinzu. Bevor du das im großen Stil machst, lohnen zwei Minuten für die Räume: Ein Gerät ohne Raum ist später in jeder Automatisierung und in jedem Sprachbefehl eine Extrazeile.

Für Zigbee oder Z-Wave brauchst du einen Funkstick am USB-Anschluss. Der ist die häufigste Quelle für Fehler, die erst Wochen später auffallen.

Schritt 5: Die erste Automatisierung

Automatisierungen bestehen aus drei Teilen: Auslöser, Bedingungen und Aktionen. Der grafische Editor unter Einstellungen, Automatisierungen und Szenen deckt inzwischen fast alles ab, und jede damit gebaute Automatisierung lässt sich über das Menü oben rechts als YAML ansehen und bearbeiten. Genau dieses YAML kannst du auch einfügen, und deshalb steht es hier:

alias: Hoflicht bei Bewegung, aber nur wenn es dunkel ist
description: >-
  Schaltet das Licht am Hoftor ein, sobald der Melder auslöst und die Sonne
  unter dem Horizont steht. Aus geht es erst nach drei ruhigen Minuten.
mode: restart

triggers:
  - trigger: state
    entity_id: binary_sensor.hoftor_bewegung
    to: "on"

conditions:
  - condition: sun
    after: sunset
    before: sunrise

actions:
  - action: light.turn_on
    target:
      entity_id: light.hoftor
    data:
      brightness_pct: 80

  # Auf Ruhe warten statt blind drei Minuten zählen. Ohne timeout würde
  # die Automatisierung hängen bleiben, falls der Melder ausfällt.
  - wait_for_trigger:
      - trigger: state
        entity_id: binary_sensor.hoftor_bewegung
        to: "off"
        for: "00:03:00"
    timeout: "00:30:00"

  - action: light.turn_off
    target:
      entity_id: light.hoftor

Drei Zeilen darin sind wichtiger, als sie aussehen. mode: restart legt fest, was passiert, wenn die Automatisierung erneut auslöst, während sie noch läuft. Die Voreinstellung ist single: Der zweite Auslöser wird verworfen und landet nur als Warnung im Protokoll. Bei einem Bewegungsmelder heißt das, dass das Licht nach der ersten Bewegung ausgeht, obwohl jemand im Raum steht. Genau dieser Fehler steckt in den meisten „das funktioniert manchmal nicht"-Berichten.

Der zweite Punkt ist wait_for_trigger statt einer festen Wartezeit. Die Automatisierung wartet damit auf drei ruhige Minuten und nicht auf drei Minuten ab Start, was den Unterschied zwischen einem Licht macht, das ausgeht, während du noch am Auto stehst, und einem, das dir folgt. Der timeout daneben ist die Notbremse: Ohne ihn wartet die Automatisierung im Zweifel für immer, etwa wenn der Melder ausfällt und nie wieder auf off geht.

Zum Ausprobieren: Unter Tools (bis 2026.8 hieß der Bereich „Entwicklerwerkzeuge") kannst du im Reiter Zustände jede Entität von Hand auf einen Wert setzen und so den Auslöser simulieren, ohne durch den Hof zu laufen. Und wenn eine Automatisierung nicht tut, was sie soll, zeigt die Ablaufverfolgung im Automatisierungs-Editor Schritt für Schritt, an welcher Bedingung sie ausgestiegen ist.

Schritt 6: Backups, und der Schlüssel, ohne den sie wertlos sind

Home Assistant sichert seit den Neuerungen von 2025 automatisch, und die Voreinstellungen sind brauchbar: ein Zeitplan, ein Aufbewahrungszeitraum und auf Wunsch ein zusätzliches Backup vor jedem Update. Ein vollständiges Backup enthält config, share, die manuell installierten Apps, ssl und media. Die beiden letzten kannst du abwählen, wenn du Kamerabilder speicherst, sonst wächst das Archiv ins Absurde und eine Wiederherstellung dauert entsprechend.

Zwei Dinge daran sind keine Einstellungssache, sondern der Unterschied zwischen einem Backup und einer Illusion. Erstens: Alle Backups sind verschlüsselt, und der Schlüssel steht im Notfall-Kit, das dir beim Einrichten einmal zum Download angeboten wird. Wer es wegklickt, hat später ein Archiv, das sich nicht öffnen lässt. Zweitens: Ein Backup, das auf demselben Datenträger liegt wie das System, übersteht genau die Fälle nicht, für die es gedacht ist. Als Ziel taugen ein Netzwerkspeicher, Google Drive, OneDrive oder Home Assistant Cloud, das dafür 5 GB verschlüsselten Speicher mitbringt.

Vor jedem größeren Eingriff, und dazu gehört auch das Umziehen auf neue Hardware, ist ein Backup von Hand schneller getippt als geklickt:

# Backup von Hand, mit sprechendem Namen
ha backups new --name "vor-umzug-auf-ssd"

# Vorhandene Backups auflisten, inklusive Slug für die Wiederherstellung
ha backups list

# Zustand des Systems, bevor man ein Update anstößt
ha core info

Fernzugriff, ohne den Router aufzureißen

Irgendwann willst du von unterwegs sehen, ob das Garagentor zu ist. Der naheliegende Weg ist eine Portweiterleitung im Router, und der ist der einzige, der hier nicht zur Debatte steht. Ein offener Web-Port stellt eine Oberfläche ins Netz, hinter der Kameras, Türschlösser und Anwesenheitsdaten liegen, und der einzige Schutz ist ein Passwort. Es gibt drei bessere Optionen, und alle drei sind an einem Abend eingerichtet.

Home Assistant Cloud von Nabu Casa kostet 7,50 Euro im Monat oder 75 Euro im Jahr, braucht keine Konfiguration und finanziert nebenbei die Entwicklung des Projekts. Ein VPN, entweder als WireGuard im Router oder als App auf dem Gerät, ist kostenlos und technisch die sauberste Variante, verlangt aber eine erreichbare Adresse von außen. Ein Reverse Proxy mit eigenem Zertifikat lohnt sich, wenn ohnehin weitere Dienste im Haus laufen.

Beim Reverse Proxy gibt es eine Stelle, an der jeder einmal hängenbleibt: Home Assistant lehnt weitergeleitete Anfragen ab, solange der Proxy nicht ausdrücklich als vertrauenswürdig eingetragen ist. Im Protokoll steht dann eine Zeile über einen X-Forwarded-For-Header von einem nicht vertrauenswürdigen Proxy, und im Browser eine leere Seite.

http:
  use_x_forwarded_for: true
  trusted_proxies:
    # Das interne Netz der Home-Assistant-Apps, etwa Nginx Proxy Manager
    - 172.30.33.0/24
    # Oder ein Proxy auf einem eigenen Rechner im LAN
    - 192.168.1.10

Aus der Praxis: Home Assistant als MCP-Server

Der Teil, der Betriebe inzwischen häufiger interessiert als das Licht im Flur: Home Assistant bringt eine Integration mit, die die eigene Installation als MCP-Server bereitstellt. Damit kann ein Sprachmodell den Zustand des Hauses lesen und Geräte schalten, über dasselbe Protokoll, mit dem du auch eigene Werkzeuge anbindest.

{
  "mcpServers": {
    "Home Assistant": {
      "command": "mcp-proxy",
      "args": [
        "--transport=streamablehttp",
        "--stateless",
        "http://homeassistant.local/api/mcp"
      ],
      "env": {
        "API_ACCESS_TOKEN": "LANGZEIT-TOKEN-AUS-DEM-PROFIL"
      }
    }
  }
}

Der wichtige Teil steht nicht in der Konfiguration, sondern eine Ebene tiefer: Das Modell sieht ausschließlich die Entitäten, die du unter Sprachassistenten ausdrücklich freigegeben hast. Das ist kein Komfortschalter, sondern die eigentliche Berechtigungsgrenze. Gib die Lampen frei, nicht das Türschloss, und schon gar nicht die Alarmanlage.

Wie ein solcher Server von innen aussieht und wie du eigene Werkzeuge daneben stellst, steht in unserem Beitrag MCP-Server selbst bauen. Und wer das Sprachmodell dazu ebenfalls im Haus betreiben will, findet die Rechnung dafür in Was ein lokaler KI-Server wirklich kostet: Für Sprachsteuerung reicht deutlich weniger Hardware, als die meisten annehmen.

Fazit

Die Installation selbst ist eine Viertelstunde. Was den Unterschied macht, sind die Entscheidungen davor, also OS statt Container, SSD statt SD-Karte, Reservierung statt Zufallsadresse, und die drei Handgriffe danach, die kaum jemand macht: Notfall-Kit sichern, Backup auf ein zweites Gerät legen, den Funkstick ans Verlängerungskabel hängen.

Wenn du weitermachen willst, in dieser Reihenfolge: erst alle vorhandenen Geräte einbinden und Räume sauber vergeben, weil darauf alles Weitere aufbaut. Dann die drei Automatisierungen bauen, über die du dich täglich ärgerst, und keine vierzig auf Vorrat. Und erst danach Dashboards, Sprache und alles, was hübsch ist.

• Offizielle Installationsübersicht
• Abkündigung von Core, Supervised und 32 Bit
• Release Notes zu Home Assistant 2026.8
• Dokumentation der MCP-Server-Integration

Häufige Fragen