DOIF Waittimer überdauert keinen Reboot

Loredo · 19 Februar 2016, 09:20:54

Ich stelle gerade fest, dass ein längerer Waittimer bei mir wohl scheinbar keinen Reboot von FHEM überlebt.
Wäre es denkbar, dass ein aktiver Waittimer irgendwie erhalten bleibt und nach einem Reboot weiterhin verfolgt wird? Oder sollte das bereits der Fall sein?

Gruß
Julian

Damian · 19 Februar 2016, 10:43:56

Zitat von: Loredo am 19 Februar 2016, 09:20:54
Ich stelle gerade fest, dass ein längerer Waittimer bei mir wohl scheinbar keinen Reboot von FHEM überlebt.
Wäre es denkbar, dass ein aktiver Waittimer irgendwie erhalten bleibt und nach einem Reboot weiterhin verfolgt wird? Oder sollte das bereits der Fall sein?

Gruß
Julian

Alle Timer insb. Wait-Timer werden beim Reboot neu gesetzt. Der Wait-Timer stirbt logischerweise, wenn das System beendet wird. Das Wiederaufsetzen eines laufenden Waittimers ist z. Zt. nicht vorgesehen.

Gruß

Damian

tomster · 19 Februar 2016, 11:51:24

Schade, das Gleiche habe ich mir auch schon bei ein paar meiner DOIFs gedacht/ gewünscht.
Wär aber nicht schlecht, wenn es persitente Timer auf die Roadmap von FHEM/DOIF schaffen könnten...

Damian · 19 Februar 2016, 16:15:34

Zitat von: tomster am 19 Februar 2016, 11:51:24
Schade, das Gleiche habe ich mir auch schon bei ein paar meiner DOIFs gedacht/ gewünscht.
Wär aber nicht schlecht, wenn es persitente Timer auf die Roadmap von FHEM/DOIF schaffen könnten...

ja, allerdings würden viele gesetzte Wait-Timer nach dem Reboot nicht mehr existieren, denn sie wären bereits abgelaufen.

Für alles was länger als eine Stunde Verzögerung braucht, kann man normale Timer mit Addition einer Zeit benutzen, diese werden nach dem Neustart neu gesetzt.

Gruß

Damian

Loredo · 21 Februar 2016, 10:45:59

Ich nutze den Waittimer recht intensiv für all meine FSM's. Die Verzögerungen sind dabei auch mal länger, z.B. die Umschaltung vom Morgen-Modus in den Tages-Modus nach 1,5h nach dem aufstehen.

Zitat von: Damian am 19 Februar 2016, 16:15:34
Für alles was länger als eine Stunde Verzögerung braucht, kann man normale Timer mit Addition einer Zeit benutzen, diese werden nach dem Neustart neu gesetzt.

Hast du ein Beispiel? Meinst du man soll ein temporäres at-Device anlegen dafür? Dann gibts ja wieder den Nachteil, dass man sich wieder was ausdenken muss, um den at-Befehl ggf. vor Ausführung automatisch abzubrechen. Das geht mit DOIF einfacher und übersichtlicher. Bei einem temporären DOIF denke ich gar, dass die Zeit nach einem Reboot dann neu berechnet wird und somit nicht mehr identisch mit der ursprünglichen Zeit wäre.
Ich würde auch ungern ein temporäres Device anlegen müssen, da ich dann erst ein "save" ausführen müsste, um es über den Reboot zu retten. Ich hätte daher gerne eine unkomplizierte Lösung rein über Readings.

Im Reading wait_timer steht ja eigentlich alles was man braucht, um nach einem Reboot den Waittimer wieder neu zu starten. Vielleicht noch eine Funktion, ob ein Trigger noch ausgeführt werden soll, wenn die Zeit zwischenzeitlich abgelaufen ist und dann ist doch schon gut.

Ich verstehe, dass das gegen dein Prinzip "ich lösche am Anfang alle Readings statt diese nur zu aktualisieren bzw. nur jene zu löschen, welche nicht mehr benötigt werden" steht. Das würde wohl hier und da einen komplizierteren Umbau erfordern, ist das so?

Damian · 21 Februar 2016, 14:21:11

Zitat von: Loredo am 21 Februar 2016, 10:45:59
Ich nutze den Waittimer recht intensiv für all meine FSM's. Die Verzögerungen sind dabei auch mal länger, z.B. die Umschaltung vom Morgen-Modus in den Tages-Modus nach 1,5h nach dem aufstehen.

Hast du ein Beispiel? Meinst du man soll ein temporäres at-Device anlegen dafür? Dann gibts ja wieder den Nachteil, dass man sich wieder was ausdenken muss, um den at-Befehl ggf. vor Ausführung automatisch abzubrechen. Das geht mit DOIF einfacher und übersichtlicher. Bei einem temporären DOIF denke ich gar, dass die Zeit nach einem Reboot dann neu berechnet wird und somit nicht mehr identisch mit der ursprünglichen Zeit wäre.
Ich würde auch ungern ein temporäres Device anlegen müssen, da ich dann erst ein "save" ausführen müsste, um es über den Reboot zu retten. Ich hätte daher gerne eine unkomplizierte Lösung rein über Readings.

Im Reading wait_timer steht ja eigentlich alles was man braucht, um nach einem Reboot den Waittimer wieder neu zu starten. Vielleicht noch eine Funktion, ob ein Trigger noch ausgeführt werden soll, wenn die Zeit zwischenzeitlich abgelaufen ist und dann ist doch schon gut.

Ich verstehe, dass das gegen dein Prinzip "ich lösche am Anfang alle Readings statt diese nur zu aktualisieren bzw. nur jene zu löschen, welche nicht mehr benötigt werden" steht. Das würde wohl hier und da einen komplizierteren Umbau erfordern, ist das so?

Ich schaue es mir mal genauer im Code an, denn die Alternativen sind tatsächlich umständlich.

Gruß

Damian

Loredo · 21 Februar 2016, 14:36:51

Allein dafür schonmal ein dickes Danke, Damian

Gruß
Julian

tomster · 22 Februar 2016, 10:31:12

Zitat von: Loredo am 21 Februar 2016, 10:45:59
Hast du ein Beispiel? Meinst du man soll ein temporäres at-Device anlegen dafür? Dann gibts ja wieder den Nachteil, dass man sich wieder was ausdenken muss, um den at-Befehl ggf. vor Ausführung automatisch abzubrechen. Das geht mit DOIF einfacher und übersichtlicher. Bei einem temporären DOIF denke ich gar, dass die Zeit nach einem Reboot dann neu berechnet wird und somit nicht mehr identisch mit der ursprünglichen Zeit wäre.

Genau DAS ist auch mein "Problem". In meinem Fall habe ich ~~Timer~~ Waits, die insgesamt bis zu 8 Stunden dauern. Kurz das Szenario:
In einer Ferienwohnung wird jeden Donnerstag per DOIF vorgeheizt. Donnerstag um 22:00 Uhr-> Nachtspeicher "Ladung" an -> 4 Stunden später -> NS-Gebläse an -> weiter 4 Stunde später -> Boiler an. Würde der RasPi dazwischen aber irgendwann neu gestartet (kommt ja vor, wenn man dauernd an der Kiste bastelt), dann würden die Waits jedesmal neu gestartet und der Zeitplan total über den Haufen geworfen. -> Im dümmsten Fall bleibt die Hütte kalt.

Klar, könnte man innerhalb eines DOIFs auch entsprechende at's definen, die dann jeweilige Timer setzen. Nur "kollidiert" das mit mit meinen DOELSEIFs, weil ich ja auch andere Szenarien "zwischendrin" damit abfangen will. Ich müsste dann in die DOELSEIFs wohl noch zusätzliche Abfragen einbauen, ob eventuell ein at aus einem anderen DOIF-Fall gesetzt wurde, damit dieser ggfls. wieder gelöscht wird. Wenn DOIF diese Fälle quasi "intern" abfangen könnte, wäre es glaube ich einfacher für den User.

Zitat
Ich würde auch ungern ein temporäres Device anlegen müssen, da ich dann erst ein "save" ausführen müsste, um es über den Reboot zu retten. Ich hätte daher gerne eine unkomplizierte Lösung rein über Readings.

Hab ich da bei den at's was mißverstanden, oder sind die nicht auch ohne "save" aktiv und überdauern einen Reboot?

--edit--
Anscheinend kann man at's trotz Kommandozeile "falsch" anlegen, dann überleben sie doch keinen Reboot (hab's jetzt aber nicht selbst probiert, auf die Schnelle)...
http://forum.fhem.de/index.php/topic,39834.0.html

tomster · 22 Februar 2016, 10:46:22

Ach ja, hab ich grad in einem anderen Thread gelesen:

Zitat
Hast du ein Beispiel? Meinst du man soll ein temporäres at-Device anlegen dafür?

Zitat von: Waldmensch am 21 Februar 2016, 23:11:50
Code Auswählen Erweitern
DOIF ([move1_chan_0] eq "on-old-for-timer 60" and [licht_hinterhof:state] eq "off") (set licht_hinterhof on, define reset_piri0 at +00:00:10 set move1_chan_0 off, define reset_hoflicht0 at +00:01:00 set licht_hinterhof off ) DOELSEIF ([move1_chan_0] eq "on-old-for-timer 60" and [licht_hinterhof:state] eq "on") (delete reset_hoflicht0, define reset_piri0 at +00:00:10 set move1_chan_0 off, define reset_hoflicht0 at +00:01:00 set licht_hinterhof off)

Loredo · 22 Februar 2016, 10:54:44

Danke dir.

Habe ja schon gesagt, dass ich temporäre Devices nicht so toll finde ^^
Die Frage nach einem Beispiel bezog sich eher auf DOIF's "normale Timer", ohne dass man ein temporäres Device anlegen muss (egal ob vom Typ "at" oder "DOIF").

Die at-Devices, wie von dir beschrieben, sind benannte temporäre at-Devices, welche sich nach der Ausführung selbst löschen. Damit sie aber den Reboot überdauern, müssen sie in die fhem.cfg geschrieben werden. Das macht der save-Befehl. Ohne diesen Befehl geht das at-Device, wie jedes andere FHEM Device, welches man anlegt und nicht abspeichert, verloren.

tomster · 22 Februar 2016, 11:41:02

Ach, *hirnpatsch* da hab ich grad den Baum vor lauter Wäldern gar nicht mehr gesehen.
Klar, ohne ein "Save" hilft einem auch kein at-Define. Es bliebe ja nur temporär.

Nur um's nochmal runterzubrechen. Meine Idee war den Wait-Timer innerhalb eines DOIFs so zu gestalten, dass er einen Reboot überlebt (wie auch immer das gehen kann).
Beispiel:

DOIF setzt Nachtspeicher "an" am Donnerstag um 22:00 Uhr. 4 Stunden später (also um 02:00 Uhr) schaltet der Lüfter ein. Wenn ich in der Zwischenzeit einen Neustart von FHEM anstosse, dann würde der Timer nicht mehr neu gesetzt. -> Der Lüfter schaltet nicht ein -> Bude kalt. Wäre der DOIF-Timer "persistent" (weil er eben mit genauer Uhrzeit "rebootsicher" hinterlegt ist), dann würde auch nach einem Neustart um 02:00 Uhr der Lüfter zuverlässig angeschalten. Danach wäre der Timer wieder gelöscht, weil ja einmalig und abgearbeitet.

Würde nun, durch einen (anderen) DOELSEIF-Fall die Notwendigkeit bestehen, den Timer vor Erreichen des Zeitpunkts wieder zu löschen, dann "kennt" ja DOIF den gesetzten Timer (es hat ihn ja schließlich verursacht) und kann ihn eben auch wieder löschen. Wird dann zwar ein ziemliches Logik-Monster, der Herr DOIF, aber "er" hätte eine Funktionalität, die ich bislang vermisse und noch bei keinem anderen Helferlein gefunden habe...

Natürlich könnte man innerhalb des DOIFs ein at setzen in Verbindung mit {fhem ("save") };, aber mir wär's lieber man hätte ein Parameter innerhalb der DOIF-Syntax, z.B. [p+04:00] um einen persitenten Timer zu definieren, der gespeichert wird und durch DOELSEIFs ggfls. auch wieder "überschrieben/ gelöscht" werden könnte...

Loredo · 22 Februar 2016, 12:23:48

Damian denkt ja schon drüber nach hat er gesagt, also lassen wir ihm doch auch diese Zeit dafür

Das Reading "wait_timer" enthält wahrscheinlich zwar alle Infos, um einen Timer nach dem Reboot erneut korrekt zu starten. Aber wie Damian durchblicken ließ ist das nicht so einfach nur einen Timer neu zu starten, da die Logik vom Modul eben eher darauf ausgelegt ist den define-Text zu parsen und die Interpretation entsprechend umzusetzen. Dazwischen jetzt einige Ausnahmen einzubauen, dass es zuvor schon einen Timer gab mag also nicht ganz trivial sein. Dazu gehören sicherlich Überlegungen wie "will ich den gesamten (internen) Modulstatus wiederherstellen oder muss ich das sogar?". Das macht man nicht mal eben so zwischen Tür und Angel

tomster · 22 Februar 2016, 12:51:54

Klar, mea culpa. Sollte mit Nichten gedrängelt klingen. Wollt's nur nochmal klar ausgedrückt haben.

DanielGab · 17 Juni 2018, 22:31:21

Gibt's hier schon was Neues? Seit Neuestem bleiben meine wait timer nach FHEM shutdown restart stehen, aber es passiert dann nichts. Ich mache regelmäßig Updates, aber ich habe keine Ahnung seit wann dieser Zustand vorhanden ist.
Mir ist leider auch nicht ganz klar, wie ich die löschen kann. Am liebsten hätte ich es, wenn sie nach dem reboot weiter laufen, wenn sie denn noch nicht abgelaufen sind.
Ich müsste diese FHEM Neustarts eigentlich öfter machen, damit meine LD382A (Ufo magic) richtig funktionieren. Sie hängen an einer Funksteckdose und funktionieren nach dem "set Funksteckdose on" nicht richtig. Aber ich verzichte für eine Menge wait timer auf diesen Schritt. Das ist das einzige, das in meinem System leider nicht wirklich funktioniert.
Liebe Grüße

Damian · 17 Juni 2018, 22:58:14

Wait-Timer überleben nicht den Neustart (genauso wenig wie ein sleep). Wenn man nach dem Neustart welche findet, dann wurden sie durch einen Trigger erneut gesetzt - DOIF setzt keine wait-Timer von sich aus ohne Trigger.

Man kann dagegen mit Hilfe des DOIF-Attributs startup bestimmte Aktionen nach dem Neustart initiieren. Man kann ggf. auch Intervalltimer nutzen, diese überleben den Neustart.

Ich persönlich würde keine längeren wait-Timer im Stundenbereich definieren, weil die Gefahr, dass ein Neustart diese unterbricht dann recht hoch ist.