At the KNXperience 2021, which comprised a 3-day conference program, KNX training Centre Booths, prizes to win, and much more, a plethora of extended development possibilities were declared, for the betterment of existing and potential KNX members.
The primary agenda of the conference was:
· To make IoT(The Internet of Things) one common communication platform.
· To standardize languages on top of IP.
· To make IoT solve everything KNX solves today.
· To explain the main difference between KNX and IoT.
· To understand and eliminate the competitive shortcomings KNX has today.
· To identify the limitations of the current KNX System.
· To adding interoperability on top of interoperability, in the case of 3rd Party IoT interface
· To get a clear understanding of Semantics and what machines require to understand the concepts of KNX installation.
· To understand the current status and plan the further roadmap for the overall KNX IoT Project.
· To elaborate on the possibilities of KNX development.
The current difficulties or issues with the IoT are that most devices are handled by different apps and serve only one purpose on the device level. For example, smoke detectors can only detect smoke and inform about it but are unable to unlock doors in emergencies. Whereas, a door lock can only unlock the door but cannot turn up the heat when one enters a room. When workarounds are used for integration, an integrator faces numerous challenges. Reliability level increases immensely on cloud and internet. If there is no internet, communication gets disrupted. With such high dependency on gateways, unpredictability and instability step in. High dependency on original suppliers and possible partnerships between suppliers is often witnessed.
The main difference between KNX and current IoT is that KNX aims to provide a coherent fixed network, consisting of products of different manufacturers and applications, to the home and building owners. KNX is a provider of smart coherent infrastructure and is sold through wholesalers and contractors/integrators (B2B). Building owners are the proprietor of their own data and products/products, due to the System specific API.
Whereas, numerous IoT material is added to an existing installation and makes one single application smart. In this case, the smart linking of all applications is mostly cloud-based. IoT products are sold directly to the end customer (B2C). However, a building owner is not the possessor of their own data due to the product-specific API.
The current shortcomings of KNX are:
- KNX Radio Frequency
Though KNX uses a frequency range of 868 MHz and has advantages compared to other technologies like range and congestion, the frequency is limited to certain regions. Therefore, redesigning of product is needed for other regions, keeping in mind a universally usable frequency(2.4 GHz)
- KNX Twisted Pair
It is an extremely easy-to-install, reliable, and robust network. However, it is not an ideal medium for some product types like home appliances, storage devices, inverters etc.
Integration possibility of the third device in KNX-
Classic Case:
- ETS DCA App fetches from the manufacturer’s cloud, the devices installed by the manufacturer’s app from the customer’s account. But, the manufacturer must be a KNX member to develop ETS App.
- The necessary group objects for communication are instantiated for the different functions in the ETS DCA.
- The installer links the KNX devices to the instantiated group objects of the gateway.
- The DCA App communicates with the manufacturer’s cloud with the mapping table (assigned group addresses to manufacturers’ devices).
- The ETS App is loaded into the manufacturer’s gateway.
- If an event happens in KNX, the interface translates this into private communication (could also be according to the 3rd Party API), sends to the cloud and from there to the non-KNX device. When an event happens on a 3rd Party device, this is communicated to the cloud and translated into the appropriate KNX group message.
Use of 3rd Party API – manufacturer cloud only:
- Export ETS project including all Group Addresses towards 3rd Party API Interface.
- KNX 3rd Party API call to retrieve IDs of all KNX data points in the project.
- ETS integrator finds the appropriate data points or the info added by integrator before export. Hence, the manufacturer cloud can easily find the data points relevant for them (push-button action helps to start a program or link white goods status info to KNX display).
- They can subscribe to get updates on data point XYZ (of a push button) (every message on GA 1/2/3 triggers subscription update).
Use of 3rd Party API – KNX cloud + clouds of different manufacturers:
- KNX 3rd Party API call to retrieve all (IDs of) KNX data points after it gets approved by the customer. Then, the call is routed towards the appropriate gateway. In this case, the manufacturer must not be a KNX member.
Use of 3rd Party API – direct communication to the gateway (unlikely) :
- The 3rd party GW needs to support the oAuth2 local scenario.
- The manufacturer’s device, acting as a client, must find the 3rd party API interface to be able to communicate with it.
- When found, KNX 3rd Party API call to retrieve all (IDs of) KNX data points.
- A need for local possibility, to select the appropriate data points relevant for 3rd Party devices, arises.
- It is a quite unlikely case without a connection with a cloud infrastructure.
Use of Point API – communication over Classic gateway – Ethernet:
· Installation includes Point API to classic GW.
· All devices are configured by ETS in the usual way.
· Device supports Ethernet as a communication medium and communicates to Point API/Classic GW.
· When having an ethernet connection, the device can support KNXnet/IP and achieve the same result. KNXnet/IP is supported in the current ETS, including Security.
Use of Point API – communication over Classic gateway – Thread :
· Installation includes Point API to classic GW and all devices are configured by ETS in the usual way.
· Device supports Thread as a communication medium and communicates to Point API/Classic GW.
· These realizations are ideal for Point API, eyeing the advantage of communication via wireless IP networks like Thread.
