Yeah, this could be wrong device. I think I ”debugged” it to be this one by unplugging the usb cable when building the system in first place, but have never actually used it in configuration as the auto-detect has worked. Let’s ignore this observation and concentrate to first error… 
Oh man, now I have to dig into local add-ons 
I guess I will just revert back to old version for now
if it’s really related to the supervisor change, than an older version of the add-on won’t help. But please let me know if the 0.3.6 still works for you (which I kinda doubt)
Good Morning. First of all, I‘m new to this community seeking some support and try to my best to do the same.
I have somehow the same issue not able to connect my KNX USB Device anymore. But in my case everything worked fine, till I tried to add a Conbee 2 Stick to my Raspberry.
As soon I connect the knx usb i can see following:
Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/032
But it doesn‘t provide the message:
Detecting HardwareAction.ADD serial hardware /dev/ttyACM0
As I see with other USB devices.
Is there somewhere a config which links the /dev/ttyACM0 with /dev/serial/by-id/…
For example if I connect the ConBee 2 can see following:
21-02-10 07:05:14 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD usb hardware /dev/bus/usb/001/033
21-02-10 07:05:14 INFO (MainThread) [supervisor.hardware.monitor] Detecting HardwareAction.ADD serial hardware /dev/ttyACM0 - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2415980-if00
Is it possible that there is an incorrect linkage between /dev/tryACM0 and the dev/serial?
As I said, I‘m totally new to raspberry and home assistant world.
hello, I have exactly the same problem as you. did you manage to solve the problem?
going back does not work for me.
Thanks
the OS does the mapping, there is no config.
Ok, Is there an option to kind of reset the mapping? Or isn’t it odd, that I don’t get a message:
’
Detecting HardwareAction.ADD serial hardware /dev/ttyACM0 - /dev/serial/by-id/*****
if I connect my KNX USB Device?
this HW hotplug support is brand new in the most recent version of HA, so no idea how this is supposed to work.
I will investigate this further evening with new information on this thread after my previous comment. Will report back if/when I get it working.
1 Like
could you guys with USB issues try to downgrade the HA OS? Latest version brought a kernel update for the RPI4, so if all of you having issues with KNX USB interfaces are running it on a RPI4, maybe it’s a kernel issue? I’m just guessing though, trying to eliminate one of the dozens of changes that happend in the last two days in the HA ecosystem
Good idea, but it stopped working even before I upgraded, last night…
So I managed to add your adjusted add-on to HA as local add-on. Now you have to select a device and there is a dropdown to select the device. You can’t start without a device now. When adding the device I still receive errors:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): stoi
What now?
well, we would have to start debugging the issue and finding the root cause. But my linux knowledge is likely to limited for that. One thing you could check though is if the KNXD config generated by the add-on is correct and the correct device it used. HomeAssistant seems to rewrite the device paths in some cases, so when you picked a device by ID, HA returns the actual device path to the add-on. Let’s see if this mapping is correct. To do so, you have to SSH into the actual docker container of the add-on. Here is a howto
- first SSH into the OS (not a SSH add-on but the actual OS)
- then exit the automatically started HomeAssistant console by writing
login - once on bash of the actual OS, you can go into the container via
docker exec -it addon_local_knxd /bin/bash(this is the command to go into the local addon version, not the one from my repository since that has a different name) - you are now inside the container and your bash prompt prefix should have changed from just
#toroot@local-knxd:/$ - inside the container you can see the content of the generate config file via
cat /etc/knxd.ini
If the device listed there is correct, we at least know that the new config system of HA is working correctly. You can try to call knxd /etc/knxd.ini manually there and see if it outputs any additional errors messages that might help.
While inside the container you can also modify /etc/knxd.ini to try out a couple things or try giving the USB device write permissions and what not. I’m entirely clueless on how to actually debug this. I’ve been searching the webs for hours now but haven’t found the slightest clue.
Ok I checked the KNXD.ini and it looks fine - the usb port is visible (the same device which was added to HA config).
While calling knxd manually I still receive the error:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): stoi
Aborted (core dumped)
No clue what the problem is…
while inside the container you could try running knxd via command line parameter instead of the ini file and see if it’s working that way. If so, we might have to try to adjust the config file
Step by step 
So I tried to run knxd with command line parameters like this:
knxd -e 0.0.100 -E 0.0.101:7 -D -T -R -S -i 6721 -b usb:/dev/bus/usb/002/003
or
knxd -e 0.0.100 -E 0.0.101:7 -D -T -R -S -i 6721 -b usb:2:3:1:0
First command line is with the usb device as listed in HA config. It throws an error:
terminate called after throwing an instance of ‘std::invalid_argument’
what(): stoi
Second command line says:
E00000029: [18:B.usb] USBLowLevelDriver: setup config: LIBUSB_ERROR_BUSY
I then opened udevadm monitor in the knxd docker container, pulled out the usb cable and re-plugged it. I then received another port which I used in the knxd command line parameters and it started:
knxd -e 0.0.100 -E 0.0.101:7 -D -T -R -S -i 6721 -b usb:2:2:1:0
In HA the device is listed as: /dev/bus/usb/002/007 ? With this path it does not work with command line but also not in HA.
In general this seems to be a problem how USB devices are passed through. Before the update I could only see the USB ports in the hardware overview and they were like /dev/ttyUSB0 and not /dev/bus/usb…
yeah, the entire HW mapping system has been rewritten in the supervisor and more add-ons using USB devices seem to have issues now.
One user reported to get it working again when giving the add-on full HW access and disabling protected mode, which kinda seems obvious. But there has to be a better way. In my test branch I now added the usb: true config.json option in order to give the container full access to the USB bus, but apparently this also didn’t fix the issue for the user testing it (discussion about this is on my github). Kinda out of ideas on what else to try. Maybe Alpine 3.13 causes some issues on top of the supervisor changes (which also recently got released and used in the add-on base images of HomeAssistant which this add-on also uses). So we could also try to downgrade the base image in build.json to see if there is any progress
Hello,
I’ve downgrade HA to 2021.1.5 and i tried to install addon knxd but i’ve the same problem. Is it possible to downgrade the knxd addon to 0.3.6?
Thanks
I suppose you would have to install it as local add-on and grab the according files from this tag in my repo https://github.com/da-anda/hass-io-addons/tree/0.3.6
Bonjour Jerome,
If you have a snapshot prior to the update available you can also select KNXD and restore the previous version.
Just tried to restore only KNXD and it doesn’t fix the issue so yeah as Da-anda suspected, the issue is not the add-on but HA itself.
Hope to get some reaction since all my KNX domain is unmanageable since a week now