[Gelöst] DOIF repeatcmd wird bei FHEM neustart gelöscht

Pnemenz · 14 Mai 2018, 09:58:01

ich habe ein DOIF, das zwischen 8:30 und 20:50 alle 4 Stunden ein Device schalten soll.
gelöst mit

defmod Anwachsen DOIF ([08:30-20:50]) ...

attr Anwachsen repeatcmd 13745

Wenn jetzt zwischen 8:30 und 20:50 FHEM neu gestartet wird (z.B. wegen eines Updates) wird nicht mehr wiederholt. Der Zyklus fängt erst wieder am nächsten Tag an.

Kann man das so einstellen, dass der Wait Timer nach Neustart erhalten bleibt?

Damian · 14 Mai 2018, 10:22:26

Zitat von: Pnemenz am 14 Mai 2018, 09:58:01
ich habe ein DOIF, das zwischen 8:30 und 20:50 alle 4 Stunden ein Device schalten soll.
gelöst mit
Code Auswählen Erweitern
defmod Anwachsen DOIF ([08:30-20:50]) ...
Code Auswählen Erweitern
attr Anwachsen repeatcmd 13745

Wenn jetzt zwischen 8:30 und 20:50 FHEM neu gestartet wird (z.B. wegen eines Updates) wird nicht mehr wiederholt. Der Zyklus fängt erst wieder am nächsten Tag an.

Kann man das so einstellen, dass der Wait Timer nach Neustart erhalten bleibt?

Nein. Der wait-Timer braucht immer einen Auslöser. Mit dem heutigen Update gibt es aber Intervall-Timer, siehe https://forum.fhem.de/index.php/topic,87183.0.html

Damit kannst du Folgendes definieren:

Code Auswählen

defmod Anwachsen DOIF ([08:30-20:50,+13745]) ...
attr Anwachsen do always

Der Intervall-Timer wird auch nach dem Hochfahren aktiv, die Berechnung des nächsten Triggers richtet sich dann nach dem Definitionszeitpunkt, hier also nach dem Zeitpunkt des Neustarts. Wenn der Triggerzeitpunkt immer zu gleichen Zeiten stattfinden soll, so sollte man für den Intervall-Timer einen nach Zeitraster ausgerichteten Timer verwenden: https://fhem.de/commandref_DE.html#DOIF_Zeitangaben_nach_Zeitraster_ausgerichtet_alle_X_Stunden oder https://fhem.de/commandref_DE.html#DOIF_Relative_Zeitangaben_nach_Zeitraster_ausgerichtet

Pnemenz · 14 Mai 2018, 18:54:39

Die Funktionen nach Zeitrater ausrichten kannte ich, aber da muss ich alle Zeitpunkte einzeln eingeben. Was bei drei oder vier nicht so schlimm ist, aber was ist bei mehr Einträgen?
Oder wie formuliere ich da 8:00 bis 20:00 alle drei Stunden?
Wie kann ich dann den nächsten gelpanten Zeitpunkt anzeigen? Der Vorteil des wait-timers ist, dass ich z.B. in einer Readingsgroup den nächsten Schaltzeitpunkt anzeigen kann.

Damian · 14 Mai 2018, 19:20:46

Zitat von: Pnemenz am 14 Mai 2018, 18:54:39
Die Funktionen nach Zeitrater ausrichten kannte ich, aber da muss ich alle Zeitpunkte einzeln eingeben. Was bei drei oder vier nicht so schlimm ist, aber was ist bei mehr Einträgen?
Oder wie formuliere ich da 8:00 bis 20:00 alle drei Stunden?
Wie kann ich dann den nächsten gelpanten Zeitpunkt anzeigen? Der Vorteil des wait-timers ist, dass ich z.B. in einer Readingsgroup den nächsten Schaltzeitpunkt anzeigen kann.

Wieso musst du alle Zeitpunkte einzeln angeben? Du kannst nur eine Angabe machen z. B.

Code Auswählen

[08:00-20:00,+03:00]

oder

Code Auswählen

[08:00-20:00,+10800]

Daraus ergibt sich

08:00, 11:00, 14:00 ...

bei den obigen Angaben, wird, wenn ein Neustart innerhalb des Intervalls stattfindet, ab dem Startzeitpunkt drei Stunden aufaddiert. Dann entstehen logischerweise andere Triggerzeiten alle drei Stunden. Das könnte man auch mit repeatcmd hinbekommen, wenn man das Attribut startup nutzt.

Wenn man dagegen immer das gleiche Zeitraster nutzen möchte (auch nach dem Neustart innerhalb des Zeitintervalls), dann muss man ausgerichtete Timer nutzen:

Hier alle drei Stunden nach Zeitraster

Code Auswählen

[08:00-20:00,+[3]:00]

08:00, 09:00, 12:00, 15:00, 18:00

hier wird auch bei Neustart das Zeitraster eingehalten.

Man kann das Zeitraster auch noch verschieben

Code Auswählen

[08:00-20:00,([+[3]:00]+7200)]

Daraus ergibt sich dann schlussendlich:

08:00, 11:00, 14:00, 17:00

Den nächsten Triggerzeitpunkt siehst im entsprechenden Timer-Reading.

Pnemenz · 15 Mai 2018, 06:14:22

Vielen Dank für die Definition der Zeiten

ZitatDen nächsten Triggerzeitpunkt siehst im entsprechenden Timer-Reading.

Korrektur: nach ca 20 Minuten habe ich das Reading N_timer_01_c01 mit dem nächsten Schaltpunkt
Keine Ahnung, warum das so lange gedauert hat.

ich habe folgende Readings:

Code Auswählen

cmd
cmd_event
cmd_nr
mode
state
timer_01_c01
timer_02_c01

keines davon zeigt den nächsten Zeitpunkt. timer_01_c01 zeigt den Beginn (8:00), timer_02_c01 zeigt das Ende (20:00).
In den Dooftools habe ich bei

Code Auswählen

get userReading_nextTimer_for
das DOIF nicht in der Liste und auch bei händischer Eingabe bekomme ich kein Reading dazu, dass mir den nächsten Schaltzeitpunkt anzeigt.
Ich habe auch versucht das Userreading händisch anzulegen, kein Erfolg.

Code Auswählen

attr Anwa userReadings N_timer_01_c01:timer_01_c01.* {DOIFtoolsNextTimer(ReadingsVal("Anwa","timer_01_c01","none"),"Anwa")}

Damian · 15 Mai 2018, 08:30:28

Zitat von: Pnemenz am 15 Mai 2018, 06:14:22
Vielen Dank für die Definition der Zeiten
Korrektur: nach ca 20 Minuten habe ich das Reading N_timer_01_c01 mit dem nächsten Schaltpunkt
Keine Ahnung, warum das so lange gedauert hat.

ich habe folgende Readings:
Code Auswählen Erweitern
cmd cmd_event cmd_nr mode state timer_01_c01 timer_02_c01
keines davon zeigt den nächsten Zeitpunkt. timer_01_c01 zeigt den Beginn (8:00), timer_02_c01 zeigt das Ende (20:00).
In den Dooftools habe ich bei
Code Auswählen Erweitern
get userReading_nextTimer_for
das DOIF nicht in der Liste und auch bei händischer Eingabe bekomme ich kein Reading dazu, dass mir den nächsten Schaltzeitpunkt anzeigt.
Ich habe auch versucht das Userreading händisch anzulegen, kein Erfolg.
Code Auswählen Erweitern
attr Anwa userReadings N_timer_01_c01:timer_01_c01.* {DOIFtoolsNextTimer(ReadingsVal("Anwa","timer_01_c01","none"),"Anwa")}

Der eigentliche Intervall-Timer wird unter timer_03_c01 erscheinen, wenn er gesetzt wird. Das passiert natürlich erst in der Zeit des Zeitintervalls, also ab 08:00 Uhr.

Pnemenz · 15 Mai 2018, 19:47:08

ZitatDer eigentliche Intervall-Timer wird unter timer_03_c01 erscheinen, wenn er gesetzt wird. Das passiert natürlich erst in der Zeit des Zeitintervalls, also ab 08:00 Uhr.

Damit kann ich aber nicht abfragen bzw feststellen wann der erste Schaltvorgang am Tag passiert.
Dazu müsste ich die Zeitdefinition mit |78 auf alle Tage erweitern. Dann habe ich aber nicht ein Reading, wo die Startzeiten stehen sondern zwei.

Damian · 15 Mai 2018, 20:22:45

Zitat von: Pnemenz am 15 Mai 2018, 19:47:08
Damit kann ich aber nicht abfragen bzw feststellen wann der erste Schaltvorgang am Tag passiert.
Dazu müsste ich die Zeitdefinition mit |78 auf alle Tage erweitern. Dann habe ich aber nicht ein Reading, wo die Startzeiten stehen sondern zwei.

Der erste Schaltvorgang ist immer zum Beginn des Zeitintervalls, also hier im timer_01_c01.

Pnemenz · 15 Mai 2018, 20:36:51

ZitatDer erste Schaltvorgang ist immer zum Beginn des Zeitintervalls, also hier im timer_01_c01.

Genau das meine ich. Ich möchte in einer ReadingsGroup den nächsten Schaltzeitpunkt darstellen. Das ist aber vor dem Startzeitpunkt im timer_01_c01 und dannach im timer_03_c01.

Ich denke, mir fehlt ein Reading Next_timer, in dem der jeweils nächste Schaltpunkt steht.

Damian · 15 Mai 2018, 21:40:17

Zitat von: Pnemenz am 15 Mai 2018, 20:36:51
Genau das meine ich. Ich möchte in einer ReadingsGroup den nächsten Schaltzeitpunkt darstellen. Das ist aber vor dem Startzeitpunkt im timer_01_c01 und dannach im timer_03_c01.

Ich denke, mir fehlt ein Reading Next_timer, in dem der jeweils nächste Schaltpunkt steht.

Dann definierst du dir ein userReading oder DOIF_Reading, bei dem du prüfst, ob in timer_03_c01 etwas drin steht, dann nimmst du den, sonst den anderen.

Pnemenz · 17 Mai 2018, 05:55:01

Vielen Dank, jetzt funktioniert alles wie ich es mir vorstelle.
Schön wäre es, wenn das DOIF mit die Arbeit abnehmnen würde, und in einem READING den nächsten Schaltpunk zeigen würde. Derzeit sind es ja drei plus der waittimer.