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.
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.
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.
The KNXnet/IP driver does not directly support the KNXnet/IP Routing Service. Proxy routing:
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.
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:
The KNXnet/IP driver’s search-network-for-devices (device discovery) feature uses a multicast connection.
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.
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.
Yes, providing the Ip Address and Control Port Number are known to the KNXnet/IP driver. They can both be entered manually.
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).
Each out-going data request actually involves six packets travelling between the KNXnet/IP driver and the KNXnet/IP Interface as follows:
This appears as several flashes on the KNXnet/IP Interface’s LEDs.
No. There can only be one KnxNetwork in a station.
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:
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.
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.