Homematic: Button Long Press

[unimatrix]

Und noch eine HM-Frage:

wie ich nun festgestellt habe ist es wohl so, dass beim "Lange-Drücken" von Tastern so lange regelmäßig LongPress-Events generiert werden, bis man wieder los lässt.

Nachteil: Es ist schwierig, auf einen einzelnen langen Tastendruck auch nur einmalig zu reagieren
Vorteil: Die Info lässt sich noch weiter auswerten, man könnte auch über einen "VeryLongPress" nachdenken

Fakt ist, man muss auch auf einzelnes langes Drücken mit einem Notify genau einmal reagieren können. Den Umweg, im Notify als erstes ein Delete zu machen und dann ein AT, was das Notify nach kurzer Zeit neu definiert finde ich etwas unschön.

Wäre es nicht sinnvoller, das CUL-HM irgendwie so umzubauen, dass während man noch drückt ständig "Still-Pressing" Events zu generieren und dann beim loslassen am besten einen Event, in dem auch die Drückdauer als Zahlenwert mit übergeben wird?

So könnte man das Ding auch so nutzen, dass man Aktionen mit sehr großer Auswirkung z.B. "Setze mein gesamtes Haus in den Abwesenheitsmodus und schalte alles ab" nur dann aufruft, wenn man einen Taster dazu mindestens x sekunden festgehalten hat.

Was meint ihr?

VG

[Zrrronggg!]

Ich habe ein sehr ähnliches Problem bei FS20. Wenn man da länger
drückt kommt "dimdown" oder dimup". Wenn man noch länger drückt,
kommen 2x z.b. dimup.

Wenn man mit diesen Events was anderes machen will als tatsächlich
dimmen, hat man u.U. eine Problem. Ich habe das bisher genau so zu
lösen versucht wie du es oben als "unschön" bezeichnet hast.

Ich weiss nicht ob HM da grundlegend anders ist als FS20, aber FS20
stelle ich mir eine FHEM seitige Lösung schwer vor. Wie soll FHEM
entscheiden, ob die einzelnen dimups von einem sehr langen Drücken
oder mehreren langen Drücken mit kurzen Pausen erzeugt wurden? Ich
*glaube*, dass zumindest FS20 nichts sendet wenn man einen Knopf los
lässt und auch nicht den Status ändert, sondern eben nur "on" bei
Tastdruck unter 0,4 sek, oder dimup bei längerem Tastendruck, bzw bei
noch längerem Tastendruck mehrern "dimup"s. D.H. was aus dem Sender
rauskommt wird schon im Sender entschieden. Fhem weiss nicht wie lange
gedrückt wird und könnte bestenfalls über Timeoutdefinitionen sagen:
"Wenn der Abstand zwischen zwei eintreffenden dimups grösser ist als
x, dann wird es sich wohl um 2 Tastendrücke gehandelt haben, sonst
wars eine sehr langer."


Gut, glauben ist nicht wissen.





On 27 Mrz., 20:28, unimatrix <sebastian.stuec...@googlemail.com>
wrote:

[unimatrix]

Ja, HM ist hier genau wie FS20, der Sender sendet schnell hintereinander LONG bis man loslässt....das geht also nur über Timeouterkennung im FHEM und würde in FS20 genau so gehen...

Ich denk mal drüber nach....

[unimatrix]

ich muss mich insofern korrigieren dass man bei HM wohl mehr machen kann.

In den Rohdaten unterscheidet sich beim Loslassen des Tasters die letzte Nachricht von allen anderen. Man weiss also: JETZT wurde losgelassen. Außerdem gibt es einen Zähler, der nur inkrementiert wird, wenn man NEU drückt.

In der jetzigen CUL_HM-Implementierung wird das jedoch nicht berücksichtigt. Insbesondere hab ich das zuerst gar nicht gemerkt, weil hier die Commands teilweise verfrickelt werden:

  $cmd = "0A$1" if($cmd =~ m/0B(..)/);
  $cmd = "A4$1" if($cmd =~ m/84(..)/);
  $cmd = "8000" if(($cmd =~ m/A40./ || $cmd eq "0400") && $len eq "1A");
  $cmd = "A0$1" if($cmd =~ m/A4(..)/);

In der Tat ist aber der Command beim loslassen "8440" welcher dann durch obigen code nach "A040" ersetzt wird.

Ich werde mir mal eine Version basteln aber vll. weiss Rudi noch wie er auf obige Ersetzungen gekommen ist. Vll. weil er keinen Unterschied in diesen Command-Codes erkennen konnte und sie daher gleich gesetzt hat.

[unimatrix]

ok habe mir ein CUL_HM gebaut in dem nun folgendes passiert:

CUL_HM taster_schlaf Btn1 onLong 1
CUL_HM taster_schlaf Btn1 onLong 2
CUL_HM taster_schlaf Btn1 onLong 3
CUL_HM taster_schlaf Btn1 onLong 4
CUL_HM taster_schlaf Btn1 onLong 5
CUL_HM taster_schlaf Btn1 onLong 6
CUL_HM taster_schlaf Btn1 onLongRelease 7

loslassen und nochmal drücken

CUL_HM taster_schlaf Btn1 onLong 1
CUL_HM taster_schlaf Btn1 onLong 2
CUL_HM taster_schlaf Btn1 onLong 3
CUL_HM taster_schlaf Btn1 onLong 4
CUL_HM taster_schlaf Btn1 onLongRelease 5

Das ist aber niciht 100% rückwärtskompatibel zur jetzigen Version. Daher wäre ich mit für alle so umbauen zunächst mal vorsichtig...

[Rudolf Koenig]

> Vll. weil er keinen Unterschied in diesen Command-Codes erkennen konnte und
> sie daher gleich gesetzt hat.

Exakt. Trotz Johan's Bemuehungen ist mir die Bedeutung der einzelnen Bits noch
nicht ganz klar. Waere Klasse, wenn jemand (evtl. nach etwas Forschung) das
klarer stellen koennte.

[unimatrix]

Ich hab eben nun auch nicht mehr erkannt dass 84 für Button festhalten und A0 für loslassen steht und das habe ich eingebaut.

Problem: Veränderung an den generierten Events führt zu niht sauberer Kompatibilität mit der alten Version

Beispiel: Mein gestern noch in der Config definierter notify "define temp notify tasterwohn:Btn1.on set irgendwas on" funktioniert ja jetzt nicht mehr ohne kleine Änderung und wer weiss, wieviele User so etwas drin haben...

[Rudolf Koenig]

> Das ist aber niciht 100% r�ckw�rtskompatibel zur jetzigen Version. Daher
> w�re ich mit f�r alle so umbauen zun�chst mal vorsichtig...

Ich waere trotzdem dafuer, sonst ist onLong nicht wirklich brauchbar, es muss
nur in CHANGED dokumentiert sein. Wenn jemand keine Aenderungen haben will,
der soll kein updatefhem ausfuehren.

Alternativ faellt uns was generischeres ein, was auch vom FS20 verwendet werden
kann. Aber auch dann waere es schade die Zusatzinformation wie Release zu
ignorieren.

[Rudolf Koenig]

> Beispiel: Mein gestern noch in der Config definierter notify "define temp
> notify tasterwohn:Btn1.on set irgendwas on" funktioniert ja jetzt nicht

> mehr ohne kleine �nderung und wer weiss, wieviele User so etwas drin
> haben...

Das verstehe ich nicht: on ist doch kein onLong, und beim on wird auch kein
onRelease gesendet. "on 1" ist haesslich: ich sehe die Aenderung nur beim
onLong.

[unimatrix]

das ist natürlich richtig, bei kurzem drücken kann man sich die Zahl sparen und auch das Release.

Änderung bleibt beim onLong. Man könnte so argumentieren, dass man bisher darauf eh schlecht triggern konnte weil es ja x mal nacheinander kommt.

Es bliebe also

Btn1.off
Btn1.on
Btn1.onLong 1
Btn1.onLong 2
Btn1.onLong 3
Btn1.onLongRelease 4

Andere Alternative:
Btn1.onPressing 1
Btn1.onPressing 2
Btn1 onPressing 3
Btn1 onLong

das wäre vll "ein bisschen kompatibler"

Am Mittwoch, 28. März 2012 09:11:14 UTC+2 schrieb Rudolf Koenig:

> Beispiel: Mein gestern noch in der Config definierter notify "define temp
> notify tasterwohn:Btn1.on set irgendwas on" funktioniert ja jetzt nicht

> mehr ohne kleine �nderung und wer weiss, wieviele User so etwas drin

> haben...

Das verstehe ich nicht: on ist doch kein onLong, und beim on wird auch kein
onRelease gesendet. "on 1" ist haesslich: ich sehe die Aenderung nur beim
onLong.

Am Mittwoch, 28. März 2012 09:11:14 UTC+2 schrieb Rudolf Koenig:

> Beispiel: Mein gestern noch in der Config definierter notify "define temp
> notify tasterwohn:Btn1.on set irgendwas on" funktioniert ja jetzt nicht

> mehr ohne kleine �nderung und wer weiss, wieviele User so etwas drin

[Rudolf Koenig]

> Man k�nnte so argumentieren, dass man bisher darauf eh schlecht triggern

> konnte weil es ja x mal nacheinander kommt.

Genau.

> Btn1.off
> Btn1.on
> Btn1.onLong 1
> Btn1.onLong 2
> Btn1.onLong 3
> Btn1.onLongRelease 4

Ich bin fuer diese Alternative, hab aber auch nichts ernstes gegen die andere
einzuwenden :)

[unimatrix]

ok so hab ichs nun implementiert und lass es erstmal bei mir testweise mit den ganzen Tastern die ich habe laufen...wenn alles stabil ist kann ich es bereitstellen

Am Mittwoch, 28. März 2012 09:24:33 UTC+2 schrieb Rudolf Koenig:

> Man k�nnte so argumentieren, dass man bisher darauf eh schlecht triggern