Ankündigung: Intervall-Timer

Damian · 21 April 2018, 21:42:17

Ich plane sogenannte Intervall-Timer zu realisieren:

Die Syntax

[<beginn>-<ende>,<relativer Timer>]

Beispiel:

[10:00-12:00,+00:01]

Zwischen 10 und 12 Uhr wird im Minutentakt getriggert.

Der relative Timer wird mit Beginn gestartet und endet mit Ende des Zeitintervalls. Es ist nicht das Gleiche, wie

Code Auswählen

[10:00-12:00] and [+00:01] , denn hier wird auch außerhalb des Zeitintervalls getriggert.

Natürlich sollen ebenso indirekte Timer oder auch Timer-Funktionen oder Zeitberechnungen kombinierbar mit Wochentagen möglich sein.

z. B.

Code Auswählen

[{sunrise()}-[ende:state],+(rand(300)+100)|Sa So]

Edit: aktuelle Version wurde eingecheckt

Ellert · 04 Mai 2018, 08:56:10

Ich wüsste schon ein paar Anwendungen dafür.

Damian · 04 Mai 2018, 10:15:55

Zitat von: Ellert am 04 Mai 2018, 08:56:10
Ich wüsste schon ein paar Anwendungen dafür.

ja, man könnte damit elegant bestimme Probleme lösen, ohne dass dauerhaft getriggert wird. Ich muss jetzt nur noch dazu kommen es umzusetzen

Damian · 06 Mai 2018, 19:14:58

Version v0.1 im ersten Post angehängt.

Es sollten alle genannten Features funktionieren. Z. Zt. kann man noch unsinnige Angaben machen (Intervalle mit einer Intervallgrenze, absolute Intervalltimer, ...), das werde ich in der nächsten Version abfangen.

Intervalltimer dürfen nicht mit Fragezeichen beginnen.

Wenn sich der Definitionszeitpunkt innerhalb eines Zeitintervall befindet, wird zum Definitionszeitpunkt der Intervalltimer gesetzt:

Bsp. 1 Um 20:01:05 Uhr wird definiert:

Code Auswählen

DOIF ([19:00-21:00,+00:01])

so lauten die nächsten Trigger 20:02:05, 20:03:05...20:59:05 und um 21:00 für cmd_2, am nächsten Tag dann: 19:00, 19:01,...20:59 und 21:00 für cmd_2

Bsp. 2 Um 20:01:05 Uhr wird definiert:

Code Auswählen

DOIF ([19:00-21:00,+:01])

so lauten die nächsten Trigger 20:02:00, 20:03:00...20:59:00 und um 21:00 für cmd_2, am nächsten Tag dann: 19:00, 19:01,...20:59 und 21:00 für cmd_2

Indirekte Timer funktionieren ebenfalls, sogar mit sofortiger Auswertung der Intervallgrenzen bei Änderung:

Bsp. 3 Um 20:01:05 Uhr wird definiert:

Code Auswählen

set begin 20:30
set end 21:00

Code Auswählen

DOIF ([[begin]-[end],+:01])

kein Timer triggert, da 20:30 Uhr noch nicht erreicht, die ersten Trigger wären um 20:30, 20:31, ...

mit

Code Auswählen

set begin 20:00

beginnt der Timer zu triggern um 20:02, 20:03, ...

ebenso kann man vorzeitig Intervalltimer beenden, indem man die Intervallgrenze verschiebt.

z. B. mit

Code Auswählen

set end 20:01

Anmerkung: Intervalltimer triggern nie außerhalb des Zeitintervalls inkl. Wochentagauswertung

Ellert · 06 Mai 2018, 19:40:50

Wenn ich richtig verstanden habe, würde ich

bisher

Code Auswählen

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

durch neu ersetzen können

Code Auswählen

([05:07-22:00;+:20])

Damian · 06 Mai 2018, 19:43:47

Zitat von: Ellert am 06 Mai 2018, 19:40:50
Wenn ich richtig verstanden habe, würde ich

bisher
Code Auswählen Erweitern
([?05:00-22:00] and ([:07] or [:27] or [:47]))

durch neu ersetzen können
Code Auswählen Erweitern
([05:07-22:00;+:20])

ja, mit dem Nebeneffekt, dass nach 22:00 Uhr bis 05:00 Uhr kein Timer mehr gesetzt wird und das DOIF-Modul außerhalb des Zeitintervalls nicht getriggert wird

Ellert · 06 Mai 2018, 23:46:33

Mit Version 0.1 nach Neustart gibt es beim Anlegen folgender Definition

Code Auswählen

define IntervallTimer DOIF ([05:07-22:00;+:20])
die Fehlermeldung

ZitatIntervallTimer DOIF: no right bracket: ([05:07-22:00
Unknown command +:20]), try help.

Das Semikolon scheint Probleme zu machen.

Damian · 07 Mai 2018, 08:50:30

Zitat von: Ellert am 06 Mai 2018, 23:46:33
Mit Version 0.1 nach Neustart gibt es beim Anlegen folgender Definition
Code Auswählen Erweitern
define IntervallTimer DOIF ([05:07-22:00;+:20])
die Fehlermeldung
Das Semikolon scheint Probleme zu machen.

In der Kommandozeile musst du es doppeln -> bekannte FHEM-Problematik

Man könnte auch anderes Trennzeichen definieren, allerdings sind | (Trennzeichen für Wochentage) und , (Trennzeichen für Default-Werte) schon vergeben.

Edit: Ich habe Version v0.2 mit Komma im ersten Post angehängt, da das Komma bei Zeitintervallen nicht für Default-Werte benutzt wird, kann man es an dieser Stelle als Trennzeichen nutzen

z. B.

Code Auswählen

DOIF ([[beginn,"09:00"]-[end],+:20])

Damian · 07 Mai 2018, 23:11:37

Version v0.3 im ersten Post mit genauerer Syntaxprüfung und Doku - eincheckbereit.

Ellert · 08 Mai 2018, 11:42:58

Zitat von: Damian am 07 Mai 2018, 23:11:37
Version v0.3 im ersten Post mit genauerer Syntaxprüfung und Doku - eincheckbereit.

Ich habe startup und Intervall-Timer in der Kurzreferenz von V 0.3 ergänzt , commandref_join.pl liefert keine Fehler.

Damian · 08 Mai 2018, 13:42:52

Zitat von: Ellert am 08 Mai 2018, 11:42:58
Ich habe startup und Intervall-Timer in der Kurzreferenz von V 0.3 ergänzt , commandref_join.pl liefert keine Fehler.

ok, dann noch mal gut testen. Diese Version hat bereits CheckReadingEvent 1 intern voreingestellt. Das muss ich in der Doku noch berücksichtigen.

Ellert · 08 Mai 2018, 15:46:54

Beide DOIF wurde ausserhalb des Zeitintervalls definiert

Die Syntax

Code Auswählen

([14:07-16:00,+:20]) {Log 1, "Intervall_1"}
liefert

Zitat
2018.05.08 14:07:00.016 1: Intervall_1
2018.05.08 14:20:00.017 1: Intervall_1
2018.05.08 14:40:00.017 1: Intervall_1
2018.05.08 15:00:00.017 1: Intervall_1

auf die volle Stunde ausgerichtete Triggerzeitpunkte,

Diese Syntax

Code Auswählen

([12:07-14:00,+00:20]) {Log 1, "Intervall_2"}
liefert

Zitat
2018.05.08 12:07:00.016 1: Intervall_2
2018.05.08 12:27:00.016 1: Intervall_2
2018.05.08 12:47:00.017 1: Intervall_2
2018.05.08 13:07:00.016 1: Intervall_2
2018.05.08 13:27:00.016 1: Intervall_2
2018.05.08 13:47:00.016 1: Intervall_2

auf den Startzeitpunkt ausgerichtete Triggerzeitpunkte.

Das ging aus den Angaben im ersten Beitrag nicht so deutlich hervor. Gut, dass es beide Varianten gibt.

Ellert · 08 Mai 2018, 16:29:43

Abhängig vom Definitionszeitpunkt vor dem Zeitintervall wird der Timer unterschiedlich gesetzt.

Zitat
Internals:
DEF ([16:07-18:00,+00:20]) {Log 1, "Intervall_3"}
MODEL FHEM
NAME IntervallTimer2
NR 166
NTFY_ORDER 50-IntervallTimer2
STATE initialized
TYPE DOIF
READINGS:
2018-05-08 15:57:15 cmd 0
2018-05-08 15:57:15 mode enabled
2018-05-08 15:57:15 state initialized
2018-05-08 15:57:15 timer_01_c01 08.05.2018 16:07:00
2018-05-08 15:57:15 timer_02_c01 08.05.2018 18:00:00
2018-05-08 15:57:15 timer_03_c01 08.05.2018 16:17:15

hier ist der Bezugspunkt der Definitionszeitpunkt

Zitat
Internals:
DEF ([16:27-18:00,+00:20]) {Log 1, "Intervall_3"}
MODEL FHEM
NAME IntervallTimer2
NR 166
NTFY_ORDER 50-IntervallTimer2
STATE initialized
TYPE DOIF
READINGS:
2018-05-08 16:02:53 cmd 0
2018-05-08 16:02:53 mode enabled
2018-05-08 16:02:53 state initialized
2018-05-08 16:02:53 timer_01_c01 08.05.2018 16:27:00
2018-05-08 16:02:53 timer_02_c01 08.05.2018 18:00:00
Timer 03 wird noch nicht gesetzt

und hier wird Timer 03 zum Definitionszeitpunk nicht berechnet, sondern erst beim Intervallbeginn.

Durch dieses unterschiedliche Verhalten wird die Ausrichtung der Triggerpunkte nicht immer gleich gesetzt.

Würde sich die Ausrichtung der Triggerpunkte bei Neustart ändern?
Ja, habe ich gerade probiert.

Damian · 08 Mai 2018, 16:53:18

Dann ist da noch ein Bug drin, denn vor dem Intervallbeginn darf noch kein Intervalltimer gesetzt werden.

Edit: Auf der anderen Seite landet der errechnete Intervalltimer zum Zeitpunkt der Definition im Zeitintervall, daher ist es gar nicht so falsch, zumal der Intervalltimer ohnehin bei nicht ausgerichteten Timern, wenn sie innerhalb des Zeitintervalls definiert werden, sich nicht am Intervallbeginn orientiert, sondern am Definitionszeitpunkt

Damian · 08 Mai 2018, 18:36:50

Version v0.4 im ersten Post. Jetzt werden grundsätzlich keine Intervalltimer gesetzt, wenn der Definitionszeitpunkt außerhalb des Zeitintervalls liegt.