Home Assistant: Smarthome-Ausfälle zuverlässig überwachen

Die meisten Home-Assistant-Nutzer machen sich viele Gedanken darüber, was ihre Automatisierungen tun sollen: Licht an, wenn es dunkel wird. Lüfter an, wenn die CO₂-Werte steigen. Benachrichtigung, wenn die Waschmaschine fertig ist. Aber eine grundlegendere Frage bleibt oft unbeantwortet: Was passiert, wenn eines der Geräte, auf denen all diese Automatisierungen beruhen, still und leise ausfällt?

Genau das passiert häufiger, als man denkt. Ein Zigbee-Sensor verliert die Verbindung. Eine WLAN-Steckdose bekommt nach einem Router-Neustart keine neue IP. Der MQTT-Broker hängt sich auf – und mit ihm verschwinden zwanzig Geräte aus Home Assistant. Das System zeigt dann „unavailable" oder „unknown" an. Aber wenn du nicht aktiv hinschaust, bemerkst du nichts. Deine Automatisierungen laufen ins Leere. Der CO₂-Sensor, der deine Raumluft überwachen soll, sendet seit drei Tagen keine Daten mehr.

Dabei ist die Geräteüberwachung eine der einfachsten und wirkungsvollsten Automatisierungen in Home Assistant. Du brauchst keine externen Dienste, keine Cloud, keine Zusatzsoftware. Alles ist bereits eingebaut: State-Trigger, die Gruppe-Integration, Template-Sensoren – und etwas Sorgfalt bei der Verzögerungslogik, damit nicht jede kurze Funkstörung als Notfall gemeldet wird.

Dieser Artikel zeigt dir, wie du ausgefallene Luftqualitätssensoren, smarte Steckdosen und Bridges zuverlässig überwachst – und wie du Fehlalarme vermeidest, die dir sonst das Vertrauen in deine eigenen Benachrichtigungen rauben.

Inhaltsverzeichnis

• Warum „unavailable" kein Zufall ist
• Der State-Trigger: Dein Frühwarnsystem
• Fehlalarme vermeiden mit Verzögerung und Bedingungen
• Luftqualitätssensoren gezielt überwachen
• Smarte Steckdosen: Mehr als nur Stromverbrauch
• Bridges und Koordinatoren: Der Flaschenhals
• Gruppenlogik: Viele Geräte, eine Warnung
• Wiederherstellungs-Checkliste nach Ausfällen
• FAQ
• Fazit

Kurzantwort

Praxisguide: Home Assistant warnt zuverlässig vor ausgefallenen Sensoren, Steckdosen und Zigbee-Bridges – mit State-Triggern, Verzögerung und Gruppenlogik. Kurz gesagt: home assistant smarthome automatisierung ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Warum „unavailable" kein Zufall ist

Bevor du mit dem Bau von Überwachungsautomatisierungen beginnst, lohnt ein Blick darauf, was die Zustände „unavailable" und „unknown" in Home Assistant eigentlich bedeuten. Sie sind nicht dasselbe – und diesen Unterschied zu verstehen hilft dir, die richtigen Konsequenzen zu ziehen.

Der Zustand „unavailable" bedeutet: Home Assistant erwartet Daten von diesem Gerät, bekommt aber keine. Die Integration ist aktiv, die Entität existiert im System, aber seit einer Weile kommt nichts mehr an. Das passiert typischerweise, wenn ein Zigbee-Gerät außer Reichweite gerät, eine WLAN-Steckdose die Verbindung verliert oder der MQTT-Broker die Keep-Alive-Nachrichten nicht mehr durchreicht. Der Zustand „unknown" hingegen tritt vor allem dann auf, wenn Home Assistant noch nie einen Wert von dieser Entität empfangen hat – etwa direkt nach einem Neustart, bevor der erste Datenpunkt eintrifft, oder wenn eine Integration zwar geladen ist, aber noch keinen initialen Zustand melden konnte laut Home Assistant State-Object-Dokumentation.

Warum ist das wichtig? Weil eine Automatisierung, die stur auf „unavailable" reagiert, nach jedem Home-Assistant-Neustart ein Feuerwerk an Benachrichtigungen auslöst. Für einige Sekunden – manchmal Minuten – sind fast alle Geräte kurzzeitig „unknown", bis sie ihre ersten Werte liefern. Eine naive Überwachung würde dir dann fünfzehn Push-Nachrichten aufs Handy schicken, nur weil der Raspberry Pi neu gestartet wurde. Das ist der schnellste Weg, sich selbst zu konditionieren, Benachrichtigungen zu ignorieren.

Es ist verlockend, das Problem pauschal zu lösen: einfach nach dem Neustart eine Sperrzeit einbauen, in der keine Alarmierungen ausgelöst werden. Das funktioniert – aber es überdeckt auch echte Ausfälle, die zufällig in genau diesem Zeitfenster auftreten. Die bessere Lösung ist eine Kombination aus Zustandsunterscheidung und Verzögerung. Dazu später mehr.

Ein weiterer Aspekt, der oft übersehen wird: Manche Geräte gehen regelmäßig in einen „unavailable"-Zustand, und zwar vollkommen unkritisch. Ein batteriebetriebener Türsensor, der nur alle paar Stunden aufwacht und kurz seinen Status meldet, ist dazwischen schlicht nicht erreichbar. Das ist kein Fehler, das ist Design. Eine pauschale „unavailable bedeutet Alarm"-Logik erzeugt hier nur Rauschen.

Der State-Trigger: Dein Frühwarnsystem

Das Kernstück jeder Geräteüberwachung in Home Assistant ist der State-Trigger. Er reagiert auf Zustandsänderungen einer Entität – und genau darum geht es: Wenn ein Luftqualitätssensor von einem numerischen CO₂-Wert auf „unavailable" wechselt, soll etwas passieren laut offizieller Home-Assistant-Automation-Dokumentation.

Die einfachste Form sieht in YAML so aus:

trigger:
  - platform: state
    entity_id: sensor.luftqualitat_co2
    to: "unavailable"

Das reicht für einen ersten Test. Aber diese Automatisierung hat zwei gravierende Schwächen: Sie löst bei jedem Neustart aus (weil die Entität kurz „unknown" wird und dann zu „unavailable" wechseln kann), und sie feuert auch bei einer einsekündigen Funkstörung. Deshalb kommt hier das for-Attribut ins Spiel:

trigger:
  - platform: state
    entity_id: sensor.luftqualitat_co2
    to: "unavailable"
    for:
      minutes: 5

Erst wenn der Sensor fünf Minuten durchgehend „unavailable" ist, wird die Automatisierung aktiv. Das filtert den Neustart-Effekt und die allermeisten kurzen Funkaussetzer zuverlässig heraus. Welche Dauer die richtige ist, hängt vom Gerätetyp ab. Für netzbetriebene Geräte wie Steckdosen, die typischerweise im Sekundentakt Statusmeldungen senden, sind zwei bis drei Minuten eine sinnvolle Schwelle. Bei batteriebetriebenen Sensoren, die nur stündlich melden, brauchst du deutlich längere Zeiträume – sonst bekommst du bei jedem normalen Schlafzyklus eine Benachrichtigung.

Du kannst den State-Trigger auch mit einer Bedingung kombinieren, die prüft, ob Home Assistant selbst gerade erst gestartet ist. Das verhindert die Neustart-Fehlalarme, ohne dass du die Verzögerungszeit künstlich aufblähen musst:

condition:
  - condition: template
    value_template: >
      {{ (as_timestamp(now()) - as_timestamp(states('sensor.uptime'))) > 300 }}

Damit werden alle Auslösungen in den ersten fünf Minuten nach Systemstart unterdrückt – unabhängig vom Gerätezustand.

Fehlalarme vermeiden mit Verzögerung und Bedingungen

Das Problem mit Fehlalarmen ist nicht nur lästig – es ist betriebsblind machend. Wenn dein Handy jeden Tag zweimal grundlos „Sensor ausgefallen" meldet, wirst du beim dritten Mal nicht mehr hinsehen. Und genau dann ist es vielleicht der eine echte Ausfall, den du übersiehst.

Die Kernstrategie besteht aus drei Elementen: Zeitverzögerung, Zustandsbedingungen und Schwellwertlogik für Wiederholungen.

Zeitverzögerung haben wir bereits beim State-Trigger besprochen. Der for-Parameter ist dein wichtigstes Werkzeug. Für die meisten netzbetriebenen Geräte sind drei bis fünf Minuten ein guter Kompromiss zwischen Reaktionsgeschwindigkeit und Störfestigkeit.

Zustandsbedingungen filtern den Auslöser weiter ein. Ein praktisches Beispiel: Du möchtest nur benachrichtigt werden, wenn eine Steckdose „unavailable" wird – nicht aber, wenn sie legitimerweise ausgeschaltet wurde und auf „off" steht. Der Trigger auf „unavailable" erledigt das bereits implizit, aber was ist mit dem Zurück-Wechseln? Wenn die Steckdose wieder auftaucht, willst du das vielleicht ebenfalls wissen. Also:

trigger:
  - platform: state
    entity_id: switch.wohnzimmer_steckdose
    to: "unavailable"
    for: "00:03:00"
  - platform: state
    entity_id: switch.wohnzimmer_steckdose
    from: "unavailable"
    to: ~
    for: "00:00:30"

Der zweite Trigger feuert, wenn die Steckdose den „unavailable"-Zustand verlässt (die Tilde ~ bedeutet „beliebiger anderer Zustand") und seit mindestens 30 Sekunden wieder erreichbar ist. So bekommst du nicht nur eine Ausfall-, sondern auch eine Wiederherstellungsmeldung. Das klingt nach Over-Engineering, ist aber im Alltag extrem nützlich: Du siehst auf einen Blick, ob sich ein Problem von selbst gelöst hat.

Schwellwertlogik geht noch einen Schritt weiter. Statt bei jedem einzelnen Ausfall zu alarmieren, zählst du, wie viele Male ein Gerät in einem bestimmten Zeitraum ausgefallen ist. Dafür brauchst du einen Zähler-Helfer:

counter:
  sensor_ausfaelle_heute:
    name: "Sensor-Ausfälle heute"
    initial: 0
    step: 1

Deine Automatisierung erhöht diesen Zähler bei jedem Ausfall und prüft, ob ein Schwellwert überschritten wurde. Ein Gerät, das innerhalb einer Stunde dreimal kurz ausfällt, ist wahrscheinlich tatsächlich gestört – auch wenn jeder einzelne Ausfall kürzer war als deine for-Zeit von drei Minuten. Eine Template-Bedingung wie {{ states('counter.sensor_ausfaelle_heute') | int > 3 }} macht daraus eine qualifizierte Warnung.

Diese Methodik hat einen Nachteil, den ich nicht verschweigen will: Sie erhöht die Komplexität deiner Konfiguration spürbar. Aus einer simplen Automation werden drei bis fünf miteinander verzahnte Elemente. Ob sich das für zwei batteriebetriebene Fenstersensoren lohnt, ist fraglich. Aber für die zentralen Geräte – die CO₂-Sensoren, die Bridge, die Steckdose am Kühlschrank – ist dieser Aufwand gut investiert.

Luftqualitätssensoren gezielt überwachen

Luftqualitätssensoren sind ein Sonderfall. Anders als ein simpler Bewegungssensor, dessen Ausfall du vielleicht erst nach Tagen bemerkst, erfüllen CO₂-, PM2.5- und VOC-Sensoren eine gesundheitsrelevante Funktion. Im Schlafzimmer kann ein CO₂-Wert über 1.500 ppm zu Konzentrationsproblemen und Kopfschmerzen führen – und wenn der Sensor, der den Lüfter triggern soll, still ausgefallen ist, merkst du das erst, wenn die Luft längst stickig ist.

Die gute Nachricht: Die gängigen Luftqualitätssensoren für Home Assistant – von AirGradient über Awair bis hin zu den preiswerten SenseAir-Boards – sind in der Regel netzbetrieben und melden ihre Werte im Sekunden- oder Minutentakt. Das macht die Überwachung einfach. Fünf Minuten ohne Daten bedeuten mit hoher Wahrscheinlichkeit einen echten Ausfall, keine normale Sendepause.

Ein Muster, das ich für Luftqualitätssensoren empfehle:

automation:
  - alias: "CO2-Sensor Schlafzimmer ausgefallen"
    trigger:
      - platform: state
        entity_id:
          - sensor.schlafzimmer_co2
          - sensor.schlafzimmer_temperatur
          - sensor.schlafzimmer_feuchte
        to: "unavailable"
        for: "00:05:00"
    condition:
      - condition: template
        value_template: >
          {{ (as_timestamp(now()) - as_timestamp(states('sensor.uptime'))) > 300 }}
    action:
      - service: notify.mobile_app_mein_handy
        data:
          title: "Sensor ausgefallen"
          message: >
            {{ trigger.to_state.entity_id }} seit {{ relative_time(trigger.to_state.last_changed) }} nicht erreichbar.

Beachte, dass hier mehrere Entitäten in einer Automation überwacht werden. Wenn ein Sensor drei Entitäten bereitstellt (CO₂, Temperatur, Feuchte), gehen bei einem Ausfall typischerweise alle gleichzeitig auf „unavailable". Die Automation würde dann drei Benachrichtigungen senden. Das kannst du verhindern, indem du im mode auf single setzt – dann läuft immer nur eine Instanz der Automation. Noch eleganter ist mode: queued, das wartet, bis die erste Ausführung abgeschlossen ist.

Ein reales Ärgernis: Manche Luftqualitätssensoren liefern bei Netzwerkstörungen keine „unavailable"-Meldung, sondern frieren einfach auf dem letzten Wert ein. Der CO₂-Sensor zeigt fröhlich 620 ppm an – seit drei Stunden, während in Wirklichkeit längst 1.800 ppm erreicht sind. Dagegen helfen nur zwei Dinge: ein regelmäßiger Heartbeat-Check über einen Template-Sensor, der prüft, ob sich der Wert innerhalb einer Stunde überhaupt verändert hat, oder – pragmatischer – ein regelmäßiger Blick auf die History-Kurve. Ein komplett flacher Graph über mehrere Stunden ist immer verdächtig.

Smarte Steckdosen: Mehr als nur Stromverbrauch

Smarte Steckdosen sind die stillen Arbeitstiere im Smarthome. Sie schalten Lampen, steuern Ventilatoren, messen den Stromverbrauch der Waschmaschine. Aber dass sie selbst ausfallen können, vergessen die meisten.

Der Ausfall einer smarten Steckdose ist tückisch, weil er oft unentdeckt bleibt. Eine WLAN-Steckdose kann nach einem Router-Neustart ihre Verbindung verlieren, ohne dass du es mitbekommst – sie bleibt einfach im letzten Schaltzustand stecken. War sie an, bleibt sie an. War sie aus, bleibt sie aus. Erst wenn die Kaffeemaschine morgens nicht angeht oder der Ventilator die Feuchtigkeit nicht abführt, fällt es auf.

Die Überwachung funktioniert nach dem gleichen State-Trigger-Prinzip wie bei Sensoren – mit einem wichtigen Zusatz: Viele smarte Steckdosen haben einen Leistungsmesswert (sensor.steckdose_power), der kontinuierlich aktualisiert wird. Selbst wenn der Schaltzustand unverändert bleibt, ändert sich der Leistungswert. Bleibt auch dieser über einen längeren Zeitraum konstant, ist das ein starkes Indiz für einen Kommunikationsausfall.

Ein Beispiel für eine kombinierte Überwachung:

trigger:
  - platform: state
    entity_id: sensor.steckdose_kueche_power
    to: "unavailable"
    for: "00:03:00"
  - platform: template
    value_template: >
      {{ states('sensor.steckdose_kueche_power') | float(0) == 0
         and state_attr('sensor.steckdose_kueche_power', 'last_changed') is not none
         and (as_timestamp(now()) - as_timestamp(state_attr('sensor.steckdose_kueche_power', 'last_changed'))) > 7200 }}
    for: "00:05:00"

Der zweite Trigger erkennt den „Eingefroren"-Fall: Der Leistungswert liegt seit über zwei Stunden bei 0 Watt und hat sich nicht verändert – obwohl die Steckdose noch als erreichbar gemeldet wird. Das ist kein theoretisches Szenario; ich habe genau dieses Verhalten bei mehreren Shelly- und Sonoff-Geräten beobachtet, besonders nach Fritz!Box-Firmware-Updates, bei denen die WLAN-Clients kurz getrennt und nicht alle sauber neu assoziiert wurden.

Speziell bei Zigbee-Steckdosen gibt es eine weitere Fallgrube: Manche Modelle melden sich nach einem kurzen Stromausfall nicht von selbst zurück am Koordinator an. Sie sind dann in der Zigbee2MQTT-Oberfläche oder ZHA sichtbar, aber als „offline" markiert. Ein physischer Tastendruck am Gerät bringt sie meist zurück – aber den kannst du nicht automatisieren. Hier hilft nur eine Betriebsbereitschafts-Automatisierung, die dir sagt: „Steckdose Küche seit 10 Minuten offline – bitte einmal manuell die Taste drücken."

Bridges und Koordinatoren: Der Flaschenhals

Wenn die Zigbee-Bridge ausfällt, gehen nicht ein, sondern alle Zigbee-Geräte auf „unavailable". Das klingt dramatisch – und das ist es auch. Aber interessanterweise ist es gleichzeitig der am leichtesten zu erkennende Fehlertyp: Du bekommst nicht eine Benachrichtigung, sondern potenziell mehrere Dutzend gleichzeitig, wenn jedes überwachte Gerät einzeln Alarm schlägt.

Deshalb willst du die Bridge-Überwachung von der Geräteüberwachung entkoppeln. Die Bridge wird separat überwacht – über ihren eigenen Verbindungsstatus. Und wenn die Bridge ausfällt, werden die einzelnen Gerätewarnungen unterdrückt. Denn der Ausfall von zwanzig Sensoren gleichzeitig ist in diesem Fall kein zwanzigfaches Problem, sondern genau eines: die Bridge.

Für Zigbee2MQTT gibt es die Entität binary_sensor.zigbee2mqtt_bridge_connection_state, die den Verbindungsstatus des MQTT-Brokers zur Zigbee2MQTT-Instanz anzeigt. Fällt diese auf „unavailable", weißt du, dass entweder der Broker, der Zigbee2MQTT-Dienst oder der Koordinator selbst gestört ist laut Community-Diskussion zur Z2M-Überwachung.

Die Automation zur Bridge-Überwachung sollte eine kürzere Reaktionszeit haben als die Sensoren selbst, und der Trigger muss die Gerätewarnungen unterdrücken. Das geht über Bedingungen:

condition:
  - condition: state
    entity_id: binary_sensor.zigbee2mqtt_bridge_connection_state
    state: "on"

Diese Bedingung wird in jede Geräte-Automation eingebaut. Ist die Bridge tot, schweigen die Einzelwarnungen – du bekommst nur die eine Bridge-Benachrichtigung.

Für ZHA-Nutzer ohne Zigbee2MQTT gibt es keinen standardisierten Bridge-Status-Sensor. Hier hilft ein Template-Sensor, der die Anzahl der „unavailable"-Zigbee-Geräte zählt:

template:
  - sensor:
      - name: "ZHA Offline Geraete"
        state: >
          {{ expand(integration_entities('zha'))
              | selectattr('state', 'in', ['unavailable', 'unknown'])
              | list | count }}

Liegt dieser Wert plötzlich über einem Schwellwert – sagen wir fünf Geräte innerhalb einer Minute –, ist mit hoher Wahrscheinlichkeit der Koordinator das Problem, nicht die einzelnen Sensoren. Eine Automation mit numeric_state-Trigger auf diesem Sensor kann dann eine fokussierte Warnung auslösen, ohne dass du zwanzig Einzelmeldungen sortieren musst.

Gruppenlogik: Viele Geräte, eine Warnung

Die Group-Integration von Home Assistant ist das eleganteste Werkzeug für die zusammenfassende Überwachung. Statt für jeden der fünfzehn Sensoren eine eigene Automation zu schreiben, fasst du sie in einer Gruppe zusammen und wertest den Gesamtzustand aus laut Home-Assistant-Group-Dokumentation.

Eine Gerätegruppe sieht so aus:

group:
  sensoren_wohnzimmer:
    name: "Sensoren Wohnzimmer"
    entities:
      - sensor.wohnzimmer_co2
      - sensor.wohnzimmer_temperatur
      - sensor.wohnzimmer_feuchte
      - sensor.wohnzimmer_helligkeit
    all: false

Das all: false ist entscheidend: Die Gruppe zeigt dann standardmäßig den Zustand der meisten Mitglieder an. Wenn drei von vier Sensoren online sind, ist die Gruppe „on". Wenn alle „unavailable" sind, ist die Gruppe „off". Das allein reicht aber nicht, denn wir wollen ja schon bei einem Ausfall gewarnt werden, nicht erst, wenn alle tot sind.

Hier kommen Template-Sensoren ins Spiel, die auf die Gruppe aufsetzen:

template:
  - sensor:
      - name: "Sensoren Wohnzimmer Unavailable"
        state: >
          {{ expand('group.sensoren_wohnzimmer')
              | selectattr('state', 'in', ['unavailable', 'unknown'])
              | list | count }}

Dieser Sensor zeigt an, wie viele Geräte in der Gruppe gerade nicht erreichbar sind. Die Automation triggert dann auf einen bestimmten Schwellwert – typischerweise 1 oder 2, je nach Toleranz:

trigger:
  - platform: numeric_state
    entity_id: sensor.sensoren_wohnzimmer_unavailable
    above: 0
    for: "00:05:00"

Der Vorteil dieser Gruppenlogik liegt nicht nur in der Konfigurationsersparnis, sondern auch in der Wartbarkeit. Wenn du einen neuen Sensor hinzufügst, musst du keine neue Automation schreiben – du trägst ihn einfach in die bestehende Gruppe ein.

Was die Gruppenlogik nicht leistet: Sie unterscheidet nicht zwischen einem einzelnen ausgefallenen Sensor und einer flächendeckenden Bridge-Störung. Dafür brauchst du die bereits beschriebene Bridge-Bedingung. Aber die Kombination aus Group, Template-Sensor und Bridge-Condition gibt dir ein robustes, pflegeleichtes Überwachungssystem, das ohne externe Abhängigkeiten auskommt.

Mir ist wichtig, hier nicht den Eindruck zu erwecken, das sei eine Universallösung. Je heterogener deine Gerätelandschaft, desto mehr Ausnahmen wirst du brauchen. Der batteriebetriebene Fenstersensor, der legitimerweise zwölf Stunden schläft, gehört nicht in eine Gruppe mit netzbetriebenen CO₂-Messgeräten, die im Minutentakt senden. Eine Gruppe funktioniert nur dann zuverlässig, wenn ihre Mitglieder ähnliche Kommunikationsmuster haben.

Wiederherstellungs-Checkliste nach Ausfällen

Ein Ausfall ist gemeldet. Jetzt willst du ihn beheben – und im besten Fall eine Systematik dahinter erkennen. Dafür hilft eine strukturierte Checkliste, die du Schritt für Schritt abarbeitest, statt hektisch den Router neu zu starten und zu hoffen, dass es danach wieder geht.

1. Muster erkennen. Ein einzelnes Gerät? Lokaler Defekt oder Reichweitenverlust. Eine ganze Gruppe? Bridge- oder Koordinatorausfall. Fällt die Bridge-Status-Entität synchron aus, liegt die Ursache oberhalb der Geräteebene.

2. Protokollebene prüfen. Bei Zigbee: Sind andere Geräte am gleichen Router noch erreichbar? Der Netzwerkgraph in Zigbee2MQTT oder die ZHA-Visualisierung zeigt die Route. Ein Gerät, dessen Eltern-Router ausgefallen ist, verliert den Anschluss – selbst wenn der Koordinator läuft. Häufig nach Änderungen an Lampen oder fest installierten Zigbee-Routern.

3. Physische Ursachen ausschließen. Wurde die Steckdose des Geräts versehentlich ausgeschaltet? Umgesteckt? Neues Möbelstück zwischen Sensor und Zigbee-Router? Metallschränke und große Spiegel sind Zigbee-Killer.

4. Gezielt neustarten. Nicht den ganzen Server – das verschleiert das Problem. Nur den betroffenen Dienst (Zigbee2MQTT, ZHA, MQTT-Broker). Wenn das nicht hilft: Koordinator für 30 Sekunden stromlos trennen.

5. Neu pairen. Erst das Gerät aus der Zigbee-Datenbank löschen, dann neu anlernen. Sonst hast du zwei Einträge für dasselbe Gerät und verwirrst die Routing-Tabelle zusätzlich.

6. Logs auswerten. Home-Assistant-Logs unter „System > Logs" zeigen Timeout- und Verbindungsfehler der betroffenen Integration. Für Zigbee2MQTT sind die eigenen Logs oft aussagekräftiger, weil sie die Rohkommunikation mit dem Koordinator abbilden.

7. Trend erkennen. Ein Ausfall pro Monat ist normaler Signalverlust. Ein Ausfall pro Tag ist ein strukturelles Problem. Ein History Stats Sensor, der zählt, wie oft die Entität in den letzten 30 Tagen „unavailable" war, automatisiert das – oder ein simpler input_text-Helfer, in den du Datum und Gerät einträgst.

Diese Checkliste ersetzt keine tiefe Netzwerkanalyse. Aber sie verhindert, dass du bei jedem Ausfall von vorne anfängst und in Panik den Router rebootest, obwohl der Zigbee-Sensor nur eine neue Batterie braucht.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du home assistant smarthome automatisierung nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

FAQ

Muss ich jedes einzelne Gerät überwachen?

Nein. Batteriebetriebene Sensoren mit langen Schlafintervallen (Tür-/Fensterkontakte, manche Bewegungsmelder) sind ungeeignet für die „unavailable"-Überwachung, weil ihr Zustandswechsel normal und unkritisch ist. Konzentriere dich auf netzbetriebene Geräte mit sicherheits- oder gesundheitsrelevanten Funktionen: CO₂-Sensoren, Rauchmelder, smarte Steckdosen an kritischen Verbrauchern, Bridges und Koordinatoren.

Welche Verzögerungszeit ist sinnvoll?

Für netzbetriebene Geräte: drei bis fünf Minuten. Das filtert WLAN-Reconnects und kurze Funkstörungen. Für batteriebetriebene Geräte: mindestens das Doppelte des normalen Meldeintervalls. Wenn dein Fenstersensor alle sechs Stunden sendet, musst du mindestens zwölf Stunden Verzögerung einstellen – und rechtfertigt das überhaupt eine Alarmierung? Meistens nicht.

Verhindert die for-Bedingung alle Fehlalarme nach einem Neustart?

Nicht garantiert. Wenn dein Home Assistant länger zum Hochfahren braucht als deine for-Zeit – etwa weil viele Integrationen geladen werden und der Start eine Minute länger dauert als sonst –, können trotzdem Fehlalarme durchkommen. Eine zusätzliche Template-Bedingung, die die System-Uptime prüft, ist sicherer.

Kann ich die Gruppenlogik auch für Geräte unterschiedlicher Integrationen nutzen?

Ja. Die group-Integration interessiert sich nicht dafür, ob ein Gerät per Zigbee, WLAN, Z-Wave oder Bluetooth angebunden ist. Du kannst einen Sonoff-Temperatursensor (WLAN), einen Aqara-Fensterkontakt (Zigbee) und einen Shelly-Stromzähler (WLAN) in dieselbe Gruppe packen. Wichtig ist nur, dass die Kommunikationsmuster ähnlich sind – sonst melden dir die einen Geräte ständig falsche Alarme, während die anderen korrekt überwacht werden.

Was mache ich, wenn ein Gerät dauerhaft „unknown" bleibt?

„Unknown" ohne Übergang zu einem Wert deutet auf ein Integrationsproblem hin, nicht auf einen Geräteausfall. Prüfe, ob die Integration korrekt konfiguriert ist und ob Home Assistant nach einem Neustart die Verbindung überhaupt aufbauen konnte. Ein Gerät, das aus einem Firmware-Update mit neuer Entitäten-ID zurückkommt, zeigt die alte ID als „unknown" – die neue läuft unter anderer Bezeichnung.

Gibt es eine fertige Lösung, die ich nur importieren muss?

Das Community-Projekt unavailable-entities-sensor von jazzyisj auf GitHub bietet einen vorgefertigten Template-Sensor, der alle „unavailable"- und „unknown"-Entitäten überwacht, mit Filter- und Ausschluss-Optionen laut Projekt-Repository. Es liefert auch eine Beispiel-Automation für Benachrichtigungen. Für den schnellen Einstieg ist das eine gute Basis – aber du wirst die Filter an deine Gerätelandschaft anpassen müssen, sonst meldet der Sensor auch die hundert Entitäten, die du bewusst nicht überwachst.

Warum werden beim Bridge-Ausfall nicht alle Geräte als „unavailable" gemeldet?

Das hängt vom Protokoll ab. Bei Zigbee2MQTT gehen die Geräte-Entitäten in der Regel zeitverzögert auf „unavailable", weil der MQTT-Broker den letzten bekannten Zustand für eine gewisse Zeit vorhält (Retain-Flag). Erst wenn die Keep-Alive-Periode abläuft, kippen die Entitäten. Das kann je nach Konfiguration zwischen einer und dreißig Minuten dauern. Deshalb ist die direkte Überwachung des Bridge-Status-Sensors zuverlässiger und schneller als auf die Geräte-Entitäten zu warten.

Kann ich die Ausfallbenachrichtigungen zeitabhängig filtern?

Selbstverständlich. Ein CO₂-Sensor-Ausfall im Schlafzimmer ist nachts um drei relevanter als tagsüber um elf, wenn niemand im Raum ist. Eine Zeitbedingung in der Automation erlaubt dir, die Alarmierung auf den relevanten Zeitraum zu beschränken:

condition:
  - condition: time
    after: "22:00:00"
    before: "08:00:00"
    weekday:
      - mon
      - tue
      - wed
      - thu
      - fri
      - sat
      - sun

Oder umgekehrt: Tagsüber nur dezent als Notification, nachts per kritischem Alarm mit Lautstärke-Override.

Wie viele Ausfälle sind „normal"?

Für ein typisches Zigbee-Netzwerk mit 30–50 Geräten sind ein bis zwei kurzzeitige Aussetzer pro Monat nicht ungewöhnlich – meist verursacht durch Interferenzen im 2,4-GHz-Band oder Nachbar-WLAN-Netzwerke laut Community-Erfahrungsberichten zur Geräteausfallüberwachung. Alles, was häufiger auftritt oder länger als zehn Minuten anhält, verdient eine genauere Untersuchung.

Fazit

Home Assistant bringt alles mit, was du für eine zuverlässige Geräteüberwachung brauchst. Keine Zusatzsoftware, keine Cloud, kein Abo. Der State-Trigger mit for-Verzögerung ist das Arbeitspferd, die Group-Integration organisiert, und die Template-Sensoren liefern das Feingefühl. Das ist die gute Nachricht.

Die weniger gute: Es gibt keine Plug-and-Play-Lösung, die du einmal importierst und dann vergisst. Eine wirksame Überwachung muss die Eigenheiten deiner konkreten Geräte abbilden – welche batteriebetrieben sind, welche hinter einer instabilen WLAN-Strecke hängen, welche Bridge bei einem Ausfall alle unter sich begräbt. Die Automatisierungen, die du baust, sind so gut wie die Sorgfalt, mit der du diese Unterschiede berücksichtigst.

Meine Empfehlung: Fang klein an. Überwache zuerst die Bridge und zwei, drei kritische Sensoren. Wenn das System eine Woche ohne Fehlalarm läuft, erweiterst du es schrittweise. Der häufigste Fehler, den ich beobachte, ist der Overkill am Anfang: dreißig Automatisierungen für fünfzig Geräte, die dann jeden Tag eine Flut von Push-Nachrichten erzeugen. Danach schaltet man alles ab – und hat gar nichts gewonnen.

Realistisch betrachtet wirst du die meiste Zeit keine Benachrichtigung bekommen. Und genau das ist der gewünschte Zustand. Eine gute Überwachung ist die, die du nicht bemerkst – bis du sie brauchst.

Quellen

• Home Assistant: Automation Triggers (State)
• Home Assistant: State Object Documentation
• Home Assistant: Group Integration
• Home Assistant Community: Unavailable/Unknown Entity Monitoring – Template Sensor
• Home Assistant Community: Detection of Device Unavailability
• Home Assistant Community: How to Trigger Automation on Unavailable Entity in MQTT
• Zack’s Blog: Hardening Home Assistant Automations Against Unavailable States
• GitHub: jazzyisj/unavailable-entities-sensor

Passende Produktrecherchen

• Smarte Luftqualitätssensoren für Home Assistant
• Zigbee-Koordinatoren und Bridges
• Smarte Steckdosen mit Energieüberwachung
• Aqara Sensoren für Home Assistant
• Shelly Plus 1PM smarte Steckdose

Weiterführende Artikel

• IoTLabs wM-Bus Gateway: ESP32-Gerät mit Wireless M-Bus für Home Assistant
• Von VMware zu Proxmox wechseln: Lohnt sich der Umstieg für Profis?
• Smarthome ohne Wegwerf-Falle: Worauf du 2026 bei Geräten achten solltest
• Solarspitzengesetz: Was ändert sich für PV-Anlagen über 100 kWp?
• Solarstrom verkaufen: Wie die Einspeisevergütung wirklich funktioniert

Hinweis: Links zu Amazon sind Affiliate-Links. Beim Kauf über diese Links erhalten wir eine kleine Provision – für dich ändert sich der Preis nicht.