DOIF mit attr waitsame reagiert nicht auf Doppelklick

Begonnen von Fritz Muster, 15 Dezember 2015, 09:37:02

Vorheriges Thema - Nächstes Thema

Fritz Muster

Hallo in die Runde,

ich möchte einen Button des Homematic Handsenders HM-RC-4-2 mit folgender Funktion belegen.

1. Taster wird betätigt und ein notify wird getriggert.
2. Wird der Button innerhalb der ersten 5 Sekunden erneut betätigt, soll ein DOIF (difHoftorAufStopp5Sec ) ausgelöst werden.
3. Wird der Button nicht in den ersten 5 Sekunden erneut betätigt, sollen die nächsten 10 Sekunden "überwacht" werden. Soll heißen, wenn der Button dann innerhalb der nächsten 10 Sekunden erneut betätigt wird, soll der DOIF (difHoftorAufStopp15Sec) getriggert werden. Hier der Code dazu:


define ntfHoftorLiReOeffnen notify FbNicoleBtn2:trigger:.*|dmyHoftorToogle:Short (IF (ReadingsVal("dmyHoftorStatus","TorStopp",,0) eq 0) ......
define difHoftorAufStopp5Sec DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and .....
attr waitsame 5
attr do always
define difHoftorAufStopp15Sec DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and ....
attr waitsame 15
attr do always


Wie verhält sich nun das Ganze? Die "Überwachung" der ersten 5 Sekunden funktioniert. Button wird einmal betätigt, notify wird getriggert, Button wird innerhalb der ersten 5 Sekunden erneut betätigt und DOIF difHoftorAufStopp5Sec wird getriggert. Soweit so Gut. Wenn nun aber die ersten 5 Sekunden abgelaufen sind ( und der Button wurde nicht erneut betätigt), reagiert der Button nicht auf einen "Button-Druck". Der DOIF difHoftorAufStopp15Sec  wird erst getriggert wenn der Button innerhalb der nächsten 10 Sekunden zweimal betätigt wird. Der DOIF soll aber bei ersten (erneuten "Button-Druck") getriggert werden.

Ich hatte auch mal versucht alles in einem DOIF zu verarbeiten

define difHoftorAufStopp DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and ... )(Bedingung 1)(Bedingung 2)
attr waitsame 5:15
attr do always


Hier war aber genau das gleiche Verhalten.

Hat jemand eine Idee, wie ich das mit den DOIF`s umsetzten kann?

Danke und Grüße Fritz
RasPi 3B+, Stretch, Fhem 5.9, DBlog SQLite
HMLAN, mapleCUN MAX/WMBus, mapleSduino 868/433/868
HM Sensoren/Aktoren ,Technoline TX 29 DTH-IT, TFA 30.3155WD, MAX!
Hour Counter, Astro, EletricityCounter, Statistics, Charting Frontend, TabletUI, Modbus

Ellert

define difHoftorAufStopp5Sec DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and .....
attr waitsame 5
attr do always
define difHoftorAufStopp15Sec DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and ....
attr waitsame 15
attr do always


Für mich sieht das schlüssig aus: Das 1. DOIF führt die Befehle bei 2x Tastenbetätigung innerhalb von 5 s aus. Das 2. DOIF führt die Befehle auch bei 2x Tastendruck innerhalb von 15 s aus. Es sei denn, das verschwiegene ... verhindert das.

Ist es von der Handhabung nicht etwas herausfordernd, 5s abzuwarten, um dann innerhalb der nächsten 10s eine 3. Aktion auszulösen?

Wäre es nicht besser, erst die Tastendrücke zu zählen und nach Abschluss der Zählung eine Aktion auszuführen?

Fritz Muster

ZitatEs sei denn, das verschwiegene ... verhindert das.
Ich habe den Rest bewusst "verschwiegen" um nicht mit "unnötigen" Coding  zu verwirren. Die Bedingungen sind in beiden DOIF`s identisch. Nur der cmd Teil ist dann je nach Bedingung ein Anderer. Aber vielleicht habe ich hier ja einen Fehler eingebaut, daher hier nochmal der komplette Code:
define difHoftorAufStopp5Sec DOIF ([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and [dmyHoftorStatus:WiederAnfahrt] eq "0" and [dmyHoftorStatus:TorStopp] eq "1" and [dmyHoftorStatus:Position] eq "1")(set AktGarageHoftorLi on-for-timer 0.5, setreading dmyHoftorStatus WiederAnfahrt 1, setreading dmyHoftorStatus TorStopp 1, delete tmp_time2, delete tmp_time3, delete tmp_time4, delete tmp_time5)
attr difHoftorAufStopp5Sec waitsame 5
attr difHoftorAufStopp5Sec  do always
define difHoftorAufStopp15Sec([FbNicoleBtn2:?trigger] and [AktGarageHoftorLi:TorStatus] eq "2" and [AktGarageHoftorRe:TorStatus] eq "1" and [dmyHoftorStatus:WiederAnfahrt] eq "0" and [dmyHoftorStatus:TorStopp] eq "1" and [dmyHoftorStatus:Position] eq "1")(set AktGarageHoftorLi on-for-timer 0.5, setreading dmyHoftorStatus WiederAnfahrt 1, setreading dmyHoftorStatus TorStopp 1, delete tmp_time2, delete tmp_time3, delete tmp_time4, delete tmp_time5)
attr difHoftorAufStopp15Sec waitsame 15
attr difHoftorAufStopp15Sec do always



ZitatIst es von der Handhabung nicht etwas herausfordernd, 5s abzuwarten, um dann innerhalb der nächsten 10s eine 3. Aktion auszulösen?
In diesem Fall nicht. Es handelt sich um eine Torsteuerung einer 2 flügeligen Drehtoranlage mit einem Pfostenanschlag des rechten Torflügels. Soll heißen, das beim betätigen zunächst der linke Flügel öffnet und dann 5 Sekunden verzögert der rechte Flügel folgt. Möchte man die die Torfahrt unterbrechen, (durch erneutes betätigen des Hansenders) muss entweder nur ein Flügel den Stopp-Befehl bekommen (Zeit<5 sek). Ist die Zeit >5 Sekunden, müseen sowohl der linke als auch der rechte Torflügel den Stopp Befehl bekommen. Daher diese Art der Handhabung/Ablaufs.

ZitatWäre es nicht besser, erst die Tastendrücke zu zählen und nach Abschluss der Zählung eine Aktion auszuführen?

Wie könnte das mit dem Zählen denn aussehen?
RasPi 3B+, Stretch, Fhem 5.9, DBlog SQLite
HMLAN, mapleCUN MAX/WMBus, mapleSduino 868/433/868
HM Sensoren/Aktoren ,Technoline TX 29 DTH-IT, TFA 30.3155WD, MAX!
Hour Counter, Astro, EletricityCounter, Statistics, Charting Frontend, TabletUI, Modbus

Ellert

Wäre es eine Lösung beiden Torflügeln immer einen Stop Befehl zu senden bei einem 2. Tastendruck, dann wäre die 2. Zeitspanne (5 bis 15 s) nicht notwendig? Der Flügel der noch nicht öffnet bleibt ungeöffnet.
Oder liefert  der Aktor Statusinformationen, wie offen, geschlossen, in Bewegung auf, in Bewegung zu?

Zählen geht etwa so:
define z dummy

define zdi DOIF ([FbNicoleBtn2:?trigger]) (set z {([z] +1)})
attr zdi do always


Fritz Muster

ZitatWäre es eine Lösung beiden Torflügeln immer einen Stop Befehl zu senden bei einem 2. Tastendruck
Geht leider nicht, die Torflügel haben den üblichen Steuerungsablauf : Auf => Stopp => Zu. (Alles mit einem Signal/Tastendruck) das bedeutet, wird innerhalb der ersten 5 Sek. der Stoppbefehl an beide Flügel gesandt, bleibt der Flügel der bereits in der "Torfahrt Öffnen" war stehen und der Flügel der noch nicht gestartet war beginnt dann die "Torfahrt Öffnen" => Kollision.

ZitatOder liefert  der Aktor Statusinformationen, wie offen, geschlossen, in Bewegung auf, in Bewegung zu?
Ja, die jeweiligen Statis habe ich mir mit Hilfe von userreadings selbstgebaut (siehe DOIF Bedingungen z.B AktGarageHoftorLi:TorStatus] eq "2", AktGarageHoftorRe:TorStatus] eq "1" usw.) Das bringt mich gerade auf die Idee, das Ganze in nur einem Zeitfenster abzufragen und dann zu prüfen, ob ein Aktor bereits "in Fahrt ist"

Würde das aber lieber mit den bereits vorhandenen DOIF`s lösen. Habe noch die Hoffnung das Ganz einfach mit einem attr wie z.B cmdpause o.ä. zu lösen. Vielleicht habt Ihr ja noch eine Idee!

RasPi 3B+, Stretch, Fhem 5.9, DBlog SQLite
HMLAN, mapleCUN MAX/WMBus, mapleSduino 868/433/868
HM Sensoren/Aktoren ,Technoline TX 29 DTH-IT, TFA 30.3155WD, MAX!
Hour Counter, Astro, EletricityCounter, Statistics, Charting Frontend, TabletUI, Modbus

Ellert

define st DOIF (([FbNicoleBtn2:?trigger] or [dmyHoftorToogle:?state..Short]) and [?st] =~ (cmd_2|cmd_3|initialized))
   (IF ([dmyHoftorStatus:TorStopp] == 0) (set ...) (set ...))
DOELSEIF ([FbNicoleBtn2:?trigger] and [st:state:sec] <= 5 and [?AktGarageHoftorLi:TorStatus] eq "2" and [?AktGarageHoftorRe:TorStatus] eq "1" and .....)
   (set ...)
DOELSEIF ([FbNicoleBtn2:?trigger] and [st:state:sec] > 5 and  [st:state:sec] <= 15 and [?AktGarageHoftorLi:TorStatus] eq "2" and [?AktGarageHoftorRe:TorStatus] eq "1" and .....)
   (set ...)


Notify fällt weg, DOIF ohne steuernde Attribute. Damit wäre dann auch so viel wie möglich von Deinen DOIFs gerettet.