Closed derandiunddasbo closed 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!
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?
I'm glad it worked out for you. DPT 16 support is on its way.
Is /config/xknx/
in your PYTHONPATH ?
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.
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.
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):Traceback (if applicable):
Additional information: Configuring
rate_limit
explicitly doesn’t help.