Zwei Uhr nachts. Die Wohnzimmerlampe geht an. Aus. An. Aus. Mein Handy vibriert, weil irgendeine Automation „erfolgreich“ gelaufen ist — zum vierzehnten Mal in drei Minuten. Spoiler: Erfolgreich war nur die Schleife. Die Lampe hat beschlossen, Disco zu spielen, und Home Assistant hat höflich applaudiert. Willkommen bei Automationen für Einsteiger — dem Moment, in dem Ihr Zuhause anfängt, eigene Entscheidungen zu treffen. Manchmal gute. Manchmal blinkende.

Die kurze Version vorab: Eine Automation in Home Assistant besteht mindestens aus Trigger und Aktion. Optional kommt eine Bedingung dazu. Offizielles Beispiel aus den Docs: Wenn Paulus nach Hause kommt und die Sonne untergegangen ist, gehen die Wohnzimmerlichter an. Klingt wie ein Rezept. Ist auch eines — nur dass die Küche Settings heißt und niemand YAML anfassen muss, wenn Sie den visuellen Editor nutzen.

Im Ernst: Der Einsteiger-Guide zeigt oft nur ein Mini-Beispiel, damit klar wird, dass Automationen existieren. Hier machen wir das Ding richtig auf — Trigger, Bedingung, Aktion, Alltagsbeispiele, der berüchtigte Flacker-Fail und warum Blueprints am Anfang Ihre Nerven retten. Wer Home Assistant noch gar nicht laufen hat, sollte vorher Home Assistant installieren; die Installation stoppt bewusst vor Automationen. Und wer gerade erst sortiert, was die Plattform überhaupt will, startet besser mit dem Home-Assistant-Einsteiger-Guide.

Trigger, Bedingung, Aktion — das Rezept ohne Panik

Home Assistant denkt Automationen in drei Teilen. Die Oberfläche sagt es sogar laut: When (Trigger), And if (Bedingung), Then do (Aktion). Englische Labels, deutsche Logik. Alltagsvergleich: Der Trigger ist die Klingel. Die Bedingung ist der Blick durch den Türspion. Die Aktion ist: Tür aufmachen — oder eben nicht.

Nerd-Alarm: Ohne Trigger passiert nichts. Ohne Aktion auch nichts Sinnvolles. Die Bedingung ist optional — aber oft der Unterschied zwischen „Lampe geht an, wenn ich heimkomme“ und „Lampe geht an, wenn ich heimkomme, es dunkel ist und niemand schon das Licht manuell angemacht hat“. Genau deshalb steht im Paulus-Beispiel das „after sunset“: Zuerst Trigger (Person kommt), dann Condition (nach Sonnenuntergang), dann Action (Licht an).

Geräte-Personifikation, weil sie hier passt: Der Bewegungsmelder ist der nervöse Pförtner. Er schreit bei jedem Schatten „Jemand!“. Die Bedingung ist die Pförtner-Schulung („nur nach 22 Uhr und nur wenn niemand im Wohnzimmer sitzt“). Die Aktion ist der Hausmeister, der die Lampe andreht. Ohne Schulung dreht der Hausmeister bei jedem vorbeilaufenden Nachbarhund das Licht an. Spoiler: Das nervt. Schnell.

Laut der offiziellen Doku zu Understanding automations bei Home Assistant sind Trigger und Action Pflichtteile; Conditions verhindern, dass Actions feuern, wenn sie nicht erfüllt sind. Das ist die ganze Magie in einem Satz. Der Rest ist Übung — und der Mut, die erste Automation speichern zu drücken, ohne drei Foren-Threads zu lesen.

UI zuerst: Automationen anlegen, ohne YAML zu berühren

Vergessen Sie für diesen Artikel YAML. Wirklich. Die Datei existiert, Sie dürfen später reinschauen, aber der Einstieg läuft über den visuellen Editor. Home Assistant empfiehlt das ausdrücklich: Automationen bauen Sie in der UI, Coding ist nicht nötig. Geräte und Dienste kennt das System schon — Sie tippen nicht „light.wohnzimmer“, Sie wählen Wohnzimmerlampe.

Der Weg, den Sie sich merken sollten:

Einstellungen öffnen (Settings),
Automations & scenes wählen,
unten rechts Create automation,
dann Create new automation.

Fertig. Sie stehen in einem Formular mit When / And if / Then do. Klingt einfach, ist es aber nicht — weil die Dropdowns plötzlich hundert Entities zeigen und Ihr Gehirn fragt: Welche Lampe war nochmal die gute? Tipp aus dem Kellerlabor: Areas und sinnvolle Gerätenamen vorher pflegen. Sonst heißen drei Lampen „Licht“, „Licht 2“ und „Light“, und Sie schalten um 23 Uhr das Kinderzimmer statt der Diele.

Im Ernst: Wer noch am Dashboard bastelt und glaubt, Kacheln seien schon Logik — nein. Das Dashboard ist UI, nicht Gehirn. Knöpfe zum Tippen, Graphen zum Anschauen. Die Entscheidungen leben in Automationen. Wer die Oberfläche schön machen will, findet das in unserem Überblick zum Home-Assistant-Dashboard; wer will, dass nach Sonnenuntergang etwas passiert, bleibt hier.

Parenthese für YAML-Fans: Später können Sie in den YAML-Modus wechseln, Blueprints forken, Templates schreiben. Heute nicht. Heute speichern Sie drei Automationen, die funktionieren — und freuen sich, dass nichts flackert. Die kurze Version: UI first, YAML later optional. Kein Deep-Dive nötig, um das Wohnzimmer zu automatisieren.

When: Trigger, die das Haus wecken

Der Trigger ist der Startschuss. Wenn er „wahr“ wird, startet die Automation — und prüft danach ggf. Bedingungen. Typische Trigger für den Alltag:

Zustand (State): Lampe wechselt von off zu on, Sensor von clear zu detected,
Zeit / Sonnenstand: 7:00 Uhr, Sonnenuntergang, 30 Minuten vor Sonnenaufgang,
Gerät (Device): physischer Taster, Bewegungsmelder, Türkontakt,
Numerisch: Temperatur über 24 °C, Luftfeuchtigkeit unter 40 %,
Zone / Person: jemand betritt „Home“, jemand verlässt „Arbeit“.

Im Editor: In der When-Sektion Add trigger. Sie können nach Ziel suchen (Entity, Device, Area, Label) oder nach Trigger-Typ. Unter Behavior gibt es bei mehreren Targets Optionen wie First, Last, Any — wann genau die Automation zünden soll, wenn mehrere Geräte überwacht werden. Nerd-Alarm: „Any“ ist der Default im Kopf der meisten Einsteiger („irgendeiner der Sensoren reicht“). First/Last brauchen Sie später, wenn Sie Gruppenlogik bauen.

Alltagsvergleich: Der Trigger ist der Wecker. Er klingelt. Ob Sie aufstehen (Aktion) und ob Sie überhaupt arbeiten müssen (Bedingung: Wochentag), entscheidet der Rest. Ein Wecker um 3 Uhr nachts, der trotzdem die Kaffeemaschine startet, weil keine Bedingung „nur Mo–Fr“ gesetzt ist — das ist Automations-Humor, den niemand lustig findet.

Geräte als Trigger sind oft der Einstieg, der sich „smart“ anfühlt: Knopf drücken, Szene läuft. Dafür brauchen Sie natürlich Geräte, die Home Assistant kennt. Wer Zigbee-Taster, Kontakte und Bewegungsmelder erst anbinden will, geht den Weg über unseren Guide zu Zigbee in Home Assistant einrichten — Pairing zuerst, Automationen danach. Sonst triggern Sie Luft.

Spoiler aus eigener Erfahrung: Der erste Trigger, den man falsch setzt, ist meist „State: light is on“ statt „State: light changes to on“. Dauerzustand versus Wechsel. Der eine feuert, wenn die Automation geprüft wird und das Licht schon an ist. Der andere feuert nur beim Umschalten. Klingt pedantisch. Ist der Unterschied zwischen „einmal“ und „warum läuft das ständig?“.

And if: Bedingungen, die peinliche Automationen verhindern

Bedingungen sind optional. Sie sind auch der Teil, den Einsteiger überspringen — und dann um 14 Uhr bei Sonnenschein die „Abendbeleuchtung“ einschalten, weil jemand die Haustür aufgemacht hat. Die Bedingung sagt: Trigger war okay, aber bitte nur, wenn X auch stimmt.

Im Editor: And if → Add condition. Unter Blocks finden Sie:

And — alle Unterbedingungen müssen passen,
Or — mindestens eine reicht,
Not — die Automation läuft nur, wenn etwas nicht zutrifft.

Das klingt nach Logik-Seminar. Im Alltag ist es Rezept: „Licht an, wenn Bewegung UND nach Sonnenuntergang UND niemand hat die Party-Szene aktiv.“ Oder: „Heizung runter, wenn Fenster offen ODER niemand zu Hause.“ Oder: „Benachrichtigung senden, wenn Kellerfeuchtigkeit hoch UND NOT (Urlaubsmodus an).“

Geräte-Personifikation: Die Bedingung ist die innere Stimme Ihrer Automation. Der Trigger schreit. Die Bedingung flüstert: „Wirklich? Jetzt? Sicher?“ Manchmal sagt sie Nein. Gut so. Automationen ohne innere Stimme sind Teenager mit Hausschlüssel und zu viel Energie.

Praktischer Tipp: Bauen Sie Bedingungen lieber zu streng und lockern Sie nach zwei Tagen, statt zu locker und um Mitternacht Logs zu lesen. Und ja — Sonnenstand als Condition ist Klassiker. „After sunset“ aus dem Paulus-Beispiel ist genau das: nicht nur „Person home“, sondern „Person home und es ist dunkel genug, dass Licht Sinn ergibt“.

Then do: Aktionen, die wirklich etwas ändern

Die Aktion ist der Teil, den Sie sehen wollen. Licht an, Szene aktivieren, Thermostat auf 20 °C, Benachrichtigung aufs Handy, Media Player pausieren, Steckdose aus. Im Editor: Then do → Add action. Wieder Ziel wählen oder nach Typ suchen. Mehrere Aktionen hintereinander? Klar. Wartezeiten? Auch. Bedingungen nur für einzelne Schritte in der Aktionsliste? Geht — wenn Sie später komplexer werden.

Für den Einstieg reicht: eine klare Aktion auf ein klares Gerät. Nicht fünf Szenen, drei Delays und ein Skript, das ein Skript aufruft. Die kurze Version: Eine Automation, die man in einem Satz erklären kann, ist eine gute erste Automation. „Wenn die Haustür aufgeht und es dunkel ist, Diele hell.“ Punkt.

Im Ernst: Aktionen können auch „nur benachrichtigen“ sein. Das ist unterschätzt. Bevor Sie die Heizung automatisch absenken, lassen Sie sich drei Tage lang nur eine Push-Nachricht schicken: „Fenster offen, Heizung würde jetzt runter.“ Beobachten. Dann Aktion scharf schalten. Bastelprojekt mit Sicherheitsnetz.

Parenthese: Run modes (Restart, Queued, Single, Parallel) kommen, wenn Automationen sich selbst in die Quere kommen — etwa weil der Trigger alle zwei Sekunden erneut feuert. Für Einsteiger: Mode Single oder Restart reicht oft. Wenn die Lampe flackert, denken Sie zuerst an Schleifen, nicht an Run modes. Dazu gleich mehr. Spoiler: Die Schleife ist schuld. Fast immer.

Fünf Alltagsbeispiele, die Sie heute nachbauen können

Smarte Lampe Automation Nacht — Nachtflur und smarte Lampe – Automation im Alltag (Symbolbild)

Theorie ohne Beispiele ist wie ein Bewegungsmelder ohne Batterie: theoretisch smart, praktisch tot. Hier fünf Automationen, die im echten Haushalt landen — bewusst simpel, bewusst UI-machbar.

1. Heimkommen nach Sonnenuntergang
Trigger: Person / Zone „home“ betreten (oder WLAN-Präsenz, oder Bluetooth — was Sie schon haben).
Bedingung: Sonne untergegangen (oder Helligkeit unter Schwellwert).
Aktion: Wohnzimmerlicht an, ggf. Diele auf 40 %.
Das ist das Paulus-Beispiel in Ihrer Variante. Kein YAML. Kein Drama.

2. Flurlicht per Bewegung, aber nur nachts
Trigger: Bewegungsmelder Diele → detected.
Bedingung: nach Sonnenuntergang AND NOT (Urlaubsmodus / Gäste-Modus, falls vorhanden).
Aktion: Diele an, nach 90 Sekunden aus (als zweite Aktion mit Delay — oder separate Automation „keine Bewegung → aus“).
Klassiker. Funktioniert. Bis die Katze Nachtschicht hat. Dann Condition „nur wenn Person home“ oder Empfindlichkeit am Sensor drehen.

3. Fenster offen, Heizung höflich absenken
Trigger: Fensterkontakt → open.
Bedingung: Außentemperatur unter 15 °C ODER Heizsaison-Helfer aktiv.
Aktion: Thermostat absenken + Push „Fenster offen im Bad“.
Spoiler: Die Push-Nachricht allein hat bei mir mehr Heizkosten gespart als die Automation selbst — weil Menschen manchmal Fenster aufreißen und vergessen. Die Automation ist der bessere Mitbewohner.

4. Morgenroutine Wochentags
Trigger: Uhrzeit 6:45.
Bedingung: Wochentag Mo–Fr AND Person home.
Aktion: Schlafzimmerlicht langsam an (Transition, falls die Lampe das kann), Kaffeemaschinen-Steckdose an, kurze Wetter-Benachrichtigung.
Klingt nach Hotel. Fühlt sich an wie „okay, der Tag darf starten“. Am Wochenende bleibt die Automation stumm — weil die Bedingung Wochentag greift. Und genau deshalb liebe ich Bedingungen.

5. Waschmaschine fertig
Trigger: Leistungssensor Steckdose fällt unter X Watt (oder bleibt Y Minuten darunter), nachdem er vorher über Schwelle war.
Bedingung: optional Tageszeit, damit Sie nicht um 3 Uhr eine Nachricht kriegen, wenn die Maschine nachts lief.
Aktion: Notify „Wäsche ist fertig“.
Nerd-Alarm: Das ist der Einstieg in numerische Trigger. Etwas fummelig beim Schwellenwert, aber einmal kalibriert unschlagbar praktisch. Die Waschmaschine selbst bleibt stumm. Die Steckdose tratscht.

Fünf Stück. Mehr brauchen Sie am ersten Wochenende nicht. Lieber fünf stabile als fünfzehn, die sich gegenseitig triggern. Und ja: Blueprints (nächster Abschnitt) liefern ähnliche Rezepte fertig zum Anpassen — falls Sie keine Lust haben, jedes Dropdown selbst zu klicken.

Fail: Wenn die Lampe flackert und die Automation sich selbst jagt

Zurück zu zwei Uhr nachts. Flacker-Disco. Was war passiert? Ich hatte eine Automation: „Wenn Wohnzimmerlicht an → Helligkeit auf 80 % setzen.“ Und eine zweite: „Wenn Helligkeit geändert → irgendwas loggen / Szene anpassen.“ Variante B, noch beliebter: Automation A schaltet Licht an. Automation B sieht „Licht an“ und schaltet etwas, das Licht wieder beeinflusst. Trigger → Aktion → neuer State → gleicher Trigger. Schleife. Endlos. Freundlich. Nervtötend.

Die kurze Version der Diagnose:

Automation-Traces öffnen (in der Automation selbst: Traces / Verlauf) — dort sehen Sie, warum sie lief.
Fragen: Ändert meine Aktion denselben Entity-State, den mein Trigger beobachtet?
Wenn ja: Trigger enger machen (to: on statt allgemein), Condition „nur wenn von off kommend“ nutzen, oder Aktion so wählen, dass sie keinen neuen relevanten Trigger auslöst.
Mode prüfen: Parallel bei schnellen Retriggern kann Chaos multiplizieren.
Im Zweifel: Automation deaktivieren, Ruhe einkehren lassen, dann neu bauen.

Alltagsvergleich: Zwei Menschen im Flur, die sich höflich die Tür offen halten und gleichzeitig durchgehen wollen. „Nach Ihnen.“ „Nein, nach Ihnen.“ Fünf Minuten später stehen beide noch da, und die Lampe flackert metaphorisch. Automations-Schleifen sind Höflichkeitsstaus mit Stromrechnung.

Mein Fix damals: Trigger auf „light turns on“ (Wechsel) statt „light is on“, Aktion nur Helligkeit setzen wenn unter 70 %, und die zweite Automation entschärft. Spoiler: Seitdem schläft die Lampe durch. Ich auch. Meistens.

Geräte-Personifikation: Die Automation ist kein böser Geist. Sie ist ein sehr wörtlicher Praktikant. Sie machen genau das, was im Rezept steht — auch wenn das Rezept „Rührei, und wenn Eier bewegt werden, nochmal Rührei“ heißt. Formulieren Sie klar. Der Praktikant hat keinen Common Sense. Der hat Traces.

Blueprints: Fertigrezept statt leerem Topf

Home Assistant sagt es auf der Automations-Übersichtsseite klar: Wenn Sie neu starten, fangen Sie mit Blueprint-Automationen an. Das sind fertige Rezepte aus der Community. Sie konfigurieren nur die Geräte — welcher Bewegungsmelder, welche Lampe, wie lange Delay. Die Logik steckt schon drin.

Im Ernst: Blueprints sind der Unterschied zwischen „ich verstehe Trigger/Bedingung/Aktion“ und „ich will heute Abend Licht, das nach Bewegung ausgeht, ohne drei Fehlversuche“. Sie lernen trotzdem. Sie sehen die Struktur. Sie können später eigene Automationen bauen. Aber der erste Erfolg kommt schneller — und Erfolg hält motiviert, bevor Frustration den Pi aussteckt.

Typische Blueprint-Kandidaten für Einsteiger: Bewegung → Licht mit Timeout, Tür offen → Notify, Knopf → Szene, Anwesenheit → Willkommen-Licht. Klingt simpel. Ist simpel. Und simpel ist am Anfang eine Tugend, keine Beleidigung.

Parenthese: Blueprints sind nicht „Betrug“. Kochen mit Rezept ist auch kein Betrug. Irgendwann improvisieren Sie. Zuerst wollen Sie essen, ohne die Küche abzufackeln. Gleiches Prinzip.

Geräte, Zigbee und warum der Trigger Luft braucht Hardware

Automationen ohne Geräte sind Theaterstück ohne Schauspieler. Sie können mit Zeit und Sonne starten — das reicht für Morgenroutine und Abendlicht. Spannend wird es, wenn physische Dinge triggern: Taster, Kontakte, PIR-Sensoren, Leistungsmesser an Steckdosen.

Viele dieser Dinge kommen über Zigbee (oder Z-Wave, oder Matter — aber Zigbee ist im Heim-Bastelkeller noch immer der Alltagsheld). Bevor Sie „Device“ als Trigger wählen können, muss das Gerät in Home Assistant existieren, Areas haben, einen vernünftigen Namen tragen. Pairing, Stick, Reichweite, der klassische „Gerät ist nach zwei Tagen unavailable“-Fail — das gehört in den Zigbee-Guide, nicht hierher. Hier nur der Hinweis: Ohne stabile Entities keine stabilen Automationen. Müll rein, Disco raus.

Wer noch zwischen Stacks schwankt oder den Stick erst zum Laufen bringen will, liest parallel Zigbee einrichten und kommt danach zurück. Automationen warten. Die UI vergisst nichts. Ihre Geduld manchmal schon.

Nerd-Alarm am Rande: Benennen Sie Entities, bevor Sie Automationen bauen. „sensor.bewegung_diele“ schlägt „sensor.aqara_motion_3f8a“ in sechs Monaten um Längen. Zukünftiges-Sie sagt Danke. Gegenwärtiges-Sie murrt fünf Minuten. Faires Geschäft.

YAML später — und was Sie heute bewusst weglassen

YAML ist optional. Später. Für Exporte, für Diffs in Git, für Templates, die die UI noch umständlich findet. Für den Einstieg ist YAML der falsche Berg. Klettern Sie den UI-Hügel zuerst. Wenn Sie irgendwann eine Automation als YAML sehen wollen: In der Automation gibt es den Editor-Wechsel. Anschauen. Staunen. Zurück zur UI, wenn der Kopf brummt.

Was Sie heute weglassen dürfen:

komplexe Templates,
verschachtelte Choose-Bäume mit zwölf Zweigen,
Automationen, die andere Automationen enablen/disablen in Ketten,
alles, was Sie nicht in einem Satz einem Mitbewohner erklären können.

Was Sie heute mitnehmen: Trigger weckt, Bedingung filtert, Aktion handelt. When / And if / Then do. Blueprints als Starthilfe. Traces bei Flackern. Und die Demut, eine Automation zu deaktivieren, statt sie um 2 Uhr nachts „noch schnell zu fixen“.

Alltagsvergleich zum Schluss dieses Blocks: Automationen sind wie ein Gießplan für Pflanzen. Erst eine Pflanze, ein Wochentag, eine Menge Wasser. Wenn die Pflanze lebt, erweitern. Wenn sie ertrinkt, Plan ändern — nicht heimlich drei weitere Gießsysteme parallel einschalten. Spoiler: Ich habe das mit Lampen gemacht. Die Pflanzen-Metapher kam später. Zu spät für die Disco-Nacht, rechtzeitig für diesen Text.

Was Automationen nicht sind (Dashboard, Installation, Pillar-Mini)

Kurze Abgrenzung, damit niemand den falschen Tab öffnet: Die Installation endet, bevor Automationen Pflichtstoff werden — Host steht, Onboarding durch, Basis-Integration da. Das Dashboard ist Bedienoberfläche: Karten, Badges, Layout. Automationen sind Logik. Der große Einsteiger-Pillar darf ein Mini-Beispiel zeigen; dieses Stück ist das How-to mittendrin im Funnel — Trigger, Bedingung, Aktion ohne YAML-Panik.

Wenn Sie also gerade Kacheln verschieben und warten, dass Logik entsteht: entsteht nicht. Klick auf Automations & scenes. Create new automation. When. And if. Then do. Speichern. Testen. Traces lesen. Lächeln oder fluchen — beides valid, solange Sie lernen.

Im Ernst: Smart Home fühlt sich erst dann nach „Zuhause arbeitet mit“, wenn die erste Automation unsichtbar sitzt und einfach stimmt. Kein App-Öffnen. Kein „Alexa, Licht an“, während die Hände voll sind. Tür auf, dunkel, Diele hell. Paulus hätte genickt. Meine Lampe auch — nachdem wir die Schleife begraben hatten.

Die kurze Version zum Mitnehmen: Automationen = Trigger + Aktion, optional Bedingung. UI-Editor unter Settings → Automations & scenes → Create automation. Blueprints für den Start. Fünf Alltagsrezepte reichen. Flackern = meist Schleife, Traces lesen, Trigger enger. Geräte erst pairen, dann automatisieren. YAML später. Und wenn um zwei Uhr nachts wieder Disco ist — Automation aus, schlafen, morgen mit klarerem Kopf. Ihr zukünftiges Ich und Ihre Nachbarn werden es Ihnen danken.