Wie kann es sein, dass von vier Timern einer nicht mehr aktualisiert wird?
2016-10-15 13:29:27 timer_1_c1 15.10.2016 17:00:00
2016-11-01 22:48:13 timer_2_c1 02.11.2016 22:48:13
2016-11-01 23:18:56 timer_3_c1 02.11.2016 17:00:00
2016-11-01 23:18:56 timer_4_c1 02.11.2016 23:02:08
timer_1_c1 wurde seit zwei Wochen nicht mehr aktualisiert, die anderen schon. Der Timer ist eine simple Zeitangabe in dieser Form: [17:00-[Dummy:Reading]].
Aufgefallen ist es mir erst jetzt, weil es sich erst jetzt dank der Winterzeit faktisch auswirkt. Die letzte Aktualisierung fand bei einem FHEM-Neustart statt.
Betroffen ist übrigens nicht nur ein DOIF, sondern mehrere DOIFs dieser Art, wo von vier Timern der "erste" seit dem 15.10. unverändert ist. Alles sind "altgediente" DOIFs, die schon seit langer Zeit problemlos laufen. Sie waren auch seit dem 15.10 praktisch täglich aktiv, also sollten die Timer auch aktuell sein, oder? Irgendwo war mal beschrieben, wann Timer genau aktualisiert werden, aber ich finde es gerade nicht wieder.
Zitat von: Brockmann am 02 November 2016, 10:53:36
Wie kann es sein, dass von vier Timern einer nicht mehr aktualisiert wird?
2016-10-15 13:29:27 timer_1_c1 15.10.2016 17:00:00
2016-11-01 22:48:13 timer_2_c1 02.11.2016 22:48:13
2016-11-01 23:18:56 timer_3_c1 02.11.2016 17:00:00
2016-11-01 23:18:56 timer_4_c1 02.11.2016 23:02:08
timer_1_c1 wurde seit zwei Wochen nicht mehr aktualisiert, die anderen schon. Der Timer ist eine simple Zeitangabe in dieser Form: [17:00-[Dummy:Reading]].
Aufgefallen ist es mir erst jetzt, weil es sich erst jetzt dank der Winterzeit faktisch auswirkt. Die letzte Aktualisierung fand bei einem FHEM-Neustart statt.
Betroffen ist übrigens nicht nur ein DOIF, sondern mehrere DOIFs dieser Art, wo von vier Timern der "erste" seit dem 15.10. unverändert ist. Alles sind "altgediente" DOIFs, die schon seit langer Zeit problemlos laufen. Sie waren auch seit dem 15.10 praktisch täglich aktiv, also sollten die Timer auch aktuell sein, oder? Irgendwo war mal beschrieben, wann Timer genau aktualisiert werden, aber ich finde es gerade nicht wieder.
Da scheint etwas verschüttgegangen zu sein. Poste bitte ein list von diesem Modul.
Gruß
Damian
Hier eines der betroffenen DOIFs:
Internals:
DEF ([LICHT_STATUS] eq "Abend" and [?XMAS_Innen_ctrl] eq "deactivated" and
(([17:00-[Datastore:GL_sleeptime]] and [HAUS_STATUS] =~ "Anwesend|Welcome|Babysitter")
or ([17:00-([23:00]+int(rand(1800)))] and [HAUS_STATUS] =~ "Abwesend|Urlaub")))
(set WZ_Ambilight on)
DOELSE (set WZ_Ambilight off)
NAME WZ_Ambilight_ctrl
NR 368
NTFY_ORDER 50-WZ_Ambilight_ctrl
STATE Licht_aus
TYPE DOIF
Readings:
2016-11-02 11:59:00 Device LICHT_STATUS
2016-11-01 22:48:13 cmd 2
2016-11-01 22:48:13 cmd_event LICHT_STATUS
2016-11-01 22:48:13 cmd_nr 2
2016-11-01 13:55:26 e_HAUS_STATUS_STATE Anwesend
2016-11-02 11:59:00 e_LICHT_STATUS_STATE Mittag
2016-11-01 22:48:13 state Licht_aus
2016-10-15 13:29:27 timer_1_c1 15.10.2016 17:00:00
2016-11-01 22:48:13 timer_2_c1 02.11.2016 22:48:13
2016-11-01 23:18:56 timer_3_c1 02.11.2016 17:00:00
2016-11-01 23:18:56 timer_4_c1 02.11.2016 23:02:08
Condition:
0 InternalDoIf($hash,'LICHT_STATUS','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "Abend" and InternalDoIf($hash,'XMAS_Innen_ctrl','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "deactivated" and ((DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"") and InternalDoIf($hash,'HAUS_STATUS','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) =~ "Anwesend|Welcome|Babysitter") or (DOIF_time($hash,$hash->{realtime}{2},$hash->{realtime}{3},$wday,$hms,"") and InternalDoIf($hash,'HAUS_STATUS','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) =~ "Abwesend|Urlaub"))
Days:
Devices:
0 LICHT_STATUS HAUS_STATUS
all LICHT_STATUS HAUS_STATUS
Do:
0:
0 set WZ_Ambilight on
1:
0 set WZ_Ambilight off
Helper:
event Mittag
globalinit 1
last_timer 4
sleeptimer -1
timerdev LICHT_STATUS
timerevent Mittag
triggerDev LICHT_STATUS
timerevents:
Mittag
timereventsState:
state: Mittag
triggerEvents:
Mittag
triggerEventsState:
state: Mittag
Internals:
0 LICHT_STATUS:STATE XMAS_Innen_ctrl:STATE HAUS_STATUS:STATE
all LICHT_STATUS:STATE XMAS_Innen_ctrl:STATE HAUS_STATUS:STATE
Interval:
0 -1
1 0
2 -1
3 2
Itimer:
all Datastore
Localtime:
0 1476543600
1 1478123293
2 1478102400
3 1478124128
Readings:
Realtime:
0 17:00:00
1 22:48:13
2 17:00:00
3 23:02:08
Regexp:
0:
All:
State:
Time:
0 17:00:00
1 [Datastore:GL_sleeptime]
2 17:00:00
3 ([23:00]+int(rand(1800)))
Timecond:
0 0
1 0
2 0
3 0
Timer:
0 0
1 0
2 0
3 0
Timers:
0 0 1 2 3
Trigger:
Triggertime:
1478102400:
localtime 1478102400
Hash:
1478123293:
localtime 1478123293
Hash:
1478124128:
localtime 1478124128
Hash:
Attributes:
cmdState Licht_an|Licht_aus
comment Steuert LEDs auf Esszimmerschrank und TV-Backlight
icon edit_settings
room _Wohnzimmer
Ich habe bei mir so etwas definiert:
([16:30-16:32] or [16:30-16:31])(set bla bla)
Um 16:32 waren alle Timer aktualisiert.
Die Anfangszeit wird immer erst mit der End-Zeit eines Intervalls aktualisiert.
Ich kann es also bei mir nicht nachstellen.
Die Frage ist, ob du es reproduzierbar nachstellen kannst, dann könnte ich eine Version mit Testausgaben machen, um das Problem einzukreisen.
Gruß
Damian
Zitat von: Damian am 02 November 2016, 17:19:48
Die Anfangszeit wird immer erst mit der End-Zeit eines Intervalls aktualisiert.
Ah, das dürfte das Problem sein.
Das Ende des Intervalls ist eher so eine Art "fail-safe" bzw. hat organisatorische Gründe. Es wird im Regelbetrieb nie erreicht, weil das Reading dafür vorher immer weitergesetzt wird.
Fällt Dir eine Möglichkeit ein, das Problem zu umgehen, ohne das DOIF komplett umzustricken. Ich könnte es täglich zu einem unkritische Zeitpunkt initialisieren, aber solche Basteleien mag ich wenig.
Hast Du an den Timern was verändert? Ich bin mir ziemlich sicher, dass das DOIF im letzten Jahr problemlos funktioniert hat und seitdem habe ich nichts grundlegendes dran geändert...
Zitat von: Brockmann am 02 November 2016, 18:42:34
Ah, das dürfte das Problem sein.
Das Ende des Intervalls ist eher so eine Art "fail-safe" bzw. hat organisatorische Gründe. Es wird im Regelbetrieb nie erreicht, weil das Reading dafür vorher immer weitergesetzt wird.
Fällt Dir eine Möglichkeit ein, das Problem zu umgehen, ohne das DOIF komplett umzustricken. Ich könnte es täglich zu einem unkritische Zeitpunkt initialisieren, aber solche Basteleien mag ich wenig.
Hast Du an den Timern was verändert? Ich bin mir ziemlich sicher, dass das DOIF im letzten Jahr problemlos funktioniert hat und seitdem habe ich nichts grundlegendes dran geändert...
Es wurden vor einiger Zeit (ich meine Anfang des Jahres) einige wichtige Änderung an der Zeitsteuerung vorgenommen.
1. Bei gleichen Zeiten gibt es jetzt nur einen Trigger.
Das ist eine saubere Lösung. Vorher haben verschiedene Timer mit gleicher Zeit mehrfach getriggert. Damit war die Reihenfolge der Abarbeitung bei mehreren Zweigen nicht gewährleistet.
2. Anfangszeit wird erst mit der Berechnung der Endzeit gesetzt
Das hat den Vorteil, dass z. B. bei Sonnenaufgang oder -untergang, wenn die neuberechnete Anfangszeit sich nach hinten verschiebt, nicht ein paar Minuten später noch mal getriggert wird, weil sie jetzt erst mit der Endzeit gesetzt wird.
Eigentlich sollte es in deinem Falle egal sein, ob die Anfangszeit beim ersten Intervall gesetzt wird oder nicht. Denn es würde bei dir aufgrund gleicher Anfangszeiten ohnehin um 17:00 Uhr nur einmal getriggert. Beide Intervalle liegen in einer Bedingung und werden dann korrekt ausgewertet.
Gruß
Damian
Zitat von: Damian am 02 November 2016, 19:19:50
Es wurden vor einiger Zeit (ich meine Anfang des Jahres) einige wichtige Änderung an der Zeitsteuerung vorgenommen.
...
2. Anfangszeit wird erst mit der Berechnung der Endzeit gesetzt
Danke für die Erklärung. Dann habe ich da wohl eine Grauzone genutzt, die es inzwischen nicht mehr gibt. Ich behelfe mir jetzt erstmal damit, dass die betroffenen DOIFs (die nur einen Zeitintervall haben und deshalb wirklich nicht mehr funktionieren) sich im DOELSE-Zweig am Ende selbst initialisieren. Das scheint zu klappen.
Aber was ich ja eigentlich definieren will, ist: Wenn die Bedingungen A und B erfüllt sind und es "nach 17:00 Uhr" ist, dann mach dies und das. Wenn ich das richtig sehe, ist das mit DOIF-Bordmitteln bislang nicht möglich. Wäre aber vielleicht eine Idee für eine Weiterentwicklung? Was ich mir vorstelle, wäre in etwa so:
DOIF ([Lichstatus] eq "Abend" and [?NOW] >= [17:00])(set...)
[?NOW] müsste dabei jeweils durch die aktuelle Uhrzeit ersetzt werden. Bei der Prüfung der Bedingung wird auch nur die Uhrzeit berücksichtigt (also das was da steht und nicht das ganze Datum). Und der Trigger [17:00] sollte beim Auslösen ja ohnehin einen Timer auf 17:00 Uhr am nächsten Tag setzen.
Fände ich eine schöne und elegante Lösung, für die vermutlich nicht nur ich Verwendung hätte. Was meinst Du?
Zitat[?NOW] >= [17:00]
kannst Du als
$hms ge "17:00:00" schreiben, um 17:00 zu triggern und zu fragen ob es 17:00 (NOW) ist ergibt irgendwie keinen Sinn.
Zitat von: Ellert am 04 November 2016, 09:11:18
kannst Du als $hms ge "17:00:00" schreiben, um 17:00 zu triggern und zu fragen ob es 17:00 (NOW) ist ergibt irgendwie keinen Sinn.
oder
... $hm ge "17:00"oder
... [?17:00-00:00]Gruß
Damian
Das es $hm gibt, sehe ich hier zum erstenmal, ist das neu?
Zitat von: Ellert am 04 November 2016, 09:23:15
Das es $hm gibt, sehe ich hier zum erstenmal, ist das neu?
Das habe ich vor längerer Zeit eingebaut, aber noch nicht veröffentlicht.
$hms ge "17:00"
funktioniert auch fast immer ;)
OK, also könnte ich es so machen:
(($hm ge "17:00" or [17:00]) and [LICHT_STATUS] eq "Abend" and ...)(set...)
Wenn die anderen Bedingungen vor 17:00 Uhr schon erfüllt sind, triggert das [17:00] Uhr um 17:00 Uhr und führt die Aktion aus.
Wenn die anderen Bedingungen nach 17:00 Uhr erfüllt werden, triggern sie selbst und das $hm ge "17:00" sorgt dafür, dass der die erste Teilbedingung wahr ist.
Zitat von: Brockmann am 04 November 2016, 11:21:47
OK, also könnte ich es so machen:
(($hm ge "17:00" or [17:00]) and [LICHT_STATUS] eq "Abend" and ...)(set...)
Wenn die anderen Bedingungen vor 17:00 Uhr schon erfüllt sind, triggert das [17:00] Uhr um 17:00 Uhr und führt die Aktion aus.
Wenn die anderen Bedingungen nach 17:00 Uhr erfüllt werden, triggern sie selbst und das $hm ge "17:00" sorgt dafür, dass der die erste Teilbedingung wahr ist.
Wenn dich der Trigger um 00:00 Uhr nicht stört, wäre das eleganter:
([17:00-00:00] and [LICHT_STATUS] eq "Abend" and ...)(set...)
Zitat von: Damian am 04 November 2016, 11:38:33
Wenn dich der Trigger um 00:00 Uhr nicht stört, wäre das eleganter:
Na, das ist ja der springende Punkt, dass ein Intervall eine Krücke wäre, weil die Geräte eben nicht von x bis y laufen sollen, sondern von x bis sie durch andere Faktoren ausgeschaltet werden.
Insofern ist meine Lösung vielleicht weniger elegant, aber dafür universeller. Form follows Function.
Noch eleganter wäre natürlich
($hm ge [17:00])wenn DOIF damit etwas anfangen könnte... ;)
Zitat von: Brockmann am 04 November 2016, 16:27:54
Na, das ist ja der springende Punkt, dass ein Intervall eine Krücke wäre, weil die Geräte eben nicht von x bis y laufen sollen, sondern von x bis sie durch andere Faktoren ausgeschaltet werden.
Insofern ist meine Lösung vielleicht weniger elegant, aber dafür universeller. Form follows Function.
Noch eleganter wäre natürlich
($hm ge [17:00])
wenn DOIF damit etwas anfangen könnte... ;)
$hm ge "17:00" läuft aber zwangsläufig nur bis "00:00". Also ist es genauso ein Intervall von x bis y, allerdings ohne Trigger bei x und y. es ist also identisch zu [?17:00-00:00].
Hinter [17:00] verbirgt sich ja eine Perlfunktion, die genau zum Triggerzeitpunkt wahr ist und sonst nicht, daher ist ein Stringvergleich der Art $hm ge [17:00] leider nicht möglich.
Noch mal zu: ($hm ge [17:00])
Die Zeitfunktion könnte zum Triggerzeitpunkt statt 1 die eigentliche Uhrzeit als String liefern, die ist ja auch wahr. Dass sollte zu den bisherigen Abfragen der Art [17:00] or/and ... kompatibel sein.
Zitat von: Damian am 04 November 2016, 17:36:02
Noch mal zu: ($hm ge [17:00])
Die Zeitfunktion könnte zum Triggerzeitpunkt statt 1 die eigentliche Uhrzeit als String liefern, die ist ja auch wahr. Dass sollte zu den bisherigen Abfragen der Art [17:00] or/and ... kompatibel sein.
Kann ich nicht beurteilen. Aber wie Du richtig angemerkt hast, wäre es ja nichts anderes als ein Intervall von 17:00 bis 0:00 Uhr, das nur um 0:00 Uhr nicht triggert. Aber es ist dann trotzdem nicht mehr wahr, wenn die Kondition von anderer Seite getriggert wird.
Insofern wäre es für das Verständnis vielleicht besser, wenn man die Leute das Intervall auch explizit hinschreiben lässt?
Merkst Du ja an mir... ;)
Zitat von: Brockmann am 04 November 2016, 18:01:04
Kann ich nicht beurteilen. Aber wie Du richtig angemerkt hast, wäre es ja nichts anderes als ein Intervall von 17:00 bis 0:00 Uhr, das nur um 0:00 Uhr nicht triggert. Aber es ist dann trotzdem nicht mehr wahr, wenn die Kondition von anderer Seite getriggert wird.
Insofern wäre es für das Verständnis vielleicht besser, wenn man die Leute das Intervall auch explizit hinschreiben lässt?
Merkst Du ja an mir... ;)
ja, daher ist $hm ge [17:00] das Gleiche wie ([?17:00-00:00] and [17:00]). Wie du schon bemerkt hast, weiß ich nicht, ob die kurze Schreibweise für die User intuitiver wäre, als die bisher mögliche (die zweite).
Zitat von: Damian am 04 November 2016, 17:36:02Die Zeitfunktion könnte zum Triggerzeitpunkt statt 1 die eigentliche Uhrzeit als String liefern, die ist ja auch wahr. Dass sollte zu den bisherigen Abfragen der Art [17:00] or/and ... kompatibel sein.
Was ist bei [0:00]?
Zitat von: Per am 08 November 2016, 12:08:57
Was ist bei [0:00]?
if ("00:00") ist wahr, das passt schon.