Ich denke eher, dass das im Sensor-Device beim Tastendruck erledigt wird. D.h. auch wenn es mehrere Peerings zu einem Device gibt, wird nur eine Nachricht geschickt.
[...] Bei HBW prüfen wir ja, ob der Empfänger-Kanal richtig gesetzt wurde, oder?
Ja, es müssen Senderadresse, Senderkanal und Zielkanal übereinstimmen, sonst wird das peering im Aktor nicht angewendet.
Hätte denn diese KeyEvent Nachricht, die mehrere Kanäle im Aktor schaltet auch mehrere Kanalnummern im Frame? Der Aktor kann ja nicht einfach den Ziel- oder Quellkanal ignorieren und nur auf die Quelladresse schauen...
Leicht erweitertes Setup:
Sensor A ch 1 -> Aktor B ch 1 (short action, toggle)
Sensor A ch 1 -> Aktor B ch 2 (short action, toggle)
Sensor A ch 2 -> Aktor B ch 1 (short action, on)
Aktor B sollte ja nur die ersten beiden peering Aktionen bei einem 'short' KeyEvent von Sensor A ch 1 ausführen... bin mir nicht sicher wie das gehen könnte..

Ich meinte das ja auch gar nicht als komplette Lösung des Problems. Ich hatte mir nur überlegt, wie man die Anzahl der Nachrichten ggf. reduzieren kann. Ansonsten muss man ja jedesmal auf ein ACK warten, was dann in der Summe dazu führen kann, dass der ganze Vorgang ein paar Sekunden dauert. Das wäre natürlich sehr lästig. Wenn man dann wenigstens alle Kanäle eines Device zusammenfassen könnte, dann wäre schon viel geholfen.
Stimmt, mit nur drei peerings ist schon eine leichte Verzögerung sichtbar. Wäre gut weniger auf die Leitung zu schicken.
PS: Hab mal ein bisschen in den XML geschaut, bzgl. den Key Events... "KEY_SIM_*" hat im Frame receiver_channel_field="11" (id="KEY_SIM_SHORT" direction="from_device" type="#K" channel_field="10" receiver_channel_field="11")
Im "normalen" Key Event ist das nicht vorhanden, d.h. HBW nutzt immer "KEY_SIM_*"? (da die Zielkanalnummer mit geschickt wird)
id="KEY_EVENT_SHORT" direction="from_device" event="true" type="#K" channel_field="10"
Ich hatte bisher nur gesehen das beim KeyEvent an die Broadcast Adresse Kanal 0 genutzt wird...
Gruß,
Thomas