Getting source address from a knx_event

Feature Requests
1

I posted this some days ago as a question to the configuration forum, but as nobody replied, I assume, what I want is currently not possible, at least not in any other way as the clunky WA I already mentioned in the post. Thus, I’ll make a feature request from it:

I want to use the source address of a knx event in an automation trigger, but the trigger data of knx_event currently only contains the destination address as the address attribute and event data in the data attribute.

The xknx module however deals with the source address as well, as it is printed to the log in debug mode:

2019-10-04 17:47:31 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="KNXIPServiceType.TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
 body="<TunnellingRequest communication_channel_id="1" sequence_counter="152" cemi="<CEMIFrame SourceAddress="PhysicalAddress("1.1.57")" DestinationAddress="GroupAddress("3/1/16")" Flags="1011110011100000" Command="APCICommand.GROUP_WRITE" payload="<DPTBinary value="0" />" />" />" />

Would it be possible to expose the source address and possibly also other attributes from a knx telegram to the trigger data of an event?

2

A more KNX way to achieve your goal would be to create a new GA for the specific function and bind only the device That shall trigger the event. In ETS you can then use it on other devices as listening GA or use OR logic of any device together with 3/1/16

3

While I somehow still dislike the idea of creating a GA only to bind it to a wall switch but not to an actual actuator, this would essentially become a sensor GA. And yes, of course I already have plenty of GAs in my setup, that are nothing else but binary sensors.

So yes, you are right, exactly this would be the “knx way”. :grinning:

1 Like
4

The recommendation by @farmio to use separate GAs that are only connected to HA instead of (silently) listening to the source address of a knx event still applies. At last (but not least), using “virtual” GAs exclusively for triggering events in HA makes connections between HA and KNX far more visible in the ETS application.

Nevertheless, I really appreciate, that at last with the current 2021.2 release, finally all metadata of a knx telegram, including the source address, have become available as data attributes for a knx_event.

So thank you for that change. I think these additional attributes will come in handy in some other cases.

1 Like