DOIF und (laaaanges) wait

[roemi]

Guten Morgen,

inzwischen habe ich mein "neues" fhem relativ gut am laufen und so einiges dazugelernt.
Aber ... es gibt immer ein aber 
Ich habe nach dieser Anleitung https://heinz-otto.blogspot.com/2018/07/kalender-in-fhem-einbinden.html den Abfallkalender meiner Stadt eingebunden und lasse mir nun Rest- und Biomüll anzeigen. Top.
Ich wollte nun noch den Hinweis "Morgen" und "Heute" mit unterbringen was mir auch auf einfach Art und Weise gelungen ist.
Das DOIF schreibt im Dummy v_tonne ins Reading "tag" gleich zu Beginn um 12:00 "Morgen" und dann, nach einer zwölfstündiger Wartezeit "Heute".
Funktioniert auch einwandfrei.

In der Referenz heißt es aber wörtlich:

Das Aufspalten einer kommagetrennten Befehlskette in eine Befehlssequenz, wie im obigen Beispiel, sollte nicht vorgenommen werden, wenn keine Verzögerungen zwischen den Befehlen benötigt werden. Denn bei einer Befehlssequenz werden Zwischenzustände cmd1_1, cmd1_2 usw. generiert, die Events erzeugen und damit unnötig FHEM-Zeit kosten.

Auch wenn mein DOIF selbst keine Komma's beinhaltet, habe ich den Eindruck das in den 12 Stunden fhem nicht reagiert wie es soll. Mehrere Device waren nicht erreichbar ... sehr komisch.
Allerdings bin ich mir auch nicht sicher ob mit diesem Hinweis das "wait" gemeint ist.

Nun meine Frage: Ist die Lösung mit dem "wait" eine blöde Idee oder sollte ich an anderer Stelle suchen?

Hier das DOIF

Code Auswählen Erweitern

Internals:
   DEF        ([v_tonne] ne 0)(setreading v_tonne tag Morgen) (setreading v_tonne tag Heute) DOELSE (setreading v_tonne tag 0)
   FUUID      63da8498-f33f-dc64-83ad-3bc003a004d0b33e
   MODEL      FHEM
   NAME       d_tonne
   NOTIFYDEV  global,v_tonne
   NR         214
   NTFY_ORDER 50-d_tonne
   STATE      cmd_1
   TYPE       DOIF
   VERSION    26938 2023-01-01 18:13:32
   READINGS:
     2023-02-01 16:29:59   Device          v_tonne
     2023-02-02 04:29:59   cmd             1.2
     2023-02-02 04:29:59   cmd_event       v_tonne
     2023-02-02 04:29:59   cmd_nr          1
     2023-02-02 04:29:59   cmd_seqnr       2
     2023-02-01 16:29:59   e_v_tonne_STATE HIS Restmüll, 2-wöchentliche Abfuhr
     2023-02-01 16:29:11   mode            enabled
     2023-02-02 04:29:59   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       v_tonne:
         0:
           &STATE     ^v_tonne$
   attr:
     wait:
       0:
         0
         43200
       1:
         0
   condition:
     0          ::InternalDoIf($hash,'v_tonne','STATE') ne 0
   do:
     0:
       0          setreading v_tonne tag Morgen
       1          setreading v_tonne tag Heute
     1:
       0          setreading v_tonne tag 0
   helper:
     NOTIFYDEV  global,v_tonne
     globalinit 1
     last_timer 0
     sleeptimer -1
   internals:
     all         v_tonne:STATE
   perlblock:
   uiState:
   uiTable:
Attributes:
   room       Dummy
   wait       0,43200:0

Vielen Dank schon mal ...

Römi

[Damian]

Grundsätzlich kann wait eine "lange" Verzögerung darstellen, das sollte auch immer funktionieren. Allerdings ist zu bedenken, dass wenn ein System zwischendurch herunter gefahren wird, ein noch nicht abgelaufener wait-Timer nicht neu aufgesetzt wird - eine verzögerte Ausführung findet dann nicht mehr statt.

[roemi]

Vielen Dank,

also ist meine Vorgehensweise erstmal nicht grundsätzlich falsch.
Gut, dann werde ich das Verhalten weiter beobachten und nach einem anderen Grund suchen müssen.

Davon abgesehen habe ich, auch aus dem von Dir genannten Grund, mir bereits überlegt das "wait" gegen ein "at" zu tauschen.

Danke Dir!!