5 Geheimtipps für bessere Home-Assistant-Automationen

Die üblichen Automation-Tipps kennt ihr wahrscheinlich schon – Zeitpläne, Anwesenheitserkennung, Szenen. Die gibt’s hier nicht. Stattdessen fünf Dinge, die kaum jemand nutzt, obwohl sie eure Automationen robuster, wartbarer und schlauer machen. Manche davon sind reine UI-Kniffe, bei einem wird’s etwas technischer – aber alles inklusive vollständigem, copy-paste-fertigem Code.

Kurzer Hinweis vorweg: Alle Beispiele nutzen die aktuelle YAML-Syntax mit triggers, conditions und actions (Plural, ohne platform:-Schlüssel). Falls ihr noch alte Automationen mit trigger:/platform: habt, funktionieren die weiterhin, aber neue Automationen solltet ihr in der aktuellen Syntax anlegen.

Passend zum Beitrag gibt’s auch ein Video, in dem ich alle fünf Tipps in knapp 10 Minuten zeige:

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

Tipp 1: Trigger-IDs statt mehrerer Automationen

Ein Klassiker in vielen Setups: Eine Automation schaltet die Lampe im Wohnzimmer ein, eine zweite schaltet sie wieder aus. Beide gehören inhaltlich zusammen, werden aber getrennt gepflegt – mit doppeltem Aufwand, sobald sich an der Logik was ändert.

Sauberer ist eine einzige Automation, die beide Trigger enthält und über die Trigger-ID unterscheidet, welcher Fall gerade eingetreten ist:

alias: "Lampe Wohnzimmer"
triggers:
  - trigger: state
    entity_id: binary_sensor.bewegung_wohnzimmer
    to: "on"
    id: "ein"
  - trigger: numeric_state
    entity_id: sensor.helligkeit_wohnzimmer
    above: 500
    id: "aus"
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: "ein"
        sequence:
          - action: light.turn_on
            target:
              entity_id: light.wohnzimmer
      - conditions:
          - condition: trigger
            id: "aus"
        sequence:
          - action: light.turn_off
            target:
              entity_id: light.wohnzimmer

Jeder Trigger bekommt eine eigene id. Im choose-Block fragt ihr dann per condition: trigger und id: ab, welcher Trigger ausgelöst hat, und führt die passende Sequenz aus.

Der eigentliche Vorteil zeigt sich erst, wenn sich was ändert: Wollt ihr zum Beispiel eine gemeinsame Bedingung ergänzen, die für Ein- und Ausschalten gelten soll – etwa „nur wenn wir zu Hause sind“ – müsst ihr sie nur einmal in der Automation einbauen, statt sie in zwei getrennten Automationen doppelt zu pflegen. Auch beim Debuggen ist es einfacher: Im Trace seht ihr sofort alles, was zur Lampe im Wohnzimmer gehört, an einem Ort.

Wann sich das lohnt: Immer dann, wenn mehrere Trigger zum selben „Anwendungsfall“ gehören – Licht ein/aus, Rollladen auf/zu, Heizung an/aus. Wenn die Trigger inhaltlich nichts miteinander zu tun haben, lohnt sich der Aufwand nicht, dann bleiben getrennte Automationen übersichtlicher.

Tipp 2: Modus der Automation bewusst definieren

Jede Automation hat einen Modus, der bestimmt, was passiert, wenn sie erneut getriggert wird, während sie noch läuft. Die meisten lassen den Standardwert stehen und wundern sich dann über unerwartetes Verhalten bei schnell aufeinanderfolgenden Triggern – etwa bei Bewegungsmeldern oder Türsensoren.

Home Assistant kennt vier Modi, die ihr im Pflegedialog jeder Automation unter „Modus ändern“ direkt auswählen könnt, ganz ohne YAML:

• Einzeln (Standard, single): Läuft die Automation gerade, wird ein erneuter Trigger ignoriert.
• Neu starten (restart): Läuft die Automation gerade und wird erneut getriggert, wird der laufende Durchlauf abgebrochen und komplett neu gestartet.
• Warteschlange (queued): Jeder Trigger wird nacheinander vollständig abgearbeitet, keiner geht verloren, keiner unterbricht einen anderen.
• Parallel (parallel): Mehrere Durchläufe laufen gleichzeitig, unabhängig voneinander.

Praxisbeispiel „Neu starten“: Eine „Licht aus nach 5 Minuten“-Automation auf Bewegungsmelder-Basis. Ohne restart würde bei erneuter Bewegung während der 5 Minuten nichts passieren – die erste Automation läuft ja noch. Mit restart fängt der 5-Minuten-Timer bei jeder neuen Bewegung wieder von vorne an, das Licht bleibt zuverlässig an, solange Bewegung erkannt wird.

alias: "Licht Flur aus nach Bewegung"
mode: restart
triggers:
  - trigger: state
    entity_id: binary_sensor.bewegung_flur
    to: "on"
actions:
  - action: light.turn_on
    target:
      entity_id: light.flur
  - delay:
      minutes: 5
  - action: light.turn_off
    target:
      entity_id: light.flur

Praxisbeispiel „Warteschlange“: Eine Automation, die Push-Benachrichtigungen verschickt oder Log-Einträge schreibt, wenn mehrere Ereignisse kurz hintereinander auftreten und keins davon verloren gehen soll – zum Beispiel bei mehreren Türklingel-Events. Mit queued wird jeder Durchlauf vollständig abgearbeitet, bevor der nächste startet.

Kurz zu „Einzeln“ und „Parallel“: „Einzeln“ passt für die meisten einfachen Automationen, bei denen ein zusätzlicher Trigger während der Laufzeit ohnehin nichts Sinnvolles beitragen würde. „Parallel“ ist eher die Ausnahme – sinnvoll etwa bei Automationen, die pro Person oder pro Raum unabhängig voneinander laufen sollen und sich gegenseitig nicht beeinflussen dürfen.

Tipp 3: Auf echte Ereignisse warten statt starrem Delay

In den Aktionen einer Automation gibt’s im Pflegedialog drei Warte-Optionen: „Eine Zeit warten“, „Auf einen Auslöser warten“ und „Auf ein Template warten“. Die meisten greifen automatisch zu „Eine Zeit warten“ (delay), weil es die naheliegendste Option ist – dabei ist sie oft nicht die robusteste.

delay wartet stur eine feste Zeit ab, egal was währenddessen passiert:

actions:
  - action: light.turn_on
    target:
      entity_id: light.flur
  - delay:
      seconds: 30
  - action: light.turn_off
    target:
      entity_id: light.flur

Problem dabei: Wenn die Bewegung länger dauert als 30 Sekunden, geht trotzdem nach 30 Sekunden das Licht aus – der Delay merkt nichts vom aktuellen Zustand.

„Auf einen Auslöser warten“ (wait_for_trigger) reagiert stattdessen auf ein echtes Ereignis:

actions:
  - action: light.turn_on
    target:
      entity_id: light.flur
  - wait_for_trigger:
      - trigger: state
        entity_id: binary_sensor.bewegung_flur
        to: "off"
        for:
          seconds: 30
  - action: light.turn_off
    target:
      entity_id: light.flur

Jetzt wartet die Automation, bis der Bewegungsmelder tatsächlich 30 Sekunden lang „keine Bewegung“ meldet – egal wie lange das dauert. Das Licht geht erst aus, wenn wirklich Ruhe ist, nicht nach einer geschätzten Zeitspanne.

„Auf ein Template warten“ (wait_for_template) funktioniert ähnlich, nur dass ihr statt eines konkreten Triggers eine Template-Bedingung angebt, auf deren Erfüllung gewartet wird:

actions:
  - wait_template: "{{ is_state('binary_sensor.bewegung_flur', 'off') }}"
    timeout:
      minutes: 10

Praktisch, wenn die Bedingung sich nicht sauber als einzelner Trigger formulieren lässt, sondern eine Kombination mehrerer Zustände ist. Der optionale timeout verhindert, dass eure Automation ewig hängen bleibt, falls die Bedingung nie eintritt.

Faustregel: Immer wenn ihr eine Wartezeit „schätzt“, weil ihr eigentlich auf ein Ereignis warten wollt, lohnt sich der Wechsel von „Eine Zeit warten“ zu einer der beiden anderen Optionen.

Tipp 4: Labels statt Areas für automationsübergreifende Logik

Areas (Bereiche) sind super, solange eure Logik sich an Räumen orientiert. Sobald ihr aber eine Automation braucht, die auf Geräte wirken soll, die über mehrere Räume verteilt sind, stoßen Areas an ihre Grenzen.

Beispiel: Weihnachtsbeleuchtung an mehreren Zwischensteckern im ganzen Haus – Wohnzimmer, Flur, Balkon. Klassisch bräuchtet ihr entweder eine Automation pro Raum oder müsstet alle Entity-IDs einzeln in einer Automation auflisten und bei jedem neuen Stecker die Automation wieder anfassen.

Mit Labels geht das eleganter. Vergebt allen relevanten Zwischensteckern (unter Einstellungen → Geräte & Dienste → Entitäten → Entität bearbeiten → Label) das Label weihnachtsbeleuchtung, egal in welchem Raum sie stehen:

alias: "Weihnachtsbeleuchtung Zeitplan"
triggers:
  - trigger: time
    at: "16:30:00"
actions:
  - action: switch.turn_on
    target:
      label_id: weihnachtsbeleuchtung

target: label_id: wirkt auf alle Entities mit diesem Label, unabhängig von Area oder Device. Kommt im nächsten Jahr ein neuer Zwischenstecker dazu – zum Beispiel am Gartenzaun – gebt ihr ihm einfach das Label. Die Automation selbst bleibt unverändert.

Weitere Einsatzzwecke für dasselbe Prinzip: Ein Label nachtmodus für alle Lichter, die beim Zubettgehen gedimmt werden sollen, unabhängig vom Raum. Oder ein Label energiefresser für alle Geräte, die in eine Verbrauchs-Automation einfließen sollen. Überall dort, wo die Zugehörigkeit zu einer Logik wichtiger ist als die Zugehörigkeit zu einem Raum, sind Labels die bessere Wahl als Areas.

Tipp 5: Das Trigger-Objekt clever nutzen

Home Assistant reicht bei jedem Trigger ein trigger-Objekt an eure Conditions und Actions durch, das mehr Informationen enthält, als die meisten nutzen. Zwei besonders nützliche Anwendungen:

Cooldown ohne extra Helfer

Wollt ihr verhindern, dass eine Automation zu oft hintereinander läuft – etwa „nicht öfter als alle sechs Stunden“ – baut ihr dafür meistens einen zusätzlichen Helfer: Input-Boolean, Timer oder Ähnliches, den ihr in der Automation selbst setzen und wieder zurücksetzen müsst.

Das ist gar nicht nötig. Home Assistant merkt sich ohnehin, wann eine Automation zuletzt gelaufen ist – über das Attribut last_triggered, abrufbar unter states.automation.<entity_id>.attributes.last_triggered. Das lässt sich direkt als Condition abfragen:

{{ as_timestamp(now()) - as_timestamp(states.automation.wischen_nach_sauna.attributes.last_triggered, default=0) > 21600 }}

21600 Sekunden entsprechen sechs Stunden. Die Automation „Wischen nach Sauna“ darf mit dieser Condition also nicht öfter als alle sechs Stunden laufen.

Eingebaut in eine vollständige Automation sieht das so aus:

alias: "Wischen nach Sauna"
triggers:
  - trigger: state
    entity_id: binary_sensor.sauna_tuer
    to: "off"
conditions:
  - condition: template
    value_template: "{{ as_timestamp(now()) - as_timestamp(states.automation.wischen_nach_sauna.attributes.last_triggered, default=0) > 21600 }}"
actions:
  - action: vacuum.start
    target:
      entity_id: vacuum.saugroboter

Wichtig: Den default=0 nicht vergessen. Ohne diesen Fallback ist last_triggered beim allerersten Lauf der Automation noch None, und as_timestamp(None) wirft einen Fehler – die Condition crasht, statt einfach false zu ergeben.

Richtung der Änderung erkennen

Bei numerischen Sensor-Triggern lässt sich direkt in der Condition prüfen, ob der Wert gestiegen oder gefallen ist, statt zwei separate Automationen oder zusätzliche Helfer zu bauen. Home Assistant stellt dafür trigger.to_state (neuer Wert) und trigger.from_state (alter Wert) bereit:

{{ trigger.to_state.state | int(0) > trigger.from_state.state | int(0) }}

Praktisch zum Beispiel bei Verbrauchsmessung, wenn ihr nur triggern wollt, sobald der Verbrauch steigt, nicht bei jeder Schwankung nach unten:

alias: "Warnung bei steigendem Verbrauch"
triggers:
  - trigger: state
    entity_id: sensor.stromverbrauch_aktuell
conditions:
  - condition: template
    value_template: "{{ trigger.to_state.state | int(0) > trigger.from_state.state | int(0) }}"
  - condition: numeric_state
    entity_id: sensor.stromverbrauch_aktuell
    above: 3000
actions:
  - action: notify.mobile_app
    data:
      message: "Stromverbrauch steigt und liegt aktuell über 3000 Watt"

Auch hier wichtig: Den Fallback | int(0) nicht vergessen. Kommt mal ein unknown– oder unavailable-Status als State rein (zum Beispiel direkt nach einem Neustart oder bei einem kurzzeitigen Verbindungsabbruch des Sensors), würde int() ohne Fallback einen Fehler werfen und die Condition zum Absturz bringen.

Beide Beispiele funktionieren nach demselben Prinzip: Das Trigger-Objekt trägt deutlich mehr Kontext, als in den meisten Automationen genutzt wird. Lohnt sich, da mal reinzuschauen – gerade trigger.to_state und trigger.from_state lassen sich auf viele andere Fälle übertragen, nicht nur auf Verbrauchswerte.

Fazit

Keiner dieser fünf Tipps braucht neue Integrationen oder zusätzliche Hardware – es sind alles Bordmittel von Home Assistant, die im Alltag einfach zu selten genutzt werden. Wenn ihr einen eigenen Geheimtipp habt, der hier fehlt: Schreibt ihn in die Kommentare unter dem Video oder in die Community, vielleicht wird’s Teil 2.