Home Assistant Blueprint: Vorlagen erklärt

Kennst du das, wenn andere eine super geniale Idee in ihrem Smart Home haben und dir tonnenweise Erklärungen liefern? Home Assistant hat hier einen echt genialen Weg gefunden, damit sehr gut umzugehen: Mit dem Home Assistant Blueprint.

Was Blueprints sind, warum sie auch für dich interessant sein könnten und weshalb ich da noch ein bisschen Optimierungsbedarf sehe, all das will ich dir in diesem Artikel genauer erläutern. Wir schauen uns nicht nur eine stumpfe Definition an, sondern gehen auch etwas mehr in die Praxis.

Denn ich bin wirklich felsenfest davon überzeugt, dass diese Funktion gerade die Einsteiger noch viel zu sehr abschreckt, obwohl sie eigentlich einen echt guten Benefit liefert. Passend dazu habe ich auch einen echt guten Leitspruch, der mir seit meinem allerersten Praktikum nie mehr aus dem Kopf gegangen ist:

Wozu das Rad neu erfinden?

Was sind Blueprints?

Unter einem Blueprint versteht man ganz allgemein einen Plan, Entwurf oder ein Modell. Diese Modelle sind bei Home Assistant vordefinierte Automationen, die von einem oder mehreren Nutzern gebaut werden. Diese vordefinierten Automationen lassen sich in das eigene Smart Home einbinden und in der Praxis nutzen.

Ganz allgemein nutzt man Blueprints vor allem aus zwei Gründen, die ich dir nachfolgend kurz erläutern möchte.

Der erste Grund sind komplexe Automationen. Nicht jeder hat das tiefe Verständnis von Smart Home und manche beschäftigen sich eher mit oberflächlichen Automationen. Diese Zielgruppe kann ein Blueprint verwenden, um mehr mit dem eigenen Smart Home machen zu können. Auf diese Weise musst du nicht selbst die komplexesten Automationen entwerfen, sondern kannst dich auf das Know-How anderer stützen, die diesen Teil für dich schon erledigt haben.

Ein weiterer Grund ist die Wiederverwendbarkeit. In jedem Smart Home gibt es in der Regel Automationen, die annähernd gleich sind. Ein typisches Beispiel sind Lampen, die bei Dunkelheit eingeschaltet werden sollen. Nun macht es ja recht wenig Sinn, diese Automation hundertfach neu zu bauen, wenn es schon eine sehr stabile Lösung gibt. Hier kann man ein Blueprint verwenden, um schnell zu einem Ergebnis zu kommen, ohne dass hierfür selbst eine Automation gebaut werden muss.

Wir sprechen hier also tatsächlich über Vorlagen, die allen Nutzern das Leben leichter machen sollen. Es ist gewissermaßen eine Art des standardisierten Austauschs von Automationen, die man selbst erstellt hat.

Blueprint vs Automation

Nun magst du dich vielleicht fragen, wo denn dann aber genau der Unterschied zwischen einem Blueprint und einer Automation liegt. Und die Frage verwirrt sicherlich sehr viele da draußen, weshalb wir das mal etwas genauer betrachten müssen.

Eine Automation in Home Assistant wird erstellt, um eine bestimmte Aktion (oder mehrere) auszuführen. Hierbei referenzierst du immer auf ein konkretes Gerät oder eine bestimmte Entität. Es ist also keine abstrakte Automation, sondern bezieht sich immer auf deine konkrete Situation. Gibst du die Automation an jemand anderen weiter, wird sie nicht funktionieren. Denn hier müssen vor allem die Entitäten korrekt gesetzt werden, was mitunter in einer YAML-Datei nicht unbedingt einfach ist.

Ein Blueprint hingegen versteht sich selbst immer nur als Vorlage. Das bedeutet, dass du bei der Installation eines Blueprints auswählen musst, auf welche Entitäten sich die Automation beziehen soll. Das wird in der Regel meist grafisch über die Weboberfläche gelöst. Gibst du nun das Blueprint weiter, wird der nächste Nutzer wieder danach gefragt und so durch die Installation dieser Vorlage geführt.

Ganz grundsätzlich kannst du dir also merken, dass Blueprints eine Art standardisiertes Format sind, um Automationen weiterzureichen. Die klassischen Automationen hingegen sind starr und nicht zum Verbreiten gedacht, da sie sich immer auf diese eine Installation beziehen. Du als Blueprint-Nutzer musst also nicht das Rad neu erfinden, sondern nur noch deine Geräte in die Variablen einsetzen. Und schon sollte alles laufen.

Durch die Verwendung von Blueprints schafft sich Home Assistant ein Konstrukt, das zur Wiederverwendbarkeit beiträgt und so Automationen in ein austauschbares Format bringt, das überall auf der Welt genutzt werden kann. Völlig unabhängig davon, ob du Lampen von Philips hast und der nächste von Osram.

Anwendungsfälle: Wann lohnen sich Blueprints?

Neben der Verbreitung von Automationen können sich Blueprints aber auch in deinem eigenen Smart Home gegebenenfalls sehr lohnen. Denn auch in einem Single-User-Setup hast du wiederkehrende Muster für die du das Rad nicht jedes Mal neu erfinden musst.

Lass mich dir das an einem praktischen Beispiel deutlich machen. Hier sieht man zum Beispiel auch, dass ich mich viel zu spät mit dem Thema beschäftigt habe und noch großes Optimierungspotenzial habe.

In meinem Zuhause habe ich Sensoren und Lampen. Betritt nun eine Person den Raum (z. B. das Badezimmer), wird die Innenhelligkeit geprüft. Ist es im Raum zu dunkel, wird das Licht eingeschaltet. Verlässt die Person nun den Raum, geht das Licht wieder aus.

Diese Automation habe ich für jeden Raum erstellt, der mit einem entsprechenden Sensor ausgestattet ist. Also bei mir ganze 6 Mal. Anstatt nun die gleiche Automation so häufig von Grund auf neu zu bauen, hätte ich auch einen Blueprint erstellen können. Diesem Blueprint übergebe ich dann nur die jeweiligen Entitäten, die ausgelesen und angesteuert werden sollen. Und siehe da: Ich müsste die Automation nur noch einmal bauen und könnte sie in jedem Raum wiederverwenden.

Neben der Zeitersparnis schaffe ich mir dadurch aber noch einen weiteren Vorteil. Denn wenn ich nun in meiner Automation einen Fehler entdecke, muss ich sie ganze 6 Mal ändern, bevor ich alle Stellen erwischt habe. In einem Blueprint hingegen müsste ich es nur einmal ändern und ich hätte sofort alle Räume mit der neuesten Logik versorgt. Dieser Vorteil führt dann auch dazu, dass ich langfristig eine sehr starke Automation entwickle, die ich Stück für Stück verbessere ohne mich mit dem Copy and Paste aufzuhalten.

Gebe ich diesen Blueprint dann noch an die Community weiter, kann diese die Automation weiter verbessern und ich erhalte langfristig gesehen auch einen großen Benefit zurück. Diesen Benefit hätte ich mir alleine vielleicht niemals schaffen können.

Vorsicht bei Individualisierung

Um mal bei meinem Beispiel mit den Sensoren und den Lichtern zu bleiben, will ich das noch etwas ausführen. Nehmen wir an, dass ich zusätzlich zum Licht in einem Raum noch die Musik schalten will. In einem anderen dafür aber zum Beispiel den Fernseher.

Nun könnte man auf die Idee kommen, dass man einfach einen weiteren Blueprint anlegt, der genau das macht. Und sicherlich ist das auch nicht die schlechteste Idee. Doch sie beherbergt Risiken.

Denn wenn du für jeden Sonderfall nun einen eigenen Blueprint baust, dass hast du nur die Automationen in Blueprints verschoben. Wiederverwenden kannst du es aber trotzdem nicht. Denn der Blueprint wird so speziell, dass er eigentlich kaum noch übertragbar ist.

Einer meiner Professoren hat damals einen Spruch in der Vorlesung geprägt: „Teile und herrsche“.

Konkret teilst du also dein Problem (die Automation) in so kleine Teile, dass du sie beherrschen kannst. Die einzelnen Bestandteile kannst du sehr gut in Blueprints packen und so später wiederverwenden. Aus mehreren Blueprints könntest du dann auch wiederum ein komplexes Gesamtkonstrukt zusammenbauen. Ohne dass du hierfür jedes Mal eine eigene Automation erstellen musst.

Merke also: Sobald es speziell wird, eigenen sich die Automationen besser. Ist es aber ein allgemeiner Vorgang, den du auch für andere Stellen haben willst, lohnt sich ein Blueprint.

Ebenso brauchst du natürlich keinen Blueprint, wenn du nur eine einzige Automation damit bauen willst. Hier wäre der Aufwand auch in keiner Relation zum Nutzen.

Neue Blueprints importieren

Willst du nun neue Blueprints importieren, musst du dich zuerst mal in deinen Home Assistant begeben. Du findest sie an folgender Stelle:

Einstellungen > Automationen & Szenen > Blueprints (oben mittig)

Hier sind sämtliche Blueprints aufgelistet, die du in deinem System hinzugefügt hast. Außerdem findest du dort auch einen Link, um weitere Blueprints zu entdecken. Beim Klick auf diesen Link wirst du in die offizielle Community weitergeleitet, wo du in einem Forum viele Ideen und vorgefertigte Blueprints finden kannst.

Viele der vorgefertigten Blueprints haben dabei den typischen Import Blueprint to My Home Assistant Button. So kannst du mit einem einzigen Klick direkt diesen Blueprint in deinem Home Assistant hinzufügen.

Alternativ kannst du aber auch im Home Assistant mit dem Button unten rechts (nachdem du im Bereich Automationen bist) auch einen Blueprint importieren. Hier musst du dafür die Adresse des Blueprints eingeben, der üblicherweise mit .yaml endet. Damit wird auch schon deutlich, dass jeder Blueprint eine YAML-Datei ist, die im Grunde nur eine Automation mit Variablen vorgibt.

Kleiner Tipp: Wenn du die Datei auf GitHub gefunden hast, gibt es rechts vom Dateinamen oft einen kleinen Button Raw. Wenn du diesen Button klickst, kannst du dir die Rohdatei ansehen, welche dann in der Regel auf die korrekte Endung (also den Dateinamen) hat. Diesen Link musst du dann in deinem Home Assistant einfügen, so dass der Blueprint installiert werden kann.

Wenn du dich noch nicht gut mit GitHub auskennst, dann empfehle ich dir meinen GitHub Leitfaden für Einsteiger. Dort erkläre ich dir viele der Basics.

Einen Home Assistant Blueprint verwenden

Nachdem sich der Blueprint nun in deinem System befindet, musst du ihn natürlich noch für dein gewünschtes Szenario nutzen. Das Vorgehen hier ist wirklich sehr simpel.

Navigiere zuerst wieder in den Bereich Automationen und erstelle eine neue Automation. Dabei hast du schon die Möglichkeit, verschiedene Arten von Automationen zu erstellen. In der Regel taucht hier dann auch der Name des Blueprints auf, den du dann anklickst.

Ein gut ausgestalteter Blueprint führt dich nun durch die Einrichtung. Denn du musst an einigen Stellen die richtigen Entitäten auswählen, so dass gewissermaßen alles korrekt miteinander verknüpft wird. Die genaue Vorgehensweise und Auswahlmöglichkeiten hängen dabei vom jeweiligen Blueprint ab. In meinem Beispiel habe ich sehr viele Konfigurationsmöglichkeiten, da der Blueprint Low Battery Notifications & Actions entsprechend viele Informationen braucht.

Im Gegenzug stellt er aber auch viele Informationen bereit, so dass man im Grunde gut durch den ganzen Prozess geführt wird.

Wichtig für dich ist aber zu wissen, dass eine Automation erst dann läuft, wenn du sie auf Basis des Blueprints erstellt hast. Einfach nur einen Blueprint herunterzuladen sorgt noch nicht dafür, dass er auch wirklich im Einsatz ist. Das ist wie wenn du dir eine Integration herunterlädst, sie aber nicht eingerichtet hast.

Übrigens habe ich dem Kapitel Automationen mit Home Assistant einen ganz eigenen Beitrag gewidmet. Dort geht es zwar nicht um Blueprints, ich gebe dir aber sehr viele wichtige Infos für dein Smart Home.

Eigene Blueprints erstellen

Für die Fortgeschrittenen unter meinen Lesern gibt es auch die Möglichkeit, selbst Blueprints zu erstellen. Der große Vorteil aus meiner Sicht ist dabei, dass du nicht nur der Community etwas zurückgeben kannst, sondern auch möglicherweise Verbesserungen und Vorschläge bekommst. Denn die Home Assistant Community ist generell sehr aktiv und man trifft eigentlich immer jemanden an, der sich dafür begeistern kann.

Blueprints basieren auf YAML und nutzen auch Jinja2-Templates. Das bedeutet, dass du dich mit diesem Format auskennen solltest und dich auch damit beschäftigen wollen. Mein absoluter Geheimtipp (der gar nicht so geheim ist) lautet, dass du bei YAML immer auch ChatGPT zu Rate ziehen kannst. Meine Erfahrungen mit ChatGPT und YAML sind durchweg positiv und so habe ich mir schon einiges an Sucharbeit ersparen können.

Der Grundaufbau eines Blueprints sieht nun wie folgt aus:

blueprint:
  name: …
  description: …
  domain: automation
  input:
    sensor_motion:
      name: Bewegungsmelder
      selector: …
    light_target:
      name: Ziel‑Licht
      selector: …
trigger:
  …
condition:
  …
action:
  …

Wichtig ist am Anfang die Definition des Blueprints. Dann folgen der Name sowie eine Beschreibung. Über die Inputs steuerst du, welche Variablen der Nutzer später mit seinen eigenen Entitäten befüllen muss. Weiter geht es dann mit dem Trigger, den Bedingungen und der Aktion.

Grundsätzlich siehst du also, dass ab dem Punkt Trigger der Blueprint genauso aufgebaut ist wie eine Automation. Alles darüber sind im Grunde genommen nur Meta-Informationen, die den Unterschied zu einer klassischen Automation machen. Dort kannst du auch Informationen einfügen, die dem Nutzer dann in der Weboberfläche von Home Assistant angezeigt werden. Typischerweise können das Hilfetexte oder auch Erklärungen sein.

Für das Erstellen von Blueprints empfehle ich dir übrigens Visual Studio Code. Eine gute Umgebung, die mit den passenden Erweiterungen dafür sorgt, dass du dich im YAML-Dschungel nicht verläufst.

Wenn du außerdem auf der Suche nach dem Schema bist, gibt es in der offiziellen Dokumentation den Bereich About the blueprint schema. Dort werden die einzelnen Attribute genauer beschrieben und es wird auch angegeben, welche Werte du eingeben kannst. An dieses Schema musst du dich zwingend halten, sonst wird dein Blueprint nicht funktionieren.

Beispiel-Blueprint

In der offiziellen Dokumentation von Home Assistant (Version 2025.11.2) findest du ein ganz gutes und übersichtliches Beispiel für einen vollwertigen Blueprint:

blueprint:
  name: Motion Light Tutorial
  description: Turn a light on based on detected motion
  domain: automation
  input:
    motion_sensor:
      name: Motion Sensor
      description: This sensor will be synchronized with the light.
      selector:
        entity:
          filter:
            - domain: binary_sensor
              device_class: motion
    target_light:
      name: Lights
      description: The lights to keep in sync.
      selector:
        target:
          entity:
            - domain: light

triggers:
  - trigger: state
    entity_id: !input motion_sensor

actions:
  - action: >
      {% if trigger.to_state.state == "on" %}
        light.turn_on
      {% else %}
        light.turn_off
      {% endif %}
    target: !input target_light

Anhand von diesem Beispiel siehst du auch wieder den klassischen Aufbau. Es beginnt zuerst mit der Deklaration als Blueprint. Direkt im Anschluss folgt dann der Name, die Beschreibung, die Domäne und der Input.

Am Input lässt sich sehr klar erkennen, dass dem Input ein Name sowie eine Beschreibung verpasst wird. Der Beschreibungstext sollte dabei so eindeutig sein, dass jeder weiß, was damit gemeint ist und was man auswählen muss. Bist du hier also zu sparsam mit deinen Worten, weißt du vielleicht in einem halben Jahr schon selbst gar nicht mehr, was dort hinein muss. Beschreibe es also besser ausführlicher als zu knapp.

Im Bereich Trigger und Actions siehst du, wie immer wieder auf die obigen Werte referenziert wird. Gerade die Action macht es aus meiner Sicht sehr deutlich. Denn hier wird als Target (Ziel) die Variable target_light genannt. Diese wurde oben beim Input deklariert. Die Aktionen manipulieren also nicht direkt den Zustand deiner Entitäten, sondern immer den der Variable. Diese Variable (target_light) verweist wiederum auf die richtige Entität.

Unten ist also der typische Platzhalter, der zu Beginn deines Blueprints gesetzt wird. Die Inputs können dabei durch die Oberfläche von Home Assistant gesetzt werden, weil der Blueprint immer in einem standardisierten Format geschrieben sein muss.

Tipps für deinen Blueprint

Einen Blueprint zu erstellen bedeutet, dass du einen Ablaufplan schreibst. Also ein Skript erstellst. Programmieren ist es tatsächlich nicht. Und für diesen Ablaufplan gibt es ein paar Tipps, die dir dein Leben leichter machen. Ich habe dir mal alles dazu aufgeschrieben, das mir als Softwareentwickler dazu in den Sinn kommt:

• Sinnvolle Benennung: Achte auf selbst beschreibende Namen, die sofort den Sinn einer Variable klar machen. Beispielsweise sollte dein Motion Sensor nicht Sensor A heißen. Ein klares Namensschema ist zwar erstmal anstrengend, aber erspart dir im Nachgang sehr viel Sucharbeit. Ausführliche und klare Beschreibungen helfen dir außerdem dabei, dass du nach einem halben Jahr noch den Sinn verstehst.
• Selektoren: Selektoren sind nicht zwingend erforderlich wie aus der Dokumentation hervorgeht. Du solltest sie aber unbedingt nutzen wenn möglich, da du so den Nutzer schon gezielt zu den richtigen Geräten und Entitäten führst. Gibst du keine Selektoren an, kann der Nutzer zum Beispiel statt einem Bewegungssensor seine Alarmanlage auswählen und der Blueprint funktioniert nicht. Das führt am Ende dazu, dass du viel mehr Supportanfragen bekommst als du eigentlich haben willst. Nutze also die Möglichkeiten, die dir Home Assistant zur Verfügung stellt um möglichst viel Klarheit zu schaffen.
• Sprache und Lesbarkeit: Benutze bei deinen Texten am besten die englische Sprache, da vieles in der Community auf Englisch abläuft. Korrigiere am besten auch die Sprache mit diversen Tools, so dass keine Missverständnisse aufkommen. Hilfreich finde ich auch hier wieder ChatGPT als Partner, der dir bei der Formulierung und Übersetzung helfen kann. Das ist insbesondere dann wichtig, wenn du deinen Blueprint weitergeben wirst.
• Local First: Schaffe mit deinem Blueprint keine Abhängigkeiten zu externen Diensten, wenn es sich vermeiden lässt. Rufe also Schnittstellen nur dann ab, wenn es wirklich zwingend notwendig ist. Denn externe Schnittstellen haben oft die Tücke, dass du Zugangsdaten brauchst oder der Dienst einmal versagen kann. Es ist besser, wenn der Blueprint komplett in der eigenen Umgebung auskommt.
• Testen: Bevor du deinen Blueprint veröffentlichst, teste ihn in deiner eigenen Umgebung gründlich. Nichts ist frustrierender als ein Blueprint, der zwei Mal am Tag ein Update braucht oder erst gar nicht funktioniert. Stabilität hat immer oberste Priorität und sollte niemals vernachlässigt werden. Du kannst gegebenenfalls auch zwei oder drei Mitglieder der Community fragen, ob sie deinen Blueprint vor der offiziellen Veröffentlichung testen wollen.

Diese Tipps helfen dir dabei, etwas Gutes und Großartiges zu erschaffen. Und dabei sind die Tipps sogar auch gleich Hinweise aus der professionellen Sicht. Denn im Grunde geht jeder Softwareentwickler gleich vor und versucht auch mit seinem Code, möglichst viel Stabilität einzubringen. Zwar hat jede Software auch mal einen Fehler, aber mit den Best-Practices lässt sich schon vorab sehr viel an Frust und Fehlern vermeiden.

Jinja2-Templates

Wie ich oben bereits kurz erwähnt habe, kannst du in deinen Blueprints auch Jinja2-Templates nutzen. Vielleicht sagt dir der Begriff erstmal nichts, aber es begegnet dir immer mal wieder in Home Assistant. Du kennst es womöglich mehr unter dem Begriff Templates.

Mit diesen Templates hast du die Möglichkeit eine Semi-Programmierung zu machen und damit den Blueprint noch etwas individueller zu gestalten. Ein Beispiel hierfür ist das Arbeiten mit Uhrzeiten. Folgendes Beispiel habe ich dir mal rausgesucht:

condition:
  - condition: template
    value_template: "{{ now().hour >= 22 or now().hour < 6 }}"

Hier siehst du im value_template, dass ein sogenanntes Jinja2-Template genutzt wird. In diesem Fall prüfen wir, ob die aktuelle Stunde größer gleich 22 oder kleiner 6 ist. Das bedeutet konkret, der Rahmen reicht hier von 22-5 Uhr. 6 Uhr ist nicht mehr eingeschlossen und wäre es nur, wenn man ein kleiner gleich machen würde.

Es geht hier also primär um Logik und Erweiterung der einfacheren Möglichkeiten, die in Home Assistant schon standardmäßig integriert sind.

Nützliche Blueprints für Home Assistant

Schauen wir nun noch auf ein paar Blueprints, die man in der offiziellen Community finden kann. Sie sollen dir dabei helfen, mehr aus deinem Smart Home herauszuholen und dir die komplexe Automatisierungsarbeit zu erleichtern.

Ob sie schlussendlich wirklich beliebt sind, ist natürlich immer schwer zu sagen. Aber anhand des Forums lässt sich zumindest darauf zurück schließen, dass sie nicht ganz uninteressant sind. Ich kann dir einfach nur den Tipp geben, dass du dir ein wenig Zeit nimmst und selbst mal auf die Suche gehst. Sicherlich findest du dort auch das eine oder andere Template, das dir in deinem Smart Home wirklich weiterhelfen kann.

Ich fokussiere mich jetzt erstmal auf drei Blueprints, die ich für dich herausgesucht habe.

Occupancy Blueprint

Der Nutzer alexbabel hat einen Blueprint entwickelt, der nach dem Prinzip einer Box arbeitet. Er betitelt es charmant als wasp in the box principle. Die Logik dahinter ist so einfach wie genial:

Geht eine Person in das Badezimmer und wird Bewegung erkannt, dann kann die Person erst wieder aus dem Raum draußen sein, wenn die Badezimmertür wieder geöffnet wird. Man prüft also die Bewegung und den Zustand der Tür. Solange die Tür nach der Bewegungserkennung nicht geöffnet wird weiß man, dass die Person den Raum nicht verlassen hat.

Auf diese Art und Weise lässt sich sehr effektiv die Beleuchtung steuern. Vorausgesetzt natürlich, dass in diesem Haushalt nicht mehrere Menschen hintereinander das Badezimmer betreten.

Eine detaillierte Beschreibung zum Blueprint findest du hier: Blueprints Exchange – Occupancy Blueprint.

AI Package Detector

Etwas ausgefallener geht es beim Nutzer DaaveK zu. Er hat einen Blueprint geschrieben, der Pakete erkennen soll. Hierzu greift er auf die Google Generative AI zurück, um Pakete erkennen zu können.

Das Prinzip sieht vor, dass der KI ein Bild der Kamera übergeben wird. Daraufhin analysiert die KI den Inhalt des Bildes und kann eine Aussage darüber geben, ob ein Paket abgelegt wurde. Die zugehörige Benachrichtigung wird dann über die Home Assistant App auf deinem Smartphone zugestellt und du bist immer über neue Pakete informiert.

Gerade gegen Ende des Jahres, wenn es auf Weihnachten zugeht, ist das vielleicht eine echt clevere Automation. Aber sie basiert natürlich auch gleichzeitig auf einem externen Dienst, weshalb man hier vorsichtig sein muss. Die Nutzung des Blueprints ist durch die KI-Anbindung außerdem möglicherweise mit Kosten verbunden.

Die gesamten Informationen findest du im Blueprints Exchange unter dem Titel AI Package Detector.

Wake-up light alarm with sunrise effect

Der dritte Blueprint ist aus meiner Sicht etwas ganz Besonderes für die Winterzeit. Denn das Aufstehen fällt uns hier wahrscheinlich allen schwer.

Mit dem Wake-up light alarm with sunrise effect kannst du das ein wenig abmildern. Dieser Blueprint basiert auf der Idee, dass aus einem Wecker der Zeitpunkt ausgelesen wird, zu dem das Aufwachen beginnen soll. Kurz zuvor oder pünktlich zu diesem Zeitpunkt wird dann die Beleuchtung dazu genutzt, um einen Sonnenaufgang zu simulieren.

Der Nutzen ist dabei ziemlich klar. Wir sollen sanfter aufwachen und der Morgen soll schon optimal starten. Und anstatt hier etwas mühevoll nachzubauen, eignet sich ein Blueprint hervorragend dafür. Ich zum Beispiel könnte das mit meinem Amazon Echo kombinieren, so dass dieser Blueprint als Automation automatisch am Morgen gestartet wird.

Die volle Beschreibung zum Blueprint findest du unter dem Namen Wake-up light alarm with sunrise effect im Blueprint Exchange.

Blueprints neu laden nach Änderungen

Egal ob importierter Blueprint oder selbst erstellt. Jede Änderung an einem Blueprint muss erstmal in die Automationen wandern. Im Hintergrund werkeln überall YAML-Dateien, die entsprechend aktualisiert werden müssen.

Üblicherweise werde die Automationen bei jedem Start von Home Assistant aktualisiert. Nun willst du aber wahrscheinlich nicht nach jeder Änderung dein System neu starten. An dieser Stelle hilft dir ein kleiner Trick, der für viele sehr versteckt und gar nicht so eindeutig gekennzeichnet ist.

Navigiere hierzu links im Menü auf die Entwicklerwerkzeuge. Achte dann darauf, dass du oben auf dem Tab YAML bist. Du findest nun den Bereich YAML-Konfiguration neu laden. Hier klickst du nun auf Automationen. Auf diese Weise werden die Konfigurationsdateien für die Automationen neu eingelesen, unter anderem eben auch die Änderungen an deinem Blueprint. Dieser Prozess kann kurz dauern, ist aber in der Regel relativ schnell abgeschlossen.

Alternativ kannst du natürlich auch jedes Mal Home Assistant neu starten. Das dauert aber wesentlich länger und sorgt immer dafür, dass laufende Prozesse unterbrochen werden. Ich persönlich empfehle dir daher insbesondere bei Änderungen lieber den Weg über die Entwicklerwerkzeuge. Kaputt machen kannst du an der Stelle nichts.

Mein Kritikpunkt am Blueprint-System

Wie du nun also mitbekommen hast, finde ich Blueprints super spannend. Aber es gibt auch einen großen Kritikpunkt, den ich hier nicht unerwähnt lassen will. Und der betrifft die Übersichtlichkeit.

Während wir Integrationen sehr einfach über die Oberfläche installieren können und auch HACS uns weitere Möglichkeiten bietet, fühlen sich Blueprints eher wie eine Krücke an. Es gibt keine Übersicht in Home Assistant selbst und auch das Herunterladen wirkt auf Einsteiger sehr kompliziert.

Ich würde mir für meinen Teil wünschen, dass Blueprints ein offizieller Teil der Home Assistant Software werden. Es sollte ein Bereich entstehen, in dem du stöbern und herunterladen kannst. Also quasi genau so wie bei HACS. Das würde die Einstiegshürde für Anfänger senken und Blueprints zu einem noch stärkeren Teil im System machen. Und das hilft vor allem der Community.

Denn wenn Home Assistant eine große Stärke hat, dann ist es definitiv die Community. Und genau diesen Faktor sollte man hier einbeziehen. So gibt man auch gleichzeitig den Nutzern die Möglichkeit, selbst einen Teil zum System beizutragen, der auch von der Wertschätzung genau so wirkt. Im Forum ist es mehr eine Art Übergangslösung und zum Teil auch schwer in der Übersicht. Das kann man definitiv besser lösen.

Vielleicht sehen wir das ja in der Zukunft noch. Wir kennen ja nicht alle Ideen, welche die Entwickler noch auf ihrer Liste haben. Aber diese sollte es ziemlich weit nach oben schaffen aus meiner Sicht.

Mein Fazit zu Blueprints

Insgesamt bleibe ich aber bei meiner Aussage, dass die Blueprints von Home Assistant ein wahnsinnig starkes Tool sind. Sie schweißen nicht nur die Mitglieder der Community näher zusammen, sondern sorgen auch für eine Gemeinschaft. Jeder kann von dieser Gemeinschaft profitieren und auch etwas zurückgeben.

Vor allem sehr hilfreich ist das für technisch weniger versierte Menschen. Denn auch sie kommen in den Genuss von komplexen Automationen, die sie selbst vielleicht nie gebaut hätten.

Und dann ist da ja noch der Faktor, dass man das Rad nicht neu erfinden muss. Denn wozu sollte ich mich jetzt hinsetzen und in mühevoller Arbeit einen Sonnenaufgang für meine Beleuchtung einbauen, wenn sich schon jemand damit beschäftigt hat? Ich kann doch meine Kapazität dann stattdessen dafür verwenden, neue Ideen zu realisieren. So entstehen innerhalb von kurzer Zeit viele Ideen und Vorlagen, die das Smart Home für alle verbessern. Genau das macht eine solche Community aus.

Allerdings muss man auch sagen, dass Blueprints gerade für Einsteiger nicht so einfach zu durchschauen sind. Seitens des Systems könnte es hier noch eine bessere Integration geben, die diesen Faktor abmildert. Dann werden Home Assistant Blueprints zu einem echten Game Changer, der das Smart Home auf das nächste Level heben kann.

Denn wenn Blueprints symbolisch für eine Sache stehen, dann ist es für Kreativität.