Da ich ja schon einige, huch, Jahrzehnte bei der Sache bin, wollte ich mal meine Erfahrungen mit automatischer Lichtsteuerung teilen. Denn vergessen wir nicht, Home Automation, wie man „Smart Homes“ früher genannt hat, lebt ja nicht von Spielereien wie „ich kann die Farbe per App einstellen“ sondern erstmal davon, dass Dinge von allein passieren, die ursprünglich oder „normalerweise“ manuell erledigt werden müssen. Also dass es insgesamt für die User einfacher wird.
Nun lässt sich jederzeit einwenden, es sei ja wohl nicht so viel Arbeit, einen Lichtschalter zu betätigen. Dem entgegen steht die schiere Häufigkeit des Vorgangs, die Tatsache dass mensch nicht immer eine Hand frei hat und dass Leute gerne vergessen, das eingeschaltete Licht am Ende auch wieder aus zu schalten. Ich sage aus eigener Erfahrung: Wer den Komfort einmal kennt möchte ihn nicht mehr missen. Sofern die Umsetzung gelungen ist, versteht sich. Da lauern nämlich auf dem Weg doch so einige Fallstricke.
Grundsätzliche Strategien
Die einfachste Herangehensweise ist wohl, das Licht automatisch zu bestimmten Uhrzeiten ein- und auszuschalten. Das haben schon meine Großeltern so gemacht, damals noch mit mechanischen Zeitschaltuhren. War damals schon irgendwie reizvoll, aber schlussendlich doch nie so ganz befriedigend. Hauptnachteil ist, dass sich bspw. die Wetterlage eben nicht an die Uhrzeit hält und außerdem der Zeitpunkt, wann es hell bzw. dunkel wird, sich im Jahresverlauf verschiebt. Von der Tatsache, dass sich diese simple Automation nicht nach tatsächlichem Nutzungsverhalten richtet, ganz abgesehen.
Praktikabler erscheint im Vergleich die Steuerung mittels Dämmerungsschalter, oder im Falle eines vernetzten Hauses, die Nutzung von Helligkeitssensoren. Auf der Hand liegender Vorteil ist, dass hier die Beleuchtung tatsächlich abhängig vom natürlichen Licht geschaltet werden kann, also zumindest in Ansätzen bedarfsgerecht. Über das Nutzungsverhalten kann ein Helligkeitssensor jedoch unmittelbar nichts aussagen.
Um wirklich auf die Nutzung eines Raums, Durchgangs etc. zu reagieren und das Licht bedarfsweise zu schalten, braucht es weitere Sensorik, meist in Form von Bewegungsmeldern. Häufig kommen sog. PIR (passiv-Infrarot-)-Melder zum Einsatz, welche auf die Wärme des Körpers reagieren. Aber auch exotischere Varianten wie Doppler-Radar-Melder oder gar Lichtschranken können in bestimmten Fällen benutzt werden. Des weiteren gibt es besonders empfindliche Varianten, die Präsenzmelder genannt werden. Auf die Funktionsweise soll hier nicht weiter eingegangen werden; die Auswahl und korrekte Platzierung solcher Melder ist noch mal ein ganz eigenes Thema.
Im vernetzten Haus können noch weitere Sensoren bzw. Parameter berücksichtigt werden, etwa ob eine bestimmte Tür geöffnet ist, oder auch ein aktivierter „Nachtmodus“.
Vernetzter Ansatz
Im vernetzten Haus haben wir im tendenziell mehrere Sensoren, deren Status bzw. Messwerte wir auswerten und in unseren Skripten verarbeiten können. Also wird unsere Lösung für das Problem der automatischen Lichtsteuerung auf eine Kombination der oben aufgezählten Strategien hinaus laufen. Wir suchen, esoterisch ausgedrückt, nach „ganzheitlichen“ Lösungen.
Auch das smarteste Smart Home wird in der Praxis meist bloß von von Skripten gesteuert. Und das ist auch ganz gut so, denn Skripte sind logisch, nachvollziehbar und wir können eingreifen und diese anpassen. Eine „black box“ die einfach selbsttätig irgendwas tut, was wir nicht nachvollziehen und kaum beeinflussen können ist selten hilfreich und ganz sicher nicht smart.
Ausgehend von meinen eigenen Erfahrungen sind meine grundsätzlichen Anforderungen für automatische Lichtsteuerung in der Regel:
[ol]
[li]Licht soll bei Raumnutzung eingeschaltet werden, falls nicht genug natürliches Licht vorhanden ist
[/li][li]Licht soll nach einer Zeit der Inaktivität wieder ausgeschaltet werden
[/li][li]Die Automatik muss sich abschalten sowie manuell umgehen lassen auf intuitive Weise
[/li][/ol]
Fallstricke
Die ersten beiden Anforderungen sind zunächst trivial und lassen sich in zwei Zeilen umsetzen. Außerdem wird so etwas meist von Haus aus von Systemen wie HomeMatic etc. unterstützt und braucht zunächst gar keine Skriptprogrammierung.
Mit dem dritten Punkt kommt aber bereits ein Faktor hinzu, der die Sache etwas komplizierter macht. Und auch die ersten beiden Punkte stellen sich in der Praxis oft komplizierter dar als man zunächst glauben mag.
Fallstricke Punkt 1:
[ul]
[li]Was ist, wenn im Raum bereits irgendwelche Leuchten aktiv sind?
[/li][li]Reagieren wir auch auf „es wird dunkel“ oder prüfen wir die Helligkeit nur im Moment der Präsenzmeldung?
[/li][/ul]
Fallstricke Punkt 2:
[ul]
[li]Wie genau definieren wir Inaktivität? Was ist, wenn Nutzer bspw. in der Badewanne entspannen und sich kaum bewegen?
[/li][li]Reagieren wir auch darauf, wenn es hell wird, also das natürliche Licht über die „ausreichend“-Schwelle kommt?
[/li][/ul]
Fallstricke Punkt 3:
[ul]
[li]Wie können Nutzer einen simplen, intuitiven „Opt-Out“ aus der automatischen Steuerun bewirken?
[/li][li]Reaktiviert sich die Automatik, wenn sie deaktiviert wurde, später von selbst?
[/li][/ul]
Was (meine) Erfahrung lehrt
Jede Person, die versucht hat, etwas im Haus zu automatisieren, wird mal die Erfahrung gemacht haben, dass eine selbst nach reiflichen theoretischen Überlegungen angelegte Automatik in der Praxis doch zu unerwünschtem Verhalten führen kann. Spätestens wenn wir nicht allein im Haus sind, kann schnell eine Situation Mensch versus Maschine entstehen, die der Reputation unserer gut gemeinten Automatisierungsbemühungen abträglich sein kann. Also empfiehlt es sich grundsätzlich, erstmal zu testen, beispielsweise im eigenen Arbeitszimmer, bevor man seinen genialen Automatisierungsalgorithmus live schaltet und auf das ganze Haus los lässt.
Was ich auch zu vermeiden versuche, sind jedwede „Überraschungseffekte“ wenn plötzlich etwas unerwartet und unverlangt von allein passiert und alle „oh“ sagen oder denken. Automation sollte sich organisch anfühlen, es sollte idealerweise genau dann genau so etwas passieren, wie es sinnvoll und hilfreich ist, so dass kein User dazu veranlasst wird, überhaupt weiter darüber nachzudenken oder gar einzugreifen.
Aus diesem Grunde halte ich nichts davon, wenn plötzlich irgendeine „Lichtstimmung“ aktiviert wird, obwohl im Raum bereits Licht brennt. Selbst wenn eine unabhängige Gruppe höchst renommierter Experten entschieden hätte, dass die oktroyierte Lichtstimmung wirklich objektiv die beste ist für die aktuelle Situation so führt es doch immer dazu, dass die im Raum anwesenden Personen, die sich ja offenbar bereits selbst Licht angemacht haben, sich bevormundet fühlen. Also: Nur dann Licht einschalten, wenn noch keines an ist!
Ähnlich verhält es sich mit Dämmerungsschaltung. Wenn dann für bestimmte eher „stimmungsgebende“ Leuchten und nicht für das große Putzlicht und am besten auch mit einer sehr langsamen Rampe, so dass es gar keinen „oha“-Moment gibt wo es plötzlich bretthell wird und sich alle verdutzt umschauen.
Was das Abschalten betrifft, gilt das gleiche: Niemals das Licht ausschalten weil es irgendwo „hell genug“ geworden ist. Es gibt eine Ausnahme; ich habe tatsächlich in einem Haus mal ein Skript geschrieben, das sämtliche unter n % gedimmte Leuchten abschaltet, wenn die Sonne aufgeht, weil dort stark gedimmte Leuchten als Nachtlicht genutzt und bei Tag oft vergessen wurden, da man kaum sehen konnte dass sie noch an sind. Aber das ist wirklich eine Ausnahme.
Auch ist wichtig, die möglichen Nutzungen eines Raums im Auge zu haben. Im Heimkino will man bspw. sicher kein Licht haben, während das Entertainmentgedönse läuft. Und sonst: Präsenzmelder sind eine feine Sache und können sehr gut funktionieren. Aber wenn jemand ungünstig sitzt oder steht, in Ruhe ein Buch liest oder in der Badewanne liegt, oder gar auf dem Sofa eingeschlafen ist, dann werden selbst die besten und angeblich unfehlbaren Präsenzmelder Schwierigkeiten haben, das zu registrieren. Also müssen in solchen Räumen entweder zusätzliche Faktoren einbezogen werden (im Bad etwa: Luftfeuchtigkeits-Trend) und ggf. das Timeout bis der Raum als inaktiv gilt verlängert werden. Oder aber man muss je nach Raum gänzlich auf diese Art von Automation verzichten. Bspw. in Schlafräumen wird es sonst sehr sehr kompliziert. Schlimmstenfalls geht das Licht aus, wenn jemand eingeschlafen ist (zunächst ja unter Umständen okay oder sogar erwünscht). Aber dann wenn sich die Person im Schlaf umdreht, dann registriert der Melder plötzlich wieder Präsenz und zack, geht das Licht an…
Die von mir vorgesehenen Möglichkeiten, die Automatik zu deaktivieren kommen auch nicht von ungefähr. Mag die Automatik bestenfalls in 99% der Fälle hilfreich sein, so kann es doch mal vorkommen, dass Umstände eintreten unter denen man sie nicht haben will. Aber auch in der Testphase, wenn möglicherweise etwas noch nicht rund läuft, kann eine simple Möglichkeit der Deaktivierung sehr hilfreich sein.
Doch mein persönlicher Ansatz geht noch weiter; ich möchte, dass für User eine simple und intuitive Möglichkeit des Opt-Out besteht. Idealerweise funktioniert das so organisch, dass mensch nicht mal darüber nachdenken braucht.
Meine Strategie hierzu ist, neben einer Bool-Variable zum Abschalten (bspw. per WebFront) der Automatik einen dreistufigen „Pausenmodus“ vorzusehen, in dem die Automatik vorübergehend nicht auf Präsenzmeldungen reagiert. Dieser wird zunächst von „inaktiv“ auf „scharf“ geschaltet, wenn eine Person das Licht im Raum manuell per Lichttaster aus schaltet und falls dann innerhalb der nächsten 10 Sekunden Bewegung im Raum ist, wird die scharfgeschaltete Pausenfunktion auf „aktiv“ umgeschaltet. Erst nachdem im Raum keine Aktivität mehr registriert wird, schalte ich die aktivierte Pausenfunktion wieder auf „inaktiv“ zurück. Ist die Pausenfunktion auf „aktiv“ so führt Bewegung im Raum nicht mehr dazu, dass Licht eingeschaltet wird.
Dies liest sich vielleicht etwas komplex, aber für User fühlt sich diese Pausenfunktion schlichtweg so an, dass sie das Licht ausschalten und es dann auch aus bleibt.
Fazit
Ich habe für all diese Anforderungen viele Skripte geschrieben, die allerdings immer sehr speziell auf die verwendeten Systeme zugeschnitten sind. Darum habe ich mich entschlossen, meine Überlegungen diesmal prosaisch zu teilen, anstatt eines Skripts, das ohnehin keiner einfach so übernehmen könnte.
Ich glaube, ich könnte meine Erfahrungswerte einerseits mit dem abgedroschenen „weniger ist mehr“ zusammenfassen, aber andererseits kann sich, wie bei der Opt-Out-Funktion auch lohnen, mal ein bisschen Komplexität zu wagen, damit es sich dann für die User nach „weniger“ anfühlt. Ich halte viel von einem User-zentrierten Denken, das auf Spielereien und „Wow“-Effekte verzichtet und sich daran orientiert, was am Ende wirklich als nützlich und hilfreich empfunden wird. Diese oft als „Woman Acceptance Faktor“ geschmähte Denkweise läuft letztlich heraus auf etwas, das wir alle wollen (sollten): Benutzerfreundlichkeit.