Howto - Vermeidung von Programmstarts nach Neustart der CCU

[Xel66]

Bisher bin ich damit immer super gefahren.

Damit werden aber alle Programme, die z.B. mit einem Zeitfenster progammiert sind (das wohl in fast jeder Installation vorhandene von soundsoviel Uhr bis soundsoviel Uhr - Licht an/Rollladen hoch - sonst aus/runter-Programm) nicht mehr getriggert, wenn die erste Schaltschwelle schon überschritten ist. Auch andere Programme, die den Status eines Sensors/Aktors (mit nicht zyklischer Statusübermittlung oder großer Zeitspanne dazwischen) auswerten und bestimmte Zustände hinstellen laufen ebenfalls nicht. Wovon sollen sie denn auch getriggert werden, wenn sich die Systemvariable zurückstellt?

Und auf dieses Ereignis triggern halte ich auch für keine gute Idee. Da kann noch viel größeres Chaos entstehen, wenn durch den Zustandswechsel der Reboot-Variable mal alle Programme gleichzeitig getriggert werden. Für einen normalen beaufsichtigten Reboot macht das nichts aus, weil dann ggf. die Aktoren in der Sollstellung laut ursprünglicher Programmierung stehen. Aber was ist mit einem Reboot auf Grund eines Spannungsausfalls. Da sind ggf. die Aktoren aus und die Rollladen signalisieren eine Behanghöhe von 50%. Ist jetzt eine Stellungsabfrage im Rollladenprogramm, funktioniert ggf. das nachfolgende Triggern auch nicht mehr und es kommt die Anfrage "mein Rollladenprogramm läuft nach Reboot nicht mehr, ich prüfe obe die Rollladen oben sind und will sie dann runterfahren". Ätschbätsch, sind sie für die CCU nicht. Sie stehen nach Spannungswiederkehr auf 50%.

Meines Erachtens ist der Einsatz der Variable nur in Programmen sinnvoll, die wirklich nicht abgearbeitet werden sollen (bei mir z.B. die Keymatic-Programme und die Push- und Mail-Programme, die über bestimmte Status informieren (da letztere ja sowieso erst mal hingestellt werden müssen). Ein pauschale Einfügen in "alle" Programme ist eher nicht zielführend, weil man sich da gegebenenfalls selbst ins Knie schießt. Der Hersteller hat die Funktion der Bedingungsprüfung bei Systemstart nicht umsonst eingebaut. Er hat sich wohl was dabei gedacht. Aber jeder ist für seinen selbst programmierten Pflegefall selbst verantwortlich. Jeder wie er will.

Gruß Xel66

[funzel1607]

das wohl in fast jeder Installation vorhandene von soundsoviel Uhr bis soundsoviel Uhr...

Tatsächlich nutze ich diese Funktion bisher gar nicht, weshalb es bei mir dadurch auch nicht zu den genannten Problemen kommt.
Es wird auch nicht durch die Variable "CCU Status" getriggert sondern z.B. von einer Uhrzeit. Die Variable wird dabei nur geprüft, damit der Trigger nicht nur aufgrund eines Neustarts das Programm auslöst.

Ein pauschale Einfügen in "alle" Programme ist eher nicht zielführend...

Das habe ich auch nicht behauptet. Ich nutze es nur in vielen meiner Programme, da ich, wie oben beschrieben, nicht mit Zeitspannen sondern mit Zeitpunkten arbeite. Dies erhöht zwar die Anzahl der Programme, da ich z.B. eins zum einschalten und eins zum ausschalten von einer Lampengruppe benötige, kann so aber im Fehlerfall durch logging, push etc. genauer differenzieren, was grad das Problem erzeugt.

[dtp]

Jeder wie er will.

Jepp.

Aber noch mal zur Klarstellung. Die Systemvariable "CCU SV Status" wird bei mir - außer im Reboot-Programm - immer nur geprüft. Sie dient niemals zum Triggern eines Programmes.

Hinzu kommt, dass ich nur äußerst selten das Zeitmodul der CCU zum Triggern verwende. Auch dieses dient mir überwiegend zum Überprüfen, während das Triggern von bestimmten HM-Komponenten und/oder Systemvariablen ausgeht. Einzig das Hochfahren der Rollläden zu einer festgelegten Zeit wird durch das Zeitmodul ausgelöst.

Weiterhin wird die CCU bei mir im Wesentlichen nur nach einem Firmware-Update neu gestartet. Ein Reboot nach einem Stromausfall kommt wegen einer vorhandenen USV nur vor, wenn der Strom für mehr als 45 Minuten ausfällt. Ich hatte in den zurückliegenden Jahren noch nie ein Problem nach dem Hochfahren der CCU. Nervig ist einzig, wenn sich während des Reboots Schaltzustände z.B. der Fenstersensoren ändern, die dann nicht korrekt erfasst werden können. Aber das ist nicht zu ändern, da die CCU während ihres mehrminütigen Reboots nun mal blind ist.

Ich weiß auch ehrlich gesagt gar nicht, ob ein Programm nach dem Reboot der CCU ausgelöst wird, wenn die im Zeitmodul eingestellt Auslösezeit bereits verstrichen ist. Sprich, wenn das Zeitmodul die Rollläden um, sagen wir mal, 21:00 Uhr herunterfahren soll und es findet ein Reboot zwischen 20:57 Uhr und 21:05 Uhr statt, werden dann trotzdem um 21:05 Uhr die Rollläden geschlossen?

[Xel66]

... nicht mit Zeitspannen sondern mit Zeitpunkten arbeite.

Und genau für zu einem Zeitpunkt getriggerte Programme ist ein Einfügen der Variable nicht notwendig, da diese Bedingung nicht erfüllt ist. Es sei denn, es ist zum Rebootzeitpunkt gerade genausoviel Uhr, wie im Trigger definiert. Das Programm wird schlichtweg nicht ausgeführt. Ist mir zumindest noch nicht untergekommen. Aber zugegebenermaßen boote ich äußerst selten.

Gruß Xel66

[dtp]

Und genau für zu einem Zeitpunkt getriggerte Programme ist ein Einfügen der Variable nicht notwendig, da diese Bedingung nicht erfüllt ist.

Na dann schadet sie aber im Umkehrschluss auch nicht.

[Xel66]

Na dann schadet sie aber im Umkehrschluss auch nicht.

Das nicht, aber wenn ich mir anschaue, was manche Anwender für Aufwand treiben (wollen) um z.B. Geräte- und Programmlisten überschaubar zu halten und dann wird ein nützliches Übersichts- und Sortierinstrument (zeige Programme, die ... enthalten) mit Absicht und in Unkenntnis kaputtgemacht. Noch dazu ohne jeglichen Nutzen und in machen Fällen sogar kontraproduktiv. Smart ist anders...

Gruß Xel66

[dtp]

Wir sind noch so weit von Smart entfernt.

Warum z.B. kann ich nicht einfach sagen: "Hey Siri (oder Alexa oder wie auch immer), steuere meine Rollläden so, dass sie..." oder "...sende mir eine Pushover-Nachricht, wenn die Waschmaschine fertig ist." und dann wird das automatisch in ein Programm samt ggf. notwendiger Skripte umgesetzt.

Noch besser wäre, wenn die Hausautomation lernt und mein regelmäßiges Verhalten in entsprechende Automatismen umsetzt. So in der Art: "Du hast jetzt jeden Morgen deine Rollläden zwischen 07:00 Uhr und 07:15 Uhr hochgefahren. Möchtest du das nicht lieber automatisiert haben? Wenn ja, sag mir einfach wann die Rollläden hochfahren sollen."

Übrigens, ich finde ehrlich gesagt nicht, dass die Programme durch einen Zweig-Parameter "CCU SV Reboot" unübersichtlicher werden. Insbesondere dann nicht, wenn er eh überall drin steht. Aber eigentlich wäre es längst an der Zeit, dass dieses Feature per Haken in den Programmen gesetzt werden kann. Ich verstehe nicht, warum eQ-3 das nicht implementiert. Aber wahrscheinlich, weil es auf der Prioliste ziemlich weit unten steht. Es geht ja auch so.

[Black]

jo, das stimmt, die anwählbare eigenschaft "trigger bei Kaltstart" wäre ein nette feature und auch net soooo riesig kompliziert umsetzbar.

Sollte, ähnlich wie bei den Devices mit der neuen Option "keine Servicemeldungen erzeugen" recht zügig durch einen eintrag in den metadaten umsetzbar sein.

<<-- das mit den Metadaten war übrigens der Wink mit dem zaunpfal an denjenigen, der mir trotz expliziter, konkreter Nachfrage partout nicht verraten wollte, wo diese neue Eigenschaft programmtechnisch untergebracht war.

Black

[Xel66]

Noch besser wäre, wenn die Hausautomation lernt und mein regelmäßiges Verhalten in entsprechende Automatismen umsetzt.

Was ist mit Leuten, die keinen regelmäßigen Tagesablauf haben. Schichtler und Leute mit wechselnden Diensplänen, die ggf. noch dazu kurzfristig sich ändern. Da ist das Anlegen eines Programms schon einfacher.

Möchtest du das nicht lieber automatisiert haben? Wenn ja, sag mir einfach wann die Rollläden hochfahren sollen."

Um das umzusetzen, müssten alle Daten vorgehalten und analysiert werden. Dieses in einen Kleinstrechner zu implementieren, ist vermutlich recht aufwändig. Dies extern zu machen.... Naja. Geben wir nicht schon genug preis?

Übrigens, ich finde ehrlich gesagt nicht, dass die Programme durch einen Zweig-Parameter "CCU SV Reboot" unübersichtlicher werden.

Grundsätzlich werden sie das nicht, aber ich habe mit einer Schaltfläche die Möglichkeit, die Programme aufgelistet anzusehen, die bestimmte Systemvariablen oder Geräte enthalten. Bei einer überflüssigen, unnützen und pauschalen Verteilung dieser Variable in alle Programme nehme ich mir diese Möglichkeit. Noch dazu behaupte ich mal, können gerade Einsteiger die Auswirkungen dieses Tuns nicht abschätzen, folgen den "Empfehlungen" aus dem Forum und wundern sich am Ende, warum das System so krude Zustände hinstellt, die mit der Programmierung nichts zu tun haben oder warum Programme nicht mehr abgearbeitet werden.

Beispiel: Ein Programm, welches die Rollladen in der Zeit zwischen X und Y hochfährt, würde das bei einem spannungsausfallbedingten Systemstart im Zeitbereich dazwischen automatisch tun. So ist es zumindest vom Hersteller angelegt (alle Bedingungsprüfungen laufen beim Systemstart). Unterbinde ich dieses, stehen die Rollladen nach einem spannungsausfallbedingten Neustart des Systems ggf. elektronisch auf 50% (Startwert nach Spannungswiederkehr), egal, wie dies reale Behanghöhe ist. Jedes Programm, welches nun diese Behanghöhen auswertet geht nun von falschen Zuständen aus (z.B. ein Programm, welches abends die Rollladen runterfahren soll und eine Behanghöhe auf "oben" prüft) und wird nun entweder gar nicht oder falsch getriggert..

Insbesondere dann nicht, wenn er eh überall drin steht.

Genau das ist das Problem.

Aber eigentlich wäre es längst an der Zeit, dass dieses Feature per Haken in den Programmen gesetzt werden kann.

Aus oben angeführten Gründen ist das kontraproduktiv und das automatisierte Triggern druch den Hersteller vermutlich absichtlich eingebaut, um kosistente Zustände zu haben. Warum sollte er eine mit Absicht einegebaute Funktion so auf's Kreuz legen?

Wenn man das unbedingt braucht, dann baut man sich das in Programme ein, die man nicht so anlegen kann, dass sie nicht automatisch laufen und bei allen anderen Programmen ist es eben nicht zielführend und/oder notwendig.

Gruß Xel66

[dtp]

Es geht hier doch einzig darum, den automatischen Start von Programmen unmittelbar nach bzw. mit dem Neustart der CCU zu unterbinden. In aus meiner Sicht weit über 90 % aller Fälle ist das durchaus sinnvoll. Bei den restlichen 10 % mag es dagegen sinnvoll sein, dass sie getriggert werden, wenn die CCU einen Neustart durchführt.

Ich kann Dein Szenario mit den Rollläden ehrlich gesagt nicht ganz nachvollziehen. Erstens wird eine CCU relativ selten neu gestartet (zumindest sollte sie das) und zweitens kommt es noch seltener vor, dass ausgerechnet unmittelbar nach dem Neustart ein Programm zum Steuern von Aktoren ausgeführt werden muss. Die CCU braucht einige Minuten (teilweise bis zu 10), bis sie einen Neustart durchgeführt hat. In dieser Zeit ist das gesamte System tot, so dass z.B. Zustandsänderungen von Sensoren nicht erfasst werden können. Alleine dadurch entstehen schon Inkonsistenzen im System, die erst mit erneuter Erfassung eines Sensorzustands bereinigt werden können.

Hinzu kommt, dass hier sehr viele User davon berichtet haben, dass ihre CCU sich nach einem Neustart seltsam verhält und Dinge macht, mit denen sie nicht gerechnet hatten. Warum sollte also eQ-3 nicht zumindest eine Option zum Sperren von Programm-Zweigen unmittelbar nach einem Neustart der CCU implementieren? Schließlich gibt es ja auch die Option, in jedem Programmzweig die laufenden Zeitverzögerungen zu beenden. Und ich wette, dass über 90 % aller User da noch nie einen Haken gesetzt haben.