Jesus Arias discusses how KNX IoT makes it even easier to create products, solutions and services, and explains the main features of the KNX IoT 3rd Party API server and the KNX IoT Point API device.
Developing a KNX solution was a very straightforward exercise 30 years ago: a KNX device was, in a simplified way, a combination of a piece of hardware and a piece of software. The hardware would be implemented in a KNX physical layer (using twisted pair (TP) cable), and the software would consist of a KNX stack and an application program. Fast-forward just over 30 years, and we find a vast development landscape, with different physical layers, advanced commissioning tooling which accepts apps, a standardised API, tooling to access the KNX bus, SDKs, different types of wireless solutions, the most advanced security mechanisms. The question is no longer ‘What is possible with KNX?’, it is ‘What is not possible with KNX?’
Living in an IP world
KNX was initiated by companies involved with electrical manufacturing, and as it grew in popularity as a standard protocol for controlling homes and buildings, it embraced the digitalisation of our world. IP became an important backbone of the technology, literally and figuratively, and many companies in the software industry have been joining the KNX Association to create software solutions that are combined with KNX installations.
Over the last three decades, the KNX standard and its related technologies have been growing quantitatively and qualitatively: from field devices using a dedicated bus to a whole development ecosystem which offers the largest variety to create products, solutions and services for the home and building automation industry.
KNX IoT enhances the way KNX is integrated at IP level
Although KNX has been connected to the IP world for many years already thanks to the KNXnet/IP protocol, the KNX IoT specifications open a new era in the KNX development landscape. KNXnet/IP can be briefly described as an encapsulation of the KNX telegram (like the one produced in the TP bus) in an IP telegram, and handled by KNX IP interfaces and KNX IP routers with the right mechanisms and procedures.
KNX IoT aims to enhance the way KNX is integrated at IP level, offering development options that are non-KNX specific and widely used in the industry, thus reducing the development effort and adopting well-established mechanisms in IP. KNX IoT can be divided in 2 branches as follows:
KNX IoT 3rd Party API server
The main highlight of KNX IoT 3rd Party API server is its standardised API approach. Before KNX IoT, servers that had connectivity with a KNX installation offered proprietary solutions to build software clients, thereby locking the software developer to one specific brand. One of the core values of KNX technology is standardisation, therefore a standard API approach has been created. Following this philosophy, the KNX IoT 3rd Party API server has been added to the KNX specifications. This server creates an abstraction layer between KNX-specific knowledge and the software developer, facilitating the task of developing software applications that can harness the data produced by KNX installations, among other advantages.
The specifications describe the security between the server and the client too, which is based on https and OAuth2.0. Even more importantly, the specifications describe the semantic layer that is added to the KNX Information Model, thus creating a rich set of data with great value. The semantic information is found at KNX device level, and, together with the information which is generated when designing the KNX installation with ETS, it is carried through the system integration chain to the KNX IoT 3rd Party API server. Lastly, the KNX IoT 3rd Party API server can have a direct connection to the twisted pair medium, or sit on the IP infrastructure (Local Area Network or Wide Area Network).
KNX IoT Point API device
The other branch of KNX IoT refers to the KNX IoT Point API device, which is a KNX device that uses an IPv6-based physical layer such as THREAD. In a nutshell, it is the same concept of interoperability as found with TP and RF (Radio Frequency), but in this case, the lower layers of the protocol stack are not KNX-specific. Instead, a mesh network approach is used, thus capable of using elements of that network (such as border routers) for communicating KNX data. Middleware between KNX IoT Point API devices and other KNX devices will then be required. In any case, the philosophy of interoperability at application level and the vendor-independent configuration software remains.
Conclusion
The business opportunities that are enabled thanks to the broadened horizons of the KNX development landscape make KNX more appealing than ever, making it easier to create products, solutions and services. In my opinion, the technologies found in the KNX development landscape, with KNX IoT at the top, offer the perfect foundation to revolutionise the way we understand homes and buildings.
Jesus Arias is in charge of Membership & Business Development for KNX Association.
