PulseSensor – Software project

Aktualisiert8. November 2024

The PulseSensor software project is a Java bundle which we intend to run on the OSGI platform Eclipse Kura is built on.

It consists out of 5 different classes.

PulseSensorMQTT class

This is the main class which contains the bundle-activate, bundle-update and bundle-deactivate methods, so all the methods which the OSGI framework is using to control the status of the bundle.

This class starts in total 3 threads from which 2 remain active throughout the entire lifecycle of the bundle.

The openHABMQTT-Thread is for communication with the openHAB MQTT Broker to set/unset the Alarm notification. Theoretically we could use the Eclipse Kapua MQTT broker for this, which would eliminate some complexity of the bundle. However, openHAB does not yet provide a binding to the Eclipse Kapua broker yet. The Eclipse Kapua broker is not straight forward and requires a specific formatting of the payload.

The SerialDataCollection-Thread monitors the serial interface and reacts on incoming traffic from the Arduino via a listener. Once a new set of data arrived, it evaluates if the BPM is within the compliance range and sets the Alarm notification to true/false accordingly.

Finally, we have the syncGPIOThread thread which is responsible for setting/unsetting the Alarm- and OK LED on the breadboard. This thread is needed to sync the availability of the GPIOOperations object, the GPIOService thread and the PulseSensorMQTTOptions object in the bundle startup phase. Once all objects are in sync, this thread dies.

In the Eclipse Kura Management console, you can see under [DEVICE ]->[THREADS] the two threads which are active as long the bundle stays active.

Another important function of the PulseSensorMQTT class is two bind services which are offered by the Eclipse Kura framework. Firstly, the CloudPublisher- and CloudSubscriber Service to communicate with the Eclipse Kapua MQTT Broker service.

CloudPublisher-and CloudSubscriber services are configured in the Eclipse Kura Management console under [CLOUD CONNECTIONS].

The ServicePID is used to configure the PulseSensorMQTT bundle so that it is able to communicate with the Eclipse Kapua platform.

The third Kura service which is leveraged by the PulseSensorMQTT bundle is the GPIOService to manage Raspberry PI’s GPIOs.

Once you reference to these services in your bundle, you must implement their interfaces. So, for the GPIOService this is the bindGPIOService and the unbindGPIOService.

For the CloudPublisher Service there are the setCloudPublisher and unsetCloudPublisher interfaces.

/**
* Setting the CloudPublisher object
* registering the Listeners for CloudConnection and CloudDelivery
* @param cloudPublisher Kura-cloudPublisher object
*/
public void setCloudPublisher(CloudPublisher cloudPublisher) {
	       	   PulseSensorMQTT.cloudPublisher = cloudPublisher;
	           PulseSensorMQTT.cloudPublisher.registerCloudConnectionListener(PulseSensorMQTT.this);
	           PulseSensorMQTT.cloudPublisher.registerCloudDeliveryListener(PulseSensorMQTT.this);
     PulseSensorMQTT.logger.info("CloudPublisher set");
}

/**
* Un-Setting the CloudPublisher object
* de-registering the Listeners for CloudConnection and CloudDelivery
* @param cloudPublisher Kura-cloudPublisher object
*/
public void unsetCloudPublisher(CloudPublisher cloudPublisher) {
	           PulseSensorMQTT.cloudPublisher.unregisterCloudConnectionListener(PulseSensorMQTT.this);
	           PulseSensorMQTT.cloudPublisher.unregisterCloudDeliveryListener(PulseSensorMQTT.this);
         PulseSensorMQTT.cloudPublisher = null;
         PulseSensorMQTT.logger.info("CloudPublisher unset");
}

A very important service offered by Eclipse Kura is the Configurable Component Service. This interface class provides access to the Eclipse Kura configuration options.

The PulseSensorMQTT bundle uses this configuration option widely! The good thing is that you can configure this bundle either locally or even remotely in the Eclipse Kapua Management platform.

Below is a representation how it looks like in the Eclipse Kura Management platform.

The same representation can be found in the Eclipse Kapua Management platform.

This enables us to configure our bundle remotely.

Parameters

The following parameters can be configured to make the PulseSensorMQTT bundle functional. All parameters can be configured in the de.natrix.kura.pulsemqtt.PulseSensorMQTT.xml file.

BPM Multiplying factor

This is a hack to simulate a BPM alarm. The Integer value provided is multiplied with the actual measurement result to simulate a higher pulse as actually measured.

[Default]: 1

CloudPublisher Target Filter

Specifies, as an OSGi target filter, the ServicePID of the Cloud Publisher used to publish messages to the cloud platform.

[Default]: (kura.service.pid=KuraPublisher)

CloudSubscriber Target Filter

Specifies, as an OSGi target filter, the ServicePID of the Cloud Subscriber used to receive messages from the cloud platform.

[Default]: (kura.service.pid=KuraSubscriber)

Data Collection (true/false)

Specifies whether the bundle shall listen on the serial interface for incoming traffic.

[Default]:true

MQTT Publishing (true/false)

Specifies whether the bundle shall publish values to the Eclipse Kapua MQTT broker.

[Default]:true

MQTT Publishing (true/false)

Specifies whether the bundle shall publish values to the Eclipse Kapua MQTT broker.

[Default]:true

MQTT Publishing to 3rd party broker (true/false)

MQTT publishing to 3rd party broker enabled

[Default]:true

Serial Interface

Serial interface to listen for Arduino data.

[Default]: /dev/ttyACM0

Time out [ms]

Timeout for serial interface initialization

[Default]: 2000

baud rate [Bytes/s]

Baud rate of the serial interface

[Default]: 115200

3^rd Party MQTT Broker

3^rd Party MQTT Broker address:port

[Default]: tcp://127.0.0.1:1883

MQTT topic Publish

MQTT topic to publish Alarm to openHAB App

[Default]: cmnd/pulsesensor/Alarm

MQTT topic Subscribe

MQTT topic to subscribe for Alarm setting on openHAB App

[Default]: /topic/pulsesensor/metrics

MQTT topic for metrics Publish

MQTT topic to publish metrics to 3rd party broker

[Default]: /topic/pulsesensor/metrics

MQTT topic for metrics Subscribe

MQTT topic to subscribe for metrics on 3rd party broker

[Default]: stat/pulsesensor/Alarm

MQTT payload for Alarm=’ON’

MQTT payload for setting Alarm=’ON’

[Default]: OFF

MQTT payload for Alarm=’OFF’

MQTT payload for setting Alarm=’OFF’

[Default]: ON

Setting alarm for min. BPM [beats/minute]

Setting [min] value for when BPM Alarm

[Default]: 40

Setting alarm for max. BPM [beats/minute]

Setting [max] value for when BPM Alarm

[Default]: 120

Setting filter for BPM false measures [beats/minute]

BPM Filter [max], everything above will be ignored

[Default]: 180

Setting filter for InterBeatIntervall false measures [ms]

IBI Filter [max], , everything above will be ignored

[Default]: 1200

Setting filter for Sample Rate false measures [mV]

SampleRate Filter, , everything above will be ignored

[Default]: 1000

gpio.service.pid

The Kura GPIO service to be used to interact with GPIOs.

[Default]: org.eclipse.kura.gpio.GPIOService

gpio.input.read.mode

Specifies how input pin value is obtained. If set to PIN_STATUS_LISTENER, the pin value will be printed on the log on change, if set to POLLING, the pin value will be read and printed on the log periodically(basically not needed as we only set the pins, and don’t read from them).

[Default]: PIN_STATUS_LISTENER

gpio.pins

List of GPIO pins expressed as pin number or pin name (i.e. DOUT1, DIN1, …). First row: ALARM(red)-PIN; 2^nd Row: OK(green)-PIN. The PulseSensorMQTT bundle is capable to configure two pins at once.

There is a mapping between the GPIO pins of Raspberry PI and how they are named in Eclipse Kura. This mapping is made in the file /path-to-kura/framework/jdk.dio.properties.

(Microsoft(1), 2021)

[Default]: GPIO_GEN4

[Default]: GPIO_GEN5

gpio.directions

Pin directions for both configured Pins

[Default]: Both, init output

gpio.modes

Pin working mode of both configured pins

[Default]: Default

gpio.triggers

Input triggering mode of both configured pins (basically not needed as we only set the pins, and don’t read from them).

[Default]: Default

PulseSensorMQTTOptions class

The PulseSensorMQTTOptions class reads all Configurable Component properties for the PulseSensorMQTT bundle and provides the parameter values within the bundle via getter/setter methods.

SerialInterface class

The SerialInterface class initializes the serial Interface on the Raspberry PI and adds a listener to it. Whenever data are coming from Arduino, this class processes them. It filters out abnormal values and determines whether the BPM alarm value is outside the compliance range to raise an alarm. After this analysis, this class initiates to get the values pushed to Eclipse Kapua via the PulseSensorMQTT class and its CloudPublisher Service, as well as setting the correct status of both the Alarm- and OK LED, also via the PulseSensorMQTT class and its implementation of the GPIOService.

ThirdPartyBrokerMQTT class

This class is all about communicating with the MQTT broker (Mosquitto broker, running on the Natrix Gateway) and to publish/subscribe to specific topics. One use case is to publish the Alarm notification to a topic for setting the Alarm notification of an openHAB item (Switch). This item can be displayed in the UI of openHAB (whether on a webpage or the openHAB App which is able to render openHAB sitemaps). There is also an option to control the Alarm- and OK LED on the breadboard by subscribing and consequently receiving item state changes back from openHAB. The other use case is to publish all metrics (Beats per Minute, Inter Beat Interval and sample data) to this broker from where it is processed via Telegraf into the Grafana Live API to show nearly real-time measurement data in a Grafana plot.

GPIOOperations class

The GPIOOperations class receives the GPIOService object from the PulseSensorMQTT class to control the GPIO pins. It also receives the PulseSensorMQTTOptions object from the PulseSensorMQTT class to access all configured parameters.

This class provides certain methods to the PulseSensorMQTT class such as a method for n- repetitions of blinking and polling specific pins to signal that the bundle hast started respectively updated. Furthermore, it exposes a method for setting the Alarm (red) and OK (green) LED according the beats per Minute Alarm status

The below class diagram shows the dependency between all classes of the PulseSensor bundle.

The Wrapper Helper class

Our PulseSensor Project requires two libraries which are not provided by the Eclipse Kura™ framework. Therefore, we provide those classes in a specific ‘Wrapper-bundle’ -> de.convergeit.osgi.wrapper.

This is an additional bundle which we need to deploy into the Eclipse Kura™ framework in order to expose two important libraries to the PulseSensor bundle and which are not provided by default from the Eclipse Kura™ framework. Those are

org.eclipse.paho.client.mqttv3-1.2.5.jar -> Paho MQTT client library
rxtx-2.1.7.jar -> native lib providing serial and parallel communication

This bundle has no own source code, it simply exports packages which in turn are imported by our PulseSensor bundle. Our PulseSensor bundle can only do this when the Eclipse Kura™ framework provides access to those packages respectively the jar files which contain those packages. In the figure below we see the manifest.mf file of our wrapper-bundle. It does nothing else than to define the exported packages, which are all part of the two jar-files mentioned in the Classpath section.

In our PulseSensor Project we see under [Referenced Libraries] that we reference to this wrapper-bundle.

Project specific Software Development Environment configuration

In order to be able to completely follow the complete development path and activities, we need to arrange our development environment in a way that it serves our needs.

Eclipse IDE

In general, we recommend that each Maker project runs in its own workspace. Consequently, the first step is to generate a new workspace.

Under [File]->[Switch Workspace]->[New] we generate a new workspace. To ease our life, we are copying all the settings which we defined so far in our initial ‘generic’ workspace into our new workspace (workspace_pulsesensor):

Importing Kura User Workspace

To set up your Kura project workspace, you will need to download the Kura User Workspace archive here: https://www.eclipse.org/kura/downloads.php.

Be cautious that you download exactly the version of the User Workspace which matches the version of your Eclipse Kura™ platform.

The result of the download is a zip file which is stored in your local download folder (configured in your browser settings). In our case this is the file user_workspace_archive_4.1.2.zip.

From the Eclipse menu [File]->[Import]->[General]->[Existing projects into Workspace]->[Select archive file].

There are a couple of sample projects imported into the workspace, which still show a lot of errors which need to be fixed.

In the [target-definition]project, double-click on the kura-equinox_3.12.50.target file, which opens the Target Definition window. Here we need to click the link ‘Set as Active Target Platform’.

Doing so will reset the target platform, rebuild the Kura projects, and clear the errors that were reported. However, we still have some warnings about depreciated functions and others, but which can be ignored for now. At this point, we are ready to begin developing Kura-based applications for our target platform.

Connecting to the Natrix Gateway Eclipse Kura™ platform

The mToolkit Plug-In allows us to connect directly to Eclipse Kura™ OSGI platform which enables us to manage the lifecycle (install, update, stop, start) of bundles out of our development environment. We need to open the mToolkit view under [Window]->[Show View]->[Other]

Once the View opened, we can add our Natrix Gateway Eclipse Kura™ to the mToolkit framework. Only parameters we have to supply is a name of the framework and the IP address of our Gateway. Leave the port 1450 as it is presuming it hasn’t been altered on the Eclipse Kura™ platform.

Once mToolkit successfully connected to the platform, we can see all bundle and their current state!

Importing PulseSensor project

We will import the PulseSensor project from GitHub where the Natrix Project stores all of its projects. For this, we launch the Egit view and click on the button [Clone a Git Repository and add the clone to this view].

In the repository path, provide the link to the PulseSensor project in the Natrix Project GitHub account:

https://githiub/xxxx/yyyy

Provide your personal GitHub account login credentials, select the ‘main’ branch only and provide a local GitHub repository on your development system where the clone shall be stored.

Once we imported project, we have a local clone stored and we can find all the details in the Egit View:

Cloning the projects into our local git repository does not automatically enables us to work with the source in our Plug-in development view.

A final step is to import this cloned project into our development environment. Change the view to ‘Plug-in development’ (that we can see the Eclipse Kura™ framework) and go to [File]->[Import]->[Git]->[Projects from Git]->[Existing local repository]. Select our just cloned project PulseSensor, select [Import existing Eclipse projects] and select again our project to start the import process.

We see that we actually import two projects. The PulseSensor project de.natrix.kura.pulsemqtt-V3-GPIO which is our main development project. Furthermore, we also import the de.convergeit.osgi.wrapper project(-> The Wrapper Helper class).

Deploying PulseSensor project to the Eclipse Kura™ framework on the Natrix Gateway

There are two different ways how we can deploy the project bundles to the Eclipse Kura™ framework. One way is to export the projects into deployable plug-ins which actually represent bundles which we can import into the OSGI framework. The other option will be to create a ‘deployment package’ DP.

Deploying via Plug-ins

A Plug-in is basically a jar file which we can generate via a project export. We mark both projects which we want to export into a jar file, then [mouse right click] and select the [Export] function.

From there, we select the [Plug-in Development]->[Deployable plug-ins and fragments] option and define a folder under [Direction] where we want to export our two project jar files to.

Finally, we have exported our two projects in two jar files:

Deploying via a Deployment Package

Instead creating a stand-alone plug-in, we can also create a Deployment Package that contains multiple bundles, configuration elements, etc. that can be deployed into the Eclipse Kura™ (or any other) OSGi framework.

To create a Deployment Package, we first need to create a Deployment Package definition. Go to [File]->[New]->[Other]->[OSGI]->[Deployment Package Definition].

Here we define the path within our project where the package definition shall be stored. We recommend adding a dedicated folder /resources/dp where to store any deployment package definitions and finally the deployment packages as such.

By double-clicking on the PulseSensorDPP.dpp file, the workbench opens the deployment package editor. Here we can add the bundles into the package which we want to deploy at once. In our case this is as already explained the wrapper-bundle and our main bundle, the PulseSensor bundle.

To generate the deployment package as such, right click on the final configured dpp file and execute [Quick Build]. The result is a dp file (PulseSensorDPP.dp) which is finally the file which can be deployed.

Project specific Software Component configuration

In a previous section of this chapter we have seen all the software components which have been used in this project. While we explained in another chapter already the installation process of the components, we need to continue here with the project specific configuration of the various components.

Eclipse Kapua™

There are a couple of configurations which we have to male in the Eclipse Kapua™ platform. We will create a new Child account, assign a new user to this account and manage some account specific settings.

This is all done with our kapua-sys account (user=kapua-sys, password=kapua-password).

Creating a new Child Account

Go to [Child Accounts]->[Add] and add a new account by providing a name, organizational name and an organizational email-address. While with the PulseSensor application we are representing a healthcare-related use case, we choose a hospital (Derry-Hospital) for this child-account.

Creating a new User and assign it to the new account

Select the account we just created, click [Users] and add a user with username, Display name, email address and telephone number (optional). At this point, we are not yet able to assign privileges to this user, this comes some steps later.

Now we need to switch to our new created account.

Modifying Account Settings

For our new account – Derry-Hospital – we need to adapt some settings which enable us to further work with this account.

In [Child Accounts]->[Derry-Hospital] click on the tab [Account Settings]. For specific services, we need to adapt the number allowed number of these services to enabled on the system.

This needs to be done for the following services:

Account Services -> infiniteChildAccounts = true
DeviceRegistryServices -> infiniteChildDevices = true
GroupService ->infiniteChildGroups = true
JobService ->infiniteChildJobs = true
RoleService ->infiniteChildRoles = true
TagService ->infiniteChildTags = true
UserService ->infiniteChildUsers = true

Modifying User privileges and roles

From here, go to [Users]->[Physician-1] and switch to the tab [Roles]. Assign the Admin role to the user Physician-1. Then go over to the [Permissions] tab and grant all permissions to this user.

Eclipse Kura

This sub-chapter is about how to configure our Eclipse Kura™ framework to connect with both the Eclipse Kapua™ platform as well as with the openHAB3 Broker.

Configuring the Cloud connection to the Eclipse Kapua™ platform

An important task is to connect our Eclipse Kura™ framework with the Eclipse Kapua™ platform. There are three entities to configure. The CloudService as such the DataService and the MQTTDataTransport Service.

Configuring the CloudService

For configuring the CloudService, we go to [Cloud Connections] and select the [CloudService] tab.

Attribute	Value	Note
Device Display-Name	custom	allows for own name
Device Custom-Name	Natrix-Gateway-PulseSensor-Maker-Project
Topic Control-Prefix	$EDC	Default value
Encode gzip	true	Default value
Republish Mqtt Birth Cert On Gps Lock	false	Default value
Republish Mqtt Birth Cert On Modem Detect	false	Default value
Enable Default Subscriptions	true	Default value
Birth Cert Policy	Publish birth on connect and reconnect	Default value
Payload Encoding	Kura Protobuf	Default value

Push the configuration by [Apply] the configuration changes.

Configuring the DataService

For configuring the DataService, we go to [Cloud Connections] and select the [DataService] tab.

Attribute	Value	Note
Connect Auto-on-startup	true
Connect Retry-interval	60	Default value
Enable Recovery On Connection Failure	false	Default value
Connection Recovery Max Failures	10	Default value
Disconnect Quiesce-timeout	10	Default value
Store DB Service PID	org.eclipse.kura.db.H2DbService	Default value
Store Housekeeper-interval	true	Default value
Store Housekeeper-interval	900	Default value
Store Purge-age	60	Default value
Store Capacity	1000	Default value
In-flight-messages Republish-on-new-session	True	Default value
In-flight-messages Max-number	9	Default value
In-flight-messages Congestion-timeout	0	Default value
Enable Rate Limit	true	Default value
Rate Limit Average	1	Default value
Rate Limit Time Unit	Seconds	Default value
Rate Limit Burst Size	1	Default value

Push the configuration by [Apply] the configuration changes.

Configuring the MQTTDataTransport Service

For configuring the MQTTDataTransport Service, we go to [Cloud Connections] and select the [MQTTDataTransport] tab.

Attribute	Value	Note
Broker-url	mqtt://[Eclipse-Kapua-Server]:1883/	This is our Eclipse Kapua server on port 1883
Topic Context Account-Name	Derry-Hospital	Creating a new Child Account
Username	Physician-1	Creating a new User and assign it to the new account
Password	<<your password here >>	Creating a new User and assign it to the new account
Client-ID	Natrix-Gateway-PulseSensor-Maker-Project	Let’s use the custom name for it
Keep-Alive	30	Default value
Timeout	20	Default value
Clean-session	true	Default value
LWT Topic	$EDC/#account-name/#client-id/MQTT/LWT	Default value
LWT Payload		Default value
LWT Qos	0	Default value
LWT Retain	true	Default value
In-flight Persistence	Memory	Default value
Protocol-version	3.1.1	Default value
SSL Default Protocol	1	Default value
SSL Hostname Verification	Rely on SSL Manager Service configuration	Default value
SSL Default Cipher Suites		Default value
SSL Certificate Alias		Default value

Push the configuration by [Apply] the configuration changes.

Checking connectivity status to Eclipse Kapua™ platform

We have to places where we can check the successful connection status between Eclipse Kura™ and Eclipse Kapua™.

After applying all configuration parameters in Eclipse Kura™, the connection status is displayed at the top of the configuration page:

In Eclipse Kapua™ we see our Natrix Gateway connected under the Client-ID as configured (Natrix-Gateway-PulseSensor-Maker-Project) and with the user Physician-1.

Adding a Publisher and Subscriber Service for the PulseSensor project

Because we publish our PulseSensor Telemetry data to Eclipse Kapua™, we need to configure a Publisher Service in Eclipse Kura™. Although we don’t need a Subscription service yet in our project, for the sake of completeness we also add a Subscriber Service.

We go to [Cloud Connections]->[New Pub/Sub] , select the factory org.eclipse.kura.cloud.publisher.CloudPublisher add a Publisher Service with the name ‘KuraPublisher’.

Same we do with the Subscriber Service, adding a Service ‘KuraSubscriber’ and assign it to the factory org.eclipse.kura.cloud.subscriber.CloudSubscriber.

Adding a Publisher and Subscriber Service for the PulseSensor project

Deploying the PulseSensor Deployment Package

Most of the configuration is done using the configuration settings of our PulseSensor project. So, the first step is to deploy the PulseSensor Deployment Package to the Eclipse Kura™ framework.

The PulseSensor Deployment Package is available for download from the Natrix Project GitHub account. (NatrixProject(1), 2021)

We need to download the ‘PulseSensorMQTT.dp’ file to your local PC.

Once we have done this, let’s open the Eclipse Kura™ Administration pages under http://[ip-address-of our-gateway]:80.

Navigate to [Packages]->[Install/Upgrade]

and choose the ‘PulseSensorMQTT.dp’ file from the location on your PC where you downloaded it.

Push [Submit] and we will see that the package has been successfully deployed into the Eclipse Kura™ framework.

Configuring the PulseSensor Plug-in

After the deployment of the package, the PulseSensorMQTT plug-in (bundle) appears in the active bundle list. With a click on it, the configuration section of the PulseSensor bundle opens on the right-hand site of the Administration page.

The following parameters need to be configured for the attributes provided by the PulseSensor bundle:

Attribute	Value	Note
BPM Multiplying factor	1	Disables value manipulation
CloudPublisher Target Filter	(kura.service.pid=KuraPublisher)	Available as target
CloudSubscriber Target Filter	(kura.service.pid=KuraSubscriber)	Available as target
Data Collection (true/false)	true
MQTT Publishing (true/false)	true
MQTT Publishing to 3rd party broker (true/false)	true
Serial Interface	/dev/ttyACM0	Arduino-Natrix-Gateway serial connection
Time out [ms]	2000
Sampling rate [ms]	10000
baud rate [Bytes/s]	115200
3^rd Party MQTT Broker	tcp://127.0.0.1:1883	Local Mosquitto Broker
MQTT topic Publish	cmnd/pulsesensor/Alarm	see here
MQTT topic Subscribe	stat/pulsesensor/Alarm	see here
MQTT topic for metrics Publish	/topic/pulsesensor/metrics
MQTT topic for metrics Subscribe	/topic/pulsesensor/metrics
MQTT payload for Alarm=’ON‘	OFF	Payload when sending Alarm=on
MQTT payload for Alarm=’OFF‘	ON	Payload when sending Alarm=off
Setting alarm for min.BPM [beats/minute]	40	Low threshold for Pulse alarm
Setting alarm for max. BPM [beats/minute]	120	High threshold for Pulse alarm
Setting filter for BPM false measures [beats/minute]	180	Everything above =false measure
Setting filter for InterBeatIntervall false measures [ms]	1200	Everything above =false measure
Setting filter for Sample Rate false measures [mV]	1000	Everything above =false measure
gpio.service.pid	org.eclipse.kura.gpio.GPIOService
gpio.input.read.mode	PIN_STATUS_LISTENER
gpio.pins	GPIO_GEN4,GPIO_GEN5	The two Pins of our project
gpio.directions	Both, init output
gpio.modes	Default
gpio.triggers	Default

Push the configuration by [Apply] the configuration changes.

If everything works smoothly, we see our first data arriving in Eclipse Kapua™ when connecting the PulseSensor to our fingertips.

Changing the Eclipse Kura™ log-parameters

As we want to have all PulseSensor Project related logfiles separated from the standard Kura log-files, we need to adjust the log4j.xml file in the directory /opt/eclipse/kura/user.

We have a dedicated logger for each module of the PulseSensor Project -> PulseSensorMQTT, SerialInterface, openHABMQTT and GPIOComponent. For each new logger we also require a dedicated Appender (RollingFileAppender).

nano /opt/eclipse/kura/user/log4j.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
#
# Copyright (c) 2018, 2019 Eurotech and/or its affiliates
#
#  All rights reserved. This program and the accompanying materials
#  are made available under the terms of the Eclipse Public License v1.0
#  which accompanies this distribution, and is available at
#  http://www.eclipse.org/legal/epl-v10.html
#
# Contributors:
#   Eurotech
#
-->
<Configuration status="warn" strict="true" name="KuraConfig" monitorInterval="30">

    <Properties>
        <Property name="filename">/var/log/kura/kura</Property>
    </Properties>
    <Filter type="ThresholdFilter" level="trace"/>
 
    <Appenders>
        <RollingFile name="RollingFile" fileName="${filename}.log" filePattern="${filename}-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz">
            <PatternLayout>
                <Pattern>%d{ISO8601} [%t] %-5p %c{1.} - %m%n%throwable{full}</Pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="20 MB"/>
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
        <RollingFile name="PulseSensorMQTT" fileName="/var/log/kura/PulseSensorMQTT.log" filePattern="/var/log/kura/PulseSensorMQTT-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz">
            <PatternLayout>
                <Pattern>%d{ISO8601} [%t] %-5p %c{1.} - %m%n%throwable{full}</Pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="20 MB"/>
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
        <RollingFile name="SerialInterface" fileName="/var/log/kura/SerialInterface.log" filePattern="/var/log/kura/SerialInterface-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz">
            <PatternLayout>
                <Pattern>%d{ISO8601} [%t] %-5p %c{1.} - %m%n%throwable{full}</Pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="20 MB"/>
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
        <RollingFile name="ThirdPartyBroker" fileName="/var/log/kura/ThirdPartyBroker.log" filePattern="/var/log/kura/ThirdPartyBroker-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz">
            <PatternLayout>
                <Pattern>%d{ISO8601} [%t] %-5p %c{1.} - %m%n%throwable{full}</Pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="20 MB"/>
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
        <RollingFile name="GpioComponent" fileName="/var/log/kura/GpioOperations.log" filePattern="/var/log/kura/GpioOperations-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz">
            <PatternLayout>
                <Pattern>%d{ISO8601} [%t] %-5p %c{1.} - %m%n%throwable{full}</Pattern>
            </PatternLayout>
            <Policies>
                <SizeBasedTriggeringPolicy size="20 MB"/>
            </Policies>
            <DefaultRolloverStrategy max="10"/>
        </RollingFile>
		
    </Appenders>
 
    <Loggers>
        <Logger name="org.eclipse" level="info" additivity="false">
            <AppenderRef ref="RollingFile"/>
        </Logger>
 
        <Root level="warn">
            <AppenderRef ref="RollingFile"/>
        </Root>
	<Logger name="de.natrix.kura.pulsemqtt.SerialInterface" level="info" additivity="false">
            <AppenderRef ref="SerialInterface"/>
        </Logger>
        <Logger name="de.natrix.kura.pulsemqtt.PulseSensorMQTT" level="info" additivity="false">
            <AppenderRef ref="PulseSensorMQTT"/>
        </Logger>
        <Logger name="de.natrix.kura.pulsemqtt.ThirdPartyBrokerMQTT" level="info" additivity="false">
            <AppenderRef ref="ThirdPartyBroker"/>
        </Logger>
        <Logger name="de.natrix.kura.pulsemqtt.GpioOperations" level="info" additivity="false">
            <AppenderRef ref="GpioComponent"/>
        </Logger>	
  </Loggers>
 
</Configuration>

PulseSensor - Software Project

PulseSensor – Software project

Changing the Eclipse Kura™ log-parameters