watchdog nach restart

Begonnen von volschin, 06 Juli 2018, 11:10:42

Vorheriges Thema - Nächstes Thema

volschin

Ich habe einige länger laufende Watchdogs und dabei festgestellt, dass diese immer lahmgelegt sind, nachdem ich ein shutdown restart gemacht habe.

Der Status "activated" mit der zugehörigen Zeit ist zwar weiter in den Readings vorhanden, wird aber nicht mehr benutzt (Status defined).

Lässt sich dieses Verhalten ändern? Ist das so gewollt oder letztlich ein Bug?
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

KölnSolar

Ich denke, dass es so gewollt ist. Normalerweise willst Du ja, wenn nach Ereignis A nicht innerhalb einer bestimmten Zeit Ereignis B eintritt eine Aktion auslösen. Nach dem Reboot hast Du da einen quasi undefinierten Zustand. B könnte zwischenzeitlich stattgefunden haben oder auch nicht. Vielleicht sogar ein erneutes Ereignis A, dessen Zeitpunkt aber nicht bekannt(zwischen dem shutdown/reboot) ist.
Du musst Dir also wahrscheinlich eine eigene "Initialisierung" für Deinen case mit dem event "global INITIALIZED" bauen.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Bug oder Feature weiss ich nicht, es ist eher ein "ich habe mich um das Problem bisher nicht gekuemmert".Eine Loesung waere (optional per Attribut) den Timeout in einem Reading zu speichern, und nach dem Restart sie auszuwerten. Die Bemerkung von Markus bleibt valide.

volschin

#3
OK, ich verstehe, dass mein Bedarf nicht für alle Anwendungsfälle sinnvoll ist. Ich fände aber ein zusätzliches Attribut Klasse.

Grundsätzlich funktioniert Wiederherstellung des Status beim at-TYPE ja auch. Dort wird allerdings
TRIGGERTIME         1530993600
TRIGGERTIME_FMT     2018-07-07 22:00:00

nochmal separat in den Internals hinterlegt.

Wäre vermutlich gut, wenn die Realisierung nach der gleichen Logik erfolgt.

Ich würde mir auch selber was mit global INITIALIZED bauen, aber ich kenne keinen Weg um den zeitlichen Status des Watchdog wiederherzustellen, auch wenn ich aus dem Reading
Activated     activated   2018-07-06 11:37:55
und der Dauer im Internal TO den Zeitpunkt herausbekomme.
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

rudolfkoenig

Ich habe dem watchdog jetzt das Attribut activateOnStart spendiert.
Zusaetzliche Readings waren nicht notwendig, das bisher gesetzte Activated, die Definition und die aktuelle Uhrzeit reicht.

volschin

Hallo Rudolf,
herzlichen Dank, ich habe es erfolgreich getestet. Das löst mein Problem. Es gibt allerdings den Effekt, dass auch ein Watchdog, der vor dem Restart auf defined stand, dadurch wiedererweckt wurde (nicht abgelaufenes Activate). In meinem Szenario stört das nicht, könnte sich aber bei jemand anderem möglicherweise negativ auswirken.

Viele Grüße
Veit
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

rudolfkoenig

Danke fuer den Hinweis, habs gefixt.