problem mit waittimer durch fhem restart

[frank]

moin,

mein doif zum verzögerten ausschalten einer warmwasserbereitung macht manchmal probleme.
und zwar nur dann, wenn während des waittimers ein fhem restart erfolgt. danach wird nie wieder ausgeschaltet.
erst wenn der zustand des überwachten readings manuell auf 0 gesetzt wird, schaltet das doif dann beim nächsten mal wieder korrekt. natürlich nur, wenn nicht wieder ein restart zur falschen zeit kommt.

im plot ist zu sehen, dass der problematische restart (rote spikes) kurz vorm auslösen des doifs kam. seit dem gab es kein abschalten des doifs.

was habe ich übersehen?


list:

Code Auswählen Erweitern

Internals:
   DEF        ([Broetje:wwBetrModus] == 1) (setreading refRoom setWWmode off)
   FUUID      5c4ce2ee-f33f-09c4-2de8-b64ac596e24559e3
   MODEL      FHEM
   NAME       di_ww_off
   NOTIFYDEV  global,Broetje
   NR         610
   NTFY_ORDER 50-di_ww_off
   STATE      cmd_1
   TYPE       DOIF
   VERSION    20163 2019-09-15 16:48:42
   READINGS:
     2019-09-16 20:29:38   Device          Broetje
     2019-09-15 19:18:26   cmd             1
     2019-09-15 19:18:26   cmd_event       Broetje
     2019-09-15 19:18:26   cmd_nr          1
     2019-09-15 22:47:30   e_Broetje_wwBetrModus 1
     2019-09-15 19:18:26   state           cmd_1
     2019-09-15 22:47:30   wait_timer      16.09.2019 00:47:30 cmd_1 Broetje
   Regex:
     accu:
     cond:
       Broetje:
         0:
           wwBetrModus ^Broetje$:^wwBetrModus:
   attr:
     wait:
       0:
         7200
   condition:
     0          ::ReadingValDoIf($hash,'Broetje','wwBetrModus') == 1
   do:
     0:
       0          setreading refRoom setWWmode off
     1:
   helper:
     globalinit 1
     last_timer 0
     sleeptimer -1
   perlblock:
   readings:
     all         Broetje:wwBetrModus
   uiState:
   uiTable:
Attributes:
   disable    0
   do         always
   group      WW.System
   room       81_WW,98_Ventile
   wait       7200

[Ellert]

Du könntest im Attribut startup checkall ausführen lassen.

Oder mit DOIFtools die laufenden Waittimer anzeigen und dann entscheiden, ob Du einen Neustart ausführen willst.

[frank]

Du könntest im Attribut startup checkall ausführen lassen.

danke, das erzeugt zumindestens einen neuen waittimer.

allerdings finde ich das "normale" verhalten des doif ohne attr startup, wie oben beschrieben, mehr als "unglücklich".

alle readings zeigen vor und nach fhem restart die selben werte und timestamps. vor allem das reading wait_timer suggeriert ja, dass der timer weiterhin existiert und alles wie "gewünscht" läuft.

da die timerdaten im reading existieren, könnte man doch theoretisch den waittimer nach restart auch wieder reaktivieren.

ein setzen des waittimers auf zb den alten wert über attr startup habe ich nicht gefunden. gibt es dafür eventuell doch eine lösung?

gruss frank

[Ellert]

Eine Diskussion dieser Problematik gibt es bereits, z.B.

https://forum.fhem.de/index.php/topic,49555.msg812978.html#msg812978

Im Prinzip könntest Du beim SHUTDOWN Event und laufendem Waittimer ein DOIF(Zweig) aktivieren, dass nach dem INITIALIZED Event die verpassten Befehle nachholt oder das Nachholen ins Attribut startup legen.

[Damian]

danke, das erzeugt zumindestens einen neuen waittimer.

allerdings finde ich das "normale" verhalten des doif ohne attr startup, wie oben beschrieben, mehr als "unglücklich".

alle readings zeigen vor und nach fhem restart die selben werte und timestamps. vor allem das reading wait_timer suggeriert ja, dass der timer weiterhin existiert und alles wie "gewünscht" läuft.

da die timerdaten im reading existieren, könnte man doch theoretisch den waittimer nach restart auch wieder reaktivieren.

ein setzen des waittimers auf zb den alten wert über attr startup habe ich nicht gefunden. gibt es dafür eventuell doch eine lösung?

gruss frank

Im wait_timer-Reading steht immer der genaue Zeitpunkt. Es wird zu keinem Zeitpunkt eine falsche Zeit angezeigt, wenn nach dem Neustart kein Timer gesetzt ist, dann steht das auch in diesem Reading.

Wait-Timer ist aus meiner Sicht Timer, der keine lange Laufzeit haben sollte, er entspricht dem sleep-Timer, der einen Neustart nicht überlegt. Feste Timer im DOIF werden nach dem Neustart neu aufgesetzt, diese können auch zur Laufzeit neu berechnet, gesetzt und damit verändert werden. Alternativ kann man einen at mit berechneter Zeit setzen, dieser Überlebt auch einen Neustart.

[frank]

Im wait_timer-Reading steht immer der genaue Zeitpunkt. Es wird zu keinem Zeitpunkt eine falsche Zeit angezeigt, wenn nach dem Neustart kein Timer gesetzt ist, dann steht das auch in diesem Reading.

hallo damian,
deine aussage kann ich leider nicht bestätigen.

im list meines doif aus post #1 steht nach mehr als 3 tagen und mehreren restarts von fhem:

Code Auswählen Erweitern

     2019-09-15 22:47:30   wait_timer      16.09.2019 00:47:30 cmd_1 Broetje

der erste "problematische" fhem restart war ca. 16.09.2019 00:21.

Wait-Timer ist aus meiner Sicht Timer, der keine lange Laufzeit haben sollte, er entspricht dem sleep-Timer, der einen Neustart nicht überlegt. Feste Timer im DOIF werden nach dem Neustart neu aufgesetzt, diese können auch zur Laufzeit neu berechnet, gesetzt und damit verändert werden. Alternativ kann man einen at mit berechneter Zeit setzen, dieser Überlebt auch einen Neustart.

ok.

eine kürzere laufzeit verringert allerdings nur die wahrscheinlich des problems.
die beispiele in der cref nutzen waittimer mit bis zu 1200 sek (rollo). ich denke, das passt nicht zu den kurzen laufzeiten.

auch die englische cref "verspricht" hier dann eventuell zu viel:

It combines the functionality of a notify, at-, watchdog command with logical queries.
Complex problems can be solved with this module, which would otherwise be solved only with several modules at different locations in FHEM. This leads to clear solutions and simplifies their maintenance.

[Damian]

Dann muss da noch etwas anderes kaputt sein. Laut Programmcode werden sowohl im Perl-Modus wie auch im FHEM-Modus Readings die so beginnen gelöscht:

my $readings = ($hash->{MODEL} eq "Perl") ? "^(Device|error|warning|cmd|e_|timer_|wait_|matched_|last_cmd|mode|block_)":"^(Device|state|error|warning|cmd|e_|timer_|wait_|matched_|last_cmd|mode|block_)";

Wie gesagt, es gibt z. Zt. keine Mechanismen, die waittimer beim Start wieder aufsetzen (dazu müsste der errechnete Zeitpunkt den Neustart überleben, das tut er aber im $hash, wo er abgelegt ist, nicht)

[frank]

werden die "gelöschten" readings eventuell durch das statefile beim restart überschrieben?

[Damian]

ja, die Funktion wird durchgeführt wenn man defmod anklickt wird - das reicht wohl nicht. Ich werde zukünftig das Reading zusätzlich nach dem vollständigen Hochfahren des Systems putzen.

[frank]

ich habe zwar wenig einsicht in die weiten des doif imperiums, aber wäre es nicht sinnvoll zumindestens bei nutzung von "flüchtigen" timern und überwachung von stati grundsätzlich so etwas wie checkall beim start einzubauen.

das war jedenfalls meine naive vorstellung.

[Damian]

Naja, du musst bedenken, dass wir über mehr als 60.000 DOIF-Definitionen reden, von denen wir nicht wissen, wie sie definiert sind. Die Kompatibilität ist den Leuten aus gutem Grunde wichtig. Ein automatisches checkall würde das Verhalten des Moduls erheblich verändern. DOIF würde auf einmal Dinge tun, die es vorher nicht gemacht hat. Daher denke ich, checkall im startup-Attribut sollte dafür ausreichend sein.

Besser wäre, einen nicht abgelaufenen Timer beim Starten automatisch zu setzen, aber das würde einige Änderungen im Modulen mit sich bringen und damit einen hohen Programmieraufwand für mich bedeuten. Und der abgelaufene Timer würde damit auch nicht abgedeckt sein.

[Damian]

Neuer Version löscht jetzt beim Start das wait_timer-Reading.

[Frank_Huber]

Warum eigentlich so oft Neustart?...?

Für solch "kritische" Aktionen würde ich im Doif ein at anlegen und speichern, das überdauert auch einen Neustart

Gesendet von meinem S60 mit Tapatalk

[frank]

Warum eigentlich so oft Neustart?...?

1x automatischer restart nach "cannot allocate memory". (hat dieses problem sichtbar gemacht)
1x fhem update.
4x restart zum testen von homematic (actiondetector nach update defekt/restart fehler).
3x restart zum testen von diesem doif problem.

Für solch "kritische" Aktionen würde ich im Doif ein at anlegen und speichern, das überdauert auch einen Neustart

jetzt bin ich auch schlauer. 
ich dachte, hier könnte ich endlich mal ein doif sinnvoll einsetzen.

[frank]

Neuer Version löscht jetzt beim Start das wait_timer-Reading.

danke.