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 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.