Configure IoT Gateway Applications with Kura

linda Examples Leave a Comment

By nature IoT applications are dynamic and, thus, complex and challenging to build. Devices can come and go at anytime. So does the network connection. Moreover, executing a system in different situations may require runtime adjustments. You can, of course, redeploy the application. However, there is another (better) option: specify configuration properties and let the values be changed at runtime.

Reactive Blocks provides templates and building blocks that enable you to use Eclipse Kura Configuration service easily and, thus, making your IoT applications configurable. Hence, you can deploy and configure applications in thousands of IoT gateways.


Eclipse Kura

Eclipse IoT provides a Java stack to help developers build complex IoT systems. As part of the stack, Kura offers a Java and OSGi-based container for applications running on gateways. To configure applications with Kura, developers define properties, i.e., key-value pairs. The values can be set remotely through a GUI on the web-console. You can see an example how this is done at the end of this article.

Configuration properties are described as metadata in compliance with the OSGi Metatype specification. Kura provides the Configuration service which is based-on the OSGi ConfigurationAdmin. When an application, i.e., a service component, is registered, Kura gives the latest stored configuration, if any, or creates a new one with the default values defined in the metatype. Any subsequent changes are also sent to the application.


Reactive Blocks support

Screen Shot 2014-10-09 at 11.15.23

Reactive Blocks is extended to enable developers utilize Kura’s configuration feature. This extension consists of three parts as follows:

  1. Template for configurable applications:
    If a developer chooses to build a Kura configurable application, a metatype file is also generated. This file contains examples of configuration properties. The developer can, thereafter, modify the examples to suit the application’s needs.
  2. The Config Listener Block:
    We create the Config Listener Block in our Kura library. This block works together with our code generator and provides configuration changes to the application. As a developer, all you need to do is simply drag this block into your specification.
  3. Kura code generator:
    When the build process, i.e., creating an OSGi bundle from a specification, is invoked, Reactive Blocks automatically generates files that manages this configuration feature: A component class that receives and forwards configurations to the Config Listener block is created. A component definition is also generated. In addition, Reactive Blocks ensures that the convention required by Kura is applied consistently.


An Example

We created an example application with Reactive Blocks that runs on a Raspberry Pi with a lamp (or LED) connected to it via a GPIO pin. The lamp is toggled periodically and its current status (on or off) is sent to an MQTT broker. The following figure shows what the application looks like.


Block Periodic Toggler on the top-left emits a tick that toggles the lamp. Then, the lamp passes its current status as a boolean value via pin toggled. The Publisher block receives this status and sends it as an MQTT message with a certain topic.

In this example, two properties are configurable, namely the duration of periodic toggle and the topic of messages sent to the broker. This means that blocks Periodic Toggler and Publisher need to listen to configuration changes. Let us see the behavior of Periodic Toggler in more details.


As shown in the figure above, Block Periodic Toggler contains an instance of the Config Listener block. Upon receiving the initial configuration via pin initConfig, the toggle duration is extracted and used to start the Timer Periodic block which emits a tick every specified duration. When a new duration is detected via pin updatedConfig and operation newDuration, block Timer Periodic is restarted with the updated value.

What about the Publisher block? It is not hard to imagine that it is very similar. As shown in the figure below, it also includes the Config Listener block. But instead of the toggle duration, here we extract the publish topic.


The two properties are defined as metatype in the XML file shown below.


Developers only need to focus on the properties, namely line 7 – 21 in the example above. When the build process is invoked, Reactive Blocks automatically generates a corresponding metatype that obeys Kura’s convention.

The two properties can be seen and set via Kura’s web-console as depicted in the following figure. After the values are modified and button Apply is pressed, the application will receive an event containing the new values.


Do you want to build configurable applications with Reactive Blocks and Kura? Learn more about Kura from here. Feel free to contact us for more info. 🙂

Leave a Reply