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:
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
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.
ZitatDu 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
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.
Zitat von: frank am 21 September 2019, 11:36:11
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.
Zitat von: Damian am 21 September 2019, 20:38:17
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:
2019-09-15 22:47:30 wait_timer 16.09.2019 00:47:30 cmd_1 Broetjeder erste "problematische" fhem restart war ca. 16.09.2019 00:21.
ZitatWait-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:
ZitatIt 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.
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:
Zitatmy $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)
werden die "gelöschten" readings eventuell durch das statefile beim restart überschrieben?
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.
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.
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.
Neuer Version löscht jetzt beim Start das wait_timer-Reading.
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
ZitatWarum 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.
ZitatFü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.
Zitat von: Damian am 26 September 2019, 20:07:31
Neuer Version löscht jetzt beim Start das wait_timer-Reading.
danke. :)