"Letzte Bewegung"-Sensor in Home Assistant: Bewegungszeitstempel pro Raum mit input_datetime

Ein klassischer Bewegungsmelder kann nur zwei Dinge: gerade Bewegung oder gerade keine. Was er von Haus aus nicht beantwortet, ist die viel nützlichere Frage — wann war zuletzt jemand in diesem Raum? Genau diese Information ist das Fundament für jede Anwesenheits-Heuristik: "Haus leer seit zwei Stunden", "im Gang seit dem Frühstück niemand mehr", "war heute überhaupt jemand in der Garage".

Mein erster Reflex war, dafür teure mmWave-Presence-Sensoren zu kaufen. Dabei reichen die simplen PIR-Melder, die ohnehin schon hängen — man muss nur ihren letzten on-Moment irgendwo speichern. In Home Assistant geht das mit einem input_datetime-Helper pro Raum und einer trivialen Automation. Kein Lichtschalt-Tutorial, sondern ein reines Daten-Muster, das ich inzwischen über das ganze Haus ausgerollt habe.

Warum input_datetime statt last_changed?

Berechtigter Einwand: Jeder Sensor hat doch ein last_changed-Attribut. Das Problem ist, dass last_changed bei jeder Zustandsänderung kippt — auch beim Wechsel von on zurück auf off. Du bekommst also den Zeitpunkt der letzten Änderung, nicht der letzten Bewegung. Und es überlebt keinen Neustart von Home Assistant sauber: nach einem Reboot steht der Sensor frisch auf off, last_changed ist der Boot-Zeitpunkt, deine Historie ist weg.

Ein input_datetime-Helper löst beides. Wir schreiben den Zeitstempel ausschließlich beim Übergang nach on, der Wert ist persistent (er übersteht Neustarts) und er ist eine echte, abfragbare Entität, die du in Templates, Bedingungen und auf dem Dashboard wie jeden anderen Sensor benutzen kannst.

Schritt 1 — pro Raum einen Helper anlegen

Lege unter Einstellungen → Geräte & Dienste → Helfer für jeden Raum einen input_datetime an, bei dem Datum und Zeit beide aktiviert sind. Die Benennung halte ich konsequent gleich — letzte_bewegung_<raum> —, weil das die spätere Skalierung trivial macht: neue Entität, gleiches Schema. Wer lieber per YAML konfiguriert, schreibt dasselbe in die configuration.yaml.

input_datetime:
  letzte_bewegung_gang:
    name: Letzte Bewegung Gang
    has_date: true
    has_time: true
  letzte_bewegung_garage:
    name: Letzte Bewegung Garage
    has_date: true
    has_time: true

Wichtig ist nur, dass beide Flags gesetzt sind — ohne has_time verlierst du die Uhrzeit und das ganze Muster wird stumpf.

Schritt 2 — bei jeder Bewegung den Zeitstempel schreiben

Jetzt die eigentliche Logik, und sie ist erfreulich kurz: eine Automation, die beim Übergang des Bewegungsmelders nach on die aktuelle Zeit per input_datetime.set_datetime in den passenden Helper schreibt. Ich triggere bewusst nur auf to: 'on' — das off-Event interessiert uns nicht, wir wollen ja den letzten Bewegungs-Beginn festhalten.

- id: '1711200000001'
  alias: Letzte Bewegung Gang
  triggers:
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_gang
    to: 'on'
  actions:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.letzte_bewegung_gang
    data:
      datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
  mode: single

Das now().strftime(...) formatiert die lokale Zeit in genau das Format, das set_datetime erwartet. mode: single genügt vollkommen: die Aktion dauert Millisekunden, parallele Läufe sind irrelevant.

Schritt 3 — dasselbe Muster über mehrere Räume

Der eigentliche Charme ist die Wiederholbarkeit. Für jeden weiteren Raum kopierst du die Automation und tauschst nur zwei Dinge: die entity_id des Bewegungsmelders und die entity_id des Helpers. Gleiches Schema, anderer Raum.

- id: '1711200000007'
  alias: Letzte Bewegung Garage
  triggers:
  - trigger: state
    entity_id: binary_sensor.bewegungsmelder_garage
    to: 'on'
  actions:
  - action: input_datetime.set_datetime
    target:
      entity_id: input_datetime.letzte_bewegung_garage
    data:
      datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
  mode: single

Bei mir laufen so rund ein Dutzend dieser Automationen parallel — eine pro PIR. Wer es kompakter mag, kann das auch als eine einzige Automation mit mehreren Triggern und einem Template über trigger.to_state bauen; ich bevorzuge die Eine-pro-Raum-Variante, weil sie in der UI sofort lesbar bleibt und man einzelne Räume gezielt deaktivieren kann.

Schritt 4 — relative Zeit aufs Dashboard

Der rohe Zeitstempel "2026-07-17 14:32:10" ist für ein Dashboard unhandlich — interessant ist "vor 12 Minuten". Dafür gibt es in Home Assistant die Template-Funktion relative_time(), die einen datetime in eine menschenlesbare Spanne übersetzt. In einer Markdown-Karte sieht das so aus:

type: markdown
content: >
  ## Letzte Bewegung

  - **Gang:** vor {{ relative_time(states('input_datetime.letzte_bewegung_gang') | as_datetime) }}

  - **Garage:** vor {{ relative_time(states('input_datetime.letzte_bewegung_garage') | as_datetime) }}

  - **Wohnzimmer:** vor {{ relative_time(states('input_datetime.letzte_bewegung_wohnzimmer') | as_datetime) }}

Das as_datetime wandelt den String-State in ein echtes datetime-Objekt, das relative_time verarbeiten kann. Ergebnis ist eine kompakte Übersicht — "Gang: vor 3 Minuten, Garage: vor 6 Stunden" — die auf einen Blick verrät, wo zuletzt Leben war.

Wozu die Daten taugen

Sobald die Zeitstempel existieren, öffnen sich die spannenden Automationen. Eine "Haus leer"-Heuristik: wenn die jüngste aller letzte_bewegung_*-Zeiten älter als z. B. 30 Minuten ist, gilt das Haus als unbewohnt — eine billige Anwesenheitserkennung ohne mmWave-Sensor. Oder raumbezogene Trigger: Heizung in einem Raum erst hochfahren, wenn dort in der letzten Stunde Bewegung war. Wer das Modbus-/Sensordatum-Denken mag, findet die gleiche "erst Daten, dann Logik"-Haltung auch in meinem Post zur PV-String-Anomalie-Erkennung wieder.

Häufige Fragen

Warum nicht einfach das last_changed-Attribut des Sensors nutzen?

Weil last_changed bei jeder Zustandsänderung kippt — auch beim Wechsel von on auf off — und einen Neustart nicht überlebt: nach einem Reboot steht der Sensor frisch auf off und last_changed ist der Boot-Zeitpunkt. Der input_datetime-Helper speichert dagegen ausschließlich den letzten on-Moment, ist persistent und überlebt Neustarts.

Überlebt der Wert einen Neustart von Home Assistant?

Ja. input_datetime-Helper sind persistent — ihr letzter gesetzter Wert wird gespeichert und nach einem Reboot wiederhergestellt. Genau das ist einer der Hauptvorteile gegenüber roh ausgelesenen Sensor-Attributen, die nach einem Neustart bei null anfangen.

Brauche ich für jeden Raum eine eigene Automation?

Nein, aber es ist die lesbarste Variante. Du kannst auch eine einzige Automation mit mehreren Triggern bauen und über trigger.to_state den passenden Helper aus einem Mapping wählen. Ich nehme bewusst eine Automation pro Raum, weil sie in der UI sofort verständlich bleibt und sich einzeln deaktivieren lässt.

Funktioniert das mit jedem Bewegungsmelder?

Mit jedem, der in Home Assistant als binary_sensor mit den Zuständen on/off auftaucht — egal ob Zigbee-PIR, KNX-Präsenzmelder oder WLAN-Sensor. Das Muster kennt die Hardware nicht, es reagiert nur auf den on-Übergang. Bei KNX-Meldern, die ich auch fürs Lichtschalten nutze, läuft dieselbe Zeitstempel-Automation problemlos parallel.