KNXnet/IP interface device

In my previous blog post I have written about USB interface devices. What they are, what are they used for and how to use the USB interface device to establish connection with the KNX network. In this blog post I will cover basics of the KNXnet/IP interface device (or IP interface device).

Like explained in my previous post, there are three types of KNX devices:

  • Sensors
  • Actuators
  • Communication devices

Communication devices can be further broken down into:

  • IP interface device
  • USB interface device
  • Repeaters (Backbone coupler, Line coupler, Line repeater)

IP interface device has a main purpose to enable communication with the KNX network. Similar like the USB interface device, IP interface device needs two physical interfaces to achieve this. On one side it needs TP interface to communicate with the KNX network. On the other side KNXnet/IP interface device has IP interface which can be used by any IP enabled client.

KNXnet/IP interface devices use the IP interface to send and receive IP packets. There are couple of options regarding the IP packets that can be used:

  • TCP packets
  • UDP packets
  • Raw IP packets

The choice on which type of packets to use basically comes down to choice between TCP and UDP packets. Both options have some advantages and disadvantages.

On one side TCP packets are more reliable. They guarantee that all of the packets will be delivered and that the ordering of the packets will be preserved. But the TCP protocol reliability comes with a price. That price is that TCP protocol contains a certain amount of overhead which makes it less efficient. One other shortcoming of the TCP is that it does not support multicast addressing which is used by KNXnet/IP Routing interface.

On the other side UDP packets are less reliable. The good thing is that KNXnet/IP Tunnelling protocol implements end to end connection based communication with fully acknowledge support. This means that in reality there is no need for the reliability of the TCP protocol. As stated before UDP is more efficient than TCP and it supports multicast addressing.

Because of this, UDP is selected as default protocol for communication between KNXnet/IP interface devices.

There are two different interfaces that every KNXnet/IP interface device can implement:

  • KNXnet/IP Tunnelling interface
  • KNXnet/IP Routing interface

Let us examine these two interfaces in more details.

KNXnet/IP Tunnelling interface

KNXnet/IP tunnelling interface is supported by all KNX IP interface devices. It is connection based communication which means that the tunnelling connection needs to be established before any of the KNX telegram information can be exchanged.

There are couple of different types of messages which are used in KNXnet/IP tunnelling communication. Let’s go through them one by one.

Search request / response

Search request is used to find available IP interface devices in the local area network (LAN). It is based on the multicast addressed message. KNXnet/IP client sends a Search request messaged on the defined multicast addressed. For this purpose reserved address is used with port 3671.

Every KNXnet/IP server is listening on this reserved multicast address. When KNXnet/IP server receives search request it creates search response and sends it back to the client who sent the request. In the search response KNxnet/IP server is providing some basic information about itself. Information like:

  • User friendly name
  • Control end point (where it waits for client connections)
  • Physical address
  • MAC address
  • Routing multicast address
  • Serial number
  • Supported service families

Description request / response

This is an addition to the search request / response mechanism. After receiving the search response from the KNXnet/IP server, client can send a Description request. Description request is sent to Control endpoint of the server which is received in the search response.

In the description response server provides all the information that can be find in the search response plus some additional manufacturer specific information. This additional manufacturer specific information provides specific details about the hardware component of the IP interface device.

Connect request / response

To establish a tunnelling connection with the KNXnet/IP server client needs to send the Connect request. Connect request is sent to the Control endpoint of the server. In the Connect request  client sends its own Control endpoint and Data endpoint to the server. This information is used by server to send information to the connected client.

KNXnet/IP server responds to the Connect request with a Connect response. In connect response server provides flag which indicates if everything is ok or if there is some error and the connection cannot be established. For the successfully opened connection server provides communication channel ID. Communication channel ID is unique identifier of the tunnelling connection on the server.

Also KNXnet/IP server will return individual address in the Connect response. This individual address represents sort of a virtual address of the client on the KNX network. As if the client is present on the KNX network. All telegrams sent by the KNXnet/IP client to the KNX network should use this individual address as source address.

Connection State request / response

Connection state request / response can be considered as a heartbeat mechanism. It enables KNXnet/IP client to ping the server in regular intervals (every 60 seconds). KNXnet/IP server responds to sent Connection State request letting the client know that it is still there and that everything is ok.

In case that the KNXnet\IP server does not respond to the sent Connection State request client will try to resend the request and eventually client will drop the connection. Similar thing will happen if the client fails to send the Connection State request. After a while (120 seconds) server will conclude that the client is not available anymore and it will terminate the tunnelling connection.

Disconnect request / response

Disconnect request is sent by the KNXnet/IP client when client wants to terminate the tunnelling connection. Channel ID is provided in the Disconnect request which indicates which tunnelling connection needs to be terminated. KNXnet/IP server will respond with the Disconnect response.

Disconnect procedure can be executed also in the opposite direction. This means that the server can send a Disconnect request and that the client will respond with a Disconnect response.

Tunnelling request / ack

Tunnelling requests are used to exchange telegram information between KNXnet/IP server and client over an active tunnelling connection. cEMI protocol is used in the Tunnelling request message to send the telegram information.

When server receives a telegram from the KNX network it will send a Tunnelling request to all active tunnelling connection with the content of that telegram. Client will respond with a Tunnelling acknowledge.

The same goes when the client wants to send a telegram to the KNX network. Client will send Tunnelling request to the KNXnet/IP server. Server will respond with a Tunnelling acknowledge and it will forward telegram information to the KNX network.

KNXnet/IP Routing interface

Compared to the tunnelling interface, KNXnet/IP routing interface is not supported by all KNXnet/IP interface devices. Only KNXnet/IP Routing devices support this functionality. Information if the routing interface is supported by the device can be find in Search response. If the device supports the routing interface it will provide information about that in the supported service families section.

Another difference to the tunnelling interface is that the routing interface is not connection based. Routing interface works on the multicast addressing mechanism. This means that all the messages are sent by the server to the multicast address and there can be zero, one or more clients listening for the message.

Search request / response

Once again everything starts with the search request. If the client wants to communicate with the KNXnet/IP server over the routing interface it first sends a Search request. KNXnet/IP server responds with the Search response and client can extract multicast address used for the routing interface by the server.

The Search request / response is already described in the tunnelling section and more information can be found there.

Routing indication

When client wants to send a message to the KNX network it will send a Routing indication message to the multicast address used by server routing interface. KNXnet/IP server will receive this message and it will forward the telegram to the KNX network.

The same way when KNXnet/IP server receives a message from the KNX network it will send that message to the multicast address. All the listening clients can receive that message and act upon it.

Same as for the tunnelling interface cEMI messages are used to send telegram information in the Routing indication.

How to use KNXnet/IP interface device

In this blog post I have covered two different interfaces supported by the KNXnet/IP interface device. Those interfaces are: Tunnelling interface and Routing interface.

In my next blog post I will explain how a KNXnet/IP interface device can be used to communicate with a KNX network. Same as for the USB interface device I will cover some commonly used tools in the KNX world:

  • ETS tool
  • PNX Monitor
  • Falcon driver
  • Low level communication approach

Stay tuned.

Leave a Reply

Your email address will not be published. Required fields are marked *