HM-PBI-4-FM / toggle, statt ON/OFF: Probleme bei LONG

[Alex85]

Hallo zusammen,

ich habe folgendes Phänomen:
habe meinen 4-fach Taster (HM-PBI-4-FM) zuvor verwendet um bestimmte Aktoren mit einem kurzen Tastendruck an und einem langen aus zu stellen.
Das Ganze wollte ich jetzt umstellen, und zwar indem ich toggle, statt ON/OFF Befehle benutze um mehr Geräte anzusprechen.

Das sieht jetzt so aus:

Code Auswählen Erweitern


define Taster4x_Kanal4 CUL_HM <Serial>
attr Taster4x_Kanal4 model HM-PBI-4-FM
attr Taster4x_Kanal4 peerIDs
attr Taster4x_Kanal4 room Unsorted
attr Taster4x_Kanal4 subType pushButton
define FileLog_Taster4x_Kanal4 FileLog ./log/Taster4x_Kanal4-%Y.log Taster4x_Kanal4
attr FileLog_Taster4x_Kanal4 archivedir /var/InternerSpeicher/Corsair-VoyagerGT3-0-01/fhem/archive/
attr FileLog_Taster4x_Kanal4 logtype text
attr FileLog_Taster4x_Kanal4 nrarchive 1
attr FileLog_Taster4x_Kanal4 room Unsorted

define Taster4x_Kanal4_on notify Taster4x:Taster4x_Kanal4.Short.* set Gartenlicht toggle
attr Taster4x_Kanal4_on room Unsorted
define Taster4x_Kanal4_off notify Taster4x:Taster4x_Kanal4.Long.* set Garage_Einzel_Licht toggle
attr Taster4x_Kanal4_off room Unsorted



Mein Problem ist, dass die short Befehle zwar einen einfachen toggle auslösen, die long Befehle aber gleich mehrfach hintereinander verarbeitet werden, sodass die Aktoren zwar kurz an gehen, aber dann auch gleich wieder den aus Befehl bekommen, statt auf den nächsten langen Tastendruck zu warten.

Das spiegelt sich auch wieder im
-> Logfile (FHEM):
2013.03.12 19:48:49 2: CUL_HM set Gartenlicht toggle rxt:1
2013.03.12 19:48:55 2: CUL_HM set Garage_Einzel_Licht toggle rxt:1
2013.03.12 19:48:56 2: CUL_HM set Garage_Einzel_Licht toggle rxt:1
2013.03.12 19:48:57 2: CUL_HM set Garage_Einzel_Licht toggle rxt:1
2013.03.12 19:48:58 2: CUL_HM set Garage_Einzel_Licht toggle rxt:1


Der Kanal der von einem kurzen Tastendruck angesteuert wird funktioniert wie er soll, bei long werden gleich 4 (toggle) Schaltvorgänge ausgelöst...

Woran kann das liegen?!
(Hardware: CUL V3 an FritzBox 7390 / Geräte: Homematic)

[snoop]

Hallo Alex85,

Ich habe verstanden, dass du einen langen Tastendruck erkennen möchtest?
Schau dir mal diesen Thread an.

Vor ein paar Wochen hatte ich ähnliches Problem, vielleicht hilft dir das - lese es dir durch - falls es nicht das ist was du suchst melde dich einfach wieder.

Viele Grüße
Arthur

[Alex85]

Ok ...
Ich hab mir jetzt nicht alles durchgelesen, aber irgendwie hab ich mir das einfacher vorgestellt.
So in Richtung short -> toggle den Aktor
und long -> toggle den anderen Aktor
ohne Komplizierte Auswertlogik davon dahinter ...

[snoop]

Hallo Alex85,

Ok ...
Ich hab mir jetzt nicht alles durchgelesen, aber irgendwie hab ich mir das einfacher vorgestellt.

Hättest es besser gemacht - das alles durchlesen meine ich, da am Ende ja eine relativ (gut ich habe ja auch eine weile gebraucht bis ich es verstanden habe :o)) einfache Lösung dokumentiert wurde.

So in Richtung short -> toggle den Aktor
und long -> toggle den anderen Aktor
ohne Komplizierte Auswertlogik davon dahinter ...

Das ganze würde ich "nicht über einen notify lösen" sondern über "devicepair":
*sorry nur so auf die Schnelle also ungetestet*

# Button 4
###################
# Hier dein Short (unter der Annahme, dass dein Gartenlicht ein Channel ist!)
set Taster4x_Kanal4 devicepair 0 Gartenlicht single set #Device pair single=toggel
set Gartenlicht regSet lgActionType off Taster4x_Kanal4 #Deaktiviere LongPress

# Hier dein Long (unter der Annahme, dass dein Garage_Einzel_Licht ein Channel ist!)
set Taster4x_Kanal4 devicepair 0 Garage_Einzel_Licht single set #Device pair single=toggel
set Garage_Einzel_Licht regSet shActionType off Taster4x_Kanal4 #Deaktiviere ShortPress

Jetzt die Anlerntaste drücken (am PBI).
Fertig.
Versuche es einfach mal vielleicht ist es ja das was du suchst.

Viele Grüße
Arthur

[martinp876]

Hi,

ich werde hier noch etwas verbessern.
Aktuell kommt
short:
   channel und device: state:Short to ....
long:
   channel und device: state:Long[no] to ....
   wobei die Nummer ein Zaehler fuer die anzahl der wiederholungen ist

Ich werden einen neuen event einbauen, der die Nummer des Tastendrucke ausgibt. Also die Nummer aus HM sicht, nicht die Anzahl der wiederholungen.
Kommt aber nur in channel rein - wird auch kein "release"
    channel:  trigger:Short[no]
    channel:  trigger:Long[no]

wenn man doppelte trigger unterbindet (event-on-change) kann man damit einfach ein notify bauen

attr Taster4x_Kanal4 event-on-change .*
define Taster4x_Kanal4_on notify Taster4x:Taster4x_Kanal4.trigger:Short.* set Gartenlicht toggle
define Taster4x_Kanal4_off notify Taster4x:Taster4x_Kanal4.trigger:Long.* set Garage_Einzel_Licht toggle

(hoffentlich ohne typos)
Werde es bald einchecken...

Generell waere mein Weg in diesem Fall aber der von Arthur.

Gruss, Martin

[snoop]

Hallo Martin,

Ich werden einen neuen event einbauen, der die Nummer des Tastendrucke ausgibt. Also die Nummer aus HM sicht, nicht die Anzahl der wiederholungen.
Kommt aber nur in channel rein - wird auch kein "release"
channel: trigger:Short[no]
channel: trigger:Long[no]

da hacke ich gerne nach... :o)
Martin, "Nummer aus HM sicht" den Unterschied habe ich noch nicht verstanden ... sorry.

Heißt "Tastendrücke" wenn ich 3 mal kurz hintereinander die Taste drücke, dann erscheint in dem neuen event eine Zahl also in diesem Fall "3" ?

Sorry der Nachfrage, ich finde das HM (FHEM?) das "long und short" mit PBI respektive Remote(s) irgendwie nicht glücklich gelöst hat. (Sorry nur ein Leihe: technisch kann ich das vielleicht noch verstehen).

Für mich wäre eine einfache Unterscheidung zwischen "kurz gedrückt" und "lange gedrückt" die erste Stufe (User Sicht: natürlich immer gefühlt  jeder nimmt das anders wahr). (Also so wie bei den vAktor mit release_short und release_long?)
Stufe zwei wäre! definiere "eine short Range (in sec. beliebig und nicht auf die derzeit max 1,6 sek? - weiß es aus dem Stegreif nicht genau!)" und "eine long Range", abhängig davon kann ich erkennen wann ich ein "short" und wann ich ein "long" ausgelöst habe und aber auch wie oft ich ein "short" und ein "long" gedrückt habe.

Das ist meine persönliche Sicht aus der Praxis.

Fazit: Idee? Event_1: Losgelassen=released Event_2:Art: wie Lange short or (||) long? Event_3:Count/Anzahl (wie lange)
Edit: Event_2:Art: ob short or (||) long? _ wie lange macht keinen Sinn.
Martin: Abgesehen von den HM Hardware/Software spezifischen Einschränkungen (short timer - Parameter/Register fällt mir grade nicht ein), macht das Sinn und wäre das realisierbar?
Okkkk, per devicepair wird es nicht gehen  verstanden  aber dass man es über FHEM abbilden könnte fände ich es super.
Das sind Fragen!,  hoffe nachvollziehbar?!?! :o( ;o)

Ist nur eine Anregung/Idee.... abgesehen von den tech. Herausforderungen.

Viele Grüße
Arthur

[martinp876]

Hi Martin,

"Nummer aus HM sicht" den Unterschied habe ich noch nicht verstanden ... sorry.

der button sendet eine Nummer des Schaltvorgangs. Diese wird von HM aktor-channels ggf ausgewertet (wenn so programmiert)
bei short wird sie immer hochgezaehlt. Bei long bleibt sie waerend eines 'vorgangs' konstant und wird beim naechsten hoch gezaehlt.
Es kommen also so lange 'long' mit der gleichen Nummer wie man den Knopf  nicht loslaesst....

HM aktoren verwenden dies ggf zum toggeln der Funktionen....

Dann gibt es noch die FHEM Zaehlung der long-trigger. Also FHEM zaehlt der wievielte 'long' einer Sequenz dies ist.
Bislang wurde nur die FHEM nummer ausgegeben. Jetzt gibt es auch den event trigger bei den Buttons, wie vor beschrieben (und im comamndref fehlt es noch:-( )

Heißt "Tastendrücke" wenn ich 3 mal kurz hintereinander die Taste drücke, dann erscheint in dem neuen event eine Zahl also in diesem Fall "3" ?

fast. Wo dein HM-channel anfaengt zu zaehlen ist seine Sache. Nach reset evtl bei 0 oder 1... meiner was gerade bei 97. Mehr als 255 sollte nicht gehen (1 Byte...)

Für mich wäre eine einfache Unterscheidung zwischen "kurz gedrückt" und "lange gedrückt" die erste Stufe (User Sicht: natürlich immer gefühlt jeder nimmt das anders wahr). (Also so wie bei den vAktor mit release_short und release_long?)

Die Begriffe finde schon ok. Wichtig zu wissen: ob ein druck long oder short ist entscheidet NICHT fhem sondern die remote. Das ist dort meist einstellbar. Manche remotes haben garkein "long".
Release ist wiederum ein FHEM einbau, der nicht explizit von HM geliefert wird. Unter gewissen Voraussetzungen ist dies aber sehr zuverlaessig nutzbar.
Short ist immer auch ein release! sollte irgendwie klar sein, hoffen ich.

Damit sollte sich deine Anmerkungen zu den definitionen geklaert haben?

Mal sehen ob ich deine Anmerkungen verstanden habe:

jetzt haben wir ein
long/short
release (nur bei long)
fhem counter (nur bei long)
hm counter

event state:
Long <fhemCnt>-<command>-
LongRelease <fhemCnt>-<command>-
Short

und neu trigger
trigger:Long_<hmCnt>
trigger:Short_<hmCnt>

wenn du jetzt eine Verzoegerung willst (veryLongPress) und erst nach dem 3. long-event reagieren willst kannst du

... notify .... FB_Btn3:Long.3-.*

benutzen. Sollte auf jeden 3. longtrigger reagieren

wenn du auf neue 'sequenzen reagieren willst:
attr FB_Btn3 event-on-change trigger

... notify .... FB_Btn3:trigger.*

Klappt dies so?

Gruss
Martin

[Martin Thomas Schrott]

Hi!
>0 oder 1... meiner was gerade bei 97. Mehr als 255 sollte nicht gehen (1 Byte...)

korrekt, ich hab die Schleife scon mal beobachtet, bei 255 ist SChluss und fängt von vorne an.

@short


Was hältst du davon den short auf
short release
umzubenennen? Dann ist es logisch und konsistent, denn der short ist wie der long release ja auch ein singlecast event oder?
Oder kann ein short auch broadcast sein?... würde ja trotzdem nichts ändern, denn es ist immer der release von einem short, denn es gibt ja nur eine message dazu.

Ich fände es logischer.

lG
Martin

[martinp876]

Hi Martin

Was hältst du davon den short auf
short release
umzubenennen?

mal laut denken:
- Ablauftechnisch korrekt.
- man koennte release nutzen um einfach jedes loslassen eines Schalters zu dedektieren.
- Probleme mit bestehenden Notifies sind anzuwaegen: Normal sollten die User ein Short.* genutzt haben, damit waere alles klar. Falls nicht fliegt ihnen die Aenderung um die Ohren...

- Inhaltlich ist es kein shortRelease sondern ein ack-request and peers. Es kommt also nur, wenn peers auf diesen Button eingetragen sind. Wenn ich es immer schicke stimmt der erste Punkt nicht mehr (Ablauftechnik).

Also ander: Der short ist ein singlecast wenn es einen peer gibt, ansonsten ein broarcast. Genauer: es ist natuerlich ein singlecast je peer.

Lange Ueberlegung zu short: eine aenderung hat auch Nachteile und macht die regexp fuer manche komplexer (ein wenig... aber immerhin). Der Vorteil ist nicht gewaltig (meines erachtens) und fuer einfache User nicht nachvollziehbar.
daher solle man es so lassen, die Tradition ist auf der Seite von "short".

Reklamationen? ;-)

Gruss
Martin

[snoop]

Hallo Zusammen,

danke Martin (ähmmm also der Martin Martin - der 876) für die, wieder mal, ausführliche Darstellung/Erklärung.
Der "trigger" ist mir neu - wieder was mitgenommen - sehe dadurch für mich durchaus einige Anwendungsfälle (werde damit mal ein wenig probieren).

Nun kan ich versuchen meine Aktoren auch per Morsezeichen ;o) zu steuern, sowas wie:

kurz lang - kurz lang kurz kurz - kurz lang - kurz lang kurz - kurz kurz - kurz lang - lang kurz | was sogut wie "Alarm an" heißen müsste | und das ganze soll in einer Zeitrange von 20 sek. erfolgen. ;o)

Zunächst vielen Dank und bis demnächst.

Grüße
Arthur

P.S: "-" ist natürlich eine kurze Pause ;o)

[martinp876]

Der "trigger" ist mir neu

oh - dabei ist der schon seit heute Morgen drin ;-)

kurz lang - kurz lang kurz kurz - kurz lang - kurz lang kurz - kurz kurz - kurz lang - lang kurz | was sogut wie "Alarm an" heißen müsste | und das ganze soll in einer Zeitrange von 20 sek. erfolgen. ;o)

Viel Spass
Martin