Rollladensteuerung 2.0 - modern, einfach, flexibel, modular (mit CCU)

[MichaelN]

Es gibt sehr viele Threads und Webseiten zum Thema Rollladensteuerung, auf die man über Google auch unweigerlich stößt. Dort sind gute Ideen beschrieben, mit denen ich auch gestartet bin. Ich habe dann aber mit etwas mehr Erfahrung mit Homematic festgestellt, das man mit einer CCU auf aktuellem Firmware-Stand einige Dinge eleganter lösen kann.

Projektumfang:
Die beschriebene Rollladensteuerung öffnet und schließt die Rollläden dämmerungsgesteuert beim Wechsel Tag/Nacht. Sie fährt die Rollläden witterungsgesteuert in eine bedarfsabhängige Beschattungsposition zur Vermeidung von unnötigem Wärmeeintrag (Hitzeschutz). Die gesamte Automatik kann zentral deaktiviert werden.


Vorraussetzungen:
CCU mit aktueller Firmware (ab 3.45.7)
Sensor zur Erkennung von Sonnenschein, empfohlen Temperatur-Differenz-Sensor; notfalls Lichtsensor, Wettersensor oder Wetterdaten aus dem WWW
natürlich Rolladenaktoren
optional Türgriffsensor oder Tür/Fensterkontakt

benötigte Fähigkeiten:
Grundkenntnisse in der WebUI-Programmierung (Anlernen von Geräten, Anlegen und Ändern von Programmen, Einfügen von Skripten)
grundlegendes Wissen über die Unterschiede zwischen "bei Aktualisierung", "bei Änderung", "nur prüfen"
Anlegen von Systemvariablen
grundlegendes Logik-Verständnis / Abstraktionsvermögen um die beschriebenen Lösungen ggf. auf eigene Bedürfnisse anzupassen
Tips zur Fehlersuche: viewtopic.php?f=31&t=67597

Systematik:
Statt die Rollladen direkt zu steuern, indem z.B. ein Programm auf Uhrzeit oder Temperatur reagiert und dann das Rollo fährt,
ist der Aufbau prinzipiell modular, indem eine Systemvariable einen Zustand repräsentiert und dessen Änderung eine Aktion auslöst.

Der Vorteil ist die Möglichkeit das Verhalten an zentraler Stelle zu beeinflussen und zudem eine Reduzierung der Komplexität, indem Entscheidungsbäume entzerrt werden.

Generell versuche ich die Grundsätze für stabile Programme zu verfolgen
- statt SONST-WENN-Blöcke jeweils eigene Programme erstellen
- bedingungslose SONST-Blöcke vermeiden

Vorbereitung:
Sensoren und Aktoren anlernen, den Geräten und Kanälen sprechende Namen geben, doppelte Namen vermeiden
Grundlegend benötigte Systemvariablen anlegen:

• sonne_elevation; Typ Zahl von -180 bis +180 grad
• sonne_azimut; Typ Zahl von-360 bis +360 grad
• Nacht; Typ Logikwert und den Optionen es_ist_nacht / es_ist_Tag
• Rollo_Automatik; Typ Logikwert und den Optionen automatisch/manuell 
• Sonnenstatus; Typ Werteliste mit den Werten: keine_Sonne;Schatten_wird_Sonne;Sonne_wird_Schatten;Sonne_scheint
  Achtung: hier ist die Reihenfolge der Werte wichtig, falls man später mal eine grafische Auswertung machen will. Die Werte werden von den Zahlen 0-3 repräsentiert, wobei bei korrekter Reihenfolge 0=keine_Sonne und 3=Sonne_scheint bedeutet
• Beschattung; Typ Logikwert mit den Optionen ja/nein
• Level_Fenster_xxx; Typ Zahl von 0 bis 100 mit Einheit % ODER von 0 bis 1 mit Einheit (%)
  => Es muss für jedes Fenster eine eigene Variable angelegt werden oder zumindest für alle Fenster, die eine unterschiedliche EInstellung für die Behanghöhe (unterschiedliche Laufzeit) benötigen.
  Achtung: hier lauert eine kleine Falle. Die Behanghöhe wird intern in 1/100 gespeichert und für die Anzeige in der WebUI in % umgerechnet. Legt man die Variable mit der Einheit % an, dann erfolgt auch hier die Umrechnung. Nimmt man eine andere Einheit - wie z.B. (%) - dann erfolgt keine Umrechnung. Man muss dies dann nur konsequent beachten. Zur Stolperfalle wird es, wenn man in Skripten die Behanghöhe verarbeitet, weil hier keine Umwandlung in % stattfindet. Daher habe ich die Variable mit (%) angelegt.
  Zur Problematik der Einheit % in der WebUi siehe diesen und folgende Beiträge.
• Forecast_Temp; Typ Zahl mit -50 bis +50 °C
• Protokolleintrag; Typ Zeichenkette; Option "protokolliert" aktiv - diese Variable ist optional und dient einfach dazu Statusinformationen ins Protokoll zu schreiben. Wenn man das nicht möchte, ignoriert man die entsprechende Aktion in den Programmen einfach

Ablaufplan:

[MichaelN]

PGM_Sonnenstand

Dies ist ein zentrales Programm, das auch abseits der Rollladensteuerung gute Dienste leistet.
Hiermit werden alle 3 bis 5 Minuten (je nach gewünschter Genauigkeit) die SV sonne_elevation und sonne_azimut neu berechnet.
Ab CCU Firmware 3.45.7 verfügt diese über eine eigene Funktion um auf Basis von Uhrzeit und Ort die Sonnenwinkel zu berechnen. Das in alten Quellen beschriebene aufwendige Skript ist nicht mehr notwendig. In der Systemsteuerung der CCU muss natürlich die richtige geografische Position eingetragen sein.

Der Elevationswinkel dient dazu dämmerungsabhängige Aktionen zu steuern. 0° bedeutet Sonnenauf/untergang. -6° ist die bürgerliche Dämmerung. Die Steuerung über die Sonnenhöhe im Gegensatz zur Astrofunktion des Zeitmoduls hat den Vorteil, das damit automatisch die unterschiedliche lange Dämmerungsphase in Sommer und Winter berücksichtigt wird.
Mit der einfachen Astro-Funktion der Standard-CCU kann man nur Sonnenauf/untergang ansprechen. Beim Sonnenuntergang ist es den meisten aber noch viel zu hell, um schon die Rollos zu schließen. Mit Tricks oder auch mit dem Zeitmodul der RasberryMatic kann man eine feste zeitliche Verschiebung vor/nach Sonnenuntergang festlegen - aber dann wird man feststellen, das man im Sommer eine andere Verzögerung braucht, als im Winter. Mit der Sonnenhöhe ist dieses Problem gelöst. Neben der Rollladensteuerung kann man den Elevationswinkel auch zur Steuerung der Beleuchtung nutzen.

Der Azimut dient dazu festzustellen, ob die Sonne überhaupt ins Fenster scheinen kann. Man könnte ganz brutal einfach alle Rollos schließen, wenn die Sonne scheint oder etwas eleganter anhand des jährlichen Sonnenlaufs die maximale Zeitspanne feststellen. Das führt aber immer dazu, das die Rollos geschlossen sind, obwohl gar keine Sonne hinein scheinen kann. Wer gerne auch mal Licht in der Wohnung hat oder einfach rausschauen möchte, ist daher froh, wenn er die Schließzeiten auf ein Minimum reduzieren kann. Das macht der Azimutwinkel. Diesen muss man dann nur für jedes Fenster individuell ermitteln. Der Azimut bleibt übrigens über das ganze Jahr gleich (tritt nur jeden Tag zu einer anderen Zeit ein). Die Beschattung kann nur ggf. durch die Sonnenhöhe beeinflusst werden, wenn noch ein Dachüberstand oder Bäume die Sonne blockieren können. Die Aufgabe ist also einmal für jedes Fenster (oder Himmelsrichtung) den Start- und End-Azimut-Winkel für die notwendige Beschattungsphase zu ermitteln. Ggf. kann man das auch theoretisch mit Hilfe von https://www.sonnenverlauf.de/ ermitteln. Oder man packt sich die beiden Systemvariablen in die Benutzer-Favoriten und kann dann mit einem Blick in der WebUI die aktuellen Werte feststellen.

Code: Alles auswählen

! Sonnenstand ermitteln V1.2
dom.GetObject(ID_SYSTEM_VARIABLES).Get("sonne_azimut").State(system.SunAzimuth().Round(1));
dom.GetObject(ID_SYSTEM_VARIABLES).Get("sonne_elevation").State(system.SunAltitude().Round(1),100);

Anmerkung: EDIT 02.07.2022 - Berechnung Elevation um 100 ms verzögert um ggf. Probleme mit zeitgleichem Setzen von Trigger-Variablen zu vermeiden
siehe auch Github-Issue - Dank für den Denkanstoß an Xel66

PGM_Nachterkennung

dies ist das zweite zentrale Programm und dient dazu festzulegen, ob es nun Tag oder Nacht ist. Und zwar unabhängig von dem, was die Astro-Funktion des Zeitmoduls als tag oder nacht definiert. Hier kann man seine individuellen Vorlieben einstellen. Ggf. auch abhängig von Wochentag oder Jahreszeit.

Ich kombiniere hier einfach ein Zeitmodul mit dem Elevationswinkel.Das Zeitmodul stellt sicher, das nicht vor 05:30 der Tag beginnt und die Nacht frühestens um 21:00. Wenn die Dämmerung entsprechend den gewählten Winkeln später stattfindet verschiebt sich der Tagesbeginn und Nachtbeginn nach hinten. Bedeutet im Sommer fahren die Rollos um 05:30 hoch, im Winter später. Abends fahren die Rollos im Winter um 21:00 runter, im Sommer aber je nach Dämmerung später.

Zusätzlich setze ich nachts noch die Variable Sonnenstatus auf keine_Sonne, damit nicht irgendwelche Tropennächte mit hohen Temperaturen falsche Daten liefern.

Hier ist auch der erste Ansatzpunkt für eine Individualisierung / Modularisierung. Man kann z.B. 2 verschiedene Programme zur Nachterkennung erstellen, wobei das eine an den Wochentagen reagiert und das andere am Wochenende.

Alle Programme die Aktionen auslösen, reagieren dann nur auf die Systemvariable "Nacht". Die Komplexität ist also zentral an einer Stelle gebündelt.

[MichaelN]

PGM_Automatik_umschalten

Um die Rollo-Automatik komfortabel ein- und ausschalten zu können benötigen wir eine virtuelle Taste. Dazu wird eine der Tasten von der virtuellen Fernbedienung HmIP-RCV-50 als "Auto-Umschalter" benannt und ein Programm erstellt, das darauf reagiert. Man kann dann später in WebUI Programmen einfach die Systemvariable schalten oder man kann auch eine Direktverknüpfung eines Aktors mit der virtuellen Taste anlegen oder diese Taste in einen Favorit der WebUI packen.

Rollo_Nacht_Fenster

Um ein erstes Erfolgserlebnis nach der Vorarbeit zu haben, legen wir nun das Programm zur Nachtsteuerung der Fenster an.
Dieses fährt die Fensterrollos auf 0% Behanghöhe, wenn die Systemvariable Nacht auf nacht umschaltet und die Rollo_Automatik auf automatisch steht.
Empfohlen wird die Rollos jeweils im Abstand von einigen Sekunden verzögert zu fahren, um zuviel Durcheinander auf dem Funkkanal zu vermeiden.

Rollo_Nacht_Tuer

Für alle Rollos mit Aussperrschutz (typisch Balkon/Terassentür) brauchen wir noch einen Sensor zur Detektion, ob die Tür offen steht. Optimal ist ein Drehgriffsensor, da dieser auch gekippte und offen angelehnte Türen feststellt. Die Vorgehensweise dafür ist hier beschrieben:

Und wenn man sowieso schon mal die Sensorik hat um gekippte und geschlossene Türen zu erkennen, dann kann man dies auch gleich für eine weitere Komfortfunktion nutzen. Mit dieser optionalen Erweiterung fährt das Rollo bei gekippter Tür "auf Lück" zum besseren Lüften. Das funktioniert sowohl beim automatischen Schließen des Rollos, als auch wenn man bei bereits geschlossenem Rollo die Tür auf Kipp stellt. Schließt man die Tür später, fährt das Rollo auch komplett zu.

Wichtig ist, das man in den Geräteeinstellungen des HmIP-SRH eine Eventverzögerung von 2-5 Sekunden eingibt, damit der Wechsel von geschlossen über offen nach gekippt nur eine Meldung auslöst.

[MichaelN]

Rollos_hoch_alle

Damit die Rollos zum Tagesbeginn wieder hochfahren - und auch beim Ende des Sonnenscheins die Beschattung beendet wird - ist dieses Programm notwendig. Es fährt - auch wieder verzögert - alle Rollos auf 100%.

Damit ist erstmal die Grundfunktion tags auf / nachts zu gewährleistet.

Beschattungssteuerung

Jetzt kommen wir zur Kür, der Beschattungssteuerung. Dazu brauchen wir zunächst noch mehr Vorarbeit, weil wir die Programmlogik aufbauen müssen, welche zwischen Sonnenschein und Wolken unterscheidet. Zusätzlich wollen wir noch zwischen Beschattung notwendig oder nicht unterscheiden - denn im Winter / an kühlen Tagen nimmt man die Sonneneinstrahlung ja gerne als kostenlose Heizenergie mit.
Nun möchte ich dies nicht starr an Jahreszeiten koppeln, da es ja besonders in der Übergangszeit mal warme und kalte Tage gibt. Also brauchen wir eine intelligentere Steuerung.

Ich nutze dafür die vorhergesagte Tageshöchsttemperatur für den kommenden Tag, die in der Systemvariablen Forecast_Temp abgelegt wird. Alternativ oder zusätzlich kann man auch die gemessene Aussen- oder Innentemperatur heranziehen. Ich nutze z.B. auch noch die Aussentemperatur im Schatten - als Sicherheit, falls die Wettervorhersage mal krass daneben lag.


PGM_Wettervorhersage

Das bedeutet aber auch, das wir uns erstmal die Wettervorhersage beschaffen müssen. Dazu habe ich <hier:Wettervorhersage über AccuWeather> beschrieben, wie man ein Skript zur Abfrage der Wetterdaten anlegt. Dieses Skript wird einmal morgens gegen 5:10 ausgeführt. 05:10, weil AccuWeather um 5 Uhr morgens die Daten aktualisiert und weil man nur 12 Stunden Vorhersage bekommt. Das reicht dann bis 17:00, was für die Tageshöchsttemperatur ausreichend ist. Diese Funktionalität ist optional. Wer das nicht benötigt, kann die SV Beschattung entweder anders steuern oder sie auch komplett weglassen. Dann natürlich in allen Programmen, wo die Systemvariable Beschattung genutzt wird! Und natürlich kann man dann auch die Variable Forecast_Temp nicht für die Steuerung nutzen.
Wer das Wetterskript nutzt, muss dafür natürlich eine wie im Beitrag 1 beschrieben die Systemvariable Forecast_Temp anlegen.

Will man nur Forecast_Temp holen, lautet der Deklarierungteil für das Wetterskript:

Code: Alles auswählen

integer AnzahlTags        = 1; !-Anzahl der eingetragenen XML-Tags
string xmlTagStart        = 'Temperature';     !-XML-Start-Tag
string xmlTagEnd          = 'RealFeelTemperature'; !-XML-End-Tag
string xmlWertStart       = 'Value'; !-Suchstring vor dem Wert
string xmlWertEnd         = 'Unit';    !-Suchstring nach dem Wert
string xmlWertStartOffset = "7";             !-Länge Wert-Suchstring + Anzahl Zeichen bis zum Wert
string xmlWertEndOffset   = "9";             !-StartOffset + Anzahl Zeichen zwischen Zahl und Ende-String
string NameSVavg0         = "";      !- Namen der Systemvariablen fuer Durchschnitt aktueller Tag
string NameSVmin0         = "";	  !- Namen der Systemvariablen fuer min-Wert
string NameSVmax0         = "Forecast_Temp";	  !- Namen der Systemvariablen fuer max-Wert
integer RegenFlag         = 999;      !- Position der Regendaten (ab 0 zählen) zur Ausgabe der Gesamtmenge - auf 999 setzen, wenn stattdessen der Tagesdurchschnitt gewünscht ist
integer WindFlag          = 999;    ! Position der Winddaten (zur Umrechnung von km/h in m/s) - auf 999 setzen, wenn keine Umrechnung gewünscht oder kein Wind ausgewertet werden soll
integer Stunden           = 12;     !- Anzahl der Stunden, die ausgewertet werden (min 1 / max 12)
boolean SAVE              = true;   !- in SV speichern: auf false für Testbetrieb, sonst true    

[MichaelN]

PGM_Beschattung

Dieses Programm enthält nun die Logik um die Beschattung aktiv oder inaktiv zu schalten

Optional kann man das weiter ausbauen. Ich nutze z.B. noch die gemessen Schattentemperatur für den Fall das die Wettervorhersage daneben lag.

PGM_Schatten-Level

Der nächste Nutzen, den ich aus der Wettervorhersage ziehe ist die Steuerung des Beschattungslevels. Für mildere Sonnentage fahre ich die Rolladen nur zu 3/4 runter, an Hitzetagen dagegen fast komplett zu. Dazu ändert ein Programm einfach anhand der Forecast_Temp die in den Level_xxx Variablen gespeicherte Behanghöhe für die Schattenposition. Natürlich könnte man das auch anhand gemessener Innen- oder Aussentemperatur steuern. Die gewünschten Schattenpositionen sind einmal zu ermitteln, indem man die Rollos entsprechend manuell verfährt und dann in der WebUI die angezeigte Ist-Höhe nachschaut. Nach der Anlage des Programms führt man das am besten einmal manuell aus, damit die Variablen mit den richtigen Werten beschrieben werden.

Bitte wie im Beitrag 1 beschrieben beachten, das man abhängig von der gewählten Einheit entweder Werte zwischen 0-100 % oder 0-1 einträgt.

Will man das der Hitzeschutz-Level auch berücksichtigt wird, wenn man tagsüber darauf umschaltet, dann siehe diese Ergänzung:
viewtopic.php?f=18&t=60764&p=679159#p679159

[MichaelN]

Sonnen/Schattensteuerung

Jetzt kommt der komplexeste Teil. Einfach ist es an verregneten Tagen oder solchen mit purem Sonnenschein: das ist selbst mit einfachster Sensorik und Logik leicht zu detektieren. Schwierig sind die Tage mit wechselnder Bewölkung. Hier muss man etwas Feintuning betreiben, will man vermeiden bei Regen im Dunkeln zu sitzen oder bei Sonne trotzdem zu schwitzen. Aber der Lohn ist dann eine Automatik die ziemlich gut arbeitet.

Der Trick ist die Werteliste Sonnenstatus, die zeitverzögert geschaltet wird. Damit wird vermieden, das sofort bei einem Sonnenstrahl oder einer kleinen Wolke die Rollos hin und her fahren. In den üblichen Steuerungen wird hier mit einer einfachen Logikvariablen gearbeitet. Meine Umsetzung mit einer Werteliste erlaubt es im Vergleich dazu aber die Zwischenzustände ebenfalls zu erfassen und bietet eine noch stabilere Steuerung. Bei meiner Lösung wird z.B. sehr elegant verhindert, das bei Erreichen des Azimutwinkel zur Beschattung eines Fenster das Rollo noch runterfährt, weil die Variable noch auf Sonnenschein steht, obwohl bereits der Countdown für die Umschaltung auf kein_Schatten läuft. 10 Minuten später würde das Rollo wieder hoch fahren, diese unnötige Fahrt kann man vermeiden, wenn man den nächsten Zustand bereits kennt.

Sonnensensor

Zunächst braucht man einen Sensor um überhaupt Sonnenphasen von Schattenphasen zu unterscheiden. Im Gegensatz zur ersten spontanen Idee ist ein (Homematic) Lichtsensor wegen seiner Richtungsabhängigkeit und begrenzten Empfindlichkeit weniger dafür geeignet. Es ginge ggf. auch, wenn man für jede Himmelsrichtung einen Sensor witterungsgeschützt so anbringen kann, das er trotzdem komplett sonnenbeschienen ist. Dann ist die Logik der Sonnen/Schattenerkennung entsprechend darauf abzustimmen. Ggf. aggregiert man vorher in einem extra Programm/Skript die Werte mehrerer Sensoren um den Maximal-Wert (gefiltert) an die Sonnensteuerung weiterzureichen.

Als beste Lösung hat sich der HM Temperatur-Differenz-Sensor mit 2 Temperaturfühler bzw. Das HmIP Pendant HmIP-STE2-PCB herausgestellt, der durch die Platzierung des einen Sensors im Schatten und des anderen in der Sonne eine Temperaturdifferenz ausgibt, der sehr verlässlich zur Erkennung von Sonne/Schatten genutzt werden kann.
Wie man diesen installiert, habe ich <hier: Sonnensensor mini> beschrieben:
Der Differenz-Temperatur-Sensor HM-WDS30-OT2-SM-2 / HmIP-STE2-PCB liefert 4 Kanäle: jeweils die Temperatur der beiden Fühler und die Differenz von 1-2, sowie 2-1. Ich habe die Kanäle entsprechend der Platzierung der Fühler in Schatten und Licht umbenannt, sowie den Differenz-Kanal aus Licht-Schatten in Diff, so das ich dort positive Werte bei Sonnenschein erhalte.

[MichaelN]

Um nicht auf winzigste Temperaturänderung zu reagieren kann man entweder durch großzügig gewählte Hysterese (Unterschied zwischen Ein- und Ausschaltschwelle) oder Zeitverzögerung das System beruhigen. Das wird in meiner Routine ebenfalls gemacht. Man kann aber (zusätzlich) die Mittelwerte bilden und damit arbeiten. Dies ist letztendlich eine Geschmacksfrage.

Mittelwert per selbst konfigurierendem Skript
Siehe viewtopic.php?f=43&t=10182&hilit=Mittel ... 70#p750572

Mittelwert per CuxD
Ich habe dafür ein CuxD Wrapper Device angelegt, das die Differenztemperatur ausliest und dafür einen Mittelwert ausgibt. Relativ einfache Geschichte. Falls das jemand umsetzen möchte zeige ich hier die passenden Geräteeinstellungen:

• Will man HmIP-Geräte mit HMSERIAL ansprechen, dann müssen dessen Daten über ein extra Programm an CUxD übermittelt werden. Dies ist in der CUxD-Dokumentation im Kapitel 9 Ankopplung von HomeMatic-IP Geräten beschrieben. Oder man macht lässt den Haken weg und schibt die Daten mit einem eigenen Skript in den Datenpunkt.

In der Anwendung ist der Unterschied einfach der, das man statt
dem Kanal Diff und dem Datenpunkt Temperatur des Sonnensensors

nun Kanal 2 und den Datenpunkt Mean des CuxD-Device verwendet

In den folgenden Beispielen habe ich aber die einfache Lösung mit den Datenpunkten des Sonnensensors verwendet!

[MichaelN]

Die folgenden Programme dienen der Detektion von Sonnenschein oder Schatten (keine Sonne)

PGM Schattenerkennung

umschalten auf Schatten; zur Anpassung an die individuellen Gegebenheiten den Entscheidungswert (hier 6°C) anpassen. Auch die Zeitverzögerung kann man an den eigenen Geschmack anpassen

PGM Sonnenerkennung

umschalten auf Sonnenschein; zur Anpassung gilt das bereits gesagte

PGM Schatten bleibt Schatten

dieses Programm sorgt dafür, das nach einem kurzen Sonnenstrahl (genauer gesagt in dem durch die Zeitverzögerung im PGM Sonnenerkennung definierten Zeitfenster) wieder auf Schatten umgeschaltet wird. Je kleiner man die Temperatur wählt, desto eher verharrt das System im keine_Sonne-Status.

PGM Sonne bleibt Sonne

dieses Programm ist der Konterpart. Es sorgt dafür, das einzelne Wolken nicht zum Wechsel in den keine_Sonne-Status führen. Je kleiner die Temperatur gewählt wird, desto stabiler wird der Sonnenschein-Status.

[MichaelN]

Nun müssen für jedes Fenster / jede Himmelsrichtung (abhängig davon wie genau man steuern will) zwei Programm angelegt werden.

Rollo_Schatten_Fenster-xyz

Dieses Programm startet / gibt die Beschattung frei, wenn der Azimut-Winkel der Sonne das Fenster erreicht und Sonnenschein erkannt wird. Außerdem wird noch geprüft, ob auch Tag ist und ob das Rollo höher als die höchste (in PGM_Level) definierte Behanghöhe ist. Hat man also schon vorher das Rollo runter gefahren, dann greift die Automatik nicht mehr ein. Achtung: (beim BROLL) mit Kanal 3 die Behanghöhe prüfen, einstellen mit Kanal 4!

Bei der Definition der Aktion muss man für die Behanghöhe die anfangs definierte Systemvariable Level_Fenster_xxx festlegen. Dazu klickt man auf das kleine weiße Blatt und wählt die Systemvariable aus. (Achtung: In der FW 3.53.26 und 3.53.30 wurde diese Funktionalität entfernt. Siehe >LINK<)

Wichtig: der Winkelbereich für den Azimut endet 3° vor dem Winkel im Ende-Programm. Damit wird verhindert, das kurz vor Ablauf des Beschattungsbereichs das Rollo nochmal runter gefahren wird.

Rollo_Schatten_Fenster-xyz_Ende

Dieses Programm beendet die Beschattung, wenn der Azimut-Winkel überschritten ist. Außerdem wird noch geprüft, ob das Rollo nicht schon geöffnet ist. Wichtig ist auch, das die SV "Nacht" hier auf "nur prüfen" steht. "Bei Änderung " kann sonst dazu führen, wenn der Ende-Azimutwinkel im Winter nach dem Sonnenuntergang liegt, das sich das Rollo "nachts" wieder öffnet.

[MichaelN]

Rollo_Schatten_Tür_xyz

Türen mit Aussperrschutz bekommen wieder eine Sonderbehandlung durch die zusätzliche Abfrage des Drehgriffsensors. Für Schatten-Ende benötigt die Tür keine Extrabehandlung, da das öffnen der Rolllade immer unkritisch ist.