Security is a critical factor in any installation and, in our opinion, it should be considered the primary design factor in a KNX installation. Furthermore, the decentralized nature of a KNX bus system requires, on multiple occasions, to make a cyclical monitoring of signals that may affect their safety. For example: wind alarms are monitored to control awnings and blinds because, in the absence of these signals, serious consequences may occur on site. On other hand, temperature signal from an external sensor may be cyclically monitored by a room thermostat to avoid unnecessary energy consumption if the sensor fails.
However, the cyclical monitoring of certain signals do not solve all possible problems in a KNX installation. KNX devices themselves may be affected by multiple types of incidents: theft, damage (rare, but possible), bus cable cutting, power failures, etc.
Therefore, monitoring of the devices themselves is needed in KNX installations, where an optimum level of security is desired. This monitoring, which is done through the individual address, also enable us to make an own traceability of the bus, and can be helpful to precisely locate not only any particular effect, but also more significant failures, such as power failure in a whole line or a possible bus cutting that affects multiple devices.
How to works
Our NETx Server uses KNX management communication to monitor the existence of KNX devices. Using the physical address of the KNX device to be monitored, the server sends a T_Connect message to the KNX device. If the device is present, it will send with a T_Disconnect message after 10 seconds timeout. If this T_Disconnect is missing, the NETx Server will resend the T_Connect message. If the T_Disconnect is still missing after 3 retries, the KNX server assumes that the device is offline and will set the corresponding server item to false.
Note that this device monitoring approach is using KNX unicast communication (KNX management communication) – it does not not use KNX group communication. Please also keep in mind that this monitoring only verifies whether a successful KNX management connection can be established to the KNX device. It does not do any further checks to verify the proper functionality of the KNX device.
KNXnet/IP routers and interfaces must not be monitored by the NETx Server! During the monitoring process, our server opens a KNX management connection. Some KNXnet/IP routers and interfaces will reboot and close all tunneling connections after closing a KNX management connection. Therefore, unwanted disconnects of the KNXnet/IP connection will occur.
Please use the GATEWAY item to monitor the state of a KNXnet/IP router or interface instead.
We will use the NETx Server for monitoring devices in a KNX installation. After installing the server, the steps for configuring the physical addresses monitoring are very simple. First, we need to extract data from ETS project using the NETx BMS Secure App.
The only compatible App for ETS5 is NETx BMS App Secure, it is free and can be downloaded from Here.
Once the Project has been imported in the studio , we can appreciate the "KNX Device Definitions" table with the "mapping" of the individual addresses (allocated to each line – IP address). In the next picture, you can see this table, where we assigned a 10 second polling from 5.1.X till 5.2.X
After a (courtesy) timeout, finally the item tree in the studio shows the device in FALSE state. Right now, for example, we could set an automatic email from the server warning about this device failure.
Although the information displayed by the item tree is very valuable to assess the health of each individual device, it is not enough to give a complete tractability of the installation. To supplement this information it is recommended to visually capture the physical layout of the devices as well as the laying of the bus
Article applies to the following products:
- NETx BMS Platform
- NETx Multi Protocol Server
- NETx BMS Server 2.0