home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
72.82k stars 30.51k forks source link

KNX component stops working with HA >0.89.2 #22768

Closed derandiunddasbo closed 5 years ago

derandiunddasbo commented 5 years ago

Home Assistant release with the issue: >0.89.2

Last working Home Assistant release (if known): 0.89.2

Operating environment (Hass.io/Docker/Windows/etc.): Docker @ RPi3

Component/platform: https://www.home-assistant.io/components/knx/

Description of problem:

After an update from 0.89.2 to 0.90.2, the knx component fails to initialize with a TypeError because of an unexpected keyword argument 'rate_limit'.

In the change log I saw, that rate_limit is a new optional configuration option for the knx component.

The error message reads, as if rate_limit was implemented only partly or if some parts of the xknx component aren’t properly updated in the HA RPi docker image (homeassistant/raspberrypi3-homeassistant:0.90.2), but then it shouldn’t work for anybody using this image...?

Maybe it's only anything simple I’m missing, but I have no clue, what to look for. I didn't see any breaking changes from 0.89.2 to newer versions, which I would consider to affect the core knx component.

For now I had to roll back to 0.89.2, which is working without issues.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

knx:
  rate_limit: 20
  tunneling:
    host: '192.168.4.221'
    port: 3671
    local_ip: '192.168.4.5'
  fire_event: True
  fire_event_filter: ["3/3/16"]

Traceback (if applicable):

2019-04-03 15:50:33 ERROR (MainThread) [homeassistant.setup] Error during setup of component knx
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/setup.py", line 151, in _async_setup_component
    hass, processed_config)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/knx/__init__.py", line 86, in async_setup
    hass.data[DATA_KNX] = KNXModule(hass, config)
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/knx/__init__.py", line 137, in __init__
    self.init_xknx()
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/knx/__init__.py", line 145, in init_xknx
    rate_limit=self.config[DOMAIN][CONF_KNX_RATE_LIMIT])
TypeError: __init__() got an unexpected keyword argument 'rate_limit'

Additional information: Configuring rate_limit explicitly doesn’t help.

github-actions[bot] commented 5 years ago

Hey there @Julius2342, mind taking a look at this issue as its been labeled with a integration (knx) you are listed as a codeowner for? Thanks!

derandiunddasbo commented 5 years ago

Well... Problem solved.

Some time ago I hacked a quick & dirty support for DPT16.000 sensors directly into the xknx component inside my local HA docker container.

Today I noticed, that my DPT16.000 sensors still worked magically, even with newly created containers definitely not containing my extensions to the component.

After a bit more digging into the issue I discovered, that HA obviously grabbed some files from a backup of the site-package xknx folder I copied to /config/xknx/ before updating the container and mixed them up with the files coming with the new container. This obviously led to the knx component initialization error at startup.

After renaming /config/xknx/ to /config/xknx_backup/ everything again worked fine. Except of course my DPT-16 sensors which now failed as expected until I re-applied my changes.

Is this an expected behavior? Why do files from the config root folder supersede site-packages files coming with the installation? Isn't the custom_components folder supposed to hold customized component files?

farmio commented 5 years ago

I'm glad it worked out for you. DPT 16 support is on its way. Is /config/xknx/ in your PYTHONPATH ?

derandiunddasbo commented 5 years ago

Is /config/xknx/ in your PYTHONPATH ?

Probably not. These are the paths shown when running python from a bash inside the HA container:

bash-4.4# python -c "import sys; print(sys.path)"
['', '/usr/local/lib/python37.zip', '/usr/local/lib/python3.7', '/usr/local/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/site-packages']

These are all physical paths, no soft links to other locations etc.

I'd rather checked this with a python_script service from inside HA. But unfortunately it's impossible to import sys in a HA python script because of restrictions of the component. So I can't be 100% sure, HA isn't using any additional paths besides the paths set globally.

stale[bot] commented 5 years ago

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 now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.