zu dem hier entstandenen -> https://forum.fhem.de/index.php?topic=142783.msg1351980#msg1351980
und jetzt so (oder immer noch) aussenden DOIF RAW
defmod XtenderSet_Max_Solar DOIF ([$SELF:ZuBerechnendeGesamtleistung] > 800 and [$SELF:ZuBerechnendeGesamtleistung] > [$SELF:ZuBerechnendeGesamtleistung_old] and [$SELF:ZuBerechnendeGesamtleistung] <= 2000)\
(set MQTT2_openDTU limit_absolute [$SELF:ZuBerechnendeGesamtleistung])\
DOELSEIF ([$SELF:ZuBerechnendeGesamtleistung] > 0 and [$SELF:ZuBerechnendeGesamtleistung] <= 2000)\
(set MQTT2_openDTU limit_absolute [$SELF:ZuBerechnendeGesamtleistung])
attr XtenderSet_Max_Solar devStateIcon disabled:general_aus@red:initialize initialize:general_an@yellow:disable initialized:general_an@yellow:disable cmd_1.*:general_an@green:disable cmd_2.*:general_an@green:disable
attr XtenderSet_Max_Solar do resetwait
attr XtenderSet_Max_Solar event-on-change-reading ZuBerechnendeGesamtleistung,ZuBerechnendeGesamtleistung_old
attr XtenderSet_Max_Solar event_Readings ZuBerechnendeGesamtleistung: {(2800 - [Studer485_VT:PV_Power_W]) > 2000 ? 800 : (2800 - [Studer485_VT:PV_Power_W])}
attr XtenderSet_Max_Solar group System_2
attr XtenderSet_Max_Solar oldreadings ZuBerechnendeGesamtleistung,oldreadingsAlways
attr XtenderSet_Max_Solar room Xtender
attr XtenderSet_Max_Solar sortby 4
attr XtenderSet_Max_Solar stateFormat state\
<br>\
ZuBerechnendeGesamtleistung
attr XtenderSet_Max_Solar userReadings ZuBerechnendeGesamtleistung_old:ZuBerechnendeGesamtleistung.* { OldReadingsVal("XtenderSet_Max_Solar", "ZuBerechnendeGesamtleistung", "0") }
attr XtenderSet_Max_Solar wait 10:0
irritiert mich folgendes ... alle meine DOIF´s kann ich über das devStateIcon in der Weboberfläche schalten. DIESES Doif verzögert ca 10 Sekunden und wird dann erst bei reload/refresh der Page mit dem aktuellen Status angezeigt. Die anderen machen das sofort. Hat es etwas mit den event_Readings zu tun, oder hat noch jemand eine andere Erklärung?
attr XtenderSet_Max_Solar stateFormat state\
<br>\
ZuBerechnendeGesamtleistung
hatte ich auch schon versuchsweise gelöscht, ohne Änderung des Verhaltens
dein 10s wait bezieht sich doch auf (set MQTT2_openDTU limit_absolute [$SELF:ZuBerechnendeGesamtleistung]) und nicht aufs "hochfahren"? dh das wird jedesmal um 10s verzögert ausgeführt, wenn deine bedingung wahr ist?
wenn das dann auch noch binnen 10s neu getriggett wird, hast du das, dass es niemals ausgeführt und nur noch ggf beim start aktualisiert wird
Ich meinte das zB ein/ausschalten via "klick auf das devStateIcon im browser". Nicht die Funktionalität des DOIF´s
attr XtenderSet_Max_Solar devStateIcon disabled:general_aus@red:initialize initialize:general_an@yellow:disable initialized:general_an@yellow:disable cmd_1.*:general_an@green:disable cmd_2.*:general_an@green:disable
wenn das DOIF aktiv ist (zB cmd_1) und ich das icon anklicke -> disabled .... das dauert ca. 10 sek und Icon (-> was rot werden müsste) ändert sich erst nach refresh der Page. Dies ist das einzige von geschätzt 40 DOIF´s, die nach dem selben Prinzip angelegt sind, was sich so verhält.
nimms doch mal raus und guck dann. versteh den sinn vom wait da ohnehin nicht
Du meinst das wait 10?
Das verhindert ein zu schnelles Hochschalten des erlaubten Stroms. Nach unten "sofort", nach oben mit 10 Sek Verzögerung.
Könnte ich mal rausnehmen, aber dass das was mit Schalten von DevStateIcon zu tun hat, würde mich wundern. Die 10 Sekunden Verzögerung beim Schalten sind auch eher gefühlt als genau 10 Sekunden.
was heisst denn zu schnelles hochschalten? der Wert ist doch da. Wieso dann 10 sek warten? Das wait 10:0 blockiert die Ausführung des ersten Teils für 10 Sekunden. Ich weiß halt nicht, wie das intern im doif modul läuft. Gut möglich, dass das device solang blockiert ist, bis das wait rum ist. das devstateicon wird ja vom modul selbst abhängig sein. Wäre jedenfalls plausibel...
das doif berechnet den Strom den ein AC gekoppelter Mikrowechselrichter leisten darf. Bei jeder Änderung im Haupt-Solarcharger. Wenn er mehr darf wird das verzögert, wenn er weniger darf sofort. Warten, damit die Wahrscheinlichkeit einer Überschneidung (Zeit Steuerkette) minimiert wird. Zu wenig für ein paar Sekunden ist easy. Zuviel für nur ne Millisekunde kann teuer werden.
Ich nehm das wait morgen mal raus. Hab aber zig andere Doifs mit waits und da ist mir noch nie eine Verzögerung beim Schalten aufgefallen.
Ich will es nochmal betonen: mir gehts um das initialize/disable des Doifs, nicht um die Funktionalität.
Zitat von: satprofi am 27 Mai 2026, 09:38:45hallo.
ich häng mich da drann. seit einigen tagen funktioniert das wait attr nicht mehr.neu angelegte DOIF übergehen das attr,alte hingegen haben in readings den wait_timer. hat sich da etwas geändert ? mehrere devices getestet, das wait wird unterschlagen.
Es hat sich an der Stelle im DOIF nichts geändert. Ich gehe davon aus, dass es nicht ein DOIF-Problem ist. Ansonsten - wie immer - ein nachvollziehbares Beispiel mit dem vermeintlichen Fehlverhalten posten.
CFGFN
DEF ([08:00]) (set MQTT2_DVES_8AF3E9 on)
DOELSEIF ([09:33]) (set MQTT2_DVES_8AF3E9 off)
FUUID 6a169543-f33f-3579-c9d9-f42b692f544c391a
MODEL FHEM
NAME Licht_test
NOTIFYDEV global
NR 1012
NTFY_ORDER 50-Licht_test
STATE cmd_1
TYPE DOIF
VERSION 27740 2023-07-10 09:31:11
eventCount 25
READINGS:
2026-05-27 09:33:30 cmd 1
2026-05-27 09:33:30 cmd_event set_cmd_1
2026-05-27 09:33:30 cmd_nr 1
2026-05-27 09:32:25 mode enabled
2026-05-27 09:33:30 state cmd_1
2026-05-27 09:32:25 timer_01_c01 28.05.2026 08:00:00
2026-05-27 09:33:00 timer_02_c02 28.05.2026 09:33:00
VERSION 27740 2023-07-10 09:31:11
eventCount 25
READINGS:
2026-05-27 09:33:30 cmd 1
2026-05-27 09:33:30 cmd_event set_cmd_1
2026-05-27 09:33:30 cmd_nr 1
2026-05-27 09:32:25 mode enabled
2026-05-27 09:33:30 state cmd_1
2026-05-27 09:32:25 timer_01_c01 28.05.2026 08:00:00
2026-05-27 09:33:00 timer_02_c02 28.05.2026 09:33:00
Regex:
accu:
bar:
barAvg:
collect:
attr:
cmdState:
wait:
0:
10
1:
60
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday)
1 ::DOIF_time_once($hash,1,$wday)
days:
do:
0:
0 set MQTT2_DVES_8AF3E9 on
1:
0 set MQTT2_DVES_8AF3E9 off
2:
helper:
NOTIFYDEV global
event timer_2
globalinit 1
last_timer 2
sleeptimer -1
timerdev
timerevent timer_2
triggerDev
DOIF_eventa:
cmd_nr: 1
cmd: 1
cmd_event: set_cmd_1
cmd_1
DOIF_eventas:
cmd_nr: 1
cmd: 1
cmd_event: set_cmd_1
state: cmd_1
timerevents:
timer_2
timereventsState:
timer_2
triggerEvents:
timer_2
triggerEventsState:
timer_2
interval:
intervalfunc:
localtime:
0 1779948000
1 1779953580
realtime:
0 08:00:00
1 09:33:00
time:
0 08:00:00
1 09:33:00
timeCond:
0 0
1 1
timer:
0 0
1 0
timers:
0 0
1 1
triggertime:
1779948000:
localtime 1779948000
hash:
1779953580:
localtime 1779953580
hash:
uiState:
uiTable:
Attributes:
room test
wait 10:60
hier , ein test. schlatet sofort,nix verzögert
Zeitpunkte werden normalerweise auch nicht verzögert.
siehe: https://fhem.de/commandref_DE.html#DOIF_timerWithWait
Zitat von: Damian am 27 Mai 2026, 10:32:12Zeitpunkte werden normalerweise auch nicht verzögert.
siehe: https://fhem.de/commandref_DE.html#DOIF_timerWithWait
das war ja nur beispiel. bei diesem hier ist es mir aufgefallen, nachdem ich Ergänzung hinzugefügt hatte
DEF (([Bewohner] eq "present" and ([08:00-21:00] or [20:00])) or (([Quadbox] eq "on" or [VSX1131:stateAV] eq "on") and [19:00-08:00]) or [FS20_7010f0] eq "on") (set tuya_smartlife_bffee61d5656c19f0e6zas on)
DOELSE (({anwesend_off}) , (set tuya_smartlife_bfb727311ed41a0cc8ycsq off))
FUUID 65cf39e1-f33f-3579-8889-597fdac1da3b48f3
FVERSION 98_DOIF.pm:0.277400/2023-07-10
MODEL FHEM
NAME Anwesend
NOTIFYDEV global,Bewohner,Quadbox,FS20_7010f0,VSX1131
NR 489
NTFY_ORDER 50-Anwesend
STATE cmd_1
TYPE DOIF
VERSION 27740 2023-07-10 09:31:11
eventCount 86
READINGS:
2026-05-27 11:25:06 Device Bewohner
2026-05-27 10:45:04 cmd 1
2026-05-27 10:45:04 cmd_event Bewohner
2026-05-27 10:45:04 cmd_nr 1
2026-05-27 11:25:06 e_Bewohner_STATE present
2026-05-27 11:25:06 e_Quadbox_STATE off
2026-05-27 10:44:48 mode enabled
2026-05-27 10:45:04 state cmd_1
2026-05-27 10:44:48 timer_01_c01 28.05.2026 08:00:00
2026-05-27 10:44:48 timer_02_c01 27.05.2026 21:00:00
2026-05-27 10:44:48 timer_03_c01 27.05.2026 20:00:00
2026-05-27 10:44:48 timer_04_c01 27.05.2026 19:00:00
2026-05-27 10:44:48 timer_05_c01 28.05.2026 08:00:00
Regex:
accu:
bar:
barAvg:
collect:
cond:
Bewohner:
0:
&STATE ^Bewohner$
FS20_7010f0:
0:
&STATE ^FS20_7010f0$
Quadbox:
0:
&STATE ^Quadbox$
VSX1131:
0:
stateAV ^VSX1131$:^stateAV:
attr:
cmdState:
wait:
0:
0
1:
5
300
waitdel:
condition:
0 (::InternalDoIf($hash,'Bewohner','STATE') eq "present" and (::DOIF_time($hash,0,1,$wday,$hms) or ::DOIF_time_once($hash,2,$wday))) or ((::InternalDoIf($hash,'Quadbox','STATE') eq "on" or ::ReadingValDoIf($hash,'VSX1131','stateAV') eq "on") and ::DOIF_time($hash,3,4,$wday,$hms)) or ::InternalDoIf($hash,'FS20_7010f0','STATE') eq "on"
days:
devices:
do:
0:
0 set tuya_smartlife_bffee61d5656c19f0e6zas on
1:
0 ({anwesend_off}) , (set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300)
helper:
NOTIFYDEV global,Bewohner,Quadbox,FS20_7010f0,VSX1131
event present
globalinit 1
last_timer 5
sleeptimer -1
timerdev Bewohner
timerevent present
triggerDev Bewohner
timerevents:
present
timereventsState:
state: present
triggerEvents:
present
triggerEventsState:
state: present
internals:
all Bewohner:STATE Quadbox:STATE FS20_7010f0:STATE
interval:
0 -1
1 0
3 -1
4 3
intervalfunc:
localtime:
0 1779948000
1 1779908400
2 1779904800
3 1779901200
4 1779948000
readings:
all VSX1131:stateAV
realtime:
0 08:00:00
1 21:00:00
2 20:00:00
3 19:00:00
4 08:00:00
time:
0 08:00:00
1 21:00:00
2 20:00:00
3 19:00:00
4 08:00:00
timeCond:
0 0
1 0
2 0
3 0
4 0
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0 1 2 3 4
trigger:
triggertime:
1779901200:
localtime 1779901200
hash:
1779904800:
localtime 1779904800
hash:
1779908400:
localtime 1779908400
hash:
1779948000:
localtime 1779948000
hash:
uiState:
uiTable:
Attributes:
group Beleuchtung
room DOIF
wait 0:5,300
ja, das Beispiel sollte aber das Fehlverhalten demonstrieren.
Wo siehst du das Problem im zweiten Beispiel?
Ich kann auch dort kein Fehlverhalten sehen.
warum schaltet er nicht verzögert aus ? bis vor einfügen des {anwesend_off} klappte es ja.
Du hast or-Bedingungen. e_Quadbox_STATE off reicht nicht, wenn Bewohner_STATE present gilt. Da musst du noch mal über deine Bedingung nachdenken.
Zitat von: Damian am 27 Mai 2026, 12:39:02Du hast or-Bedingungen. e_Quadbox_STATE off reicht nicht, wenn Bewohner_STATE present gilt. Da musst du noch mal über deine Bedingung nachdenken.
aber cmd2 wird ja ausgeführt,nur eben ohne Verzögerung 🤔
Dann musst du den Fall cmd2 posten und nicht cmd1.
DOELSE ist doch cmd2 , oder nicht ?
Das schaltet, wenn present und keine der beiden Geräte on ist.
mit
wait 0:5,300
willst du cmd2 verzögern
gepostet hast du aber:
2026-05-27 11:25:06 Device Bewohner
2026-05-27 10:45:04 cmd 1
2026-05-27 10:45:04 cmd_event Bewohner
2026-05-27 10:45:04 cmd_nr 1
2026-05-27 11:25:06 e_Bewohner_STATE present
2026-05-27 11:25:06 e_Quadbox_STATE off
2026-05-27 10:44:48 mode enabled
2026-05-27 10:45:04 state cmd_1
Will soll man damit ein Fehlverhalten erkennen?
Ich hab ja nur list gepostet. Da steht dich alles drinn, oder ? Warum klappt es nicht mehr ? Habe nur das Script eingefügt, das die restlichen Lampen abdreht. Seitdem gibt's keine Verzögerung mehr
Du musst List kopieren, wenn cmd2 ausgeführt wurde, jetzt zeigt es dir die Variablen und Timer von cmd1 an. Das hilft nicht weiter.
habe es jetzt anders gelöst, tuya kann man mit internen timer schalten, ich machs jetzt so.
hier noch das list von cmd2
DEF (([Bewohner] eq "present" and ([08:00-21:00] or [20:00])) or (([Quadbox] eq "on" or [VSX1131:stateAV] eq "on") and [19:00-08:00]) or [FS20_7010f0] eq "on") (set tuya_smartlife_bffee61d5656c19f0e6zas on)
DOELSE (({anwesend_off}) , (set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300))
FUUID 65cf39e1-f33f-3579-8889-597fdac1da3b48f3
FVERSION 98_DOIF.pm:0.277400/2023-07-10
MODEL FHEM
NAME Anwesend
NOTIFYDEV global,Bewohner,Quadbox,FS20_7010f0,VSX1131
NR 489
NTFY_ORDER 50-Anwesend
STATE cmd_2
TYPE DOIF
VERSION 27740 2023-07-10 09:31:11
eventCount 89
READINGS:
2026-05-27 23:19:24 Device Bewohner
2026-05-27 23:19:19 cmd 2
2026-05-27 23:19:19 cmd_event Quadbox
2026-05-27 23:19:19 cmd_nr 2
2026-05-27 23:19:24 e_Bewohner_STATE present
2026-05-27 23:19:12 e_Quadbox_STATE off
2026-05-27 23:18:32 e_VSX1131_stateAV off
2026-05-27 10:44:48 mode enabled
2026-05-27 23:19:19 state cmd_2
2026-05-27 21:00:00 timer_01_c01 28.05.2026 08:00:00
2026-05-27 21:00:00 timer_02_c01 28.05.2026 21:00:00
2026-05-27 20:00:05 timer_03_c01 28.05.2026 20:00:00
2026-05-27 10:44:48 timer_04_c01 27.05.2026 19:00:00
2026-05-27 10:44:48 timer_05_c01 28.05.2026 08:00:00
2026-05-27 23:19:16 wait_timer no timer
Regex:
accu:
bar:
barAvg:
collect:
cond:
Bewohner:
0:
&STATE ^Bewohner$
FS20_7010f0:
0:
&STATE ^FS20_7010f0$
Quadbox:
0:
&STATE ^Quadbox$
VSX1131:
0:
stateAV ^VSX1131$:^stateAV:
attr:
cmdState:
wait:
0:
0
1:
5
0
waitdel:
condition:
0 (::InternalDoIf($hash,'Bewohner','STATE') eq "present" and (::DOIF_time($hash,0,1,$wday,$hms) or ::DOIF_time_once($hash,2,$wday))) or ((::InternalDoIf($hash,'Quadbox','STATE') eq "on" or ::ReadingValDoIf($hash,'VSX1131','stateAV') eq "on") and ::DOIF_time($hash,3,4,$wday,$hms)) or ::InternalDoIf($hash,'FS20_7010f0','STATE') eq "on"
days:
devices:
do:
0:
0 set tuya_smartlife_bffee61d5656c19f0e6zas on
1:
0 ({anwesend_off}) , (set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300)
helper:
NOTIFYDEV global,Bewohner,Quadbox,FS20_7010f0,VSX1131
event present
globalinit 1
last_timer 5
sleepdevice Quadbox
sleepsubtimer -1
sleeptimer -1
timerdev Bewohner
timerevent present
triggerDev Bewohner
timerevents:
present
timereventsState:
state: present
triggerEvents:
present
triggerEventsState:
state: present
internals:
all Bewohner:STATE Quadbox:STATE FS20_7010f0:STATE
interval:
0 -1
1 0
3 -1
4 3
intervalfunc:
intervaltimer:
localtime:
0 1779948000
1 1779994800
2 1779991200
3 1779901200
4 1779948000
readings:
all VSX1131:stateAV
realtime:
0 08:00:00
1 21:00:00
2 20:00:00
3 19:00:00
4 08:00:00
time:
0 08:00:00
1 21:00:00
2 20:00:00
3 19:00:00
4 08:00:00
timeCond:
0 0
1 0
2 0
3 0
4 0
timer:
0 0
1 0
2 0
3 0
4 0
timers:
0 0 1 2 3 4
trigger:
triggertime:
1779948000:
localtime 1779948000
hash:
1779991200:
localtime 1779991200
hash:
1779994800:
localtime 1779994800
hash:
uiState:
uiTable:
Attributes:
group Beleuchtung
room DOIF
wait 0:5,0
kann keine Verzögerung erkennen, kein waittimer
Ob das eine Ursache ist, kann ich nicht beurteilen, aber du hast im wait für cmd2 zwei Zeiten vorgesehen, hast aber durch die Klammer nur einen Part. Nimm mal das ",0" weg
Man kann sehen, dass wait-timer aktiv war und um 23:19:16 beendet wurde:
2026-05-27 23:19:16 wait_timer no timer
Wäre wait nicht im Einsatz, gäbe es dieses Reading nicht.
Der erste Befehl von cmd2 wird um 5 Sekunden verzögert, der zweite - nach deiner aktuellen Definition - nicht.
Ebenfalls sind keine Events zu sehen, die mit der Schaltzeit übereinstimmen:
2026-05-27 23:19:19 cmd_nr 2
2026-05-27 23:19:24 e_Bewohner_STATE present
2026-05-27 23:19:12 e_Quadbox_STATE off
2026-05-27 23:18:32 e_VSX1131_stateAV off
Fünf Sekunden Verzögerung sind eine kurze Zeitspanne. Du kannst sie zum testen erhöhen, den Auslöser für cmd2 provozieren und schauen, ob das Reading für den waittimer korrekt gesetzt wird.
Edit:
Wenn du mehrere Sequenzen haben willst, die du einzeln verzögern willst, dann musst du auch die korrekte Syntax befolgen:
statt: DOELSE (({anwesend_off}) , (set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300))
DOELSE ({anwesend_off})(set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300)
ZitatOb das eine Ursache ist, kann ich nicht beurteilen, aber du hast im wait für cmd2 zwei Zeiten vorgesehen, hast aber durch die Klammer nur einen Part. Nimm mal das ",0" weg
die 0 steht ja für cmd1, oder?
ZitatFünf Sekunden Verzögerung sind eine kurze Zeitspanne.
ich hatte den 2. immer auf 300 , aber seit änderung des DOELSE wurde das ignoriert. Und die 5 sekunden sollten doch bemerkbar sein.
wait 0:5,0
bedeutet:
0 für cmd1
5 für die erste Sequenz von cmd2
0 für die zweite Sequenz von cmd2
Wenn man die Sequenzen richtig definiert hätte:
DOELSE ({anwesend_off})(set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300)
PS.
Eigentlich solltest du ein alter Hase sein, was die Nutzung des Moduls angeht ;)
Zitat von: Damian am 28 Mai 2026, 08:31:02Wenn man die Sequenzen richtig definiert hätte:
DOELSE ({anwesend_off})(set tuya_smartlife_bfb727311ed41a0cc8ycsq countdown_usb1 300)
PS.
Eigentlich solltest du ein alter Hase sein, was die Nutzung des Moduls angeht ;)
Schande über mich ! Danke !!!
Ohne "wait" fällt das gar nicht auf .....
DOELSEIF ([16:10]) ((set daytime_UBRW HSV 0,46,70 1000),(set daytime_WWNW HSV 40,80,60 1000))