Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KNX_EVENTS are dropped if they are sent from Home Assistant #43256

Closed
cassianyoung opened this issue Nov 15, 2020 · 15 comments
Closed

KNX_EVENTS are dropped if they are sent from Home Assistant #43256

cassianyoung opened this issue Nov 15, 2020 · 15 comments

Comments

@cassianyoung
Copy link

cassianyoung commented Nov 15, 2020

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
Copy link
Contributor

farmio commented Nov 15, 2020

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
Copy link
Author

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
Copy link

knx documentation
knx source
(message by IssueLinks)

@probot-home-assistant
Copy link

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
Copy link
Contributor

farmio commented Nov 15, 2020

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
Copy link
Author

cassianyoung commented Nov 15, 2020

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
Copy link
Contributor

a005 commented Nov 16, 2020

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
Copy link
Author

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
Copy link
Contributor

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

self.hass.bus.async_fire(

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
Copy link
Author

Great, thanks for looking at this!

@marvin-w
Copy link
Contributor

marvin-w commented Nov 17, 2020

Tracked here: XKNX/xknx#497

@cassianyoung cassianyoung reopened this Nov 17, 2020
@cassianyoung
Copy link
Author

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
Copy link
Contributor

farmio commented Nov 17, 2020

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.

@github-actions
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@farmio
Copy link
Contributor

farmio commented Feb 22, 2021

Its jsut been fixed by #46809 ;)

@github-actions github-actions bot locked and limited conversation to collaborators Mar 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants