Einer von vier Timern eines DOIF wird nicht mehr aktualisiert

Begonnen von Brockmann, 02 November 2016, 10:53:36

Vorheriges Thema - Nächstes Thema

Brockmann

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.

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

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

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

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...

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

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?


Ellert

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.


Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

Das es $hm gibt, sehe ich hier zum erstenmal, ist das neu?

Damian

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 ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

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.

Damian

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...)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

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...  ;)


Damian

#14
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF