KNXD add-on: convert your KNX-USB interface into an IP interface that can be used by HA

Hey community,

I’ve been working on a knxd add-on for hass-io and would like to share my progress. KNXD is a daemon/library that can turn your device into a KNX IP-Interface/gateway and a lot more. The aim of my add-on is to provide a KNX IP-Interface by utilizing connected TPUART/USB devices. In my case I have a TPUART USB-stick from, which I can now use to program my KNX devices from ETS software and also use it as IP gateway for the KNX hass component.

Maybe it’s of use for somebody else. Here is the source code / repository

I still have to clean up the docker image and get rid of the build dependencies, after the compilation (on device for now) of the lib. But it at least for me seems to do the job already - aka it’s working for me - which is why I decided to share the add-on.


Does the TPUART act as a normal KNX/IP interface?

yes, that’s how I configured knxd to behave. You run this add-on along with some TPUART eib connector (can be an USB stick like mine, or f.e. a PI HAT) or an existing KNX-USB interface (like the ones from Gira, MDT, …) and have a KNX-IP interface. I’m using this also to program my KNX devices via ETS. The nice thing about knxd is, you can have it run multiple “servers”, so f.e. the IP interface and a router to connect two KNX buses via IP.

Actually it would make a lot of sense for hass-io to ship knxd by default, because it also has bindings to dozens of programming languages, like python. Which means, that xknx would be somewhat superfluos or could be heavily stripped down (ripping out low level knx stuff etc) and likely have slightly better performance (that’s just my suspicion that native C code is faster than python, especially on something like a PI). This is at least what I understood from their docs.

Here is the link to the USB-stick I’m using:

and this would be a one-wire HAT for the PI that could be combined with a knx TPUART module:

This is really interesting work. I just bought a “Tapko UIM RF” KNX-RF USB stick from Germany to use on my Rpi3 for hopefully communicating with my Siemens Synco Living heating system, which communicates via KNX-RF. And eventually getting my temperatures and perhaps more in HomeKit.

Do you know if this should work with your addon ? Link here:

Also, does your addon work with the or would Hassbian be better ? EDIT: It’s a addon, ok.

depends on how this USB stick is showing up in linux, but it should work as long as the linux kernel does support it.

My add-on is for, so yes, it’ll work with it. No idea of this add-on is compatible with Hassbian, but since you should have a full blown debian core with Hassbian, you should be able to install knxd in the regular way. See

I’ll think I’ll go for and noticed this is for that, so everything is go.

Tapko says their stick has native Linux HID support for the USB stick so excited to try it out with your addon!

Right. So SSHed into the Rpi3 with installation on it, ran “hassio host hardware” and found that my Tapko USB KNX-RF stick seems to be identified as serial device /dev/TTYAMA0.

Tried to change this in the config field for your add-on in but I still get an error about /dev/TTYACM0. Is this device address hardcoded somewhere else? I see it in the config file in your GitHub repository, but I can’t reach that config with the Samba share add-on it seems.

Also should interface be “tpuart” or “usb” for me then, do you think ?

BTW, this is the output of dmesg for usb items:

    core-ssh:~# dmesg | grep usb
[    0.150838] usbcore: registered new interface driver usbfs
[    0.150926] usbcore: registered new interface driver hub
[    0.151025] usbcore: registered new device driver usb
[    0.639780] usbcore: registered new interface driver smsc95xx
[    1.040931] dwc_otg 3f980000.usb: DWC OTG Controller
[    1.040977] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    1.041011] dwc_otg 3f980000.usb: irq 62, io mem 0x00000000
[    1.041269] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.041283] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.041295] usb usb1: Product: DWC OTG Controller
[    1.041307] usb usb1: Manufacturer: Linux 4.4.50 dwc_otg_hcd
[    1.041318] usb usb1: SerialNumber: 3f980000.usb
[    1.042885] usbcore: registered new interface driver usb-storage
[    1.164970] usbcore: registered new interface driver usbhid
[    1.164975] usbhid: USB HID core driver
[    1.414655] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    1.614833] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    1.614845] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.894621] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    1.994903] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    1.994917] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.057622] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:08:a9:0a
[    2.134667] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    2.240804] usb 1-1.2: New USB device found, idVendor=28c2, idProduct=0008
[    2.240817] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.240823] usb 1-1.2: Product: TAPKO KNX RF+           
[    2.240829] usb 1-1.2: Manufacturer: TAPKO GmbH              
[    2.240835] usb 1-1.2: SerialNumber: 0072FB00018C
[    2.245435] hid-generic 0003:28C2:0008.0001: hiddev0,hidraw0: USB HID v1.11 Device [TAPKO GmbH               TAPKO KNX RF+           ] on usb-3f980000.usb-1.2/input0
[    3.677188] usbcore: registered new interface driver brcmfmac

phew, actually no idea. I’m not really a linux guy and was happy that I manged it that far with the add-on :wink: What I did during my initial setup and testing on how I have to configure knxd, was that I manually started the container via SSH and connected to it’s bash for debugging. If I would just remember the docker command I used back then, I’d have a look and see what dmesg is showing for my USB stick. If I’ll figure it out agian, I’ll let you know.

But since dmesg doesn’t list anythiing “UART”, I’d try using the USB setting for knxd. If you speak German, you can also check out for help on configuring knxd for your device and needs.

Do you see anything in the log of the add-on? knxd should give errors if it can’t use the device. And no, there is no other setting to modify. The values entered in the add-on config will be copied into the knxd config on startup of the add-on

that’s my dmesg. Also no mention of UART, besides of the product name. So sorry, no idea what the correct setting for your USB stick is

[    2.297791] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
[    2.413484] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
[    2.413514] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[    2.413530] usb 1-1.3: Product: TPUART
[    2.413545] usb 1-1.3: Manufacturer: busware . de

Great work on the addon anyway :slight_smile:

i just noticed that I change the config options in the UI to my device name /dev/ttyama0 but the log still complains it cant find /dev/ttyacm0. And in the config file in the github for your addon there are additional places where you specify device /dev/ttyacm0 which I cant change in the UI.

ah, now I see what you mean with “/dev/ttyACM0” being in several places in the config.json. Well, from how I understood the HASS docs, this setting should instruct docker to map any connected devices to the container and the line above is actually just a left over from my earlier tests. If this setting doesn’t work that way, I’ll need some help from a more experienced HASS add-on developer to guide me. If you like, I can add your device to the list as well and bump the add-on version so that you can test if it fixes it. Or I remove the “devices” line and you can check again (in case this line overrules the auto setting)

edit: I just removed the hardcoded devices list - please try again (my PI2 is still compiling the new version, so can’t tell yet if it still works for me)

Great! Looking forward to testing the new version! With none or more hardcoded devices.

I just got some new problems when updated to 0.95 yesterday… seems I get lots of errors everywhere. I’ll let you know. Please keep me in the loop about what you find out as well.

compile just finished and it’s still working fine for me. So I hope it’s also working fine for you now.

Is it working for you now?

No my USB HID device is never attached to DietPi, Rapbian og (ResinOS) Linuxes. I can see it in dmesg and the vendor and product codes under lsusb, but is not attached. My ttyAMA0 is something else, and this should be ttyUSB*. Wondering if I have to dabble with dev rules and get them applied system-wide.:frowning:

Thanks for this add-on da-anda.

I kindly ask for help, because I was not able to get it running.
Always get an error:
F00000000: [12:interface] Link down, terminating
Maybe it’s just a lack in understanding and setting it up correctly.
I have to admit, that I’am pretty new to hass.

I use a Hager USB device, which I had been running for years with the old eibd. So HW and HW-connections to the TP should be the problem.
[ 2.111609] usb 1-1.5: new full-speed USB device number 4 using dwc_otg
[ 2.271115] usb 1-1.5: New USB device found, idVendor=135e, idProduct=0025
[ 2.274001] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.274010] usb 1-1.5: Product: KNX-USB Data Interface
[ 2.274016] usb 1-1.5: Manufacturer: Hager Electro
[ 2.292879] hid-generic 0003:135E:0025.0001: hiddev96,hidraw0: USB HID v1.01 Device [Hager Electro KNX-USB Data Interfa
ce] on usb-3f980000.usb-1.5/input0

ls -l /dev/ttyA*
crw-rw---- 1 root audio 204, 64 Jul 30 22:42 /dev/ttyAMA0
Is ownership and group ok for knxd ?

knxd Config:
“address”: “0.0.1”,
“client_address”: “0.0.1:10”,
“interface”: “tpuart”,
“device”: “/dev/ttyAMA0”,
“custom_config”: “”
I assume address is the knx adress that th IF uses for TPUART comm.
But what is “client address” ?

Container Host
3671/udp 3671
6720/tcp 6720

config_file: xknx.yaml

How could I further trace this down ?
Thanks for any help.

Hey. Sorry for the delayed response. I honestly don’t know the answer to your question. I’m neither a linux export nor know much about knxd itself. I followed the online documentation of knxd and with a little help of the I was finally able to find the correct configuration for my setup. Haven’t touched it ever since.
But see here on how those HASS add-on variables are mapped to the knxd configuration file:

And if my default config template doesn’t suite your needs, you can specify your own knxd config to use in the setting “custom_config”.

edit: having a brief read on I think “tpuart” is the wrong interface to use in your case. Try “usb”

edit2: also see

Problem SOLVED !!!

Thanks for the response da-anda.
In the meantime I have connected the same TPUART USB-stick from ( and used the same default knxd config.

My fault was, that after logged intop hassio with the standard ssh, I believed this is the “real” system, but now I understand its only a docker instance not showing up the read physical world of the raspi. This led to the wrong assumption, that the only USB device I found as /dev/ttyAMA0 must be the KNS-USB IF.

Now I learned how to ssh into the “real” sysem, to see whats really going on
Then changed knxd config back to default with “device”: “/dev/ttyACM0”.
Now I could see the knxd successfull started up and running.

Secondly I had to remove the ip-addresses under knx: section in configuration.yaml, just leaving single line:

This is a huge step forward in setting up ha, because knx gives access to nearly everything in my house.

Hi, hopefully someone can help me.
The only way our alarmsystem can communicate with home automation is thru KNX.
The first thing I was thinking, ‘hmm I’ve seen a KNX component somewhere’.
After some reading I discovered that Hass needs to connect to a KNX IP gateway.
Because I don’t own any KNX hardware I went on a search for a software solution and stumbled on knxd and this topic.
I am wondering if knxd can be used to act as sort of a broker (router/relay/server or so) to pickup the messages send by our alarmsystem and relay them to Hass?

Any help would be great!

Hi, basically knxd can act as IP router/relay/gateway for your KNX bus, but you will still need KNX hardware (and likely also software). So in order for the KNX bus to work, it needs a power supply. Then, you have to give your alarm system a KNX address and also assign group addresses to it’s “entry points” (via additional software like ETS5), so that you can read specific values from it or turn things on/off. And in order for KNXD to do it’s job, you also need some sort of KNX interface (USB, IP, …). Now, since you don’t have any KNX hw yet, I would suggest to go and buy a KNX IP interface, which makes knxd and this add-on basically obsolete, since you can use this interface directly with the KNX component of HomeAssistant. IP interfaces are not that much more expensive than USB interfaces (at least not the one from the brand MDT IIRC).
The aim of this add-on basically is to turn any existing KNX interface you have into a IP interface to which HomeAssistant can connect to. So if you would already have a USB interface, you could turn it into a IP interface using knxd and this add-on. If you want to save a few bucks and like tinkering, you can also grab a USB interface and use this add-on, but it’s way easier for you to directly get a IP interface.

As for the additional software you will need: You can get some sort of “Demo” version of the ETS5 KNX software after you passed the free ETS5 online training (it’s not hard, basically watching videos and answering questions right after each video). Alternatively you could buy ETS-Inside . But since I never used ETS-Inside and thus don’t know if you in addition will still need a IP/USB interface to control it, you’d have to do some research on it on your own.