-
Notifications
You must be signed in to change notification settings - Fork 195
Home
knxd is a fork of eibd from the bcusdk-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 deprecated pthsem library. Use this only if you need to do regression testing.
-
v0.14 "master"
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.
-
"deb"
This branch follows "stable" but also contains the files required for building on Debian, Ubuntu, or other Linux distributions derived from them.
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 or --eibaddr=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 or --client-addrs=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 or --layer2=layer-2-URL. Example: -b tpuarts:/dev/ttyACM0 or --layer2=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.
The -i or --listen-tcp option tells knxd to accept client connections on a specific IP. The -u or --listen-local option tells knxd to accept client connections on a 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.
The -S or --Server option starts a multicast server; the default is port 3671 on address 224.0.23.12. Most likely, you really want options -R -S or --Routing --Server 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 or --Tunnelling --Server 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 or --Name=HOSTNAME --Discovery --Tunnelling --Routing --Server.
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.
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.
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 because it's almost never what you actually want. If you really intent to run knxd that way, you need to add a dummy interface.
Use -t 0xffc -f 9 if you want to watch in excruciating detail what knxd is doing.
There used to be 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; it's also the one that's currently supported.
-
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. As knxd now supports multiple interfaces and the old
knxtoolprotocol has no way to tell knxd which to use, this mode is currently not supported.
- replaced pthsem with libev (done with v0.12)
- add more tests
- add documentation
- see ToDo page