KNX IoT is taking shape

As regards interoperability between products of different manufacturers, KNX has always been best in class since the day it was conceived, also thanks to the rigorous third party KNX certification scheme of products. In spite of this, mainly because of the plethora of other home and building automation solutions (be it proprietary or other protocols) and because of the widespread use of the internet, the market today requires that any system provides a well-documented way to interact with it, via mechanisms that are state-of-the art in the IT industry.

If you are wanting to tap into data from KNX installations via superordinate systems or integration platforms (linking KNX to other 3rd party non-KNX devices), you would simply expect that you would not need to learn the KNX protocol but be able to retrieve the following data – via a standardised and non-manufacturer-specific RESTful API: 

• what locations (rooms) does the installation consists of?
• what functionalities (e. g. lighting, heating / cooling, sun shading, …) influence a certain location?
• what data is linked to that functionality or to that device realising the functionality and how can I read it and (if needed) change it?
• what link does this functionality have to the real / physical world?
• were is the device physically installed?

What is important for manufacturers implementing such integration platforms is that the information supplied by these KNX IoT gateways is machine readable and has rich semantics, at best the direct result of the product data used and / or work done by the installer designing and configuring the KNX installation. Hence, the rich (semantic) data should simply be supplied to the KNX IoT gateway by a specific ETS export that is more stable than the current XML format and is easier to upgrade. This enriched data should also offer the possibility to simplify the design phase of a KNX installation (easier selection of supported product functionality), possibly also constitute the basis for easier binding between different products and should document an installation over its lifetime as part of the Building Information Modelling (BIM) data.

The 3rd party API was also designed in such a way that it may support a websocket interface that enables for example direct cloud integration with bidirectional communication. Cloud applications can in this way subscribe to information on demand, minimising data transfer to cloud and costs. The websocket interface can also be used for messaging, for example, for a GUI to get notifications on modified data to be able to show changes in the system immediately. Needless to say, the KNX IoT 3rd party KNX interface provides state-of-the-art IT security. 

With the final voting of the specifications, KNX is now completing the above 3rd party interface and corresponding KNX information model, which is also accessible to non-KNX members via https://schema.knx.org.

As a next step and on the basis of the KNX draft specifications that are already available, KNX wants to also finalise the KNX IoT Point API specifications, a solution allowing IPv6 field level sensor / actuator (group) communication. This will allow KNX installations to be extended with devices that use other media like Thread or WiFi to exchange KNX data. As a first step, group communication would be realised via pre-configured recipients (brokers). For this, KNX plans to complete the final voting of the specifications in a year from now and plans an ETS prototype allowing configuration of security and group tables in the first KNX IoT device prototypes of manufacturers.

Discover the new possibilities found in the KNX development landscape thanks to the KNX IoT specifications.