ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker

for Healthcare Purposes in the COVID Scenario

Alberto Faro

, Daniela Giordano

and Mario Venticinque

DeepSensing srl Innovative Start-up, Catania, Italy

Dept. of Electrical, Electronics and Computer Engineering, Catania University, ISAFOM-CNR Associate, Catania, Italy

Istituto per i Sistemi Agricoli e Forestali del Mediterraneo ISAFOM – CNR, Catania, Italy

Keywords: Cyber Physical Systems (CPS), IoT, MQTT Communication Protocol, Mobile Connected Healthcare, COVID

Control System, Ubiquitous and Pervasive Systems, SOM based Classification, Sensor Network, Tensorflow.

Abstract: The aim of this paper is twofold. First, it demonstrates a low cost implementation of a BLE/MQTT gateway

to support monitoring and control of the patient health conditions from distance by means of the commonly

used health devices. A variant of the CPS model is used to execute the monitoring and control tasks

effectively. Secondly, it points out that such a gateway together with conventional BLE sensors on body

temperature and oxygen in the blood and possible other BLE edge devices allow us to implement a pervasive

warning system on COVID status and some general forecast on COVID diffusion. MQTT edge devices are

also outlined for measuring the relevant health parameters at distance without the help of the above gateway,

but in a way that the sensed data may interoperate with the ones taken by the conventional BLE devices.

1 INTRODUCTION

Many IoT platforms are available on the market to

support the internet connectivity of sensors and

actuators with the aim of developing ubiquitous

monitoring and control of systems and processes

belonging to several domains, e.g., healthcare, mobile

information services and domestic appliances.

Such platforms generally implement control

services using the communication and basic services

of the Cyber Physical System (CPS) model as firstly

proposed in (Gill, 2006). In our approach we used a

variant of such model (Faro, 2020) consisting of a

simplified CPS model to manage common needs in

home automation and healthcare, called CPSc, where

c stands for common. Also, our approach is based on

a technology independent communication protocol,

i.e., MQTT (Stanford-Clark, 2013), to improve

sensors and actuators interoperability.

Aim of this paper is twofold. First, it demonstrates

a low cost implementation of a BLE/MQTT gateway

to support monitoring and control of the patient health

conditions from distance by means of the commonly

used health devices mainly provided with Bluetooth

https://orcid.org/0000-0001-8487-0019

https://orcid.org/0000-0001-5135-1351

Low Energy (BLE) interface, thus further developing

and finalizing the general themes introduced in (Faro,

2020). Gateways to allow devices provided with

Radio Frequency (RF) or Long Term Evolution

(LTE) channels to send/receive MQTT messages are

for further work. Secondly, the paper illustrates how

the use of the proposed gateway together with the use

of conventional BLE sensors on body temperature

and oxygen in the blood or other novel edge devices

allow us to implement a useful and pervasive warning

system on the current COVID status. How to derive

from the collected data a general forecast on COVID

spreading is also outlined in the paper.

Sect.2 extends the model of CPSc so that it may

be used not only to manage basic home automation

and healthcare needs but also mobility needs to help

patient assistance. This model is useful to understand

how the functions of the proposed monitoring and

control system don’t depend on the manufacturers

and how such functions may be extended for the

coordination of the overall control system by using

proper customer processes.

Sect.3 explains the software structure of the

overall architecture and in particular of the MQTT

Faro, A., Giordano, D. and Venticinque, M.

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario.

DOI: 10.5220/0010147800300041

In Proceedings of the 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors (PECCS 2020), pages 30-41

ISBN: 978-989-758-477-0

 2020 by SCITEPRESS – Science and Technology Publications, Lda. All r ights reserved

gateway that allows us to send through internet the

data taken by BLE sensors to distant devices or

remote centers without using smart phones. Sect.3

discusses also how implementing the visualization of

the measured data and simple control services using

the software Domoticz (Domoticz, 2015) to carry out

timely interventions and health studies. Edge sensors

that don’t need external MQTT gateways are also

proposed to implement distributed intelligent systems

that increase the control capability of the edge nodes

and reduce the network load.

Sect.4 discusses in details how exploiting the

systems proposed in sect.3 for pervasively measuring

in real time and at distance the body temperature and

oxygen in the blood featuring the COVID status. The

same approach is suggested to collect vital parameters

relevant for other risky pathology. Sect.4 illustrates

also: a) how using the devices available on the market

and the advanced devices envisaged in the paper to

collect the needed data, and b) how deriving from the

measured data suitable warning information and a

general forecast of the COVID diffusion.

The use of the suggested methods at a large scale

is for future studies since this involves the agreement

with other companies and Public Administration.

2 PERVASIVE AND UBIQUITOUS

CYBER PHYSICAL SYSTEMS

CPS is a layered structure similar to the Internet of

Things (IoT), that presents a meaningful coordination

between physical and computational elements as

shown in fig.1.

Figure 1: General structure of a Cyber Physical System.

A detailed functional architecture of CPSc to deal

with patient assistance from remote to meet common

healthcare needs is drawn in fig.2.

Figure 2: From the general CPS model to CPSc: a layered

functional model to meet common healthcare needs.

The model of CPSc allows us to point out in

details the main elements of the adopted CPS

architecture:

 the sensors and actuators used to collect health

data and to control the processes of a given field

should take into account the data collected on

another field. Generally the sensed data are sent

by a push method to a control center that on its

turn will follow the same push model for real

time controlling the supervised application.

 the control services should store the collected

data into internal files or into some data storage.

The main aim of the control services is the one

of finding suitable online recovery interventions

possibly taking into account data from multiple

fields.

 the customer processes should optimize the

activities of the control services and hopefully

should be able to find how to prevent dangerous

situations and to manage possible anomalies of

the supervised systems.

Coordination

& Optimization

Computation, Control

and Data Storage

Physical Layer

(Sensors and Actuators)

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario

Fig.2 points out three types of users:

 user A able to manage only patients residing at

home. Typically, user A may be the patient, a

family member or the family doctor.

 User B able to supervise patients that are either

at home or in mobility. This user may access the

health data storage to carry out diagnosis and

forecast. Typically, user B may be a doctor at

hospital or at a clinical lab.

 User C able to manage walking or driving

patients as well as to carry out diagnosis and

forecast. User C may be the patient, a family

member, the family doctor or the first aid staff.

The main feature of such model with respect to

the IoT systems is that the systems involved in the

cyber space should be able: to communicate, to carry

out computation and to interoperate between them.

Although our approach aims to meet common

health needs mainly using the IoT devices available

on the market, we should note that this aim is not

straightforward, since the available monitoring and

control devices at level L1 for healthcare purposes are

usually not able to exchange data directly between

them, often they work as stand-alone devices. Only

recently we may find BLE devices able to send the

collected data to processes at level L2 where the data

are stored and processed by a proper control system.

However, to process data coming from different

sensors and to send commands to different actuators

we need that such data are received and sent

according to a suitable format (i.e., according to an

agreed data semantics at control layer) and through a

proper communication protocol.

For this reason, in our implementation the data are

coded following the JSON format and are exchanged

through an MQTT broker that is connected to the

edge devices by the MQTT secured protocol, i.e., a

version of MQTT that makes use of TLS (Transport

Layer Security) encryption at the transport layer to

enhance data security. Although other data

communication protocols could be used for this

purpose we chosen MQTT, or its secured version, for

its simplicity and energy efficiency (Faro, 2020).

Also, to meet real time requirements it is suitable

that the MQTT broker will be directly linked to the

home automation system. Thus, we chosen Domoticz.

that it is easily linkable to the MQTT broker even if

other home automation systems can be used, such as

SmartThings

or Home Assistant

The data received by Domoticz may be stored into

internal files or into simple database such as Node-

Red

. Also, such data could be stored on a large data

storage (e.g., MySQL

) for further analysis.

In Domoticz the data sensed by a sensor on the

field are processed as if they were collected by a

virtual sensor associated to the real one. After

processing such data, Domoticz will send the

commands to the proper virtual actuator that on its

turn will send these commands through the MQTT

protocol as JSON messages to the real actuator.

In the proposed model, the customer processes

should manage different control system following a

shared format that allows the users to coordinate and

optimize the different control systems using the terms

of an agreed user ontology. This last aspect is outside

the scope of the paper. The interested reader may find

in (Costanzo, 2016) how customer processes could

interoperate according to an user ontology.

Fig.3 summarizes the software architecture that

implements the functional structure of CPSc. Besides

the modules at level L2 and L3 discussed before, this

software architecture allows us to point out at level

L1 the key component to obtain a pervasive

monitoring and control of the targeted applications,

i.e., the BLE/MQTT gateway. By this BLE/MQTT

gateway many BLE sensors or actuators not provided

natively with MQTT communication may exchange

messages with the automated control system through

the MQTT broker. By using this gateway we may

include in the monitoring and control system quite all

the BLE devices commonly available on the market.

Due to the relevance of this gateway in the CPSc

architecture, it will be described into details in sect.3.

Figure 3: From the layered functional model to the layered

software architecture for implementing CPSc.

Fig.3 points out that some systems may enter

directly into the MQTT broker, i.e.: a) the user

processes at level L3 to faster the visualization of the

sensed data and for managing the edge devices, and

b) the edge devices at level L1 with proper MQTT

functionalities.

PECCS 2020 - 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors

Since the use of edge devices provided with a

proper MQTT gateway simplifies the overall

architecture, in sect.3 we illustrate how implementing

DIY sensors provided with MQTT functionalities.

A solution partially similar to ours is given by the

recent project called Open MQTT gateway even if

this project (see http://docs.openmqttgateway.com/)

envisages autonomous Arduino based gateways that

need the knowledge of the format of the frames

containing the data sensed by the edge devices. This

is not needed in our approach neither by the devices

provided with an MQTT gateway shown in sect.3,

neither if one adopts the method illustrated in sect.4.

Finally, fig.3 points out at level L1, edge devices

able to interoperate between them without the help of

an external control service (see the line connecting

the sensor/actuator box with itself). This allows us to

point out the recent trend to move intelligence

towards the edge devices for improving real time

control and reducing the network load.

3 MQTT GATEWAYS FOR

M_CONNECTED

HEALTHCARE

To build a BLE /MQTT gateway useful for mobile

connected (M-Connected) healthcare, we can use

several types of chipsets. In our implementation we

chosen the Arduino

chipset since it has good

performance and low cost. In particular, we chosen

the ESP32 nodemcu chip (see fig.4left) since it allows

us to use in the same chip two antennas: a BLE

antenna to capture the data sent by BLE sensors on

the field and a WiFi antenna to send the sensed data

to internet through a WiFi channel. In the paper this

gateway is denoted by GW

Figure 4: ESP32 chips for implementing a BLE-WiFi

gateway on the left and a BLE/3G-4G gateway on the right.

Another interesting version of the MQTT

gateway is the one denoted as GW

(see fig.4right)

that includes the BLE, WiFi and 3G/4G

communication functions to allow the sensors to send

data to the data center even when the subject is

walking or driving using 3G/4G channels.

In the software of the gateway based on both the

above ESP32 chips, the BLE data are converted to

MQTT messages by a Lua script that is uploaded to

the ESP32 by means of the Arduino IDE. Such Lua

script combines three main sub-scripts:

 in GW

the first script scans the available WiFi

networks to connect the gateway to the one

prefixed by the user. It is inspired by the WiFi

scan script reported on the Arduino IDE.

Analogously in GW

the script connects the

device to the 3G/4G network as illustrated in

https://randomnerdtutorials.com/esp32sim800l-

publish-data-tocloud/

 the second script scans the BLE sensors to

connect the gateway to the one prefixed by the

user, and to extract the relevant BLE data. The

BLE scan is inspired by the script reported on

the examples of the Arduino IDE. The capture

of the data in the BLE frames depends on the

format adopted by the sensor. If it is not known,

then it is needed to investigate the format of the

frames, e.g., by using a BLE sniffer.

 the third converts the BLE data to MQTT

messages, and send them to the MQTT broker

through WiFi or 3G/4G connections.

The main advantages of using such gateways are

that they are easily portable either when the user is at

home or when he is engaged in mobile tasks. Also,

both these gateways may send the data to any control

center, not necessarily the one of the manufacturers,

where the data could be processed all together thus

allowing the virtual devices to interoperate between

them.

In this way the control center could take into

account all the relevant parameters sensed by the

available sensors and, after processing the received

data, it could send: effective commands to the

actuators installed on the field and warning messages

to the user processes to manage risky events.

Finally, let us note that these gateways are

autonomous micro-systems that are not implemented

on the smart phone, thus satisfying the privacy

constraints claimed by the users. i.e., by using such

gateways we avoid to use the smart phones as

gateways but we use them only as visualization

devices so solving the problem advanced in

(Zachariah, 2015) where the authors claimed that

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario

“Internet of Things has a Gateway Problem”. Indeed,

the available gateways on the market are often

software APPs implemented on the smart phones able

to collect data sensed on the field and conceived to

send such data through internet to a proprietary

control system where the data are stored and deeply

processed to discover dangerous events.

By the proposed gateway we may include in our

non-proprietary framework:

 all the devices that are able to transmit health data

to the smart phone but not to a remote data center,

e.g. the wrist device that measure blood pressure

and heart beat per minute produced by iHealth

, and the stress locator Bluetooth oximeter or the

emotional sensor from skin responses of Happy-

Electronics

 the devices managed by proprietary monitoring

and control center such as the smart bands of

Huawei or Xiaomi to measure many vital

parameters, except the body temperature, and the

BLE thermometer of Kinsa.

The proposed approach may be used also for the

networking of the items known as iBeacons, i.e., low

cost devices able to send BLE frames mainly for

informing about the indoor position (

Dalkılıç

, 2017)

but that are also used for sensing the parameters

featuring human health and production processes.

Therefore, in the paper we propose the use of

and GW

to allow BLE sensors to send the

collected data to any monitoring and control center in

the network chosen by the user.

To achieve the maximum of pervasiveness we

should take into account the IR devices not provided

with BLE communication facilities so that it is

possible also in this case to inform immediately the

control personnel or the same subject on the values of

the relevant parameters. However, since this needs

some hardware modifications of such sensors, it is for

further study.

Moreover, as said in the sect.2, the proposed

gateway is not needed for managing the sensing and

actuating edge devices provided with proper MQTT

communication functions. However, such sensors

should be designed carefully since they are acceptable

in our approach only if they send data to the control

center chosen by the user according to an agreed

format (Faro, 2020), e.g., the JSON format, to allow

the measured data to be managed together with the

data sensed by all the BLE devices connected to the

center through the MQTT gateway.

Moreover, using edge devices provided with

MQTT functions generally increases the costs but

improves the time performance. Therefore, their use

in practice should be evaluated by a cost-benefit

analysis considering that the advantage of using them

is not only the one of achieving better time

performance but also the possibility of pre-processing

the data collected for an immediate control. These

pre-computed data can be sent by these computational

edge devices to the data center chosen by the user

where they can be further processed together with the

ones coming from the low cost IoT devices.

Fig.5 shows some possible platforms to manage

the data collected by the sensors, i.e.:

 an MQTT APP resident on a smart phone to

visualize the data and to receive alerts,

 a Raspberry PI platform powered by Domoticz

and MQTT broker to monitor and control the

health data and related home appliances or mobile

systems. In particular, on this platform we may

install a simple home automation center able to

alert the users or family members in case of risky

events without needing the use of remote centers

installed at the family doctor or at the hospital.

 instead of Raspberry PI, one may use the NVIDIA

Jetson Nano or the NVIDIA Xavier boards

(Sparsh, 2019), where one may implement not

only conventional control procedures based on

threshold control but also advanced programs

taking advantage from the AI tools available on

such board, e.g. TensorFlow (Shukla, 2018) to

develop deep control of remote applications as

envisaged by the adopted CPSc model.

Figure 5: Functions, software modules and hardware

platforms to implement CPSc: data storage, visualization

and automated control services.

Fig.6 shows three main stacks to implement the

sensing tasks described in the paper:

 The sensors provided with TensorFlow Lite

(Tang, 2018), denoted in the paper as TFL, able

to classify on line the health data patterns

featuring the user health status. They are also

able to send the sensed data to the MQTT broker

PECCS 2020 - 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors

and to receive the updating of the weights of the

TFL model from TF resident on the server.

Typically such an edge node could be an

NVIDIA Jetson Nano (Cass, 2020).

 The sensors provided with MQTT

communication functionalities that don’t need

of the BLE/MQTT gateway proposed in the

paper. The collected data are sent through the

MQTT broker to Domoticz that will carry out

the due control on line. Typically such nodes

could be Sonoff

devices provided with an

operating system named Tasmota offering

MQTT facilities (Tasmota, 2016).

 The commonly used sensors provided with BLE

communication facilities that need the

BLE/MQTT gateway to send (receive) data

(commands) through the MQTT broker to

(from) Domoticz.

Figure 6: Functions, software modules and hardware

platforms to implement CPSc: sensors and actuators stacks.

Let us note that although the MQTT edge devices are

very effective to implement distributed intelligent

control systems to meet real time constraints and to

reduce the network load, they are still not largely

diffused not only because of their relatively high cost,

as said before, but also because the manufacturers aim

at developing monitoring and control systems in

which it is needed to use mainly their devices.

Thus, waiting for the availability of MQTT edge

devices at a reasonable cost, it is useful to follow the

approach proposed in the paper aiming at developing

MQTT gateways, as illustrated in sect.4, to give rise

to effective online health control system. This will

extend the MQTT sensors, currently used for

implement home automation processes (see module

in the center in fig.6) to perform healthcare tasks.

Fig.7 shows how the ESP32 provided with WiFi

functions can be used to develop an MQTT sensor. In

particular, it shows two sensing devices to measure

the body temperature: a wearable device based on

MAX

30205

on the right and an IR device based on

MLX 90614 on the left. The software to be installed

on the ESP32 to manage the sensed data coming from

these sensors according to the MQTT protocol may

be easily found on the Web.

Since the above DIY approach may require to use

more than one electronic piece by a soldered circuit,

it is not suitable for mass production. It may be

suitably adopted for developing prototypical or

dedicated systems consisting of a limited amount of

MQTT edge devices especially when these devices

consist of few parts, e.g., only of ESP32 and the

sensor.

Figure 7: WiFi body temperature sensor on the left based

on the IR sensor MLX 90614ESF BAA. This sensor should

be connected through the interface I2C, i.e., (from up to

down) VIN-3V3, GND-GND, SCL-G22, SDA-G21. The

sensor MAX30205 on the right should be interconnected to

ESP32 using the same rules.

4 MONITORING IN SEARCH OF

COVID: ALERT & FORECAST

Although several parameters may be useful to trace

COVID, we take particular attention on how to

measure online the main relevant parameters, i.e.,

body temperature and the oxygen in the blood.

In the following we discuss how to do it by using

the mentioned sensing devices to give an idea on how

these devices may be used in our framework and the

reliability of their measurements.

In particular, in this section we take into account

three smart bands, i.e. the Honor Band 5i by Huawei

(H5i), the one known as W11 and a low cost band

belonging to T01 type. Such wearable devices are

able to measure several relevant vital parameters,

among which the oxygen in the blood, whereas only

T01 is able to measure also the body temperature.

In our tests we taken into account also three types

of thermometers that may complement the basic

measurement apparatus needed for COVID, i.e., the

portable forehead thermometer by Kinsa, a similar IR

without MQTT

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario

low cost device known as IR laser gun, and the

wearable thermometer known as Smart Baby (SB)

that can be used for children and adults.

Due to the increasing diffusion of iBeacons, a low

cost iBeacon for measuring the body temperature is

considered too.

All the obtained results were compared with the

ones taken by certified medical devices. Also the use

of the mentioned DIY devices will be taken into

account.

Fig.8 illustrates how we may send the health data

sensed by W11 (see fig.8a) to an MQTT broker using

a portable MQTT gateway GW

discussed in

previous section.

Let us note that this task is not straightforward

because to know the health data to send to the MQTT

broker it is necessary to decode the BLE frames sent

from W11 to the APP resident on the smart phone.

This is relatively easy if the format of the BLE

frames is given by the manufacturers, otherwise this

should be obtained by using a BLE sniffer, e.g., the

Hollong sniffer and/or some APPs such as Light Blue

and BLE Analyzer. In fig.8 we illustrate the main

steps to be followed to discover the blood pressure

measurement in the BLE frame of W11, i.e.,

 first we inspected using the BLE sniffer the

frames sent by W11 to its APP during the blood

pressure measurement phase (see fig.8b),

 after inspecting such BLE frames we understood

that the hexadecimal digits of the frame related to

the blood pressure, are the ones pointed out in

fig.9, i.e.: Systolic blood pressure = 71 HX =113

mmHg, and Diastolic blood pressure = 4b HX =

75 mmHg.

 only at this point, the software loaded in the

gateway (fig.8c) is able to send the relevant data

to the MQTT broker where the data are read by

the MQTT clients resident on remote mobile and

on the Domoticz platform.

 this allows the blood pressure data to be

visualized on the MQTT client resident on the

mobile (fig.8d) and by the virtual Domoticz

device identified by idx=37 (fig.8e).

The same procedure used to send the data

collected by W11 on the blood pressure to the MQTT

broker was followed successfully to decode the BLE

frames containing health data measured not only by

W11 but also by the smart bands H5i and T01.

Since the above data don’t deal with body

temperature except for T01, we tested also the above

method to send to the MQTT broker the body

temperature measured by the main BLE

thermometers available on the market, e.g., Kinsa,

Smart Baby, iBeacons and the IR laser guns.

Figure 8: Visualization of the blood pressure taken by W11

on several user devices. Let us note that the blood pressures

shown on such devices refer to different proof sessions.

Figure 9: BLE frames sent by W11 during the blood

pressure measurement phase.

Although the proposed approach worked

successfully for all the mentioned devices, it is not

possible to say that it may be used for all the BLE

sensors. Indeed, as said above, this result might be

achieved if the manufacturers will make available the

format of the BLE frames sent by their devices to the

APP installed on the smart phone, otherwise the

possibility of sending data from a BLE device to the

MQTT broker should be verified experimentally case

by case. However, in the paper we have demonstrated

that our approach was successful at least for a set of

devices able to measure the main health parameters

relevant for COVID and to counteract other epidemic

pathologies, such as the seasonal influences.

To have a first evaluation of the precision of the

measurements mostly relevant for COVID, we

compared the measurements of the blood oxygen

saturation levels (in percentage) of a given user at a

certain time with the one taken by a certified medical

oximeter (MO) for the same person at the same time.

The results reported in tab.1 indicate that each

tested oximeter, except T01, shows a satisfactory

precision. Then several devices can be used with

confidence to monitor and control at distance the

oxygen in the blood using the proposed approach.

PECCS 2020 - 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors

Table 1: Blood oxygen saturation levels (in percentage)

measured by wrist bands compared with the one taken by a

certified medical device, i.e., MO.

H5i

W11

T01

An analogous test was done to verify the precision

of the body temperature taken by Kinsa, Smart Baby

(SB), T01, iBeacons and the DIY devices illustrated

in the previous section, i.e., the IR contactless sensor

MLX

96104BAA

and the contact sensor MAX

30205

The results shown in Tab.2 deal with the

temperatures of different parts of the body taken for

the same user at the same time. Also in this case we

found that all the IR and wrist thermometers available

on the market and the ones built by using relevant

body temperature sensors show a satisfactory

precision, except T01.

Table 2: Body temperatures in °C taken by different

thermometers for the same person at the same time.

Finger Wrist Hand Forehead

IR Kinsa (cert.) 36,5 34,6

IR MLX

96104BAA

36,2 35

IR LC 36,4 35,4

Smart Baby (cert.) 35,2

T01 36,5

iBeacons 35,4

MAX

30205

35,1

Then, there are many devices that can be used

with confidence for monitoring and controlling at

distance and online the body temperature according

to the proposed framework. Let us note that in our

approach the body temperature and oxygen in the

blood can be easily monitored also during the therapy

followed by the user at home or at hospital, e.g.,

fig.10 shows a simple Blockly program that can be

used by Domoticz to send warning messages to the

doctors when the patients are in the risky range.

Figure 10: Blockly program to send an alert when the body

temperature is higher than 37,5 °C.

A discussion on how the proposed approach may

be used to exchange messages between the devices

belonging to two different networks is given in

sect.4.1 to demonstrate how the patient control may

be carried out at distance from hospitals satisfying the

privacy requirements. In sect.4.2 we propose a simple

classification scheme of the available health

measurement devices to clarify the types of devices

that from our point of view are: a) few useful, b) of

limited importance, c) upgradable by using our

MQTT gateways and d) coherent with our requisites.

How our approach may be used not only to implement

an alert system but also to forecast the COVID

outbreaks and similar events is illustrated in sect.4.3.

4.1 Interconnecting Domoticz Systems

A meaningful advantage of using Domoticz is not

only the one to be linkable directly to MQTT or the

one to allows us an easy implementation of an

effective warning system, e.g., by means of Blockly

commands, but also the one that it may be

interconnected to another Domoticz system resident

on a network managed by another administrator.

Indeed, the device interconnection proposed in the

paper by using Domoticz may be obtained only if we

know the addressing scheme to implement data

exchange between sensors and actuators through the

MQTT broker. This may be achieved by knowing: a)

the MQTT names and the LAN addresses of the

relevant devices, and b) the LAN address and the

global address of the MQTT broker.

This means that by Domoticz it is possible to alert

users by email and SMS or to send commands to

actuators that are located on any LAN of the network

managed by the same broker, i.e., belonging to the

same administrative system. On the contrary, it is not

easy to interconnect devices belonging to different

administrative systems since this would require the

knowledge of the addressing scheme of the devices of

a network managed by a different administrator.

To overcome this problem we propose to adopt a

naming scheme rather than an addressing scheme.

This may be obtained in several ways, in the

following we illustrate how interconnecting the

Domoticz systems of the two networks through the

web service named IFTTT (Xianghang, 2017).

Indeed, IFTTT makes possible that a device or

system may execute commands expressed in the

format “IF This (event) Then That (action)” where the

event is detected by a device/system of a network A,

whereas the action could be carried out by a

device/system resident on the same network A or on

a different network B.

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario

Fig.11 shows how devices belonging to different

networks can cooperate following the IFTTT

procedure reported in www.domoticz.com/wiki/

IFTTT_integration_with_Domoticz. In particular it

points out how a Blockly command executed on a

Domoticz system located at a retirement home A may

be used for triggering an action of a device managed

by a Domoticz system located at hospital B when the

data sensed by some sensors at a retirement home are

in the risky range:

IF body temperature of people X at A > 37,5

& oxygen saturation of people X at A < 90

THEN doorbell_D1 at B = ON

where the body temperature is taken by sensor T1 and

the oxygen in the blood is detected by sensor O1.

Figure 11: By interconnecting two Domoticz systems by

IFTTT, events detected by sensors located in network A

(i.e., T1 and O1) activate actions to be carried out by a

device resident in network B (i.e. D1).

Let us note that the IFTTT approach is generally

not suitable to manage a private network for

flexibility and security reasons, whereas it is suitable

to trigger specific actions in a network managed by a

Domoticz system after the occurrence of a given

event in the network managed by another Domoticz

system since this is obtained by a naming scheme

transparent to IFTTT.

This allows a hospital to make available on the

global network only the devices that are really needed

by remote patients, and vice-versa it allows patients

to make available to a remote hospital only the home

devices that are useful to monitor/control their

pathology from distance.

4.2 Comparing Our

Monitoring/Control Approach with

Respect to Others

Previous sections let to emerge by examples and

small case studies that the main point of our approach

for an effective monitoring and control of COVID

outbreaks is that the measurements of the relevant

parameters, e.g., body temperature and oxygen in the

blood, should be collected through MQTT protocol in

real time into servers at disposal of the sanitary

system not only when such parameters are beside the

threshold but also when they are in the normal range

for statistics studies.

Also, these measurements should be: a) sent by

the edge devices to the servers without using smart

phones mainly for privacy reasons, and b) taken by

contact devices if they are used by only one person,

whereas contactless technologies should be used to

monitor several people, e.g. at a store or school

entrance.

To better elucidate our point of view about the

main features of an effective monitoring and control

system for detecting possible COVID outbreaks we

use in this section the following two dimensions

scheme for classifying the available edge devices:

a) how data are collected by the sensors

1. contact devices

2. contactless devices

b) how the data are stored for further processing

1. no data storage

2. data storage on

i. Scan Disk (SD)

ii. smart phones

iii. proprietary systems

iv. user servers (*)

(*) The dimension b.2.iv includes servers

installed on the user PCs and the one at family

doctor or at hospitals authorized by the users.

This classification scheme allows us to point out

that with respect to our point of view:

• the devices that belong to b.1.i or to b.2.i,

independently on if they are contact or

contactless, are of limited importance since they

don’t support online control from distance and

generally don’t contribute to build statistics for

COVID forecast as envisaged in sect.4.3. In other

words, their use is meant only for controlling that

people entering into a public service are in the

normal condition under the only responsibility of

the operator taking the measurement.

PECCS 2020 - 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors

• the devices that belong to a.1.ii or a.2.ii are

acceptable only if they are for personal use and

don’t to send data to distant servers through

smart phones since using smart phones as

gateways should be avoided at least to meet

privacy conditions.

• the devices that belong to a.1.iii or b.2.iii are not

acceptable since sensible data should not be

stored on the servers of the service providers.

• the devices that belong to a.1.iv or b.2.iv are the

ones that best meet our approach at condition that

the ones belonging to a.1.iv are for personal use.

These considerations clarify why we claim that

our MQTT gateway installed on a portable IoT

devices may improve the devices available on the

market, often provided with BLE interface, by

allowing them to send the sensed data to user servers.

In particular, the proposed gateway could be used

to allow the following devices to provide the

envisaged online control service even if they were not

conceived natively for this purpose:

• the BLE smart/wrist bands and iBeacons used to

measure relevant health parameters by an APP

on a smart phone, and

• the BLE contactless control systems, e.g. the IR

body temperature laser guns that take the body

temperature for controlling people at the entrance

of a public service.

Also, from the above scheme it is easy to

understand why we encourage solutions that meet

natively the requirements a.1.iv and a.2.iv, i.e.,

solutions in which the gateway is implemented in the

sensor/actuator itself as the DIY projects in fig.7.

Finally, we note that recently there are on the

market IR cameras for fever screening belonging to

b.2.i that may partially fit our approach, i.e., the IP

binocular cameras provided with thermal array

sensors. Indeed, in such cameras the thermal and

optical data can be visualized by any device

connected to Internet (see fig.12) but they are usually

stored on a local SD. Thus, an MQTT client should

be installed on such cameras so that the data will be

available online on the servers indicated by the users

for the relevant processing.

However, the lack of such feature is partially

overcome in this case by the fact that when these

cameras detect undesired events, they are able to

activate some relevant actions such as

opening/closing the entrance door of a store and

alerting distant control people.

Fig.12 deals with such a thermal IP camera able

to control the facial temperature of a people at a

certain distance from it (about 200 cm). Other IP

cameras provided with simpler IR sensors are able to

trigger actions depending not only on the facial

temperature but also on the people identity even if

they need that people passes closer to the camera

(about 50 cm). In both the mentioned cameras, the

data stored on SD can be used later for statistical

processing.

Figure 12: The optical and infrared images taken by IP

cameras provided with an array thermal sensor for fever

available to any PC on Internet. Many walking people can

be controlled contemporaneously. People with fever or

without mask are signalled to the control personnel and are

not allowed to enter into the controlled service.

4.3 Timely Discovering the Incipience

of a COVID Outbreak

The users could authorize Domoticz to send the

collected data to hospitals or clinical laboratories for

Optical

image

obscured for

privacy

reasons

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario

a deep control of the health situation. The number of

people affected by suspicious pathologies related to

COVID could be reported in a map to point out

unusual levels of community spread of illness over

the past several weeks as proposed on the site Health

Weather powered by Kinsa.

Another approach may be the one of sending the

data on the body temperature and on the oxygen in the

blood to a control center even if they are not outside

the normal thresholds, but also when they are quite

normal but different from the ones typically owned

by the user.

A procedure to timely discover anomalies

indicative of the incipience of a COVID outbreak

may be implemented on a control center at the

hospital or at a clinical laboratory using a

classification approach similar to the one proposed in

(Faro, 2009), i.e.:

• measure daily the health parameters h

relevant for

COVID (such as body temperature, oxygen in the

blood, heart beat per minute, diastolic and systolic

pressure, breathing per minute). Let say N the

number of health variables taken into account, and

let us assume that the subject is every day in three

main contexts: resting at home, working (at home,

in the office , etc.), and commuting.

• represent the daily health status as a point in a N-

dimensions space whose components are p

m,k

]

…. p

m,k

], where m from 1 to 3 denotes the

context and k from 1 to 30 is the day number in

the last thirty days, e.g., 1 is the current day and 7

refers to seven days ago.

• built the similarity array S whose generic element

s(d, k) represents the similarity s(p

m,d

, p

m,k

) of the

health status at day d with health status at day k

for a given context m according to the metrics

proposed in in (Faro, 2009).

• pass each row of the array S to a SOM neural net

(Kohonen, 2013) having N input neurons and

three output neurons to allow us to classify the

daily status in three main classes, i.e. normal,

abnormal and suspicious.

• alert the user if his current health status is risky

since he is passing from normal to abnormal status

and communicate to a control center every

suspicious daily health status and how much it is

distant from the abnormal one.

In this way, a control center may alert the users

and compute two maps to study the COVID diffusion

at macroscopic level, besides the public map dealing

with the people affected by COVID. The suggested

maps should be: I) the map proposed by Kinsa, and

ii) the map showing the emerging anomalies at micro-

community level as proposed in this paper. Both these

maps could be indicative of the incipient COVID.

Currently, we are evaluating if a better

classification could be obtained using the

autoencoding neural network available in

TensorFlow instead of SOM. By this choice we plan

also to implement an online control of the suspected

events at the user side. Indeed, after the learning

phase needed to compute the weights of the neural

autoencoder at the server side, we may use the

autoencoder TensorFlow Lite (TFL) installed on the

edge nodes, e.g., the NVIDIA Jetson Nano, to

discover timely anomalies during the testing phase

carried out on the edge nodes. Such nodes should

send the sensed data also to the main control center,

e.g., the one installed on the NVIDIA Jetson Xavier,

to be used to update the weights of the mentioned

autoencoder.

This would avoid to signal emerging anomalies

when the health data of an user differ from the ones

of the other users. Indeed, anomalies will be signalled

only when the health data of an user differ from the

ones usually featuring the same user in other days but

in the same context.

5 CONCLUSIONS

The paper aims at contributing to the development of

a pervasive health monitoring and control system not

only for COVID but also for risky pathology of social

relevance. In particular the paper has demonstrated

how all the IoT sensors and actuators provided with

BLE communication facilities may be included in a

distributed intelligent system to discover timely if a

people is affected by COVID or to identify, by means

of suitable AI methods, the infections areas so that

they may be suitably controlled. The methodology

proposed and the technologies suggested could be

adapted to control other epidemic events.

Like other proposed ICT tools to counteract

COVID, the proposed approach should be

implemented in a pervasive way to effectively reach

the prefixed aims. However, unlike many other

proposals, the monitoring and control outlined in the

paper remains anonymous and does not involve

critical personal systems such as smart phones

without decreasing the effectiveness of the results at

least to discover the incipience of COVID in small

communities or city districts. Of course timely

diagnostics at micro-community or personal level can

be carried out only with the consensus of the

interested people.

PECCS 2020 - 10th International Conference on Pervasive and Parallel Computing, Communication and Sensors

Future works deal with:

 a systematic comparison of the proposed

approach with the existing ones by using more

than the two dimensions chosen in the paper,

 the development of a contactless sensor for

measuring the oxygen in the blood by taking

into account relevant methods presented in the

literature, e.g., (Liu, 215) and (Negishi, 2020),

 the implementation of a data protocol for

interconnecting devices of different networks

not only by means of IFTTT at Domoticz level,

but also through platforms, e.g., Beebotte

(Beebotte, 2017), that are able to interconnect

different MQTT brokers,

 the development of deep learning tools based on

the ones described in the paper to obtain a timely

diagnosis of COVID and a reliable forecast for

the epidemy diffusion.

ACKNOWLEDGEMENTS

The methodology and the outlined technologies,

especially the DIY ones, are currently under test in a

project called I-HOSP to assist patients affected by

risky pathology at distance, supported by EC regional

funds in the action 1.1.5 aiming at promoting

innovative projects dealing with key themes of the

socio-economic development such as industry 4.0

and mobile-connected healthcare. Although the

COVID monitoring is not in the main project aims,

the proposed approach is also under test in another

project of the same action called SELCA dealing with

advanced clinical LIMSs (Laboratory Information

Management Systems).

REFERENCES

Beebotte, May 2017, [online] https://beebotte.com

Cass S., 2020, Nvidia makes it easy to embed AI: The

Jetson nano packs a lot of machine-learning power into

DIY projects, IEEE Spectrum Vol. 57

Costanzo A., Faro A., Giordano D., Spampinato C., 2016,

An ontological ubiquitous city information platform

provided with Cyber-Physical-Social-Systems, IEEE

Annual Consumer Communications & Networking

Conference (CCNC). p. 137-144, Las Vegas, USA

Dalkılıç et al., 2017, An Analysis of the Positioning

Accuracy of iBeacon Technology, Indoor

Environments, In International Conference on

Computer Science and Engineering (UBMK’17),

Antalya, Turkey

Domoticz, 2015, Open Source Home Automation System,

https://www.domoticz.com/DomoticzManual.pdf

Faro A., Giordano D., Maiorana F., C. Spampinato, 2009

Discovering Genes-Diseases Associations From

Specialized Literature Using the Grid, 2009, IEEE

Transactions on Information Technology in

Biomedicine, vol. 13, no. 4, pp. 554-560

Faro A., Giordano D., Venticinque M., 2020, Deploying

WiFi, RF and BE sensors for pervasive monitoring and

control, IEEE Conf. on Metrology for Industry 4.0,

Rome, Italy

Gill, H., 2006, NSF perspective and status on cyber–

physical systems, NSF Workshop on Cyber–physical

Systems, National Science Foundation, Austin, USA

Home assistant, 2018, Open source home automation

software based on Python, https://www.home-

assistant.io

Kohonen T., 2013 Essentials of the self-organizing map,

Vol.37, Neural Networks, Elsevier

Liu H., Ivanov K., Wang Y., Wang L., 2015 A novel

method based on two cameras for accurate estimation

of arterial oxygen saturation. BioMed. Eng. 14, 52

Negishi T., et al. 2020 Contactless Vital Signs Measure-

ment System Using RGB-Thermal Image, Sensors and

Its Clinical Screening Test on Patients with Seasonal

Influenza, Sensors, April.

Shukla N., 2018, Machine Learning with TensorFlow.

Manning Publications Co. ISBN:978-1-61729-387-0

Sparsh M., 2019, A Survey on optimized implementation

of deep learning models on the NVIDIA Jetson

platform. In Journal of Systems Architecture Vol.97,

pages 428-442, August.

Stanford-Clark A., Truong H.L., 2013, MQTT For Sensor

Networks, https://mqtt.org/new/wp-content/uploads/

2009 /06/MQTT-SN_spec_v1.2.pdf

Tang J., 2018, Intelligent mobile projects with TensorFlow,

Packt Publishing Ltd, UK, 2018 978-178883-454-4

Tasmota, 2016, Open source firmware for ESP8266

devices, https://tasmota. github.io/docs/About/

Xianghang M., et al., 2017 An empirical characterization of

IFTTT: ecosystem, usage, and performance, Conf.

(IMC), London, UK

Zachariah T., Klugman N., Dutta P., 2015 The Internet of

Things Has a Gateway Problem, Proceedings of the

16th International Workshop on Mobile Computing

Systems and Applications, pages 27–32, Santa Fe, USA

ESP32 based Edge Devices to Bridge Smart Devices to MQTT Broker for Healthcare Purposes in the COVID Scenario