[Gelöst] Homematic Fernbedienung (HM-RC-Key4-3) Short/Long Button Event abfangen

Begonnen von northberlin, 09 Dezember 2016, 18:05:24

Vorheriges Thema - Nächstes Thema

northberlin

Hallo Forum,

ich habe leider im Forum zu meinem Problem nichts gefunden und meine Versuche sind ins Leere gelaufen. Vllt habt Ihr einen Tipp für mich wie ich das elegant lösen kann.

Zum Problem:

Ich möchte die Short und Long Click meiner Fernbedienung (HM-RC-Key4-3) abfangen und einen HTTP Request mittels Notify auslösen.

Für Short geht das wunderbar, allerdings habe ich Probleme beim Long Click.

Der löst eigentlich viele Events aus, desto länger man drückt desto mehr.

Events:

2016-12-09 17:59:35 CUL_HM Remote1 battery: ok
2016-12-09 17:59:35 CUL_HM Remote1 Remote1_light Long
2016-12-09 17:59:35 CUL_HM Remote1_light Long 1_157 (to broadcast)
2016-12-09 17:59:35 CUL_HM Remote1_light trigger: Long_157
2016-12-09 17:59:35 CUL_HM Remote1_light trigger_cnt: 157

2016-12-09 17:59:36 CUL_HM Remote1 battery: ok
2016-12-09 17:59:36 CUL_HM Remote1 Remote1_light Long
2016-12-09 17:59:36 CUL_HM Remote1_light Long 2_157 (to broadcast)
2016-12-09 17:59:36 CUL_HM Remote1_light trigger: Long_157
2016-12-09 17:59:36 CUL_HM Remote1_light trigger_cnt: 157

2016-12-09 17:59:36 CUL_HM Remote1 battery: ok
2016-12-09 17:59:36 CUL_HM Remote1 Remote1_light Long
2016-12-09 17:59:36 CUL_HM Remote1_light Long 3_157 (to broadcast)
2016-12-09 17:59:36 CUL_HM Remote1_light trigger: Long_157
2016-12-09 17:59:36 CUL_HM Remote1_light trigger_cnt: 157

2016-12-09 17:59:36 CUL_HM Remote1 battery: ok
2016-12-09 17:59:36 CUL_HM Remote1 Remote1_light Long
2016-12-09 17:59:36 CUL_HM Remote1_light Long 4_157 (to broadcast)
2016-12-09 17:59:36 CUL_HM Remote1_light trigger: Long_157
2016-12-09 17:59:36 CUL_HM Remote1_light trigger_cnt: 157


Ich will aber nur exakt einmal auf einen Long Click reagieren und den HTTP Request einmal auslösen.

Meine naiven Versuche bisher:


  • Notify mittels sleep um die für mich uninteressanten Events nicht zu verarbeiten, leider werden die wohl gequeued und nach dem sleep ebenso verarbeitet...
  • Notify das mittels ReadingsVal den state ausliest (state Long 6_157 (to broadcast)), da werden die zusammenhängenden Events mit einem Counter hochgezählt, leider komme ich da nur an Long ran, nicht aber an den Counter...


Ich freue mich über einen Tipp wie man das sinnvoll umsetzen kann!

frank

am schluss kommt immer das longRelease-event beim loslassen. das sollte funktionieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

northberlin

Zitat von: frank am 09 Dezember 2016, 18:23:56
am schluss kommt immer das longRelease-event beim loslassen. das sollte funktionieren.

Hi Frank,

dank Dir! Sowas habe ich gesucht aber nicht finden können. Ich bin leider auch noch ziemlich schlecht beim FHEM debuggen, mein Event Monitor ist leer (warum auch immer...) und ich bin nur per Telnet und Inform an den Events dran, da sehe ich ein Release Event nicht, daher hatte ich versucht mit den state Zustandsvariablen der Channels was anzufangen (wie oben beschrieben).

Mach ich da grundsätzlich was falsch auf der Suche nach diesem Event?

Pfriemler

LongRelease funktioniert an sich sehr zuverlässig, aber ist wenig intuitiv, weil die Aktion erst ausgelöst wird, wenn man die Taste loslässt.

Du hast schon richtig erkannt, dass während des Tastendrückens die erste Zahl hinter Long heraufgezählt wird (und die nach dem _ den eigentlichen Tastendruck heraufzählt), die Änderungen default bei HomeMatic alle 0,4 Sekunden. Statt auf alle Longs zu triggern, kannst Du auf ein einzelnes Event reagieren:
FB12_Btn_10:Long.5.* nutze ich bspw. in einem Notify, welches nach etwa 2 Sekunden getriggert wird (Schutz gegen Fehlbedienung). Ein Risiko besteht darin, dass dieses Event von FHEM übersehen wird, etwa weil eine Funkstörung den Empfang genau dieses Telegramms verhindert.
Triggerst Du auf ":Long.1.*", dann wird allerdings auch bei "Long 10_xxx" beginnend 10x getriggert (bis Long 19) und dann ab "Long 100" im Dauerfeuer.

Der Punkt nach Long ist tricky - Regex lässt grüßen. Um eine Beschäftigung damit kommst Du bei FHEM eigentlich nicht herum.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

northberlin

Zitat von: Pfriemler am 09 Dezember 2016, 22:39:38
LongRelease funktioniert an sich sehr zuverlässig, aber ist wenig intuitiv, weil die Aktion erst ausgelöst wird, wenn man die Taste loslässt.

Das hier würde ich gern verstehen, ich sehe dieses Event ja nirgends, sollte ich das über eine Telnet-Verbindung und "inform timer" sehen? Oder in welchem Log taucht das auf? Das ist vermutlich ein DAU Frage, sorry.


Zitat von: Pfriemler am 09 Dezember 2016, 22:39:38
FB12_Btn_10:Long.5.* nutze ich bspw. in einem Notify, welches nach etwa 2 Sekunden getriggert wird (Schutz gegen Fehlbedienung).

Das hat funktioniert. Danke! Hatte nie versucht per RegEx aus dem Event auf den Counter zu reagieren sondern immer nur per ReadingsVal. Mit der Lösung kann ich super leben!

Zu deinem Risikoeinwand, nutzt das Homematic Protokoll denn keine ACKs und evtl. ReSends? Ich habe bei mir noch nie erlebt das ein Paket nicht angekommen ist, aber ich werde das mal beobachten.

frank

ZitatDas hier würde ich gern verstehen, ich sehe dieses Event ja nirgends, sollte ich das über eine Telnet-Verbindung und "inform timer" sehen? Oder in welchem Log taucht das auf? Das ist vermutlich ein DAU Frage, sorry.
den eventmonitor würde ich schon "reparieren".
vielleicht hast du zuviele offene tabs/fensterzu fhem.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Pfriemler

Zitat von: northberlin am 10 Dezember 2016, 15:18:44
sehe dieses Event ja nirgends...
Sollte aber schon auftauchen. Sieht (in Auszügen) dann so aus:
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 1_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 2_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 3_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 4_6 (to vccu)
2016-12-10 20:03:40 CUL_HM FB4V_Btn4 Long 5_6 (to vccu)
2016-12-10 20:03:40 CUL_HM FB4V_Btn4 LongRelease 6_6 (to vccu)


ZitatHatte nie versucht per RegEx aus dem Event auf den Counter zu reagieren sondern immer nur per ReadingsVal
Ist aber der üblichere Weg.

ZitatZu deinem Risikoeinwand, nutzt das Homematic Protokoll denn keine ACKs und evtl. ReSends?
Doch, aber die beziehen sich auf den Gesamt-Sendevorgang an sich (wie oben also das Event _6). Quittiert per ACK wird nach dem LongRelease, die "Zwischensendungen" nicht. Kann man bei der Fernsteuerung von Dimmern gut sehen - die Sender-LED leuchtet während der Betätigung gelb und wird erst nach dem Loslassen kurz grün (wenn alles klappt).

Wie oft bei mir Long-Pakete "verfallen", kann ich nicht sagen - meine Mechanismen sind bis auf solche Ausnahmen wie oben entsprechend "gehärtet", da merke ich das nicht. Wenn man etwa mit DOIF arbeitet, kann man die wiederholte Ausführung der für Long vorgesehenen Aktionen recht einfach unterbinden, geht aber dennoch sicher, dass die Trigger verarbeitet werden.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

northberlin

Zitat von: Pfriemler am 10 Dezember 2016, 20:16:18
Sollte aber schon auftauchen. Sieht (in Auszügen) dann so aus:
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 1_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 2_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 3_6 (to vccu)
2016-12-10 20:03:39 CUL_HM FB4V_Btn4 Long 4_6 (to vccu)
2016-12-10 20:03:40 CUL_HM FB4V_Btn4 Long 5_6 (to vccu)
2016-12-10 20:03:40 CUL_HM FB4V_Btn4 LongRelease 6_6 (to vccu)


Wird bei mir über Telnet nicht angezeigt, da sieht es so aus:

CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 1_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237
CUL_HM Remote1 battery: ok
CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 2_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237
CUL_HM Remote1 battery: ok
CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 3_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237
CUL_HM Remote1 battery: ok
CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 4_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237
CUL_HM Remote1 battery: ok
CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 5_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237
CUL_HM Remote1 battery: ok
CUL_HM Remote1 Remote1_light Long
CUL_HM Remote1_light Long 6_237 (to broadcast)
CUL_HM Remote1_light trigger: Long_237
CUL_HM Remote1_light trigger_cnt: 237


Hast Du denn die gleiche Fernbedienung (HM-RC-Key4-3)? Ich habe gelesen da gibt es noch andere HM-RC-SEC (Alarm),... Vielleicht verhalten die sich anderes?
Oder ist es womöglich eine Konfiguration? Leider konnte ich meinen Event Monitor noch nicht zum Leben erwecken, aber ich gehe stark davon aus das das was ich über die Telnet Verbindung sehe, dem Inhalt des Event Monitors entspricht. Vllt kannst Du das auch bestätigen, das Du das LongRelease Event auch per Telnet siehst. Danke schonmal.

northberlin

Zitat von: frank am 10 Dezember 2016, 15:54:02
den eventmonitor würde ich schon "reparieren".
vielleicht hast du zuviele offene tabs/fensterzu fhem.

Habe ich leider bisher noch nicht geschafft. Alle möglichen Browser probiert, FHEM auf die aktuelle Version gebracht,..
Gelesen hatte ich auch das bei manchen Virenscanner und Netzwerkkartentreiber Probleme gemacht haben. Das läuft aber bei mir auf einem RPi, also nix exotisches und auch kein Virenscanner. Wenn Du noch irgendwelche Tipps hast bin ich Dir dankbar :)

Pfriemler

So, jetzt weiß ich auch wie das mit telnet geht ...
Habe gerade mal "inform on" angeworfen und das hier (gekürzt) gelesen:
CUL_HM FB4V_Btn4 trigger_cnt: 7
CUL_HM FB4V battery: ok
CUL_HM FB4V FB4V_Btn4 Long
CUL_HM FB4V_Btn4 Long 1_8 (to vccu)...
CUL_HM FB4V_Btn4 Long 2_8 (to vccu)
CUL_HM FB4V_Btn4 Long 3_8 (to vccu)
CUL_HM FB4V_Btn4 Long 4_8 (to vccu)
CUL_HM FB4V_Btn4 LongRelease 5_8 (to vccu)

Und da ist das LongRelease.

Das ist eine "HM-RC-4-2". Prinzipiell unterscheiden sich aber alle Geräte nicht voneinander, das Sendeverhalten ist IMHO überall gleich.
Die Sec-Alarm und die Key unterscheiden sich nur im Verhalten beim direkten Peeren.

Was mir noch auffällt: Dein Ding sendet an "broadcast". Das machen doch nur Geräte, die noch nicht gepairt sind. Dachte ich. Ist wohl falsch:
edit:
Fernbedienung gesucht, die noch an "broadcast" sendet. Ist auch auf meiner 12-Tasten-FB.
Und auf Longpress sendet die (gekürzt):
2016-12-12 19:20:29 CUL_HM FB12 battery: ok
2016-12-12 19:20:29 CUL_HM FB12 FB12_Btn_11 Long
2016-12-12 19:20:29 CUL_HM FB12_Btn_11 Long 1_50 (to broadcast)
2016-12-12 19:20:29 CUL_HM FB12_Btn_11 trigger: Long_50
2016-12-12 19:20:29 CUL_HM FB12_Btn_11 trigger_cnt: 50
2016-12-12 19:20:29 CUL_HM FB12 battery: ok
2016-12-12 19:20:29 CUL_HM FB12 FB12_Btn_11 Long
2016-12-12 19:20:29 CUL_HM FB12_Btn_11 Long 2_50 (to broadcast)
...
2016-12-12 19:20:30 CUL_HM FB12 battery: ok
2016-12-12 19:20:30 CUL_HM FB12 FB12_Btn_11 Long
2016-12-12 19:20:31 CUL_HM FB12_Btn_11 Long 7_50 (to broadcast)
2016-12-12 19:20:31 CUL_HM FB12_Btn_11 trigger: Long_50
2016-12-12 19:20:31 CUL_HM FB12_Btn_11 trigger_cnt: 50

Und endet dort, ohne LongRelease. That's it.

Womit geklärt wäre, warum Du kein LongRelease siehst.
Wofür ich gerade keine Erklärung habe: Die "FB12" ist gepairt mit meinem FHEM ebenso wie die "FB4V". Auf die betreffende Taste reagieren bei mir Notifys, aber die Tasten sind nicht gepeert - leuchtet nur gelb, ohne grüne Quittung. Die FB4V sendet "to vccu" und liefert LongRelease, die FB12_Btn_11 sendet an "broadcast" und da ist kein LongRelease.

Nun meine ich mich dunkel zu erinnern (wenn ich nicht falsch liege), dass Martin mal gesagt hat, die Fernbedienungen senden kein LongRelease, das Event erzeugt FHEM, wenn es keine Longs mehr bekommt. Für "broadcast" fühlt es sich aber nicht zuständig und erzeugt demzufolge nix.

(kopfkratz).

Zum Eventmonitor:
http://<ip-der-fhem-installation>:8083/fhem?cmd=style%20eventMonitor tut nicht?
Kaspersky? Bitdefender? Auf dem Gerät wo der Browser läuft (mit dem RPi hat das ja gar nichts zu tun)?

noch ein edit:
http://<ip-der-fhem-installation>:8085/fhem?cmd=style%20eventMonitor tut NICHT!
Auf der Tablet-Oberfläche (=8085) habe ich einige Räume ausgeblendet, aber der Link zum Eventmonitor tut. Nur bleibt die Seite leer.
Welchen Web-Port nutzt Du?

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

northberlin

Zitat von: Pfriemler am 12 Dezember 2016, 19:11:44
Zum Eventmonitor:
http://<ip-der-fhem-installation>:8083/fhem?cmd=style%20eventMonitor tut nicht?
Kaspersky? Bitdefender? Auf dem Gerät wo der Browser läuft (mit dem RPi hat das ja gar nichts zu tun)?

Erstmal zum Eventmonitor (das geht schneller  ;) ), das war natürlich ein selten dämlicher Denkfehler von mir zu glauben das der Server ein Problem hat. Natürlich war es der Client. Es liegt an meinem Rechner. Mit dem Telefon sehe ich im Eventmonitor Events. Kümmer ich mich mal später drum welche Komponente da genau Probleme macht...


Zitat von: Pfriemler am 12 Dezember 2016, 19:11:44
Womit geklärt wäre, warum Du kein LongRelease siehst.
Wofür ich gerade keine Erklärung habe: Die "FB12" ist gepairt mit meinem FHEM ebenso wie die "FB4V". Auf die betreffende Taste reagieren bei mir Notifys, aber die Tasten sind nicht gepeert - leuchtet nur gelb, ohne grüne Quittung. Die FB4V sendet "to vccu" und liefert LongRelease, die FB12_Btn_11 sendet an "broadcast" und da ist kein LongRelease.

Nun meine ich mich dunkel zu erinnern (wenn ich nicht falsch liege), dass Martin mal gesagt hat, die Fernbedienungen senden kein LongRelease, das Event erzeugt FHEM, wenn es keine Longs mehr bekommt. Für "broadcast" fühlt es sich aber nicht zuständig und erzeugt demzufolge nix.

Das mit dem Pairen war der richtige Hinweis. Die Thematik ist bisher komplett an mir vorbeigegangen. Durch autocreate habe ich die paar HM Geräte die ich verwende immer direkt gesehen und nutzen können. Jetzt hab ich mir erstmal den Wiki Artikel zum Pairen durchgelesen. Nach dem erfolgreichen Anlernen verhält sich die FB wie Deine und schickt auch keine Broadcasts mehr. Das LongRelease Event seh ich auch. Dank Dir für die Mühe das für mich Nachzutesten!


Pfriemler

Zitat von: northberlin am 12 Dezember 2016, 20:45:47
Das mit dem Pairen war der richtige Hinweis.

Das wäre ja auch nicht das erste Mal  :D
Wie auch immer - hab auch was dabei gelernt. Freut mich dass Deine Probleme nun zu lösen sein werden. Bleibt die Frage, warum die Buttons von meinen beiden gepairten Fernbedienungen mal an vccu, mal an broadcast senden. Aber das ist eine andere Geschichte und soll ein anderes Mal geklärt werden.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

northberlin

Zitat von: Pfriemler am 12 Dezember 2016, 22:32:26
Bleibt die Frage, warum die Buttons von meinen beiden gepairten Fernbedienungen mal an vccu, mal an broadcast senden. Aber das ist eine andere Geschichte und soll ein anderes Mal geklärt werden.

Mein Paring war auch nicht ganz problemlos. Ich musste erstmal lernen wie man das sieht man das pairing geklappt hat:

list <name>

und dann muss in den Readings stehen:

R_pairCentral  0xABCDEF

Bei mir stand da:

R_pairCentral  0x000000

Hab dann nochmal set <Name HM-Gerät> unpair ausgeführt, das Gerät gelöscht, den CUL mit set <CUL> hmPairForSec 600 in den Pairing modus gebracht und nochmal die Anlerntaste gedrückt. Danach war es dann tatsächlich gepaart. Vllt ist bei Dir auch was schief gegangen?!

Pfriemler

Unpair ist eigentlich nicht erforderlich. Wenn das Gerät noch nicht gepairt ist - sprich die Daten der Zentrale bei sich eingetragen hat - kann man von FHEM-Seite bliebig "drüberpairen" - da wird nichts doppelt oder dreifach eingetragen. Manche Geräte benötigen teilweise mehrere Versuche, Ursachen gibt es viele, oft ist es einfacher es einfach zu wiederholen. Eine beiden fraglichen Geräte sind natürlich sauber gepairt. Ich weiß doch wie das geht :-) ...
Ich kenne inzwischen eine gewisse Gelassenheit gegenüber Dingen, deren Korrekturaufwand den Nutzen übersteigt ... Klemmt der CUL auf SlowRF, läuft das Log mit Perl-Warnungen über usw ... shutdown restart und der Zauber legt sich in 95% aller Fälle so schnell wie er gekommen ist.

Punkt!

geht nich gips nich

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."