Rollladen Steuerung

[Xel66]

indem man bei einem Reboot die vor dem Stromausfall gespeicherten Rollladenwerte aufruft und prüft, ob sie noch im eingestellten Zeitfenster liegen.

Wenn man mit dem Zeitmodul die Steuerzeiten als Zeitbereich eingibt (z.B. von 22:00 bis 06:00 Uhr oder nachts oder eine Kombination daraus), dann wird bei einem Reboot zu späterer Zeit dieser Zeitbereich von Haus aus bei einem Reboot geprüft und er entsprechende Sollzustand hergestellt. Das kann das System also von ganz allein, weil der Hersteller es so vorgesehen hat. Allerding wird dieser Automatismus auf Grund der "Empfehlung aus dem Forum" mit dem Anwesenheitsvariablenworkaround vorsätzlich durch die Nutzer kaputt gemacht, weil sie ihre Programme nicht dementsprechend anlegen und stattdessen lieber den häufig vorgetragenen (und aus diesem Grunde als "richtig" empfundenen) Empfehlungen aus dem Forum folgen (siehe auch Screenshot oben).

Gruß Xel66

[dtp]

Viele Wege führen bekanntlich nach Rom. Man muss nur wissen, wie man sie zu gehen hat.

Ich habe nie behauptet, dass meine Umsetzung die einzig wahre ist. Was ich aber behaupten kann, ist, dass sie funktioniert. Nichts anderes sollte meine obige Aussage beinhalten.

Ich komme z.B. mit insgesamt sechs Programmen für die gesamte Rollladen-Steuerung aus. Und das beinhaltet nicht nur das tägliche Rauf- und Runterfahren der Rollläden am Morgen und bei Dunkelheit, sondern auch die Hitzesteuerung und das nachträglich automatische Fahren der Rollläden in ihre Sollposition beim Betätigen von Fenstern und Türen innerhalb eines definierbaren Zeitfensters.

Beispiel: Jeden Abend schließen die Rollläden automatisch, wenn die Helligkeit des Außenbewegungsmelders auf der Terrasse einen bestimmten Schwellwert unterschreitet. Ist dabei z.B. die Terrassentür geöffnet, wird der Rollladen nicht oder nur minimal heruntergefahren, sofern er nicht eh schon eine Behanghöhe aufweist, die unter dem Sollwert liegt. Liegt sie darunter, passiert hier nichts. Wenn nun jemand innerhalb von 20 Minuten nach dem automatischen Schließen der Rollläden die Tür schließt oder kippt, wird der Rollladen automatisch mit dem Betätigen der Tür in die Sollposition für die geschlossene oder gekippte Tür gefahren. Wird die Tür innerhalb dieses Zeitfensters wieder geöffnet, dann wird der Rollladen wieder in die Sollposition für eine geöffnete Tür gefahren. Das kann man beliebig wiederholen, bis das Zeitfenster abgelaufen ist, und zwar für sämtliche Rollläden des Hauses bzw. für die, die man auf diese Weise angesteuert hat. Bei einem Schließen der Rollläden aufgrund von erwarteter Hitze passiert übrigens das gleiche. Ergänzend ist es zudem möglich, die mechanische Betätigung eines bestimmten Rollladens zu blockieren, wenn man z.B. Angst hat, dass ein Hund oder ein kleines Kind den Rollladen betätigen könnte.

Diesen Automatismus kann man nun mit einem einzigen simplen Programm darauf erweitern, dass Entsprechendes auch nach einem Neustart der CCU erfolgt. Nur darauf wollte ich hinweisen.

Bis dann,

Thorsten

[Xel66]

Ich habe nie behauptet, dass meine Umsetzung die einzig wahre ist.

Und ich habe nicht behauptet, dass dieses nicht so wäre. Mein Zitat bezog sich einzig und allein auf die Methode "Abspeichern irgendwelcher Zustände und Wiederaufruf nach Reboot". Und gerade das ist nicht notwendig, wenn man eine Steuerung nach obigem Beispiel aufbaut und den vom Hersteller vorgesehenen Automatismus zur Bedingungsprüfung angelegter Programme beim Systemstart NICHT durch den genannten Anwesenheitsvariablen-Workaround unterbindet.

Dann stellt das System automatisch den für den aktuellen Zeitraum programmierten Zustand her. Das war die beabsichtigte Aussage. Nicht mehr und nicht weniger, denn ich bin eben kein Freund von einem globalen und nicht hinterfragten Einsatz dieses Workarounds. Leider lesen sich die entsprechenden Threads zu dem Thema hier im Forum anders und es wird die falsche Meinung verbreitet, dass alle Programme beim Boot gestartet werden. Auch wenn es in manchen Fällen so aussehen mag, dem ist aber nicht so, sondern die Funktion folgt dem oben dargelegten Grundsatz.

Gruß Xel66

[manfredh]

...es wird die falsche Meinung verbreitet, dass alle Programme beim Boot gestartet werden...

Ich dachte immer, es wäre so.

Und dass dann natürlich eine ganz normale Bedingungsprüfung stattfindet und je nach Ergebnis ein "Dann" ausgeführt wird oder nicht.

[dtp]

Wenn man mit dem Zeitmodul die Steuerzeiten als Zeitbereich eingibt (z.B. von 22:00 bis 06:00 Uhr oder nachts oder eine Kombination daraus), dann wird bei einem Reboot zu späterer Zeit dieser Zeitbereich von Haus aus bei einem Reboot geprüft und er entsprechende Sollzustand hergestellt.

Letztlich ist auch dies eine Zusatzbedingung, die verhindern soll, dass ein Programmzweig nach einem Reboot der CCU3 ausgeführt werden soll. Ich persönlich fände es besser, wenn eQ-3 das grundsätzlich ausschließen würde und man die Ausführung eines Programmzweiges nach dem Neustart der CCU mit dem expliziten Setzen eines Hakens analog dem Beenden aller laufenden Verzögerungen aktivieren müsste.

[Xel66]

Und dass dann natürlich eine ganz normale Bedingungsprüfung stattfindet ...

Nicht "Und", sondern NUR. Es wird lediglich eine Bedingungsprüfung durchgeführt bei der auch der Zeitstempel aktualisiert wird. Programme, bei denen keine Prüfung durchgeführt wurde, weil kein "gültiger" Trigger (Systemvariable nicht gesetzt beim Start, oder Status eines Aktors nicht abgefragt/übermittelt etc.) enthalten ist, erhalten auch keinen Zeitstempel. Würden alle Programme, wie es häufig zu lesen ist, bei Systemstart getriggert, hätten auch alle Programme den Zeitstempel des Systemstarts. Dem ist aber nicht so.

Ich persönlich fände es besser, wenn eQ-3 das grundsätzlich ausschließen würde und man die Ausführung eines Programmzweiges nach dem Neustart der CCU mit dem expliziten Setzen eines Hakens analog dem Beenden aller laufenden Verzögerungen aktivieren müsste.

Andersrum wird ein Schuh draus. Grundsätzlich gehört dieses (wie mehrfach dargelegt) aktiviert und ausschließlich und explizit für Programme, die definitiv nicht getriggert werden sollen, könnte sich das ausschließen lassen. Also der Status-Quo wie mit dem Workaround, nur dass man die Systemvariable nicht einfügen müsste. Unterlässt man die Seuche mit dem SONST, dann gibt es auch wenig Grund, diesen Workaround einzusetzen, da sich Programme durchaus so anlegen lassen, damit keine unerwünschten Aktionen beim Systemstart ausgeführt werden (und sei es durch eine simple Satusabfrage vor der Ausführung). Analog zu meinem Beispiel mit dem Zeitbereich zur Rollladensteuerung könnte man auch noch die Iststellung abfragen und so das Aussenden von Befehlen, die nur den aktuellen Status beinhalten, verhindern. Beispiel:

Code: Alles auswählen

WENN Zeitmodul täglich 06:00 Uhr bis 22:00 Uhr zu Zeitpunkten auslösen
UND Rollladen Behanghöhe gleich 0% nur prüfen
DANN Rollladen Behanghöhe 100%
SONST WENN Zeitmodul täglich 22:00 Uhr bis 06:00 Uhr zu Zeitpunkten auslösen (nur prüfen reicht auch)
UND Rollladen Behanghöhe >0%
DANN Rollladen Behanghöhe 0%

Dieses simple Programm würde bei einem Systemstart zwischen 06:00 Uhr und 22:00 Uhr einen Hoch-Befehl nur senden, wenn der Rollladen nicht oben ist und vice versa. Setzt man ein SONST ein, müsste man bei einem Systemstart außerhalb der angegebenen Zeit mit einem unnützen Runter-Befehl leben (weil ja ggf. die Rollladen schon unten sind). Lässt man die Prüfungsabfrage der Behanghöhe weg, und die Rollladen stehen schon in Soll-Stellung, werden die Befehle ausgesendet, was aber nichts an der Stellung ändern würde.

Aber in jedem Falle steht nach dem Reboot der Zentrale der Rollladen in dem für diesen Zeitbereich laut Programm vorgesehen Soll-Zustand. Und genau um dieses zu erreichen, werden die Bedingungsprüfungen bei Systemstart durchgeführt. Eine unbedachte Benutzung der glücklicherweise nicht vorhandenen Funktion (gemäß der dann definitiv auftauchenden, aber falschen Empfehlungen aus dem Forum) würden diesen nützlichen Automatismus zunichte machen. Dieses ist nur ein Beispiel, was aber auch auf andere Anwendungszweige mit einem externen Trigger (Stausabfragen etc.) übertragen werden kann.

Gruß Xel66

[manfredh]

Und dass dann natürlich eine ganz normale Bedingungsprüfung stattfindet ...

Nicht "Und", sondern NUR. Es wird lediglich eine Bedingungsprüfung durchgeführt...

...und bei einem wahren Block entsprechend reagiert?!

Okay, die Programme werden ncht getriggert, sondern nur die Bedingungen geprüft und ggfls. ein Dann ausgeführt.

Aber ist das im Ergebnis nicht das gleiche, als ob die Programme getriggert würden?

Und ist dann unsere Diskussion nicht ein wenig Spitzfindig?

[Xel66]

Du hast es immer noch nicht richtig verstanden. Es wird eben nicht jedes Programm "gestartet". Das macht eben den Unterschied, warum bei einigen Programmen der Zeitstempel gesetzt wird und bei anderen nicht. Der Zeitstempel kann im Grunde erst mal egal sein. Wichtig ist aber zu verstehen, warum bestimmte Aktionen ausgeführt werden und andere eben nicht.

Und SONST-Aktionen werden nun mal ausgeführt, wenn keiner der in einem Programm enthaltenen Bedingungen ein WAHR ergibt. Und das eben unabhängig davon, ob jetzt einer der Trigger angesprochen hat oder nicht. Das ist der elementare Unterschied. Und darum ist z.B. die Benutzung des Workarounds mit der Anweseheitsvariable in Programmen mit einem SONST. Programme mit einen SONST erhalten beim Boot einen Zeitstempel, solche mit einem Zeitmodul und einem Zeitpunkt als Trigger gehalten keinen, da der Zeitpunkt nicht geprüft werden muss. Ebenso werden durch Taster getriggert Programme nicht geprüft, welche, die durch Bewegungsmelder getriggert werden uswusf.

In solchen Programmen die Systemvariable einzusetzen, ist schlichtweg überflüssig. Und das macht eben den Unterschied.

Gruß Xel66

[dtp]

Sag ich doch auch. Vergesst die Sonst-Zweige und definiert stattdessen für jeden Sonst-Wenn-Zweig klare Bedingungen.

Der Unterschied zwischen unserem Vorgehen liegt lediglich darin, dass ich grundsätzlich keine Programme bzw. Programmzweige bei einem Neustart der CCU ausführen möchte (außer dem Reboot-Programm natürlich).

[roe1974]

Also ich kann der Aussage von @Xel66 nicht zustimmen ... das entspricht auch nicht meinen Erfahrungen ... die aktiven Programme werden alle gestartet ...
Eine Info zu dem Thema habe ich auch hier im FHEM Forum von Badenpower gefunden:

https://forum.fhem.de/index.php/topic,1 ... #msg964569