A guide to using KNX over IP

Originally designed in the early 1990s the KNX twisted pair (TP1) bus has proven time and time again it is the most reliable and scalable building automation system available. Although the bus runs at a relatively slow baud rate (9600bps), especially when compared to newer systems what is often overlooked is that by having this baud rate, the bus can have long cable lengths, a free topology and greatly reduced power consumption of the end devices that are attached to it.

Even at that baud rate, the bus can still support over 50 telegrams per second which is more than sufficient given a KNX system can be broken up into lines and areas, each independent from the other and with their own 50 telegrams per second.

However, with advancements in the use of KNX, there is certainly a need for higher transmission rates, especially at a system wide level. With visualisation devices and central monitoring becoming more common, there is often a requirement for all telegrams to be available at the highest topological level along with a large number of feedback telegrams. 

As part of the ongoing evolution of KNX, an IP telegram was developed which allows for the use of Ethernet as a low cost, high-bandwidth medium that is common in most buildings, be they residential or commercial. It is important to understand however, that whilst LAN networks provide many benefits, the requirement to have a defined and controlled infrastructure means KNX TP1 is here to stay.

To allow the inclusion of IP as a communication medium, the KNX Association created a standardised KNX/IP telegram. This is also based on the OSI reference model with different definitions for the Transport, Network and Physical layers. Put simply, this defines how the enclosed TP1 telegram should be distributed.

The actual TP1 telegram is maintained, along with an additional field to define the KNXnet/IP action, which can be any of the following services:

• KNXnet/IP Core
• KNXnet/IP Device Management
• KNXnet/IP Tunnelling
• KNXnet/IP Routing
• KNXnet/IP Remote Logging
• KNXnet/IP Remote Configuration and Diagnosis
• KNXnet/IP Object Server

Most of the above are service functions that are self-maintained, so the main terms we need to focus on are KNXnet/IP Tunnelling and KNXnet/IP Routing. 

KNXnet/IP Tunnelling

KNXnet/IP Tunnelling is the primary method of interfacing to a KNX system and allows for a point-to-point communication (unicast) from a single external device to the KNX system. This is akin to using a USB or Serial Interface.

This is the simplest form of IP communication within KNX and is easy to understand as you only need to point an external device at the IP address of the KNX IP interface. This allows you to see all traffic from the bus and communicate directly to individual devices such as for ETS programming. It is also commonly used for external systems to communicate with KNX.

Note: in ETS this method is only referred to as KNX/net IP.

KNXnet/IP Routing

KNXnet/IP Routing is a multicast-based telegram, which allows a KNX IP device to perform the function of a Twister pair to IP coupler. This means the backbone of a KNX system can be Ethernet-based, allowing a much higher speed of transmission and more flexibility when installing. 

Multicast is a group-orientated connection method where, instead of using device IP addresses, all devices point to a standard multicast address. This allows all telegrams to be seen by all KNX IP devices looking at this address. The KNX Association has reserved multicast address 224.0.23.12 but any address could be used as long as it is the same on all devices. 

Hardware

Now that we have covered the basic communication methods, let’s take a look at which products are required. The two primary KNX IP devices are Interfaces and Routers.

A KNX IP Interface supports KNXnet/IP Tunnelling only, however a single interface, such as the Weinzierl 731, may support multiple connections. This device can have 5 simultaneous tunnelling connections which are managed by defining multiple KNX local addresses on the device. This is useful when you have multiple instances of ETS accessing the same KNX system or if you want to use the interface for both an ETS connection and an external interface to an AV system for example.

KNX IP Routers have the primary function of routing telegrams so need to be installed in ETS in the position of a line or area coupler. Within the parameters it is possible to configure the filter table to manage the flow of traffic between the higher and lower level line in the same way as a normal line coupler.

All IP routers will support a second (or multiple) KNXnet/IP Tunnelling connections meaning the device can be used for linking together different KNX lines and also for interfacing to the system. By its very nature, the routing connection has no limits to the number of connections due to the multicast connection. Some devices such as the Gira 216700, have time servers and memory cards to record the bus as well.

Because of the filter table in an IP router when you connect via the multicast connection you may only see a subset of the bus traffic. In fact this is also true for a tunnelling connection, however you will see all traffic on the connected line but may not see telegrams on the other side of a line coupler.

Both types of device generally require an additional voltage over and above the KNX bus power supply unit (PSU) and it is recommended to use a separate PSU for this not the auxiliary output on a KNX PSU another option on some IP devices is to power them via the Ethernet cable (PoE). This will require a network switch capable of PoE, but is a very simple and tidy method of installation.

If the requirement were to connect two KNX systems via the KNXnet/IP routing connection, the local network must support multicast traffic which may require approval by the network administrator. If this isn’t possible, the ABB IPR/S 3.1.1 can be used to link multiple lines together using the KNXnet/IP Tunnelling connection. This uses an ETS plugin to manage the flow of traffic. 

Security and Remote Access

Once you have implemented an IP solution it is possible to configure either of the above connection types to allow remote access for commissioning and support. Using a KNXnet/IP Tunnelling interface, it is possible to set up a direct external connection if the external WAN address is known. A port redirection will have to be implemented in the network router to navigate the firewall. However, since the KNX system does not require a password to access this, it is not a secure connection method so not recommended.

It is better to use a VPN tunnel to establish a remote connection between an external network and the local network. This has a higher level of security and encrypts the traffic down the tunnel. Alternatively you can use a device specifically designed for KNX remote access, such as the Gira S1, which uses a secure HTTP connection without needing to make any changes to the network router or firewall. It also make remote connection via Gira apps easier as a VPN doesn’t need to be enabled first.

Summary

Given the above considerations, it is no wonder we get a lot of questions on KNX over IP. Once the above terms are understood however, it becomes a lot easier to specify and install the correct products. By combining the speed and flexibility that IP brings with the reliability and simplicity of the KNX bus, you have a very powerful, flexible and future proof system.