Eine einfache Automation ist selten so einfach, wie sie am Anfang klingt. Genau das merkt man meistens erst dann, wenn sie im Alltag nicht nur einmal funktioniert, sondern jeden Tag. Morgens. Abends. Mit vollen Händen. Mit Hund. Im Halbschlaf. Und natürlich genau dann, wenn man eigentlich nur kurz das Haus verlassen will.
Ein gutes Beispiel dafür ist mein Flurlicht.
Die Grundidee war banal: Wenn es draußen dunkel ist und ich vorne oder hinten die Haustür öffne, soll im Flur automatisch das Licht angehen. Klingt logisch, praktisch und nach einer Automation, die man in fünf Minuten baut und dann nie wieder anfassen muss.
Natürlich war es nicht so.
Denn eine einfache Automation ist eben nicht automatisch eine gute Automation. Sie kann technisch völlig korrekt reagieren und im Alltag trotzdem nerven. Genau da beginnt der Unterschied zwischen „irgendwas schaltet automatisch“ und „mein Smart Home hilft mir wirklich“.
Schnellnavigation
- Das Problem mit der Fernbedienung
- Die erste Version: Tür auf, Licht an
- Warum nicht einfach ein Bewegungsmelder?
- Dann kommt der Alltag und macht alles kaputt
- Die erste Lösung: Kontext statt Reflex
- Der nächste Haken: Die Reihenfolge ist nicht egal
- Ereignis oder Zustand
- Die bessere Logik: nicht nur auslösen, sondern bewerten
- Warum gerade 30 Sekunden?
- Die eigentliche Intelligenz steckt nicht im Sensor
- Gute Automationen funktionieren unbewusst
- Schlechte Automationen erkennt man an Ausreden
- Manuell schlägt automatisch
- So könnte die Automation technisch aussehen
- Warum das besser ist als eine reine Dashboard-Lösung
- Die wichtigste Frage vor jeder Automation
- Kleine Regeln, großer Unterschied
- Fazit
Das Problem mit der Fernbedienung hatten wir schon
In meinem Beitrag über „wirklich smart statt Fernbedienung“ ging es bereits darum, dass ein Dashboard noch kein echtes Smart Home ist. Wenn ich statt auf einen Lichtschalter an der Wand nur auf einen Button auf dem Tablet tippe, habe ich das Problem nicht gelöst. Ich habe den Schalter nur umgezogen.
Das ist manchmal praktisch, aber nicht automatisch smart.
Der nächste Denkfehler lauert direkt dahinter: Nur weil etwas automatisch passiert, ist es noch lange nicht sinnvoll automatisiert. Eine Automation kann genauso stumpf sein wie ein Dashboard-Button. Sie drückt den Schalter dann nur selbst.
Genau deshalb ist das Flurlicht-Beispiel so schön. Es zeigt, dass eine einfache Automation erst dann wirklich gut wird, wenn sie den Kontext versteht.
Oder wenigstens so tut, als würde sie ihn verstehen.
Die erste Version: Tür auf, Licht an
Die naive Version der Automation wäre schnell erklärt:
Wenn Haustür vorne geöffnet wird
ODER Haustür hinten geöffnet wird
UND es draußen dunkel ist
DANN Flurlicht einschalten
Das ist die typische erste Version. Ein Sensor meldet ein Ereignis, eine Bedingung prüft die Dunkelheit, ein Aktor schaltet das Licht ein.
Solche Automationen lassen sich mit vielen Systemen umsetzen. In ioBroker geht das zum Beispiel über Datenpunkte, Skripte oder Blockly. In Home Assistant besteht eine Automation klassisch aus Trigger, Bedingungen und Aktionen. Und mit Geräten von Shelly lassen sich viele Dinge auch lokal und ohne Cloud-Zwang umsetzen.
Für die Hardware braucht man im Prinzip nicht viel: Türkontakte, eine Möglichkeit zur Helligkeitserkennung und ein schaltbares Licht. Wer dafür passende Sensoren sucht, findet zum Beispiel Smart-Home-Türkontakte bei Amazon (bezahlter Link) oder direkt spezialisierte Geräte wie Shelly Door/Window Sensoren*.
Bis hierhin klingt alles sauber. Und für den Fall „ich komme nach Hause und es ist dunkel“ funktioniert es auch wunderbar.
Tür auf. Licht an. Kein Gefummel am Schalter. Kein Stolpern im dunklen Flur. Genau so soll Smart Home sein.
Warum nicht einfach ein Bewegungsmelder?
An dieser Stelle könnte man natürlich fragen: Warum so kompliziert? Warum nicht einfach einen Bewegungsmelder (bezahlter Link) oder Präsenzmelder (bezahlter Link) in den Flur hängen?
Die Antwort ist simpel: Weil ein Bewegungsmelder nicht weiß, wer oder was sich bewegt.
Ich habe Hunde. Und Hunde sind aus Sicht vieler Sensoren einfach kleine, warme, sich bewegende Automations-Auslöser mit Fell. Wenn nachts ein Hund durch den Flur läuft, soll deshalb nicht jedes Mal das Licht angehen. Das wäre weder smart noch angenehm. Es wäre nur eine sehr teure Art, dem Hund eine eigene Lichtshow zu bauen.
Dazu kommt die Nachlaufzeit. Bewegungsmelder und Präsenzmelder arbeiten meist nicht nur mit „Bewegung erkannt → Licht an“, sondern halten das Licht noch eine gewisse Zeit eingeschaltet. Im Flur will ich das aber gerade nicht. Wenn ich nur kurz durchgehe oder die Tür öffne, soll das Licht passend reagieren, aber nicht unnötig lange nachleuchten.
In meinem Haus kommt noch ein weiterer Punkt dazu: Die Zimmertüren haben Glas. Wenn das Flurlicht unnötig lange anbleibt, stört es durch diese Glastüren in angrenzenden Räumen. Gerade abends oder nachts ist das ziemlich nervig. Dann ist das Licht im Flur zwar technisch korrekt eingeschaltet, aber im Alltag falsch.
Außerdem ist mein Flur ziemlich lang. Ein einzelner Bewegungsmelder würde ihn nicht sinnvoll abdecken. Man bräuchte also mehrere Sensoren, müsste deren Erfassungsbereiche sauber planen und hätte am Ende wieder mehrere Auslöser, die zusammen eine eigentlich einfache Lichtsteuerung übernehmen sollen.
Damit wäre die Bewegungsmelder-Lösung nicht nur unpassender, sondern auch unwirtschaftlich und erneut komplex. Mehr Sensoren bedeuten mehr Kosten, mehr Batterien oder Verkabelung, mehr Funkgeräte im System, mehr mögliche Fehltrigger und mehr Dinge, die irgendwann nicht mehr sauber funktionieren. Aus einer vermeintlich simplen Lösung würde also wieder genau das entstehen, was ich eigentlich vermeiden wollte: eine einfache Automation, die plötzlich gar nicht mehr einfach ist.
Ein Türkontakt ist hier also nicht die billige Alternative zum Bewegungsmelder, sondern der passendere Auslöser. Er erkennt nicht „irgendwas bewegt sich“, sondern ein konkretes Ereignis: Eine Haustür wurde geöffnet. Genau dieses Ereignis ist für meine Flurlicht-Automation relevant.
Und noch etwas kann ein Bewegungsmelder nicht sauber unterscheiden: welche Tür geöffnet wurde.
Bei mir macht es einen Unterschied, ob die Haustür oder die Hintertür geöffnet wird. Beide Türen können unterschiedliche Situationen bedeuten und deshalb auch unterschiedliche Lichtszenen auslösen.
Mit zwei Türkontakten lässt sich das sauber abbilden:
Vordere Haustür geöffnet → Flurlicht-Szene Eingang
Hintere Haustür geöffnet → Flurlicht-Szene Hinterausgang
Ein Bewegungsmelder sieht dagegen nur: Da bewegt sich etwas im Flur. Ob das vorne, hinten, Mensch, Hund oder der nächtliche Gang zum Kühlschrank ist, bleibt ihm herzlich egal.
Mit Triggern ist es ein bisschen wie mit O.B.s*: Sie sollen das Ereignis genau dort erfassen, wo es passiert. Nicht drei Meter weiter, nicht ungefähr im selben Raum und schon gar nicht erst, wenn der halbe Flur zur Sensor-Teststrecke geworden ist.
Dann kommt der Alltag und macht alles kaputt
Das Problem zeigte sich beim Verlassen des Hauses.
Der Ablauf war ungefähr so:
- Ich stehe im Flur.
- Ich mache das Licht aus.
- Ich öffne die Haustür.
- Die Automation sieht: Tür offen, draußen dunkel.
- Das Licht geht wieder an.
- Ich denke Dinge, die Alexa (bezahlter Link) zensieren würde.
Technisch hatte die Automation nichts falsch gemacht. Die Tür wurde geöffnet. Es war dunkel. Also ging das Licht an.
Nur war das in dieser Situation eben Unsinn.
Ich hatte das Licht gerade bewusst ausgeschaltet. Das Smart Home hat diesen manuellen Eingriff aber nicht als Information verstanden. Für die Automation war der Zustand „Licht aus“ nur ein Zustand. Für mich war er eine Entscheidung.
Und genau das ist der spannende Punkt: Eine einfache Automation scheitert oft nicht am Sensor, nicht am Schalter und nicht am Smart-Home-System. Sie scheitert daran, dass sie keine Ahnung hat, warum etwas passiert.
Die erste Lösung: Kontext statt Reflex
Die erste Lösung war nicht kompliziert, aber entscheidend: Nach dem Ausschalten des Flurlichts wird für 30 Sekunden eine Sperre aktiviert.
Während dieser Sperrzeit darf die Tür-Automation das Licht nicht wieder einschalten.
Die neue Logik sieht also zunächst so aus:
Wenn Flurlicht ausgeschaltet wird:
Sperre für 30 Sekunden aktivieren
Wenn Haustür vorne oder hinten geöffnet wird:
Prüfen, ob es draußen dunkel ist
Prüfen, ob die Sperre nicht aktiv ist
Nur dann Flurlicht einschalten
Das ist immer noch keine Raketenwissenschaft. Aber es ist der Unterschied zwischen einer stumpfen Reaktion und einer Automation, die den Alltag respektiert.
Denn jetzt gilt:
- Wenn ich nach Hause komme und es dunkel ist, geht das Flurlicht automatisch an.
- Wenn ich das Haus verlasse und das Licht gerade ausgeschaltet habe, bleibt es aus.
- Nach 30 Sekunden funktioniert die Automation wieder ganz normal.
Manchmal ist ein einfacher Timer smarter als jede angebliche KI-Erkennung.
Aber damit ist das Thema noch nicht vollständig gelöst.
Der nächste Haken: Die Reihenfolge ist nicht egal
Die 30-Sekunden-Sperre löst genau ein Problem: Das Licht geht nicht sofort wieder an, wenn ich es ausschalte und danach die Tür öffne.
Aber was passiert in der anderen Reihenfolge?
Also nicht:
Licht aus → Tür auf
Sondern:
Tür auf → Licht an → Licht aus
Das klingt nach einem kleinen Unterschied, ist für eine Automation aber eine komplett andere Situation.
Ein Beispiel:
- Es ist draußen dunkel.
- Ich öffne die Haustür.
- Das Flurlicht geht automatisch an.
- Die Tür bleibt offen.
- Ich schalte das Flurlicht aus.
Was bedeutet das jetzt?
Gehe ich gerade raus? Lüfte ich nur kurz? Stehe ich mit offener Tür im Flur? Kommt gleich jemand rein? Ist das Licht bewusst ausgeschaltet worden, obwohl die Tür noch offen ist?
Die Automation weiß es nicht.
Und genau dadurch entsteht ein unbestimmter Zustand. Die Tür ist offen, draußen ist es dunkel, das Licht ist aus, aber die normale Regel „Tür auf → Licht an“ wurde bereits verarbeitet. Wenn jetzt nur der ursprüngliche Tür-Trigger betrachtet wird, passiert nichts mehr. Die Tür ist ja schon offen. Es gibt kein neues „Tür wurde geöffnet“-Ereignis.
Das ist ein typisches Smart-Home-Problem: Viele Automationen reagieren auf Ereignisse, aber der Alltag besteht aus Zuständen.
Ereignis oder Zustand: Der kleine Unterschied, der nervt
Ein Ereignis ist ein kurzer Moment:
Tür wurde geöffnet
Licht wurde ausgeschaltet
Bewegung wurde erkannt
Ein Zustand ist dagegen etwas, das andauert:
Tür ist offen
Licht ist aus
Es ist dunkel
Sperre ist aktiv
Die erste Version der Automation reagiert nur auf das Ereignis „Tür wurde geöffnet“. Das reicht aber nicht immer. Denn wenn die Tür bereits offen ist und danach das Licht ausgeschaltet wird, muss die Automation trotzdem erkennen können, dass sie sich jetzt in einer besonderen Situation befindet.
Sonst bleibt nur ein undefinierter Zwischenzustand übrig: Tür offen, dunkel, Licht aus, aber keine klare Entscheidung, ob das so gewollt ist oder ob die Automation später wieder eingreifen soll.
Und genau deshalb reicht bei einer scheinbar einfachen Automation oft nicht ein einziger Trigger.
Die bessere Logik: nicht nur auslösen, sondern bewerten
Die Automation muss also nicht nur auf „Tür wurde geöffnet“ reagieren. Sie muss auch bewerten können, was gerade gilt.
Vereinfacht gesagt:
Wenn sich ein relevanter Zustand ändert:
Prüfe die Gesamtsituation
Entscheide dann, ob das Flurlicht eingeschaltet werden darf
Relevante Zustände sind hier zum Beispiel:
- Tür vorne offen oder geschlossen
- Tür hinten offen oder geschlossen
- Flurlicht an oder aus
- draußen dunkel oder hell
- Sperre aktiv oder nicht aktiv
- Licht wurde gerade bewusst ausgeschaltet
Damit wird aus der einfachen Tür-Automation eher eine kleine Zustandsmaschine. Das klingt größer, als es ist. Es bedeutet nur: Die Automation schaut nicht blind auf einen einzelnen Auslöser, sondern auf die aktuelle Gesamtsituation.
Für mein Beispiel heißt das:
Wenn Tür geöffnet wird:
Situation prüfen
Wenn Flurlicht ausgeschaltet wird:
Sperre setzen
Prüfen, ob eine Tür offen ist
Falls ja: bewusst ausgeschalteten offenen-Tür-Zustand merken
Wenn Tür noch offen ist und Licht ausgeschaltet wurde:
Nicht sofort wieder einschalten
Zustand merken
Wichtig ist dabei auch: Diese Logik entsteht gerade deshalb, weil kein allgemeiner Bewegungsmelder die Hauptentscheidung treffen soll. Die Automation soll nicht auf jede Bewegung im Flur reagieren, sondern auf das relevante Ereignis an der jeweiligen Haustür. Dadurch kann sie auch unterscheiden, ob vorne oder hinten geöffnet wurde und welche Lichtszene dazu passt.
Damit wird auch die zweite Reihenfolge sauber behandelt. Das System weiß dann: Die Tür ist zwar offen und es ist dunkel, aber das Licht wurde in dieser offenen-Tür-Situation bewusst ausgeschaltet. Also bitte nicht direkt wieder einschalten.
Das ist kein Luxus. Das ist der Moment, an dem eine Automation aufhört, mit dem Menschen zu streiten.
Warum gerade 30 Sekunden?
Die 30 Sekunden sind kein Naturgesetz. Sie sind ein praktischer Kompromiss.
Die Zeit ist lang genug, um nach dem Ausschalten des Lichts die Tür zu öffnen und das Haus zu verlassen. Gleichzeitig ist sie kurz genug, damit die Automation danach wieder normal arbeitet. Wenn ich also später wieder reinkomme, ist die Sperre längst abgelaufen und das Licht geht wie gewünscht an.
Man könnte auch 20 Sekunden nehmen. Oder 45. Oder eine komplexere Logik mit Anwesenheitserkennung, Türstatus, Bewegungsmelder und Sonnenstand bauen.
Wichtig ist aber: Die Sperrzeit allein ist nicht die ganze Lösung. Sie behandelt nur einen zeitlichen Sonderfall. Für den unbestimmten Zustand „Tür ist bereits offen und Licht wird danach ausgeschaltet“ braucht es zusätzlich eine saubere Zustandsbewertung.
Das klingt erstmal nach Overengineering, ist aber genau das Gegenteil. Es verhindert, dass man später immer neue Flickschichten über eine zu einfache Regel legt.
Eine einfache Automation sollte nicht unnötig zu einem privaten Forschungsprojekt werden. Die beste Lösung ist nicht immer die mit den meisten Bedingungen. Die beste Lösung ist die, die zuverlässig funktioniert und die man auch nach drei Monaten noch versteht.
Die eigentliche Intelligenz steckt nicht im Sensor
Viele Smart-Home-Geräte werden mit Begriffen wie „smart“, „intelligent“ oder „automatisch“ beworben. Aber in der Praxis ist der Sensor selten der wirklich smarte Teil.
Ein Türkontakt meldet nur offen oder geschlossen. Ein Helligkeitssensor meldet einen Wert. Ein Relais (bezahlter Link) schaltet ein oder aus. Das ist alles nützlich, aber nicht besonders intelligent.
Smart wird es erst durch die Regel dazwischen.
Beim Flurlicht ist nicht der Türkontakt smart. Auch nicht das Licht. Smart ist die Entscheidung, wann das Licht eben nicht angehen soll. Und noch smarter ist die Erkenntnis, dass nicht nur ein einzelnes Ereignis zählt, sondern die Reihenfolge mehrerer Ereignisse.
Das ist ein wichtiger Gedanke für fast jede Smart-Home-Automation:
Nicht die Aktion macht eine Automation smart, sondern die Ausnahme.
„Tür auf, Licht an“ ist einfach. „Tür auf, Licht an, aber nicht direkt nach einem bewussten Ausschalten und auch nicht, wenn die Tür schon offen war, bevor das Licht ausgeschaltet wurde“ ist alltagstauglich.
Gute Automationen funktionieren unbewusst
Eine gute Automation merkt man oft daran, dass man sie kaum bemerkt.
Sie löst kein Feuerwerk aus, braucht kein Dashboard (bezahlter Link) mit 42 Buttons und verlangt keine App. Sie benötigt keinen Account und keine täglichen Streicheleinheiten, sie macht einfach das Richtige im Hintergrund.
Und genau deshalb denkt man im besten Fall nicht einmal: „Cool, was da gerade passiert ist.“
Man nimmt es einfach als logisch hin.
Wenn man im Dunkeln eine Haustür öffnet und im Flur geht das Licht an, ist das keine spektakuläre Science-Fiction-Szene. Es ist die erwartbare Reaktion auf eine Situation. Dunkel. Tür auf. Mensch kommt rein. Licht an.
Kaum jemand wundert sich darüber, weil es sich richtig anfühlt. Genau das ist der Punkt.
Eine gute Automation sollte nicht ständig Aufmerksamkeit auf sich ziehen. Sie sollte sich so verhalten, dass man sie erst dann bemerkt, wenn sie fehlt. Wie ein Lichtschalter, der immer an der richtigen Stelle sitzt. Oder wie eine Außenlampe, die genau dann angeht, wenn man sie braucht.
Schlechte Automationen erkennt man an Ausreden
Eine einfache Automation wird meistens dann problematisch, wenn man anfängt, ihr Verhalten zu erklären wie einen etwas launischen Mitbewohner.
Und ja, ich sage das nicht aus der Theorie. Ich kenne das, weil es mir selbst schon passiert ist.
Dann steht man da und erklärt sich innerlich sein eigenes Smart Home:
„Normalerweise geht das Licht aus, aber wenn vorher die Tür offen war und der Bewegungsmelder noch aktiv ist, dann wartet er manchmal, außer die Szene vom Wohnzimmer hat noch den alten Zustand.“
Spätestens wenn man so anfängt, sollte man kurz innehalten.
Denn dann ist die Automation nicht mehr logisch. Sie funktioniert vielleicht noch irgendwie, aber man versteht sie nicht mehr auf einen Blick. Und genau das ist gefährlich. Nicht gefährlich im Sinne von „das Haus explodiert“, sondern eher im Sinne von: Man baut sich ein System, das man selbst nur noch mit Bauchgefühl bedient.
Typische Warnzeichen sind:
– Man weiß nicht mehr, warum ein Licht gerade angegangen ist.
– Mehrere Automationen steuern denselben Aktor ohne klare Priorität.
– Manuelle Bedienung wird sofort wieder von einer Automation überschrieben.
– Gäste finden keine einfache Möglichkeit, Licht einzuschalten oder auszuschalten.
– Man baut eine neue Automation, um das Fehlverhalten einer alten Automation zu korrigieren.
– Man sagt Sätze wie: „Das macht er manchmal, aber eigentlich ist das richtig so.“
Gerade der letzte Punkt ist tückisch. Man gewöhnt sich erstaunlich schnell an kleine Macken im eigenen Smart Home. Irgendwann nimmt man sie nicht mehr als Fehler wahr, sondern als Charaktereigenschaft des Hauses.
Das ist dann kein Smart Home mehr. Das ist ein digitaler Hausgeist mit schlechter Dokumentation.
Und genau deshalb lohnt es sich, Automationen möglichst nachvollziehbar zu halten. Nicht, weil jede Regel perfekt sein muss. Sondern weil man in drei Monaten noch verstehen möchte, warum das Licht gerade meint, eine eigene Meinung haben zu müssen.
Manuell schlägt automatisch
Eine Regel, die ich bei solchen Automationen immer wichtiger finde: Manuelle Bedienung sollte Vorrang haben.
Wenn ich das Licht ausschalte, dann ist das eine Absicht. Das System sollte diese Absicht nicht sofort übergehen, nur weil irgendein Sensor ein Ereignis meldet.
Das gilt nicht nur für das Flurlicht.
Es gilt auch für Heizungen, Rollläden, Steckdosen, Lüfter, Luftentfeuchter, Außenlicht und eigentlich alles, was im Alltag automatisch gesteuert wird.
Ein Smart Home sollte helfen, aber nicht kämpfen.
Wenn der Mensch eine bewusste Entscheidung trifft, sollte die Automation entweder zurücktreten oder zumindest eine klare Logik haben, warum sie trotzdem eingreift. Genau dafür sind Sperrzeiten, Zustandsvariablen, Hysterese und Prioritäten so wichtig.
Klingt trocken. Ist aber der Unterschied zwischen „praktisch“ und „ich reiße gleich den Sensor von der Wand“.
So könnte die Automation technisch aussehen
Plattformunabhängig besteht die Automation aus drei Ebenen.
1. Sperre setzen
Trigger:
- Flurlicht wird ausgeschaltet
Aktion:
- Sperre aktivieren
- 30 Sekunden warten
- Sperre deaktivieren
2. Licht einschalten
Trigger:
- Haustür vorne wird geöffnet
- Haustür hinten wird geöffnet
Bedingungen:
- Es ist draußen dunkel
- Sperre ist nicht aktiv
- kein bewusst ausgeschalteter offener-Tür-Zustand aktiv
Aktion:
- Flurlicht einschalten
3. Den unbestimmten Zustand erkennen
Trigger:
- Flurlicht wird ausgeschaltet
Prüfung:
- Ist eine Haustür bereits offen?
- Ist es draußen dunkel?
Wenn ja:
- Merken: Licht wurde bei offener Tür bewusst ausgeschaltet
- Automation darf das Licht nicht sofort wieder einschalten
Dieser Zustand muss irgendwann wieder aufgelöst werden. Zum Beispiel wenn beide Türen geschlossen sind, wenn die Sperrzeit abgelaufen ist oder wenn das Licht später bewusst wieder eingeschaltet wird.
Eine mögliche Logik wäre:
Wenn beide Haustüren geschlossen sind:
offener-Tür-Sonderzustand zurücksetzen
Wenn Flurlicht manuell eingeschaltet wird:
offener-Tür-Sonderzustand zurücksetzen
Wenn Sperrzeit abgelaufen ist und keine Tür mehr offen ist:
Normalzustand wiederherstellen
In ioBroker könnte diese Sperre zum Beispiel ein eigener Datenpunkt unter 0_userdata.0 sein. Zusätzlich könnte es einen zweiten Datenpunkt für den Sonderzustand geben, etwa flurlicht_tuer_offen_bewusst_aus. In Home Assistant könnte man mit einem timer, einem input_boolean oder einer Bedingung über den letzten Zustandswechsel arbeiten. In Node-RED wäre es ein Flow mit Sperrflag, Timeout und Statusprüfung.
Die Technik ist austauschbar. Die Denkweise ist wichtiger.
Warum das besser ist als eine reine Dashboard-Lösung
Natürlich könnte ich das Flurlicht auch über ein Dashboard (bezahlter Link) schalten. Ein Button für an, ein Button für aus, vielleicht noch ein hübsches Icon und ein dunkler Hintergrund, damit es nach Kontrollzentrum aussieht.
Aber dann habe ich nichts wirklich gelöst.
Ich müsste beim Heimkommen trotzdem daran denken, das Licht zu schalten. Ich müsste mit vollen Händen trotzdem irgendwie das Tablet bedienen. Und beim Verlassen müsste ich ebenfalls selbst kontrollieren, ob alles aus ist.
Das Dashboard ist in so einem Fall nur die digitale Version des Lichtschalters.
Die Automation dagegen nimmt mir einen kleinen, wiederkehrenden Handgriff ab. Aber eben nur dann, wenn es sinnvoll ist. Nicht immer oder blind und nicht aus Prinzip.
Und genau darum geht es: Eine einfache Automation ersetzt nicht nur einen Tastendruck. Sie sollte eine Situation verbessern.
Die wichtigste Frage vor jeder Automation
Bevor ich eine neue Automation baue, lohnt sich eine simple Frage:
Welches konkrete Alltagsproblem löst diese Automation?
Beim Flurlicht ist die Antwort klar:
Ich will im Dunkeln nicht erst nach dem Schalter suchen, wenn ich zur Tür hereinkomme. Gleichzeitig will ich aber kein Licht, das durch Hunde, zufällige Bewegung oder eine lange Nachlaufzeit ständig unnötig im Flur brennt und durch die Glastüren in andere Räume scheint. Und ich will unterscheiden können, ob die vordere oder hintere Haustür geöffnet wurde, weil daraus unterschiedliche Lichtszenen entstehen können. Mehrere Bewegungsmelder für den langen Flur wären dafür teurer, aufwendiger und trotzdem weniger eindeutig.
Die zweite Frage ist aber genauso wichtig:
In welcher Situation wäre diese Automation nervig?
Beim Flurlicht war die erste Antwort:
Wenn ich das Haus verlasse und das Licht gerade bewusst ausgeschaltet habe.
Die zweite Antwort kam erst später:
Wenn die Tür schon offen ist und ich danach das Licht ausschalte.
Erst durch diese zweite Frage wurde aus der einfachen Automation eine brauchbare Automation. Denn sie betrachtet nicht mehr nur einen Ablauf, sondern mehrere mögliche Reihenfolgen.
Kleine Regeln, großer Unterschied
Das Flurlicht-Beispiel ist technisch nicht beeindruckend. Es nutzt keine künstliche Intelligenz, keine Gesichtserkennung, keinen Cloud-Dienst und keinen magischen Hersteller-Algorithmus.
Es ist nur eine kleine Regel mit einer kleinen Sperrzeit und einer kleinen Zustandsprüfung.
Aber genau solche Details machen ein Smart Home im Alltag besser.
Nicht die große Präsentation, das schönste Dashboard oder die meisten Geräte. Sondern Regeln, die Rücksicht auf echte Nutzung nehmen und sich dabei so selbstverständlich anfühlen, dass man sie kaum noch bewusst wahrnimmt.
Eine einfache Automation ist selten einfach, weil der Alltag selten nur aus einem Trigger und einer Aktion besteht. Menschen gehen rein und raus. Sie schalten Dinge bewusst aus. Öffnen Türen aus unterschiedlichen Gründen. Machen Dinge in anderer Reihenfolge, als man sie beim ersten Skriptentwurf im Kopf hatte.
Und sie wollen nicht jedes Mal mit ihrem eigenen Haus diskutieren.
Wenn das Smart Home das berücksichtigt, wird es tatsächlich ein Stück smarter.
Fazit: Smart wird es bei den Ausnahmen
Die erste Version meiner Flurlicht-Automation war technisch korrekt: Tür auf, draußen dunkel, Licht an.
Aber korrekt ist nicht automatisch sinnvoll.
Die 30-Sekunden-Sperre nach dem Ausschalten war der erste wichtige Schritt. Sie verhindert, dass das Licht direkt wieder angeht, wenn ich es ausschalte und danach die Tür öffne.
Aber erst die zusätzliche Zustandsbewertung macht die Automation wirklich sauber. Denn auch die andere Reihenfolge muss erkannt werden: Tür auf, Licht an, Licht aus. In diesem Moment darf das Smart Home nicht stur denken: „Tür ist offen und es ist dunkel, also Licht wieder an.“ Es muss akzeptieren, dass das Licht in genau dieser Situation bewusst ausgeschaltet wurde.
Die Automation erkennt zwar nicht wirklich meine Absicht, aber sie respektiert zumindest naheliegende Situationen. Wenn ich das Licht gerade ausgeschaltet habe und die Tür im Spiel ist, muss das Licht nicht beleidigt wieder angehen.
Für mich ist das der Kern von echtem Smart Home:
Nicht alles automatisieren, was technisch möglich ist. Sondern die kleinen wiederkehrenden Situationen so lösen, dass sie weniger nerven.
Eine einfache Automation ist selten einfach. Aber wenn sie gut gemacht ist, fühlt sie sich genau so an. Nicht weil sie beeindruckt, sondern weil sie im richtigen Moment einfach logisch reagiert.
Passende Beiträge zum Weiterlesen
Wenn du tiefer in das Thema einsteigen möchtest, passen dazu auch meine Beiträge über Smart Home ohne Hersteller-App und Smart Home ohne Cloud. Dort geht es stärker darum, warum lokale Steuerung im Alltag oft angenehmer und langlebiger ist als ein System, das für jeden Schalter erst eine App oder einen Hersteller-Account braucht. Praktischer wird es im Artikel zur Shelly Direktverknüpfung ohne Cloud, in dem lokale Automationen direkt zwischen Geräten umgesetzt werden. Wer lieber mit ioBroker arbeitet, findet mit Automatisches Licht mit Blockly und Licht automatisch einschalten beim PC-Start weitere Beispiele dafür, wie aus einfachen Auslösern erst durch Bedingungen und Kontext brauchbare Automationen werden.
GrayTheZebra ist Entwickler und Betreiber von prokrastinerd.de mit Fokus auf Smart Home ohne Cloud, ESP32 und MQTT-basierte Systeme. Alle Projekte basieren auf praktischer Umsetzung und eigener Hardwareentwicklung.
Autorprofil und Hintergrund:
Über GrayTheZebra

