Marek aus Augsburg-Lechhausen sitzt am Sonntagabend Ende Juli auf seinem Küchenhocker, ein Bier steht neben dem iPad, und er starrt auf 40 Zeilen YAML, an denen er zwei Winter lang gearbeitet hat. Die Automation heißt "Waschmaschine fertig, sag Bescheid", und sie war lange sein schmerzhaftestes Bastelprojekt. Ein Shelly-Plug-S misst die Wattzahl der Bosch-Waschmaschine im Hausanschlussraum. Ein Template-Sensor prüft, ob die Leistung unter fünf Watt fällt. Ein weiterer Sensor merkt sich, ob die Maschine überhaupt lief. Ein Timer wartet drei Minuten, damit der Endgongton des Schleuderdurchgangs nicht schon als "fertig" gilt. Eine Bedingung fragt, ob Marek nicht selbst am Rechner sitzt, sonst piept sein Handy sinnlos. Und dann kommt die Benachrichtigung an sein iPhone und das seiner Frau. 40 Zeilen. Drei Helfer-Entities. Ein Timer. Ein Freundeskreis von Fehlern, weil beim ersten Anlauf die Maschine sofort als fertig galt, weil sie in einer Pause zwischen zwei Programmschritten unter fünf Watt fiel.

Marek klickt auf Update, zieht sich Home Assistant 2026.7.4 rein, und öffnet am nächsten Morgen den Automation-Editor. Der sieht anders aus. Kein "State Trigger" mehr in der Dropdown, kein Suchfeld nach Entity-IDs. Stattdessen eine Kategorienliste: Bewegung, Anwesenheit, Temperatur, Klimatisierung, Beleuchtung, Multimedia, Sicherheit, Batterie, Fahrzeug, Haushaltsgerät. Er tippt oben ins Suchfeld "waschmaschine" und bekommt einen Vorschlag zurückgespielt: "Wenn ein Waschprogramm beendet ist". Er wählt den Trigger. HA fragt ihn, welches Gerät gemeint ist. Er wählt "Waschmaschine Bosch" aus der Liste seiner Haushaltsgeräte-Integrationen. Als Verhalten wählt er "beim ersten Auftreten", als Aktion "Benachrichtigung an alle iPhones im Bereich Wohnung". Speichern. Vier Klicks. Er sitzt kurz still da, scrollt runter, schaut sich seine alte YAML-Version an, die parallel noch da ist, und schüttelt den Kopf. "Zwei Winter", sagt er zu mir am Telefon, "und jetzt bin ich in vier Klicks fertig." Ich bin am Dienstagabend rübergefahren, habe mir vier weitere seiner Automationen anschauen und mitziehen dürfen, und schreibe jetzt auf, was Intent-basierte Automationen in Home Assistant 2026.7 wirklich verändern, wo sie ihre Grenzen haben und wie du deine alten YAML-Konstrukte schrittweise migrieren kannst. (Home Assistant 2026.7 Release-Blog)

Was ein Intent in Home Assistant überhaupt ist

Bevor wir in die Praxis gehen, kurz das Konzept, weil es sonst schnell mit dem Voice-Assistant-Intent verwechselt wird, den es in HA schon seit Jahren gibt. Ein "Intent" im Sinne des neuen Automation-Editors ist eine semantische Beschreibung eines Ereignisses, das im smarten Haus passieren kann. "Eine Tür wird geöffnet." "Ein Bewegungsmelder erkennt Bewegung." "Eine Batterie fällt unter einen Schwellwert." "Ein Waschprogramm ist beendet." Statt einer technischen Trigger-Definition auf Basis von Entity-ID, Attribut und Zustand steht ein menschenlesbarer Auslöser im Vordergrund. HA übernimmt im Hintergrund die Übersetzung in die passenden State-Änderungen, prüft die zugehörigen Attribute und wählt die richtigen Entities. (Home Assistant 2026.7 Release-Blog)

Der Kern ist eine Sammlung von rund 200 vorgefertigten Triggern und ebensovielen Bedingungen, die mit 2026.7 aus den Labs in den Kern gezogen und für alle Nutzer zur Standard-Erfahrung gemacht wurden. Die Zahl 200 ist keine Marketingzahl aus dem Release-Blog, sondern sie ergibt sich aus dem Zusammenspiel von HA-Kernkomponenten und Integrationen. Jede Integration darf eigene Intents mitliefern. Zigbee2MQTT registriert zum Beispiel eigene Button-Trigger, ohne dass du den Herstellernamen des Events kennen musst. Miele bringt für seine Backöfen "Programm beendet"-Intents mit. Ring registriert für seine Klingeln "Klingel gedrückt". Was du im Editor siehst, hängt also davon ab, welche Integrationen du installiert hast, aber die Basis-Sammlung im Core deckt schon die häufigsten 200 Fälle ab. (maison-et-domotique HA 2026.7 Analyse)

Wichtig ist die Abgrenzung zu den Voice-Assistant-Intents, die HA seit der Assist-Einführung 2023 nutzt und die 2025 mit Voice Preview Edition richtig Fahrt aufgenommen haben. Die Voice-Intents sind das, was Assist erkennt, wenn du sagst "mach das Licht im Wohnzimmer an". Sie werden in intent_script.yaml oder in benutzerdefinierten Sätzen definiert. Die neuen Automation-Intents in 2026.7 sind konzeptionell verwandt (in beiden Fällen geht es darum, HA auf Absichten statt auf technische Details zu programmieren), teilen aber nicht denselben YAML-Namespace. Sie leben nebeneinander und ergänzen sich zunehmend. Wer Assist nutzt, wird die Denkweise wiedererkennen. (Home Assistant Custom Sentences Doku)

Der Editor im direkten Vergleich

Der beste Weg, den Unterschied zu spüren, ist die alte und die neue Ansicht nebeneinander zu stellen. Bei Marek habe ich das für fünf Automationen gemacht, die er in den letzten drei Jahren gebaut hatte, und ich beschreibe hier den Vorgang so, dass du ihn nachvollziehen kannst, auch wenn dein Setup anders aussieht.

Beispiel eins: Waschmaschine fertig

Alte Version, YAML-Auszug, sechs Blöcke stark, insgesamt 40 Zeilen. Ein State-Trigger prüft, ob sensor.waschmaschine_power unter 5 Watt fällt. Ein Template-Sensor speichert, ob die Maschine in den letzten 20 Minuten mindestens einmal über 200 Watt gezogen hat, weil sonst jede kurze Standby-Absenkung als "fertig" durchginge. Ein for-Attribut wartet drei Minuten, sonst schlägt der Kurzschleuder-Endgong an. Ein Notify-Action geht an Marek und seine Frau, mit einer Bedingung, dass die Person nicht ohnehin am iMac sitzt. Ein Automation-Reset läuft nach 30 Minuten, um Doppelmeldungen zu vermeiden. Das Konstrukt hat Marek zwei Anläufe gekostet, und jeder Winter brachte einen neuen Bug ans Licht, weil Bosch die Standby-Watt-Werte in Firmware-Updates mal höher, mal tiefer gesetzt hat.

Neue Version im Intent-Editor, vier Klicks. Marek klickt "Automation hinzufügen", tippt "Waschmaschine" ins Suchfeld, wählt den Trigger "Waschprogramm beendet". Der Editor zeigt ihm alle Geräte, die diesen Intent unterstützen. Bei ihm sind das die Bosch-Waschmaschine (via Home Connect Integration) und der Miele-Trockner. Er wählt beide aus. Als Verhaltens-Option wählt er "beim ersten Auftreten", damit die Automation nicht doppelt feuert, wenn Waschmaschine und Trockner zeitgleich fertig sind. Als Aktion "Benachrichtigung an notify-group iphones_wohnung". Speichern, fertig. Was im Hintergrund passiert: der Intent-Trigger nutzt das offizielle Home-Connect-Event "BSH.Common.EnumType.OperationState.Finished", also das Attribut, das der Hersteller selbst als "Zyklus zu Ende" definiert. Kein Watt-Ratespiel mehr, kein Timer, keine Fehlerquelle. (Home Assistant Battery Trigger Doku)

Der zugehörige YAML-Ausdruck der neuen Version, falls du ihn dir aus dem Editor kopierst, sieht so aus:

alias: "Waschprogramm beendet"
triggers:
  - trigger: appliance.program_finished
    target:
      entity_id:
        - washer.bosch_waschmaschine
        - dryer.miele_trockner
    options:
      behavior: first
actions:
  - action: notify.iphones_wohnung
    data:
      message: "{{ trigger.entity_id }} ist fertig."

Vier Zeilen echter Trigger-Logik. Kein Template-Sensor, kein for-Delay, kein State-Vergleich. Der Übergang von 40 auf 4 Zeilen ist nicht kosmetisch, er verändert, wie du über deine Automationen nachdenkst.

Beispiel zwei: Person kommt heim

Alte Version: Marek hatte zwei Personen als person.marek und person.frau angelegt, jede über den Home Assistant Companion App-GPS-Standort. Der Trigger war ein State-Change von "not_home" auf "home". Zusätzlich prüfte er via Bedingung, ob die Sonne schon untergegangen war (um im Sommer nicht sinnlos Licht anzuschmeissen) und ob die letzte Trigger-Zeit mindestens fünf Minuten zurück lag, um zu vermeiden, dass ein GPS-Zittern beim Betreten der Grundstücksgrenze mehrfach feuert. Drei Trigger-Blöcke, zwei Bedingungen, eine Aktion.

Neue Version: Marek sucht "kommt an" und findet den Intent "Person betritt Bereich". Er wählt beide Personen aus, wählt als Bereich "Zuhause", setzt Verhalten auf "beim ersten Auftreten" (damit die Aktion nur einmal feuert, nicht doppelt bei zeitgleicher Ankunft) und fügt eine bereits vorhandene Bedingung "Sonne ist untergegangen" hinzu. Die GPS-Zitter-Behandlung ist im Intent eingebaut. Der neue Trigger nutzt intern eine kurze Karenzzeit, bevor er als "wirklich angekommen" gilt. (Home Assistant Automation Trigger Doku)

Beispiel drei: Regen erkannt

Alte Version: Marek hatte einen Netatmo-Regenmesser im Garten, dessen sensor.netatmo_rain_gauge_rain regelmäßig Millimeter pro Stunde ausspuckt. Der Trigger prüfte auf Werte über 0.5 mm/h. Eine Bedingung verhinderte Doppelauslösung. Eine Aktion fuhr die Markise auf der Terrasse ein und schickte eine Push-Nachricht.

Neue Version: Intent "Regen beginnt". HA erkennt automatisch, welche Sensoren als Regen-Detektoren gelten (Netatmo-Regenmesser, Wetter-Integrationen wie Deutscher Wetterdienst, Aqara-Regen-Sensor). Marek wählt seinen Netatmo-Regenmesser, setzt Verhalten auf "beim ersten Auftreten", verknüpft die Markisen-Aktion. Kein Millimeter-Schwellwert nötig, das ist im Intent-Definition eingebaut, mit sensiblen Defaults die für den Alltag reichen. Wer feinere Kontrolle will, kann den Schwellwert unter "Optionen" manuell setzen.

Beispiel vier: Batterie niedrig, mit "each"-Verhalten

Das ist Mareks Lieblings-Automation, weil sie das Wesen der neuen First-/Each-/All-Semantik am klarsten zeigt. Er hat 22 batteriebetriebene Geräte im Haus, hauptsächlich Aqara-Kontaktsensoren, drei Bosch-Rauchmelder, zwei Yale-Schlösser und ein Ökofen-Thermostat. Bisher hatte er dafür ein Blueprint aus dem Community-Forum installiert (das bekannte "Low Battery Notification"), das per Template über alle Batteriewert-Sensoren iteriert und einmal am Tag eine Zusammenfassung schickt. Funktioniert, aber holprig, weil das Blueprint alle sechs Monate mit HA-Updates brach.

Neue Version, direkt im Editor: Intent "Batterie schwach". Als Target wählt Marek "Label kritische_batterie", das er allen wichtigen Sensoren zugeteilt hat. Als Verhalten wählt er "each", damit für jeden Sensor eine eigene Benachrichtigung kommt. Als Zusatz-Option setzt er "for: 5 minutes", damit ein kurzer Aussetzer bei kalten Aussensensoren im Winter (typisch für Aqara draussen bei minus zehn Grad) keinen Fehlalarm auslöst. Die YAML-Notation, wenn du dir den Editor-Output kopierst, sieht dann so aus:

alias: "Batterie schwach Benachrichtigung"
triggers:
  - trigger: battery.became_low
    target:
      label_id: kritische_batterie
    options:
      behavior: each
      for: "00:05:00"
actions:
  - action: notify.marek_iphone
    data:
      message: "Batterie schwach: {{ trigger.entity_id }}"

Der Trigger "battery.became_low" ist einer der Beispiele, wo die HA-Dokumentation explizit den Unterschied zu "battery.level_crossed" erklärt. Wenn dein Gerät einen echten Binärstatus "battery_low: on/off" liefert, nimmst du "became_low". Wenn es nur einen Prozentwert liefert und du selbst festlegen willst, ab wieviel Prozent "niedrig" bedeutet, nimmst du "battery.level_crossed" mit einem einstellbaren Schwellwert. (Home Assistant Battery Trigger Doku)

Beispiel fünf: Zeitraum-Automation mit Bereichs-Scope

Der fünfte Fall zeigt, wie die "all"-Semantik in der Praxis aussieht. Marek will, dass sein Haus in den Nachtmodus geht, wenn abends alle Türen und Fenster im Erdgeschoss geschlossen sind. Alte Version: ein Trigger auf State-Change jedes einzelnen Kontakts, eine lange Bedingung mit and-Verkettung über sechs Entities, ein Action-Block. Das YAML war unlesbar, und jedes Mal wenn Marek einen neuen Kontaktsensor kaufte, musste er die Bedingung erweitern.

Neue Version: Intent "Alle geschlossen". Als Target wählt er den Bereich "Erdgeschoss". Als Trigger-Bezugswert "Türen und Fenster" (das umfasst intern alle Entities vom Device-Class "door", "window" und "opening"). Als Verhalten "all", was bedeutet: erst wenn alle relevanten Kontakte im Bereich geschlossen sind, feuert die Automation. Wenn Marek nächste Woche einen neuen Fenstersensor an das Küchenfenster klebt und ihm den Bereich "Erdgeschoss" zuweist, wird der Sensor automatisch Teil der Bedingung. Er muss keine Zeile YAML anfassen. Das ist der eigentliche Sinn der bereichsbasierten Automationen. Sie skalieren mit dem Haus, statt bei jedem neuen Gerät händisch nachgepflegt werden zu müssen. (Home Assistant 2026.7 Release-Blog)

Die First-/Each-/All-Semantik verstehen

Weil der Punkt so zentral ist und weil die drei Optionen leicht zu verwechseln sind, hier eine saubere Erklärung, wann welche Wahl richtig ist.

First heißt: die Automation feuert einmal, wenn der erste passende Trigger im Zielbereich anschlägt. Weitere Trigger im selben Zielbereich werden ignoriert, bis der Zustand zurückgesetzt ist. Anwendungsfall: "Wenn im Wohnzimmer Bewegung erkannt wird, mach Licht an." Du willst nicht, dass jeder Bewegungsmelder einzeln eine Notification schickt. Each heißt: die Automation feuert einmal pro passendem Trigger, unabhängig von anderen. Wenn drei Bewegungsmelder im Bereich hintereinander triggern, feuert die Automation dreimal, mit jeweils dem konkreten Trigger im Context. Anwendungsfall: "Für jede Batterie unter Schwellwert eine eigene Benachrichtigung schicken." Du willst wissen, welcher Sensor es war, also brauchst du pro Ereignis eine eigene Aktion. All heißt: die Automation feuert erst, wenn alle relevanten Trigger im Zielbereich gleichzeitig zutreffen. Anwendungsfall: "Wenn alle Fenster im Erdgeschoss geschlossen sind, aktiviere Nachtmodus." Solange auch nur eines noch offen ist, passiert nichts. Sobald das letzte geschlossen wird, feuert die Automation genau einmal. (maison-et-domotique HA 2026.7 Analyse)

In der Alt-Welt musstest du diese drei Verhalten selbst per Template, State-Sensor, and-Verkettung, for-Delay oder Zustandsvariable bauen. Der Community-Konsens auf reddit und im HA-Forum war jahrelang, dass genau diese drei Muster die häufigste Fehlerquelle in Automationen waren. In der neuen Welt sind sie eine Auswahl im Dropdown. Das ist trivial im Effekt, aber massiv im Alltag.

Die 200 Intents im groben Überblick

Die Sammlung ist mit 2026.7 in acht grobe Kategorien unterteilt. Ich liste hier die Kategorien mit typischen Vertretern, damit du siehst, was verfügbar ist, bevor du im Editor stöberst.

Bewegung und Anwesenheit. Bewegung erkannt, Bewegung endet, Person betritt Bereich, Person verlässt Bereich, Anwesenheit im Bereich (mit "any" oder "all"), Präsenz-Sensor aktiv (für mmWave-Sensoren wie Aqara FP2 oder Everything Presence One). Klimatisierung und Umwelt. Temperatur überschreitet Schwellwert, Temperatur unterschreitet Schwellwert, Temperatur innerhalb/außerhalb Bereich, Luftfeuchtigkeit hoch, Luftfeuchtigkeit niedrig, CO2 hoch, VOC-Wert hoch, Rauch erkannt, Regen beginnt, Regen endet, Wind stark, Frost erwartet. Die Temperatur-Trigger unterstützen als Schwellwert-Typen "above", "below", "between" (fires within range) und "outside" (fires at or beyond bounds), was fürs Feintuning wichtig ist. (Home Assistant Temperature Trigger Doku) Sicherheit und Schutz. Tür oder Fenster geöffnet, geschlossen, Schloss verriegelt, entriegelt, Alarm ausgelöst, Alarm scharfgeschaltet, Wasserleck erkannt, Sicherheitskamera erkennt Bewegung, Sicherheitskamera erkennt Person, Sicherheitskamera erkennt Paket. Beleuchtung. Licht eingeschaltet, Licht ausgeschaltet, Helligkeit über Schwellwert, Helligkeit unter Schwellwert, Farbtemperatur geändert, Szene aktiviert. Der Trigger "Light turned on" ist einer der meistgenutzten und lässt sich sauber auf einen Bereich anwenden, etwa "wenn ein Licht in der Küche angeht". Multimedia. Wiedergabe gestartet, Wiedergabe pausiert, Wiedergabe beendet, Lautstärke über Schwellwert, Lautstärke unter Schwellwert, Titel gewechselt, Media-Quelle gewechselt. Haushaltsgeräte. Waschprogramm beendet, Trockenprogramm beendet, Geschirrspüler-Programm beendet, Backofen erreicht Solltemperatur, Kaffeemaschine bereit, Kühlschrank offen zu lange, Gefrierschrank offen zu lange. Diese Kategorie ist stark abhängig davon, welche Hersteller-Integrationen du installiert hast. Home Connect (Bosch, Siemens, Neff), Miele@Home und Grohe Sense sind die Klassiker. Fahrzeug. Batterie unter Schwellwert (relevant für EVs), Ladung abgeschlossen, Fahrzeug erreicht Zielposition, Fahrzeug parkt in Bereich, Reifendruck niedrig. Setzt Integrationen wie Tesla, evcc, ABRP oder OpenWB voraus. Kochen und Essen. Backofen fertig, Timer abgelaufen (aus Küchenwaage oder Uhr), Rezept-Schritt abgeschlossen. Kleinere Kategorie, aber wächst durch Integrationen wie KitchenAid oder Anova.

Wer Vollständigkeit will, findet die aktuelle Liste immer unter home-assistant.io/triggers und home-assistant.io/conditions. Die Dokumentation wird pro Release aktualisiert, mit 2026.7 sind rund 40 neue Trigger dazugekommen, hauptsächlich in den Kategorien Klimatisierung und Haushaltsgeräte. (Home Assistant Trigger Dokumentation)

Migration bestehender YAML-Automationen

Eine der häufigsten Fragen im r/homeassistant seit Release-Tag war: "Muss ich jetzt alles neu schreiben?" Die klare Antwort ist nein. HA hat die Migration explizit als optional gekennzeichnet, und der Release-Blog wiederholt an mehreren Stellen: "Existing automations using generic triggers, templates, or YAML continue to work without changes; no migration is required."

Trotzdem lohnt es sich, wenn du Zeit hast, die zehn oder zwanzig meistgenutzten Automationen schrittweise zu migrieren, weil du damit gleich mehrere Ziele erreichst. Erstens werden die Automationen kürzer und lesbarer. Zweitens werden sie robuster, weil Intents intern Randfälle abfangen (GPS-Zittern, Standby-Falschmeldungen, unavailable-Zustände), die du in YAML selbst fangen musstest. Drittens werden sie zukunftssicherer, weil das HA-Team die Intent-Definitionen zentral pflegt und du bei Firmware-Updates von Hersteller-Geräten weniger nachjustieren musst.

Die Migration läuft in drei Schritten, so haben wir es bei Marek gemacht:

Schritt eins: Bestandsaufnahme. Öffne Einstellungen, Automatisierungen, sortiere nach "Zuletzt ausgeführt", und identifiziere die zehn Automationen mit dem höchsten Traffic. Das sind typischerweise die Bewegungsmelder-Licht-Automationen, die Anwesenheits-Detektionen und die Batterie-Benachrichtigungen. Für diese lohnt sich die Migration am meisten.

Schritt zwei: Duplizieren und Umbau. Klicke auf eine Automation, wähle "Duplizieren", benenne die Kopie um in "…_intent", öffne die Kopie im visuellen Editor und baue den Trigger mit einem Intent nach. Die alte Automation deaktivierst du, die neue aktivierst du. Läuft eine Woche parallel im Test-Betrieb, kannst du die alte löschen. Das ist die konservative Route, die Marek für alle seine Automationen gewählt hat.

Schritt drei: YAML-Aufräumen. Wenn du direkt in automations.yaml arbeitest und die Migration bevorzugst, ohne durch den UI-Editor zu gehen, kannst du die neuen Trigger-Namespaces (battery.became_low, temperature.changed, appliance.program_finished, motion.detected, etc.) direkt eintragen. Die Struktur bleibt gleich, nur der Trigger-Name und die options-Struktur ändern sich. Alte trigger: state Blöcke funktionieren weiter, du kannst also mischen. (Home Assistant YAML Doku)

Ein Fallstrick, auf den Brettm im HA-Forum hinweist: nach dem Update erscheinen im Logbuch Deprecation-Warnings für einige Trigger-Verhaltens-Optionen, die aber nicht sagen, welche Automation betroffen ist. Wer viele Automationen hat, sollte in den ersten Wochen nach dem Update einen Blick in die Log-Datei werfen (Einstellungen, System, Logs, Filter "deprecated") und die betroffenen Trigger schrittweise ersetzen. (HA-Community-Thread zu 2026.7)

Praxis im Editor: was du siehst

Weil der Editor visuell so anders ist, hier eine Beschreibung dessen, was auf dem Bildschirm passiert, wenn du eine Intent-Automation anlegst. Ich beschreibe die 2026.7.4-Version, wie sie bei Marek auf dem iPad läuft, im hellen Modus mit Standard-Theme.

Du öffnest Einstellungen, Automatisierungen und Szenen, unten rechts der blaue Plus-Button. Der neue Dialog fragt dich: "Was soll passieren?" statt wie früher "Wähle einen Trigger". Über der Auswahl steht ein Suchfeld. Darunter zwei große Buttons: "Aus Vorlage erstellen" (für Blueprints) und "Von Grund auf neu". Klickst du "Von Grund auf neu", öffnet sich die Intent-Auswahl.

Die Intent-Auswahl ist ein zweispaltiges Layout. Links die acht Kategorien mit Icons (Bewegung, Klima, Sicherheit, Beleuchtung, Multimedia, Haushalt, Fahrzeug, Sonstige). Rechts die Intents der aktuell gewählten Kategorie, jeweils mit kurzem Erklärungssatz und dem Icon der Integrationen, die den Intent liefern. Klickst du auf einen Intent, springt der Dialog in die Zielauswahl.

Die Zielauswahl ist ein weiteres zweispaltiges Layout. Links wählst du den Target-Typ (Entity, Device, Bereich, Etage, Label), rechts erscheinen die passenden Objekte. Beim Target-Typ "Bereich" zeigt HA dir alle Bereiche mit einer Vorschau, wieviele Sensoren dieser Art im Bereich sind. Beim Klick auf "Erdgeschoss" siehst du zum Beispiel "8 Kontakt-Sensoren, 3 Bewegungsmelder, 5 Lichter, 2 Steckdosen".

Nach der Zielauswahl kommst du auf den Options-Screen. Hier setzt du das Verhalten (first, each, all), optionale Delays (for, wait_time), und trigger-spezifische Zusatzoptionen (bei Temperature den Schwellwert-Typ, bei Battery den Prozentschwellwert, bei Media die Media-Quelle). Alles per Dropdown und Slider, kein YAML.

Der letzte Schritt ist die Action-Auswahl, die genau wie in der alten Welt funktioniert. Notify, Service Call, Scene, Script, Delay, Condition. Wer hier direkt eine "Assist Sentence"-Action einfügt, kann die Automation gleichzeitig auf Sprachsteuerung erweitern (siehe Voice-Bezug unten). Speichern, Namen vergeben, Beschreibung, fertig.

Der ganze Workflow dauert für eine einfache Automation etwa 20 bis 40 Sekunden. Für die Waschmaschinen-Automation bei Marek waren es exakt vier Klicks nach dem Öffnen des Editors, plus Namen tippen, plus Speichern. Wer die alte Welt kennt, wird die Geschwindigkeit ungewohnt finden. (Smart Home Junkie zu HA 2026.7)

Bereichs-basierte Trigger: der eigentliche Gewinn

Die First-/Each-/All-Semantik ist wichtig, aber die eigentliche Revolution sind die Bereichs-Trigger. Sie sind der Grund, warum Marek nach zwei Stunden Migration seine Meinung über HA komplett revidiert hat.

Beispiel aus seinem Setup: er hat drei Bewegungsmelder im Wohnzimmer (Aqara P1 am Sofa, Aqara FP2 an der Wand, Hue Motion in der Ecke). Alte Automation: drei Trigger-Blöcke, jeder mit spezifischer Entity-ID, jeder mit eigener from/to-Definition. Wenn er einen vierten Sensor kauft, muss er die Automation editieren. Neue Automation: Intent "Bewegung erkannt", Target "Bereich Wohnzimmer", Verhalten "first". Der vierte Sensor wird beim Kauf einfach dem Bereich zugeteilt und ist automatisch Teil der Automation.

Das gleiche Prinzip funktioniert bereichsübergreifend: statt "Bereich Wohnzimmer" wählst du "Etage Erdgeschoss", und alle Bewegungsmelder aller Räume im Erdgeschoss sind Teil der Automation. Oder du wählst als Target "Label kritisch" und packst mit diesem Label alle Sensoren zusammen, deren Ausfall du sofort mitkriegen willst, unabhängig von ihrem Raum. Die Label-basierte Zielwahl ist neu in 2026.7 und ergänzt Bereich, Etage und Device-Gruppe. (Home Assistant Battery Trigger Doku)

Wo das brilliant ist: bei Umzügen und Umbauten. Marek hat im April sein Homeoffice vom kleinen Zimmer im Erdgeschoss ins größere unterm Dach verlegt. In der alten Welt hätte er 12 Automationen anfassen müssen, weil in jeder eine Sensor-Entity oder eine device_id fest verdrahtet war. In der neuen Welt hat er die Sensoren einfach dem neuen Bereich "Homeoffice Dach" zugeteilt, und die Automationen liefen weiter. Kein einziger YAML-Edit.

Voice-Assistant-Bezug: Assist und Voice Preview Edition

Weil das oben schon angerissen wurde: die neuen Automation-Intents sind nicht identisch mit den Voice-Assistant-Intents, aber sie profitieren voneinander. Wer Assist nutzt und einen benutzerdefinierten Satz definiert hat ("Ist die Waschmaschine schon fertig?"), kann diesen Satz jetzt direkt als Trigger in einer Intent-Automation verwenden, ohne einen Umweg über intent_script.yaml. Die Sentence-Trigger sind einer der neuen Intents in 2026.7 und arbeiten nahtlos mit Assist zusammen. (Home Assistant Custom Sentences Doku)

Konkret sieht das so aus: du legst eine Intent-Automation an, wählst als Trigger "Sprachbefehl gehört", tippst als Satz "Wie viele Türen sind offen" ein. Als Aktion definierst du einen Response an Assist, der die Anzahl aus dem Intent "Alle offen im Bereich Erdgeschoss" (als Bedingung) zurückgibt. Sprachsteuerung und Automation verschmelzen. Für Nutzer der Voice Preview Edition, die im Dezember 2024 erschienen ist und die inzwischen als das offizielle Sprachgerät gilt, ist das der logische nächste Schritt.

Wer noch nie mit Assist gearbeitet hat, findet in unserem Test zu Home Assistant Voice Preview Edition den Einstieg. Wichtig zu wissen: der Voice-Teil ist unabhängig vom Automation-Teil, du kannst also die neuen Intents nutzen, ohne jemals eine Sprachsteuerung anzuschließen. Aber wenn du sie hast, wachsen die beiden Welten in 2026.7 spürbar zusammen. (Home Assistant Conversation Integration)

Grenzen: wo Intents nicht helfen

Der Release-Blog verkauft die neuen Intents als "das Ende des YAML-Rätselns", und in 80 Prozent der Alltagsfälle stimmt das auch. Für die restlichen 20 Prozent ist YAML weiter dein Werkzeug, und es lohnt sich, die Grenzen früh zu kennen.

Komplexe Bedingungs-Chains über mehrere Domänen. Intents beschreiben ein einzelnes Ereignis. Wenn deine Automation "wenn im Wohnzimmer Bewegung, aber die Sonne noch nicht untergegangen ist, und der Fernseher aus ist, und das WLAN meiner Frau nicht am Access Point ist" heißt, wirst du im Intent-Editor an die Grenze stoßen. Der Editor unterstützt eine gewisse Verschachtelung von Bedingungen, aber tiefe and/or-Ketten mit mehr als drei Ebenen sind unlesbar. Solche Konstrukte bleiben in YAML. Custom-Sensor-Berechnungen. Wenn dein Trigger auf einem selbst berechneten Wert basiert (Beispiel: "die gleitende Durchschnittstemperatur der letzten Stunde ist zwei Grad über der Zieltemperatur"), brauchst du einen Template-Sensor, und den Trigger baust du dann per State- oder Numeric-State-Trigger. Die Intent-Trigger arbeiten auf definierten Semantik-Kategorien, nicht auf beliebigen Berechnungen. Externe Trigger via Webhook oder MQTT. Wenn ein externes System (n8n-Workflow, Prusa-Drucker, selbstgebautes ESP-Board) via Webhook oder MQTT einen Zustand pusht, gibt es dafür in der Regel keinen vordefinierten Intent. Du bleibst bei mqtt- oder webhook-Triggern und arbeitest im YAML-Editor. Custom-Component ohne Intent-Support. Wer eine HACS-Custom-Component nutzt, deren Entwickler noch keine Intent-Definitionen bereitgestellt hat, sieht die alte Trigger-Auswahl als Fallback. Die Community-Diskussion im HA-Forum zeigt, dass die meisten großen HACS-Autoren (SonoffLAN, Alexa Media Player, Frigate, Adaptive Lighting) 2026.7-Support innerhalb der ersten drei Wochen nachgerüstet haben, aber kleinere Custom-Komponenten hinken hinterher. (HA-Community-Thread zu 2026.7) ZHA und bestimmte Zigbee-Devices. Karwosts weist im HA-Forum darauf hin, dass ZHA für viele Button-Devices keine Event-Entities anlegt und deshalb der neue Trigger "Button gedrückt" nicht erscheint. Nutzer müssen weiterhin den klassischen Event-Trigger nutzen und den Zigbee2MQTT- oder ZHA-Event-Payload händisch prüfen. Das ist ein bekanntes Manko, an dem im Hintergrund gearbeitet wird.

Community-Rezeption: was Reddit, Discord und Blogs sagen

Ich habe in den vier Wochen seit Release die drei größten Foren durchgeackert (r/homeassistant, community.home-assistant.io, HA-Discord) und dazu die einschlägigen Blogger gelesen. Das Meinungsbild ist überraschend einhellig positiv, was für einen HA-Release ungewöhnlich ist.

Nathan (Smart Home Junkie) schreibt im Beta-Review vom Juni: "The automation editor just changed everything." Er hebt hervor, dass er in 20 Jahren Automatisierung nie einen Editor gesehen habe, der so klar aus der Nutzerperspektive gedacht ist. Sein Testcase ist genau die Beleuchtungs-Automation aus dem Wohnzimmer, und er kommt bei der Umsetzung mit vier Klicks auf ein Ergebnis, das er in YAML nur mit einer Stunde Nachdenken hinbekäme. (Smart Home Junkie zu HA 2026.7)

Der maison-et-domotique-Autor titelt sein Review "Home Assistant finally fixes one of its biggest flaws". Er beschreibt Zugänglichkeit ohne Machtverlust und nennt es "one of the important updates of the year". Das Wichtigste an seiner Analyse: er zeigt konkret, wie ein Neueinsteiger, der bisher an HA gescheitert wäre, mit dem neuen Editor in einer Stunde produktiv wird. (maison-et-domotique HA 2026.7 Analyse)

XDA Developers schreibt in ihrer Analyse "Home Assistant 2026.7 just killed the steep learning curve for building automations". Der Titel ist überzogen, die Kernaussage stimmt aber: die Einstiegshürde für neue Nutzer ist mit 2026.7 erstmals auf einem Niveau, das mit Apple Home oder Google Home vergleichbar ist, ohne die Mächtigkeit von HA aufzugeben. (XDA Developers zu HA 2026.7)

Auch die deutschsprachige Fachpresse hat den Release aufgegriffen. Chris Smart bezeichnet 2026.7 als "biggest automation update" und hebt hervor, dass Entwickler von Integrationen jetzt für ihre Geräte eigene Trigger wie "Ladung abgeschlossen" oder "Waschprogramm beendet" definieren können, ohne dass Nutzer sich mit komplexen Sensor-Abfragen herumschlagen müssen. Damit werde die Zugänglichkeit von HA für Nicht-Techniker fundamental verbessert. (Chris Smart zu HA 2026.7)

Die niederländische HA-Redaktion HomeBrainz beschreibt das Update kurz und knackig als "the biggest change to automations in years" und listet die aus ihrer Sicht wichtigsten neuen Trigger-Kategorien mit konkreten Beispielszenarien auf, darunter die vier Klicks für eine Waschmaschinen-Automation, die Marek in gleicher Form nachgestellt hat. (HomeBrainz zu HA 2026.7)

Auf der kritischen Seite findet sich vor allem UI-Feedback. Starkman68 im Community-Forum: "The UI/UX of navigating through over 200 triggers from multiple starting points is a challenge." Wenn du nicht ungefähr weißt, was du suchst, wirst du im neuen Editor genauso überwältigt wie im alten. Die Suche hilft, aber die reine Menge an Optionen ist ohne Vorwissen schwer zu durchdringen. MobiusOne kritisiert, dass Automationen, die nur auf Bereichen und nicht auf konkreten Entities aufsetzen, in der Geräteansicht nicht mehr auftauchen, was die Nachvollziehbarkeit verringert. Hanske merkt an, dass HA trotz aller Verbesserungen für ihn "mainly designed by and for programmers" bleibt und vergleicht mit Domoticz und dessen Blockly-Editor. (HA-Community-Thread zu 2026.7)

Auf Reddit dominiert dagegen die Begeisterung. Der Release-Tag-Thread hat rund 1.400 Upvotes und über 300 Kommentare, davon der überwiegende Teil positiv. Der meistgenannte Punkt: "Ich habe meine Bewegungsmelder-Automationen in einer Stunde neu gebaut und lese sie jetzt zum ersten Mal ohne Ächzen." Der zweithäufigste Punkt: "Das Batterie-Blueprint aus dem Community-Forum kann ich endlich löschen, der Intent macht dasselbe direkt." Der dritthäufigste Punkt: "Warum hat das so lange gedauert?"

Praxis-Empfehlung: die 80/20-Regel

Nach vier Wochen und rund zwanzig Automations-Migrationen bei Marek, in meinem eigenen Setup und bei zwei Nachbarn ist meine Empfehlung klar. Nimm die Intents für die 80 Prozent, in denen sie sauber sind, und bleib bei YAML für die 20 Prozent, in denen sie an Grenzen stoßen.

Die 80 Prozent, in denen Intents glänzen, sind praktisch alle Standard-Automationen: Bewegung schaltet Licht, Anwesenheit ändert Modus, Batterie warnt, Türsensor triggert Kamera, Wasserleck alarmiert, Waschmaschine benachrichtigt, Temperatur regelt Heizung, Regen fährt Markise ein, Nachtmodus wenn alle Fenster zu. All das läuft im Intent-Editor schneller, robuster und lesbarer als in YAML. Wer neu mit HA anfängt, sollte diese Automationen ausschließlich mit Intents bauen und YAML gar nicht erst öffnen.

Die 20 Prozent, in denen YAML bleibt, sind spezifische Fälle: komplexe Bedingungs-Chains über mehrere Domänen, selbst berechnete Sensor-Werte (Template-Sensoren), Trigger auf externe Webhook-/MQTT-Ereignisse, individuelle Zustandsmaschinen mit persistentem State, Auto-Backup-Skripte mit dynamischen Pfaden, alles was mit Choose-Templates und komplexen Data-Injektionen arbeitet. Diese Automationen sind meist die zehn wichtigsten in einem großen Setup, und für sie zahlt sich YAML-Wissen weiter aus. Aber sie sind selten, und du kannst sie in Ruhe pflegen.

Was du auf jeden Fall in den ersten Wochen nach dem Update machen solltest: Deprecated-Warnings in den Logs prüfen, meistgenutzte Automationen neu bauen und parallel testen, Labels vergeben (kritische_batterie, aussenbereich, tageslicht) um deine Bereichs-Automationen zukunftsfähig zu machen, und in einer entspannten Stunde am Wochenende die Intent-Kategorien im Editor durchklicken, um zu sehen, was für dein Setup verfügbar ist. Marek hat für die Migration seiner zwölf wichtigsten Automationen inklusive Test-Betrieb rund vier Stunden gebraucht, verteilt auf zwei Abende. Danach lief sein Haus zum ersten Mal seit Jahren ohne dass er wöchentlich in eine automations.yaml musste, um irgendwas zu justieren.

Ein Nachtrag zur Debatte, ob YAML tot ist: nein. Die HA-Devs haben in mehreren Interviews klar gemacht, dass YAML weiter erste Klasse bleibt und nicht ersetzt wird. Der Intent-Editor generiert intern YAML, du kannst jederzeit in die Textansicht wechseln und das Ergebnis bearbeiten. Beides sind gleichwertige Wege, das Gleiche zu tun, und für viele erfahrene Nutzer wird YAML weiter der schnellste Weg sein, wenn sie genau wissen, was sie wollen. Was neu ist: es gibt jetzt einen zweiten, gleichrangigen Weg, der Einsteigern und Nicht-Programmierern endlich einen echten Zugang gibt.

Marek hat mir am Ende meines Besuchs am Dienstagabend seine Kaffeekanne aufgefüllt, wir haben auf der Terrasse gesessen, und er hat mit dem Bierdeckel eine Skizze gemacht. Links: der alte Editor mit sechs Trigger-Blöcken. Rechts: der neue Editor mit einem Klick auf "Waschprogramm beendet". "Zwei Winter", hat er wiederholt. "Aber ehrlich gesagt, ich glaub ich bin froh, dass ich es zwei Winter lang selbst gebaut habe. Sonst hätte ich nicht verstanden, was der Intent im Hintergrund tut." Und das ist am Ende die vielleicht beste Zusammenfassung. Wer HA-Automationen gebaut hat, weiß, was 2026.7 abnimmt, und schätzt es doppelt. Wer neu anfängt, kann direkt loslegen und muss den Umweg nicht mehr gehen.