Core: KNX_EVENTS are dropped if they are sent from Home Assistant

[cassianyoung]

The problem

The problem easily be replicated by sending knx_events from Home Assistant while listening on the Developer/Events page. Events sent from Home Assistant are not read back as knx events.

The events make it to the bus. They successfully open covers etc, but they are missing from the list below "Listen to events"

There is a more general problem of some KNX_EVENTS not being read from the bus. For me, this seems to depend upon the source field on the KNX message "1.1.29" is read, "15.15.243" is not.

EXPECTED BEHAVIOUR
All knx events that meet the filter specified in the "fire_event_filter" should be read from the bus

STEPS TO REPRODUCE

1. In the UI, go to the Developer page. Enter "knx_event" in the "event to subscribe to" field. Press "start listening"
2. Attach a bus monitor to the KNX bus
3. Send a knx payload from the Developer/Services screen. In my case "address: 4/0/2 payload: 0"
4. The message appears on the bus monitor. The blinds open/close. But the "4/0/2" message is missing from the events page, although other knx messages are read from the bus.
   

   Environment

   • Home Assistant Core release with the issue: All versions from 0.116 to 0.117.6
   • Last working Home Assistant Core release (if known): 0.114.2
   • Operating environment (OS/Container/Supervised/Core): Problem with both container and supervised
   • Integration causing this issue: knx
   • Link to integration documentation on our website: https://www.home-assistant.io/integrations/knx/

   Problem-relevant configuration.yaml

   
   knx:
   tunneling:
   host: '192.168.1.2' #IP-Address of the knx IP interface
   port: 3671
   local_ip: '192.168.1.10' #IP-Address of the Home-Assistant server
   fire_event: true
   fire_event_filter: ["4/0/", "6/0/0", "6/0/4", "6/0/5", "6/0/6", "6/0/7", "6/0/8", "6/0/9", "6/0/10", "6/0/11", "0/0/1", "3/0/" ]
   cover:
   - name: Rear Ground Blinds
   move_long_address: '4/0/2'
   - name: Basement Blinds
   move_long_address: '4/0/4'
   - name: Cinema Cover
   move_long_address: '4/0/13'

   Traceback/Error logs

   Additional information

[farmio]

Please try again with 0.118. We have made a lot of bugfixes there, I think this was addressed too.

0.118 is currently in beta, the fixed are available from 0.118b1.

[cassianyoung]

Thanks, I just tried 0.118b1 and had the same behaviour. (Testing is much easier since I switched to hassio on a NUC)

I will try again on 0.118 when it comes out and let you know.

[probot-home-assistant[bot]]

knx documentation
knx source
_{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @julius2342, @marvin-w, mind taking a look at this issue as its been labeled with an integration (knx) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[farmio]

I had a second look at this. If you use the knx.send service all devices should get updated if they use the destination GA in the device too.

I'm not sure I totally agree with your expected behaviour:

All knx events that meet the filter specified in the "fire_event_filter" should be read from the bus

Imho the knx_event should only be triggered for incoming telegrams, not for outgoing.

---

Can you describe the situation you would need this?

[cassianyoung]

Here are some reasons I think this is a problem

1. I don't want to read outgoing telegrams, I want to read all telegrams that appear on the bus. All telegrams on the bus that match the filter should also be incoming messages.

2. This is the way Home Assistant worked until 0.116. The functionality has changed for no reason I can understand.

3. These are not the only telegrams being dropped. I am not a KNX expert, but as far as I can tell any telegrams generated from the internal logic created my installers aren't being read either. They were before 0.116.

4. I have two use cases that aren't currently working and are a problem for me:

a. I catch telegrams from my wall panels in Home Assistant and set complex scenes including lights, announcements and covers. I was able to activate these scenes by sending out a telegram from HA that matched the one sent from the wall panels i.e. from HA I could simulate a press of a button on the wall panel, that doesn't work any more.

b. I used to be able to catch the fact that the blinds at the rear of my house were being opened at night, from whatever source (which leads to angry calls from the neighbours) and shut the blinds again. These telegrams are not being picked up any more, as they were before 0.116.

[a005]

I catch telegrams from my wall panels
I used to be able to catch the fact that the blinds were being opened

These cases do not require to listen outgoing events (which are generated by the _knx.send_ service). "Steps to reproduce" don't relevant to your problem.

[cassianyoung]

I don't want to listen to outgoing events. I want to read all events on the bus that match the filter.

Can you please explain why the design was changed from 0.114.2 onwards? What value does this add?

The behaviour is not the same. Check it for yourself.

[marvin-w]

There was a bug for tunneling connections that resulted in telegrams being processed twice. That has been the only reason why this ever worked for you - not by design.

We will readd that events are thrown from both, incoming and outgoing telegrams. Additionally, we will add the telegram direction to the event data here https://github.com/home-assistant/core/blob/aa6376a69174bea235e047ee6a674bcb85e046c2/homeassistant/components/knx/__init__.py#L325

Then everyone can decide for him/herself if they want to fire stuff on incoming or outgoing events.

For reference: Outgoing telegrams are telegrams created by xknx. Incoming telegrams are those that you trigger from other sources.

Also, this will not be part of 0.118.0 and will thus not be working in that version.

[cassianyoung]

Great, thanks for looking at this!

[marvin-w]

Tracked here: https://github.com/XKNX/xknx/issues/497

[cassianyoung]

OK.

By the way, I think I see a wider issue. I can see other telegrams on the bus monitor that meet the filter, but that aren't being read by HA, which I don't think are outgoing. But maybe its best to retest the revised version to see if this goes away?

[farmio]

If they are not created by HA they should trigger an event. The logic behind that will probably not be touched, so if you could capture these telegrams we can have a look.