Hallo zusammen,
da meine alten Intertechno Steckdosen nicht mehr zuverlässig auf die abgesetzten Schaltbefehle reagieren, habe ich mir nun einige Tasmota Plugs zugelegt um die IT Steckdosen zu ersetzen. Diese habe ich als MQTT2_Devices angelegt und lassen sich auch via MQTT2 Server device über die Weboberfläche schalten.
Für die Automatisierung meines AVR Recievers habe ich mir einzelne notifys angelegt wie z.B. folgendes um das Radio einzuschalten:
WZ_AVR_Radio:.* {
if ($EVENT eq "on")
{
fhem ("set WZ_Multimedia on");
system ("sleep 1; irsend SEND_START Denon KEY_POWER; sleep 1; irsend SEND_STOP Denon KEY_POWER;
sleep 1; irsend SEND_START Denon KEY_TUNER; sleep 1; irsend SEND_STOP Denon KEY_TUNER");
}
else
{
system ("irsend SEND_START Denon KEY_GAMES; sleep 1; irsend SEND_STOP Denon KEY_GAMES;
irsend SEND_START Denon KEY_POWER2; sleep 1; irsend SEND_STOP Denon KEY_POWER2");
fhem ("sleep 1; set WZ_Multimedia off");
}
}
WZ_Multimedia ist hierbei die Steckdose in der der AVR eingesteckt ist, und über die folgenden System Befehle (irsend...) wird dieser dann über einen Infrarotsender (LIRC) eingeschalten.
Nun ist WZ_Multimedia keine IT Steckdose mehr sondern ein MQTT2_Device. Allerdings gibt es jetzt ein Timingproblem. Bei der Ausführung passiert zunächst kurz nix und dann wird die Steckdose eingeschalten, der AVR bleibt aber aus.
Für mich wirkt es so als ob das einschalten der Steckdose über den MQTT Server verzögert wird. Das ist halt blöd weil das ding ja dann noch gar keinen Saft hat wenn der IR Sender die Einschaltbefehle absetzt.
Ich habe schon versucht mit zusätzlichen sleeps zu arbeiten oder die externen Befehle über "qx" oder `` auszuführen, bin aber auf keinen grünen Zweig gekommen.
Habt ihr eine Idee?
Der MQTT Server an sich reagiert nicht verzögert, aber es gibt viel Faktoren, die eine Verzögerung hervorrufen (Freezes in Fhem, Netzwerkauslastung, der Aktor selbst etc.).
MQTT Geräte geben aber eine Rückmeldung (bidirektional), d.h. du kannst auf das entsprechende Reading reagieren und erst weitermachen, wenn der Aktor geschaltet hat.
Ansonsten sollte auch ein if ($EVENT eq "on")
{
fhem ("set WZ_Multimedia on; sleep 5 quiet; system ("irsend SEND_START Denon KEY_POWER; sleep 1; irsend SEND_STOP Denon KEY_POWER;
sleep 1; irsend SEND_START Denon KEY_TUNER; sleep 1; irsend SEND_STOP Denon KEY_TUNER") ");
}möglich sein.
ist das sleep innerhalb des "system" nicht blockierend?
Mus gestehen, das ich es deshalb in ein externes Script auslagern würde und dieses dann mit Bordmitteln starten würde (und dann auch im Hintergrund) ..
ich würde das vorgeschlagene FHEM sleep von frober nicht zeit sondern event getriggert und "benannt" machen:
set WZ_Multimedia on; sleep WZ_Multimedia:on WZ_M quiet; system ...
Das setzt voraus, das Tasmota Device ist so eingerichtet, dass dieser event wirklich sauber kommt, Beispiel:
2023-04-28 12:06:36 MQTT2_DEVICE MQTT2_DVES_A55730 set_on
2023-04-28 12:06:36 MQTT2_DEVICE MQTT2_DVES_A55730 on
2023-04-28 12:06:47 MQTT2_DEVICE MQTT2_DVES_A55730 set_off
2023-04-28 12:06:47 MQTT2_DEVICE MQTT2_DVES_A55730 off
Die Wlan Dosen brauchen in Abhängigkeit von Zeit Raum und Sonnenstand ja manchmal mehr als 5 sec - und man will ja die Bedienkette nicht unnötig lang machen.
Zitat von: Wernieman am 28 April 2023, 10:34:20ist das sleep innerhalb des "system" nicht blockierend?
Mus gestehen, das ich es deshalb in ein externes Script auslagern würde und dieses dann mit Bordmitteln starten würde (und dann auch im Hintergrund) ..
Da war ich mir auch nicht sicher. Alternative wäre ein "wait 1".
Soweit ich das gelesen habe.
@Otto, stimmt habe ich nicht dran gedacht...
Ottos Lösung funktioniert aber alleine auch nicht zuverlässig, wenn der WLAN-Aktor - aus welchen Gründen auch immer - überhaupt nicht reagiert.
Meine bevorzugte Lösung wäre ein sequence (https://commandref.fhem.de/#sequence) device, das den abgesetzten Befehl und die Rückmeldung des Aktors innerhalb einer Zeitspanne auswertet. Mit dem notify würde ich dann auf das sequence triggern.
Habe es jetzt so wie Otto gelöst und das sleep event basiert umgebaut. Nun passt es mit dem Timing:
WZ_AVR_Radio:.* {
if ($EVENT eq "on")
{
fhem ("set WZ_Multimedia on;
sleep WZ_Multimedia:on ID_1 quiet;
\"irsend SEND_START Denon KEY_POWER;; sleep 1;; irsend SEND_STOP Denon KEY_POWER\";
\"irsend SEND_START Denon KEY_TUNER;; sleep 1;; irsend SEND_STOP Denon KEY_TUNER\"");
}
else
{
fhem ("\"irsend SEND_START Denon KEY_GAMES;; sleep 1;; irsend SEND_STOP Denon KEY_GAMES\";
\"irsend SEND_START Denon KEY_POWER2;; sleep 1;; irsend SEND_STOP Denon KEY_POWER2\";
set WZ_Multimedia off");
}
fhem ("sleep 10; cancel ID_1 quiet");
}
Für den Fall dass die WLAN Steckdose mal nicht erreichbar ist, löscht das cancel am Ende des notifys nach 10 Sekunden das sleep. Damit werden ungewollten Schalthandlungen vermieden wenn die Steckdose dann wieder online ist.
Vielen Dank für die schnellen Antworten :)
Zitat von: Awtomat am 28 April 2023, 18:10:58Habe es jetzt so wie Otto gelöst und das sleep event basiert umgebaut. Nun passt es mit dem Timing:
WZ_AVR_Radio:.* {
if ($EVENT eq "on")
{
fhem ("set WZ_Multimedia on;
sleep WZ_Multimedia:on ID_1 quiet;
\"irsend SEND_START Denon KEY_POWER;; sleep 1;; irsend SEND_STOP Denon KEY_POWER\";
\"irsend SEND_START Denon KEY_TUNER;; sleep 1;; irsend SEND_STOP Denon KEY_TUNER\"");
}
else
{
fhem ("\"irsend SEND_START Denon KEY_GAMES;; sleep 1;; irsend SEND_STOP Denon KEY_GAMES\";
\"irsend SEND_START Denon KEY_POWER2;; sleep 1;; irsend SEND_STOP Denon KEY_POWER2\";
set WZ_Multimedia off");
}
fhem ("sleep 10; cancel ID_1 quiet");
}
Für den Fall dass die WLAN Steckdose mal nicht erreichbar ist, löscht das cancel am Ende des notifys nach 10 Sekunden das sleep. Damit werden ungewollten Schalthandlungen vermieden wenn die Steckdose dann wieder online ist.
Vielen Dank für die schnellen Antworten :)
Dein cancel kommt aber erst zum Tragen, wenn das notify wieder auslöst.