Driver FAQs

What is a KNXnet/IP Interface device?

A KNXnet/IP Interface device is a hardware device that supports KNXnet/IP tunnelling only. A single interface, such as the Weinzierl 730 and the Siemens N 148/22 may support multiple KNXnet/IP tunnelling connections. These devices can have simultaneous tunnelling connections, which are managed by defining multiple KNX individual device addresses on the device. In the KNXnet/IP driver, this is called the Individual Device Address and allows the KNX network to be accessed by both ETS and the KNXnet/IP driver.

What is a KNXnet/IP router device?

This is a hardware device that supports both KNXnet/IP tunnelling and KNXnet/IP routing connections, as well as having the filter table to allow the device to perform as a coupler. Some KNXnet/IP Routers, such as the Siemens N 146/02 allow multiple tunnelling connections.

What is KNXnet/IP routing?

KNXnet/IP Routing is a multicast-based telegram, which allows a KNXnet/IP router to perform the function of a line or area coupler. This means the backbone of a KNXsystem can be Ethernet-based, allowing a much higher speed of transmission and more flexibility when installing. The KNXnet/IP router also provides a filter table to manage the flow of traffic where needed.

The KNXnet/IP driver does not support KNXnet/IP Routing.

What is proxy routing?

The KNXnet/IP driver does not directly support the KNXnet/IP Routing Service. Proxy routing:

  • Enables the KNXnet/IP driver to communicate with KNXnet/IP router devices whose IP subnet differs from the Host IP subnet.
  • Allows the KNXnet/IP driver to communicate with multiple KNXnet/IP router devices without using up a KNXnet/IP tunnelling connection in each KNXnet/IP router.

Proxy routing relies on configuring a KNXnet/IP device in the station using a KNXnet/IP tunnelling connection to one KNXnet/IP router device that has the same IP subnet address as the host. The KNXnet/IP router device’s filtering needs to be configured to allow it to route messages from the KNXnet/IP tunnelling connection to other KNXnet/IP router devices and vice-versa.

The other KNXnet/IP routerdevices can then be configured as KNXnet/IP devices in the station with their Connection Method property set to Proxy Routing and their proxy device address and other connection properties set to the KNXnet/IP device that was configured to use the KNXnet/IP tunnelling connection described above.

What KNXnet/IP device address information does the KNX driver need and how does it obtain it?

Interfaces and routers are the two primary KNXnet/IP device types. The KNXnet/IP driver needs three addresses to communicate with either of these device types:

  • Ip Address: Obtained from the KNXnet/IP device either over the KNX network using the driver’s search-network-for-devices feature or by manual data entry.
  • Control Port Number: Obtained from the KNXnet/IP device either over the KNX network using the driver’s search-network-for-devices feature, by manual data entry, or by default.
     
    NOTE: The default Control Port Number is 3671.
     
  • Individual Device Address: Obtained from the KNXnet/IP device either over the KNX network using the driver’s search-network-for-devices feature, by manual data entry, or by using importing devices from the driver’sknxproj file.
     
    NOTE: Manual data entry is not available in v29 of the KNXnet/IP driver.
     

The KNXnet/IP driver’s search-network-for-devices (device discovery) feature uses a multicast connection.

 
NOTE: If both the Ip Address and Control Port Number are known by the KNXnet/IP driver, it does not initiate a search request via a multicast connection.
 

Does the KNXnet/IP driver support multicast telegrams?

The term “multicast” can apply to both IP Multicast and the KNX point-to-multi-point, connection-less (multicast) transport layer communication mode.

To facilitate device discovery on the network, the KNXnet/IP driver does support IP Multicast.

 
NOTE: The default IP Multicast Address is 224.0.23.12.
 

The KNXnet/IP driver inherently supports the KNX point-to-multi-point, connection-less (multicast) transport layer communication mode in so far as it makes use of the A_GroupValue_Read-PDU, A_GroupValue_Response-PDU and A_GroupValue_Write-PDU Application Layer services, which are only supported using this communication mode.

Does the KNX driver support KNXnet/IP devices that do not support multicast?

Yes, providing the Ip Address and Control Port Number are known to the KNXnet/IP driver. They can both be entered manually.

 
NOTE: Multicast–connection support is part of the Core: KNXnet/IP service, which is mandatory for all certified KNXnet/IP devices.
 

What controls the rate of KNX data requests from the driver?

The Inter Message Delay setting in the tunnel connection paces the out-going data requests from the driver. This can be used to reduce the rate of data requests in cases where a KNXnet/IP Interface device cannot cope with the traffic volume, caused possibly by its implementation settings or by its operating speed. The Inter Message Delay default setting of minimum 15ms has proved successful with Siemens interface devices. Any problems arising from this being set too small would manifest as control points intermittently having a Read Fault: Timed out waiting for L_Data_con (condition).

Figure 4.   Inter Message Delay
Image

Each out-going data request actually involves six packets travelling between the KNXnet/IP driver and the KNXnet/IP Interface as follows:

  1. Request from KNXnet/IP driver to KNXnet/IP Interface
  2. Acknowledgement from KNXnet/IP Interface to KNXnet/IP driver
  3. Confirmation from KNXnet/IP Interface to KNXnet/IP driver
  4. Acknowledgement from KNXnet/IP driver to KNXnet/IP Interface
  5. Reply from KNXnet/IP Interface to KNXnet/IP driver
  6. Acknowledgement from KNXnet/IP driver to KNXnet/IP Interface

This appears as several flashes on the KNXnet/IP Interface’s LEDs.

 
NOTE: There is an important difference in the implementation of Inter Message Delay between the KNXnet/IP driver and the EIBnet/IP driver. In the EIBnet/IP driver the Inter Message Delay was applied between all out-going messages, including acknowledgements and all connection control messages. The KNXnet/IP driver only applies the Inter Message Delay between data request messages.
 

Can I have more than one KNX network in my station?

No. There can only be one KnxNetwork in a station.

Figure 5.   Driver Manager view
Image

How does the driver prevent communications traffic from swamping the KNX twisted pair line?

The KNXnet/IP driver prevents the KNX twisted pair line from being swamped with traffic by controlling the number of concurrently active group address read operations and is set by the Max Pending Reads property in the Group Data Manager. The term “active” in this context means that:

  1. A particular group address read operation reached the head of the group data operation queue.
  2. The communications stack sent an L_Data_req message to the KNXnet/IP device and received an L_Data_con reply, but has not yet received a corresponding L_Data_ind message.

The default value of Max Pending Reads is 4 but, unfortunately, there is no clear guidance in the KNX Specs as to what an acceptable Max Pending Reads value should be. However, having this value too small does not cause a read–queue–is–full fault.

Figure 6.   Max Pending Reads
Image

Is the IP port adjustable?

This question is sometimes asked by IT departments who need control over the IP port usage on their network.

Protocol: The KNX System specifications specify that UDP (User Datagram Protocol) is used for KNXnet/IP connections rather than TCP (Transmission Control Protocol) and, therefore, the following commentary on ports and messaging is in relation to UDP.

Device and Driver Ports: There are four logical UDP ports allocated for each tunnel connection between the KNXnet/IP driver and a KNXnet/IP Interface device. Two ports (one for control and one for data) are at the device and two ports are at the driver (control and data). Activities, such as opening, closing, the connection and for heart beat use the control port. Point data use the data port.

Port numbers: It is usual that KNXnet/IP Interface devices use port 3671 for both control and data, but this may not always be the case. The KNXnet/IP driver dynamically allocates the two ports it uses to communicate with the device when establishing and maintaining a connection. In this way, the driver can separate the messaging between multiple devices concurrently by allocating different port numbers. In the driver, the control and data ports for each device are always different.

Port number selection: The ETS tool sets the port numbers used by the KNXnet/IP Interface device (provided that the device can be configured). The port numbers that the KNXnet/IP driver chooses dynamically for each Local Interface range between a port-minimum (0-65535) and port-maximum (0-65535). The default values of these are 3500 and 4000 although they can be changed when setting up of the driver. Clearly, reducing the range restricts the number of potential device connections and, ultimately, if the range offers only one port number, the driver will not function because two ports is a minimum for each device connection.

Recycling port numbers: When dynamically choosing a new port number, the KNXnet/IP driver starts at the port minimum number (default setting) and chooses the next available port number or it cycles through the range. You can select this behaviour when setting up the driver.