Auf dieser Seite
Die CCU liefert bereits eine Astrofunktion, die anhand der Koordinaten den Sonnenauf- und untergang berechnet. Da diese beiden Zeitpunkte relativ unflexibel sind und eigentlich nirgendwo so richtig passen, hatte ich die Funktion in meinem Tageszeit-Script schon etwas erweitert und den Tag in mehrere Phasen aufgeteilt.
Unsere niegelnagelneuen Rolladen sollen nun nicht nur nach Zeit öffnen und schließen, sondern auch nach Helligkeit: Im Morgengrauen sollen sie erst öffnen, wenn der Tag anbricht – bei Wolken also später als bei klarem Himmel. Umgekehrt dürfen sie abends auch etwas länger offen bleiben, wenn es länger hell ist.
Dazu gibt es hier eine handvoll Programme.
Benennung von Systemvariablen
Prinzipiell kann man Systemvariablen – so wie allen Objekten in der CCU – beliebige Namen geben, also z. B. auch Umlaute und Sonderzeichen verwenden. Ich empfehle jedoch, sich auf reguläre Buchstaben (a-z, A-Z) zu beschränken: Bei Umlauten und Sonderzeichen besteht die Gefahr, dass Systemvariablen in Scripten nicht überall gefunden werden.
Träge Helligkeit
Der einfachste Weg wäre natürlich, direkt die Helligkeit des Kombisensors zu verwenden, um festzustellen, dass es hell oder dunkel wird. Der Nachteil ist, dass der Kombisensor auch auf kurze Schwankungen z.B. durch vorbeiziehende Wolken reagiert.
Da die Rolladen auch tagsüber zur Beschattung eingesetzt werden, würden sie mit dem direkten Helligkeitswert gelegentlich etwas hektisch öffnen und schließen.
Ich bastele mir also als erstes ein Programm, das die Helligkeit mit etwas Trägheit in eine Systemvariable schreibt.
Die Variable Helligkeit ist einfach eine Zahl, die den geglätteten Helligkeitswert des Kombisensors aufnehmen wird.
Befüllt wird sie über ein kurzes WebUI-Programm.
Ich hänge das Script hier an meinen Systemtakt, damit es auf jeden Fall regelmäßig ausgeführt und so laufend der Durchschnittswert berechnet wird.
Theoretisch könnte ich auch den Kombisemsor als Gerät auswählen und das Script bei Aktualisierung der Helligkeit ausführen lassen. Allerdings kommt es dann womöglich zu unvorhersehbaren Werten, wenn der Kombisensor nicht regelmäßig seine Daten liefert – Funkstörungen oder ähnliches. Deshalb gehe ich auf Nummer sicher und bleibe beim Systemtakt.
Das Script ist absolut simpel:
gesamtes Script markieren / kopieren
real r = dom.GetObject ("AB Garten Kombisensor").DPByHssDP ("ILLUMINATION").Value();
object o = dom.GetObject ("Helligkeit");
o.State (((o.Value() * 4.0) + r) / 5.0);
Die Variable r wird mit dem aktuellen Helligkeitswert des Kombisonsors gesetzt. Objekt o ist die neue Systemvariable Helligkeit. Diese wird mit einer einfachen Formel aktualisiert: Der aktuelle Wert der Variable wird vierfach gewichtet, der neue Wert des Kombisensors einfach, dann die Summe durch 5 teilen.
Der Kombisensor muss jetzt mehrfach hohe Werte senden, um Helligkeit in die Höhe zu treiben und umgekehrt. Damit werden vorbeiziehende Wolken oder kurze Sonnenstrahlen herausgefiltert. Programme, die von der Helligkeit abhängen, bekommen einen geglätteten Wert und springen nicht im Minutentakt zwischen „Sonne“ und „Wolken“ oder ähnlich.
Der Vorteil der Trägheit ist natürlich auch ihr Nachteil: Die Variable reagiert mehr oder weniger stark verzögert auf Helligkeitsänderungen. Im folgenden Abschnitt sieht man am praktischen Beispiel, wie sich das auswirkt.
Tag und Nacht
Nachdem wir nun einen Helligkeitswert haben, der dem Tagesgeschehen träge hinterherläuft, ist es Zeit für die Systemvariable, die Tag und Nacht speichert.
Ich nenne sie Tag und Nacht und sie kann die Werte Tag und Nacht annehmen. Ich bin ein Genie!
Das WebUI-Programm ist etwas ganz Besonderes, denn ich verwende hier ausnahmsweise kein Script, sondern klicke mir die Logik in der Oberfläche zusammen.
Ich gehe einfach der Reihe nach die Bedingungen durch, wann Nacht sein soll, und nur wenn keine davon zutrifft, ist es Tag.
Als erstes kommt das Zeitmodul: Wenn es zwischen 22:00 abends und 06:00 morgens ist, dann ist bei mir Nacht. Basta. Das Zeitmodul wird täglch ausgeführt und setzt dem Tag eine harte Grenze.
Strenggenommen wird bereits im Tageszeit-Script eine harte Grenze gesetzt, allerdings mit leicht anderen Uhrzeiten. Bevor ich das Script anpasse und mir womöglich Inkonsistenzen mit anderen Programmen einfange, die die Tageszeit nutzen, hole ich hier lieber das Zeitmodul raus.
Danach kommt die etwas flexiblere Tageszeit ins Spiel: Wenn es nach Astrofunktion Abend, Nacht oder frühmorgens ist, dann ist Tag und Nacht ebenfalls Nacht.
Zeit für die träge Helligkeit: Im Morgengrauen – also in der Stunde vor dem Tagesbeginn nach Astrozeit der CCU – verbleibt Tag und Nacht auf Nacht, solange Helligkeit nicht 0,5 oder höher ist. Die zusätzliche Bedingung für Tag und Nacht sorgt dafür, dass Tag und Nacht im Morgengrauen nicht wieder auf Nacht zurückspringt, falls ein paar Wolken aufziehen und es wieder dunkler wird.
In der Dämmerung – das ist die Stunde nach dem Tagesende gemäß Astrozeit – wechselt Tag und Nacht zu Nacht, wenn Helligkeit unter 15 ist. Eine zusätzliche Bedingung wie im Morgengrauen kann ich hier nicht direkt einbauen – dafür müsste man Bedingungen verschachteln können.
Auffällig ist, dass der Grenzwert für Tag im Morgengrauen und Nacht in der Dämmerung deutlich unterschiedlich ist. Das liegt wie angekündigt an der Trägheit der Helligkeit.
Wenn der Kombisensor die ersten Sonnenstrahlen registriert, liefert er erstmal nur Werte unterhalb von 1. Die werden dann in der Variable Helligkeit, die selbst über Nacht auf (fast) 0 abgesunken ist, noch durch 5 geteilt, so dass es sehr lange dauert, bis die Helligkeit reagiert. Daher lasse ich den Tag schon bei einer (trägen) Helligkeit von 0,5 anbrechen.
Am Ende des Tages ist es umgekehrt: Die registrierte Helligkeit des Kombisensors sinkt langsam Richtung 0, aber die träge Helligkeit sinkt deutlich langsamer. Also springt Tag und Nacht schon bei Unterschreiten eines deutlich höheren Wertes auf Nacht.
„Deutlich höher“ ist hier übrigens relativ – wenn die Sonne scheint, liegen die Werte über dem 200-fachen meiner mickrigen „15“ für das Tagesende.
Durch Änderung dieser Werte kann man auch noch etwas nachjustieren, wenn Tag oder Nacht zu früh oder spät ausgelöst werden.
Natürlich kümmert sich noch eine letzte Bedingung darum, dass Tag und Nacht in der Dämmerung auf jeden Fall auf Nacht bleibt, wenn es einmal gesetzt ist. Es hat doch hoffentlich niemand geglaubt, ich hätte das vergessen?
Schließlich und endlich wird die Systemvariable gesetzt – Nacht, wenn eine der Bedingungen zutrifft, ansonsten Tag.
Sonne, Regen, bedeckt?
Wenn ich schon mal dabei bin, meine CCU mit Systemvariablen vollzupflastern, dann kann ich auch noch eine dritte anlegen, die mir Sonnenschein (für die Beschattung meiner Räumlichkeiten) und Regen (für die Beschirmung meines müden Hauptes) anzeigt.
Ich nenne sie diesmal nur Sonne. Es handelt sich um eine Werteliste mit den Werten Sonne, Regen und bedeckt. Ich weiß, die Überraschung ist nach der Überschrift irgendwie weg.
Das WebUI-Programm kommt wieder ohne Script aus.
Im ersten Teil wird geprüft, ob der Kombiseonsor gerade Regen meldet. Wenn ja, dann wird auch die Systemvariable auf Regen gesetzt.
Regen ist bei mir Regen – egal ob die Sonne scheint. Einen Zustand Regenbogen gibt es nicht.
Der zweite Teil des WebUI-Programms kümmert sich dann um die Sonnenerkennung. Hier kommt die träge Helligkeit ins Spiel: Wenn sie über 2500 ist, dann ist es wohl schon einige Zeit halbwegs hell, also wird Sonne auf Sonne gesetzt. Sinkt die Helligkeit darunter, ist es bedeckt.
Sturm und Wind
Ich gehöre ja zu den Exoten, die ihre Fenster mit der WinMatic öffnen und schließen lassen. Bei Sturm würde ich sie immer schließen, also brauche ich eine Sturmerkennung.
Falls ich jemals unsere Markise in die HomeMatic einbinde, soll die ebenfalls automatisch eingefahren werden – aber nicht erst bei Sturm, sondern schon bei Wind.
Auch hier wäre der einfachste Weg, direkt die Windgeschwindigkeit des Kombisensors zu verwenden. Da habe ich dann aber den Effekt, dass bei Windböen die Fenster immer wieder geschlossen und geöffnet werden. Ich brauche also auch hier so etwas wie Trägheit – aber natürlich keinesfalls, wenn es um die Erkennung von Wind und Sturm geht, sondern nur für die Auflösung.
Die Lösung: Zwei Systemvariable, die bei Wind bzw. Sturm aktiviert werden und erst nach einer Stunde wieder in ihren Ausgangsstatus zurückfallen, wenn zwischendurch kein Wind mehr wehte.
Die Variablen Sturm_1h und Wind_1h sind Logikwerte, die Sturm bzw. Wind oder Flaute signalisieren können. Sie werden unabhängig voneinander gesetzt, denn auch wenn ein Sturm vorbei ist, kann es immer noch windig sein.
Als erstes das WebUI-Programm für Wind_1h.
Wie man sieht – sehr einfach gestrickt. Wenn die Windgeschwindigleit größer als 15 km/h ist, wird Wind_1h auf Wind gesetzt. Nach einer Stunde zurück auf Flaute.
Wichtig sind hier drei Dinge:
- Emtsprechend der Logik von WebUI-Programmen muss bei Aktualisierung auslösen ausgewählt werden, damit bei anhaltendem Wind die Variable so lange immer wieder getriggert wird, bis tatächlich für eine Stunde kein Wind herrschte.
- Vor dem Ausführen alle laufenden Verzögerungen beenden muss aktiviert sein, damit die Stunde immer wieder von vorne beginnt. Fehlt der Haken, wird eine Stunde nach der ersten Aktivierung die Variable wieder deaktiviert, auch wenn es eigentlich noch windig ist und die Variable bei der nächsten Aktalisierung gleich wieder aktiviert wird.
- In den Geräteeinstellungen des Kombisensors muss eingestellt sein, dass er keine Aktualisierungen auslässt, auch nicht bei unveränderten Werten. Ich hatte bei der Sommer-Erkennung für meine Heizungssteuerung (die neueste …) mal was dazu geschrieben.
Für Sturm_1h gibt es ein entsprechendes Programm mit dem Grenzwert 25 km/h.
Natürlich wären 25 km/h bei weitem noch kein Sturm. Der Kombisensor ist freilich auch kein Präzisionsinstrument, das ich im Freifeld oder in großer Höhe installiert hätte. 25 km/h (oder 15 km/h für Wind) passen für mich, aber man kann die Werte wie alle Parameter in meinen Beispielen individuell anpassen und bei Bedarf auch immer nachjustieren.
Die Wind- und Sturmerkennung lässt sich auch mit weiteren Informationen kombinieren. Zum Beispiel könnten meine Fenster nicht nur auf Sturm reagieren, sondern auch auf Wind, wenn es gleichzeitig regnet – damit der Regen draußen bleibt.
Wer keine WinMatic hat, kann sich auch per Telegram informieren lassen, wenn noch Fenster offen sind, und dann durchs Haus sprinten. Niemand hat behauptet, dass das Leben mit Hausautomation bequemer wird.
