Die Verwaltung von Home-Assistant-Benachrichtigungen kann bei einem wachsenden System zu einer Herausforderung werden. Insbesondere wenn wir nicht mehr wissen, wer wohin Benachrichtigungen sendet. Ich habe in 28 Automationen eine gemeinsame Benachrichtigungslogik eingebaut, die Information und Zustellung voneinander trennt.
Keine der Automationen kennt mehr das konkrete Ziel der Benachrichtigung. Und auch keine der Automationen muss sich um den Weg der Zustellung kümmern. Stattdessen senden alle Automationen ihre Informationen an ein zentrales Skript, welches sich um die Ausführung, Zustellung und das Routing kümmert. Dadurch muss ich bei einem Gerätewechsel (z. B. ein neues Smartphone) nur im Skript Änderungen vornehmen. Es ist nicht mehr notwendig, dass ich alle 28 Automationen manuell anpasse.
Seit mehreren Monaten setze ich dieses Benachrichtigungsskript nun schon ein und bin nach wie vor davon überzeugt, dass es eine der besten Investitionen in mein Smart Home ist. In diesem Artikel möchte ich dir die Grundgedanken, Umsetzung und Erfahrungen der letzten Monate zeigen.
Warum die gleiche Logik in 28 Automationen?
Bevor ich mir Gedanken über die Abstraktion gemacht habe, mussten verschiedene Automationen (damals noch nicht 28) ihre Benachrichtigungen selbst an mich senden. Die Ausgangslage war dabei immer die gleiche: Soll die Benachrichtigung per Push, Sprache oder über beide Kanäle erfolgen?
Dazu kam die Frage, wieso meine Echos sprachen, obwohl niemand zu Hause war. Und wie sollte ich mit der mehrfach vorhandenen Logik im Falle von Änderungen vorgehen? Mit steigender Anzahl an Automationen stieg auch der Zeitaufwand für Änderungen. Ganz deutlich zu sehen daran, wenn ich das Smartphone wechsle und an jeder Stelle das neue Gerät hinterlegen muss.
Der wachsende Wartungsaufwand und die fehlende einheitliche Logik bei Benachrichtigungen haben mich dann zu einer Lösung gebracht, die in der Softwareentwicklung üblich ist: Abstraktion. Hier geht es nicht darum, weniger Informationen zu senden. Die Zustelllogik muss an einer Stelle gebündelt sein, so dass diese Stelle über die Art und das Ziel der Benachrichtigung entscheidet und nicht mehr jede Automation für sich. Zusätzlich soll diese Logik weitere Faktoren berücksichtigen, die Auswirkungen auf meine Benachrichtigungen haben, wie zum Beispiel ein Nachtmodus.
In Summe reduziert der Einsatz einer solchen zentralen Zustelllogik meinen Wartungsaufwand und vereint meine Perspektive des Softwareentwicklers mit den Möglichkeiten, die Home Assistant durch eigene Skripte bietet.
Mein wichtigstes Learning: Bei Normalität herrscht Ruhe
Im Zuge meiner Vereinheitlichung bin ich außerdem auf einen Sachverhalt gestoßen, der mir auch bereits öfter in Unterhaltungen aufgefallen ist: Das Smart Home neigt in vielen Fällen zum Plaudern. Damit meine ich, dass viel zu viele Informationen versendet werden.
Aber nicht jedes Ereignis braucht eine Meldung. Normalzustände brauchen in der Regel keine aktive Meldung. Wichtig sind Abweichungen und echter Handlungsbedarf. Denn zu viele Meldungen führen zur Abstumpfung und wir nehmen sie im Alltag nicht mehr richtig wahr.
Mein eigenes Vorgehen habe ich dazu auch neu ausgerichtet. Ich frage mich schließlich bei jeder Benachrichtigung, ob ich sie überhaupt bekommen muss. Welchen Mehrwert bietet mir diese Information überhaupt? Dabei kommt für mich ganz klar heraus, dass viele Informationen es nicht wert sind, zugestellt zu werden. Andere wiederum nehme ich als hilfreich wahr (z. B. Statusmeldung der Waschmaschine) und lasse sie mir bewusst zustellen.
Ein gutes Beispiel hierfür ist mein Self-Healing für die VELUX-KLF-200. Hier erhalte ich eine Information darüber, dass die Zentrale gerade nicht erreichbar ist und mit dem Self-Healing gestartet wird. War das Self-Healing erfolgreich, erhalte ich auch darüber eine Information. Das ist nützlich für den Beginn, kann auf Dauer aber auch anstrengend werden. Ich überlege daher aktuell, ob ich mir nicht einfach nur noch dann eine Benachrichtigung zustellen lasse, wenn das Self-Healing nicht erfolgreich war. Denn vom eigentlichen Reparaturversuch muss ich im Grunde nichts mitbekommen, solange er erfolgreich ist. Das habe ich ja eben genau deshalb an eine Automation abgegeben, damit ich mich gedanklich nicht mehr damit beschäftigen muss.
Das zeigt aus meiner Sicht sehr schön, dass wir neugierig auf Informationen sind, diese aber oft gar nicht brauchen. Weniger Informationen bedeuten dann für mich weniger Unterbrechungen, mehr Fokus und vor allem mehr Zeit für das Wesentliche.
Die Automation kennt das Ereignis – das Skript übernimmt die Zustellung
Im laufenden Betrieb sieht es nun so aus, dass die konkrete Automation weiterhin ihrer eigentlichen Tätigkeit nachgeht. Sie durchläuft die zuvor von mir festgelegten Schritte und ruft beispielsweise am Ende das Skript zur Benachrichtigung auf. Darin enthalten sind verschiedene Parameter, die ich während der Erstellung setze und die das Verhalten beeinflussen.
Bei Benachrichtigungen legt die Automation damit nur noch die Information fest und ruft das zentrale Skript auf. Die Zustellung übernimmt sie nicht mehr.
Das hat einerseits zur Folge, dass ich vorhandene Logiken nicht mehr duplizieren muss und andererseits meine Automationen übersichtlicher werden. Durch das Auslagern behält die Automation an sich nur noch ihren wesentlichen Kern, für den sie ursprünglich von mir oder mittlerweile der KI gebaut wurde.
Das zentrale Skript enthält die Zustelllogik und kennt die konkreten Geräte und Regeln. Es wertet eingegangene Parameter aus und sorgt zuverlässig für die Zustellung über den gewählten Weg. Dabei ist der gedankliche Weg der Benachrichtigung für mich von entscheidender Bedeutung:
In der Automation wird über die Relevanz der Benachrichtigung entschieden. Sicherheitsrelevante Informationen erhalten eine hohe Priorität, während informative Ereignisse eine geringere Priorität haben. Zudem wird der Kanal festgelegt, auf dem eine Information erscheinen soll. Dieser Kanal kann entweder Sprache, Push oder beides sein. Das letzte Wort bei der Zustellung hat jedoch immer das Skript. Aufgrund übergeordneter Zustände kann es Benachrichtigungen unterdrücken, wenn diese in diesem Moment nicht von Bedeutung sind.
Der Aufbau des Skripts kann dabei sogar noch wesentlich gestärkt werden. Indem die Automation in einem weiteren Ausbauschritt nur noch über die Relevanz entscheidet, kann das Skript eigenständig den Kanal festlegen und so würde ein Teil der Parameter bei der Übergabe entfallen. Das würde für eine noch stärkere Abstraktion sorgen, ist aktuell in meinem Szenario aber noch nicht umgesetzt.
Heruntergebrochen sieht die gedankliche Kette also wie folgt aus:
Relevanz -> Dringlichkeit -> Kontext -> Kanal -> Ziel
So entscheidet das Skript zwischen Push und Sprache
Für die korrekte Zustellung nach meinen Vorstellungen nutzt das Skript weitere Informationen, die Home Assistant zur Verfügung stellt. Da diese Informationen für die Zustellung entscheidend sind, möchte ich sie mit dir nachfolgend einmal detailliert durchgehen. Das schärft dein Verständnis für die Automation, die ich dir gleich als vollständiges YAML zur Verfügung stelle.
Hierzu müssen wir auf zwei wesentliche Informationen blicken.
Anwesenheit entscheidet über den Kanal
Über welchen Kanal eine Benachrichtigung ausgegeben wird, hängt maßgeblich vom Aufenthaltsort der Person ab. Hierzu unterscheidet Home Assistant, ob die Person sich gerade daheim aufhält oder außerhalb des Zuhauses. Die Standortinformationen werden durch die Companion App ermittelt und in Form einer einfachen Entität weiterverwendet. Das gehört zum Standardumfang von Home Assistant, wenn man die zugehörige App verwendet.
Befinde ich mich außerhalb von meinem Zuhause, entscheidet das Skript sich für eine Push-Benachrichtigung. Bin ich hingegen daheim, erfolgt eine Sprachausgabe und keine Push-Benachrichtigung. Das hat den Hintergrund, dass ich nicht auf mehreren Kanälen gleichzeitig benachrichtigt werde, aber in jedem Fall nur die gleiche Information bekomme. Habe ich die Meldung gehört, dass die Waschmaschine fertig ist, brauche ich diese Information nicht auch noch auf meinem Smartphone zu sehen.
Gleichzeitig unterscheidet das Skript bei den Personen. Eine Person kann die Ansage über den Amazon Echo hören, während die andere Person zur gleichen Zeit eine Benachrichtigung als Push bekommt, da sie nicht daheim ist. So bleibt man auf dem gleichen Informationsstand, ist aber an den jeweiligen Kanal gebunden, der in diesem Augenblick am zuverlässigsten bei der Person ankommt.
Konkret führt das in meinem Fall dazu, dass ich deutlich weniger Push-Benachrichtigungen erhalte und relevante Informationen über den passenden Kanal bekomme.
Raumpräsenz entscheidet über den Lautsprecher
Die zweite Entscheidung betrifft die Sprachausgabe einer Benachrichtigung, die ich nach der ursprünglichen ersten Version in das Skript eingefügt habe. Hierbei geht es darum, dass ich meine Präsenzmelder dafür nutze, die Belegung eines Raums als weiteres Merkmal hinzuzufügen.
Konkret führt das dazu, dass die Home-Assistant-Sprachausgabe nur noch dort erfolgt, wo sich eine Person im Raum aufhält. Ist der Raum hingegen gerade unbelegt, bleibt der dortige Echo still und es ist keine Benachrichtigung zu hören. Sind mehrere Räume belegt, erfolgt die Sprachausgabe in jedem belegten Raum.
Die Basis für diese Unterscheidung bilden meine Aqara FP2 sowie die SONOFF-Präsenzmelder. Sie übermitteln den Status des Raums (belegt/unbelegt) an Home Assistant, wodurch ich diese Information in mein Skript einfließen lassen kann. Verfügt ein Raum nicht über einen Präsenzmelder, bleibt er entweder still oder kündigt jede Benachrichtigung an, die vom Skript verarbeitet wird.
Interessant ist dabei, dass ich keine genaue Ortung in meiner Wohnung brauche. Stattdessen genügt mir die Information, ob sich in einem Raum eine Person aufhält oder nicht. Eine Verzögerung, wie ich sie dabei schon öfter beobachtet habe, ist in der Praxis kein Problem. Wird ein Raum nach dem Verlassen noch kurz als belegt erkannt, kann dort weiterhin eine Ansage erfolgen. Viel wichtiger ist dabei jedoch, dass ich sie so nicht verpasse. Deutlich problematischer wäre es, wenn keiner der Räume eine Belegung anzeigt und ich deshalb über wichtige Informationen keine Benachrichtigung bekomme. Das kam jedoch in der Praxis bislang noch nicht vor.
Einzige Ausnahme ist das Schlafzimmer. Da ich dort noch keine Anwesenheit per Präsenzmelder umgesetzt habe, spricht der Lautsprecher dort unabhängig von der Präsenz. Das ist eine bewusste Ausnahme, die ich aufgrund fehlender Hardware getroffen habe.
Nachtmodus, Priorität und „immer Push“
Neben dem reinen Kanal spielt auch die Priorität einer Benachrichtigung eine wichtige Rolle. Sie entscheidet darüber, ob sie bei Bedarf unterdrückt wird oder welche Einschränkungen für die Sprachausgabe gelten.
Mein Smart Home verfügt über einen Nachtmodus, der am Abend manuell per Sprache ausgelöst wird, indem man die Einschlafroutine startet. Ab diesem Moment werden Benachrichtigungen mit normaler Priorität von der Sprachausgabe unterdrückt, sodass ein ruhiger Schlaf möglich ist. Lediglich Benachrichtigungen mit hoher Priorität werden weiterhin ausgegeben. Die Ausgabe erfolgt bei hoher Priorität außerdem auf allen Geräten, ungeachtet der aktuellen Präsenz. So erhöhe ich die Wahrscheinlichkeit, eine dringende Meldung tatsächlich zu hören.
So erhalte ich zum Beispiel in der Nacht keine Meldung darüber, wenn die Post angekommen ist (z. B. weil die Klappe versehentlich in Bewegung gerät oder sich jemand einen Streich erlaubt). Meldungen für Wasserleck-Sensoren hingegen werden weiterhin ausgegeben, da sie für das Zuhause sicherheitsrelevant sind. Der Nachtmodus ist demnach ein zusätzlicher Filter, der für eine angenehme Nachtruhe sorgt, während das Smart Home am Tag durchaus gesprächiger sein kann. Ich erspare mir so lästige zeitbasierte Steuerungen in jeder einzelnen Automation.
Hinzu kommt noch die Möglichkeit, Benachrichtigungen immer per Push zu senden. Das ist besonders dann hilfreich, wenn ich Informationen in einem zeitlichen Rückblick noch nachvollziehen möchte. Hauptsächlich nutze ich das für die Änderung des Status der Alarmanlage, um nicht versehentlich doch mal in die Falle zu tappen und sie auszulösen. Dabei ist aber auch klar, dass diese Funktion eher sparsam eingesetzt werden muss, da ich sonst mein Problem der zu vielen Meldungen einfach nur an eine andere Stelle delegiere, aber nicht löse.
Zusammenfassend löst das Skript damit nicht nur die Frage nach dem Kanal, sondern auch die Frage nach der Dringlichkeit in Form der Priorität. Es bietet auch eine Ausnahme, um Benachrichtigungen vorbei an der Präsenzfrage immer auf das Smartphone zuzustellen.
Das vollständige Skript
Nachfolgend findest du mein vollständiges Skript, das ich für die Benachrichtigungssteuerung nutze. Aus nachvollziehbaren Gründen habe ich Teile des Skripts anonymisiert und persönliche Informationen ersetzt. Historisch gewachsene Bestandteile sind weiterhin enthalten, auf die ich in den nachfolgenden Absätzen zu sprechen komme. Für die Integration musst du ein paar Elemente im Skript auf deine Bedürfnisse anpassen.
alias: Benachrichtigung
description: ''
mode: queued
fields:
benachrichtigungstext:
selector:
text: null
name: Benachrichtigungstext
description: Inhalt der Benachrichtigung
required: true
an_sprachassistenten_senden:
selector:
boolean: {}
name: An Sprachassistenten senden
required: true
default: true
immer_per_pushnachricht_senden:
selector:
boolean: {}
name: Immer per Pushnachricht senden
required: true
an_lametric_senden:
selector:
boolean: {}
name: An Lametric senden
default: true
required: true
bild_entity:
selector:
text: null
name: bild_entity
required: false
description: Bild-Entität, z. B. image.eingang_person
prioritaet:
selector:
select:
options:
- normal
- hoch
mode: dropdown
name: Priorität
description: Relevanz für Sprachassistent im Nachtmodus
required: false
default: normal
sequence:
- if:
- condition: or
conditions:
- condition: zone
entity_id: person.lukas
zone: zone.home
- condition: zone
entity_id: person.bewohner_2
zone: zone.home
- condition: template
value_template: '{{ an_sprachassistenten_senden }}'
- condition: or
conditions:
- condition: state
entity_id: input_boolean.nachtmodus
state: 'off'
- condition: template
value_template: '{{ prioritaet | default(''normal'') == ''hoch'' }}'
- condition: or
conditions:
- condition: or
conditions:
- condition: time
after: '06:00:00'
before: '22:00:00'
weekday:
- fri
- thu
- wed
- tue
- mon
- condition: time
after: '09:00:00'
before: '22:00:00'
weekday:
- sat
- sun
- condition: template
value_template: '{{ prioritaet | default(''normal'') == ''hoch'' }}'
then:
- variables:
room_routes:
- occupancy: binary_sensor.arbeitszimmer_belegung
speaker: media_player.studio_arbeitszimmer
platform: alexa
- occupancy: binary_sensor.essbereich_belegung
speaker: media_player.essbereich
platform: alexa
- occupancy: binary_sensor.badezimmer_belegung
speaker: media_player.badezimmer
platform: alexa
- occupancy: binary_sensor.wohnzimmer_belegung
speaker: media_player.wohnzimmer
platform: alexa
- occupancy: binary_sensor.gaeste_wc_belegung
speaker: media_player.buro
platform: google
alexa_targets: >-
{% set urgent = prioritaet | default('normal') == 'hoch' %}{% set ns
= namespace(out=[]) %}{% for r in room_routes %}{% if r.platform ==
'alexa' and (urgent or is_state(r.occupancy, 'on')) %}{% set ns.out
= ns.out + [r.speaker] %}{% endif %}{% endfor %}{{ ns.out | unique |
list }}
google_targets: >-
{% set urgent = prioritaet | default('normal') == 'hoch' %}{% set ns
= namespace(out=[]) %}{% for r in room_routes %}{% if r.platform ==
'google' and (urgent or is_state(r.occupancy, 'on')) %}{% set ns.out
= ns.out + [r.speaker] %}{% endif %}{% endfor %}{{ ns.out | unique |
list }}
- choose:
- conditions:
- condition: template
value_template: '{{ alexa_targets | count > 0 }}'
sequence:
- repeat:
for_each: '{{ alexa_targets }}'
sequence:
- action: notify.alexa_media
data:
message: '{{ benachrichtigungstext }}'
data:
type: announce
target: '{{ repeat.item }}'
- choose:
- conditions:
- condition: template
value_template: '{{ google_targets | count > 0 }}'
sequence:
- repeat:
for_each: '{{ google_targets }}'
sequence:
- action: tts.cloud_say
data:
entity_id: '{{ repeat.item }}'
message: '{{ benachrichtigungstext }}'
cache: false
- action: media_player.play_media
data:
announce: true
media:
media_content_id: media-source://tts/cloud?message="{{ benachrichtigungstext }}"
media_content_type: music
metadata: {}
target:
device_id: DEVICE_ID_LAUTSPRECHER
- if:
- condition: and
conditions:
- condition: or
conditions:
- condition: not
conditions:
- condition: zone
entity_id: person.lukas
zone: zone.home
- condition: template
value_template: '{{ immer_per_pushnachricht_senden }}'
- condition: template
value_template: >-
{% set bild = bild_entity | default('') | trim %}{% set picture =
state_attr(bild, 'entity_picture') | default('') | trim %}{{ bild
| length == 0 or picture | length == 0 }}
then:
- action: notify.mobile_app_lukas_iphone
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
enabled: false
- action: notify.mobile_app_lukas_iphone_17
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
- if:
- condition: and
conditions:
- condition: or
conditions:
- condition: not
conditions:
- condition: zone
entity_id: person.lukas
zone: zone.home
- condition: template
value_template: '{{ immer_per_pushnachricht_senden }}'
- condition: template
value_template: >-
{% set bild = bild_entity | default('') | trim %}{% set picture =
state_attr(bild, 'entity_picture') | default('') | trim %}{{ bild
| length > 0 and picture | length > 0 }}
then:
- action: notify.mobile_app_lukas_iphone
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
data:
image: >
{% set bild = bild_entity | default('') | trim %}{% set image_path
= state_attr(bild, 'entity_picture') %}
http://HOME_ASSISTANT_ADRESSE{{ image_path }}
enabled: false
- action: notify.mobile_app_lukas_iphone_17
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
data:
image: >
{% set bild = bild_entity | default('') | trim %}{% set image_path
= state_attr(bild, 'entity_picture') %}
http://HOME_ASSISTANT_ADRESSE{{ image_path }}
- if:
- condition: and
conditions:
- condition: or
conditions:
- condition: not
conditions:
- condition: zone
entity_id: person.bewohner_2
zone: zone.home
- condition: template
value_template: '{{ immer_per_pushnachricht_senden }}'
- condition: template
value_template: >-
{% set bild = bild_entity | default('') | trim %}{% set picture =
state_attr(bild, 'entity_picture') | default('') | trim %}{{ bild
| length == 0 or picture | length == 0 }}
then:
- action: notify.mobile_app_bewohner_2_alt
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
enabled: false
- action: notify.mobile_app_bewohner_2
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
- if:
- condition: and
conditions:
- condition: or
conditions:
- condition: not
conditions:
- condition: zone
entity_id: person.bewohner_2
zone: zone.home
- condition: template
value_template: '{{ immer_per_pushnachricht_senden }}'
- condition: template
value_template: >-
{% set bild = bild_entity | default('') | trim %}{% set picture =
state_attr(bild, 'entity_picture') | default('') | trim %}{{ bild
| length > 0 and picture | length > 0 }}
then:
- action: notify.mobile_app_bewohner_2_alt
metadata: {}
data:
title: Smart Home
message: '{{ benachrichtigungstext }}'
image: >
{% set bild = bild_entity | default('') | trim %}{% set image_path =
state_attr(bild, 'entity_picture') %}
http://HOME_ASSISTANT_ADRESSE{{ image_path }}
enabled: false
- action: notify.mobile_app_bewohner_2
metadata: {}
data:
data:
image: >
{% set bild = bild_entity | default('') | trim %}{% set image_path
= state_attr(bild, 'entity_picture') %}
http://HOME_ASSISTANT_ADRESSE{{ image_path }}
message: '{{ benachrichtigungstext }}'
title: Smart Home
max: 10Reales Beispiel: Meldung des Wasserleck-Sensors
Nun schauen wir uns den realen Aufruf des Skripts anhand des Wasserleck-Sensors an. Die Automation ist bewusst simpel aufgebaut und lagert die besagte Logik zur Benachrichtigung vollständig an das Skript aus:
alias: Wasserleck Waschmaschine
description: >-
Warnt sofort per Sprachansage und Pushnachricht, wenn der Wasserlecksensor an
der Waschmaschine Nässe erkennt.
triggers:
- trigger: state
entity_id: binary_sensor.waschmaschine_wasserleck
to: 'on'
conditions: []
actions:
- action: script.benachrichtigung
data:
benachrichtigungstext: >-
Achtung! Der Wasserlecksensor an der Waschmaschine hat Nässe erkannt.
Bitte sofort prüfen.
an_sprachassistenten_senden: true
immer_per_pushnachricht_senden: true
an_lametric_senden: false
prioritaet: hoch
mode: singleIm Benachrichtigungstext wird festgelegt, welche Information gesendet werden soll. Der Text wird anschließend entweder über einen Echo ausgegeben oder als Push-Benachrichtigung zugestellt.
Über den Parameter an_sprachassistenten_senden legt die Automation fest, ob eine Benachrichtigung per Sprache ausgegeben werden soll. Zusätzlich findest du im Beispiel noch den Parameter an_lametric_senden. Er stammt aus einer früheren Version meines Skripts, in der ich Benachrichtigungen auch auf meiner LaMetric angezeigt habe. Inzwischen hat dieser Parameter keine Funktion mehr und ist lediglich als technische Altlast erhalten geblieben.
Zudem siehst du den Parameter immer_per_pushnachricht_senden. Er legt fest, ob ich auch bei Anwesenheit in meinem Zuhause eine Push-Benachrichtigung erhalte. Ist das nicht aktiviert, erfolgt nur die Sprachausgabe. Schalte ich die Sprachausgabe auch noch ab, erhalte ich keinerlei Information mehr, wenn ich gerade daheim bin.
Über die Priorität lege ich fest, ob diese Benachrichtigung den Nachtmodus im Skript übersteuern darf. Bei hoher Priorität wird die Sprachausgabe auch bei aktivem Nachtmodus zugelassen. Bei normaler Priorität hingegen wird er weiter beachtet und es erfolgt keine Ausgabe über die Lautsprecher. Push ist hiervon nicht berührt.
Du siehst, dass die Automation weder die Smartphones noch die Lautsprecher kennen muss, auf die eine Ausgabe erfolgt. Die konkreten Zielgeräte sind von der Automation entkoppelt. Aus diesem Grund muss ich bei einem Smartphone-Wechsel nicht jede Automation ändern und kann nachträglich auch weitere oder andere Sprachausgabe-Möglichkeiten in Betrieb nehmen.
Mein produktives Skript ist nicht perfekt
Klar ist nach der genauen Betrachtung des Skripts, dass es Baustellen gibt, die angegangen werden müssen. Das Skript verfügt heute noch über die LaMetric-Integration, welche jedoch keinerlei Funktion mehr erfüllt und lediglich aus historischen Gründen noch in Teilen enthalten ist. Das zeigt, dass mein Skript über die Monate gewachsen ist und dabei technische Altlasten entstanden sind, die ich noch bereinigen möchte.
Genauso sehen wir noch feste Zeitfenster, anhand derer ursprünglich die Sprachausgabe gesteuert wurde. Sie existieren ebenfalls nur noch aus historischen Gründen und es ist überfällig, sie zu entfernen. Der Nachtmodus ist durch das manuelle Auslösen wesentlich präziser und flexibler für diesen Fall. Da er jedoch erst nach dem Skript hinzugekommen ist, kann es genau zu solchen Altlasten kommen, die in einem solch lebendigen System immer wieder auftreten.
Aber selbst wenn diese Herausforderungen alle gelöst wären, gäbe es noch die fehlenden Präsenzmelder in manchen Räumen. Hier kann das Skript nicht seine vollständige Stärke ausspielen, was eindeutig auf fehlende Hardware zurückzuführen ist. Diesen Umstand zu beseitigen ist ebenfalls ein Punkt, der auf meiner ToDo-Liste steht. Hier sieht man auch ganz klar, dass die Hardware dem Design des Smart Homes folgt. Ich integriere nicht schöne Technik und suche mir dann den Anwendungsfall, sondern habe den Anwendungsfall und suche dann die passende Hardware.
Für diesen Artikel wollte ich aber mein Skript nicht künstlich auf Hochglanz polieren. Denn auch wenn perfekte Skripte und Automationen immer schick aussehen, entsprechen sie selten der Lebensrealität.
Mein Fazit nach mehreren Monaten
Mehrere Monate und 28 angebundene Automationen später zeigt sich in meinem Smart Home, dass die Vorteile des Skripts seine Schwächen deutlich überwiegen. Die Entkopplung der konkreten Zustellung für Benachrichtigungen hilft, die verstreute Zustellungslogik zuverlässig zu verwalten.
Gleichzeitig sorgt das Skript für ein einheitliches Muster, nach dem ich die Benachrichtigungen kategorisiere und strukturiere. Der wohl größte Gewinn ist neben der Zustellung per Sprache oder Push ganz klar die Priorität. Sie hilft auch schon beim Erstellen einer Automation dabei, sich aktiv Gedanken um die Wichtigkeit zu machen. Ein Faktor, den man sonst möglicherweise zu stark unterschätzt.
Als ich schließlich mein Smartphone gewechselt habe, war die Anpassung in Home Assistant innerhalb kürzester Zeit erledigt. Denn anstatt mehrere Automationen anzufassen, genügte die Änderung im Skript. Die konnte ich darüber hinaus auch noch von der KI erledigen lassen, so dass ich im Grunde mehr Zeit für das Einrichten meines Smartphones als für den Austausch der Entitäten in Home Assistant gebraucht habe.
Für mich ist damit klar, dass ich diesen Aufbau jederzeit wieder bevorzugen würde. Schon allein deshalb, weil ich dieselbe Zustelllogik nicht in sämtlichen Automationen vorhalten möchte. Interessant wäre aber auch, ob es seitens der Entwickler nicht auch eine Möglichkeit gäbe, sowas grundsätzlich in das System einzubauen. Mit einem Benachrichtigungsmanager würde Home Assistant Flexibilität gewinnen und gleichzeitig den Kern der Automationen stärken. Denn hier geht es nicht um die Benachrichtigung als primäres Ziel, sondern um die Automation eines konkreten Anwendungsfalls.
Für mich bleibt deshalb die wichtigste Erkenntnis: Eine Automation sollte wissen, welches Ereignis eine Benachrichtigung auslöst. Aber nicht, auf welchem Gerät sie am Ende ausgegeben wird.
0 Kommentare