Matthias Urlichs edited this page Jan 21, 2018 · 17 revisions

knxd is a fork of eibd from the bcuskd-0.0.5 which is no longer maintained.


KNX (or EIB) is a low-speed bus system for home or building automation. It's an established industry standard with many manufacturers and very good interoperability.

KNX messages can be transmitted

  • on the physical bus wires which 99% of KNX devices use
  • as multicast datagrams via IP
  • as non-multicast datagrams, directed at a physical gateway
  • using a TCP connection
  • using a Unix socket

knxd's main use is to relay KNX messages between these interfaces. It also supports the standard gateway discovery protocol and offers various methods to monitor messages, many of which are currently somewhat broken (for historical reasons).


knxd is actively developed. Please choose the branch you're most comfortable with.

  • v0.12 "oldstable"

    No longer maintained; requires the pthsem library. Use only if you need to do regression testing.

  • v0.14 "stable"

    Current stable version for general use.

  • "dev" (to become v0.16)

    Development branch. New disruptive features here. Expect it to not build without hand-holding.


You might want to read the help text:

$ knxd --help

For an explanation of the command line parameters (and their order) see the Command line parameters page.

Options are parsed in order. Those which look like they might affect a specific interface probably do; they affect the next interface that's set up with -b. The same warning applies to knxd's debugging state.

Internally, starting with v0.14 options are converted to a .ini-style configuration file. You can separate these steps: run /usr/lib/knxd_args with knxd's arguments and redirect the output someplace. Then run knxd /that/file/name.


Every device in a KNX system requires a physical address, and knxd is no exception. On a simple bus system with no filtering or routing gateways you can use any free address; check your installation's documentation (which you'll need anyway). The default is 0.0.1 which usually works, except when it doesn't. Use -e 1.2.3 to change it.

Programs which talk to knxd are essentially KNX devices, so they may need their own address. The default is to re-use knxd's physical address, which doesn't work very well. Use -E 1.2.3:10 to tell knxd that addresses 1.2.3 through 1.2.12 are available for assignment to its clients.


Keep in mind that knxd is a router; therefore you need at least two interfaces, otherwise you can't route anything.

Physical Interfaces

You specify a physical interface with -b layer-2-URL. Example: -b tpuarts:/dev/ttyACM0. Ask whoever gave or sold you your interface if you're not sure which driver to use.

You may or may not need to use any interface-specific options.

Network interfaces

Local server

The -i and -u options tell knxd to accept client connections on a specific IP or Unix socket. You want one or both of these if you have client programs which specifically talk to knxd. This includes the tools, examples and language bindings which come with knxd.

Multicast server

The -S option starts a multicast server; the default is port 3671 on address Most likely, you really want options -R -S so that knxd actually routes multicast data. This is the network mode ETS uses when you attach to an interface. Note that multicast packets get blocked by some WLAN APs.

Tunneling server

-T -S starts a UDP-based server to which clients can connect. This is the network mode ETS uses if you attach to a specific host. Most likely, you really want -n HOSTNAME -D -T -R -S.

Multicast client

The -b ip: option also connects to multicast; however, it just treats the multicast address like a glorified KNX wire with no bells and whistles. Use this if some other device (knxd or otherwise) provides the server features.

Some older and/or buggy WLAN gateways don't forward multicast data.

Non-Multicast client

Use -b ipt:your-knx-gateway or -b iptn:your-knx-gateway. depending on whether you need address translation.

Some older KNX/IP interfaces don't really work with this method. It's recommended to use multicast wherever possible.

Single-server mode

With the exception of multicast, technically a server is not an interface – it creates a new one for every connecting client. Thus, starting knxd -u or knxd -TS just to facilitate a couple of clients to talk to each other (i.e. not using any other interface option) makes sense – in theory. However, in actual practice this is a configuration error. If you really intent to run knxd that way, you need to add a dummy: interface.

Debugging et al.

Use -t 0xffc -f 9 if you want to watch in excruciating detail what knxd is doing.

There are two ways to monitor bus messages with knxtool.

  • The "vbusmonitor" modes hook into the router and get a copy of every message.

    This is probably the mode you want.

  • The "busmonitor" modes detach your physical interface and send every bus message to the monitor.

    This mode is disruptive: the interface will not participate in routing KNX messages while you're monitoring it. Currently, the only way to tell knxd which interface you want to affect is to add the -N option in front of every interface you do not want to monitor.


Milestone 1.0.0

  • replaced pthsem with libev (done with v0.12)
  • add more tests
  • add documentation
  • see ToDo page
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.