DOIF - Zeitintervalle - Startzeitpunkt später als Endzeitpunkt?

[yersinia]

Hallo zusammen,

ich nutze in meinen DOIFs Zeitintervalle zum Beispiel für den Sonnenschutz (Rolladensteuerung). Da es Westseite ist, benötige ich den Sonneschutz nur zwischen Mittag und kurz vor dem Sonnenuntergang. Wenn ich ein DOIF Intervall habe wie

Code Auswählen Erweitern

([13:00-18:00)
( set Dummy; )
DOELSEIF ([19:00])
( set Dummy; )
Dann funktioniert dies auch. Ich sehe dann die Readings

Code Auswählen Erweitern

timer_01_c01 24.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
Soweit, so schön.

Wenn ich jetz aber um sagen wir 15:00 (nach einem update) ein shutdown restart mache oder etwas an der DEF des DOIFs ändere, dann ändern sich die Readings nach

Code Auswählen Erweitern

timer_01_c01 25.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
Natürlich ist um 15:00 dann 13:00 vorbei. Die nächste Möglichkeit wäre am nächsten Tag. Logisch.

Allerdings ergibt sich meinen Beobachtungen nach ein neues Zeitintervall. Dem Beispiel folgend vom 25.04. 13:00 bis 24.04. 18:00. Also umgekehrt und entspräche einem DOIF

Code Auswählen Erweitern

([18:00-13:00)
( set Dummy; )

Möglicherweise ist meine Sorge unbegründet und DOIF ignoriert die Startzeit einfach?

Kann man irgendwie verhindern, dass der Startzeitpunkt später als der Endezeitpunkt ist?
(In meinem Beispiel würde ich erwarten dass der Startzeitpunkt dann neu gesetzt wird - dann auf kurz nach der Initialisierung durch den shutdown restart auf 15:02)

Danke für Input vorab.

[Damian]

Deine Definition ist so nicht sinnvoll.

Du hast ein Zeitintervall von 13:00 Uhr bis 18:00 Uhr ohne DOELSE definiert. Was soll denn um 18:00 Uhr passieren?

[yersinia]

Hi Damian,
ich habe das Beispiel oben stark vereinfacht. DOIF (und die DOELSEIF) haben noch weitere Bedingungen. Insgesamt funktioniert es bei mir auch ohne DOELSE ganz gut. Genau genommen sollen in einem Zeitintervall wenn bestimmte Werte erreicht werden (Temperatur) der Rolladen auf Sonnenschutz gefahren werden (erster DOIF Zweig). Der DOELSEIF Zweig sorgt dafür, dass der Sonnenschutzstand kurz vor Dämmerung wieder deaktiviert (= Rolladen hochgefahren) wird. Bisher hatte ich keinen Bedarf eines DOELSE, würde bei mir dann allerdings so aussehen:

Code Auswählen Erweitern

([13:00-18:00)
( set Dummy; )
DOELSEIF ([19:00])
( set Dummy; )
DOELSE ()

Aber die Frage des Zeitintervalls und der Startzeit später als die Endzeit finde ich noch nicht beantwortet - oder würde sich das durch das DOELSE aufheben? Kann ich mir irgendwie nicht vorstellen...

[CoolTux]

Ich würde hier das Modul AutoShuttersControl (ASC) empfehlen.

[Damian]

Hi Damian,
ich habe das Beispiel oben stark vereinfacht. DOIF (und die DOELSEIF) haben noch weitere Bedingungen. Insgesamt funktioniert es bei mir auch ohne DOELSE ganz gut. Genau genommen sollen in einem Zeitintervall wenn bestimmte Werte erreicht werden (Temperatur) der Rolladen auf Sonnenschutz gefahren werden (erster DOIF Zweig). Der DOELSEIF Zweig sorgt dafür, dass der Sonnenschutzstand kurz vor Dämmerung wieder deaktiviert (= Rolladen hochgefahren) wird. Bisher hatte ich keinen Bedarf eines DOELSE, würde bei mir dann allerdings so aussehen:

Code Auswählen Erweitern

([13:00-18:00)
( set Dummy; )
DOELSEIF ([19:00])
( set Dummy; )
DOELSE ()

Aber die Frage des Zeitintervalls und der Startzeit später als die Endzeit finde ich noch nicht beantwortet - oder würde sich das durch das DOELSE aufheben? Kann ich mir irgendwie nicht vorstellen...

Du musst schon die komplette Bedingung hier posten, sonst lassen sich kaum sinnvolle Aussagen machen.

Bei mehreren DOELSIF ist DOELSE auf der anderen Seite meistens gefährlich, weil man diesen "sonst"-Fall kaum durchschaut.

Deine eigentliche Frage wird hier beantwortet: https://fhem.de/commandref_DE.html#DOIF_Zeitsteuerung_mit_Zeitintervallen

Siehe Zeitintervalle über Mitternacht.

Edit: bei [13:00-18:00] ist das Intervall bis 18:00 Uhr wahr, unabhängig davon, ob es um 13:00 Uhr getriggert hat oder nicht.

[yersinia]

Du musst schon die komplette Bedingung hier posten, sonst lassen sich kaum sinnvolle Aussagen machen.

Bei mehreren DOELSIF ist DOELSE auf der anderen Seite meistens gefährlich, weil man diesen "sonst"-Fall kaum durchschaut.

Ich dachte, das kann ich mir sparen, da ich mich auf die Zeitintervalle fokussieren wollte. Reiche ich nach, wenn ich wieder daheim bin.

Deine eigentliche Frage wird hier beantwortet: https://fhem.de/commandref_DE.html#DOIF_Zeitsteuerung_mit_Zeitintervallen

Siehe Zeitintervalle über Mitternacht.

Edit: bei [13:00-18:00] ist das Intervall bis 18:00 Uhr wahr, unabhängig davon, ob es um 13:00 Uhr getriggert hat oder nicht.

Leider wird meine Frage dort nicht beantwortet. Ja, ich möchte ein Intervall [13:00-18:00] haben. Ja, es wird wahr zwischen 13:00 und 18:00 Uhr. Das funktioniert auch. Sehe ich auch an den Timer-Readings (siehe auch mein Anfangspost).

Wenn ich aber um 15:00 (also genau im Intervallbereich) ein restart durchführe (zB nach Update) oder das DOIF neu initialisiere, dann kann es für heute kein 13:00 Uhr mehr geben. Das nächst-logische wäre also Morgen. Dadurch bekomm ich allerdings ungewollt ein Intervall über Mitternacht.
Aus (vereinfacht) ([13:00-18:00]) { foo } mit den Timer Readings
timer_01_c01 24.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
wird nach Neustart/Neuinitialisierung um 15:00Uhr ein DOIF Device mit den Timer Readings
timer_01_c01 25.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
Und damit ist der Startzeitpunkt (timer_01_c01) später als der Endzeitpunkt (timer_02_c01). Dies ergibt einen ungewollten Timer über Mitternacht (und zwar [18:00-13:00]) bis nach Mitternacht die Timer Zeiten neu kalkuliert werden.

Und genau dieses Verhalten würde ich gern verhindern.

[Damian]

Ich dachte, das kann ich mir sparen, da ich mich auf die Zeitintervalle fokussieren wollte. Reiche ich nach, wenn ich wieder daheim bin.
Leider wird meine Frage dort nicht beantwortet. Ja, ich möchte ein Intervall [13:00-18:00] haben. Ja, es wird wahr zwischen 13:00 und 18:00 Uhr. Das funktioniert auch. Sehe ich auch an den Timer-Readings (siehe auch mein Anfangspost).

Wenn ich aber um 15:00 (also genau im Intervallbereich) ein restart durchführe (zB nach Update) oder das DOIF neu initialisiere, dann kann es für heute kein 13:00 Uhr mehr geben. Das nächst-logische wäre also Morgen. Dadurch bekomm ich allerdings ungewollt ein Intervall über Mitternacht.
Aus (vereinfacht) ([13:00-18:00]) { foo } mit den Timer Readings
timer_01_c01 24.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
wird nach Neustart/Neuinitialisierung um 15:00Uhr ein DOIF Device mit den Timer Readings
timer_01_c01 25.04.2019 13:00:00
timer_02_c01 24.04.2019 18:00:00
timer_03_c02 24.04.2019 19:00:00
Und damit ist der Startzeitpunkt (timer_01_c01) später als der Endzeitpunkt (timer_02_c01). Dies ergibt einen ungewollten Timer über Mitternacht (und zwar [18:00-13:00]) bis nach Mitternacht die Timer Zeiten neu kalkuliert werden.

Und genau dieses Verhalten würde ich gern verhindern.

Es passiert genau das, was in der verlinkten Dokumentation beschrieben ist:

Zeitintervalle werden im Format angegeben: [<begin>-<end>], für <begin> bzw. <end> wird das gleiche Zeitformat verwendet, wie bei einzelnen Zeitangaben. Getriggert wird das Modul zum Zeitpunkt <begin> und zum Zeitpunkt <end>. Soll ein Zeitintervall ohne Zeittrigger lediglich zur Abfrage dienen, so muss hinter der eckigen Klammer ein Fragezeichen angegeben werden (siehe Beispiele weiter unten). Das Zeitintervall ist als logischer Ausdruck ab dem Zeitpunkt <begin> wahr und ab dem Zeitpunkt <end> nicht mehr wahr.

Beispiel:

Code Auswählen Erweitern

DOIF ([13:00-18:00] and [aussen:temp] > 23) (set rollo runter)

Wenn das System um 15:00 Uhr gestartet wird, dann wird mit dem nächsten Trigger ([aussen:temp]) der Rollladen herunter gefahren, wenn das Modul noch nicht in diesem Zustand ist (hier cmd1) und die Temperatur über 23 Grad ist, da das Zeitintervall bis 18:00 Uhr, wie schon geschrieben, wahr ist, ob es um 13:00 Uhr getriggert hat oder nicht.

Die Wahrheit eines Zeitintervalls hängt nicht vom Datum, sondern nur von der Zeitangabe ab.

[yersinia]

Die Wahrheit eines Zeitintervalls hängt nicht vom Datum, sondern nur von der Zeitangabe ab.

Danke Damian, genau das wollte ich bestätigt haben.
(mich hat nur der neu berechnete Timer timer_01_c01 25.04.2019 13:00:00 verunsichert...)

[Damian]

Danke Damian, genau das wollte ich bestätigt haben.
(mich hat nur der neu berechnete Timer timer_01_c01 25.04.2019 13:00:00 verunsichert...)

Das Modul muss ja wissen, wann es wieder triggern soll.