Originally posted by: <email address deleted>
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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
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
wrote:
> 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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....
Am Mittwoch, 28. März 2012 01:03:26 UTC+2 schrieb 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
> wrote:
> > 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
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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.
Am Mittwoch, 28. März 2012 06:50:02 UTC+2 schrieb 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....
>
> Am Mittwoch, 28. März 2012 01:03:26 UTC+2 schrieb 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
>> wrote:
>> > 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
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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...
Am Mittwoch, 28. März 2012 07:32:59 UTC+2 schrieb 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.
>
> Am Mittwoch, 28. März 2012 06:50:02 UTC+2 schrieb 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....
>>
>> Am Mittwoch, 28. März 2012 01:03:26 UTC+2 schrieb 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
>>> wrote:
>>> > 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
>>
>>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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...
Am Mittwoch, 28. März 2012 08:37:49 UTC+2 schrieb 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> > 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.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> 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 :)
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
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
> > 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 :)
>
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com