Hallo zusammen,
ich möchte mit DOIF ... DOELSE ein zeitgesteuertes Ereignis realisieren,
welches:
- jede Minute zwischen
- xMinuten vor Sonnenuntergang bis
- yMinuten nach Sonnenaufgang
eine Aktion ausführt (Nachtmodus) (bei mir ein "get <Nachtgeräte> status")
und für den Rest der Zeit, also xMin nach Sonnenaufgang bis yMin vor Sonnenuntergang, die zweite Aktion durchführt (Tagmodus) (bei mir "get <Taggeräte> status")
Ich scheitere an der DOIF-Bedingung für die Definition des Zeitintervalls.
Ich habe schon viel ausprobiert und gelesen und hier im Forum gesucht, aber es will einfach nicht.
Aktueller Stand ist:
DOIF (((({sunset()}-3600)-({sunrise()}+3600)) > 0) and [+60] ) (Aktion_Nachtmodus) DOELSE (Aktion_Tagmodus)
Wo ist hier der Fehler versteckt?
Ich habe auch schon mit den eckigen Klammern [] experimentiert, aber auch ohne Erfolg.
Danke im Voraus für einen Tipp
Jens
([({sunset()}-3600)-({sunrise()}+3600),+60])
siehe: https://fhem.de/commandref_DE.html#DOIF_Intervall-Timer
Hallo Damian,
danke für die schnelle Antwort. Leider funktioniert die Lösung noch nicht korrekt. Die "+60" wird ignoriert und die Aktion wurde nur einmal ausgeführt. ich habe es wie folgt verändert
([({sunset()}-3600)-({sunrise()}+3600)] and [+60])
Damit scheint es nun zu funktionieren.
Vielen Dank aber noch einmal für Lösung zum Hauptproblem mit der Zeitverschiebung zum Sonnenauf- und Untergang!
Also bei mir wird es alle 60 Sekunden ausgeführt, Voraussetzung ist natürlich die erlaubte Wiederholung mit dem Attribut do always. Deine Lösung hat im Gegensatz zu meiner den Nachteil, dass außerhalb des Zeitintervalls weiterhin alle 60 Sekunden getriggert wird, obwohl nichts zu tun gibt.
hmm, komisch.
Ich habe auch das "do" Attribut mit "always" gesetzt.
Ich war auch der Meinung, dass es gestern Abend mit dem ",+60])" funktioniert hat, aber heute Vormittag lief es nicht mehr. UNd wollte auch nicht starten nach einem shutdown restart. Ich stelle das jetzt noch einmal auf ",+60])" um und schaue morgen noch einmal.
Mit ",+60]" scheint es auch jetzt wieder zu laufen.
Der "and [+60])" Eintrag wäre bei mir ja nicht das Problem, da ich in dem Nacht-Zeitraum mehr Module abfrage als im Tag-Zeitraum. Ich nutzt auch den DOELSE-Zweig.
Du musst immer schauen, wann genau der Startzeitpunkt ist, wenn zum Zeitpunkt der Definition der Startzeitpunkt am nächsten Tag liegt, dann beginnt auch das Intervall erst am nächsten Tag. Der dritte Timer, hier alle 60 Sekunden, wird auch nur innerhalb des aktuellen Zeitintervalls gesetzt und sonst nicht.
ok.
Die Änderung von gestern Abend hat dazu geführt, dass der Timer zwar die ganze Nacht lief, aber heute Früh nicht auf den "Tagmodus" (DOELSE) gewechselt hat und nun nichts mehr macht.
Aktuelle Werte un 9:00 Uhr
Aktuell: sunset: 18:44:25
Aktuell: sunrise: 30:09:20 (ist ja die Zeit +24h)
Also geht er jetzt auch nicht in den DOELSE-Zweig.
Ich möchte aber, dass er tagsüber die ELSE-Anweisungen abarbeitet. Also doch wieder das "and [+60]" rein, oder?
define status_abfrage_jede_minute DOIF ([({sunset()}-3600)-({sunrise()}+3600),+60])\
...
DOELSE\
...
attr status_abfrage_jede_minute alias status_abfrage_jede_minute
attr status_abfrage_jede_minute do always
attr status_abfrage_jede_minute room ioBroker
attr status_abfrage_jede_minute wait 0.1,0.1,...:0.1,0.1,...
# FUUID 65e7905e-f33f-dcfe-0beb-205e0a8b59c988be
# MODEL FHEM
# NAME status_abfrage_jede_minute
# NOTIFYDEV global
# NR 137
# NTFY_ORDER 50-status_abfrage_jede_minute
# STATE cmd_2
# TYPE DOIF
# VERSION 28546 2024-02-23 20:11:05
# eventCount 36824
# READINGS:
# 2024-03-08 07:11:38 cmd 2.11
# 2024-03-08 07:11:38 cmd_event timer_2
# 2024-03-08 07:11:38 cmd_nr 2
# 2024-03-08 07:11:38 cmd_seqnr 11
# 2024-03-07 20:55:32 mode enabled
# 2024-03-08 07:11:38 state cmd_2
# 2024-03-08 07:11:37 timer_01_c01 08.03.2024 17:44:25
# 2024-03-08 07:11:37 timer_02_c01 09.03.2024 07:09:20
# 2024-03-08 07:11:38 wait_timer no timer
# condition:
# 0 ::DOIF_time($hash,0,1,$wday,$hms)
# days:
# helper:
# NOTIFYDEV global
# event timer_2
# globalinit 1
# last_timer 3
# sleepdevice timer_2
# sleepsubtimer -1
# sleeptimer -1
# timerdev
# timerevent timer_2
# triggerDev
# DOIF_eventa:
# cmd_nr: 2
# cmd_seqnr: 11
# cmd_event: timer_2
# cmd_2
# DOIF_eventas:
# cmd_nr: 2
# cmd_seqnr: 11
# cmd_event: timer_2
# state: cmd_2
# timerevents:
# timer_2
# timereventsState:
# timer_2
# triggerEvents:
# timer_2
# triggerEventsState:
# timer_2
# interval:
# 0 -1
# 1 0
# intervalfunc:
# 2 ::DOIF_time($hash,0,1,$wday,$hms)
# intervaltimer:
# 0 2
# 1 2
# localtime:
# 0 1709916265
# 1 1709964560
# realtime:
# 0 17:44:25
# 1 07:09:20
# time:
# 0 ({sunset()}-3600)
# 1 ({sunrise()}+3600)
# 2 +60
# timeCond:
# 0 0
# 1 0
# 2 0
# timer:
# 0 0
# 1 0
# 2 0
# timers:
# 0 0 1 2
# triggertime:
# 1709916265:
# localtime 1709916265
# hash:
# 1709964560:
# localtime 1709964560
# hash:
# uiState:
# uiTable:
#
setstate status_abfrage_jede_minute cmd_2
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 cmd 2.11
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 cmd_event timer_2
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 cmd_nr 2
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 cmd_seqnr 11
setstate status_abfrage_jede_minute 2024-03-07 20:55:32 mode enabled
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 state cmd_2
setstate status_abfrage_jede_minute 2024-03-08 07:11:37 timer_01_c01 08.03.2024 17:44:25
setstate status_abfrage_jede_minute 2024-03-08 07:11:37 timer_02_c01 09.03.2024 07:09:20
setstate status_abfrage_jede_minute 2024-03-08 07:11:38 wait_timer no timer
ja, es funktioniert wie programmiert, die kontinuierliche Triggerung läuft, wie ich schon geschrieben habe, nur innerhalb der Zeitintervalls. Am Ende gibt es noch den Endtrigger vom Intervall, das Modul wechselt in cmd 2 und macht dann nichts mehr.
Wenn du die kontinuierliche Triggerung auch im ELSE-Fall haben willst, dann musst du deine Lösung nehmen.
Super danke für die Unterstützung.
Das Thema kann als gelöst angesehen werden.
Schönen Tag noch.