Howto - Vermeidung von Programmstarts nach Neustart der CCU

[debianatoe]

Ich habe zum Thema Reboot noch eine andere Frage. Es wurde hier schon mehrfach diskutiert, daß die Geräte, insbesondere die batteriebetriebenen, nach dem Neustart einen undefinierten Status haben und man dieses Manko lindern könnte, indem man den Status in Systemvariablen sichert, deren Inhalt bei einem ordnungsgemäßen Reboot erhalten bleibt. Nun gibt es ja auch das schöne Addon CUXD, mit dem sich virtuelle Geräte erstellen lassen. Ich nutze diese z.B. zur automatisierten Ermittung statistischer Daten (MAX, MIN, Durchschnitt), mußte aber feststellen, daß die CUX-Geräte leider genauso ihre Daten vergessen wie die realen Geräte in der CCU. Wäre es nicht möglich bzw. sinnvoll, wenn wenigstens die virtuellen CUX-Geräte ein Gedächtnis über den Reboot hinaus hätten? Momentan sehe ich als einzigen Ausweg, daß man die statistischen Daten über eigene Programme mit Hilfe von Systemvariablen berechnet. Wie ist da Eure Meinung zu?

[robbi77]

nach dem Neustart einen undefinierten Status haben

Stimmt ja so eigentlich nicht …
Die alten TFKs haben nach einem Neustart immer den Zustand geschlossen, und dieser ist immer so definiert. Nur mit dem unterschied das er nicht dem realen Zustand entspricht, wenn das Fenster während dem Neustart geöffnet war.

[debianatoe]

nach dem Neustart einen undefinierten Status haben

Stimmt ja so eigentlich nicht …
Die alten TFKs haben nach einem Neustart immer den Zustand geschlossen, und dieser ist immer so definiert. Nur mit dem unterschied das er nicht dem realen Zustand entspricht, wenn das Fenster während dem Neustart geöffnet war.

Vielen Dank für die Präzisierung und Richtigstellung! Am Problem ändert das allerdings nicht viel und es gibt ja auch noch andere batteriebetriebene Geräte neben den TFKs.

[Roland M.]

Hallo!

Es wurde hier schon mehrfach diskutiert, daß die Geräte, insbesondere die batteriebetriebenen, nach dem Neustart einen undefinierten Status haben und man dieses Manko lindern könnte, indem man den Status in Systemvariablen sichert, deren Inhalt bei einem ordnungsgemäßen Reboot erhalten bleibt.

Meine Meinung ist, dass man sich über diese Eigenschaft im Bewussten sein sollte, ich für meine Person mache aber keine Klimmzüge über Systemvariablem.
Der Grund ist einfach: Während eines Neustarts der CCU, der ja auch ein paar Minuten dauert, kann so manch ein Fenster geöffnet oder geschlossen werden. Somit wäre auch der alte Zustand wieder falsch. Und zweiter Punkt: wenn man ein Miniprogramm "WENN Fenster auf DANN SV=wahr SONST SV=falsch" auf Änderung auslösen lässt, dann ändert sich der Zustand ja beim Neustart auch und die SV wird erst mit dem falschen Wert überschrieben.
Die einzige Abhilfe, die mir einfällt, wäre, der SV neben "offen" und "geschlossen" auch noch einen Zustand "unbekannt" zu geben und beim Neustart die SV auf "unbekannt" zu setzen. Somit wäre bis zum ersten eigenen Lebenszeichen des Sensors zumindest klar, dass der Status nicht vertrauenswürdig ist.


Roland

[debianatoe]

Meine Meinung ist, dass man sich über diese Eigenschaft im Bewussten sein sollte, ich für meine Person mache aber keine Klimmzüge über Systemvariablem.
Der Grund ist einfach: Während eines Neustarts der CCU, der ja auch ein paar Minuten dauert, kann so manch ein Fenster geöffnet oder geschlossen werden. Somit wäre auch der alte Zustand wieder falsch. Und zweiter Punkt: wenn man ein Miniprogramm "WENN Fenster auf DANN SV=wahr SONST SV=falsch" auf Änderung auslösen lässt, dann ändert sich der Zustand ja beim Neustart auch und die SV wird erst mit dem falschen Wert überschrieben.
Die einzige Abhilfe, die mir einfällt, wäre, der SV neben "offen" und "geschlossen" auch noch einen Zustand "unbekannt" zu geben und beim Neustart die SV auf "unbekannt" zu setzen. Somit wäre bis zum ersten eigenen Lebenszeichen des Sensors zumindest klar, dass der Status nicht vertrauenswürdig ist.

Für die Fenster sehe ich das genauso. Mir geht es hier aber mehr um die Statistiken von Meßgeräten. Da ist es verkraftbar, wenn man während des Reboots einen Ausfall der Meßwerte für ca. 10min hat. Aber es ist ärgerlich, wenn durch den Reboot um 22h abends die gesamte Tagesstatistik gelöscht wird. Und genau das passiert aktuell bei den 90er CUX-Geräten. Um das zu vermeiden, nutze ich das "Gedächtnis" der Systemvariablen.

[Xel66]

Kann man machen, wird aber relativ wenig nützen. Du verkomplizierst massiv das gesamte Systemsetup. Damit Du eine Zustand speichern kannst musst Du ja diese Systemvariable bei jeder Statusänderung mitführen. Dann musst Du auch noch dafür sorgen, daß dieser gespeicherte Staus (Systemvariable) persistiert wird (Sicherung der regadom), um auch bei einem unvorhergesehen Systemstart (Spannungsausfall) einen validen Status zu haben.

Dein Problem ist jetzt zusätzlich, dass dieser Default-Status auch beim Reboot gesetzt wird, also praktisch auch das gleiche Speicherprogramm triggert. Das Programm musst Du dann auch noch zusätzlich gegen eine Statusänderung bei Reboot sichern. Und das ganze Konstrukt kann noch zusätzlich durch das manchmal übliche Abschalten der zyklischen Statusmeldungen verkompliziert werden. Und den ganzen Spaß darfst Du dann sowohl für alle batteriebetriebenen Geräte, CUxD-Geräte und alle HmIP-Geräte machen (letztere werden auch beim Systemstart nicht abgefragt).

In meinen Augen ist es dagegen einfacher, solche Unwägbarkeiten bei der eigenen Programmierung zu berücksichtigen und etwas fehlertolerant seine Programme zu designen. Ein Beispiel aus meiner Programmierung: Wenn ich die Keymatic zum Verschließen des Hauses beim Verlassen aktiviere, bekommt sie als ersten Befehl den in der CCU gespeicherten Status und danach erst mit Verzögerung den eigentlichen Schließbefehl. So fange ich auch eventuelle mechanische Stellungsänderung durch Schlüsselbenutzung oder Drehen am Handrad ab (diese Maßnahmeverhindert auch ein "auf Block fahren" der Keymatic). Eine andere Fehlertoleranz ist, Programme nicht auf Defaultwerte von Sensoren zu triggern (reine Temperatursensoren werden z.B. auf 0°C gesetzt). Beispiel aus meiner Programmierung: ich triggere die Systemvariable "Heizperiode" nicht allein auf einen Sensorwert, sondern werte zusätzlich die Tiefsttemperatur des vorhergegangenen Tages aus.

Ich bin nicht grundsätzlich gegen diesen Workaround aus diesem Thread und benutze ihn auch zum Unterdrücken von Push-/Mailmeldungen beim Systemstart durch das Setzen von Defaultwerten oder Statusabfragen. Auch mein Keymatic-Programm habe ich damit gesichert. Aber ich finde es sinnfrei, ihn in jedes Programm einzubauen, ohne wirklich begriffen zu haben, wie das Teil wirkt und warum. Und jemand, der den Workaround in Programmen mit einem SONST einsetzt, hat die Wirkungsweise nicht begriffen. Just my2ct.

Gruß Xel66

[debianatoe]

Kann man machen, wird aber relativ wenig nützen. Du verkomplizierst massiv das gesamte Systemsetup.

So negativ würde ich das nicht sehen. Ja, es wird komplizierter und ich bin für eine einfachere Alternative offen.

Damit Du eine Zustand speichern kannst musst Du ja diese Systemvariable bei jeder Statusänderung mitführen.

Das ist richtig und wird natürlich die Grundlast der CCU etwas erhöhen.

Dann musst Du auch noch dafür sorgen, daß dieser gespeicherte Staus (Systemvariable) persistiert wird (Sicherung der regadom), um auch bei einem unvorhergesehen Systemstart (Spannungsausfall) einen validen Status zu haben.

Diese Maßnahme würde aus meiner Sicht über das Ziel hinausschießen. Ich habe trotz Energiewende deutlich mehr geplante Reboots als Stromausfälle. Sollte sich das in Zukunft ändern, könnte man über eine USV nachdenken. Stand heute würde ich die seltenen Stromausfälle in Kauf nehmen.

Dein Problem ist jetzt zusätzlich, dass dieser Default-Status auch beim Reboot gesetzt wird, also praktisch auch das gleiche Speicherprogramm triggert. Das Programm musst Du dann auch noch zusätzlich gegen eine Statusänderung bei Reboot sichern.

Danke für den Tip! Das werde ich tun.

Und das ganze Konstrukt kann noch zusätzlich durch das manchmal übliche Abschalten der zyklischen Statusmeldungen verkompliziert werden.

Diesen Hinweis verstehe ich nicht. Kannst Du das bitte genauer erläutern, wodurch das Abschalten der zyklischen Statusmeldung zu einem Problem werden könnte?

Und den ganzen Spaß darfst Du dann sowohl für alle batteriebetriebenen Geräte, CUxD-Geräte und alle HmIP-Geräte machen (letztere werden auch beim Systemstart nicht abgefragt).

Nein, das werde ich nicht tun, weil das übertrieben wäre. Ich werde den Aufwand nur für die Geräte betreiben, bei denen mir die Statistik wichtig ist. Ich werde das auch erst einmal nur mit einem Gerät testen. Bei den meisten Geräten ist die Statistik nicht so wichtig, daß sich der Aufwand lohnen würde. Zumindest ist das meine persönliche Einschätzung, aber das kann natürlich jeder machen, wie er mag.

In meinen Augen ist es dagegen einfacher, solche Unwägbarkeiten bei der eigenen Programmierung zu berücksichtigen und etwas fehlertolerant seine Programme zu designen. Ein Beispiel aus meiner Programmierung: Wenn ich die Keymatic zum Verschließen des Hauses beim Verlassen aktiviere, bekommt sie als ersten Befehl den in der CCU gespeicherten Status und danach erst mit Verzögerung den eigentlichen Schließbefehl. So fange ich auch eventuelle mechanische Stellungsänderung durch Schlüsselbenutzung oder Drehen am Handrad ab (diese Maßnahmeverhindert auch ein "auf Block fahren" der Keymatic). Eine andere Fehlertoleranz ist, Programme nicht auf Defaultwerte von Sensoren zu triggern (reine Temperatursensoren werden z.B. auf 0°C gesetzt). Beispiel aus meiner Programmierung: ich triggere die Systemvariable "Heizperiode" nicht allein auf einen Sensorwert, sondern werte zusätzlich die Tiefsttemperatur des vorhergegangenen Tages aus.

Vielen Dank für Deine Tips! Bei der Programmierung hat man meist nur den laufenden Betrieb vor Augen. Und Du hast vollkommen recht, daß man eigentlich auch den Fall des Neustarts in den Programmen berücksichtigen müßte. Ich werde das beherzigen und meine Programme mal diesbezüglich überarbeiten. Es ist allerdings schon Spezialwissen, daß TFKs beim Neustart geschlossen und reine Temperatursensoren auf 0°C gesetzt werden. Man müßte ja für jedes Gerät wissen, was die CCU beim Neustart für einen Default-Wert annimmt. Gibt es dazu eine Doku? Oder muß man sich das mühsam selbst erarbeiten? Konkret würde mich interessieren, was für ein Default-Status beim Wassermelder HmIP-SWD angenommen wird, denn der meldet mir bei jedem Neustart eine eingebildete Überschwemmung.
Ich habe z.B. ein Frostwarnprogramm, das um so aktiver wird, je näher sich die Temperatur 0°C nähert. Wenn beim Neustart grundsätzlich erst einmal 0°C gemeldet werden, brauche ich mich also nicht zu wundern, daß es zu Fehlaktivitäten kommt. Wie wäre in diesem Fall Dein Programmiervorschlag? Ich denke, daß der Workaround von Seite 1 in diesem Fall das Einfachste wäre.

Ich bin nicht grundsätzlich gegen diesen Workaround aus diesem Thread und benutze ihn auch zum Unterdrücken von Push-/Mailmeldungen beim Systemstart durch das Setzen von Defaultwerten oder Statusabfragen.

Und genau dafür würde ich das auch einsetzen wollen.

Auch mein Keymatic-Programm habe ich damit gesichert. Aber ich finde es sinnfrei, ihn in jedes Programm einzubauen, ohne wirklich begriffen zu haben, wie das Teil wirkt und warum. Und jemand, der den Workaround in Programmen mit einem SONST einsetzt, hat die Wirkungsweise nicht begriffen. Just my2ct.

Das sehe ich genauso. Natürlich werde ich diesen Workaround nur in die Programme einbauen, in denen es nötig ist. Und das sind bei mir sicherlich nur wenige.

[robbi77]

Man müßte ja für jedes Gerät wissen, was die CCU beim Neustart für einen Default-Wert annimmt. Gibt es dazu eine Doku? Oder muß man sich das mühsam selbst erarbeiten? Konkret würde mich interessieren, was für ein Default-Status beim Wassermelder HmIP-SWD angenommen wird, denn der meldet mir bei jedem Neustart eine eingebildete Überschwemmung.

Einmal Neustarten und in der Webui die Zustände ansehen …
Für den Wassermelder weißt du es ja schon …

[debianatoe]

Selbst einmal kurz ausprobieren?
Original-"Anwesenheit" umbenennen, neue SV "Anwesenheit" anlegen, testen.
Minimaler Aufwand und mit gleich wenig Aufwand reversibel.

So: ich habe den Test durchgeführt und die Original-"Anwesenheit" umbenannt. Nach ein paar Minuten war eine neue SV "Anwesenheit" vorhanden, d.h. HM-pdetect legt diese SV offenbar automatisch wieder an, wenn keine mehr da ist. Weitere Folgen muß ich jetzt beobachten.

[Xel66]

Kannst Du das bitte genauer erläutern, wodurch das Abschalten der zyklischen Statusmeldung zu einem Problem werden könnte?

Mal abgesehen davon, dass das in den wenigsten Fällen überhaupt einen Sinn ergeben kann (mir fällt momentan nicht mal einer ein), beraubt man sein System des Selbstheilungseffektes. Bei einem Reboot haben die TFK z.B. eben alle den Zustand "geschlossen" unabhängig davon, wie sie vorher standen oder in der Zwischenzeit verändert wurden. Mit aktiven zyklischen Statusmeldungen hat man nach spätestens einer Stunde wieder einen den tatsächlichen Gegebenheiten entsprechenden Status im System. Mit abgeschalteten Meldungen kann das dann durchaus etwas länger dauern (den trotz der deaktivierten Meldungen, werden trotzdem hin und wieder Statusmeldungen ausgesendet (braucht man ja allein schon wegen der Batteriestatusüberwachung). Nur bei klassischen HM-Tastern gibt es sowas nicht.

Wie wäre in diesem Fall Dein Programmiervorschlag? Ich denke, daß der Workaround von Seite 1 in diesem Fall das Einfachste wäre.

Einfach wäre das, ja. Bei einem Programmiervorschlag kommt es ja auch auf die Nebenbedingungen an. Wie beschrieben, werte ich für meine Umschaltung die Vortageswerte mit aus. Ich habe in meinem System auch gleitende Durchschnittswerte. Die fangen solch plötzlichen Extremwerte von allein ab. Hier bleibt eben nur, nicht direkt auf den Messwert zu triggern, sondern auf einen gespeicherten Wert.

Natürlich werde ich diesen Workaround nur in die Programme einbauen, in denen es nötig ist. Und das sind bei mir sicherlich nur wenige.

Ja, aber häufig sind hier auch Screenshots zu sehen, in denen der Workaround wegen definitiv falscher Aussagen zum Triggerverhalten beim Systemstart in alle Programme eingebaut wird. So z.B. auch in Programme, die durch eine Tastenbetätigung getriggert werden. Bei solchen Triggern ist es einfach von absolut jeder Sinnhaftigkeit befreit und beweist, dass derjenige Anwender nicht verstanden hat, worum es überhaupt geht, bzw. das solche Blödsinnsbehauptungen, dass beim Systemstart "alle Programme gestartet werden" auf fruchtbaren Boden gefallen sind. Auch durch eine noch so häufige Wiederholung gewinnt dieser Blödsinn nicht an Wahrheitsgehalt und beweist nur, dass diejenigen, die das behaupten, sich nicht mit der Funktionsweise des Systems auseinandergesetzt haben. Zumindest zählt das Verständnis der Funktionsweise der CCU nicht zu deren Kernkompetenzen. Ja, es werden beim Systemstart standardmäßig die Bedingungen von Programmen geprüft und ggf. auch ausgeführt, aber eben aus ganz anderen Gründen (weil die Prüfung einer Bedingung ein WAHR ergeben hat oder das Programm ein SONST enthält). Dass an der Aussage nichts dran ist, kann man selbst nachprüfen, wenn man sich mal die Zeitstempel der Programme nach einem Reboot anschaut. Man wird viele finden, die keinen bekommen haben. Hier wurde keine Bedingungsprüfung durchgeführt und schon gar nichts ausgeführt.

Gruß Xel66