Begriffe & Glossar

Home Assistant verwendet einige spezifische Begriffe. Hier findest du 42 Begriffe mit einer kurzen Definition, einer ausführlichen Erklärung und einem praktischen Beispiel.

Grundlagen

Entity

Ein einzelner Datenpunkt eines Geräts.

Jedes Gerät erzeugt eine oder mehrere Entities. Eine Entity hat eine eindeutige ID (z.B. light.wohnzimmer_decke), einen aktuellen Zustand (State) und optionale Attribute. Entities sind die Grundbausteine, die du im Dashboard anzeigst und in Automationen verwendest.

Beispiel: light.wohnzimmer_decke — State: 'on', Attribute: brightness=200, color_temp=350

State

Der aktuelle Zustand einer Entity.

Jede Entity hat genau einen State — z.B. 'on', 'off', '23.5', 'home'. States ändern sich, wenn das Gerät seinen Zustand ändert. State-Änderungen können Automationen auslösen. Ein State kann auch 'unavailable' (nicht erreichbar) oder 'unknown' sein.

Beispiel: sensor.aussentemperatur hat den State '18.3' (°C). binary_sensor.haustuer hat den State 'on' (= offen).

Attribute

Zusätzliche Eigenschaften einer Entity neben dem State.

Attribute enthalten Details, die über den Hauptzustand hinausgehen. Ein Licht hat z.B. den State 'on', aber Attribute wie brightness, color_temp und rgb_color. Attribute können in Templates und Automationen abgefragt werden.

Beispiel: light.wohnzimmer: State='on', Attribute: brightness=200, color_temp=350, friendly_name='Wohnzimmer Licht'

Service

Eine Aktion, die Home Assistant ausführen kann.

Services sind Befehle, die du an Entities senden kannst. Zum Beispiel 'light.turn_on', 'switch.toggle' oder 'climate.set_temperature'. Du verwendest sie in Automationen und Scripts. Jeder Service akzeptiert bestimmte Parameter (data).

Beispiel: Service: light.turn_on → target: entity_id: light.flur → data: brightness_pct: 80

Domain

Die Kategorie einer Entity (z.B. light, sensor, switch).

Jede Entity gehört zu einer Domain, die den Typ beschreibt: light., sensor., switch., binary_sensor., climate., cover., etc. Die Domain bestimmt, welche Services verfügbar sind und wie die Entity im Dashboard dargestellt wird.

Beispiel: light.wohnzimmer (Domain: light), sensor.temperatur (Domain: sensor), cover.rollladen (Domain: cover)

Integration

Ein Plugin, das HA mit einem Gerät oder Dienst verbindet.

Integrationen sind die Brücke zwischen Home Assistant und der Außenwelt. Es gibt über 2.800 offizielle Integrationen — von Philips Hue über Fritzbox bis zu Wetterdiensten. Jede Integration erstellt Entities für die angebundenen Geräte. Sie können per UI oder YAML konfiguriert werden.

Beispiel: Die Shelly-Integration findet alle Shelly-Geräte im Netzwerk und erstellt für jedes Schalter- und Sensor-Entities.

Device (Gerät)

Ein physisches oder virtuelles Gerät.

Ein Device gruppiert mehrere zusammengehörige Entities. Zum Beispiel erzeugt ein Shelly Plug ein Device mit Schalter-, Leistungs- und Temperatur-Entities. Devices können Areas (Räumen) zugeordnet werden.

Beispiel: Device: Shelly Plug Wohnzimmer → Entities: switch.shelly_plug, sensor.shelly_plug_power, sensor.shelly_plug_temp

Area (Bereich)

Ein logischer Raum in deinem Zuhause.

Areas helfen dir, Geräte nach Standort zu organisieren. Du erstellst Bereiche wie 'Wohnzimmer', 'Küche', 'Garten' und weist Geräte zu. Das Dashboard und Sprachassistenten nutzen diese Zuordnung. Du kannst auch ganze Areas als Ziel in Services nutzen.

Beispiel: Area 'Bad' enthält: Licht Bad, Heizung Bad, Bewegungsmelder Bad. Service: light.turn_off → target: area_id: bad

Automationen

Automation

Eine Regel, die automatisch Aktionen ausführt.

Automationen bestehen aus drei Teilen: Trigger (Auslöser), Condition (Bedingung, optional) und Action (Aktion). Wenn der Trigger ausgelöst wird UND die Conditions erfüllt sind, werden die Actions ausgeführt. Automationen können per UI oder YAML erstellt werden.

Beispiel: Trigger: Bewegungsmelder erkennt Bewegung → Condition: Es ist nach 18 Uhr → Action: Licht einschalten

Trigger

Der Auslöser einer Automation.

Trigger definieren, WANN eine Automation starten soll. Es gibt viele Trigger-Typen: State-Änderung, Uhrzeit, Sonnenaufgang, Webhook, Geofencing, Template, MQTT, NFC-Tag und mehr. Eine Automation kann mehrere Trigger haben — jeder einzelne kann sie auslösen.

Beispiel: Trigger: State von binary_sensor.haustuer ändert sich auf 'on' (= Tür wurde geöffnet)

Condition

Eine Bedingung, die erfüllt sein muss.

Conditions prüfen, OB die Automation weiterlaufen soll, nachdem der Trigger ausgelöst wurde. Sie sind optional. Wenn eine Condition nicht erfüllt ist, wird die Aktion nicht ausgeführt. Conditions können mit AND, OR, NOT verknüpft werden.

Beispiel: Condition: sun.sun ist 'below_horizon' (= Es ist dunkel) AND time.weekday ist mon-fri

Action

Die Aktion, die eine Automation ausführt.

Actions definieren, WAS passieren soll. Du kannst Services aufrufen, Benachrichtigungen senden, Verzögerungen einbauen, Szenen aktivieren, choose-Blöcke für Verzweigungen nutzen und vieles mehr. Mehrere Actions werden nacheinander ausgeführt.

Beispiel: Action: light.turn_on für light.flur mit brightness: 200, dann delay: 5 Minuten, dann light.turn_off

Szene

Ein gespeicherter Zustand mehrerer Entities.

Eine Szene speichert, wie mehrere Geräte eingestellt sein sollen. Beim Aktivieren werden alle Geräte gleichzeitig auf die gespeicherten Werte gesetzt. Anders als Automationen reagieren Szenen nicht automatisch — sie werden manuell oder durch eine Automation aktiviert.

Beispiel: Szene 'Filmabend': Wohnzimmer-Licht auf 20%, TV an, Rollläden runter

Script

Eine wiederverwendbare Abfolge von Aktionen.

Scripts sind wie Automationen, aber ohne Trigger. Du definierst eine Reihe von Aktionen und kannst das Script dann manuell, aus Automationen oder per Dashboard-Button aufrufen. Scripts können Parameter (fields) akzeptieren.

Beispiel: Script 'Morgenroutine': Licht im Bad an → Kaffeemaschine einschalten → Radio starten

Blueprint

Eine vorgefertigte Automations-Vorlage.

Blueprints sind Vorlagen, die du importieren und an deine Geräte anpassen kannst. Du musst keine Automation von Null schreiben — wähle einen Blueprint, fülle die Felder aus, fertig. Der Blueprint Exchange bietet hunderte Community-Vorlagen.

Beispiel: Blueprint 'Licht bei Bewegung': Du wählst nur deinen Bewegungsmelder und dein Licht — die Logik ist bereits definiert.

Mode (Automation)

Bestimmt Verhalten bei mehrfacher Auslösung.

Der Mode legt fest, was passiert wenn eine Automation ausgelöst wird, während sie noch läuft: single (ignorieren), restart (neu starten), queued (warten), parallel (gleichzeitig). Für Bewegungslichter ist 'restart' ideal.

Beispiel: mode: restart → Jede neue Bewegung setzt den Ausschalt-Timer zurück, statt eine zweite Instanz zu starten.

Konfiguration

YAML

Eine Textsprache für Konfigurationen.

YAML (YAML Ain't Markup Language) ist ein einfaches Textformat mit Einrückungen statt Klammern. Home Assistant nutzt es für configuration.yaml, Automationen, Scripts und fortgeschrittene Konfigurationen. Einrückung mit Leerzeichen (KEINE Tabs!) ist entscheidend.

Beispiel: light: - platform: group name: Alle Lichter entities: - light.wohnzimmer - light.kueche

configuration.yaml

Die zentrale Konfigurationsdatei von HA.

Unter /config/configuration.yaml definierst du Einstellungen, die nicht über die UI konfigurierbar sind: Template-Sensoren, MQTT-Konfiguration, Customize-Einstellungen und mehr. Änderungen erfordern oft einen Neustart oder ein 'Konfiguration prüfen'.

Beispiel: homeassistant: name: 'Wohnung Berlin' unit_system: metric template: - sensor: - name: 'Durchschnittstemperatur'

secrets.yaml

Datei für sensible Daten wie Passwörter.

In secrets.yaml speicherst du Passwörter, API-Keys und andere sensible Daten. In der configuration.yaml referenzierst du sie mit !secret. So hältst du Passwörter aus dem Haupt-Config raus, was besonders wichtig ist wenn du deine Config versionierst (Git).

Beispiel: In secrets.yaml: mqtt_password: 'mein-passwort' In configuration.yaml: password: !secret mqtt_password

Template (Jinja2)

Eine Vorlagensprache für berechnete Werte.

Home Assistant nutzt Jinja2 als Template-Sprache. Damit kannst du berechnete Werte erstellen, dynamische Nachrichten in Automationen schreiben und Bedingungen formulieren. Templates stehen in {{ doppelten geschwungenen Klammern }}.

Beispiel: {{ states('sensor.temperatur') | float + 2 }} → Gibt die Temperatur + 2 zurück {{ states.light | selectattr('state','eq','on') | list | count }} → Anzahl eingeschalteter Lichter

Customize

Entity-Anpassungen (Name, Icon etc.).

Über 'Customize' kannst du Entity-Eigenschaften überschreiben: friendly_name, icon, unit_of_measurement, device_class. Das geht per UI (Entity → Zahnrad) oder in configuration.yaml. Nützlich um Sensoren aussagekräftige Namen zu geben.

Beispiel: homeassistant: customize: sensor.temp_1: friendly_name: 'Wohnzimmer Temperatur' icon: mdi:thermometer

Netzwerk

Zigbee

Funk-Protokoll für Smart-Home-Geräte.

Zigbee ist ein Mesh-Netzwerk-Protokoll, das von vielen günstigen Sensoren und Lampen genutzt wird (Aqara, IKEA TRÅDFRI, Philips Hue). Es braucht einen Zigbee-Koordinator (USB-Stick) und wird über ZHA oder Zigbee2MQTT eingebunden.

Beispiel: Aqara Tür-/Fenstersensor über Zigbee: binary_sensor.aqara_haustuer — State: 'on' (offen) / 'off' (geschlossen)

Z-Wave

Funk-Protokoll mit großer Reichweite.

Z-Wave ist ein proprietäres Mesh-Netzwerk-Protokoll mit guter Reichweite (30-100m) und geringem Energieverbrauch. Beliebt für Schalter, Schlösser und Thermostate. Braucht einen Z-Wave-Stick (z.B. Aeotec Z-Stick). In HA über die Z-Wave JS Integration.

Beispiel: Fibaro Wall Plug über Z-Wave: switch.fibaro_plug → Power: 342W, Energy: 4.2 kWh

MQTT

Nachrichten-Protokoll für IoT-Geräte.

MQTT (Message Queuing Telemetry Transport) ist ein leichtgewichtiges Publish/Subscribe-Protokoll. Geräte senden Nachrichten an 'Topics', die andere Geräte abonnieren. Wird von Zigbee2MQTT, Tasmota und vielen DIY-Projekten genutzt. Braucht einen MQTT-Broker (z.B. Mosquitto).

Beispiel: Topic: zigbee2mqtt/sensor_wohnzimmer → Payload: {'temperature': 21.5, 'humidity': 55} Topic: cmnd/tasmota_plug/POWER → Payload: ON

Matter

Neuer herstellerübergreifender Smart-Home-Standard.

Matter ist ein offener Standard (von Apple, Google, Amazon und Samsung) für Smart-Home-Geräte. Matter-Geräte funktionieren mit allen Plattformen ohne separate Apps oder Bridges. Matter läuft über IP (WiFi oder Thread). Home Assistant unterstützt Matter als Controller.

Beispiel: Ein Matter-Licht wird einmal eingerichtet und funktioniert mit HA, Apple Home, Google Home und Alexa gleichzeitig.

Thread

Mesh-Netzwerk-Protokoll für Matter.

Thread ist ein IPv6-basiertes Mesh-Netzwerk-Protokoll, das als Transport für Matter dient. Es bietet niedrigen Stromverbrauch, hohe Zuverlässigkeit und Mesh-Fähigkeit. Braucht einen Thread Border Router (z.B. Apple TV 4K, HomePod Mini, HA Yellow).

Beispiel: Eve Motion (Thread) → Mesh über Apple TV 4K → Home Assistant über Matter

Erweiterungen

Add-on

Zusatzsoftware, die neben HA läuft.

Add-ons sind Docker-Container, die über den Add-on Store installiert werden. Sie erweitern Home Assistant um zusätzliche Funktionen. Nur verfügbar bei HA OS und Supervised Installation. Beliebte Add-ons: File Editor, Mosquitto MQTT Broker, Zigbee2MQTT, Node-RED.

Beispiel: Add-on 'Mosquitto MQTT Broker': Stellt einen MQTT-Broker bereit, den Zigbee2MQTT und Tasmota-Geräte nutzen.

HACS

Home Assistant Community Store.

HACS ist ein Community-Projekt, das zusätzliche Integrationen, Custom Dashboard Cards und Themes bereitstellt, die nicht im offiziellen Store sind. Es wird über ein Script installiert und bietet Zugang zu tausenden Erweiterungen.

Beispiel: Über HACS installieren: Mushroom Cards (Dashboard), Browser Mod (UI-Erweiterung), Alarmo (Alarmanlage), Spook (Debug-Tools)

Custom Card

Community-Dashboard-Karte aus HACS.

Custom Cards sind benutzerdefinierte Kartentypen für das Dashboard, die über HACS installiert werden. Sie erweitern die Standard-Kartentypen um zusätzliche Funktionalität und Design-Optionen.

Beispiel: Mushroom Light Card: Schöne Lichtsteuerung mit Farbrad. Mini Graph Card: Kompakte Verlaufsgrafiken für Sensoren.

ESPHome

Framework für DIY-ESP32/ESP8266-Geräte.

ESPHome ermöglicht es, eigene Sensoren und Aktoren mit ESP32/ESP8266-Mikrocontrollern zu bauen — komplett per YAML-Konfiguration, ohne C++ Code. Geräte werden nativ über die ESPHome-API in HA integriert und unterstützen OTA-Updates.

Beispiel: ESP32 mit DHT22: sensor.wohnzimmer_temperatur (21.5°C), sensor.wohnzimmer_feuchtigkeit (55%)

Tasmota

Open-Source-Firmware für WiFi-Geräte.

Tasmota ist eine alternative Firmware für ESP8266/ESP32-basierte Geräte. Im Gegensatz zu ESPHome konfiguriert man Tasmota über eine Web-UI. Kommuniziert über MQTT mit Home Assistant. Ideal zum Umflashen von fertigen Geräten.

Beispiel: Sonoff Basic mit Tasmota geflasht → MQTT-Topic: cmnd/sonoff_flur/POWER → ON/OFF

Dashboard

Dashboard (Lovelace)

Die Hauptoberfläche von Home Assistant.

Das Dashboard (intern 'Lovelace') ist die visuelle Oberfläche zum Steuern und Überwachen. Es besteht aus Ansichten (Tabs/Views) und Karten (Cards). Du kannst mehrere Dashboards erstellen, z.B. eines pro Raum oder Nutzer. Im Edit-Modus per Drag & Drop anpassbar.

Beispiel: Dashboard 'Übersicht': Tab 'Wohnzimmer' mit Licht-Card, Temperatur-Gauge, Kamera-Feed. Tab 'Energie' mit Verbrauchsgrafiken.

View (Ansicht)

Ein Tab innerhalb eines Dashboards.

Views sind die Tabs oben im Dashboard. Jede View kann ein eigenes Layout, eigene Karten und Bedingungen haben. Du kannst Views nach Raum, Funktion oder Person organisieren. Views können auch als 'Panel' (eine Karte füllt den ganzen Screen) konfiguriert werden.

Beispiel: Views: 'Übersicht' (alle Räume), 'Kamera' (nur Kamera-Feeds), 'Energie' (Verbrauchsdaten)

Theme

Visuelles Design für das Dashboard.

Themes ändern Farben, Schriften und Abstände im gesamten Dashboard. Offizielle und Community-Themes (via HACS) verfügbar. Themes können global oder pro Benutzer aktiviert werden. Beliebte Themes: iOS, Catppuccin, Mushroom Shadow.

Beispiel: Theme 'iOS Dark': Dunkles Design angelehnt an Apples iOS mit abgerundeten Karten und transparenten Elementen.

System

Zone

Ein geografischer Bereich auf der Karte.

Zonen sind GPS-Bereiche, die für die Anwesenheitserkennung genutzt werden. Die 'Home'-Zone wird automatisch erstellt. Du kannst weitere Zonen hinzufügen (Arbeit, Schule, Fitnessstudio). Zones werden in Automationen als Trigger oder Condition genutzt.

Beispiel: Zone 'Arbeit' mit Radius 200m → Automation: 'Wenn ich die Arbeit verlasse, Heizung einschalten'

Companion App

Die offizielle HA-App für iOS/Android.

Die Companion App bietet Fernzugriff, Push-Notifications, Standort-Tracking und Sensor-Daten vom Handy (Akku, Schritte, WLAN). Sie wird als notify.mobile_app_* in HA registriert.

Beispiel: notify.mobile_app_mein_iphone: Push mit Bild der Haustür-Kamera und Action-Buttons 'Tür öffnen' / 'Ignorieren'

Recorder

Speichert Entity-Verlaufsdaten in einer Datenbank.

Der Recorder schreibt alle State-Änderungen in eine SQLite-Datenbank (oder MariaDB). Damit kannst du Verläufe anzeigen und Statistiken berechnen. Standardmäßig werden 10 Tage gespeichert. Zu viele Entities belasten die Datenbank — schließe unnötige aus.

Beispiel: recorder: purge_keep_days: 5 exclude: domains: [media_player, weather]

Supervisor

Verwaltungsschicht für Add-ons und Updates.

Der Supervisor ist ein Container, der bei HA OS und Supervised läuft. Er verwaltet Add-ons, Backups, Updates und das Betriebssystem. Ohne Supervisor (Container/Core) musst du alles manuell verwalten.

Beispiel: Supervisor → Add-on Store → Mosquitto installieren → Backup erstellen → OS updaten

Nabu Casa

Offizieller Cloud-Dienst für Fernzugriff.

Nabu Casa ist der offizielle Cloud-Dienst des Home Assistant Teams (~7,50 €/Monat). Er bietet verschlüsselten Fernzugriff ohne Portfreigaben, Alexa- und Google-Home-Integration und unterstützt die Entwicklung von HA.

Beispiel: Zugriff von unterwegs: https://deine-id.ui.nabu.casa → Kamera prüfen, Heizung steuern

Assist

Home Assistants lokaler Sprachassistent.

Assist ist der eingebaute Sprachassistent, der komplett lokal läuft — keine Cloud, keine Daten nach außen. Er nutzt Whisper (Speech-to-Text), die eingebaute Intent-Erkennung und Piper (Text-to-Speech). Mit Hardware wie ESP32-S3-BOX nutzbar.

Beispiel: 'Hey Nabu, schalte das Licht im Wohnzimmer ein' → Whisper → Intent → light.turn_on → Piper: 'Licht ist jetzt an'

Webhook

HTTP-Endpunkt zum Auslösen von Automationen.

Ein Webhook ist eine URL, die Automationen von extern auslösen kann. Ideal für Dienste wie IFTTT, Tasker, Shortcuts oder eigene Skripte. Der Webhook-Trigger generiert eine einzigartige URL.

Beispiel: POST an https://ha.example.com/api/webhook/mein-webhook → Automation wird ausgelöst

REST API

Programmierschnittstelle von Home Assistant.

Die REST API ermöglicht externen Zugriff auf alle HA-Funktionen: States lesen/setzen, Services aufrufen, Automationen triggern. Authentifizierung über Long-Lived Access Tokens. Basis-URL: /api/.

Beispiel: GET /api/states/sensor.temperatur → {state: '21.5', attributes: {unit: '°C'}} POST /api/services/light/turn_on → {entity_id: 'light.flur'}

Tipp: Du kannst diese Begriffe auch im YAML-Guide und im Automations-Guide in Aktion sehen.