Today we will talk about the KNX protocol.
The KNX protocol is intended for building automation. Such as controlling air conditioning, lighting, blinds, and much more. Unlike the BACnet protocol, it is more focused on the area of "home automation" (BACnet is more complex and difficult to implement).
According to Wikipedia, the KNX protocol was created by evolving three earlier standards - the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB or Instabus). Personally, I think it was an intelligent design rather than an evolution :-)
Anyhow, the KNX protocol is being developed by the KNX association consisting of almost 500 companies in 190 countries.
During its development, KNX first supported twisted pair, later came the support for powerline (data transmission over the electrical network), radio transmission (868.3 MHz), and finally, the support for the IP protocol. In the year 2006, KNX was approved as ISO/IEC 14543 standard.
At present, the description of the KNX standard is freely available. If you want to read it all, then be careful - you will need a considerable amount of time, as the whole standard is distributed in more than 100 MB zip file, containing dozens of PDF files. I will list at least their structure:
· 01 Volume 1 “Primer” (does not exist yet :-) )
· 02 Volume 2 Cookbook
· 03 Volume 3 System Specifications
· 04 Volume 4 Hardware Requirements
· 05 Volume 5 Certification Manual
· 06 Volume 6 Profiles
· 07 Volume 7 Application Descriptions
· 08 Volume 8 System Test Specifications
· 09 Volume 9 Basic and System Components
· 10 Volume 10 Application Specific Standards
When using twisted pair (TP1), a baud rate of 9600 bits per second is used. Media access is via CSMA/CA (i.e. collision avoidance - avoiding collisions when multiple devices are trying to send data). One line can contain up to 256 devices and can consist of up to 4 segments of 64 devices. Each segment has a maximum length of 1000 meters and requires local power for connected devices (so that the dual-line can be used not only for communication but also for power).
Up to 15 lines can be connected to the main line by means of line couplers and thus connected to one area. Fifteen areas can be connected to the domain by means of backbone couplers.
The KNX network can, therefore, contain up to 57 375 devices. Their addressing is 16-bit, the first 4 bits are reserved for the area, the second 4 for the line, and the remaining 8 bits is the device address on the line. An example of an address is 1.2.21 (area 1, line 2, address on line 21).
The KNX association is developing the ETS tool that is used to configure KNX devices from various manufacturers. This is one of the great advantages - one tool for everyone, enabling parameterization and configuration of any KNX device.
Another valuable feature of the KNX protocol is that there is an official driver called Falcon. The fact that Falcon is written in C# and therefore a.Net framework (or at least .NET Core 3.1) is needed to run it is less charming. How to connect the interpreted .NET environment with the D2000 system, which is developed in the Ada language? The Falcon documentation suggested wrapping it in a COM object - but that wasn't applicable to the Linux platform. Finally, we created a simple d2knx module, which is written in C# and contains a link to the Falcon driver. This module communicates with the D2000 KOM process using JSON messages transmitted over a TCP connection. The D2000 KOM process can run the d2knx module or can connect to it (if d2knx runs remotely, or in redundant systems multiple d2knx modules can be run on redundant application servers).
We mentioned Linux - since there is a .NET Core for Linux (and even for Raspberry Pi), it is possible to use the KNX in the D2000 on these platforms as well.
The advantage of using the Falcon driver is that it can work with various KNX adapters. We tested communication via "KNX USB Interface" and "KNX IP Router" on both Windows and Raspberry Pi. KNX communication can even be secured (so-called secure group communication). In this case, it is possible to export the security key file from the ETS configuration tool and enter the path to it and the password for access in the line configuration.
From the angle of the D2000 KOM process, we work with the so-called group values. The group value has a 16-bit address. It can be entered in 3 formats:
· three-level address: main/middle/sub, where main = 0..31, middle = 0..7, sub = 0..255
Example: 1/2/24
· two-level address: main/sub, where main = 0..31, sub = 0..2047
Example: address 1/536 corresponds to 1/2/24 (because 2 * 256 + 24 = 536)
· directly as a number 1..65535 (group address 0 is not allowed)
Example: address 2584 corresponds to 1/2/24 (because 1 * 2048 + 2 * 256 +24 = 2584)
The ETS tool is used to configure which KNX devices send which values as group variables and which KNX devices receive the values. Subsequently, the D2000 KOM process sees all the values on the line to which it is connected as spontaneous changes. In addition to the value itself, it also has information about the address of the device that sent the value, the priority of the message, and the auxiliary flags:
· read – the reading of a value
· write – the writing of a value
· response – the response of a value
· secure – it is a secured communication
The D2000 KOM can also explicitly request values. When? The "Read Group Addresses" protocol parameter is used for this. The default value Once means read after the communication starts, value Never disables reading and the value Always causes the values to be read in each cycle (according to the time parameters of the station). Be careful - it is necessary to think about the speed of 9600 baud on the twisted pair line so that we do not overload the KNX medium with frequent requests!
The read priority is specified by another parameterRead Group Priority, and the timeout for waiting for a response is defined by the Read Group Timeout parameter.
When a value arrives into the KOM process, a station with the same address as the source address is searched. To avoid the user having to define several stations (if several devices generate the same value - for example, imagine several staircase switches), it is possible to define a station with a symbolic address GROUP. All group values will go to the measured points (I/O tags) at such a station.
So how does the I/O tag configuration look like?
At all times, it is necessary to enter the Group address and which attribute of the value is to be mapped to the I/O tag (value, flags, source address, priority, or data size in bits).
If we work with a value, it is necessary to enter the interpretation of data when reading - Value type (reading). This information is not transmitted by the communication protocol – thus it is up to the user to specify whether the received data will be interpreted as an unsigned integer, signed, real number (KNX protocol supports 2, 4, or 8-byte real numbers) or text (KNX protocol supports 14-character texts).
If the I/O tag is configured as an output tag in the D2000, it is possible to set the conversion required for writing using the Value subtype (writing) parameter. The already mentioned real number can be sent as 2, 4, or 8-bit. A signed value can be written as a 1, 2, 4, or 8-byte signed number. In addition, an unsigned value can be sent as Bool, TwoBit, FourBit, or SixBit. Text .. surprisingly, it can only be sent as 14-character text :-).
Conclusion
The KNX protocol is quite widespread in the field of home automation, therefore we assume that its support in the D2000 will not only please existing D2000 users but also inspire home enthusiasts to download the D2000 version 12.2.65 for Raspberry Pi and use it to manage their households.
Ing. Peter Humaj, www.ipesoft.com
