Guten Morgen,
inzwischen habe ich mein "neues" fhem relativ gut am laufen und so einiges dazugelernt.
Aber ... es gibt immer ein aber 8)
Ich habe nach dieser Anleitung https://heinz-otto.blogspot.com/2018/07/kalender-in-fhem-einbinden.html (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:
ZitatDas 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
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
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.