Reboot mit System und Ablauflogik

[BadenPower]

Das "Problem" aufgrund dessen ich mir diese Methode ausgedacht habe, liegt darin, dass nach einem Neustart/Stromausfall die Werte von Sensoren nicht mehr vorhanden sind auch die Systemvariablen-Werte, entsprechen nicht mehr den momentan herrschenden Zustände. Oder Schaltungen, welche verzögert ausgeführt werden sind nicht mehr vorhanden, wenn zwischen dem Setzen und der Ausführung der verzögerten Aktion der Strom ausfällt.

Daher bilde ich auch alle relevaten Sensodaten als Systemvariablen ab und zwar nicht 1:1, sondern mit einem zusätzlichen "Initialisierungswert". Ein abgebildeter Tür-Kontakt ist dann nicht Logik, sondern eine WerteListe aus "unbekannt;geschlossen;offen". Beim Start der CCU wird dann der "Sensor" auf "unbekannt" gesetzt. Somit wird verhindert, dass Aktionen ausgeführt werden, welche gar nicht stattfinden hätten dürfen.

Nehmen wir einen Rollo / Jalousie, welcher zu einer bestimmten Uhrzeit automatisch herunterfährt, aber nur wenn das Fenster geschlossen ist, um Schäden zu vermeiden.

So, jetzt ist das Fenster offen / gekippt und der Strom fällt aus. Die CCU fährt nach Spannungswiederkehr hoch und die Sensordaten sagen daher nicht, dass das Fenster geöffnet ist. Jetzt löst das Programm zum Schließen der Rollos aus. Bingo.

Eines der zahlreichen Beispiele.

Du solltest Deine Signatur anpassen.

Angepasst.

[nimmnenkeks]

Daher bilde ich auch alle relevaten Sensodaten als Systemvariablen ab und zwar nicht 1:1, sondern mit einem zusätzlichen "Initialisierungswert". Ein abgebildeter Tür-Kontakt ist dann nicht Logik, sondern eine WerteListe aus "unbekannt;geschlossen;offen". Beim Start der CCU wird dann der "Sensor" auf "unbekannt" gesetzt. Somit wird verhindert, dass Aktionen ausgeführt werden, welche gar nicht stattfinden hätten dürfen.

Nehmen wir einen Rollo / Jalousie, welcher zu einer bestimmten Uhrzeit automatisch herunterfährt, aber nur wenn das Fenster geschlossen ist, um Schäden zu vermeiden.

So, jetzt ist das Fenster offen / gekippt und der Strom fällt aus. Die CCU fährt nach Spannungswiederkehr hoch und die Sensordaten sagen daher nicht, dass das Fenster geöffnet ist. Jetzt löst das Programm zum Schließen der Rollos aus. Bingo.

Eines der zahlreichen Beispiele.

Die Abbildung der Sensordaten und Modi (z.B Beschattung, Tagesmodus, u.v.m.) hatte ich bisher auch immer versucht in SysVars abzubilden, jedoch fast immer mit Typ Logik, was wiederum zur weiteren "Verschachtelung" oder weiterer Programme (um den Zustand WENN zu prüfen) geführt hat.

Hoffe ich habe jetzt keinen Denkfehler, aber
Statt beispielsweise 2 SysVars Logik anzulegen

- "Rollladen-x_Lueften_AN-AUS"
- "Rollladen-x_Lueften_Tag-Nacht"

reicht ja dann 1 SysVar Werteliste
"Rollladen-x_Lueften"

mit den Werten:
- unbekannt (Initialisierung)
- Lueften-Tag_AN (tagsüber)
- Lueften_Tag_AUS (tagsüber)
- Lueften_Nacht_AN (in der Nacht)
- Lueften_Nacht_AUS (in der Nacht)
- ...

was natürlich um weitere Bedingungen (z.B. Hitzeschutz-Tag/Nacht, Lueften_Durchzug, u.v.m.) erweiterbar ist, jedoch nur 1 SysVar benötigt

Ich finde diesen Beitrag sehr interessant (gerade der konzeptionelle Aufbau), aber bei Betrachtung der Programme und Erlärungen dazu, stellt sich für mich die Frage, was das für ein Aufwand war (und wie viele Konzepte man bis dahin über den Haufen geworfen hat, da man merkt... das passt doch nicht so richtig ).

Mag für die "alten Hasen" hier Mumpiz sein, für einen Anfänger toller Input um die eigene Konzeptionierung umzusetzen.


BG Keks

[nimmnenkeks]

Hatte endlich mal Zeit, das ganze "zu verstehen" und mal ein paar Versuche zu starten.

Läuft ab Neustart wesentlich besser, als die bisherige bekannte Version (an die man als Frischling meist zuerst hängen bleibt)

Auch die Deine Methode der Programmauslösung finde ich sehr spannend!
K.A. ob ich jetzt einen Denkfehler habe, aber so sollte es doch die Rollladensteuerung im Prinzip in einem Programm ermöglichen (ok. wird ellenlang ), vorrausgesetzt alle Auslöser sind enthalten (Fenstergriffstellung, Positions/Behangdefinitionen;Tag-Nachtmodus, Beschattung uvm.).
Das würde die Anzahl der Fitzelprogramme doch erheblich verkeleinern.

In dem Programm
download/file.php?id=42903&mode=view

beschreibst Du, dass Du die Weckzeiten über ein Skript setzt.
Ist es da ehemalige "Timer/Wecker-Skript", weches mit der Firmware 2.27.28 noch lief und als Skript "!Rollo Trigger...." setzen läuft?
Nutzt Du da mehrere Versionen von?

Bsp. wäre es ja nützlich eine Werteliste "Trigger-Nachtruhe" zu nehmen, um die Nachtruheberechnung (früh oder spät) zu setzen.
Mit Deinem Kalenderskript kann man das ja hervorragend umsetzen und wenn "spät" rauskommt setzt man der Wert auf 23:00 Uhr und führt dann das Skript "Nachtruhe setzen (anderer Name, andere SysVar)" aus um den Trigger zu setzen???

Da ich ebenfalls Sonnendämmerungszeiten aus einer CSV auf der CCU auslese und täglich in die beiden SysVars schreibe (basierend auf dem Timerskript), gibt es da Beschränkungen zu der Anzahl der zu setzenden Trigger?

Wie wäre die zu empfehlende Vorgehensweise?
Einen Trigger-SysVars mit etlichen Werten, oder mehrere SysVars mit weniger Werten und entsprechenden Skriptaufrufen dazu?

Bsp
Weckzeiten 05:45:00;06:00:00
Tagesprogrammbeginn 05:00:00;05:15:00
Nahchtruhe 22:00:00;22:15;00;22:30:00;22:45:00;23:00
usw.

oder überschreiben diese sich gegenseitig?

Sind Pausen dazwischen angesagt, oder kann ich diese Skripte in den Reboot-Reihenfolge z.b. in CCU-Reboot-03 (VT03 Lang) hintereinander ausführen.

Da ich ja noch die 2.27.8 nutze, könnte ich ja auch im Prinzip Dein Backup-Skript nutzen, um "vor Editierung/Neuanlage" von Programmen alle Programme wegzuschreiben. Für den Fall dass die UI mal wieder spinnt und ein Programm mit doppeltem Namen vergibt und ein anders "flöten geht"
Dazu nutze ich die von Die angegebene Vorgehensweise mit den Programmlisten (über den den HM-Investigator 0.1.6).
Aber vom Prinzip sollte dass doch passen "VT für Backup der Programme und falls etwas schief geht, "mal eben" Programm wieder hergestellt.

BG
Keks