Peering Taster Aktor nur auf long press

[slor]

Ich teste am WE noch mal ein wenig.
Habe noch zwei Taster rumliegen.
Ich habe zwar ein doif, das schaltet zuverlässig einen anderen Aktor auf Short. Es ist ein Sonoff, daher kein peering dazu.
Keine Änderung, auch wenn ich das deaktivere.

[papa]

Vielleicht kann ich hier mal ein paar "gemonitorte" Infos beifügen. Bei der Implementierung der AskSin++ habe wir folgendes Verhalten festgestellt:

Bei LONGPRESS wird grundsätzlich eine Broadcast-Message gesendet. Es wird hier auch kein Ack erwartet. Erst beim LONGPRESSRELEASE wird genau eine Message an jeden Aktor gesendet (auch wenn mehrere Kanäle gepeert sind). Hier erfolgt dann auch erst das Signieren, wenn der Aktor danach fragt. Ein original HM-Dimmer hat auch erst nach dem RELEASE und dem Sign die entsprechende Helligkeit eingestellt.
Bei SHORTPRESS wird grundsätzlich jedem Aktor genau eine Nachricht gesendet - auch wenn mehrere Kanäle gepeert sind.

Der Aktor schaut bei jeder empfangenen Broadcast-Message in seine Peer-Listen, welcher Kanal mit dem sendenden Gerät gepeert ist. Und schaltet entsprechende Kanäle. Es reicht für LONGPRESS also aus, den Peer beim Aktor einzutragen. Er reagiert dann aber nicht mehr auf SHORTPRESS, da das kein Broadcast ist und er deshalb auch nicht in der Liste sucht.

[Otto123]

Das würde jetzt bedeuten, das der Button mit einem anderen Aktor gepeert ist.

Mein test gestern erzeugt sehr wohl einen broadcast bei Short

Code Auswählen Erweitern

Internals:
   DEF        101E7802
   NAME       FB12_Btn_02
   NOTIFYDEV  global
   NR         48
   NTFY_ORDER 50-FB12_Btn_02
   STATE      Short 1_119 (to broadcast)
   TYPE       CUL_HM
   chanNo     02
   device     FB12
   READINGS:
     2018-03-01 16:30:42   R-sign          on
     2018-03-01 16:30:42   RegL_01.          04:10 08:01 09:00 00:00
     2018-03-01 16:40:17   state           Short 1_119 (to broadcast)
     2018-03-01 16:40:17   trigger         Short_119
     2018-03-01 16:40:17   trigger_cnt     119
   helper:
     BNO        119
     BNOCNT     1
     peerIDsRaw ,00000000
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     shadowReg:
       RegL_00.    00:00
       RegL_01.     04:10 08:01 09:00 00:00
     tmpl:
Attributes:
   model      HM-RC-12
   peerIDs    00000000,
   room       Tasten

[papa]

Code Auswählen Erweitern

  STATE      Short 1_119 (to broadcast)

Das ist aber etwas anderes. Hier wurde eine Nachricht an die Adresse 000000 geschickt. Das pasiert, wenn nicht gepaired ist. In FHEM wird dann als Ziel broadcast eingesetzt. Ich meinte, dass in der Nachricht das Broadcast-Flag gesetzt ist. Dann erfolgt die Verarbeitung bei den Aktoren anders. Eine Nachricht an 000000 ohne Broadcast-Flag werden alle ignorieren.

[Otto123]

Sorry papa ich versteh deinen Einwand nicht. Aber kann sein das Du Recht hast...

ich kann das gerne nochmal wiederholen, aber macht das Sinn?
Sowohl meine FB als auch mein Aktor waren gepaired mit meiner VCCU in FHEM.
Beide waren nicht mit einander gepeered.
Ich habe lediglich im Aktor einseitig mit peerBulk die ID des FB12_Btn_02 eingetragen und er hat sofort auf ein Short mit toggle reagiert.

Ob dabei ein Broadcast mit oder ohne Flag entsteht kann ich nicht sagen.


Gruß Otto

[Pfriemler]

"to broadcast" senden bei mir aber auch Buttons, die zu einem definitiv gepairten Gerät gehören, aber noch keinen peerpartner kennen.

papas Beobachtung zum Verhalten bei longpress an Dimmer klingt für mich absolut nachvollziehbar. Das ACK kommt zum Schluss oder auch nicht.
Die übrigen Einwände lassen nachvollziehen, warum ein Aktor nur auf die broadcasts bei gedrücktem Button reagieren könnte... Bin irgendwie im Sonntagsmodus, um das verstehen zu können ...