Ankündigung: Intervall-Timer

[Ellert]

Mein Ziel ist es von 06:00-22:00 jeweils um HH:07, HH:27 und HH:47 zu triggern.

Wenn ich jetzt im Intervall definiere

Code Auswählen Erweitern

([06:07-22:00,+00:20]) {Log 1, "Intervall_3"}

dann bezieht sich der relative Timer auf den Definitionszeitpunkt. Ab morgen 06:07 wird dann so getriggert wie ich es vorhabe.

Auch bei jedem FHEM-Neustart im Intervall wird bis zum Ende des Intervalls, ab dem Initialisierungszeitpunkt alle 20 Minuten getriggert.

Habe ich das so richtig verstanden?

[Damian]

Mein Ziel ist es von 06:00-22:00 jeweils um HH:07, HH:27 und HH:47 zu triggern.

Wenn ich jetzt im Intervall definiere

Code Auswählen Erweitern

([06:07-22:00,+00:20]) {Log 1, "Intervall_3"}

dann bezieht sich der relative Timer auf den Definitionszeitpunkt. Ab morgen 06:07 wird dann so getriggert wie ich es vorhabe.

Auch bei jedem FHEM-Neustart im Intervall wird bis zum Ende des Intervalls, ab dem Initialisierungszeitpunkt alle 20 Minuten getriggert.

Habe ich das so richtig verstanden?

So ist es. Besser ist natürlich ausgerichtete Timer zu verwenden, denn diese sind immer gleich.

[FunkOdyssey]

Damit ihr nicht denkt, dass ihr immer alleine seid; ich bin - wie immer - total begeistert von den ständigen neuen Features. Danke.

[Damian]

Bis vor kurzen ging als Zeitberechnung auch [([+:20]+[00:07])] für HH:07, HH:27, HH:47

Das ließe sich auch als Intervalltimer angeben. Leider wird seit der letzten Version diese Zeitberechnung nicht als relativer Timer erkannt (fehlendes Plus-Zeichen am Anfang), daher wird nur noch einmal am Tag geschaltet.

Edit: Ich sehe, dass diese Regelung (ein mal pro Tag schalten) beim Intervalltimer nicht aktiv ist, daher könnte auch funktionieren:

([06:07-22:00,([+:20]+[00:07])])

[Ellert]

Bis vor kurzen ging als Zeitberechnung auch [([+:20]+[00:07])] für HH:07, HH:27, HH:47

Das ließe sich auch als Intervalltimer angeben. Leider wird seit der letzten Version diese Zeitberechnung nicht als relativer Timer erkannt (fehlendes Plus-Zeichen am Anfang), daher wird nur noch einmal am Tag geschaltet.

Dann bleibt also nur diese Lösung?

Code Auswählen Erweitern

([?05:00-22:00] and ([:07] or [:27] or [:47]))

[Damian]

Dann bleibt also nur diese Lösung?

Code Auswählen Erweitern

([?05:00-22:00] and ([:07] or [:27] or [:47]))

Wie gerade festgestellt, vermutlich auch diese:

Code Auswählen Erweitern

([06:07-22:00,([+:20]+[00:07])])

[Damian]

Wie gerade festgestellt, vermutlich auch diese:

Code Auswählen Erweitern

([06:07-22:00,([+:20]+[00:07])])

Wie gerade getestet: es funktioniert tatsächlich

Das Modul macht inzwischen mehr, als ich mir ausgedacht habe. Sind wir schon bei KI?

Nicht, dass wir nicht genügend Alternativen hätten

Code Auswählen Erweitern

([06:00-22:00,+:20])

mit wait 7 Minuten verzögern

[Damian]

Version v.05. Ich musste noch etwas nachhelfen. Jetzt funktionieren wieder grundsätzlich ausgerichtete Timer mit Berechnung (insbesondere mit Zeitverschiebung)

z. B.

Fünfzehn Sekunden nach einer vollen Minute

Code Auswählen Erweitern

[([+:01]+[00:00:15])]

Wer so etwas braucht. 

[Ellert]

Version v.05. Ich musste noch etwas nachhelfen. Jetzt funktionieren wieder grundsätzlich ausgerichtete Timer mit Berechnung (insbesondere mit Zeitverschiebung)

z. B.

Fünfzehn Sekunden nach einer vollen Minute

Code Auswählen Erweitern

[([+:01]+[00:00:15])]

Wer so etwas braucht. 

Code Auswählen Erweitern

([06:07-22:00,([+:20]+[00:07])])
Startet mit dem korrekten Timer.
Auf die Idee, den relativen Timer so zu berechnen wäre ich vermutlich nicht gekommen, danke für den Tip.

Es gibt Warnungen mit V0.5 beim Neustart

2018.05.09 07:34:29.764 1: PERL WARNING: "my" variable $time masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 1571, <$fh> line 192.
2018.05.09 07:34:29.982 1: PERL WARNING: "my" variable $wday masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2679, <$fh> line 192.
2018.05.09 07:34:29.984 1: PERL WARNING: "my" variable $hms masks earlier declaration in same scope at ./FHEM/98_DOIF.pm line 2680, <$fh> line 192.

[Damian]

Code Auswählen Erweitern

([06:07-22:00,([+:20]+[00:07])])
Startet mit dem korrekten Timer.
Auf die Idee, den relativen Timer so zu berechnen wäre ich vermutlich nicht gekommen, danke für den Tip.

Es gibt Warnungen mit V0.5 beim Neustart

Dass Berechnungen mit ausgerichteten Timern funktionieren, war mehr oder weniger Zufall. Ich käme nicht auf die Idee, dass HH:07, HH:27, HH:47 für jemanden wichtig sein kann. Ich hätte gedacht, dass HH:00, HH:20 und HH:40 ausreichend wäre.

Mit v0.05 funktionieren zumindest jetzt auch Berechnungen mit ausgerichteten Timern, damit kann man sicherlich auch Unsinn berechnen.

Die Warnungen baue ich noch aus.

Übrigens, man kann auch mit Sekunden rechnen

Code Auswählen Erweitern

[([+:20]+[00:07])] entspricht

Code Auswählen Erweitern

[([+:20]+420)]

oder wie wäre es mit "ausgerichtetem Zufall":

Code Auswählen Erweitern

[([+:20]+rand(120))]

[Ellert]

Ich käme nicht auf die Idee, dass HH:07, HH:27, HH:47 für jemanden wichtig sein kann.

Ich hole mir Daten von einer in der Nähe liegenden Wetterstation, die alle 20 min aktualisiert, als ich das eingebaut habe lagen die optimale Zeitpunkte zum Abholen der Daten bei HH:07, HH:27, HH:47  und nachts benötige ich die Daten nicht.

[Damian]

Ich hole mir Daten von einer in der Nähe liegenden Wetterstation, die alle 20 min aktualisiert, als ich das eingebaut habe lagen die optimale Zeitpunkte zum Abholen der Daten bei HH:07, HH:27, HH:47  und nachts benötige ich die Daten nicht.

Klar, irgendwie so etwas habe ich mir schon gedacht.

[Damian]

Bereinigte Version v.06 im ersten Post.

[Ellert]

Ich habe im Wiki einen Hinweis zu dem zukünftig geänderten checkReadingEvent eingefügt https://wiki.fhem.de/wiki/DOIF

[Damian]

OK, ich werde noch die Doku dazu anpassen.

Edit: Die Beschreibung zu checkReadingEvent lautet jetzt:

Readingauswertung bei jedem Event des Devices   

Bei Angaben der Art [<Device>:<Reading>] wird das Modul getriggert, wenn ein Ereignis zum angegebenen Device und Reading kommt. Soll das Modul, wie bei Statusangaben der Art [<Device>], auf alle Ereignisse des Devices reagieren, so muss das Attribut auf Null gesetzt werden.

Bemerkung: In früheren Versionen des Moduls, war checkReadingEvent 0 per default intern voreingestellt gewesen.