KNX-Bewegungsmelder-Automationen in Home Assistant

Als bewegungsgesteuertes Licht bei mir das erste Mal wirklich funktionierte, fühlte es sich nicht clever an. Es fühlte sich selbstverständlich an — ich ging in einen dunklen Flur, und das Licht war schon an, bevor ich überhaupt registriert hatte, dass es dunkel war. Das ist die Messlatte. Nicht smart, einfach aufmerksam. Mit sieben KNX-Bewegungsmeldern dorthin zu kommen kostete weniger Code, als ich dachte, und eine Erkenntnis, die ich gern am ersten Tag gehabt hätte.

Das ist Teil 05 der Serie. Die früheren Teile decken das langweilige, aber tragende Fundament ab: Home Assistant in Docker betreiben und HACS einrichten. Hier setze ich voraus, dass HA läuft, KNX spricht, und du einfach willst, dass das Licht sich benimmt.

Ein Sensor, zwei Aufgaben, zwei Adressen

Hier ist der Fehler, den ich gemacht habe, und er ist der ganze Grund für diesen Beitrag. KNX stellt jeden Bewegungsmelder Home Assistant als binary_sensor mit device_class: motion bereit, gespeist von einem KNX-Gruppenadress-Statusobjekt, das du in knx.yaml mit einer state_address pro Sensor konfigurierst. Klingt einfach. Also habe ich alle sieben Sensoren mit je einer Gruppenadresse verdrahtet und sowohl die Lichtautomation als auch die Präsenzlogik auf dasselbe Signal gerichtet.

Das funktioniert genau so lange, bis die beiden sich unterschiedlich verhalten sollen. Licht soll auf das kleinste Zucken reagieren, sofort, großzügig. Präsenz und Sicherheit wollen das Gegenteil: einen Entprell-Filter, ein Gnadenfenster, etwas Skepsis, bevor sie sich festlegen. Wenn beide auf derselben Gruppenadresse reiten, verformt jede Änderung an dem einen still das andere. Ich habe einen Abend damit verbracht, in Home Assistant Bedingungen zu verzweigen, um aus einem Signal zwei Bedeutungen zu pressen.

Die Lösung steckt gar nicht in Home Assistant. Sie steckt in ETS: gib jedem physischen PIR eine zweite Gruppenadresse. Eine steuert das Komfortlicht, die andere speist Präsenz und den Alarmpfad. Ich nutze eine flache Konvention — 5/4/x fürs Licht, 5/5/x für den Sicherheitspfad, 5/6/x reserviert für generische Präsenz. Jetzt sind "das Licht reagiert" und "die Sicherheit reagiert" wirklich getrennte Ereignisse. Die Lichtautomationen unten berühren die Alarmseite nie, und genau so will ich es — dieser Beitrag dreht sich strikt um Licht und Präsenz, die Alarm-Interna bleiben bewusst außen vor.

Erst die dumme Version

Fang mit der An/Aus-Automation an, die jeder schreibt. Bewegung geht von aus auf an, Licht an. Bewegung geht aus, Licht aus. Zwei Automationen, ein Sensor und ein Licht:

# Motion ON -> light on; motion OFF for 5 min -> light off
- alias: "Hallway light on motion"
  triggers:
    - trigger: state
      entity_id: binary_sensor.flur_motion
      from: "off"
      to: "on"
  actions:
    - action: light.turn_on
      target: { entity_id: light.flur }
      data: { brightness_pct: 100 }
  mode: single

- alias: "Hallway light off after 5 min"
  triggers:
    - trigger: state
      entity_id: binary_sensor.flur_motion
      from: "on"
      to: "off"
      for: { minutes: 5 }
  actions:
    - action: light.turn_off
      target: { entity_id: light.flur }
  mode: single

Zwei Dinge leisten hier stille Arbeit. mode: single bewahrt die Automation davor, sich in einen Sturm zu retriggern, wenn ein Sensor flattert — kombiniere es mit max_exceeded: silent, damit die Überlappung geschluckt wird, ohne dein Log zu fluten. Und die Aus-Seite triggert, wenn der Sensor auf aus geht, mit einem for: von fünf Minuten, nicht sofort. Dieses for: ist die wichtigste Zahl im ganzen Aufbau.

Das ehrliche Scheitern: Licht geht aus, während du noch da bist

Jeder Bewegungslicht-Aufbau scheitert in der ersten Woche auf dieselbe Art: du stehst völlig still und liest etwas, der Sensor sieht dich nicht mehr, und der Raum wird dunkel. Es ist das klassische Versagen, und es ist zum Verrücktwerden, weil das Haus sich anfühlt, als würde es schmollen.

Der Instinkt ist, den Sensor zu bekämpfen — schnelleres Polling, ein empfindlicherer PIR, ausgefeiltere Präsenzerkennung. Lass es. Die Lösung ist fast immer, die Aus-Verzögerung zu verlängern. Ich habe mich auf eine kleine Taxonomie festgelegt, die abbildet, wie lange Menschen tatsächlich in einem Raum verweilen: kurzes Halten von etwa 30 Sekunden bis einer Minute für kleine Durchgangsräume, mittel von 3 bis 5 Minuten für Flure und Treppen, und lang von 10 bis 15 Minuten für Wohnzimmer und Büros, in denen man still sitzt. Ein Flur bekommt fünf Minuten. Ein Lesesessel bekommt keine dreißig Sekunden.

Ich gebe dem Trigger außerdem ein Gnadenfenster von 2 bis 5 Sekunden, bevor er handelt, damit ein einzelnes Flackern auf der Leitung den Raum nicht zum Stroboskop macht. Günstige Versicherung.

Die Feinheiten, die es absichtsvoll wirken lassen

Sobald das Licht sich benimmt, kannst du die Teile ergänzen, die es so wirken lassen, als wäre das Haus gestaltet und nicht nur geskriptet. Keines davon ist schwer; sie sind nur durchdacht.

Treppe nur nachts. Treppenhaus- und Flurlichter fahren nur im Dunkeln automatisch hoch. Eine condition: sun mit after sunset / before sunrise sperrt sie, damit sie nicht sinnlos mittags angehen, wenn ohnehin Tageslicht da ist.

Helligkeit nach Tageszeit. Eine feste Helligkeit verrät, dass eine Maschine dein Haus geschrieben hat. Volle Pulle um 3 Uhr nachts ist feindselig. Ich steuere die Helligkeit mit einem choose:-Block nach Zeitfenstern — grob 30% spät nachts (22:00 bis 06:00), 70% am frühen Morgen (06:00 bis 08:00) und 100% tagsüber:

# Time-of-day brightness with choose:
actions:
  - choose:
      - conditions:
          - condition: time
            after: "22:00:00"
            before: "06:00:00"
        sequence:
          - action: light.turn_on
            target: { entity_id: light.stairs }
            data: { brightness_pct: 30 }
    default:
      - action: light.turn_on
        target: { entity_id: light.stairs }
        data: { brightness_pct: 100 }

Pfadbeleuchtung die Treppe hinauf. Mein Lieblingstrick. Die Treppenautomation verkettet zwei Lichter mit einem delay: von etwa drei Sekunden dazwischen — erst das untere Licht, dann die Etage darüber einen Takt später — sodass das Licht vor dir die Treppe hinaufgeht, statt den ganzen Schacht auf einmal zu fluten. Eine Kleinigkeit, die jedes Mal auffällt.

Ein Energie-Cutoff für die ganze Zone. Worauf ich am stolzesten bin, weil hier die naive Version still Strom verschwendet. Statt dass jedes Licht für sich auszählt, triggert eine Energiespar-Automation auf eine Liste von Bewegungsmeldern, die alle für eine Haltezeit auf aus gehen — ich nutze zehn Minuten über die Gruppe — und stellt dann in ihren Bedingungen erneut fest, dass jeder einzelne Sensor der Zone noch auf aus steht, bevor sie irgendetwas abschaltet. Diese UND-über-alle-Absicherung ist entscheidend: ein zurückspringender Sensor soll nicht eine ganze Etage erleuchtet halten, und ein still gewordener Sensor soll keine belegte Zone in Dunkelheit stürzen. Licht fällt nur, wenn die Zone wirklich leer ist. Es über area_id statt über jede einzelne Leuchte zu steuern bedeutet, dass eine Automation eine ganze Zone auf einmal abschalten kann.

Ein günstiger Präsenzwert, fast geschenkt

Hier ist eine Kleinigkeit, nach der ich immer wieder greife. Du brauchst nicht immer eine echte Präsenz-Plattform, um "war kürzlich jemand in der Küche?" zu beantworten. Gib jedem Bereich ein input_datetime-Helper und füge pro Bewegungsmelder eine einzeilige Automation hinzu, die beim Übergang auf an die aktuelle Zeit hineinstempelt. Jetzt hast du pro Bereich einen "letzte Bewegung gesehen"-Wert, den du überall auslesen kannst — in Bedingungen, auf einem Dashboard, in einer Benachrichtigung — ohne irgendetwas zu installieren.

Es ist keine Belegung im strengen Sinn; es ist ein Zeitstempel. Aber "zuletzt vor zwei Minuten gesehen" beantwortet neun von zehn der Fragen, die ich meinem Haus tatsächlich stelle, und kostet einen Helper und eine winzige Automation pro Raum.

Zum Feintuning all dessen pack die Sensoren auf eine Lovelace-type: entities-Karte, damit du den Live-Bewegungszustand pro Bereich beobachten kannst, während du an den Aus-Verzögerungen drehst. Einen Sensor eine ganze Sekunde früher auf off sitzen zu sehen, als du erwartet hast, ist die Art, wie du lernst, welcher Raum ein längeres for: braucht.

Was ich meinem früheren Ich sagen würde

Zwei Dinge. Erstens: trenne das Signal am Bus, nicht in YAML. Eine zweite Gruppenadresse pro Sensor sind fünf Minuten in ETS, und sie erspart dir, einen Turm aus Bedingungen zu bauen, der versucht, ein Ereignis zwei widersprüchliche Dinge bedeuten zu lassen. Zweitens: die gesamte Qualität von Bewegungslicht liegt in der Aus-Verzögerung, nicht im An-Trigger. Ein Licht einzuschalten ist trivial; es im richtigen Moment auszuschalten, nach dem richtigen Halten, nur wenn der Raum wirklich leer ist, ist das ganze Handwerk.

Durchgehend habe ich die Entity-Namen bewusst generisch gehalten — flur, stairs, hallway — und das Gruppenadress-Schema abstrakt. Der eigentliche Grund, warum ein Lichtsignal und ein Sicherheitssignal getrennte Adressen bekommen, ist der Alarmpfad, der auf der anderen liegt, und das ist eine Geschichte für einen Teil dieser Serie, der die Interna sehr bewusst auslässt. Fürs Licht ist das Rezept oben das Ganze. Der nächste Teil setzt dort an, wohin die zweite Gruppenadresse führt.