Der Saugroboter soll im Sommer früher starten als im Winter. Die Ruhezeit des Roborock endet um acht Uhr – aber am Wochenende bitte um zehn. Wer solche Zeiten bisher ändern wollte, öffnete entweder die Hersteller-App oder schrieb einen input_datetime-Helfer, der die eigentliche Geräteeinstellung nur abbildete, nicht steuerte. Seit Home Assistant die time-Domäne kennt, ist das vorbei: Geräte exponieren ihre Zeiteinstellungen direkt als Entität – schreib- und automatisierbar.
Das Problem mit gespiegelten Zeiten
Ein Blick in meine Entitätenliste zeigt zwei unscheinbare Kandidaten:
time.roborock_s6_maxv_bitte_nicht_storen_beginn → 22:00:00
time.roborock_s6_maxv_bitte_nicht_storen_ende → 08:00:00
Das sind keine Helfer. Das sind echte Geräteeinstellungen, die über die Cloud-API des Roborock gesetzt werden. Ändert man den Wert in Home Assistant, ändert sich die Einstellung im Gerät – und umgekehrt.
Der Unterschied zu einem input_datetime ist fundamental. Ein Helfer speichert eine Zahl in Home Assistant und braucht immer eine zusätzliche Automation, die diese Zahl irgendwohin überträgt. Eine time-Entität ist die Einstellung. Kein Spiegel, kein Synchronisierungsproblem, kein Auseinanderdriften nach einem Neustart.
Schritt 1: Den Zustand sichtbar machen
Bevor automatisiert wird, gehört die Entität aufs Dashboard. Die schlichte Entitätenkarte genügt und bietet direkt einen Zeitwähler:
type: entities
title: Roborock Ruhezeit
entities:
- entity: time.roborock_s6_maxv_bitte_nicht_storen_beginn
name: Ruhe ab
- entity: time.roborock_s6_maxv_bitte_nicht_storen_ende
name: Ruhe bis
Ein Tipp auf das Feld öffnet den Zeitwähler. Der Wert wandert unmittelbar ins Gerät. Für Mitbewohnende, die keine Automationen anfassen sollen, ist das der eleganteste Zugang.
Schritt 2: Zeiten automatisch verschieben
Interessant wird es, wenn Home Assistant die Zeiten selbst setzt. Die Aktion heisst time.set_value und erwartet einen String im Format HH:MM:SS.
alias: Ruhezeit Wochenende
triggers:
- trigger: time
at: "03:00:00"
conditions:
- condition: time
weekday:
- sat
- sun
actions:
- action: time.set_value
target:
entity_id: time.roborock_s6_maxv_bitte_nicht_storen_ende
data:
time: "10:00:00"
mode: single
Das Gegenstück am Montagmorgen setzt den Wert zurück auf 08:00:00. Wer keine zwei Automationen mag, nutzt eine einzige mit einem Template:
actions:
- action: time.set_value
target:
entity_id: time.roborock_s6_maxv_bitte_nicht_storen_ende
data:
time: >-
{{ '10:00:00' if now().weekday() >= 5 else '08:00:00' }}
Schritt 3: Zeiten an die Sonne koppeln
Der wirklich befriedigende Anwendungsfall: Die Ruhezeit beginnt nicht starr um 22 Uhr, sondern eine Stunde nach Sonnenuntergang. Im Hochsommer heisst das 22:30 Uhr, im Dezember bereits 17:45 Uhr.
alias: Ruhezeit folgt der Sonne
triggers:
- trigger: time
at: "12:00:00"
actions:
- action: time.set_value
target:
entity_id: time.roborock_s6_maxv_bitte_nicht_storen_beginn
data:
time: >-
{{ (state_attr('sun.sun','next_setting') | as_datetime
| as_local + timedelta(hours=1)).strftime('%H:%M:%S') }}
mode: single
Wichtig ist as_local: next_setting liefert UTC. Ohne Konvertierung landet die Ruhezeit im Sommer zwei Stunden zu früh – ein Fehler, der erstaunlich lange unentdeckt bleibt, weil das Ergebnis plausibel aussieht.
Der Zeitwert wird dabei als reiner Zeitpunkt ohne Datum gespeichert, der Zustand der Entität lautet schlicht 22:00:00. Für Templates heisst das: Ein direkter Vergleich mit now() funktioniert nicht, weil dort ein vollständiger Zeitstempel steht. Wer prüfen will, ob die Ruhezeit gerade aktiv ist, greift auf states('time.…') als String zu und vergleicht mit now().strftime('%H:%M:%S') – solange keine Mitternachtsgrenze überschritten wird, genügt das. Andernfalls lohnt sich ein Template-Binärsensor, der beide Enden sauber berücksichtigt.
Ein zweiter Vorteil zeigt sich beim Backup. Weil time-Entitäten ihren Wert im Gerät halten, überlebt die Konfiguration auch eine Neuinstallation von Home Assistant. Helfer hingegen liegen im Storage-Verzeichnis und sind nach einem missglückten Restore schlicht weg – mit ihnen die sorgfältig eingestellten Zeiten.
Fallstricke
Nicht jede time-Entität ist schreibbar. Manche Integrationen liefern sie schreibgeschützt; erkennbar daran, dass time.set_value mit einer Fehlermeldung quittiert. Ein Blick in die Entwicklerwerkzeuge unter «Zustände» hilft: Fehlt das Attribut editable oder reagiert die Entität nicht, ist es eine reine Anzeige.
Zweitens: Cloud-gebundene Geräte wie der Roborock quittieren time.set_value erst nach einem Roundtrip zum Server. Bei Verbindungsproblemen wird der Wert nicht gesetzt, ohne dass die Automation scheitert. Wer sich darauf verlässt, baut eine state-Bedingung ein, die den tatsächlichen Wert nach dreissig Sekunden prüft.
Und drittens: time ersetzt keine Zeitpläne. Für wiederkehrende Wochenpläne bleibt der Schedule-Helfer das bessere Werkzeug, wie im Beitrag zu Schedule-Helfern in HA gezeigt. Die time-Domäne ist für einzelne, gerätegebundene Zeitpunkte gedacht.
Fazit
Die time-Domäne ist eine dieser stillen Verbesserungen, die keine Release-Schlagzeile bekommen und trotzdem YAML einsparen. Statt Geräteeinstellungen in Helfern nachzubauen, steuert man sie direkt. Prüfen Sie Ihre Entitätenliste mit dem Filter time. – die Chancen stehen gut, dass dort seit Monaten Einstellungen liegen, die nur darauf warten, endlich automatisiert zu werden.