easyESP über DOIF schalten

[rob]

Killah78s Versuch 2 oben hatte ich so verstanden, dass das mit notify klappt, aber mit DOIF in selber Konstellation nicht:

Mein 2. Versuch: Ich habe ein dummy erstellt, welches per notify den S20 schaltet. Wenn ich den Dummy direkt schalte, schaltet auch der S20.
schalte ich den dummy über mein DOIF, sehe ich dass der dummy ein und aus schaltet, aber der S20 bleibt ohne Reaktion.

Das Event scheint ja in beiden Fällen zu kommen, mit und ohne wait:

Code Auswählen Erweitern


ohne wait
2021-11-15 10:22:32.010 DOIF di_fenster2 cmd_event: HM_3E8178
...
mit wait
2021-11-15 10:26:25.993 DOIF di_fenster2 cmd_event: HM_3E8178

Irgendwie scheint der wait_timer u.s. um 10:26:24.540 schon gesetzt zu sein, obwohl das Event erst um 10:26:25.993 kommt. Gibt es ggf. mehrere Events, die in dem ggf. Ausschnitt nicht zu sehen sind?

[Wernieman]

Nee .. er geht über einen Dummy, den er per DOIF schaltet. Ich wollte, das mal komplett ohne DOIF arbeitet. Da er mit Perl-Ebene {} arbeitet, sollte er das eigentlich hinkriegen ...

[killah78]

Der Versuch über den Dummy funktioniert. Also ich hatte anstelle des Fensterkontakts einen dummy erstellt und entsprechend ein DOIF. Die Kombination Dummy und ESP funktioniert ohne Probleme.
Mein Problem ist nur die Kombination von dem Fenstersensor und ESP.

Ich hatte das auch mit einem Notify probiert. Ging aber auch nicht. Und eben auch Direkt oder Perl-Ebene.

Das komische ist auch, wenn ich über den DOIF zB das cmd_1 direkt ausführe, schaltet der ESP, wenn der trigger vom Fenstersensor kommt, sehe ich im DOIF dass ausgelöst wird, aber der ESP schaltet nicht.

Achso, dieser "2. Versuch", den ich gemaht hatte war Folgendes:

Ein Dummy schaltet per notify den ESP.  Klappt.
Dann habe ich den DOIF erstellt, welches auf den Fenstersensor reagiert und den dummy schaltet. (der dummy schaltet dann wieder den ESP per notify). Ergebnis war, das der Fenstersensor den DOIF triggert, ich sehe auch, dass der dummy schaltet (zustandsänderung), aber der ESP bleibt unverändert. So wollte ich prüfen, dass das DOIF funktioniert, denn der dummy wurde ja geschaltet. Aber eben er nachrangige ESP dann nicht.

PS: Ich hatte aber auch ein notify getestet, der auf den FEnstersensor reagiert und den ESP schaltet. Hat nicht funktioniert. Nur eben mit dem Wait.

[rob]

Danke Euch für die Klarstellung. Der Teufel steckt im Detail

...auch mit einem Notify probiert. Ging aber auch nicht...
...wenn ich über den DOIF zB das cmd_1 direkt ausführe, schaltet der ESP, ...

Ich kann es nicht beweisen, aber für mich klingt es danach, als wenn einfach die Teile des DOIF oder Notify alle sehr schnell nacheinander wahr werden würden. So als würde ohne wait mittendrin auf das closed=off getriggert werden und mit wait auf das letzte open/tilted=on.
Auf Kraft möchte ich da aber auch nicht weiterbohren. Bin halt neugierig, ich gebs ja zu

[Damian]

Man kann beim wait-Attribut auch Angaben kleiner eins machen.

Du könntest es auch mit wait 0.1 testen.

[killah78]

Ja, "wait 0.1:0.1" funktioniert auch. Ich merke aber keinen Unterschied in der Verzögerung. Also 0.1 und 1 ist gefühlt gleich.

[Wernieman]

Trickert denn der notify?
Kannst Du (per verbose) sehen, ob überhaupt der Schalt-Befehl zum esp abgesendet wird?

[killah78]

Im Moment ist es wieder ein DOIF. Das Notify war ein Test, hat aber das gleiche Ergebnis geliefert.
Hier siehst du den Event-Monitor mit und ohne wait.
https://forum.fhem.de/index.php/topic,124084.msg1187135.html#msg1187135
In beiden Fällen wird der ESP getriggert. (In dem Fall ohne wait passiert halt nur nix)
Komisch ist, dass der ESP erst getriggert wird und dann erst der DOIF cmd erscheint. Aber wahrscheinlich loggt das Modul erst nach der Ausführung.

[Wernieman]

Wenn wirklich der befehl von FHEM gesendet wird, müste er auf dem Weg zum ESP "verlohren" gehen.

Was mir mal spontan einfällt .. ist Dein WLAN überlastet? häufiger von Stöhrungen betroffen? Das würde eventuell erklähren, warum eine Verzögerung eine Besserung bringt ...