The e-magazine for KNX home & building control

KNX IoT: Part 7 – the open-source KNX IoT stack

In the seventh of this series of articles on KNX IoT, Bruno Johnson and Wouter van der Beek explain the open source KNX IoT Stack.

Digital transformation has been one the main strategy topics on company board meeting agendas for the last few years. The opportunity to develop digital services from cloud-based applications requires Internet protocol (IPv6) based network connections to edge devices that become the customer interface. Businesses of all shapes and sizes in commercial building automation have been asking for wireless IoT solutions to make this happen, and KNX Association responded by releasing KNX IoT Point API (KNX IoT), including an open-source stack.

Why release an open-source stack?

Implementing a new stack is a costly business. The KNX Association took the opportunity to fund the implementation of KNX IoT open-source stack, and this stack was implemented by Cascoda on behalf of the KNX Association. The open-source license has been chosen in such a way that everyone can use the stack in their products. Since the stack is generic, it means that a porting layer to the underlying system is needed. Also, it means that the application layer is missing, e.g., what the device needs to do. However, to support this there is a porting layer and an application layer so that functional devices can be created. Hence, having an open-source stack means that a lot of layers are already implemented and ready to use.

Stack components.

Porting layer

The definition of the stack is that there is a porting layer to the underlying operating system. This allows porting to any other system. The stack supports two operating-system ports: Windows and Linux. Both operating systems are used to validate the implementation and can be used for showcasing the stack.

When running the stack on Thread-based devices, there are currently two ports available: one from Cascoda on its Chili Module and one from Nordic on its zephyr-based modules.

Stack with application layer API and porting layer.

Application Level

The application level has an API to create the datapoints. The datapoints will have a dpt and dpa value and use an API to register callbacks to handle the GET (and PUT) functions that should be implemented for the actual datapoint. The code snippet to create a datapoint is as follows:

The code snippet to create a datapoint

The function prototypes for the GET and PUT callbacks are the same, but the behaviour is different. The GET function only returns the data. The function to send a global Boolean variable back as payload is represented in the following function:

The function to send a global Boolean variable back as payload.

The PUT function will have an input payload which needs to be used to perform an action; most of the time the PUT function will not have a return payload, hence the function to parse a Boolean in the input is represented in the following function:

The function to parse a Boolean in the input.

All other mechanics are already part of the stack:

  • Implementing all mandatory tables.
  • Secure onboarding with spake.
  • OSCORE security.

KNX IoT Virtual

There are also two example applications that allow you to play around with KNX IoT. Although they are called virtual devices, they implement actual KNX IoT applications running on a PC and can be seen as a digital twin. The virtual applications can be configured with ETS.

The knx_iot_virtual_pb is a push button application with feedback. It implements a button, which after configuration can send out an s-mode message.

Push button application.

The knx_iot_virtual_sa is a switch actuator application. It implements an actuator which after configuration can show the received value of an s-mode message.

Switching actuator.

Both example applications are available as code on GitHub and GitLab.

Summary

KNX IoT can run on any OS and any IPv6 network. For example, KNX IoT works with Wi-Fi b to Wi-Fi 6 and all versions of Thread.

The open-source KNX IoT stack is freely available and can be used to create KNX devices.

For Thread-based devices a porting layer is needed. Thread-based KNX IoT development kits are currently available from Cascoda that implement such a port, as well as a router to Wi-Fi and Ethernet. This allows for physical KNX IoT devices to be built and tested against each other or against KNX IoT virtual devices, and example applications are freely available for anyone to use.

Bruno Johnson and Wouter van der Beek are the CEO and COO respectively of Cascoda Limited. Cascoda is a communications company that manufactures secure IoT semiconductor radios and modules, and leads the development of secure IoT communications standards for smart building and smart city. Its products solve range, reliability, security, power and scalability issues for industrial and commercial IoT through patented innovations and the latest most secure standards, all integrated into inexpensive ultra-low power IoT modules.

www.cascoda.com

Screen shots by Cascoda
Figures by Cascoda (on GitHub, as part of the stack documentation)

Share on facebook
Share
Share on twitter
Tweet
Share on linkedin
Share

SPONSORS

Interra iX3 4” Touch Panel


Interra iX3 4” Touch Panel
A next-generation room controller that transforms environmental management. With integrated sensors for temperature, humidity, brightness, and air quality (optional ...

Intesis DALI to KNX PRO


Intesis DALI to KNX PRO
The new Intesis DALI-2 to KNX TP PRO Gateway is a multi-master application controller for DALI-2 ballast ...

Clever solution for existing KNX properties


Clever solution for existing KNX properties
Anyone who built their home over three decades ago with the European installation bus can now upgrade it with modern ...

Interra KNX AC Gateway


Interra KNX AC Gateway
Interra KNX AC Gateway: Smart Climate Control Solutions The Interra KNX AC Gateway offers an innovative solution for climate control ...