Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
No longer maintained; requires the pthsem library. Use only if you need to do regression testing.
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
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.
You specify a physical interface with
-b layer-2-URL. Example:
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.
-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.
-S option starts a multicast server; the default is port 3671 on address 126.96.36.199. 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.
-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.
-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.
-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.
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
Debugging et al.
-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
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
knxdwhich interface you want to affect is to add the
-Noption in front of every interface you do not want to monitor.
- replaced pthsem with libev (done with v0.12)
- add more tests
- add documentation
- see ToDo page