Access Keys:
Skip to content (Access Key - 0)

Technical Overview of KNX

Main concept of the specification is that of interworking which is a made up word to describe interaction around a standard message protocol. Unlike proprietary end-to-end solutions, where one vendor offers an integration solution and interacts with others on a one-off basis, here vendors implement the standard KNX messages. This opens up the end-to-end stack at each step of the interaction. For example panels from many vendors can interact with lighting from other, completely unrelated vendors. The advantage of this is an economical one in the market place. Where the mainframe was end-to-end solution with high prices (and margins), the PC offered modularity around an Operating System where unrelated vendors could participate in a solution by implementing the drivers. As a result there is a wealth of offering at every step of the solution. KNX creates a marketplace.

  • Works over various twisted pair, powerline (230V or low voltage bus), RF and IP. In the real world the only media supported is TP with low voltage.
  • Standard: ISO/IEC 14543-3, ANSI + certain Europe specific standard and a Chinese standard.
  • Operation over IP or mobile available.


  • lighting
  • blinds & shutters
  • heating, ventilation and air control (HVAC)
  • audio/video control (AV)
  • operation and visualization
  • security
  • remote access


KNX Group address

The communication between devices is made with telegrams sent to Group addresses. A Group address is a logical name for a given topic linking the output of a sensor with the input of an actuator. The topic can be encoded in a bit, a nibble, a byte, 2 bytes. These are considered signatures. Compatible devices listen in a group. One or more sensors emit the bits many actuators listen on a given group. This is the primary way to connect things in KNX.

For example, connecting the event click on is sent to a group we can call lights on. The actuators are drag-and-dropped in this group and when a message is sent with the group address on, the devices know to answer.

One can view a device, sensor or actuator, as a collection of objects. Whether these objects are exported, in a Remote Procedure Call (RPC) way is a configuration option. Once they are exported the output objects can be linked to the input objects by way of a communication group addresses.

A group address is represented 2/3/4 (with slashes).

Is a group address the equivalent of Scene? yes and no. A group communication address is based on a type that is either bit, nibble, byte and one value a scene may involve several types (on bits and absolute dimming for example) and different value (one dimming at 25 and others at 75). So while programming groups that all respond to exactly the same input is a trivial task in KNX, a scene is a difficult, product dependent issue.

KNX Physical address

A device always has a physical address. A Physical address is of the form n/n/n where the numbers represent a real topology. For example 1.2.4 (with dots). A physical address is allocated to each device during commissioning. A button needs to be pressed on the physical device the first time around for the commissioning to happen. Even on sub-sequent prints of the addresses the device require physical button pressing on them. It makes sense that devices be identified during installation. You can also ask for a given address to blink so you can physically identify a unit in the field. (blinking light).

The Physical addresses have an impact on topology. Because the devices are memory constrained, the numbers cannot be more than 64. This, it seems, means the line segments need to have 64 devices and it impacts the electricians work.

The lack of a controller

A system or controller is included in the network during commissioning and maintenance. But during normal run time a KNX install is head-less, it doesn't need the Controller CPU to listen to group messages. The advantage is that a KNX install is robust and really doesn't have a logical point of failure. The disadvantage is that advanced features must be implemented in silicon and by the spec. This will slow down the evolution of the spec outside of S-mode.

Downloading VD files for KNX ETS

If we adapt Beehive to support ETS product browsing, loading the VD files would be a good plus. The VD files are actually standardized schema based files. They are actually database files that can be imported as such. In that way a Beehive extension should be possible.

The other problem with ETS VD files is that each vendor provides their own on their website. For newbies it can be a pain to find new material. Even experienced installers stick to the versions they have. A browsing mechanism for the latest drivers could be a useful feature. Many of the licenses I read do not have a beef with actual redistribution of the binaries to installers by definition of the model. Many of them require marketing information however.

A useful resource in loading these files is the following German-only website. The "Los" button is the one you want to push to get to the resource. Since the VD file format is defined by spec we should be able to parse it for browsing and would be in a position to redistribute binaries ideally.

KNX on Beehive. Just like we have LIRC on Beehive.

What is an object in KNX?

An object in KNX is really an attribute of an object. For example the object actuator/switch which can turn on and off a light and do contact closure will have an input called long/short operation which takes a bit. They will be exposed as 2 objects and the linking is done between objects. What is called an object in Object Oriented software is the superset.

Does the KNX specification define a object model?

Yes and No. The KNX specification defines every object seen in a environment. Not every object is exposed by the device, they need to be turned on during configuration so that an RPC like call can be made. It does not however define an API that can be accessed. There is no notion of programming the runtime other than group linking of objects and configuration.

KNX Specifications

KNX specifications include no less than 10 volumes.

Volume 3 - System Specification is the core of the spec, defining the reference for both hardware and software implementations.

The other volumes cover general architecture, information on specification tests and certification, conformance tests, device profile definitions, etc.

Hardware and Networking Notes

Depending on which media is used:


KNX specification defines KNX telegrams which can be sent over IP using UDP (unicast and multicast). No additional equipment besides regular Ethernet hardware is required. 10Mbit Ethernet is sufficient. The communication stack is a standard IP stack (what we get from Linux with Java socket abstraction) + what is called the KNX Common Kernel on top of IP which basically handles the KNX Telegram <--> UDP translation.

Sample IP Gateway (ABB i-bus EIB/KNX), ABB i-bus KNX IP Router


No custom components required. RF protocol is defined in the KNX specification. KNX/RF doesn't seem to be used much. Since most devices are powered by the bus, RF does require independent powering.

Bitrate 16kbps.

KNX Over Powerline (230V)

Needs a bus coupling unit with the appropriate circuitry + comms stack on top of ASIC for PL110 (?)

Bitrate 1200bps.

KNX Over Twisted Pair

Chipsets and comms stack available from KNX system vendors.

Bitrate 9600bps.

Bus Coupling Units

BCU. They connect the devices to the Bus. If the Bus is a TP (green wire) then a BCU is something that takes power and signal from the cable and feeds the application module (sensor). Every device is a BCU and a application module on top. The BCU contains the physical address, the Application module is never programmed with an address.

KNX Tools

KNX Association provides a collection of software tools for software developers, integrators and installers to ease the adoption of the platform.

ETS - Engineering Tool Software

Tools for configuring KNX certified products. ETS is independent of manufacturer, installer/integrator can use it to orchestrate all compliant devices over all different media.

The ETS is licensed per PC. Price ~€950 per license. It uses Falcon (see below) as protocol stack. ETS is Windows only.


PC (Windows DCOM & .NET) software component implementing the KNX communication stack over IP, RS232 and USB. Targeted for software developers.

Pricing depends on number of IPs, from €250 single IP/single connection, €5000 for unlimited IPs with single connection each up to €10,000 for unlimited IPs with unlimited number of concurrent connections.

Crippled demo versions are available.

Interesting implementations

Open source or otherwise relevant KNX projects.


Open source implementation, GPL: and

A point of interest for OR is that Calimero abstract away most of the network implementation for an application like the ORC. Access to the network becomes a simple API programming matter. It can be seen as a gateway to the KNX bus.

KNX USB Linux Driver

User space module for Linux that bridges USB and KNX bus. LGPL license.

With a Simple USB coupler this is in essence a serial gateway to the KNX bus. The API seems less well documented than Calimero. The community seems as vibrant.


  • For device manufacturers: certification program to achieve the right to use KNX logo, requires also ISO 9001 compliance
  • Software certification also exists.
  • Certified training centers get access to training material from KNX association. Instructor certification.
Labels: , , , , , , , , , , ,

Added by Juha Lindfors

Last edit by Juha Lindfors on Nov 28, 2009 12:33

Adaptavist Theme Builder Powered by Atlassian Confluence