FHEM Forum

Moin zusammen,

ich versuche gerade folgendes Problem zu lösen.
Ich habe eine 4/8er Fernbedienung (HM-RC-8) bei der ich mit den Tasten 1/2 eine Markise verbunden habe.
Mit den Tasten 3 und 4 sind einzelne Aktoren verbunden. Das klappt alles wunderbar.

Nun habe ich überlegt mit einem Notify eine weitere Zuordnung zu erzeugen

define nGA_FB_Btn_08 notify GA_FB_Btn_08.Long.* set GA_Markise pct 40

Auch das geht wie gewünscht, nun kommt aber das Problem.

Kann ich irgendwie realisieren, dass ich auch mit der Taste 1 oder 2 das notify nutzen kann?

Ein
define nGA_FB_Btn_02 notify GA_FB_Btn_02.Long.* set GA_Markise pct 40
funktioniert leider nicht. Wenn ich nun lang auf die Taste 2 drücke, dann fährt die Markise ca. 2 Sekunden raus und bleibt dann wieder stehen. Wo ist da mein Fehler?

LG
Tommi

Hallo Tommi,

ZitatTasten 1/2 eine Markise verbunden habe.

Du hast die beiden Tasten mit dem Aktor gepeert?

Dann bewirkt der Lange Tastendruck ja genau das was vorgesehen ist: er fährt solange Du drückst. (Standardverhalten)

Gruß Otto

Du solltest für sowas auch immer den Event-Monitor parallel ansehen.

Aus dem Kopf sehe ich zwei Probleme:
a) das (auch von Otto123 vermutete) direkte Peering bewirkt, dass der letzte Befehl, den der Aktor "sieht", die "Release"-Mitteilung ist. Die überschreibt dann alle vorhergehenden Anweisungen (ggf. eben auch die vom notify)
b) du wertest relativ viele Events aus und sendest daher vermutlich auch oft denselben Befehl raus => ungünstig...

Würde das wie folgt angehen:
1) das Peering sollte nur die kurzen Tastendrücke für Schaltaktionen auswerten. Dazu muss ggf. die Parametrierung auf dem Aktor geändert werden. Details wären die "lg"-Werte (oder so ähnlich) zu ändern, Details bitte dem Wiki (Startpunkt: https://wiki.fhem.de/wiki/Homematic_Peering_Beispiele?) und dem Anhang zum Einsteiger-pdf entnehmen;
2) den trigger für das notify auf den "Release"-Event einschränken und dann ggf. noch ein (kurzes) (FHEM-) sleep vor die eigentliche Funkanweisung (set ...) einfügen, dass sich erst der Funkverkehr beruhigen kann, bevor was neues kommt (nämlich das, das letztendlich gewollt ist).

Ah, okay, stimmt eigentlich,

kurz - so lange bis Ende oder ein anderer Druck kommt
lang - so lange, bis losgelassen wird

Gut, damit wäre es klar, warum es sich so verhält - ist ja richtig.

Letztendlich müsste das  LongRelease abgefragt werden, davor alles quasi auf 0 gesetzt werden, damit nichts weiter abgearbeitet wird und dann nach dem  LongRelease müsste dann der eigentliche Befehl GA_Markise pct 40 abgesetzt werden.

Dann schaue ich mir mal nochmal die Peering-Beispiele an, danke für die beiden Infos/Anregungen.

LG
Tommi

Zitat von: TommiH am 23 Juni 2021, 13:22:33
Letztendlich müsste das  LongRelease abgefragt werden,

[OT-Hinweis]
Die Wortwahl "abgefragt" irritiert mich etwas: MAn. sollte man sich angewöhnen, die Wortwahl an die "Denkweise" vom jeweiligen Modul anzupassen, und hier wäre dann m.E. eben besser: (Nur) der LongRelease-Event soll (als trigger) ausgewertet (und beachtet) werden.

Obacht: Wenn du direktes peering hast und eine VCCU eingerichtet, kann es sein, dass du zwei entsprechende Events hast. Dann bitte den Trigger noch weiter einschränken (Tipp: die Klammern dann in der regexp durch Punkte ersetzen).

Hallo TommiH

Da wir jetzt schon beim Feintuning sind :)
Dein Trigger ist nicht "günstig" siehe auch hier: https://forum.fhem.de/index.php?topic=115414.0

Long ist noch spezieller. Man kann aber so triggern, dass nur ein Long erkannt wird - den ersten Event im Hauptdevice und nicht im Channel nehmen! Taster4_01:Taster_Klingel:.Long :
2021-06-24 09:16:07 CUL_HM Taster4_01 Taster_Klingel Long
2021-06-24 09:16:08 CUL_HM Taster_Klingel Long 1_3 (to VCCU)
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:08 CUL_HM Taster_Klingel Long 2_3 (to VCCU)
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:08 CUL_HM Taster_Klingel Long 3_3 (to VCCU)
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:08 CUL_HM Taster_Klingel Long 4_3 (to VCCU)
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:08 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:09 CUL_HM Taster_Klingel Long 5_3 (to VCCU)
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:09 CUL_HM Taster_Klingel Long 6_3 (to VCCU)
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger_cnt: 3
2021-06-24 09:16:09 CUL_HM Taster4_01 CMDs_done
2021-06-24 09:16:09 CUL_HM Taster4_01 Taster_Klingel LongRelease
2021-06-24 09:16:09 CUL_HM Taster_Klingel LongRelease 6_3 (to VCCU)
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger: Long_3
2021-06-24 09:16:09 CUL_HM Taster_Klingel trigger_cnt: 3
Man kann auch gezielt auf einen bestimmten (den dritten) Long reagieren Taster_Klingel:Long.3_.* .
Man kann die Dauer auswerten:
defmod n_TasterklingelLong notify Taster_Klingel:Long.(\d*)_.* {my $string=$EVENT;;$string=~/Long.(\d*)_.*/;;my $number=$1;; if ($number > 3){Log 1,"So Lange gedrueckt: $number"}}
Man kann eine mehrfachtriggerung verhindern durch das Attribute disabledAfterTrigger

ZitatdisabledAfterTrigger <sekunden>
deaktiviert die Ausführung für <sekunden> nach dem das notify ausgelöst wurde.

Zu Long_Release : mMn drückt die eine Hälfte der Menschheit den Knopf bis etwas passiert - die sind bei dieser Logik quasi raus :)

Gruß Otto

Zitat von: Otto123 am 24 Juni 2021, 09:24:57
Zu Long_Release : mMn drückt die eine Hälfte der Menschheit den Knopf bis etwas passiert - die sind bei dieser Logik quasi raus :)

(Im Prinzip): fully agreed!

Das sollte man ggf. nur triggern lassen, um z.B. einen Dimmprozess zu beenden.

Hier ist es aber etwas speziell: Wer weiß, dass ein langer Tastendruck eine ganz bestimmte Position anfahren soll, sollte sich auch merken können, dass das ganze erst losläuft, wenn er losläßt ::) ... Ob sich das mit einer direkten Reaktion hier mit direktem Peering (?) überhaupt lösen ließe, habe ich aber auch nicht näher untersucht.

warum eigentlich zusätzlich ein notify nutzen?
das sollte doch auch direkt über das peering funktionieren.