Programmauslösung nur bei Änderung der Systemvariable

[BurgCCU]

Was bewirkt aber die zusätzliche Zeitprüfung im Logikverlauf?

Ich bin zwar nicht der Angesprochene und habe auch den Beitrag bisher nicht gelesen, aber kann keinen Nachteil der von mir vorgestellten Lösung gegenüber der angeführten entdecken. Eher im Gegenteil.

Das Zeitmodul sorgt für eine WAHRe Bedingung, wenn durch die Aktualisierung der Systemvariable die Bedingungsprüfung des Programms getriggert wird und sorgt für die Ausführung des DANN. Gründe findest Du im WebUI-Handbuch zum Triggern und Abarbeiten von Programmen.

Das ist m.E. auch der große Nachteil der Lösung, die unverständlicherweise als Vorteil (Ausführung bei Systemstart) dargestellt wird. Dadurch wird ggf. der bestehende (veraltete) Inhalt der Systemvariable versandt. Dieser hat vielleicht schon längst vor dem Reboot für das Triggern des Programms gesorgt. Meist werden durch solche Konstrukte ja Push, Mail- oder TTS-Programme getriggert. Aber jeder wie er will.

Gruß Xel66

Sorry. Habe deine Anwort falsch gelesen und hatte die Aufgabe noch nicht auf "Aktivität SONST" hinterlegt. So läuft es und ist eine kürzere Lösung.

Danke

[[sprotte80]]

Hi

Sorry. Habe deine Anwort falsch gelesen und hatte die Aufgabe noch nicht auf "Aktivität SONST" hinterlegt. So läuft es und ist eine kürzere Lösung.

Kürzer is es ja nu auch nicht wo du doch nun nen 'Sonst' hast. Also ne zusätzliche Regel mit extra Destination Also nen unnötigen Mehrverbrauch an IDs. Is aber nich so schlimm gibt ja genug davon.

Nich wundern das das Prog halt nix ausführt wo in der WebUI von ner CCU oder in ner App das Prog von Hand gestartet wird.
Den Nachteil hat dir Xel unterschlagen.

Dafür hat er den Reboot "Nachteil" kreiert. Xel hat keinen Bezug zur Reboot-Variable wo das verhindert wo er als nachteil sieht.
Da man nich weis ob das Prog beim reboot ausgeführt werden soll oder nich ist es schon vermessen das automatisch als Nachteil zu sehen.
Xel is ja Hellseher kann sich aber nich vorstellen das es andre Einsatzmöglichkeiten gibt wo sein angeblicher nachteil ein sehr grosser vorteil is.
Er schreibt zwar immer "aber jeder wie er mag" is aber so fixiert auf seine Meinung das er keine andre gelten läst.

Thomas

[BurgCCU]

Hi

Sorry. Habe deine Anwort falsch gelesen und hatte die Aufgabe noch nicht auf "Aktivität SONST" hinterlegt. So läuft es und ist eine kürzere Lösung.

Kürzer is es ja nu auch nicht wo du doch nun nen 'Sonst' hast. Also ne zusätzliche Regel mit extra Destination Also nen unnötigen Mehrverbrauch an IDs. Is aber nich so schlimm gibt ja genug davon.

Nich wundern das das Prog halt nix ausführt wo in der WebUI von ner CCU oder in ner App das Prog von Hand gestartet wird.
Den Nachteil hat dir Xel unterschlagen.

Dafür hat er den Reboot "Nachteil" kreiert. Xel hat keinen Bezug zur Reboot-Variable wo das verhindert wo er als nachteil sieht.
Da man nich weis ob das Prog beim reboot ausgeführt werden soll oder nich ist es schon vermessen das automatisch als Nachteil zu sehen.
Xel is ja Hellseher kann sich aber nich vorstellen das es andre Einsatzmöglichkeiten gibt wo sein angeblicher nachteil ein sehr grosser vorteil is.
Er schreibt zwar immer "aber jeder wie er mag" is aber so fixiert auf seine Meinung das er keine andre gelten läst.

Thomas

Danke für deine Erklärung. Werde es testen und schauen wie es am besten passt.

[Xel66]

Probiere es aus. In Deinem Zitat sehe ich, dass auf die manuelle Ausführung eines Programms Bezug genommen wird. Das ist zwar zu Testzwecken möglich, aber im Normalbetrieb kein notwendiger und üblicher Bedienschritt. Das Programm soll ja später durch die Aktualisierung der Systemvariable getriggert werden. Und Programme muss man nicht auf mögliche Testszenarien optimieren, sondern für den automatischen und nebenwirkungsfreien Normalbetrieb.

Wenn man das getriggerte Script testen will, gibt es in dem betreffenden Editor-Fenster durchaus die Möglichkeit, das Script explizit auszuführen. Sowas muss man allenfalls während der Entwicklung des Scripts machen, danach ist der manuelle Start durchaus verzichtbar. Solch schlechten Stil pflegen allenfalls Apps, die Programme nur als Zusammenfassung von auszuführenden Aktionen verstehen, weil deren Schwerpunkt eben die manuelle Bedienung/Fernsteuerung der Geräte, aber nicht die Automation ist. Smart ist anders. Die einen legen Wert auf ein smartes Home, die anderen auf ein Smartphonehome, welches sie per Wischiwaschi fernsteuern. So hat halt jeder seine Prioritäten.

Gruß Xel66

[BurgCCU]

Probiere es aus. In Deinem Zitat sehe ich, dass auf die manuelle Ausführung eines Programms Bezug genommen wird. Das ist zwar zu Testzwecken möglich, aber im Normalbetrieb kein notwendiger und üblicher Bedienschritt. Das Programm soll ja später durch die Aktualisierung der Systemvariable getriggert werden. Und Programme muss man nicht auf mögliche Testszenarien optimieren, sondern für den automatischen und nebenwirkungsfreien Normalbetrieb.

Wenn man das getriggerte Script testen will, gibt es in dem betreffenden Editor-Fenster durchaus die Möglichkeit, das Script explizit auszuführen. Sowas muss man allenfalls während der Entwicklung des Scripts machen, danach ist der manuelle Start durchaus verzichtbar. Solch schlechten Stil pflegen allenfalls Apps, die Programme nur als Zusammenfassung von auszuführenden Aktionen verstehen, weil deren Schwerpunkt eben die manuelle Bedienung/Fernsteuerung der Geräte, aber nicht die Automation ist. Smart ist anders. Die einen legen Wert auf ein smartes Home, die anderen auf ein Smartphonehome, welches sie per Wischiwaschi fernsteuern. So hat halt jeder seine Prioritäten.

Gruß Xel66

Da hatte ich mioch wohl falsch ausgedrückt. Mit testen ist der automatisierte Betrieb und nicht die manuelle Auslösung gemeint.

[Xel66]

Da hatte ich mioch wohl falsch ausgedrückt. Mit testen ist der automatisierte Betrieb und nicht die manuelle Auslösung gemeint.

Nein, ist schon angekommen. Passt so. Ich bezog mich auf das Zitat in Deinem Beitrag (ich sehe die sonstigen Posts des Zitierten nicht ) und der unterstellten Anforderung, dass das Script auch bei manueller Ausführung des Programms über die WebUI funktionieren soll. Das geht so nicht bei Benutzung eines SONST (zumindest mit der Standardfirmware, weil dort keine Bedingungen geprüft werden). Mit der Raspberrymatic ist das kein Problem. Grundsätzlich finde ich die Umsetzung mit dem Zeitmodul als zweiter Bedingung eigentlich ganz geschmeidig, bis auf die Hervorhebung, dass das auch bei Reboot ausgeführt wird (was ich als eben wegen des möglichen veralteten Variableninhaltes nicht als zielführend finde).

Gruß Xel66