Interoperability inside KNX
KNX has an unbeatable reputation for its strong interoperability between products of different manufacturers in home and building automation projects. This unbeatable reputation bases upon the belief that both the protocol for exchanging information as well as the information itself needs to be stringently standardized, but also needs to be stringently checked during KNX certification.
This interoperability is also achieved thanks to the installer linking identical standardized functions of different products together with the help of the common KNX design & configuration tool, ETS.
Note: Or in smaller installations thanks to the intelligence of the KNX product only linking to identical functions of its communication partner expressed by KNX easy mode connection codes.
So, inside the KNX Ecosystem, everything works perfectly together.
KNXnet/IP
If something wants to interface to the KNX Ecosystem, then already for quite some time, KNX offers the KNXnet/IP protocol to do this. Numerous perfectly working solutions are in the market based on this technology. However, this approach has some shortcomings as regards IT friendliness and comprehensiveness:
- KNXnet/IP tunnels the same information as on the KNX bus in an IP frame: the receiver needs to understand the KNX protocol to be able to make out the source and the destination of the sent data;
- The KNX system is by nature a data driven system, meaning that the actual interpretation of data (“a light is switched”) is only known between the sender and receiver. Or to put it differently, the meaning of the exchanged data is not included in the transmitted messages. A more sophisticated word for “meaning” is “semantics”.
ETS XML files
For making some sense out of the KNXnet/IP message, one needs to implement the KNX protocol on the receiver side and base oneself on the exported ETS project (who was the sender, to whom did it sent, in which location are the devices, did one switch a light or something else, …?).
The main disadvantage of this exported ETS project is however that:
- little semantic data is included;
- the format of this export file changes with every new update of the ETS;
- It includes data that is not directly of interest (e.g. topology of the KNX network).
The needed solution: KNX 3rd Party API
Because of the above, KNX needed a solution that adds interoperability on top of interoperability, meaning:
- An interface needed to be created to an already interoperable system that also adds semantic data on this interface;
- A new export format needs to be defined for ETS projects
- This interface needs to exchange this KNX semantic data with state-of-the-art IT web technologies, not with an own KNX protocol;
- State of the art Encryption and authentication on this interface is a must;
- This interface is static, needs to be manufacturer independent, shall be described in accordance with the Open API requirements and is electronically available;
The KNX IoT 3rd Party API thus adds another standardized interface layer to the already strong interoperability of the KNX Ecosystem, letting any 3 Party talk to KNX installations in a unified way, not different for any specific KNX manufacturer.
How KNX realized a new export format for ETS and how semantics will come into play with KNX IoT is explained in the web page on Semantics.