Introduction

Nowadays, smart systems have invaded our daily lives with a plethora of devices, mainly from consumer electronics, like smartwatches, smartphones, digital assistants, and domestic appliances with intelligent capabilities to autonomously drive modern homes. These are generally based on wireless protocols, like WiFi, Bluetooth Low Energy (BLE) and ZigBee, low-cost sensing components, including Passive InfraRed (PIR), Radio-Frequency Identification (RFID)-based technologies, and several other types of environmental sensors. These devices communicate with each other without the need for human intervention, thus contributing to the implementation of the Internet of Things (IoT) paradigm [1]. Their number is continuously increasing, and their versatility enables several opportunities for different scenarios, ranging from simple environmental monitoring solutions to more complex autonomous control systems, in both private life (i.e., at home) and public contexts (i.e., social and working environments). Without claiming to be exhaustive, examples of applications can be found in healthcare [2, 3] and elderly assistance [4, 5], in smart building for Human Activity Recognition (HAR) [6], and energy management [7, 8], as well as in smart industries [9], smart cities [10], and the recognition of environmental context [15, 16]. The concept of home, indeed, includes different connotations, and according to [17], it is characterized as a place for (a) security and control, (b) activity, (c) relationships and continuity, and (d) identity and values. Thus, to guarantee and promote these peculiarities, the design of a smart home cannot ignore the need of implementing the capability of recognizing human activities through HAR systems to provide real-time information about people’s behaviors. HAR algorithms are based on pattern recognition models fed with data perceived by on-body sensors, environmental sensors, and daily-life smart devices [16, 18]. The recognized activities can vary from simple walking to recognizing compound activities such as cooking, cleaning, or watching TV [18]. These algorithms, together with smart devices, represent the foundation for implementing and integrating intelligent systems, which autonomously take decisions and support life activities in our homes.

The literature concerning smart home platforms is extremely vast and differentiated, which makes it impossible to summarize them exhaustively. Concentrating on the academic research domain, among the most known and cheapest solutions, we can cite the CASAS platform proposed in [19]. It integrates several ZigBee-based sensors for door, light, motion, and temperature monitoring at a total cost of $2,765. Based on the data collected by the platform, the authors were able to recognize ten different Activities of Daily Life (ADLs) executed by the environment occupants achieving, on average, approximately 60% accuracy.

Similarly, in [20], the authors proposed a HAR model, fed with data collected through a smart home platform based on motion, door, temperature, light, water, and bummer sensors, to classify more than ten ADLs, achieving approximately 55% accuracy.

In [21], a study is presented where the authors installed a sensor network composed of motion sensors, video cameras, and a bed sensor that measures sleep restlessness, pulse, and breathing levels, in 17 flats of an aged eldercare facility. They gathered data for 15 months on average (ranging from 3 months to 3 years). The collected information was used to prevent and detect falls and recognize ADLs by identifying anomalous patterns.

In [22], the authors used an application to continually record raw data from a mobile device by exploiting the microphone, WiFi scan module, device heading orientation, light proximity, step detector, accelerometer, gyroscope, magnetometer, and other built-in sensors. Then, time-series sensor fusion and techniques such as audio processing, WiFi indoor positioning, and proximity sensing localization were used to determine ADLs with high accuracy.

Moreover, when develo** a strategy to deploy technology for discreet in-home health monitoring, several questions arise concerning, for example, the types of sensors that should be used, their location, and the kind of data that should be collected. In [23], the authors intensely studied such issues, pointing out that no clear answer can be identified. Still, the perceived data must be accurately evaluated to provide insights into such questions.

Recently, relevant pilot projects, such as HomeSense [24, 25], have been developed and presented to demonstrate seniors’ benefits and adherence response to the designed smart home architecture. HomeSense exposes the visualization of activity trends over time, periodic reporting for case management, custom real-time notifications for abnormal events, and advanced health status analytics. HomeSense includes magnetic contact, passive infrared motion, energy, pressure, water, and environmental sensors.

However, all these innovative systems and applications frequently present disadvantages in terms of accessibility and applicability. In several cases, they are based on ad hoc and costly devices (e.g., cameras) which are not accessible to everyone. In fact, as discussed in [26], among 844 revised scientific contributions, the system cost is the principal reason for the failure of projects concerning the design of smart health/home systems.

Some projects targeting the definition of low-cost solutions have also been proposed, but they are generally devoted to monitoring or recognizing single activities and/or specific use-case scenarios, thus lacking generality, or requiring the final users to install several non-inter-operable solutions in their homes [26]. For example, in [27] a set of very low-cost projects focusing on solutions for hel** visually impaired people are presented. Nevertheless, as has been extensively discussed in the recent literature [28,29,30,31], less effort has been spent in designing solutions that use low-cost Objects of Daily Life (ODLs) to monitor and recognize people’s activity in general.

Table 1 presents an overview of similar research-oriented smart home architectures, advantages, disadvantages, and comparisons with SHPIA 2.0.

Table 1 Existing similar architectures
Full size table

Furthermore, the existing smart home environments require annotating the collected data based on the video registration of the environment for training the pattern recognition algorithms, which is of central importance for the implementation of efficient HAR algorithms. Unfortunately, the annotation process is generally a very time-consuming manual activity, while only a few prototypical automatic approaches are currently available in the literature [34, 35].

On the other side, commercial smart home platforms like Google Home, Google Nest, Samsung Smart Home, and Amazon Home offer convenience and connectivity but come with certain limitations, particularly concerning the needs of researchers:

  • Interoperability: A major limitation is the lack of compatibility with devices from different brands. These platforms tend to prioritize their own proprietary products, making it difficult for users to integrate devices from other manufacturers.

  • Restrictions: Commercial platforms may have limited customization options, restricting users from fully tailoring their smart home setups to suit their specific requirements.

  • Privacy and security concerns: There are concerns about data privacy and security, as these platforms collect and store user data in known data centers (cloud), potentially exposing users to privacy risks.

  • Cost: The economic cost can be significant, as users and researchers may need to invest in specific branded devices or subscriptions to access the full range of features and functionalities.

  • Accessibility: Data accessibility problems can arise due to data being locked behind proprietary systems, restricted by privacy regulations, stored in complex or incompatible formats, or limited by inadequate infrastructure or technology. Ensuring proper data accessibility is crucial for researchers, businesses, and individuals to make informed decisions and leverage data for various purposes effectively.

Paper Contribution: According to the previous considerations and the limitation of existing solutions, this paper presents SHPIA 2.0, an easily scalable, low-cost, multi-purpose smart home platform for intelligent applications. It is based on the use of low-cost BLE-based devices, which make daily objects smart. These devices allow collecting and automatically labeling of different types of data to provide intelligent services in smart homes. By exploiting these devices, SHPIA 2.0 flexibly collects and annotates data representing the interaction between humans and the environment they live in, and hence the related behaviors. These datasets represent the first step to develop and train HAR-based systems which can be exploited in intelligent applications for several indoor monitoring and coaching scenarios. SHPIA 2.0 can be set up with less than \(\$ 200\) and operates in a ubiquitous and not invasive manner (i.e., no camera is required). SHPIA’s software is available to the scientific community through a public GitHub repository [36].

Scope of SHPIA 2.0: SHPIA is not intended as a commercial system. Instead, it is primarily designed for researchers and utilization in research activities. Unlike commercial platforms, SHPIA provides researchers, enthusiasts, and developers with an accessible alternative that encourages collaboration, customization, and innovation. Its open-source nature fosters a community of users who can leverage SHPIA’s capabilities to explore novel applications, experiment with new protocols, and contribute to the advancement of the smart home domain. Additionally, SHPIA’s affordability makes it an attractive option for users who may not have the financial resources to invest in expensive commercial solutions. By reducing barriers to entry, SHPIA enables a broader user base to actively participate in smart home research and development.

SHPIA vs. SHPIA 2.0: This paper extends our recent conference paper “SHPIA: A Low-Cost Multi-purpose Smart Home Platform for Intelligent Applications [37]". The conference paper supports only one specific type of sensor (i.e., Thingy 52) communicating with the data collector node (i.e., Android smartphone) through BLE connected mode, thus limiting the number of sensors simultaneously linked to the data collector node to 11. Instead, SHPIA 2.0 implements the following new features:

  • Supports both BLE connected and BLE broadcast network topology;

  • Besides Nordic Thingy 52 devices, it supports a wide variety of BLE beacon devices such as, Estimote Stickers, Estimote Locators, Global Tag, and Smartphone BLE simulators;

  • Supports iBeacon and Eddystone broadcasting protocols;

  • More than 11 (i.e., hundred) nodes can be simultaneously used;

  • Enables the simultaneous transmission of both inertial and environmental data.

Paper Organization: The rest of the paper is organized as follows. Section “Preliminaries” introduces preliminary information concerning the devices and the communication protocols used in SHPIA 2.0. Section “SHPIA 2.0 architecture” details the SHPIA 2.0 architecture and describes how it enables data collection and labeling. Section “SHPIA evaluation” showcases and discusses the experimental results and application scenarios. Finally, Section “Conclusions and Future Works” concludes the paper with final remarks.

Preliminaries

SHPIA 2.0 supports two types of BLE devices (aka., SHPIA nodes): a) the Nordic Thingy 52 supporting the BLE connected mode, and BLE beacons supporting the BLE broadcast mode, shown in Fig. 2. Such devices are highly versatile and present a complete set of characteristics, summarized below in this section. However, these devices can be easily replaced, without affecting SHPIA functionalities, with many other BLE-based units available on the market, provided that they allow the collection of similar data through their sensors.

Fig. 2
figure 2

SHPIA 2.0 supported devices: BLE beacons (i.e., estimote locator, estimote sticker, and global tag) and the nordic thingy 52 sensor kit

Full size image

Nordic Thingy 52

The Nordic Thingy 52 is a compact, power-optimized, multi-sensor device designed for collecting data of various type based on the nRF52832 System on Chip (SoC), built over a 32-bit ARM CortexTM-M4F CPU. The nRF52832 is fully multiprotocol, capable of supporting Bluetooth 5, Bluetooth mesh, BLE, Thread, Zigbee, 802.15.4, ANT, and 2.4 GHz proprietary stacks. Furthermore, the nRF52832 uses a sophisticated on-chip adaptive power management system achieving exceptionally low energy consumption. This device integrates two types of sensors: (i) environmental and (ii) inertial. Environmental concern temperature, humidity, air pressure, light intensity, and air quality sensors (i.e., \(CO_2\) level). Instead, inertial concerns accelerometer, gyroscope, and compass sensors. Besides the data directly measured by the integrated sensors, the Thingy computes over the edge the following information: quaternion, rotation matrix, pitch, roll, yaw, and step counter. Concerning the communication capabilities, Thingy 52 instantiates a two-side BLE communication with the data aggregator device, unlike BLE beacons. Unfortunately, this limits the number of simultaneously connected devices on the data aggregator side, thus reducing the architecture’s scalability. For example in Android v11, there can be connected simultaneously up to 11 Thingy nodes.

The communication between Thingy 52 and the data aggregator occurs at a frequency that goes from 0.1 Hz to 133 Hz, making SHPIA adaptable to applications scenarios were high sampling frequencies are required. Moreover, since the BLE provides the possibility to send more than just one value into every single transmitted package, the sensor’s sampling frequency is not limited to 133 Hz (i.e., the maximal frequency of the BLE communication), but it enables the sensor to sample at higher frequencies (e.g., 200 Hz).

BLE Beacons

BLE beacons, introduced in 2011 with the introduction of the iBeacon protocol by Apple, are low-cost and reduced size devices that broadcast their identifier to nearby BLE receivers, an overview of such devices is reported in Fig. 2. They enable smartphones, tablets, and other devices to perform specific actions based on the broadcasted data. Besides advertising, beacons can transmit data perceived by built-in sensors, such as temperature, pressure, acceleration, or brightness. Since there is not a established connection, the data aggregator device (aka., BLE receiver) can perceive the data frames broadcasted from more than 100 beaconsFootnote 1. Thus, such technology is highly scalable and reduces constraints related to the maximal number of beacons deployable into the environment.

SHPIA 2.0 makes use of three types of BLE beacon devices. Estimote beaconsFootnote 2, in particular the Estimote locator and Estimote sticker beacons, and Global Tag beaconsFootnote 3, communicating through iBeacon, and Eddystone protocols. Finally, BLE beacons present a significantly extended battery life, ranging from 6 months to 5 years, depending on the battery size, device transmission power, and advertising frequency. This is due to the advertising frequency going from 1 frame emitted every 10 seconds (i.e., 0.1 Hz) to 10 frames emitted each second (i.e., 10 Hz) [38]. Furthermore, SHPIA 2.0 can integrate any other type of beacons implementing the iBeacon/Eddystone advertising Protocol Data Unit (PDU) shown in Fig. 3.

Fig. 3
figure 3

Advertising PDU of a iBeacon and b eddystone [38]

Full size image

BLE Network Topologies

One of the main characteristics of BLE communication technology concerns the capability to enable communication among most of the existing IoT devices available nowadays. BLE technology is supported by almost every modern platform, such as iOS, Android, Windows, Linux, or standalone devices like Beacons or Single Board Computers (SBC), regardless of the constraints these devices have to endure.

In particular, the BLE protocol has been designed with a special focus on reduced battery consumption and scalability. This is made possible, thanks to the support of three different network topologies: (a) broadcast, (b) connected, and (c) mixed. SHPIA architecture enables both connected and broadcast topologies. Moreover, BLE supports the utilization of two types of devices: (a) peripheral and (b) central, defined as follows:

  • Peripheral devices are small, low-power, resource-constrained devices (e.g., BLE beacons, Thingy 52, heart rate monitors, or proximity tags) that can connect to a much more powerful central device.

  • Central devices usually present higher processing and memory capabilities (e.g., smartphones, computers, SBC, or tablets).

Figure 4 presents an overview of the BLE network topologies and the involved type of devices.

Fig. 4
figure 4

Bluetooth low energy (BLE) network topologies

Full size image

SHPIA supports both broadcast and connected BLE topologies (i.e., mixed topolgy). When working on broadcast topology, the SHPIA data collection node (i.e., smartphone) behaves as the observer device, and the BLE beacons (shown in Section "BLE Beacons") behave as the BLE broadcaster device. The latter broadcast a BLE data packet at a defined sampling rate that is received by all the BLE observer devices in the range of action; no pear-to-pear connection is used. Instead, when working on connected topology, the SHPIA data collection node (i.e., smartphone) behaves as a central device and instantiates a connection toward one or more peripheral devices (i.e., Thingy 52 SHPIA nodes).

Table 2 presents an overview on the main advantages and disadvantages of the described BLE network topologies.

Table 2 Advantages and disadvantages of the different BLE network topologies
Full size table

Performance Measurements

The performance of the different pattern recognition and regression models trained over the data collected by the SHPIA platform are measured in terms of Specificity, Sensitivity, Precision, and Accuracy, concerning the pattern recognition models, and Root Mean Square Error (RMSE) and Mean Absolute Error (MAE) concerning the regression models [39]. Such metrics are defined as follows:

$${\text{Specificity}} = \frac{{tn}}{{tn + fp}},$$
(1)
$${\text{Sensitivity}} = \frac{{tp}}{{tp + fn}},$$
(2)
$${\text{Precision}} = \frac{{tp}}{{tp + fp}},$$
(3)
$${\text{Accuracy}} = \frac{{tp + tn}}{{tp + tn + fp + fn}},$$
(4)
$${\text{RMSE}} = \sqrt {\sum\limits_{{i = 1}}^{n} {(x_{i} - y_{i} )^{2} } } ,$$
(5)
$${\text{MAE}} = \sum\limits_{{i = 1}}^{n} | x_{i} - y_{i} |.$$
(6)

Here, tp represents the number of true positives, tn represents the number of true negatives, fn represents the number of false negatives, fp the number of false positives, \(x_i\) the ground truth value, \(y_i\) predicted value, and n number of samples in the dataset.

SHPIA 2.0 Architecture

This section introduces the core of the SHPIA 2.0 architecture, which is shown in Fig. 5. In particular, it describes the principal agents composing its architecture, and how a smart home environment can be defined and configured for enabling data collection. From now on, we refer to SHPIA 2.0 as SHPIA, and to the BLE beacons and Thingy 52 devices as SHPIA nodes.

Fig. 5
figure 5

Schematic view of the SHPIA 2.0 architecture

Full size image

Agents

The agents involved in the SHPIA architecture are classified as abstract agents and real agents. The abstract agents are necessary to analyze the status of the environment (in terms of included objects and environmental conditions) and the status of people living in it (in terms of presence, number, movements, and accomplished actions). On the other side, real agents are represented by the people occupying the environment, their smartphones, and the SHPIA nodes. SHPIA enables communication capabilities among real agents as described below in the paper.

Fig. 6
figure 6

SHPIA 2.0 Android mobile application. a authentication page, b environments page, c sub-environment page, d sensor in sub-environments, e and f real-time data visualization, and g settings page

Full size image

Environment Definition

Concerning the home environment, SHPIA defines it as a set composed of the home itself, people inside it, and available ODLs. In particular, ODLs enclose mobile objects (bottles, pills container, keys, etc.) and motionless objects (e.g., doors, desks, coffee machine, etc.) present inside the environment, as those shown in Fig. 5.

Therefore, given a set of mobile ODLs (M) and a set of motionless ODLs (Ml), the environment (E) is formally defined as:

$$\begin{aligned}&E=\{\{M \cup Ml\},f_s ,f_l, T, D\}, \text {with}\\&f_s:M \longrightarrow T,\\&f_l:Ml\longrightarrow T, \end{aligned}$$

where T is a set of SHPIA nodes, D is a data aggregator node, while \(f_s\) and \(f_l\) are functions that associate, respectively, a SHPIA node with each mobile (M) and motionless (Ml) ODL. The data aggregator D identifies the device that collects the data perceived by the SHPIA nodes, behaving as a gateway toward a Cloud database. SHPIA uses an Android-based smartphone as data aggregator.

Environment Configuration

To handle the definition of the environment, we designed the Android application shown in Fig. 6. It allows the users to create one or more environments and associate a SHPIA node to each ODL of interest. In addition, this application allows real-time visualization of the perceived data and enables the smartphone to operate as the data aggregator.

Figure 7 presents the steps that the user has to perform to configure the smart environment by means of the mobile application.

Fig. 7
figure 7

SHPIA environmental configuration work-flow

Full size image

User Account Creation

In this first step, the SHPIA application allows, if not already existing, the creation of a user profile to associate the collected data. Once the user is verified, she/he can set the IP address of a Cloud-based NoSQL database from the setting page, to which the data will be transmitted. We want to emphasize that the transmitted data can be saved at any NoSQL database deployed on such IP. Users, for analysis purposes, need only to know the format that the SHPIA mobile application uses to save the data. Listing 1.1 provides an overview of the user account data structure in SHPIA.

figure a

Create Environment

Once authenticated, the user can create one or more environments, as introduced in Section "Environment Definition", by defining its name (i.e., env_id) and geographical address (i.e., address). Alternatively, if the environment already exists, the user can share it with other SHPIA users (Button Join Ambient in Fig. 6 a). Listing 1.2 provides an overview of the environment data structure in SHPIA.

figure b

Create Sub-environment

SHPIA users can create as many environments as needed, and an environment is typically composed of other sub-environments, as showed in Fig. 6c. For example, an apartment consists of a lounge, a kitchen, two bedrooms, and two bathrooms. SHPIA does not present any limit in the depth of nested sub-environments (i.e., it can configure sub-environments of a sub-environment of \(\dots\) of an environment). This specific feature has been developed by considering the possibility of adopting SHPIA also in industrial, scholastic, or smart city scenarios. Moreover, SHPIA can also be used for not environmental-related contexts. For example, the users can adopt it for implementing a wireless body area network by associating the SHPIA nodes to body parts instead of environments or ODLs, as in [40]. Overall, environments and sub-environments are described as shown in the example of Listing 1.2. Besides, env_id and address, the environments and sub-environments are identified by owner, creation_time, list of sub_environments and a brief description.

Select Node Types

Once the environments and sub-environments have been created, the user can select the type of SHPIA nodes she/he wants to use. This enables SHPIA to operate only with nodes communicating through BLE connected mode (i.e., Nordic Thingy 52), only nodes communicating through BLE broadcast mode (i.e., BLE beacons), or both types of nodes as depicted in Fig. 6d.

Create Smart ODLs

Once the environment has been created and the types of nodes decided, the user can finally attach a SHPIA node to each mobile or motionless ODL of interest, transforming it into a smart ODL. At this point, the user is required to move his/her smartphone close (< 10 cm) to the ODL equipped with the SHPIA node to allow SHPIA to recognize it. SHPIA automatically associates the nearest SHPIA node by exploiting the Received Signal Strength Indicator (RSSI) measurement (Fig. 6d). RSSI, often used in Radio Frequency (RF)–based communication systems, indicates the power level at which the data frames are received. The higher the RSSI value, the stronger the signal and the closer the receiver and the emitter are. The RSSI is used to reduce possible wrong associations in the presence of a high number of BLE devices distributed in the environment.

For each ODL, SHPIA stores the information’s shown in Listing 1.3.

figure c

As shown, the user has complete control over each smart ODL since she/he can decide the type of sensor to enable, the list of enabled sensors is present in the node description. Nevertheless, if the specified node does not support the enabled sensors, only those actually available will be activated.

Data Collection

After the environment definition and the association of ODLs with SHPIA nodes, the SHPIA mobile app will start collecting data from them (Fig. 6e and  f). The data perceived by the SHPIA nodes are transmitted to the smartphone and internally stored as JSON documents. As soon as an Internet connection is available, all data are transmitted to the remote NoSQL database (Fig. 6g). Listing 1.4 shows an example of the data perceived by the SHPIA node defined in Listing 1.3.

figure d

Attributes deviceID, on_aggreg_time and on_device_time uniquely identify the document; the rest represents the data perceived by the device’s sensors and the RSSI value measured by the smartphone. The on_aggreg_time variable represents the timestamp when the aggregator receives the data. Instead, on_device_time represents the timestamp when the data is perceived on the node. Finally, deviceID is used to identify the (sub-) environment to which the node is associated. We want to emphasize that the transmitted data can be saved at any NoSQL database deployed on the target IP (Fig. 6g). SHPIA users, for analysis purposes, necessitate only to know the data format (i.e., Listings 1.1, 1.2, 1.3, and 1.4) that the SHPIA mobile application adopts to store the data.

SHPIA Evaluation

This section deals with the evaluation of the performance of the SHPIA data aggregator to show the lightweight of the Android application in terms of power consumption and use of resources. In addition, it illustrates four application scenarios where SHPIA can operate. Such scenarios do not require any modification of the SHPIA platform, thus proving its versatility.

Data Aggregator Performance Evaluation

The performances of four Android smartphones with different characteristics and prices have been evaluated while acting as data aggregators for the SHPIA platform. The characteristics of the tested smartphones are reported in Table 3.

Table 3 Characteristics of the tested data aggregator nodes
Full size table

Instead, Table 4 presents the results of profiling the data aggregator nodes over a collection phase of 4/4/4 hours, by using five SHPIA nodes (i.e., Thingy 52) with sensors sampling data set at 50Hz, 100Hz, and 200Hz. The data aggregator nodes were placed over a table at the height of 100 cm. Instead, the Thingy devices were associated with different desks. The distance between the data aggregator and the thingy nodes varied between 2 and 7 meters. Overall, the average RAM use per hour was < 119 Mbh, the storage memory use was < 138 MbhFootnote 4, and the battery usage was < 594 mAhFootnote 5. On average, CPU usage and data loss were respectively 32 % and 0 %.

Table 4 Data aggregators profiling
Full size table

It is worth noting that smartphones executing an Android version older than v11 can be connected simultaneously with up to seven Thingy 52. Instead, smartphones running Android v11 can support the simultaneous connection with up to 11 Thingy 52. To cope with scenarios requesting the utilization of a higher number of Nordic Thingy 52 nodes, SHPIA implements a computation balancing module that allows different smartphones (thus, different users sharing the same environment) to automatically balance the number of Thingy 52 devices connected to them and save their information on the same dataset. Thus, in practice, SHPIA can handle more than 11 Thingy devices by jointly using more than one smartphone. Moreover, this balancing process helps to further reduce smartphone battery consumption.

These results show that the proposed platform works well on different data aggregator nodes, proving there is no need to buy costly top-level smartphones to run the SHPIA application.

SHPIA Nodes Battery Duration

Concerning the SHPIA nodes battery duration we observed the following. The Nordic Thingy 52 nodes efficiently operate at a sampling frequency of 200 Hz for more than three days without recharging the battery. In addition, a lower sampling frequency would further extend the battery life consistently for both smartphone and BLE nodes [41].

Instead, as certified by the manufacturers, the BLE beacons efficiently operate for more than one year at a sampling frequency of 1 Hz. In particular, the Estimote Locators nodes can operate for almost five years due to their larger battery capacity, and Estimote stickers and Global Tags can operate for one year. Nevertheless, based on the defined power transmition and sampling rate, the battery duration will significantly variate [38].

SHPIA Application Scenarios

In the following, we provide an overview of four different applications exploiting the SHPIA platform: (a) environmental monitoring, (b) occupancy detection and counting, (c) automatic data annotation of ADLs, and finally, (d) virtual coaching.

Environmental Monitoring

The primary use of SHPIA is that of collecting data concerning environmental conditions. For example, we used SHPIA to monitor a working office, shown in Fig. 8, shared by ten persons. We associated the Thingy 52 devices with 5 motionless nodes (indicated by red arrows in Fig. 8) and six mobile nodes (indicated by green arrows in Fig. 8) to perceive the environment status. The Honor 7S smartphone, described in Table 3, permanently connected to the electric current acted as a data collector. The Thingy 52 associated with the motionless nodes were placed as follows: one at the office door, two on the windows, one on the desk at the office center, and one inside the locker. Instead, the mobile nodes were used to monitor different ODLs and the activity that employees performed on them (e.g., one Thingy 52 was attached to a bottle of water). The data collection process was conducted for two consecutive weeks.

Fig. 8
figure 8

Office 1.71. Motionless (red) and mobile (green) nodes and data collector (gray)

Full size image

Table 5 shows an overview of the collected data. The first column introduces the used sensors. The second and third columns show the sensor sampling frequency and the measurement unit. Column four shows the number of samples collected by the system during the two weeks (i.e., 12,09,600 seconds). Column five identifies the number of data sources (SHPIA nodes). Finally, the last column shows the memory space required to store the sensed data. The last row concerns the collection of RSSI data, since the data collector extracts and associates the reception timestamp, the RSSI measure, and the emitter identity to each received BLE packet.

Table 5 Results of data collection
Full size table

Once collected through SHPIA, such data were successfully used by a HAR-based analyzer to perform environmental monitoring, recognition of people’s actions (e.g., drinking), and localization of ODLs and people in the environment. Because of the adopted low sampling frequency, the mobile and motionless BLE nodes perfectly worked for the overall duration of the experiments (2 weeks) without being recharged.

Occupancy Detection and Counting

Occupancy detection and counting represent a fundamental knowledge for implementing smart energy management systems, as well as solutions for security and safety purposes [42]. Existing techniques for occupancy detection and counting can be categorized as (a) not device free [43] and (b) device free [44]. The SHPIA platform provides the capability to implement both categories.

Not Device Free: Concerning the former, SHPIA can detect a user inside an environment by estimating the distance between the user’s smartphone and an SHPIA node associated with the environment itself, based on the RSSI measurement. To test this scenario, we evaluate the accuracy of the distance estimation between the user’s smartphone and ODLs equipped with Thingy 52 node. Since radio signal transmission highly depends on the environment characteristics [45], we limited the tests on this scenario to a maximum distance of 5 meters between the receiver and the emitters. The evaluation has been performed on three different distance ranges: (a) 0–5 m, (b) 0–3 m, and (c) 0–2 m using two opposite setups: (i) the smartphone in the user’s hand and the ODL in a fixed position, and (ii) the ODL on the user’s hand and the smartphone in a fixed position.

Table 6 presents the results obtained by seven different regression models trained on RSSI data perceived at 60 Hz. The models were trained in two ways: using the raw data, and using features extracted from one-second RSSI time windows. The quality of the achieved results is shown in terms of Root Mean Square Error (RMSE) and Mean Absolute Error (MAE) while estimating the distance in centimeters between the emitter and the receiver. The Random Forest model achieved the lowest RMSE/MAE value in both the raw and the feature-based data representation. The second most performing model was Gradient Boosting. Overall, we achieved an RMSE on raw RSSI data of 51 cm in the range 0–5 m, 17 cm in the range 0–3 m, and 12 cm in the range 0–2 m. Moreover, in terms of MAE, the features performed better than the raw data: 28 cm (range 0–5 m), 8 cm (range 0–3 m), and 8 cm (range 0–2 m). Furthermore, the most essential characteristics of these regression models regard the reduced memory and computation requirements, making them suitable for running on mobile and hardware-constraint devices.

Table 6 Distance estimation results based on RSSI measurements captured at 60 Hz
Full size table

Device Free: The second category of occupancy detection and counting systems behave more intelligently. In fact, users do not need to carry any device. By using SHPIA, we can detect their presence and number based on the variations of the RSSI measurements associated with the BLE signals received by the data aggregator from Thingy 52 located in the environment. The idea is that RSSI measurement fluctuations are generated by people’s presence and movements inside the environment. Figure 9 shows very clearly the difference between nocturnal (red plot [8:00 PM–8:00 AM]) and diurnal (blue plot [8:00 AM–8:00 PM]) RSSI observations at the office shown in Fig. 8. The same concept is applied as regards the occupancy counting scenario (aka., identification of the number of people present inside or in the environment).

Fig. 9
figure 9

Office 1.71. RSSI fluctuation between night and day for occupancy detection

Full size image

We carried out tests in a university classroom (8.8 m x 8.6 m) with 15 study stations (chairs + tables) involving six different subjects. One female (29 years, 1.58 m height) and five males (25–29 years, 1.75–1.95 m height) were involved in the experiment. Subjects entered and left the environment in an undefined order with the only constraint that they must stay in the environment at least for one minute. Besides, the following environmental situations were recreated: (i) all standing still, (ii) all standing in motion, (iii) all seated, and iv) some standing in motion and some sitting.

Table 7 presents the achieved results using five different BLE nodes connected to SHPIA. Tests were performed over five different well-known classification modelsFootnote 6. Columns two to five show results in terms of specificity, sensitivity, precision, and comprehensive accuracy. Overall, the SVM model with a linear kernel achieved the most noticeable results. Among all the other models, such a model requires higher computational capabilities; however, the Keras library provides a Quasi-SVM model implementation for Android-based mobile devices, thus enabling the SHPIA data collector on-device recognition capabilities. Furthermore, the selected models have a reduced hyperparameterization space, thus requiring less training time. In future research, we plan to investigate other alternative models (e.g., MLP), considering their potential for computation on resource-constrained devices. By verifying the classification errors in detail, we observed that the incorrectly classified samples are related to the situation in which people inside the environment are all seated, independently by their number.

Table 7 Occupancy detection results
Full size table

Table 8 presents the results obtained on raw and features data concerning the occupancy counting scenario. The outcome is an estimation of the number of persons in the environment. The lower the RMSE, the higher the estimation accuracy. In particular, the proposed occupancy counting system, given a set of features identifying a one-second time window of RSSI measurements, estimates the number of people in the environment with a RMSE of 0.5 and a MAE of 0.3. Using the raw dataset, we achieved a RMSE of 0.7 and a MAE of 0.4. As for the occupancy detection scenarios, the estimation error is amplified when all people inside the environment are sitting down.

Table 8 Occupancy estimation results
Full size table

Automatic Annotation of ADLs

As already mentioned in Section “Introduction”, one of the most significant limitations in the HAR research area concerns the creation of the learning dataset through a data annotation process. This process usually requires extensive manual work, during which at least two annotators associate data samples (e.g., perceived through inertial sensors) with labels that identify the activity (e.g., slee**, eating, drinking, cooking, and many others) based on a video recording of the context. SHPIA can automatically annotate these activities by assigning, as shown in Fig. 10, an SHPIA node to specific objects or locations in the environment (e.g., by associating the Estimote Sticker to the eating table, to the working desk, the bottle of water, the bed, etc.) and by estimating the distance between the SHPIA data collector (i.e., the smartphone that the user is carrying) and the SHPIA node.

Fig. 10
figure 10

Overview of the proposed SHPIA-based HAR automatic data annotation methodology

Full size image

Thus, when the user is eating, SHPIA assigns the label “eating” to the data collected from the smartphone, based on the estimated distance between the nearest SHPIA node (i.e., the one on the table) and the user’s smartphone. Preliminary results in this direction [34] showed that the approach works properly for activities requiring more than 30 seconds to be performed (e.g, intensively washing hands, or cooking).

Virtual Coaching

Virtual coaching capabilities can be easily supported by the SHPIA platform. A virtual coaching system (VCS) is an ubiquitous system that supports people with cognitive or physical impairments in learning new behaviors and avoiding unwanted ones. By exploiting SHPIA, we set up a VCS comprising a set of smart objects used to identify the user needs and to react accordingly. For example, let us imagine a person requiring a new medical treatment based on pill’s assumption that initially forgets to respect the therapy. By attaching a BLE tag to the pills container SHPIA can monitor pills assumption. The user carries the smartphone (e.g., into the pocket), and when he/she approaches the pills container, SHPIA estimates the distance between the user and the container. Figure 11 present an overview on RSSI measurements distribution on distance variation between SHPIA nodes (emitter) and SHPIA data collector.

Fig. 11
figure 11

RSSI measurements distribution on distance variation

Full size image

It can also understand when the user opens and closes the cap based on the received motion information emitted by the BLE tag attached to the container. Thus, it is possible to understand, with greater accuracy, whether the user has taken medicines or not. If the person does not take medicines, the system warns him. Otherwise, the system remains silent. A prototype of such a system has been proposed in [46].

Conclusions and Future Works

This paper presented SHPIA 2.0, a platform exploiting low-cost BLE devices and an Android mobile application that transforms ODLs into smart objects. It allows effective and efficient data collection for implementing various solutions in smart home and HAR scenarios. SHPIA works in a ubiquitous and non-invasive way, using only privacy-preserving devices such as inertial and environmental sensors. Its versatility has been evaluated by discussing four monitoring scenarios concerning the automatic data annotation of ADLs, occupancy detection and counting, coaching systems, and environmental monitoring. Moreover, despite the mentioned scenarios, SHPIA can be easily used in other scenarios such as industrial, smart buildings, smart cities, or human activity recognition. Nevertheless, although we have already implemented a computation balancing system that overcomes SHPIAs scalability issue, SHPIA 2.0 was upgraded by integrating support for BLE broadcasting network topology, transforming it into an easily scalable architecture.

While SHPIA shows its adaptability and scalability for applications in smart homes, industrial settings may provide particular complications that call for careful attention. Due to differences in hardware and communication standards, integration with current industrial systems and protocols may be difficult. To ensure smooth operations, a thorough assessment of the resilience and dependability of SHPIA in industrial settings is also required. As sensitive data and crucial activities are frequently handled in industrial environments, security and privacy issues also need to be addressed. Despite these possible problems, SHPIA has bright promise for expanding smart solutions in industrial domains with appropriate adaption and industry expert participation. To make SHPIA 2.0 a workable and efficient tool for industrial applications, more study and development are required. Finally, compared to existing commercial systems, SHPIA stands out with its affordable use of low-cost BLE devices, versatile and scalable platform, focus on user privacy, and open-source availability. These unique features position SHPIA as a compelling alternative to existing commercial systems that researchers in the field of IoT, HAR, AAL, and AmI can use to eliminate the existing limitations and challenges in their research.