Vertrauenswürdiger Zustand von Batteriesensoren nach Reboot

[Yosh]

Hallo zusammen,

ich habe im Forum nichts zu dem Thema gefunden, von daher poste ich mal, wie ich das Problem gelöst habe. Wenn es andere Lösungen gibt, bin ich natürlich auch daran interessiert.

Das Problem: nach einem Reboot/Stromausfall der CCU gibt eine Abfrage des Zustands der batteriebetriebenen HmIP (Fenster-)sensoren den letzen Zustand vor dem Reboot zurück alle Fenster als "geschlossen" zurück. Öffnet oder schließt man während des War vor dem Stromausfall/Reboot ein Fenster offen, ist der Zustand in der CCU nach dem Reboot nicht vertrauenswürdig bis sich der Sensor wieder gemeldet hat. Alle Programme, die aufgrund des Zustands etwas auslösen sollten also nur ausgeführt werden, wenn der Zustand vertrauenswürdig ist (z.B. Abfrage auf Anzahl offener Fenster).

Meine Lösung: für jeden Sensor habe ich eine Logik Systemvariable, die auf wahr gesetzt wird, wenn sich ein Sensor nach dem Reboot der CCU das erste mal gemeldet hat. Um diese Variable zu setzen habe ich für jeden Sensor ein "Miniprogramm", dass auf die erste Meldung wartet, die Variable setzt und sich dann deaktiviert. Nach dem Reboot habe ich ein "init" Script dass unter anderem die Variable auf falsch setzt und das Miniprogramm aktiviert.

Die Einstellung am Sensor selbst bewirkt, dass er sich spätestens nach einer knappen Stunde meldet:

sensor.JPG (19.16 KiB) 1033 mal betrachtet

Auszug aus den Systemvariablen:

Auszug aus dem init script, dass nach einem Reboot läuft:

Code: Alles auswählen

! 1. Alle SV für Verschlüsse zurücksetzen
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Init_Arbeitszimmer_Fenster").State(false);
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Init_Bad_Fenster").State(false);
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Init_Esszimmer_Fenster").State(false);
! [...]
! 4. Alle Programme für Initialisierung auf aktiv setzen
dom.GetObject(ID_PROGRAMS).Get("Init_Arbeitszimmer_Fenster").Active(true);
dom.GetObject(ID_PROGRAMS).Get("Init_Bad_Fenster").Active(true);
dom.GetObject(ID_PROGRAMS).Get("Init_Esszimmer_Fenster").Active(true);

Ein "init" Programm für einen Fenstersensor - das Programm heißt genau wie die entsprechende Systemvariable.

Durch das "bei Aktualisierung auslösen" wird das Programm ausgeführt, sobald sich der Sensor das erste Mal nach dem Reboot meldet. Beide möglichen Zustände sollen den Aktionsteil auslösen, daher auch die Prüfung auf "offen".

Das Script selbst ist für jedes Fenster identisch. Es setzt die gleichnamige Systemvariable und deaktiviert das Programm:

Code: Alles auswählen

! Aktualisiert SV (muss den gleichen Namen wie das Programm haben!!!) und setzt Programm inaktiv
! Ruft am Ende das Programm 1_Monitor_Aktualisieren auf!!!

if ( dom.GetObject("0_CCU_REBOOT").Value() == false) {
   string sv_name = dom.GetObject("$this$").Name();
   dom.GetObject(ID_SYSTEM_VARIABLES).Get(sv_name).State(true);
   dom.GetObject("$this$").Active(false);
   dom.GetObject("1_Programme_loggen").State(dom.GetObject("$this$").Name() #" wurde am "#system.Date("%d.%m. %H:%M Uhr") #" deaktiviert");
   dom.GetObject(ID_PROGRAMS).Get("1_Verschluss_Aktualisieren").ProgramExecute();
}

Aktionen, die aufgrund des Sensorwertes in anderen Programmen/Scripten ausgeführt werden, prüfen bei der Ausführung, ob die entsprechende Variable auf "wahr" steht.

Vielleicht ist das "mit Kanonen auf Spatzen" geschossen, aber für mich funktioniert es recht gut.

Gruß,
Yosh

[Roland M.]

Hallo!

Danke für das Zeigen deiner Umsetzung!

Vielleicht ist das "mit Kanonen auf Spatzen" geschossen, aber für mich funktioniert es recht gut.

Ich hätte das vereinfacht und ohne Script realisiert.

Für jeden Fensterkontakt eine SV als Werteliste angelegt
"Status Fenster 1" = unbekannt, geschlossen, offen


Bei Neustart der CCU ein Programm ohne Bedingung:

Code: Alles auswählen

WENN {leer}
DANN Status Fenster 1 = unbekannt
     Status Fenster 2 = unbekannt
     Status Fenster 3 = ...

und ein Programm

Code: Alles auswählen

WENN Fenster 1 offen [auslösen auf Aktualisierung]
DANN Status Fenster 1 = offen
SONST Status Fenster 1 = geschlossen

Somit ist der Status nach dem Neustart "unbekannt", sonst entsprechend "offen" oder "geschlossen".

Aber viele Wege führen bekanntlich nach Rom...


Roland

[Xel66]

Es ginge sogar noch einfacher. Einfach die Status der Fenstersensoren eine Stunde als ungültig betrachten und davo abhängige Programme erst dann wieder triggern lassen. Dazu setzt man eine Sperrvariable beim Systemstart auf WAHR und verzögert um eine Stunde aus FALSCH. Hat man eine beaufsichtigten Reboot ohne Fensterbewegungen gemacht, kann man die Variable ja händisch wieder zurückschalten.

Gruß Xel66

[dtp]

Irgendwie stehe ich gerade auf dem Schlauch.

Das Problem: nach einem Reboot/Stromausfall der CCU gibt eine Abfrage des Zustands der batteriebetriebenen HmIP (Fenster-)sensoren den letzen Zustand vor dem Reboot zurück.

Meines Wissens werden nach einem Neustart der CCU alle batteriebetriebenen Fenstersensoren auf den Zustand geschlossen gesetzt. Nur, wenn man die Zustände zusätzlich in entsprechenden Systemvariablen schreibt, überleben diese einen Neustart der CCU. Das ändert aber nichts daran, dass Zustandsänderungen nicht korrekt erfasst werden können, wenn diese erfolgen, während die CCU stromlos war.

Mir ist irgendwie nicht ganz klar, wie man Zustandsänderungen während einer stromlosen CCU zeitnah nach dem Neustart der CCU korrekt erfassen kann, da die Batteriesensoren ja nicht von der CCU aus abgefragt werden können. Und die zyklische Zustandmeldung des Sensors erfolgt im Worst Case doch auch erst 24 Stunden nach dem Neustart.

Ich vermeide daher möglichst eine längere stromlose Phase der CCU durch eine vorgeschaltete USV. Außerdem starte ich meine CCU meistens nur dann neu, wenn ich davon ausgehen kann, dass in der Zwischenzeit niemand ein Fenster oder eine Tür betätigt.

Durch das "bei Aktualisierung auslösen" wird das Programm ausgeführt, sobald sich der Sensor das erste Mal nach dem Reboot meldet. Beide möglichen Zustände sollen den Aktionsteil auslösen, daher auch die Prüfung auf "offen".

Auch das verstehe ich nicht. Ein "nur prüfen" triggert niemals ein Programm.

Übrigens gab es mal den Tipp, Namen von Programmen, Systemvariablen etc. nicht mit einer Ziffer zu beginnen. Aber das kann sich mittlerweile auch erledigt haben.

[Xel66]

Und die zyklische Zustandmeldung des Sensors erfolgt im Worst Case doch auch erst 24 Stunden nach dem Neustart.
...
Übrigens gab es mal den Tipp, Namen von Programmen, Systemvariablen etc. nicht mit einer Ziffer zu beginnen. Aber das kann sich mittlerweile auch erledigt haben.

Der worst case sind die alten magnetischen TFK. Aber der optischen Serie gibt es Aktualisierungsinterval von ca. einer Stunde.

Den Tipp mit der führenden Ziffer für Programme würde ich immer noch beherzigen.

Gruß Xel66

[MichaelN]

Auch das verstehe ich nicht. Ein "nur prüfen" triggert niemals ein Programm.

Aber "bei Aktualisierung"

[dtp]

Aber "bei Aktualisierung"

Hast Recht. Da habe ich zu kurz gedacht.

Ich hätte es mit einer UND-Verknüpfung von "geschlossen" und "geöffnet" mit jeweils "bei Änderung auslösen" gemacht. Das beinhaltet ja das gegenseitige "nur prüfen".

[MichaelN]

Ich hätte es mit einer UND-Verknüpfung von "geschlossen" und "geöffnet" mit jeweils "bei Änderung auslösen" gemacht. Das beinhaltet ja das gegenseitige "nur prüfen".

Das führt aber idR dazu das das Programm entweder 2x triggert oder das Triggerereignisse verschluckt werden. Daher: wenn ein Trigger schon im Programm ist - niemals ein zweites Mal im Programm triggern lassen. Zumindest für alle (nahezu) zeitgleich eintretenden Ereignisse gilt dies.
siehe auch https://github.com/jens-maus/RaspberryMatic/issues/1278

[Yosh]

Hallo zusammen,

vielen Dank für Eure Anmerkungen.

@Roland M.
Das hatte ich auch überlegt, aber ich brauche ja eigentlich nur einmal nach dem Reboot die Änderung, dass der Sensor "da" ist. Daher war meine Idee das Überwachungsprogramm beim Reboot zu aktivieren und nachdem es seine Aufgabe erledigt hat wieder schlafen zu legen. Wird wahrscheinlich nicht viel Ressourcen verbrauchen, aber bei Deiner Lösung würde das Programm doch vom Sensor immer (mit-)getriggert, oder?

@Xel66
Wäre auch eine Möglichkeit, aber ich möchte tatsächlich sicher sein, dass sich der Sensor gemeldet hat.

@dtp
Du hast recht - ich hatte das falsch interpretiert - Die Fenster werden alle als geschlossen angezeigt. Den Tip mit der Ziffer am Anfang kannte ich noch nicht. Ich habe da nicht viele, halt so ein paar, die mit einem Neustart zu tun haben, oder die so zentrale Variablen sind, dass sie in vielen Programmen verwendet werden und da ist es einfach schön, wenn sie ganz ober in der Drop-Down Liste bei der Auswahl stehen Bisher sind da auch noch keine Probleme aufgetreten, aber ich werde darauf mal achten.

Gruß,
Yosh

[Roland M.]

Hallo Yosh!

@Roland M.
Das hatte ich auch überlegt, aber ich brauche ja eigentlich nur einmal nach dem Reboot die Änderung, dass der Sensor "da" ist.
[...]
Wird wahrscheinlich nicht viel Ressourcen verbrauchen, aber bei Deiner Lösung würde das Programm doch vom Sensor immer (mit-)getriggert, oder?

So what?
Die CCU-Auslastung meiner CCU2 (!) liegt jedenfalls im 1%-Bereich [*]. Da machen ein paar "unnütze" Dinge ja auch nichts.

Mit deiner Version musst du aber diese SV und den Status der Fensterkontakte abfragen. Mit meiner Variante nur die eine SV. Könnte man dann fast schon wieder gegenrechnen.

Wie gesagt, viele Wege führen zum Ziel, ich versuche aber auch, die Programmierung möglichst einfach zu halten. Ich möchte schließlich auch noch selbst nachvollziehen können, was ich vor Jahren programmiert habe...


Roland


[*]
Bei etwa 100 Geräten und 150 Programmen meint die CCU2:

Code: Alles auswählen

# uptime
 20:49:57 up 40 days,  6:42,  1 users,  load average: 0.91, 0.64, 0.66
#