Bewegungs-Automation feuert nur manchmal: veralteter Helligkeitswert

Das Szenario ist schnell beschrieben: Eine Home-Assistant-Automation schaltet das Flurlicht ein, wenn Bewegung erkannt wird und es gleichzeitig dunkel genug ist. Meistens klappt das. Dann wieder passiert nichts, obwohl jemand durch den Flur läuft und der Raum offensichtlich dunkel ist. Die üblichen Verdächtigen lauten Zigbee-Verzögerung oder ein zickender Bewegungsmelder. In dem Fall, um den es hier geht, war beides falsch 1.

Die kurze Antwort vorweg: Die Bewegung wurde korrekt erkannt, aber die Helligkeitsbedingung wurde gegen einen veralteten Messwert geprüft. Der Helligkeitssensor meldet seine Lux-Werte nicht kontinuierlich, sondern nur, wenn sich der Wert ausreichend ändert. In den Fenstern dazwischen steht in Home Assistant ein alter Wert, und die Bedingung entscheidet auf dieser falschen Grundlage 1. Derselbe Fehler zeigt sich in einer zweiten Variante: Ist der Sensorwert gerade gar nicht vorhanden, kann Home Assistant die Bedingung nicht als Zahl auswerten, und sie fällt ebenfalls durch 2, 3.

In diesem Artikel zeige ich, wie du erkennst, welche der beiden Varianten bei dir vorliegt, und wie du sie behebst. Das Kernstück ist eine prüfbare Diagnose, keine allgemeine Einordnung. Alle Aussagen über das Verhalten von Home Assistant sind mit der offiziellen Dokumentation belegt; die Zahlen in eckigen Klammern verweisen auf die Quellen am Ende.

Kurzantwort

Home-Assistant-Automation feuert manchmal nicht: Die Helligkeitsbedingung läuft oft gegen einen veralteten Lux-Wert. So diagnostizierst und behebst du das. Kurz gesagt: ki tools praxis 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.

Das Szenario und der falsche Verdacht

Ausgangspunkt ist ein Erfahrungsbericht aus dem Home-Automation-Forum auf Reddit 1. Die Automation dort hat drei Teile: Ein Trigger reagiert auf Bewegung, eine Bedingung prüft die Helligkeit, eine Aktion schaltet das Licht ein. Konkret etwa so:

automation:
  - alias: "Flurlicht bei Bewegung und Dunkelheit"
    triggers:
      - trigger: state
        entity_id: binary_sensor.flur_bewegung
        to: "on"
    conditions:
      - condition: numeric_state
        entity_id: sensor.flur_helligkeit
        below: 20
    actions:
      - action: light.turn_on
        target:
          entity_id: light.flur

Die Automation funktionierte nach Angabe des Verfassers die meiste Zeit, versagte aber gelegentlich: Bewegung war klar erkennbar, der Raum war eindeutig dunkel, trotzdem ging das Licht nicht an 1. Der Verfasser suchte die Ursache zunächst bei einer Zigbee-Verzögerung und dann bei einem unzuverlässigen Bewegungsmelder. Der tatsächliche Grund lag woanders: Der Helligkeitssensor meldet Lux-Werte nur, wenn sich der Wert um einen bestimmten Schwellenwert ändert, nicht fortlaufend. Dadurch gab es Zeitfenster, in denen der zuletzt gemeldete Wert veraltet war 1.

Das ist keine exotische Eigenheit eines einzelnen Geräts. Batteriebetriebene Zigbee-Endgeräte melden ihren Zustand in der Regel nur, wenn etwas passiert, um den Akku zu schonen. Die Home-Assistant-Dokumentation zur Zigbee-Integration ZHA nennt solche Geräte ausdrücklich als “sleepy sensors”, also Geräte, die nur bei einem Ereignis senden 5. Ein Helligkeitssensor, der nur bei einer Wertänderung sendet, sendet eben nicht, wenn es langsam dunkler wird, solange die Änderung unter seiner Meldeschwelle bleibt.

Warum die Bedingung manchmal nicht greift

Um zu verstehen, warum das schiefgeht, muss man sich ansehen, wie Home Assistant eine Bedingung vom Typ numeric_state auswertet. Die Dokumentation beschreibt das so: Dieser Bedingungstyp versucht, den Zustand der angegebenen Entität oder eines ihrer Attribute als Zahl zu lesen, und gilt als erfüllt, wenn der Wert die Schwellen erfüllt. Die Vergleiche sind dabei strikt, das heißt, der Schwellenwert selbst zählt nicht mehr als erfüllt 3. Bei einem Helligkeitssensor ist die Einheit Lux hinterlegt: Der Geräteklass illuminance steht laut Dokumentation für den aktuellen Lichtpegel in Lux 4.

Aus dieser Arbeitsweise ergeben sich zwei getrennte Fehlerbilder, die oft in einen Topf geworfen werden.

Das erste Fehlerbild ist der veraltete Wert. Der Sensor hält noch eine gültige Zahl, etwa 40 Lux von vor ein paar Stunden. Als es dunkel wurde, hat der Sensor nicht gemeldet, weil die Änderung unter seiner Schwelle lag oder er nur in größeren Abständen sendet. Wenn dann Bewegung ausgelöst wird, prüft Home Assistant die Bedingung gegen die 40 Lux. 40 ist nicht unter 20, die Bedingung fällt durch, das Licht bleibt aus. Hier wird nichts falsch ausgewertet. Es wird korrekt gerechnet, nur eben mit einer Zahl, die die Wirklichkeit nicht mehr beschreibt.

Das zweite Fehlerbild ist der fehlende Wert. Jede Entität in Home Assistant hat genau einen Zustand. Zwei Zustände haben eine besondere Bedeutung: “unavailable” heißt, die Entität kann ihren Zustand gerade nicht liefern, etwa weil das Gerät nicht erreichbar ist oder die Integration nicht eingerichtet wurde. “unknown” heißt, für die Entität liegt kein Wert vor 2. Beides sind keine Zahlen. Eine numeric_state-Bedingung, die versucht, so einen Zustand als Zahl zu lesen, kann die Schwelle nicht erfüllen und fällt durch 2, 3.

Der fehlende Wert kann aus derselben Wurzel wachsen wie der veraltete. ZHA markiert ein batteriebetriebenes Gerät als nicht verfügbar, wenn es innerhalb einer einstellbaren Frist nicht mehr gemeldet hat. Der Standardwert für batteriebetriebene Geräte sind sechs Stunden, also 21600 Sekunden 5. Ein träger Sensor, der nur bei Ereignissen sendet, kann diese Frist reißen und erscheint dann als “unavailable”, obwohl er eigentlich nur gespart hat. Die Dokumentation empfiehlt für solche Geräte, die Frist heraufzusetzen, damit sie nicht wiederholt als nicht verfügbar markiert werden 5. Fehlender Wert und veralteter Wert sind damit keine getrennten Welten, sondern zwei Sichtweisen auf dasselbe Verhalten.

Der Unterschied ist für die Reparatur entscheidend. Beim veralteten Wert hilft ein Standard-value_template mit Ersatzwert nichts, denn der Sensor liefert ja eine gültige Zahl, nur die falsche. Beim fehlenden Wert ist genau das der passende Hebel. Beides wird weiter unten getrennt behandelt.

Dazu kommt eine strukturelle Eigenschaft von Bedingungen: Anders als ein Trigger, der die Automation startet, werden Bedingungen standardmäßig mit UND verknüpft. Alle Bedingungen müssen wahr sein, sonst stoppt die Automation 3. In der Beispiel-Automation gibt es nur eine einzige Bedingung, aber sobald du Bewegung und Helligkeit und vielleicht noch eine Zeitbedingung kombinierst, reicht ein einziger nicht erfüllter Baustein, und nichts passiert. Bei einer sporadisch fehlschlagenden Automation lohnt es sich deshalb, jede Bedingung einzeln zu prüfen statt pauschal den Trigger zu verdächtigen.

Diagnose: welche Variante liegt bei dir vor

Bevor du etwas änderst, kläre, welches der beiden Fehlerbilder vorliegt. Die Schritte sind einzeln ausführbar und brauchen keine Zusatzsoftware.

Schritt eins: Öffne die Automationsabläufe. In Home Assistant zeigt die Ansicht “Abläufe” zu jeder Automation die letzten Läufe an. Dort steht, welcher Trigger gefeuert hat und welche Bedingung nicht erfüllt war. Wenn bei einem fehlgeschlagenen Lauf der Trigger Bewegung ist und die Helligkeitsbedingung als nicht erfüllt markiert ist, liegt die Ursache in genau dieser Bedingung, nicht am Bewegungsmelder.

Schritt zwei: Schau dir den Zustand des Helligkeitssensors im Moment des Fehlers an. Unter Entwicklerwerkzeuge und Zustände findest du die Entität mit ihrem aktuellen Wert und den Zeitstempeln. Zwei Fälle sind zu unterscheiden. Steht dort ein plausibler Lux-Wert, dessen Zeitstempel aber Stunden alt ist, hast du den veralteten Wert. Steht dort “unavailable” oder “unknown”, hast du den fehlenden Wert 2.

Schritt drei: Teste den Sensor aktiv. Mache das Licht in dem Raum an und aus und beobachte, ob und wann sich der Lux-Wert ändert. Ein Sensor, der nur bei einer größeren Änderung sendet, reagiert auf kleine Helligkeitsunterschiede spät oder gar nicht. Vergleiche den angezeigten Wert mit dem, was du mit einer Lichtmess-App oder dem Auge erwartest. Ein grober Abgleich genügt, um zu sehen, ob der Wert der Wirklichkeit hinterherhinkt.

Schritt vier: Prüfe die Zeitstempel genauer. Die Dokumentation zum Zustandsobjekt unterscheidet drei Zeitstempel: last_changed ändert sich, wenn der Zustand wechselt, last_updated zusätzlich, wenn sich Attribute ändern, und last_reported, wenn die Entität zuletzt gemeldet hat, und zwar auch dann, wenn sich weder Zustand noch Attribute geändert haben 2. Für die Diagnose eines trägen Sensors ist last_updated der einfachste Anhaltspunkt: Ist der Wert seit Stunden unverändert, während die Umgebung sich sichtbar geändert hat, meldet der Sensor schlicht zu selten.

Schritt fünf: Ordne das Gerät ein. Ist der Helligkeitssensor batteriebetrieben und Teil eines Kombigeräts mit Bewegungsmelder, spricht das für die Meldeschwelle 5. Ist er über das Netzteil versorgt und trotzdem stundenlang stumm, ist eher eine Verbindungs- oder Integrationsfrage zu klären, etwa ob das Gerät überhaupt erreichbar ist.

Wer nicht jedes Mal Zeitstempel ablesen will, kann sich die Aktualität des Wertes als eigenen Sensor anzeigen lassen. Ein Template-Sensor, der die Minuten seit dem letzten Update ausgibt, macht ein träges Gerät auf einen Blick sichtbar:

template:
  - sensor:
      - name: "Flur Helligkeit Alter"
        unit_of_measurement: "min"
        state: >
          {{ ((as_timestamp(now()) - as_timestamp(states.sensor.flur_helligkeit.last_updated)) / 60) | round(0) }}

Der Sensor rechnet die Differenz aus aktueller Zeit und dem Zeitstempel last_updated des Helligkeitssensors in Minuten um 2. Wächst dieser Hilfssensor über längere Zeit an, hat der Helligkeitssensor wieder nicht gemeldet. Damit hast du ein sichtbares Signal statt einer Vermutung.

Die Korrekturen

Welche Korrektur passt, hängt vom Befund aus der Diagnose ab. Ich trenne deshalb fehlenden Wert und veralteten Wert sauber.

Liegt der fehlende Wert vor, ist die Ursache meist eine nicht erreichbare Entität oder eine Integration, die den Wert nicht liefert. Das solltest du zuerst beheben, nicht wegprogrammieren. Willst du die Automation trotzdem robust machen, kannst du der Bedingung beibringen, einen fehlenden Wert als “dunkel” zu werten. Das geschieht über ein value_template, das den Zustand vor der Prüfung verarbeitet:

conditions:
  - condition: numeric_state
    entity_id: sensor.flur_helligkeit
    below: 20
    value_template: "{{ float(state.state, -1) }}"

float(state.state, -1) versucht, den Zustand als Zahl zu lesen, und liefert minus eins, wenn das nicht gelingt. Minus eins ist kleiner als 20, also zählt ein fehlender Wert als dunkel. Das ist eine bewusste Entscheidung: Bei einem defekten oder getrennten Sensor geht das Licht an, statt auszubleiben. Ob dir “im Zweifel an” oder “im Zweifel aus” lieber ist, musst du selbst festlegen. Für einen Flur ist “im Zweifel an” meist die angenehmere Wahl, für eine Außenbeleuchtung mit Stromverbrauch kann es anders aussehen.

Liegt der veraltete Wert vor, hilft dieses Template allein nicht. Der Sensor liefert eine gültige Zahl, nur eine alte. Der saubere Weg ist, die Bedingung so zu formulieren, dass auch das Alter des Wertes einbezogen wird:

conditions:
  - condition: template
    value_template: >
      {{ states('sensor.flur_helligkeit') | float(-1) < 20
          or as_timestamp(now()) - as_timestamp(states.sensor.flur_helligkeit.last_updated) > 3600 }}

Die Bedingung gilt als erfüllt, wenn der Wert unter 20 liegt oder wenn er seit mehr als einer Stunde, also 3600 Sekunden, nicht mehr aktualisiert wurde. Der erste Teil behandelt den normalen Fall und den fehlenden Wert, der zweite Teil den veralteten Wert. Auch das ist eine Annahme: Ein Wert, der länger als eine Stunde alt ist, wird als nicht mehr vertrauenswürdig eingestuft. Die Stundengrenze musst du an dein Gerät und deinen Raum anpassen. Ein Sensor, der ohnehin nur alle zwei Stunden sendet, würde mit dieser Schwelle faktisch immer als dunkel gelten, und das wäre dann wieder falsch.

Diese Template-Lösung ist ein Pflaster, keine Reparatur. Sie verhindert, dass die Automation schweigt, aber sie ändert nichts daran, dass der Sensor zu selten meldet. Der eigentliche Fix ist, den Sensor dazu zu bringen, häufiger zu senden, oder einen Sensor zu verwenden, der das von Haus aus tut.

Der erste Ansatzpunkt ist die Meldekonfiguration des Geräts. Viele Zigbee-Integrationen erlauben es, pro Cluster einzustellen, ab welcher Wertänderung und in welchem Mindestabstand ein Gerät meldet. Bei einer trägen Helligkeitsmessung senkst du die Änderungsschwelle oder verkleinerst den Meldeabstand. Das kostet bei einem batteriebetriebenen Gerät Akku, weil häufiger gesendet wird 5. Ob und wie dein konkreter Sensor das unterstützt, hängt vom Gerät und von der Integration ab; bei ZHA ist die Meldekonfiguration über die Cluster-Verwaltung möglich, bei Zigbee2MQTT über die Reporting-Einstellungen der jeweiligen Entität.

Der zweite Ansatzpunkt ist ein Sensor, der für diesen Zweck besser passt. Ein netzversorgter Helligkeitssensor, der kontinuierlich oder in kurzen Abständen meldet, umgeht das Batterieproblem, weil ihn der Sendeabstand nicht an der Steckdose schmerzt. Er muss allerdings als eigenständige Entität vorhanden sein. Viele Kombi-Geräte bündeln den Helligkeitssensor im Bewegungsmelder und unterwerfen beide derselben sparsamen Melde-Logik; dann verlagert man das Problem nur.

Der dritte Ansatzpunkt ist, die Helligkeitsbedingung ganz zu entschärfen, wo sie keinen echten Nutzen bringt. Wenn die Lampe ohnehin wenig verbraucht und es nur darum geht, dass im Flur nie Dunkelheit herrscht, ist die Helligkeitsbedingung der Teil, der ausfällt, ohne dass der Nutzer es merkt. Dann ist es eine ehrliche Entscheidung, sie zu streichen und das Licht bei jeder Bewegung einzuschalten. Das ist kein Workaround, sondern die Feststellung, dass die Bedingung mehr Ausfall als Nutzen erzeugt.

Entscheidungskriterien

Welche Korrektur für dich richtig ist, lässt sich an drei Fragen festmachen.

Erstens: Was zeigt die Diagnose? Fehlender Wert bedeutet, zuerst Erreichbarkeit und Integration prüfen, dann erst das value_template als Absicherung. Veralteter Wert bedeutet, Meldekonfiguration oder Sensorwahl anfassen; die Template-Absicherung mit Zeitstempel ist die schnelle Zwischenlösung.

Zweitens: Was kostet ein Fehlauslöser? Geht das Licht im Zweifel an, obwohl es noch hell ist, ist der Schaden gering. Bleibt im Zweifel ein dunkler Flur oder eine unbeleuchtete Treppe, ist der Schaden größer. Die Entscheidung “im Zweifel an oder aus” solltest du ausdrücklich treffen und in der Automation dokumentieren, statt sie dem Zufall zu überlassen.

Drittens: Wie wichtig ist der Stromverbrauch? Bei einer netzversorgten LED im Flur ist häufigeres Einschalten billig, bei einer dauerhaft laufenden Außenbeleuchtung oder einem Heizstab nicht. Ein Gerät häufiger melden zu lassen, kostet wiederum Akku bei Batteriegeräten 5. Beide Kosten gegeneinander zu rechnen, ist sinnvoller als pauschal auf eine “bessere” Konfiguration zu drängen.

Grenzen dieser Diagnose

Diese Diagnose setzt voraus, dass der Trigger zuverlässig feuert und nur die Bedingung versagt. Wenn der Bewegungsmelder selbst aussetzt, etwa wegen Reichweite, Position oder eines toten Winkels, greifen die Schritte hier nicht. In dem Reddit-Fall war die Bewegung klar erkennbar und der Trigger funktionierte; das ist eine Voraussetzung, die du bei deiner eigenen Automation zuerst bestätigen musst 1.

Auch die Zahlen sind ein Einzelfall. Dass der Sensor “nur bei Änderung meldet”, ist die Beschreibung des Verfassers für sein konkretes Gerät und keine allgemeingültige Aussage über alle Zigbee-Sensoren 1. Welche Meldeschwelle und welcher Meldeabstand bei deinem Gerät gelten, musst du am Gerät selbst nachsehen. Die hier gezeigten Template-Werte, minus eins als Ersatz und eine Stunde als Alterungsgrenze, sind Beispiele, die du an deine Situation anpassen musst.

Schließlich ist die Template-Absicherung eine Entscheidung unter Unsicherheit. Sie behandelt einen fehlenden oder alten Wert so, als wäre es dunkel. Ob das in deinem Zuhause die richtige Annahme ist, hängt von dem Raum ab. Es gibt keine Konfiguration, die einen nicht gemeldeten Zustand in einen gemessenen verwandelt. Was sich herstellen lässt, ist eine Automation, deren Verhalten im Fehlerfall du selbst festgelegt hast statt dem Sensor überlassen.

Weiterführende Artikel

• Home Assistant: Smarthome-Ausfälle zuverlässig überwachen
• Home Assistant Apps: So erweiterst du dein Smart Home sinnvoll
• Solarstrom verkaufen: Wie die Einspeisevergütung wirklich funktioniert
• 3 Panels parallel und 40 A: Warum Ankers 6 mm²-Kabel trotzdem ausreichen
• Open-Source-Streamdeck selbst gebaut: Decky auf dem Elecrow CrowPanel 7 Zoll

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

• Shelly- und Smarthome-Komponenten ansehen
• LiFePO4-Speicher für Balkonkraftwerke ansehen
• KI- und Produktivitäts-Zubehör ansehen
• Starlink-Verfügbarkeit und Konditionen prüfen

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.

Häufige Fragen

Was beantwortet dieser Beitrag zu Bewegungs-Automation feuert nur manchmal: veralteter Helligkeitswert?

Er ordnet die genannten Quellen ein und übersetzt sie in Prüfpunkte für die eigene Entscheidung. Er ersetzt keine individuelle Planung, Beratung oder Wirtschaftlichkeitsrechnung.

Welche Angaben sollte ich vor einer Entscheidung selbst prüfen?

Entscheidend sind die eigenen Verbrauchs- und Nutzungsdaten, Kosten, technische Voraussetzungen und die aktuell geltenden Regeln. Die Quellen am Ende zeigen, welche Aussagen aus der Meldung stammen und wo die Grenzen der Einordnung liegen.

Sind die genannten Zahlen auf jeden Haushalt übertragbar?

Nein. Umfrage- und Marktwerte beschreiben Gruppen oder Zeitpunkte. Ob eine Maßnahme im Einzelfall passt, hängt von den konkreten Voraussetzungen vor Ort ab.

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Quellen

[1] Motion automation only fires when it feels like it, turned out the condition I wrote was unevaluable – Reddit r/homeautomation

[2] State and state object – Home Assistant Dokumentation

[3] Conditions – Home Assistant Dokumentation

[4] Sensor – Home Assistant Dokumentation

[5] Zigbee Home Automation (ZHA) – Home Assistant Dokumentation