FHEM Forum

Hallo!

mein Funk-Wandtaster HM-PB-2-WM55 (https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster (https://wiki.fhem.de/wiki/HM-PB-2-WM55_2fach-Funk-Wandtaster)) hat - wie jeder seiner Art - zwei Tasten: Kanal 2 oben und Kanal 1 unten.
Ebenfalls wie bei jedem seiner Sorte stehen entsprechend der Tastendrücke unter anderem die Events

• vom HM-PB-2-WM55
  
  

  Taste unten	|	Taste oben
  <HM-PB-2-WM55>_Btn_01 Short	|	<HM-PB-2-WM55>_Btn_02 Short
  <HM-PB-2-WM55>_Btn_01 Long	|	<HM-PB-2-WM55>_Btn_02 Long
  <HM-PB-2-WM55>_Btn_01 LongRelease	|	<HM-PB-2-WM55>_Btn_02 LongRelease
  Short 1_<lfd. Nr.> (to <Peer>)	|	Short 1_<lfd. Nr.> (to <Peer>)
  Long <lfd. Zeit>_<lfd. Nr.> (to <Peer>)	|	Long <lfd. Zeit>_<lfd. Nr.> (to <Peer>)
  LongRelease <lfd. Zeit>_<lfd. Nr.> (to <Peer>)	|	LongRelease <lfd. Zeit>_<lfd. Nr.> (to <Peer>)
  trigger: Short_<lfd. Nr.>	|	trigger: Short_<lfd. Nr.>
  trigger: Long_<lfd. Nr.>	|	trigger: Long_<lfd. Nr.>

  
  
• vom <Peer> (ein virtueller Kanal an der VCCU)
  
  

  Taste unten	|	Taste oben
  trig_<HM-PB-2-WM55>_Btn_01: Short_<lfd. Nr.>	|	trig_<HM-PB-2-WM55>_Btn_02: Short_<lfd. Nr.>
  trig_<HM-PB-2-WM55>_Btn_01: Long_<lfd. Nr.>	|	trig_<HM-PB-2-WM55>_Btn_02: Long_<lfd. Nr.>

an.
Mittels notify auf die Events des HM-PB-2-WM55 lassen sich dann viele Steuerungen realisieren.

Nun endlich mein Anliegen:  :D

Anstatt jedesmal zum Taster zu rennen, hätte ich im FHEMWEB gerne Befehlsknöpfe, die den entsprechenden Tastendruck simulieren. Wie kann ich das realisieren?

Meiner Meinung nach stehen mir für webCmd weder Short noch Long, sondern nur

<HM-PB-2-WM55>	|	<HM-PB-2-WM55>_Btn_0{1,2}
assignHmKey	|
clear	|	clear
deviceRename	|
fwUpdate	|
getConfig	|	getConfig
getDevInfo	|
getRegRaw	|	getRegRaw
	|	peerBulk
	|	peerChan
	|	peerSmart
raw	|
regBulk	|	regBulk
regSet	|	regSet
reset	|
	|	sign
	|	trgEventL
	|	trgEventS
	|	trgPressL {all, <Peer>}
	|	trgPressS {all, <Peer>}
unpair	|

zur Verfügung.

Spontan dachte ich, dass trgEvent{L, S} und trgPress{L, S} mein Problem lösen können. Aber weder die commandref noch praktische Versuche zeigten direkte Wirkung.

• trgEvent{L, S}
  set <HM-PB-2-WM55>_Btn_0{1,2} trgEvent{L, S} <Peer> <irgendeine natürliche Zahl>
  erzeugt gar kein Event.
  Wo ist das in der commandref mit
  
  
  
  • trgEventS [all|<peer>] <condition>
    Issue eventS on the peer entity. If all is selected each of the peers will be triggered. See also eventS
    <condition>: is the condition being transmitted with the event. E.g. the brightness in case of a motion detector.
  • eventS <peer> <condition>
    simulates a short event from a peer of the actor. Typically sensor do not send long events.
  angekündigte Event?
  
  
• trgPress{L, S}
  set <HM-PB-2-WM55>_Btn_0{1,2} trgPress{L, S} <Peer>
  erzeugt immerhin das Event set_pressS <HM-PB-2-WM55>_Btn_0{1,2} - allerdings für den <Peer>
  Die commandref schreibt hier
  
  
  
  • trgPressS [all|<peer>]
    Issue pressS on the peer entity. If all is selected each of the peers will be triggered. See also pressS
  • pressS <peer>
    simulates a short press similar to long press
  • pressL <peer> [<repCount>] [<repDelay>]
    simulate a press of the local button or direct connected switch of the actor.
    <peer> allows to stimulate button-press of any peer of the actor. i.e. if the actor is peered to any remote, virtual or io (HMLAN/CUL) press can trigger the action defined.
    <repCount> number of automatic repetitions.
    <repDelay> timer between automatic repetitions.
    Example: set actor pressL FB_Btn01 # trigger long peer FB button 01
    set actor pressL FB_chn-8 # trigger long peer FB button 08
    set actor pressL self01 # trigger short of internal peer 01
    set actor pressL fhem02 # trigger short of FHEM channel 2

So, nun meine meine Zusammenfassung:

• trgEvent{L, S} funktioniert nicht.
• Ich muss meine Notifys umstellen: Während sie jetzt auf das sendende Gerät, nämlich den <HM-PB-2-WM55> triggern, müssen sie nun zusätzlich auf den <Peer> hören.

Habe ich den ganzen Komplex eigentlich (richtig) verstanden? Ist es wirklich so kompliziert?  :-[

Im Prinzip denke ich, dass Du das verstanden hast.

Aber ich verstehe den Sinn noch nicht ganz. Warum genau möchtest Du Tastenevents genieren?

Ich sehe eine Aktion vor: Schalte Licht ein, schalte Licht aus. Dafür bietet der Aktor direkt eine Bedienoberfläche mit webCmd.
Oder ein DOIF für komplexere Vorgänge.
Eine Eventbehandlung verknüpft das mit dem Aktor, im DOIF kann man das Event direkt auswerten.

Zu Testzwecken? Oder hast Du komplexe Vorgänge hinter einem Tastendruck versteckt (etwa per notify), die Du auch aus der Bedienoberfläche auslösen möchtest?

Für WebCmd hast Du zudem pressL und pressS beim einem Aktor zur Verfügung.

Umweg: Wenn Du einen virtuellen Aktor/Button in FHEM definierst und an dessen Auslösung Deine Routinen festmachst, kannst Du einen Taster damit peeren und die Aktion mit diesem triggern und auch per trgPress <virtuellerAktorButton> diese Aktion auslösen.

Zitat von: Pfriemler am 24 Juni 2020, 22:01:53Im Prinzip denke ich, dass Du das verstanden hast.

Eben nicht!  ;)

Denn im Grunde habe ich falsch herum gedacht: 'Ich muss den Tastendruck simulieren um das Licht einzuschalten' - statt 'Ich muss das Licht einschalten'!
Der Taster sollte folglich gar nicht in der Oberfläche auftauchen, sondern nur der "Licht-ein-und-ausschalt-Aktor" (Den habe ich sogar bereits in der Oberfläche.)

Vielleicht habe ich hier ein Beispiel für das Sprichwort "den Wald vor lauter Bäumen nicht sehen" geliefert...  ::)
Vielen Dank für die Neuorientierung!

P.S.: Ist zwar für mich nicht mehr relevant, aber warum erzeugen trgEventL und trgEventS keine Events?

eventuell weil du keine peers hast?
peere doch zb mal mit einem channel der vccu.

Zitat von: GaiusMarius am 25 Juni 2020, 07:41:46
Eben nicht!  ;)

Eben doch. Du klangst ja selbst schon zweifelnd.

Außerdem gibt es einen feinen Unterschied in der Fernbedienung von Aktoren von Homematic. Gerade bei Dimmern wird Dir nämlich auffallen, dass nahezu alle Direktverknüpfungen normalerweise mit einer Ein- und Ausschaltrampe festgelegt werden (0,5s), die Bedienung aus FHEM aber immer "schlagartig" erfolgt, wenn man nicht spezielle Befehle verwendet. Darüberhinaus kann es teilweise sehr sinnvoll sein, bestimmte Abläufe im Zusammenhang mit den Direktverknüpfungen zu realiseren statt mit einem Zentralenprogramm - Direktverknüpfungen sind bspw. immer spürbar schneller.
Anderes Beispiel:
Ein Taster realisert eine Zentralsteuerung aller Rolläden.
Man kann das machen indem man
a) über ein Notify einen Befehl an alle Rolläden schickt (was bei geschickter Namensgebung auch zukunftssicher sein kann, etwa "set EG_Rolladen.* down" funktioniert auch, wenn irgendwann später ein Rolladen EG_Rolladen_Klofenster dazukommt :-) ) - oder auch -
b) indem man eine Direktverknüpfung mit den Rolladenaktoren macht. Diese kann man dann auch etwas feintunen, etwa dass nicht alle gleichzeitig anlaufen, indem man Register shOnDly in den jeweiligen Aktoren individuell einstellt usw. Möchte man diese Funktion nun aber auch über die Zentrale auslösen, müsste man den Ablauf dort ebenfalls nachprogrammieren ("set Rollo1 down; sleep 1; set Rollo2 down; ...") - oder aber einfach mit "trgPressS all" exakt das einmal programmierte Verhalten reproduzieren.

Es ist also nicht so schwarzweiß und richtig oder falsch wie herum man das sieht.

ZitatDer Taster sollte folglich gar nicht in der Oberfläche auftauchen...

... und in der Tat ist das bei mir überall so (außer natürlich im Raum CUL_HM, wo ich zu Konfigurationszwecken dann doch Zugriff habe).

Zitat
P.S.: Ist zwar für mich nicht mehr relevant, aber warum erzeugen trgEventL und trgEventS keine Events?

Gibt es keine Fehlermeldung? Laut commandref erzeugt trgPressS/trgPressL ein Tasterevent ohne Wert, während trgEventS/L zusätzlich einen Wert übermitteln soll, der n.m.M. nicht optional ist. Ein Peering mit einem Fensterkontakt etwa könnte man mit "trgEventS 0" bzw. "trgEventS 200" simulieren - für die Zustände "offen" und "geschlossen".
Ausprobiert habe ich es noch nicht.

Zitat von: Pfriemler am 25 Juni 2020, 11:10:46
a) über ein Notify einen Befehl an alle Rolläden schickt (was bei geschickter Namensgebung auch zukunftssicher sein kann, etwa "set EG_Rolladen.* down" funktioniert auch, wenn irgendwann später ein Rolladen EG_Rolladen_Klofenster dazukommt :-) ) - oder auch -
b) indem man eine Direktverknüpfung mit den Rolladenaktoren macht. Diese kann man dann auch etwas feintunen, etwa dass nicht alle gleichzeitig anlaufen, indem man Register shOnDly in den jeweiligen Aktoren individuell einstellt usw. Möchte man diese Funktion nun aber auch über die Zentrale auslösen, müsste man den Ablauf dort ebenfalls nachprogrammieren ("set Rollo1 down; sleep 1; set Rollo2 down; ...") - oder aber einfach mit "trgPressS all" exakt das einmal programmierte Verhalten reproduzieren.

"b)" ist ein guter Hinweis! Bisher folge ich dem Ansatz "a)". Zumal ich auch einige Nicht-Homematic-Komponenten dabei habe. Auch finde ich es praktisch, wenn letztendlich alles im Rechner verdrahtet ist.

Zitat von: frank am 25 Juni 2020, 07:51:02
eventuell weil du keine peers hast?
peere doch zb mal mit einem channel der vccu.

In meiner realen Umgebung ist der Taster tatsächlich mit einem Kanal der VCCU gepeert. Dennoch kommt der trgEvent{L, S} nicht.

Zitat von: Pfriemler am 25 Juni 2020, 11:10:46
Gibt es keine Fehlermeldung?

Im fhem-*.log ist nichts zu finden und die (Nicht-)Events habe ich zum Schluss sogar mit
define Notify_XX_XX_XX_LogAlles notify .* {\
  Log 0, "->:";;\
  Log 0, "->: \$NAME =$NAME (\$TYPE =$TYPE)";;\
  Log 0, "->: \$EVENT=$EVENT";;\
}
gesucht...  >:(

Zitat von: Pfriemler am 25 Juni 2020, 11:10:46
Eben doch. Du klangst ja selbst schon zweifelnd.

Selbstzweifel und -reflexion sind unmodern geworden... Bei meinen Fragen war es aber häufig so, dass ich etwas nicht oder missverstanden habe. Selten war FHEM schuld!
Ab jetzt werde ich optimistischer!  8)