Mehrere DOIFs mit wait funktionieren nicht parallel

[Hifi-Ear]

Hat es hier ein generelles Problem?
Einen Dummy nach Wartezeit ausschalten funktioniert, z.B.:

define MOTION dummy
attr MOTION room GROUNDFLOOR
attr MOTION setList on off
attr MOTION webCmd on:off
define MOTIONoff DOIF ([MOTION:"on"]) (set MOTION off)
attr MOTIONoff wait 22

Wird ein zweiter Dummy gleicher Art während der Wartezeit des Ersten auf on gesetzt, bleibt einer der beiden ständig on, ignoriert also das Abschalten nach der Wartezeit.
Mache ich einen Fehler, oder hat es hier noch ein Problem?

Nun, wenn ich die beiden Dummies so zeitverzögert abschalte, funktioniert es für meine Zwecke:

define MOTION dummy
attr MOTION room GROUNDFLOOR
attr MOTION setList on off
attr MOTION webCmd on:off
define MOTIONoff watchdog MOTION:on 00:00:22 MOTION:off IF ([MOTION] eq "on") (set MOTION off);; trigger MOTIONoff .

[Damian]

Hat es hier ein generelles Problem?
Einen Dummy nach Wartezeit ausschalten funktioniert, z.B.:

define MOTION dummy
attr MOTION room GROUNDFLOOR
attr MOTION setList on off
attr MOTION webCmd on:off
define MOTIONoff DOIF ([MOTION:"on"]) (set MOTION off)
attr MOTIONoff wait 22

Wird ein zweiter Dummy gleicher Art während der Wartezeit des Ersten auf on gesetzt, bleibt einer der beiden ständig on, ignoriert also das Abschalten nach der Wartezeit.
Mache ich einen Fehler, oder hat es hier noch ein Problem?

Nun, wenn ich die beiden Dummies so zeitverzögert abschalte, funktioniert es für meine Zwecke:

define MOTION dummy
attr MOTION room GROUNDFLOOR
attr MOTION setList on off
attr MOTION webCmd on:off
define MOTIONoff watchdog MOTION:on 00:00:22 MOTION:off IF ([MOTION] eq "on") (set MOTION off);; trigger MOTIONoff .

Zwei verschiedene Dummys in zwei verschiedenen DOIFs beeinflussen sich nicht, ansonsten hätten wir schon längst große Probleme bei 25.000 DOIF-Definitionen.

Gruß
Damian

[Hifi-Ear]

Vielen Dank, Damian, für die schnelle Reaktion.
Habe es indes mit readingsProxy versucht - gleiches Fehlverhalten.
Also ist das geniale DOIF entlastet!
Da belasse ich es wohl beim Wachhund. Der ist zuverlässig.

Gruß,
Hifi-Ear

[Damian]

Vielen Dank, Damian, für die schnelle Reaktion.
Habe es indes mit readingsProxy versucht - gleiches Fehlverhalten.
Also ist das geniale DOIF entlastet!
Da belasse ich es wohl beim Wachhund. Der ist zuverlässig.

Gruß,
Hifi-Ear

Dann muss da noch eine indirekte Abhängigkeit sein. Wenn du natürlich beide Dummys innerhalb eines DOIF abfragst, dann ist klar dass ein laufender Wait-Timer unterbrochen wird.

[Hifi-Ear]

Habe diesen einfachen Test mit "set Test1 on" und danach gleich "set Test2 on" in der Kommando-Eingabezeile gestartet - funktioniert, beide schalten ab.
Wenn zuerst Test2 gesetzt wird, schalten beide nicht mehr ab.

define Test1 dummy
attr Test1 room Store
attr Test1 setList on off
attr Test1 webCmd on:off
define Test1off DOIF ([Test1:"on"]) (set Test1 off)
attr Test1off wait 15

define Test2 dummy
attr Test2 room Store
attr Test2 setList on off
attr Test2 webCmd on:off
define Test2off DOIF ([Test2:"on"]) (set Test2 off)
attr Test2off wait 20

[Hifi-Ear]

Es hat da noch eine Warnung im Logfile nach Abspeichern der config: WARNING: unsupported character in reading e_SensorAbsenceOn_.* (not A-Za-z/\d_\.-), notify the DOIF module maintainer.
Genannter Sensor ist aber in keinem DOIF verwendet, tut aber was er soll. Habe den Sensor versuchsweise #auskommentiert. Auch dann kommt die Warnung. Hat es da vielleicht irgendwelche Leichen im Code, welche die Timer in den Test-DOIFs ärgern?

[Damian]

Habe diesen einfachen Test mit "set Test1 on" und danach gleich "set Test2 on" in der Kommando-Eingabezeile gestartet - funktioniert, beide schalten ab.
Wenn zuerst Test2 gesetzt wird, schalten beide nicht mehr ab.

define Test1 dummy
attr Test1 room Store
attr Test1 setList on off
attr Test1 webCmd on:off
define Test1off DOIF ([Test1:"on"]) (set Test1 off)
attr Test1off wait 15

define Test2 dummy
attr Test2 room Store
attr Test2 setList on off
attr Test2 webCmd on:off
define Test2off DOIF ([Test2:"on"]) (set Test2 off)
attr Test2off wait 20

Wenn du kein do always gesetzt hast, dann ist klar, dass die Sache nur einmal funktioniert, da du jeweils nur einen Zustand definiert hast.

Gruß

Damian

[Hifi-Ear]

Besten Dank, mit do always geht's. Leider begreife ich es noch nicht: Test1 und Test2 sind doch zwei unabhängig verschiedene Dummies, wieso beeinflussen sie sich denn? Einzeln hat ja jeder der beiden Tests wie erwartet funktioniert, auch ohne do always. Ja, wenn man dann während der Wartezeit von z.B. Test1 nochmals Test1 on setzt, schaltet er nicht ab, das ist klar. Aber was hatte es mit dem Test2 zu tun?
Belaste deine Zeit aber nicht zu sehr. Wenn nicht gerade periodisch Werte ausgelesen werden, setze ich halt immer prophylaktisch do always.

[Damian]

Besten Dank, mit do always geht's. Leider begreife ich es noch nicht: Test1 und Test2 sind doch zwei unabhängig verschiedene Dummies, wieso beeinflussen sie sich denn? Einzeln hat ja jeder der beiden Tests wie erwartet funktioniert, auch ohne do always. Ja, wenn man dann während der Wartezeit von z.B. Test1 nochmals Test1 on setzt, schaltet er nicht ab, das ist klar. Aber was hatte es mit dem Test2 zu tun?
Belaste deine Zeit aber nicht zu sehr. Wenn nicht gerade periodisch Werte ausgelesen werden, setze ich halt immer prophylaktisch do always.

Sie beeinflussen sich nicht. Das, was du beobachtest beruht auf der Tatsache, dass ohne du always ein erneuter Test (ohne Zustandswechsel) nicht funktioniert. Es ist also egal, ob du zuerst mit test2 oder mit test1 beginnst zu testen.

[Hifi-Ear]

Vielen Dank, Damian, für deine Geduld. Habe nochmals getestet. Es ist genau wie von dir erläutert - Alles Super! Jetzt bekommt der Raspi jede Menge DOIFs reingefüttert.

Gruß,
HiFi-Ear