Home Assistant Blueprints: Warum ich eine Automation einmal schreibe und siebenmal benutze

Es gibt einen Moment im Leben jedes Home-Assistant-Nutzers, an dem man merkt, dass man dieselbe Automation zum fünften Mal kopiert und nur den Raumnamen ausgetauscht hat. Bei mir war das die Heizung. Sieben Räume, jeweils fast identische Logik, und jede kleine Änderung musste siebenmal gemacht werden. Irgendwann stimmt eine Kopie nicht mehr mit den anderen überein, und man sucht lange, warum ein Raum sich anders verhält.

Die Lösung heißt Blueprint. In diesem Artikel zeige ich, wie ich damit arbeite und worauf ich dabei achte. Wie die Heizung selbst aufgebaut ist, steht im Artikel zur Heizungssteuerung, hier geht es um das Prinzip dahinter.

Was ein Blueprint ist

Ein Blueprint ist eine Automation mit Lücken. Statt feste Entitäten einzutragen, definiert ihr Eingaben (Inputs): „Hier kommt der Thermostat hin“, „hier der Zeitplan“, „hier die Temperatur“. Aus dem Blueprint erzeugt ihr dann beliebig viele Automationen, die jeweils eigene Werte für diese Eingaben bekommen. Ändert ihr später den Blueprint, ändert sich das Verhalten aller daraus erzeugten Automationen.

Das ist wie eine Vorlage in einer Textverarbeitung: Aufbau einmal pflegen, Inhalte pro Instanz verschieden.

Das Grundgerüst

So sieht ein stark vereinfachter Blueprint aus. Er schaltet ein Thermostat nach einem Zeitplan zwischen zwei Temperaturen um:

blueprint:
  name: Raumheizung nach Zeitplan
  description: Setzt die Solltemperatur passend zum Zeitplan.
  domain: automation
  input:
    thermostat:
      name: Thermostat
      selector:
        entity:
          domain: climate
    zeitplan:
      name: Zeitplan
      selector:
        entity:
          domain: schedule
    tagtemperatur:
      name: Tagtemperatur
      selector:
        entity:
          domain: input_number
    absenktemperatur:
      name: Absenktemperatur
      selector:
        entity:
          domain: input_number

mode: single

variables:
  zeitplan_entity: !input zeitplan
  tag_entity: !input tagtemperatur
  absenk_entity: !input absenktemperatur

triggers:
  - trigger: state
    entity_id: !input zeitplan

actions:
  - action: climate.set_temperature
    target:
      entity_id: !input thermostat
    data:
      temperature: >-
        {{ states(tag_entity if is_state(zeitplan_entity, 'on') else absenk_entity) | float(19) }}

Das Beispiel ist bewusst kurz. In der Praxis habe ich mehr Eingaben, aber der Kern ist derselbe: Selektoren statt feste Namen.

Variablen für Eingaben

Die häufigste Stolperfalle beim ersten Blueprint: Ihr könnt !input nicht direkt in einem Jinja-Ausdruck verwenden. Stattdessen holt ihr den Wert im Block variables: in eine Variable (siehe oben) und benutzt dann diese im Template. Der Standardwert float(19) fängt zusätzlich den Fall ab, dass ein Helfer einmal unknown ist.

Regel 1: Entity-IDs, nicht Geräte-IDs

Der Automationseditor bietet gern an, ein Gerät auszuwählen. Dabei landet eine kryptische device_id im YAML. Das ist bequem, aber fragil: Die ID hängt am Gerät, nicht an eurem Namen dafür. Wenn ihr ein Gerät austauscht oder neu einbindet, ist die ID weg, und die Automation läuft ins Leere, oft ohne Fehlermeldung.

Ich nehme deshalb grundsätzlich entity_id. Eine Entität könnt ihr bei einem Gerätetausch einfach umbenennen oder neu zuweisen, und alles bleibt lesbar. In Blueprints erzwingen die Selektoren das ohnehin.

Regel 2: Werte gehören in Helfer

Wer Temperaturen und Zeiten fest in die Automation schreibt, muss die Automation anfassen, wenn er sie ändern will. Ich lege solche Werte deshalb in Helfer (zum Beispiel input_number und schedule) und gebe sie dem Blueprint als Eingabe mit. Das Ergebnis: Wenn ich im Winter die Tagtemperatur im Wohnzimmer ändern will, ändere ich einen Wert in einem Dashboard. Der Blueprint bleibt unberührt.

Das klingt nach Kleinkram, erspart aber auf lange Sicht viele Eingriffe ins YAML, und die macht man bekanntlich am liebsten nie wieder an einem Sonntagabend.

Regel 3: Nur an Schaltpunkten schalten

Eine Design-Entscheidung, die sich bei mir sehr bewährt hat: Die Automation reagiert nur dann, wenn sich etwas ändert (der Zeitplan wechselt), und setzt nicht ständig Werte neu. Der Grund ist simpel. Wenn jemand manuell am Thermostat dreht, soll das bis zum nächsten Schaltpunkt bestehen bleiben. Eine Automation, die jede Minute alles „richtig“ setzt, nimmt Menschen die Kontrolle weg, und genau das merkt man im Alltag als Erstes.

Technisch heißt das: Trigger auf Zustandswechsel des Zeitplans statt auf einen Zeit-Trigger im Minutentakt.

Regel 4: Der mode ist keine Nebensache

mode: single bedeutet, dass eine laufende Automation nicht erneut starten kann. Für kurze, einmalige Aktionen ist das richtig. Bei längeren Abläufen, die mehrfach getriggert werden können, braucht ihr queued oder restart. Wenn eine Automation scheinbar „manchmal nicht“ läuft, schaut als Erstes in die Ablaufverfolgung (Trace) der Automation; dort steht, ob sie wegen des Modus abgebrochen wurde.

Instanzen anlegen und warten

Aus dem Blueprint erzeugt ihr eine Instanz über Einstellungen → Automationen & Szenen → Blueprints → Automation erstellen. Pro Raum fülle ich Thermostat, Zeitplan und die beiden Temperatur-Helfer aus, gebe der Automation einen sprechenden Namen, fertig.

Wenn ich später die Logik ändere, ist das ein Eingriff an einer Stelle. Und weil ich nie YAML kopiert habe, kann auch keine Instanz „leise“ von den anderen abweichen. Ein kleiner Haken: Fügt ihr einem Blueprint neue Pflicht-Eingaben hinzu, müssen die bestehenden Instanzen angepasst werden. Neue Eingaben deshalb besser optional machen und mit einem sinnvollen Standardwert versehen.

Wann sich ein Blueprint nicht lohnt

Nicht alles gehört in einen Blueprint. Eine Automation, die es nur einmal gibt, braucht keine Abstraktion; die zusätzliche Schicht macht sie nur schwerer lesbar. Meine Faustregel: Ab der dritten Kopie wird ein Blueprint daraus.

Fazit

Blueprints haben meine Home-Assistant-Konfiguration deutlich ruhiger gemacht. Wenige Regeln reichen: Entitäten statt Geräte, Werte in Helfern, Schalten an Schaltpunkten, Modus bewusst wählen. Wer das beherzigt, hat Automationen, die man auch in einem halben Jahr noch versteht.