Tastendruck lang erzeugt drei Trigger Events

[esbol]

Bei der Fehlersuche fiel mir auf, dass ein langer Tastendruck (egal welcher Tastertyp) zu drei Events führt, statt einem. Hier der Systemlog, Auszug exemplarisch:

Code: Alles auswählen

Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Remote Arbeitszimmer:Reihe 3 Links KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:24 Uhr
Programme_loggen	Programm:  AUS System Receiver Küche durch: Trigger Receiver Küche mit dem Wert: Aus am: 05.06. 15:24 Uhr
Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Remote Arbeitszimmer:Reihe 3 Links KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:24 Uhr
Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Remote Arbeitszimmer:Reihe 3 Links KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:24 Uhr
Trigger Receiver Küche	1
Programme_loggen	Programm:  RADIO System Receiver Küche durch: Trigger Receiver Küche mit dem Wert: Radio am: 05.06. 15:24 Uhr
Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Taster2 Flur AZ:Oben KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:25 Uhr
Programme_loggen	Programm:  AUS System Receiver Küche durch: Trigger Receiver Küche mit dem Wert: Aus am: 05.06. 15:25 Uhr
Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Taster2 Flur AZ:Oben KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:25 Uhr
Trigger Receiver Küche	0
Programme_loggen	Programm:  DANN Kueche Radio Aus durch Kanal: Taster2 Flur AZ:Oben KEY_TRANSCEIVER mit DP: PRESS_LONG mit dem Wert: PRESS_LONG am: 05.06. 15:25 Uhr
Trigger Receiver Küche	1
Programme_loggen	Programm:  RADIO System Receiver Küche durch: Trigger Receiver Küche mit dem Wert: Radio am: 05.06. 15:25 Uhr

Zur Erklärung: Auslöser ist entweder ein Tastendruck auf einem HmIP-RC8 oder einem HmIP-WRC2 (andere Geräte machen das gleiche). Bei einem langen / kurzen Tastendruck wird zunächst im ersten Programm "Kueche Radio Aus" ("Küche Radio Ein" ist nicht dargestellt) eine Systemvariable "Trigger Receiver Küche" gesetzt, diese triggert dann das eigentliche Programm "System Receiver Küche", das einen Yamaha Receiver per Shell-Skript ein oder aus schaltet, je nach Wert in der Variable (der kann "Aus" (0) oder "Radio" (1) sein).

Bei einem langen Tastendruck wird die Variable nun immer dreimal hintereinander gesetzt! Bei einem kurzen Tastendruck nur einmal! Das Programm "System Receiver Küche" wird dennoch nur einmal ausgeführt, weil dieses auf "Änderung" wartet, nicht auf "Aktualisierung". Leider lässt sich das nicht immer so machen, so dass dann Skripte u.U. dreimal hintereinander aufgerufen werden würden, wenn auf "Aktualisierung" gewartet wird - nicht gut!

Das Verhalten ist konsistent über alle Tastertypen!
Wie kann man dieses Verhalten abstellen? Ich möchte auch bei langem Tastendruck nur einen Trigger haben!

Forensuche und sonstige Suche ergab nichts sinnvolles.

Viele Grüße
Frank

[Matsch]

Das Verhalten ist noch etwas anders. Solange du die Taste (lang) drückst, so lange wird vom Gerät die Botschaft "Tastendruck lang" gesendet, aller 250ms.

Ich hab hier mal einen Vorschlag zum Abfangen der multiplen Triggerungen gemacht:

Anleitung_Tastendruck.pdf

(720.4 KiB) 217-mal heruntergeladen

Ursprünglich war das dafür gedacht, wie man kurzen/langen Tastendruck wie bei einer Direktverknüpfung über die CCU simulieren kann, z.B. von Homematic-Gerät auf Homematic-IP oder umgekehrt.
In deinem Fall würde es sich anbieten, das Tastenereignis Tastendruck lang in eine Systemvariable zu schreiben und dein Programm auf Systemvariable = wahr zu triggern.

[esbol]

Ursprünglich war das dafür gedacht, wie man kurzen/langen Tastendruck wie bei einer Direktverknüpfung über die CCU simulieren kann, z.B. von Homematic-Gerät auf Homematic-IP oder umgekehrt.
In deinem Fall würde es sich anbieten, das Tastenereignis Tastendruck lang in eine Systemvariable zu schreiben und dein Programm auf Systemvariable = wahr zu triggern.

Sowas ähnliches habe ich mir gedacht bzw. befürchtet! Aber gehofft, man könnte das Retriggern irgendwie unterbinden. :-/
Ok, mit Variablen geht es, klar, ist aber aufwändig und lästig... na gut, wat mutt, dat mutt...

Danke für die Info.

Ergänzung:
Das mit der Verzögerung um 1 Sekunde (aus dem PDF entnommen) ist ein wirklich netter Trick - funktioniert prima!
Da muss man erst mal drauf kommen. Danke nochmal!

Für alle hier nochmal das Beispiel als Bild:

Der Tastendruck beschreibt eine Variable mit einer Sekunde Verzögerung. Die Variable triggert dann das eigentliche Programm.
Durch die Verzögerung (mit der ich leben kann) wird tatsächlich immer nur ein Event ausgelöst, egal wie lange man die Taste drückt (also auch wenn man die länger als eine Sekunde drückt)!

[Matsch]

Aber so war's nicht gedacht! Drückst du die Taste sehr lange, dann wird das Ereignis erst nach Loslassen der Taste getriggert, weil der Timer ja ständig regetriggert wird. Und was ist mit dem Rückstellen der Variablen nach dem Loslassen?

Meine Idee war aber, bei einem Triggeraufruf die Variable sofort zu setzen und nach 1 s rückzusetzen (2 Befehlszeilen hintereinander). Damit wird die Variable beim ersten Auftreten des Ereignisses verzögerungslos gesetzt und 1s nach loslassen der Taste rückgesetzt.
Die Variable stellt dann den "entprellten" Wert "Tastendruck lang" dar.

[esbol]

Das ist auch eine Möglichkeit.
Vorteil: Triggert sofort, aber immer noch mehrfach, Variable kann daher nur auf "Änderung" verwendet werden und muss dann zurückgesetzt werden, was vielleicht nicht immer gewünscht ist. In der Tat ist in einigen Fällen die Variable bei mir auch gleichzeitig der Status, d.h. ich setze erst beim Einschalten (Tastendruck kurz) wieder zurück. Man kann natürlich Trigger-Variable und Status-Variable trennen, klar.

Meine Version triggert in der Tat erst nach Loslassen der Taste.
Vorteil: Es wird wirklich nur einmal getriggert. Das Rücksetzen der Variable ist in dem Fall nicht nötig, und man kann auch auf "Aktualisierung" der Variable Programme starten. Und es geht auch ohne Variable, man kann auch einen beliebigen (virtuellen) Aktor um die Sekunde verzögert schalten.
Nachteil: Triggert erst nach Loslassen der Taste plus die eine Sekunde, also lange Verzögerung, bis etwas passiert. Nicht immer gewünscht.

Zwei Möglichkeiten, die das Problem lösen.
Danke für die Klarstellung.

[Matsch]

Du hast anscheinend noch immer nicht verstanden, wie das Programm funktioniert.

1. Erste Botschaft "Tastendruck lang" trifft ein --> Variable wird gesetzt, Timer mit 1s aufgezogen
2. Nach 250ms trifft die nächste Botschaft ein, der Timer ist noch nicht abgelaufen, hat also die Variable noch nicht rückgesetzt. Erneut wird der Timer auf 1s gesetzt.
3. Solange Botschaften aller 250ms eintreffen, wird immer wieder der Timer rückgesetzt, er läuft nie ab, der Zustand der Variablen ändert sich nicht.
4. Sobald keine Botschaften mehr eintreffen, läuft der Timer ab und die Variable wird rückgesetzt.

Da wird nichts mehrfach getriggert, die Variable löst nur einmalig eine Aktion aus.
Natürlich muß die Variable auf "Bei Änderung auslösen" ausgewertet werden, nicht auf "Bei Aktualisierung auslösen"!!!

[esbol]

Doch, ich habe Dein Programm verstanden und ausprobiert. Und das Ergebnis gibt mir recht, hier das Programm:

Ist im Wesentlichen das gleiche wie Deins.

Hier das Ergebnis im Systemlog (in dem ich u.a. die Variablen protokolliere):

Man sieht also, dass die Variable hier viermal neu gesetzt wird. Das davon abhängige Programm wird nur deshalb einmalig ausgeführt, weil es auf "Änderung" (und nicht "Aktualisierung") reagiert!

Wenn man also die Variable nicht zurücksetzen kann oder möchte, bzw. wenn man das Programm eben auf "Aktualisierung" triggern muss / will, geht Deine Variante schlicht nicht. Das ist meine Aussage. Das heisst nicht, dass Dein Programm falsch ist, man muss nur wissen, was man tut und was man will.

Meine Variante mit dem verzögerten Setzen setzt am Ende die Variable tatsächlich nur einmal, aber erst nach Loslassen der Taste und die Aktion wird um eine Sekunde verzögert.

Das ist was ich gerne hätte, da ich einige Variablen nicht zurücksetzen möchte und letztlich dann auch auf "Aktualisierung" triggere. Den Nachteil der Verzögerung nehme ich in Kauf.

[Matsch]

Mein Ansinnen war es, das Ereignis "Tastendruck lang" in einer Systemvariablen abzubilden, deren Inhalt nicht immer wieder geändert wird durch die zyklischen Botschaften. Dass Variablen auf "Änderung" getriggert werden, ist ja eigentlich der Normalfall, auf "Aktualisierung" triggern eher ein Spezialfall, der sich manchmal nicht vermeiden läßt, hier aber schon.

Was ich meine: Das von mir gezeigte (Kurz-)Programm dient einzig und allein zur Generierung des "entprellten Tastenzustands lang".
Im eigentlichen Anwendungsprogramm wird nun die Änderung (!) des Variableninhalts zur Erkennung und Triggerung des Tastenereignisses verwendet. Dort kannst du dann gerne auch eine weitere anwendungsspezifische Systemvariable damit setzen lassen, von mir aus auch ohne Rücksetzen.

Das mag jeder selbst entscheiden, aber ich persönlich würde das Entprellen des Tastenereignisses nicht mit dem eigentlichen Anwendungsprogramm vermischen, sondern 2 getrennte Programme und Variablen einsetzen.

Aber Hauptsache, du bist mit deiner Lösung zufrieden.

[Gerti]

Hi!

Stand gerade auch vor dem Problem, habe es aber einfacher gelöst.
Einfach in den Einstellungen des Senders/Aktors die Dauer für den langen Tastendruck auf 0.8s gestellt und den Timeout für langen Tastendruck auf 100ms. Dadurch wird nur 1x nach 0.8s der lange Tastendruck gesendet.

Gruß,
Gerti

[Matsch]

Das wird oft eben keine Lösung sein, denn i.d.R. will man ja etwas bestimmtes mit dem langen Tastendruck erreichen, z.B. fahren eines Rollladens, so lange man drauf drückt. Oder eine Lampe dimmen, so lange man drauf drückt. Mit dem Loslassen der Taste soll der Vorgang beendet werden.
Dazu muß man aber das Ende des langen Tastendrucks erfahren. Das ist in deinem Fall dann nicht mehr möglich.