Engineering Tool Software (or ETS tool) is created by the KNX organization. Main purpose of the ETS tool is to configure devices in a KNX network.

In order to configure devices in a KNX network, ETS tool needs to establish connection with the KNX network. In most cases IP interface device is used for this.

IP interface device represents communication KNX device. That means that clients can connect to the IP interface device. After establishing connection, clients can start to communicate with the KNX network.

IP interface device supports two protocols:

• KNXnet/IP Tunnelling
• KNXnet/IP Routing

KNXnet/IP Tunnelling is connection based protocol. Client first need to establish connection with the IP interface device. After that client can send and receive messages from the KNX network.

KXNnet/IP Routing is a connectionless protocol. This means that there is no need for connection before client can start sending and receiving messages from the KNX network.

IP Interface discovery

IP interface device is connected to the Local Area Network (LAN). All clients, that are connected to the same LAN, can communicate with the IP interface device.

Discovery mechanism is used by the clients to figure out available IP interface devices in a LAN. IP interface device is listening on a specific endpoint (224.0.23.12:3671) for search requests. When a client sends a search request, IP interface device sends a search response back.

In the search response, IP interface device sends useful data about itself. Data like:

• Control endpoint,
• Device friendly name,
• Device MAC address,
• Device serial number,
• Device Routing multicast address,
• Device physical address,
• KNX medium,
• Project installation identifier,
• Device status.

In a search response, client can find all the necessary information to communicate with the KNX network over IP interface device. For the tunnelling interface, control endpoint holds IP address and port number which are needed for the client to open the tunnelling connection. For the routing interface, there is Routing multicast address where client needs to send and receive messages.

This is a great mechanism. Nothing needs to be hardcoded. Clients don’t need to know about available IP interfaces in advance. When needed, client can use discovery mechanism to find available IP interfaces.

ETS and IP interface device

From the communication point of view, ETS is the same as any other IP interface device client. It can use both tunnelling interface and routing interface to communicate with the KNX network.

For the tunnelling connection ETS has two options.

ETS can use the discovery mechanism to find available IP interface devices in a LAN. All the discovered devices are shown in the list of discovered IP interfaces. You can simply select the desired device, press the select button and the connection is established.

ETS can also create a manual connection. In this case you need to provide all the connection parameters: IP address, port number, is NAT used.

For the routing connection, ETS can only use the discovery mechanism. All routing interfaces will be shown in the list of discovered IP interfaces. Once again, you only need to select the desired device and press the select button.

ETS and discovery mechanism

There is one more interesting thing about ETS and its discovery mechanism. And this is something I have learned the hard way.

At some point in my KNX carrier, I have implemented an IP interface device. It was a PC based software solution. But nevertheless, it was a full IP interface device. I needed to implement complete KNXnet/IP protocol.

At that point, I had a lot of experience in implementing all kinds of IP interface clients. I thought I knew everything about IP interface devices. In order to start with something easy, I decided to implement the discovery mechanism.

Sounds easy. What could possibly go wrong?

In my IP interface device I have implemented search request handler. Whenever a search request was received, search response was sent back to the client. In the search response I have populated important connection information like: Control endpoint and Routing multicast address.

So far so good. It was time to test the discovery mechanism.

I have started my IP interface device and used one of the IP interface client I have developed. The IP interface device was present in the list of discovered interfaces. Exactly what I have expected.

After that, I tried to do the same thing with the ETS tool. To my surprise, my new and shiny IP interface device was not present in the list of discovered interfaces. It’s needless to say that I was not happy. I expected this to be a routine check, and it turned out to be a debugging nightmare.

After some investigation, I figured that the problem lies with the serial number used by the IP interface device. Since I figured that IP interface device serial number is not important, I have used all zero values as a serial number.

But the ETS tool performs additional checks against serial number. Serial number consists out of 6 bytes. First 2 bytes represent manufacturer code. Next 4 bytes represent unique identifier of the product created by that manufacturer.

ETS has information about all KNX manufacturers. When ETS receives search response, it will check the serial number (manufacturer code part of the serial number) against all known KNX manufacturers. If the manufacturer is not knows, ETS will not trust the discovered IP interface device and the device will not be shown in the discovered interfaces list.

After our company has registered as a KNX manufacturer, and I have used our manufacturer code in a serial number, the problem was solved and our IP interface device was listed in a discovered interfaces section.

As always, the solution is easy.

The trick is to figure out what the problem is.