Da sind zumindest für mich zu wenig Informationen.
Der Aktor kann also keine on-for-timer nehme ich an?
Wie wird der denn ausgelöst?
Hast du eine Konstrukt, wo das drücken eines Senders eine Define...notify auslöst?
Wenn ja, dann sowas wie:
define Garagentor notify Mein_Schalter:on set Garagentor_aktor on ;; sleep 1.0 ;; set Garagentor_aktor off
Wenn du hingegen mit einem Sender direkt schaltest, dann nur so:
define Garagentor notify Mein_Schalter:on sleep 1.0 ;; set Garagentor_aktor off
Oder ich verstehe dein Problem nicht richtig.
Was ist eigentlich ein MQTT?
Zitat von: Zrrronggg! am 24 August 2015, 12:24:50
Wenn du hingegen mit einem Sender direkt schaltest, dann nur so:
define Garagentor notify Mein_Schalter:on sleep 1.0 ;; set Garagentor_aktor off
Dies funktioniert wunderbar! Für meinen Fall angepast:
define Gate notify gate_test:on sleep 1.0 ;; set gate_test off Nun ist mir auch klar was ein notify macht. Herzlichen Dank!
Mit sleep wird Fhem für die sleep Zeit angehalten. Ist das so von Dir berücksichtigt.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Zitat von: JoWiemann am 25 August 2015, 11:23:48
Mit sleep wird Fhem für die sleep Zeit angehalten. Ist das so von Dir berücksichtigt.
Naja es hat für die eine Sekunde (noch) vermutlich keine große Auswirkung. Gibt es eine elegantere Lösung?
Verstehe leider nicht ganz was du mit
ZitatDas on-for-timer kann eigentlich als Nachricht mit gegeben werden und wird dann im MQTT Server dem Device mitgegeben.
meintest.
ZitatMit sleep wird Fhem für die sleep Zeit angehalten. Ist das so von Dir berücksichtigt.
Ja, ist berücksichtig, weil es nämlich nicht so ist soweit ich weiss. Sleep ist ein FHEM Commando, siehe commandref.
http://www.fhem.de/commandref.html#sleep
Dort findet sich z.b. auch folgendes Beispiel:
define n3 notify btn3.* set lamp on;;sleep 1.5;;set lamp offdas doch recht analog zu meinem Vorschlag ist.
Allerdings: Ein sleep in einem PERL Teil blockiert fhem.
Daher riet auch ich selber früher von der Verwendung von sleep eher ab, zumindest solange man als Anfänger noch nicht genau weiss, was FHEM und was perl ist. Die Gefahr besteht darin, dass mein Beispiel oben um eine Perl-if Variant erweitert wird und das sleep dann in den perl Teil rutscht und DANN BLOCKIERT es auch.
Diese Gefahr ist mit dem neuen und einfacher zu erlernenden DOIF Befehl aber eigentlich gebannt.
Ein weiteres Problem ist: falls sleep von keinem Befehl gefolgt wird, DANN wird FHEM auch tatsächlich blockiert.
Die Gefahr, dass einer das schreibt sehe ich als noch geringer an.
Also AFAIK geht sleep IN Fhem und ist quasi ein "define at" ohne Namen.
Die
voll ausgeschriebene Variante wäre also z.b.:
define Garagentor notify Mein_Schalter:on define verzoegerung1 at 00:00:01 set Garagentor_aktor offDas wäre auch die Lösung, wenn man sleep vermeiden will und ich schreibe das auch immer so, wenn das sleep länger als wenige Sekunden ist, unter anderem deswegen, weil man dann in "Everything" unter der Sektion "at" alle eventuell noch wartenden späteren Folgeaktionen sehen kann, wartende sleeps aber nicht.
ZitatVerstehe leider nicht ganz was du mit
ZitatDas on-for-timer kann eigentlich als Nachricht mit gegeben werden und wird dann im MQTT Server dem Device mitgegeben.
meintest.
Das meint, dass "on-for-timer" ein Befehl ist, den viele Aktoren nativ beherrschen, also IM AKTOR. FS20 und HM Aktoren z.b. kann man anstelle "on" ein "on-for-timer 1" senden, dann schalten die für eine Sekunde ein und dann von alleine wieder aus. Ohne weiteren "off" Befehl von fhem. Der Aktor muss das aber auch können. IT kann das z.b. nicht. Ob bei MQTT die Aktoren das können, oder ob eine Zwischeninstanz ("MQTT-Server") das nachbildet weiss ich nicht, ich kenn MQTT nicht. WENN, dann könnte man sich das Ausschalten nach einer Sekunde sparen sondern dem Aktor gleich befehlen nur eine Sekunde einzuschalten.
Ich ging davon aus, dass es sicherer ist anzunehmen, dass dein Aktor das nicht kann, daher mein Vorschlag. Der geht immer.