A Low-Cost Monitoring Platform and Visual Interface to Analyse Thermal Comfort in Smart Building Applications Using a Citizen–Scientist Strategy

Abstract

Smart building issues are critical for current energy and comfort managing aspects in built environments. Nevertheless, the diffusion of smart monitoring solutions via user-friendly graphical interfaces is still an ongoing issue subject to the need to diffuse a smart building culture and a low-cost series of solutions. This paper proposes a new low-cost IoT sensor network, exploiting Raspberry Pi and Arduino platforms, for collecting real-time data and evaluating specific thermal comfort indicators (PMV and PPD). The overall architecture was accordingly designed, including the hardware setup, the back-end and the Android user interface. Eventually, three distinct prototyping platforms were deployed for initial testing of the general system, and we analysed the obtained results for different building typologies and seasonal periods, based on collected data and users’ preferences. This work is part of a large educational and citizen science activity.

1. Introduction

A growing interest in smart and intelligent building solutions is evident, and the impact that IT (Information Technologies) and ICT (Information and Communication Technologies) have on both society [1] and the built environment is well-recognised and studied at building [2] and urban [3,4] scales. The last 2018 EPBD EU Directive clearly underlines the importance of smart solutions, mentioning the need to establish a smart readiness indicator (SRI) supporting the calculation of building capability in adapting during operational phases to user needs [5]. This indicator is now defined under the correlated EU Commission Delegate Regulation [6] and Implementation Regulation [7] and annexes [8,9]. However, the penetration of smart systems in the building sector is still an ongoing process due to limitations in available systems and costs [10], and the lack of additional performance indicators [11]. Nevertheless, smart monitoring solutions are needed to support a correct analysis of building conditions, i.e., thermal comfort, visual comfort, indoor air quality (IAQ) and acoustic comfort, and to define optimisation strategies [12]. Even before the COVID-19 situation, people were used to spending the majority of their lives in confined spaces with the risk of being exposed to poor environmental conditions and being affected by Sick Building Syndrome (SBS), or more in general by a reduction in productivity and decision-making performance [13]. Indeed, offices, gyms and public buildings are expected to pay attention to these considerations according to regulations, i.e., [14], and guidelines, e.g., [15], there is a growing interest in smart monitoring systems for residential buildings [16]. By exploiting new technologies and IoT (Internet of Things) systems [17], smart buildings can provide healthier indoor environments and meet user comfort needs. Deeper knowledge about the actual situation is a crucial step to efficiently achieving results; reducing the financial and environmental impacts of unwise decisions; and supporting end-user satisfaction and energy consumption reductions. In fact, HVAC systems (heating, ventilation and air conditioning) are responsible for over 50% of the total energy consumption of a building [18]. Considering the significance of the mentioned aspects to supporting analysis and evaluations, specific mathematical models and comfort indices have been introduced and widely employed—see, for example, [19]. Focusing on thermal comfort, the Predicted Mean Vote (PMV) and the Predicted Percentage of Dissatisfied (PPD) are recognised indexes for evaluating mechanically controlled spaces [20,21].

Numerous systems have been developed to control and monitor different aspects of indoor climates, such as high performance Building Management Systems (BMS) [22]; professional monitoring cloud solutions, e.g., the Capetti Winecap system [23], and simpler systems that allow the users to check the basic parameters characterising the thermal environments of their houses via mobile applications, such as commercial home kits—including those of Netatmo [24] and Aircare [25]. Simpler systems are not able to be customised in terms of connected probes and do not include user feedback. Even professional solutions do not generally allow one to calculate PMV, even if they may allow one to connect additional third-party sensors. However, in all mentioned cases, data access is not direct, but passes through mobile or web applications, with the exclusion of warning lights. Thus, large possibilities are left open for the development of simpler and cheaper solutions based on basic IoT networks [26], and/or involving computer simulated scenarios [27].

Very interesting work was presented in [28], describing a comfort-oriented solution to control mixed-mode ventilation in buildings using a simple Raspberry Pi-connected PMV monitoring station. However, this approach is devoted to building automation rather than user information. The results demonstrate how PMV kits may be developed in a low-cost fashion. Similarly, recent work on IoT smart home thermal comfort analysis was reported in [29] to support actuators in an office laboratory environment. A technical environmental monitoring interface has been developed in C# that includes CO₂ and PMV values, although server facilities and user feedback are not included, and there are no simple graphical interfaces for non-expert users. Other authors have recently investigated the correlations between an IoT PMV monitoring kit and BIM models supporting real-time data processes. One such approach was based on the Google Cloud platform to show temperature distribution in virtual reality (VR) represented room spaces [30]. Other researchers analysed the possibility to connect digital twin models in CAD environments with real-time monitored data, such as temperature and humidity sensors, as recently reported in [31] and shown in [32]. BMS data usages to characterize operational and design suggestions are currently a diffuse research topic, allowing, for example, defining optimal PCM melting points in walls and roofs [33], or calibrating numerical models for shaping thermal conditions in traditional buildings, e.g., [34]. It is important to remember that ICT systems may correlate thermal comfort indices with individual comfort sensations, thereby including the possibility of exploiting wearable devices able to track basic human parameters, as noted, for example, in [35]. It is, in fact, possible to further adapt a monitoring system to customised characteristics supporting user profiling and personal preferences for thermal comfort. This can be done by collecting user feedback via surveys or mobile applications. Numerous studies are analysing the psycho-physical user conditions to support machine learning techniques based on detected and exploited retrieved data to define personalised comfort models—see, for example, [36]—which surpass standard models and requirements, e.g., the ones reported in UNI (national) [37,38,39], EN (European) [14,40], ASHRAE (American) [41] or ISO (International) Standards [21]. Focussing on the above-mentioned PMV/PPD indices, it is possible to recall that they require a large set of parameters to be calculated, including personal data, the mean radiant temperature of a space and relative air velocities. However, additional specific indexes have been developed for studying thermal comfort perceptions according to different climates; building characteristics and typologies; and/or physical, psychological, cultural and social conditions—see, for example, [42,43]. Remaining in the PMV/PPD domain, Humphreys and Nicol conducted a study on large datasets, concluding that their PMV model produces valid results under stricter ranges of parameters than the ones defined in the ISO 7730 standard [44]. Another study tested their PMV model for specific target buildings [45], underlining how different groups of people tend to prefer “not-neutral” thermal conditions, and another in relation to the kind of activity the people are performing and how much time they spend in the tested area [46]. PMV models are useful for HVAC controlled environments, whereas for naturally ventilated buildings and under free-floating conditions, the prediction of thermal comfort conditions can be achieved by adopting adaptive thermal comfort indices: see the first paper [47] and recent works [48,49], along with comparisons between models [50]. Additional studies proposed revised PMV models combining the prediction performance of the original static model with thermal comfort factors based on the adaptive comfort theory [51]. Finally, considering the general aging of the world population, the demand for comfortable living environments is rising, opening up a set of possible applications of monitoring systems to meet specific comfort needs [52].

This paper introduces a new IoT thermal comfort monitoring solution able to be low-cost, compared to previously mentioned commercial solutions; scalable and modular. The objectives of this paper are expressed in the following section.

Paper’s Objectives and Organisation

The main objective of this study was the development of a beta-version of a new smart building monitoring platform able to collect indoor comfort data and to make them accessible to a user via a server facility. This work is an initial stage of a large research-based educational activity, and the proposed system is expected to be implemented during the next project phases to develop an IoT monitoring network based on pre-assembled nodes. The system should be distributed in several schools and residential buildings for a citizen–scientist action devoted to comfort data collections to further promote real-time self-actuation actions to users to optimize internal conditions.

Focussing on this paper, the following specific objectives are defined:

• To develop the beta-version of a smart platform based on a sensor network for monitoring thermal comfort in building spaces. The platform is required to be low-cost compared to the professional equipment mentioned above. Compared to the home monitoring systems mentioned in the above section, the measured values are larger, including air velocity and mean radiant temperature, and the system allows one to calculate thermal comfort indices, e.g., PMV and PPD;
• To develop a system suitable to addressing different end-user profiles, which should include a mobile application for data visualisation and for collecting end-user feedback;
• To detail the making of a low-cost IoT monitoring device detailing different phases, i.e., research design, method, monitoring solutions and initial result interpretations.

The paper is organised as follows: Beyond the introduction, Section 2 describes the adopted methodology, including the system architecture and the adopted thermal comfort model. Section 3 is devoted to detailing the hardware and server implementation. Section 4 describes the implemented user interface and the chosen data visualisation approaches. In Section 5, initial testing applications are reported and discussed. Finally, the paper includes a Discussion and Conclusion section.

2. Methodology and System Architecture

The system proposed in this paper is composed of three main actors—see Figure 1: (i.) the back-end with the related software implementation, (ii.) the hardware platform, and (iii.) the graphical interface (Android application) devoted to end-users. Each portion is introduced in detail herein by describing requirements and discussing individual component choices.

Additionally, the following technical requirements are assumed during the system definition: (i.) scalability and modularity; (ii.) decentralisation and adaptability; (iii.) proper protocols implementation; (iv.) public API support; and (v.) automatising and plug and play.

2.1. Back-End Definition

The back-end is the core element of the system, dealing with all the possible requests and actions performed by the hardware platform and the user interface. In particular, it needs to comply with computational-capability requirements. The main functionalities concern the storage of data from different monitoring kits (e.g., different users and buildings), the management of specific settings and personal preferences, real-time computations of PMV and PPD, alerting messages, dashboards and statistics. The development of the back-end is conceived to include, where possible, third-party available software in order to reduce development costs and software maintenance. The final structure consists of:

• A server composed for this paper by a Raspberry Pi 4—4 GB RAM, 64 GB storage. However, the Raspberry may be substituted during future developments with a more powerful server in order to manage a larger set of platforms for citizen science activities.
• A Python environment and a Cherry framework. The software has been indeed developed completely from scratch, exploiting Python 3.7.3 libraries and the possibilities offered by Cherry; all services have been designed to meet the requirements.
• Ngrok—pro plan. Tunnelling is a crucial aspect to make the server reachable from outside using a reliable service [53]. In addition, the chosen plan allows one to set the necessary configurations for the feasibility of the project, while extra-nodes in Ngrok allow scalable service plans.
• Influx DB. Adopted to define a time-series database thanks to its ability to manage massive volumes of data produced by sensors, applications and infrastructures [54]. Therefore, Influx DB is a popular solution for IoT systems in smart buildings.
• Grafana dashboard. Grafana, chosen also for its ability to cooperate with InlfuxDB, allows one to provide graphs and statistical representations of results supporting attractive data-visualisations for the end user [55].
• Monitoring nodes (hardware kits), based on a Raspberry Pi and an Arduino UNO shield, plus devoted sensors with the addition of a small visor to show real-time monitored data even without connecting to the mobile application.

To provide scalability and modularity, a micro-services approach has been adopted. Each service is responsible for a limited subgroup of functionalities, being completely independent of the others. They communicate through the corresponding API interfaces, processing REST-based HTTP requests. Since all communications are Internet-based, each service could be hosted by a different node.

The proper choice of protocols is a crucial aspect to guarantee an efficient software design. For this purpose, the whole developed system relies on two widespread Internet protocols: HTTP and MQTT. The former is essential for implementing a REST-based API, retrieving results and managing requests and communications among entities. However, the latter was also adopted to guarantee constantly updated measurements from sensors [56]. In fact, MQTT is a lightweight protocol with minimal bandwidth usage. In order to support its asynchronous nature, three actors are involved: (i.) broker, (ii.) publisher and (iii.) subscriber. For the project’s purposes, MQTT has been selected to send alerts and warnings to users.

2.2. Hardware Kits

In designing the hardware kit and choosing its components, particular attention was given to keeping the system flexible, able to support different types of sensors and as cheap as possible. A Raspberry Pi and an Arduino are used to handle the different types of sensors. The Arduino board in particular is used as an analogue to digital converter (ADC) for those sensors that produce analogy output. A serial connection via cable is applied between the two devices to avoid a more complex and expensive implementation of data exchange via a Wi-Fi module or a Lora one, even if the latter may be considered in the future if multiple nodes need to be installed in the same building. Lastly, the Raspberry Pi is also in charge of communicating with the server using its Wi-Fi connectivity. A list of all the components included in the current version of the prototype hardware kit is reported in

Table 1. Hardware kit components.

List of Sensors				List of Other Hardware Components
Sensor	Measured Parameter	Accuracy	Average Cost	Component	Average Cost
DS18B20	Air Temperature	±0.5 °C	∼2 €/piece	Raspberry Pi 3B kit	∼75 €
DHT22	Humidity (+Temperature)	±2%RH	∼8 €/piece	Arduino One	∼24 €
MAX6675	Globe Temperature	±0.25 °C	∼8 €/piece	Breadboard kit	∼6 €
Rev-C	Air velocity	nd	∼17 €/piece	Display OLED 0.96”	∼5 €

.

Sensors

Different designs of the hardware kit have been tested, taking into account the overall cost. Nevertheless, in Table 1, the list of sensors used in the final developed prototype is shown, along with their corresponding parameters measured, accuracies and average costs. This list was better detailed in a previous work defining an outdoor comfort monitoring kit—see [57]. The described basic configuration was deployed to ensure the availability of the necessary parameters for computing the mathematical models explained in Section 2.4. Clearly, platforms can be upgraded with new sensors to extend the available environmental overview, e.g., by implementing IAQ analyses; see, for example, the monitoring solution reported in [58].

2.3. Android Application

End-users expect to have access to results, settings and graphs. However, the interface needs to be intuitive and user-friendly, supported by icons and the possibility to quickly switch from one activity to another. The proposed application was developed using Java in the Android Studio environment in order to have a completely web-based user interface. The proposed application simply retrieves the requested information from the server. This ensures a lightweight application, with minimal disk memory usage and data updated in real-time. Therefore, the user can handle all the platforms associated with his/her profile, monitoring thermal conditions and sensor network status.

2.4. Thermal Comfort Indices and Model

The main objective of the system is to provide to end users a measure of the thermal comfort of confined spaces in which the monitoring kits are installed. Thermal comfort may be defined as the condition that describes human satisfaction with the thermal environment. Different models can be used to express thermal comfort conditions. Among them, the well-known PMV/PPD index is adopted in this paper, in line with other studies, e.g., the above-mentioned [28,29,30,31], assuming to mainly work in controlled spaces. The PMV (Predictive Mean Vote)—see also [59]—is defined on a scale from −3 to +3, where PMV equal to zero corresponds to thermal neutrality. The Predicted Percentage of Dissatisfied (PPD) index gives instead an estimation of the predicted percentage of people who will be dissatisfied by the undergoing thermal conditions, whether discomfort comes from a too cold or a too hot environment. An evident correlation exists between PMV and PPD being PPD a function of PMV. The model aims to estimate the average thermal sensation of a group of people occupying a certain indoor space by correlating four environmental parameters (air temperature, mean radiant temperature, relative humidity and relative air velocity) with two personal parameters (clothing insulation and metabolic heat rate). The firsts are retrieved by the monitoring kit sensors, while the seconds are assumed according to standard suggestions for the given prevailing activity, although they can be modified by the developed application. After collecting all necessary data, thermal comfort results are obtained by applying the index-correlated mathematical equations—see next sub-sections. The PMV/PPD model is also referred to as a static model for thermal comfort, in contrast with the adaptive one. While the PMV/PPD model is assumed to describe thermal comfort in air-conditioned buildings, the adaptive model can be applied to naturally ventilated ones [60,61]. Future versions of the kit will also include a larger set of thermal comfort KPIs including free-running building ones.

2.4.1. Parameters and Measurements

In order to compute the PMV, the monitoring platform directly measures the air temperature t_a [°C], the relative humidity RH [%] and the air velocity v_a [m/s]—see also ISO 7726 [62]. Instead, in order to calculate the MRT (mean radiant temperature), the measured globe temperature t_g is combined with air temperature and airspeed according to the equation reported in [63]—see Equation (1).

$$MRT=\left[{\left(t_g+273.15\right)}^4+\frac{1.335·{10}^8{v}_a^{0.71}}{{\epsilon }_g·D^{0.4}}\left(t_g-t_a\right)\right]$$

(1)

where ε_g and D represent, respectively, the globe thermometer emissivity and its diameter.

Two other fundamental model parameters are clothing insulation I_cl and the metabolic heat rate M. The clothing insulation can be defined by considering the individual insulation of each piece of clothing that a person is wearing—see, for example, [48]—although different methodologies have been exploited to measure the clothing insulation, involving body scanners or heated manikins [12]. However, these techniques are expensive, require complex machinery, and cannot be adapted for end-user applications. Tables of typical values are instead available for various clothing ensembles—see above-mentioned thermal comfort standards and references. Users can set via the mobile application the value of insulation corresponding to their current clothing, choosing from a set of possible values, although basic winter (1 clo) and summer (0.5 clo) values for indoor spaces are assumed as initial thresholds. The metabolic rate depends on the type of activity a person is carrying out. As in the case of clothing insulation, tables of typical values are available. The user can set the value for the metabolic heat rate choosing from a list of predefined values according to typical kinds of activities carried out in the room, e.g., 1 met for a relaxed seated person or 2 met for domestic works.

2.4.2. PMV/PPD Mathematical Model

The Predicted Mean Vote calculation is based on the equations originally developed by Fanger [59,64] and included in ISO 7730 and EN 16798-1. The PMV index is derived from a thermal balance equation of the human body (Equation (2))—see also [65].

$$PMV=\left[0.303 exp\left(-0.036M\right)+0.028\right]·\left[\left(M-W\right)-H-E_c-C_{res}-E_{res}\right]$$

(2)

where M is the energy metabolic rate (W/m²); W is the effective mechanical power (W/m²); H is the sensitive heat exchanges including radiation and convection; E_c is the heat exchange by evaporation (sweat) and transpiration of the skin; C_res and E_res are, respectively, the breathing heat exchange by convection and evaporation. H, E_c, C_res, and E_res are calculated, respectively, through Equations (3)–(6)—see also [65] and ISO 7730.

$$H=3.96·{10}^{-8}·f_{cl}·\left[{\left(t_{cl}+273\right)}^4-{\left(MRT+273\right)}^4\right]-f_{cl} h_c \left(t_{cl}-t_a\right)$$

(3)

$$E_c=3.05·{10}^{-3}·\left[5733-6.99\left(M-W\right)-p_a\right]-0.42\left[\left(M-W\right)-58.15\right]$$

(4)

$$C_{res}=0.0014·M\left(34-t_a\right)$$

(5)

$$E_{res}=1.7·{10}^{-5}M\left(5867-p_a\right)$$

(6)

where f_cl is the clothing surface area factor, t_cl is the clothing surface temperature (°C), MRT (°C), h_c is the convective heat transfer coefficient (W/(m²K)), ta the air temperature (°C), p_a is the water vapour partial pressure (Pa). The mean radiant temperature is obtained from the measured globe temperature through Equation (1). The clothing surface area factor f_cl is computed according to Equation (7) [21], while p_a is obtained according to Equation (8).

$$f_{cl}=\left\{\begin{array}{cc}1.00+1.290 I_{cl}\hfill & if I_{cl}\le 0.078 m^{2}K/W\\ 1.05+0.645 I_{cl}\hfill & otherwise\end{array}\right.$$

(7)

$$p_a=\frac{RH}{100}·p_{sat}$$

(8)

$$p_{sat}=exp\left(\frac{A·t_a}{B+t_a}+C\right)$$

(9)

where I_cl is the clothing insulation (m²K/W)—see above; p_sat is the saturated vapour pressure—see Equation (9); and A, B and C are factors depending on the air temperature—i.e., they can be assumed to be, respectively, 22.3376, 271.68 and 6.4146 when −40 °C < t_a < 0 °C, or 17.438, 239.78 and 6.4147 when 0 < t_a < +40 °C [66].

Differently, t_cl is obtained through an iterative process, considering a heat balance equation for the clothing layer. In fact, in steady-state conditions, it is assumed that the heat transmitted through clothing by conduction balances the heat exchanged with the surrounding environment by convection and radiation. A starting value for t_cl is generally chosen as an average between the air temperature and the skin external temperature. The latter is defined in Equation (10). The value of the clothing surface temperature is then updated through Equation (11), picking at each iteration the average between the new value and the one obtained at the previous iteration. The convection coefficient h_c also appears in the equation for t_cl and it is set at each iteration with Equations (12) and (13) [21], where v_ar is the relative air velocity [m/s]. The iterative calculation is carried on until convergence is reached: in this case, when the difference between two consecutive results is less than 0.001 °C.

$$t_{sk}=35.7-0.028\left(M-W\right)$$

(10)

$$t_{cl}=t_{sk}-I_{cl} (3.96·{10}^{-8} f_{cl} ({(t_{cl}+273)}^4-{\left(MRT-273\right)}^4)+f_{cl} h_c \left(t_{cl}-t_a\right))$$

(11)

$$h_c=\left\{\begin{array}{cc}D\hfill & if D>\sqrt{v_{ar}}·12.1\\ 12.1\sqrt{v_{ar}}\hfill & otherwise\end{array}\right.$$

(12)

$$B=2.38·{\left|t_{cl}-t_a\right|}^{0.25}$$

(13)

The PPD value is directly derived from the PMV according to Equation (14).

$$PPD=100-95 exp\left(0.03353 PM{V}^4+0.2179 PM{V}^2\right)$$

(14)

3. Hardware and Server Implementation

This Section details the implementation of the above described structure, taking into account both software and hardware developments. Figure 2 shows the layer structure for the general implementation of the system software, with the corresponding main functionalities.

The data-source layer integrates the measurements obtained by each hardware platform with additional information retrieved by public API. Managing heterogeneous data is a key aspect for modern IoT systems in smart buildings, along with proper data format. For this reason, all ex- changed messages among different elements of the system are based on JSON format. Raw data are then processed by the back-end, hosting and indexing the necessary services to deal with the expected requests. Finally, the application layer allows the user to have access to real-time results and dashboards, supported by alerting and communications.

3.1. Back-End Design

3.1.1. Hardware

The back-end requires specific computational capabilities to guarantee the proper operation of the system, especially when different platforms are running. In fact, all data elaboration is performed by the server. In order to be consistent with the general strategy of the project and the correlated costs, the most suitable choice is a Raspberry Pi 4 Model B, fully devoted to the purpose. Despite the small size and relatively low price, acceptable performances are achieved relying on 4 GB RAM and 64 GB for disk memory. Considering the computational effort expected by the back-end, passive dissipation is not sufficient. Therefore, a 5 V fan is combined to avoid overheating.

3.1.2. Micro Services Architecture

Following the microservices approach, each developed service presents a similar structure basically composed of a REST-API interface, for handling requests and communications, and a JSON file, storing settings and data. This strategy makes services potentially easy to be migrated to different nodes without additional coding. The main actor in microservices architecture is the Services Catalogue, managing requests and registrations. Firstly, when a new service is launched, it performs the registration to the Services Catalogue, communicating its own address and port at which the process is available within the local network. Secondly, the other services retrieve this information by sending the specific request to the Services Catalogue. Since the discovering is dynamic, the system is always updated even if one service changes its own configuration. However, besides internal communications among services, also hardware platforms and mobile applications need to contact the server for different purposes. Therefore, the Services Catalogue needs to store the associated public address for each service, relying on Ngrok integration. As shown in Figure 3, it is able to handle both private and public requests, making the system accessible from the external world.

The implemented services are the following:

• MQTT broker, hosted by the server at port 1883 for allowing MQTT communications with platforms and sensors;
• Users Catalogue, for managing registrations and login via mobile application. For each user, also the list of associated platforms is stored;
• Profiles Catalogue, storing preferences of each user concerning platforms, rooms and locations. Preferences are updated via the application and are completely customizable;
• Resources Catalogue, representing the core activity of the server for data collection. The database shows a complex and hierarchical structure, inheriting rooms catalogue and devices catalogue. It is in charge to collect current measurements, check for inactive sensors and perform all necessary computations to apply the PMV/PPD model. Consequentially, the Resources Catalogue produces customised alerting messages when values are outside the suggested ranges;
• Resources Subscriber, completing the MQTT communication with sensors. It is the key component for organising data collection. Subscriptions are performed in parallel according to the list of running platforms and are continuously updated through information exchange with other services. When new data are notified, the Resources Subscriber reports information about the measurement (platform, room, parameter, value and timestamp) to the Resources Catalogue and the Influx database for storing purposes;
• Drivers Catalogue, storing configuration data retrieved by platforms HUB when sensors are installed;
• Feedback Catalogue, allowing the user to send (facultative) the actual feeling about the perceived thermal comfort in a specific room;
• Grafana, hosting dashboards for all different users. The process runs on the back-end and can be accessed by the client interface;
• Grafana Catalogue, cooperating with the Grafana process. The service is devoted for managing, creating and editing dashboards.

3.1.3. Database

Regarding data storage, two different approaches are actually implemented. In the first approach, each service relies on a simple and specific JSON file in which information is saved regarding both configuration and users. For instance, Profiles Catalogue defines an entry for each new profile with all the correlated preferences. When the user performs some changes, the corresponding database is updated. In particular, Resources Catalogue stores current measurements for all platforms. They are overwritten every time a corresponding new measurement is available, following the hierarchical structure of the database for platforms and rooms. In fact, the purpose of this database is to provide users a real-time overview of the room, showing current conditions. The complete structure of each database can be observed in Figure 4.

Differently, a second approach is implemented in order to define a historical database for each platform based on Influx DB. This is a recognised database for collecting data along the time especially when including graphs and statistics. In this case, Influx DB is organised to insert a new entry every 5 min. Since this approach is efficient and scalable, a specific database is created and devoted for each platform under the same instance of the server. Each parameter is stored individually, specifying the room ID as” tag”. Then, collections are aggregated over time, ensuring a faster ingestion rate. Considering the importance of space saving, Influx DB allows one to specify a retention policy for databases so that old data can be discarded. For the project purpose, this discharging time is set to six months. A retention policy can be adapted according to server capabilities or it can be used as a premium feature for the potential introduction of a commercial version of the application.

3.2. Additional Services and External API

3.2.1. Ngrok-Tunnelling

In order to expose the back-end services running on a local machine to the Internet, Ngrok has been included in the server configuration. It is suitable for tunnelling, especially considering the simplicity in integrating the service with the existing system, being sufficient to specify the port in which each service is running. Hence, Ngrok is chosen as a proper solution for testing the developed platform and the user application while connected to a local back-end, before integrating the system in a large, devoted server during potential future deployment. However, for project purposes, the basic version of Ngrok was not sufficient, and a ‘pro’ plan was assumed to be needed to expose ten services with a fixed address to feed the Services Catalogue.

3.2.2. Open Weather—Weather API

The indoor thermal comfort is clearly related to external conditions, like weather, seasons and time of the day. For this reason, the system is integrated with Open Weather, a public API devoted to retrieving weather data [67]. The direct comparison among internal and external thermal conditions leads to more consistent analysis for the user. The implementation involves both front-end and back-end systems. A first in-app overview is indeed made available according to each specific user location, extended by additional information and graphs in the complete dashboard. In fact, the Influx DB database has been implemented in order to periodically store weather information for each user and provide detailed graphs and results including also Open Weather retrieved data.

3.3. Monitoring Platform Kit

3.3.1. Hardware

As introduced in Section 2.2, the platform kit is composed of: (i.) a Raspberry Pi 3B+, which is in charge to communicate with the server, (ii.) an Arduino One R3 board, which is used as an analogue of a digital converter, (iii.) a breadboard to which (iv.) all the sensors and (v.) the display is attached. The complete circuit structure with all connections is shown in Figure 5.

Three prototypes have been assembled. The wind sensor Rev-c has been placed in order to stick out from the breadboard to properly sense air movements in the room. An initial calibration of the sensor is needed to set the proper zero value, e.g., by placing the sensor inside a glass bell in order to eliminate all possible residual air movements. Sensors DHT11 and DHT22 have been included in different kits to collect relative air humidity; DHT22 shows a slightly better accuracy (±2%RH) with respect to DHT11 (±5%RH) and it is characterised for having a wider range of measurement (0–100%RH). Instead, DHT11 shows good performances only within 0–80%RH, which includes in any case the general comfort ranges for RH—see EN 16798-1. The air temperature sensor DS18B20 is used in two different versions. The first one is an integrated probe which only requires a simple connection of the output pin to the Raspberry. The other one (see also Figure 5) needs a 4.7 kΩ resistor to be added in series between the output pin of the sensor and the I/O pin of the Raspberry. Considering the globe temperature, a thermocouple is placed in the centre of a dark sphere. Existing commercial solutions are usually expensive and bulky. A low-budget version has been instead realised by using a table tennis ball (diameter of 38 mm), painted with a known RAL grey colour paint (emissivity around 0.9) [63]. The thermocouple sensor has been placed inside the ball, paying attention not to leave holes in the structure. The thermocouple is then connected to the base attached to the breadboard. The ball is placed above the overall structure in order to properly intercept radiant temperature from the surrounding surfaces. This general approach is in line with other publications, e.g., [63], while the specific configuration here assumed has been tested by the research group in previous work [57]. The last component of the hardware kit is an OLED display, placed on the front part of the kit for displaying the real-time values of PMV, air temperature, humidity and air velocity to users even without accessing the application.

3.3.2. Software Implementation

The user kit is composed of a central HUB, in charge of contacting the server, and one or more devices associated with the HUB. Each device represents a new room of the existing platform, allowing the user to have a hierarchical organisation for the specific building. Since the deployed prototypes are intended as a starter kit for the user, they are hosting both the central HUB and a first room. Therefore, if the user wishes to integrate the system with new devices for a more complete mapping of the building, the additional rooms will be associated with the central HUB already present inside the local network.

The central HUB implementation is crucial for installing the new platform and managing different rooms. For this paper, it is organised as a simple REST-based API exposed within the local network. A unique platform ID is associated with each HUB (e.g., ‘MP-A00013’) to support the server communication without requiring a direct contribution by the users and allowing an automatic installation. When the central HUB is running, it retrieves the necessary information from the back-end, making them locally available for the connected rooms. This strategy reduces the amount of requests expected by the server and also results to be very user-friendly by end-users.

Rooms are not universally identified. In fact, the user creates a virtual instance of a new room via an app on the server. When the device is powered on, it simply discovers the local central HUB and automatically performs the association, contacting the server. Using a simple counter, the server assigns a unique room ID valid inside the hierarchy of the specific user’s platform. Clearly, the mobile application allows one to include a personalised name for rooms and platforms (e.g., room X2 or bedroom, while platform MP-A00013 may be for example named My Home).

In order to support the flexibility and modularity of the system, each sensor is based on the same main script. When the script is launched, the name of the sensor is specified to include the corresponding Python class and retrieve the configuration file from the central HUB, which performs the proper request to the Drivers Catalogue. In this way, the user relies on the most recent updates after each rebooting. The central HUB also provides the MQTT broker address so that each sensor can act as a publisher for communicating with the server. The software design is effective because it is based on the proper use of MQTT topics. Each message is published defining the platform ID, room ID and name of the sensor directly on the topic (e.g., MP-A00013/room X2/dht22 for the humidity sensor). Exploiting the MQTT wildcards system, the subscriber can easily retrieve the required measurements (see Supplementary Material).

To ensure easy deployment of the kit, the operative system of the Raspberry Pi is cloned on an SD memory with the proper settings and configurations, ready to run on a new platform. A script to automatically installs the software according to the ID of the platform included, together with an auto-run command. It automatically runs all the needed processes to boot the platform when it is connected and powered on or after rebooting. On the first configuration, it is required that the user connects the platform to the local Wi-Fi network. This operation can be done by exploiting the ssh connection of the Raspberry Pi or editing the configuration file in the SD card. After the first initialisation, the software is automatically launched on reboot.

3.4. Data Collection and Communication Protocols

For testing the developed system in operation, the three mentioned monitoring platforms are given to three different voluntary users. This scenario is extremely important to analyse the response of the back-end, the reliability of the mobile application, and the feasibility of platforms installation leaving this task to the final testing users. Moreover, migrating the testing scenario from a local network to the public Internet allows the detection of errors and further points of failure. After initial tests of the system for ensuring robustness to the described conditions, the platforms are placed in three different buildings, related to three distinct users (residential flats). For this test, the platforms MP-A00003 and MP-A00013 were located in two different zones of Nichelino, a city near Turin, whereas MP-A00014 was in Turin. Additionally, each user is responsible for the setting of its own platform according to the desired preferences, similarly to any commercial IoT device, by following a simple instruction list.

Except for the first association to the specific domestic Wi-Fi connection, platforms are completely manageable via application once they are set up. This aspect is particularly important for end-users without specific computer skills and makes the system able to be simply implementable in the future for applications like educational activities and citizen sciences. When associated, platforms start to continuously collect data that are stored by the server database. Each sensor relies on information automatically provided by the downloaded drivers of the central HUB. The possibility to follow this specific configuration supports the developers in designing a more accurate system with potential future implementation by remote. For instance, the interval of time between two consecutive measurements can be set independently for each sensor. For this test, all sensors have been designed to send new data every 30 s. This interval is short enough to provide real-time information, without detecting any overload issues on the back-end side for the given scenario. In addition, sensors perform basic checks on the feasibility of the obtained measurements, avoiding sending to the server erroneous values. Therefore, by exploiting timestamps, it is easy to detect inoperative sensors. Lastly, the communications protocols introduced in Section 2.1 are carefully implemented to link the different components of the system for data exchange among platforms and servers. The overall design is shown in Figure 6. For each platform, the central HUB performs requests to the server through HTTP before making them locally available. Additionally, rooms and sensors exploit HTTP to contact the central HUB and to communicate with the back-end for the first installation. However, to support the continuous stream of information, sensors use MQTT for sending data about environmental conditions, as mentioned in Section 3.3.2. Then, for each measurement, if the last information is older than 5 min, the back-end updates the Influx DB database. In parallel, if the PMV value is outside the suggested range, a warning message is automatically generated. In order to not bother users, messages are limited to no more than one per hour. In this case, the server acts as a publisher using the proper topic /warning/platform ID/room ID—where platform ID and room ID refer to the unique identifier of the involved platform and room—while the communication is sent to the user through the mobile application, acting as a subscriber.

4. Implementation of Data Visualisation and User Interface

Considering end users, an essential aspect to make the proposed platform useful and adopted is the possibility to allow them to visualize results. In the proposed system, the client interface is represented by a mobile application developed at present for Android devices. It supports users in data visualisation as well as in managing platforms, defining settings and starting new installations. Server communications are performed relying on HTTP requests to minimize requirements expected by the application. In parallel, the application acts as an MQTT subscriber for receiving alerts. However, this feature can be disabled by the user of each platform if unwanted. The final version of the application is distributed to the three voluntary users for testing purposes.

4.1. Android Application

4.1.1. Homepage

When the application is launched, the user is first requested to perform the login or to create a new profile. Secondly, the homepage is available, showing the implemented functionalities—see Figure 7a. Users may navigate between activities using interconnection links without the need to return to the homepage after each activity. The navigation bar is customised according to the specific activity. In this way, the application is more reactive to user needs. Additionally, the homepage is a first overview about external conditions is given, based on the location set by the user. The spinner allows one to select the desired platform and easily access the related settings—see Figure 7b—or the list of associated platforms—Figure 7c. Finally, using the plus button, the user can easily add new platforms and/or rooms.

4.1.2. Room Overview

Once the My Overview activity is selected—see Figure 7a—the application retrieves information about different rooms which are registered for the selected user platform—see Figure 8a. When the page is refreshed, data are updated. Therefore, users have a real-time summary of the entire building, with the first overview of indoor conditions and corresponding PMV. When the user ‘virtually’ enters the room, the complete overview is displayed—Figure 8b—showing the clothing insulation and the metabolic configuration, measurements from the sensor network, PMV and PPD values. The implemented shortcuts allow the user to quickly access the room settings, visualize graphs, check the sensors configuration, such as shown in Figure 8c, or provide feedback about thermal comfort.

4.1.3. Warning Messages and Push Notifications

Three different types of notifications are currently implemented in the proposed monitoring system:

• Feedback reminder. For testing purposes (facultative), the user periodically provides the actual feeling about the thermal comfort, choosing among the following categories {ok, cold, too cold, hot, or too hot}. Feedbacks are then stored by the server in the specific Influx DB database.
• Association performed. It is used to notify the user of the correct installation of a new platform or a new room. The user is, therefore, informed that the configuration is completed and the platform is collecting data.
• Alerting. If the PMV is outside the suggested range, the system warns the user about discomfort conditions.

However, realising potential future updates, it is easy to include new typologies of messages and notifications.

4.2. Grafana

Grafana is a multi-platform open source web application providing tools for the analysis and visualisation of data from different data-sources. In particular, a specific Grafana dashboard related to data collected from each platform is defined to be accessible to the associated user from the Android mobile application.

4.2.1. Grafana HTTP API

The Grafana back-end exposes an HTTP API that is used to automatically create and manage new users, data sources and dashboards. When a valid new platform is registered through its ID, a new Organisation with the same platform ID is created in Grafana. Organisations are employed to create private environments, accessible only by users belonging to the specific organisation. New users are inserted into the list of authorised users with a viewer role and credentials for authentication. Hence, users can safely access the Grafana web page related to their organisation using ID and password. They can view dashboards, but they are not allowed to add, edit or delete any dashboard components, while data related to each user are stored in a different JSON file. Secondly, regarding the creation of the data-source, the operation is performed exploiting the data-source HTTP API, using the API key of the corresponding organisation. The data-source is created by specifying the turn of the Influx DB database in which data are stored, assigning the same name of the platform ID. By this way, Grafana data-sources will collect only data related to the corresponding platform. Once the organisation, user and data source have been linked to a platform through its ID, a Dashboard can be created inside the organisation environment. When the user registers a new room through the mobile application, the HTTP API instantiates a new dashboard using the API key of the corresponding organisation for authentication. A predefined JSON model is imported, in charge of completely describing the structure and style of the final dashboard. The JSON model is automatically modified by properly setting the right data-source and the tag corresponding to the room ID. Hence, only data corresponding to the right room is taken from the organisation data-source. The title is also updated in the model and a unique identifier (uid) is associated with the dashboard. The uid is then exploited to provide access to the end user. In fact, through the mobile application, the user sends a GET request to the server specifying the uid. The server, on the other hand, returns the public link to the corresponding dashboard which will be open in a web view in the application.

In addition, two other functions have been implemented for allowing users to change room names, and consequently the dashboard, and to delete a dashboard when the corresponding room is deleted or removed from the platform.

4.2.2. Grafana Dashboard

The Grafana dashboard was created to support data visualisation for a specific room. It includes graphs, time series and statistical analysis. The proposed dashboard is organised into three sections. The first one is devoted to data and statistic visualisation regarding PMV and PPD indices. Instead, the second one shows indoor parameters, such as temperature, humidity and air velocity. Finally, the third one provides access to data regarding the external weather conditions and the corresponding comparison with indoor data. An example of the first section can be seen in Figure 9. On the left, two gauges show the current values of PMV and PPD, while the set values for clothing insulation and metabolic rate are displayed on the top. Two time series highlight how the PMV changes with respect to these two values. In addition, another time series shows the average hourly values for the PMV and the corresponding PPD in the last 24 h, with the optimal PMV range being highlighted in green. Moreover, statistical data about average, mode, minimum and maximum values for the PMV in the last week can be observed. Lastly, the user can appreciate a heat map showing the PPD trend in the last 24 h and the last feedback sent, along with its corresponding timestamp.

The second section of the dashboard is shown in Figure 10. In the top left quadrant, the current values of air temperature, mean radiant temperature, air velocity and humidity are shown in four gauges. Differently, in the top right quadrant, the two curves representing the average values of air temperature and radiant temperature are shown (sampled every 30 min). The table in the bottom left corner provides instead a list of average hourly values for the two temperatures. A statistical analysis of the parameters measured in the last week completes the picture, including average, minimum and maximum values registered for air temperature, mean radiant temperature, humidity and air velocity.

The last dashboard section includes data from the external API concerning outside weather conditions; see Figure 11. The geographical position of the platform is displayed on a map, together with the name of the city and the current weather conditions, i.e., temperature, apparent temperature, humidity, wind velocity and direction. In the bottom portion, users can appreciate two-time series related to data from the last 24 h, comparing internal monitored temperature with external and apparent temperature, and internal monitored humidity with external humidity.

5. Application Results and Discussion

After designing and implementing the system, several tests were performed to analyse its responses in different scenarios. In particular, each sensor has been individually tested to verify its correct operation and to detect potential anomalies. Similarly, the PMV/PPD model has been analysed by exploiting different configurations and environmental conditions to assess the general responses. By producing and distributing three platforms among different users, it was possible to solve specific issues concerning public communications among the clients and server. After successfully integrating the whole system, data were collected during the testing monitoring phase to further analyse the obtained results.

5.1. Data Analysis

The first platform we tested (ID: MP-A00003) collected data constantly for about five months in a residential house in Nichelino (Turin) from March to mid-July 2021. In this subsection, however, only the results of March, April and May are analysed. The variability of weather conditions provides interesting insights concerning the thermal comfort responses. The measured parameters are summarised in

Table 2. Mean monthly values of monitored parameters of the first testing platform.

Month	Temperature	Humidity	MRT	Air Flow
March	20.42 °C	53.43%	21.97 °C	0.063 m/s
April	20.67 °C	55.33%	22.43 °C	0.270 m/s
May	21.87 °C	50.54%	23.46 °C	0.241 m/s

—the average value of each parameter is shown for each month. Figure 12 describes, instead, user preferences in terms of clothing insulation, by averaging the information provided via the application according to reasonable time slots of the day for each month. As expected, in March the clothing insulation was higher, close to the typical winter level (1 clo). Instead, May and April were characterised by lighter weight clothes, similar to the ones expected during summer (0.5 clo). Differently, focussing on the metabolic rate, the set value by the user was always between 1.2 met (normal desk activities) and 1.5 met (light standing activity) for the whole period.

Figure 13 shows the evolution over time of the PMV value, grouping results by the hour of the day (average monthly). The picture supports the analysis of potential trends following a 24 h scheduling approach. Especially for March, it is possible to observe a reasonable increase in discomfort during the night, especially in early-morning hours, but the thermal comfort returns within the suggested range when approaching midday—i.e., the green sector which is representing ±0.5 PMV, comfort category II limits of EN 16798-1:2019. Similar behaviour is also shown for April, even if, in this case, the effect is mainly visible between morning and afternoon, indicating the positive effect of solar gains. However, despite the arrival of spring, the considered room was actually providing a colder environment than in March, due to the fact that the heating system was turned off during this month—i.e., by the 15th of April. Among possible reasons, the significant change in clothing level could also be mentioned as the main cause. Since summer clothes were not appropriate for the given thermal conditions, the user could rely on the monitoring system for planning possible actions to achieve proper comfort conditions according to the desired preferences, particularly for the hours in which discomfort is more evident, i.e., during the second half of the night. Considering the whole month, April shows an average PMV value equal to −1.01 and a PPD equal to 29.71%, corresponding to a cool environment. March, instead, is characterised by average neutral conditions, with a PMV equal to −0.44 and a PPD equal to 11.57%. Comparable results were also obtained for May, in which the average PMV was −0.51 and the average PPD was 13.55%. However, for the latter, the distribution over time was more unpredictable. In fact, the evaluated thermal comfort exceeded the optimal limit at different hours of the day, especially in the afternoon. Additionally, in this case, from Figure 12 it is evident that the clothing level was lower in that section of the day. Moreover, it should be noticed that people tend to change habits when a new season arrives. Considering Northern Italy and the specific climate zone of Nichelino [68], heating systems are still employed in March and windows are in general opened less frequently compared to May—see also the increase in measured indoor air velocities shown in Table 2—while the impact of solar gains is growing with respect to winter. This aspect, combined with the already mentioned considerations about clothing, leads to a more difficult environment to be managed in terms of PMV/PPD thermal comfort during April and May, being characterised by free-floating conditions—see also [19,60,61].

Finally, considering the whole period, Figure 14a summarizes the thermal comfort conditions observed in the monitored room. In parallel, periodical feedback was sent by the user via the mobile application so that we could make a direct comparison with the estimated results, which is shown in Figure 14b. The user had the possibility to choose from a simplified version of comfort ranges in order to provide an intuitive selection. Given the natural subjectivity of thermal comfort, different users can prefer slightly warmer or slightly cooler environmental conditions. The pie graphs show that only 23.74% of the time, the PMV was estimated to be within the neutral range, but the user was actually satisfied 56.73% of the time. However, considering the limited options for feedback and potential preferences, it is reasonable to assume that “slightly cool” conditions are positively perceived, especially when considering that a part of the monitored period is concerned with free-floating conditions. In this case, results in the extended comfort zone are remarkable, i.e., 62.16% vs. 56.73%. Similar values were also retrieved for “cool” conditions, although the 2.88% of “warm” feedback highlights that it is not possible to exactly predict all user feelings. Over the whole period, the user was estimated to experience slightly cool conditions on average, with an average PMV equal to −0.865 and an average PPD of 25.1%.

5.2. Comparison among Platforms

5.2.1. Multi-Month Comparison Period

In the period ranging from the 9th of May till the 14th of July, an additional monitoring platform located in a different building in Nichelino was available (ID: MP-A00013). The corresponding platform’s average values are shown in

Table 3. Average parameters for the two considered platforms.

	MP-A00003		MP-A00013
	Mean	St.dev.	Mean	St.dev.
Air temperature	25.91 °C	1.97	25.38 °C	2.19
MRT	27.74 °C	2.35	26.63 °C	2.19
Humidity	54.33%	6.99	51.56%	4.96
Air velocity	0.405 m/s	0.418	0.223 m/s	0.254
Clothing insulation	0.384 clo	0.148	0.633 clo	0.230

. For both platforms, the metabolic rate was constantly in the range of 1.2–1.5 met. The environmental conditions were similar, though there were slightly higher values of average temperature (∆temperature = 0.54 °C, ∆MRT = 1.10 °C) and humidity (∆humidity = 2.76%) for the MP-A00003 platform. However, differences are remarkable in terms of air velociy (∆air speed = 0.182 m/s) and clothing level (∆clo = 0.249 clo).

This analysis allowed us to test differences in behaviours (both user and building ones) under the same external environmental conditions—both buildings being located in the same Municipality. Figure 15 shows changes over time of the average PMV value for each day of the studied period. In particular, the red line describes the external temperature trend to provide additional information regarding actual conditions. As expected, the external temperature increased over time for natural seasonal changes. The green area represents the optimal range for PMV thermal comfort defined as the boundaries of comfort class II.

Focussing on average daily PMV values, the two considered platforms had significantly different behaviours. However, both platforms demonstrated the ability to react to stimuli, showing an increase in thermal comfort values when days started to be warmer. For the initial month, station MP-A00003—see also the description in Section 5.2.1 for May—was characterised by negative values and PMV was occasionally outside the suggested range. On the contrary, the calculated thermal comfort index for platform MP-A00013 was consistently within the optimal range until mid-June. During the following warmer days, i.e., the second half of June, the PMV of this second platform frequently had daily values above the optimal threshold, corresponding to warmer thermal conditions. This highlights the natural importance of clothing insulation, which was the main difference among the two considered monitoring systems. The user associated with platform MP-A00013 showed less tolerance for cold environments, preferring warmer clothing: the mean value was 0.901 clo in May vs. 0.622 clo for MP-A00003, and it was 0.548 clo in summer vs. 0.318 clo for MP-A00003.

Focussing on July, it is interesting to observe how the estimated thermal comfort drastically dropped following the worst weather conditions in Nichelino, with general lower external temperatures, strong winds and rain. Given the set configuration of clothing, based on previous warmer days, it was inadequate for the actual thermal conditions, and both platforms quickly detected the significant change. For platform MP-A00003, a small level of discomfort was underlined during the coldest days. Differently, the second user, i.e., MP-A00013, reacted to the new thermal conditions by increasing the clothing insulation, passing from 0.5 clo to 0.8 clo. This reaction had an effect: from the 9th of July, the PMV values were higher with respect to the previous platform.

Table 4. Thermal comfort results for the two distinct platforms.

	MP-A00003			MP-A00013
	Mean	Mode	Stud	Mean	Mode	Stud
PMV	0.088	−0.043	0.499	0.328	−0.102	0.397
PPD	10.212	5.000	9.748	10.575	5.000	6.675

summarises room performances with respect to PMV and PPD. It is evident that the first platform provides almost neutral conditions with PMV close to 0. Differently from previous months (March and April), in fact, platform MP-A00003 maintained satisfying thermal comfort conditions on average during the considered period, thanks to the warmer days of June. Changes in the calculated PMV are remarkable, however, when the different months are considered: the mean value is −0.514 for May, but 0.19 for June and July. Differently, when focussing on the MP-A00013 platform, conditions were neutral in May, with an average PMV value equal to −0.034, and it became warmer in the following months with a PMV value equal to 0.432. Since both platforms ensured average general conditions in the optimal range, the PPD values are comparable and relatively low. However, by observing the standard deviation for both PMV and PPD, we can see that platform MP-A00003 is prone to larger variations of thermal comfort, while MP-A00013 has a more uniform distribution over time. Therefore, despite the estimated average neutral conditions, platform MP-A00003 detected more variation in thermal conditions, leading to moments characterised by discomfort.

In order to perform additional evaluations for the thermal comfort responses of the two platforms, the corresponding PMV values are classified in Figure 16 according to specific ranges. As expected on the basis of previous considerations, the graph clarifies the general distribution of results. This is important for a final evaluation of the thermal comfort performances of the two monitored building rooms, given the specific configurations. Platform MP-A00003 was characterised by a more heterogeneous distribution, including all the possible conditions between “cool” and “warm”. Differently, MP-A00013 has 81.0% of its PMV values within the optimal range, proving acceptable thermal comfort conditions for the simulation period. Besides the clothing difference, the higher value of airspeed recorded in MP-A00003 suggests the presence of higher airflows, related to different habits concerning the use of windows for natural ventilation.

Finally, both users periodically provided feedback regarding their actual sensations. Figure 17 shows the feedback distribution for the two platforms. The results are consistent with the above analysis for the PMV values calculated by the system. The user associated with platform MP-A00003—see Figure 17a—experienced satisfactory conditions 46.48% of the time. The second user—see Figure 17b—considered the thermal conditions more appropriate, being satisfied 74.14% of the time. A difference in the preferences of users is evident: the first user is more susceptible to warm conditions, indicating warm and hot discomfort 33.81% of the time, whereas the second user mainly indicated discomfort in cool conditions (17.24% of the time).

5.2.2. Three-Station Comparison—Short Periods

In order to analyse in more detail, the platforms’ behaviours, the first one-week period was selected (19–25 May 2021). This comparison includes data retrieved by the third platform (ID: MP-A00014), placed inside a massive old building in Turin, built in the late XIX century.

Table 5. Average values in the monitoring period for the three platforms.

	MP-A00003		MP-A00013		MP-A00014
	Mean	St.dev.	Mean	St.dev.	Mean	St.dev.
Air temperature	22.63 °C	0.67	21.69 °C	0.34	22.23 °C	0.65
MRT	24.02 °C	0.64	23.00 °C	0.43	23.94 °C	0.63
Humidity	49.76%	8.21	49.02%	5.99	63.33%	4.67
Air velocity	0.259 m/s	0.460	0.08 m/s	0.043	0.311 m/s	0.161
Clothing insulation	0.685 clo	0.156	0.824 clo	0.083	0.993 clo	0.037

shows the mean value for each parameter for each platform. These results underline the specific behaviour of each monitored building. Platform MP-A00014 (historical building) was in a more humid place than the others, showing differences between 13.52% and 14.31% in relative humidity compared to the other two platforms. Moreover, users associated with platforms MP-A00003 and MP-A00014 preferred ventilated rooms, the monitored air velocities being higher than those of user MP-A00013. The large standard deviation highlights the dynamism of this parameter that is associated with manual window opening.

Figure 18 shows the evolution of PMV values for the three platforms. Except for the first portion of the considered period, in which MP-A00003 detected a colder environment, they all registered similar behaviour within the comfort range (Class II). This result is interesting since thermal comfort was achieved despite the differences in terms of air parameters and user preferences, supporting the fact that all users were able to adapt in order to balance building, environmental and personal parameters in their houses. In particular, MP-A00003 was characterised by higher values concerning air temperature and MRT. Consequentially, the adopted clothing insulation was lower compared to the other users, who preferred clothing levels similar to those for winter. The depicted situation is coherent with environmental conditions retrieved by the wheatear API system, including some rainy days, with a mean external air temperature of 16.36 °C, a mean external relative humidity equal to 54.95% and a mean external apparent temperature of 15.79 °C in Nichelino; in Turin, the same parameters were 13.02 °C, 63.98% and 12.12 °C, respectively.

PMV and PPD results are summarised in

Table 6. Average PMV/PPD values for the three platforms.

	MP-A00003		MP-A00013		MP-A00014
	Mean	Stud	Mean	Stud	Mean	Stud
PMV	−0.332	0.594	−0.112	0.183	0.093	0.201
PPD	13.077	17.786	5.966	2.321	6.021	1.553

. The slightly lower PMV value for MP-A00003 led to the more significant PPD, i.e., 13.08%, with less continuous comfort results.

An additional comparison was performed in order to evaluate the behaviour of the three locations during warmer days. This second short comparison period covered 13 June 2021 to 22 June 2021. The thermal conditions were characterised by significantly higher temperatures for all platforms with respect to the previous analysis, in terms of both air temperature and MRT. Platform MP-A00014 also had, in this case, a slightly higher level of humidity—the site was in Turin, not far from the river Po. In all cases, the warmer climate induced users to adopt different strategies in terms of ventilation, especially in window utilisation. Differently from May, the measured air velocities were considerably higher in all sites, especially in platform MP-A00014. The results for the latter suggested that the kit may have been positioned in an exposed airflow site, e.g., in proximity to either a window or a ventilation system. The tenants confirmed that during this period, windows were left open continuously and that the kit was in the centre of a room facing a main window. Finally, the clothing insulation was the same for MP-A00013 and MP-A00014, but the user of platform MP-A00003 was characterised by lighter clothes.

Table 7. Main parameters for the three distinct platforms in summer.

	MP-A00003		MP-A00013		MP-A00014
	Mean	St.dev.	Mean	St.dev.	Mean	St.dev.
Air temperature	27.92 °C	0.70	27.47 °C	0.62	26.90 °C	0.70
MRT	29.71 °C	0.97	28.66 °C	0.74	29.01 °C	0.64
Humidity	56.00%	5.38	52.36%	4.07	59.12%	5.98
Air velocity	0.526 m/s	0.414	0.251 m/s	0.121	2.08 m/s	0.419
Clothing insulation	0.324 clo	0.065	0.500 clo	0	0.500 clo	0

shows average parameters during this period.

The evolution of PMV values over the given period is depicted in Figure 19. The graph shows that platforms MP-A00003 and MP-A00013 behaved differently from platform MP-A00014. In the former cases, warmer thermal comfort values were calculated and for several hours were above the PMV upper boundary levels of class II, i.e., they were hot environments. Differently, the latter station was in the comfort range during the entire period, showing even slightly cold behaviour. This difference is, however, consistent with expectations, since the third station was positioned in an ancient building characterised by very massive walls, i.e., ranging from 60 to 80 cm of rock and brick, and in a north-facing room. Additionally, MP-A00014 was characterised by higher air velocity values, as the windows were always open. In the summer period, this level of natural-driven ventilation ensured thermal comfort for occupants, who reasonably preferred a slighter cooler and ventilated environment.

Table 8. Average thermal comfort values for the three platforms in summer.

	MP-A00003		MP-A00013		MP-A00014
	Mean	Stud	Mean	Stud	Mean	Stud
PMV	0.466	0.421	0.772	0.232	−0.190	0.238
PPD	13.211	8.563	18.684	6.847	6.935	2.484

shows the average values of PMV and PPD during the considered period. In line with the above figure, MP-A00014 provided the minimal value of potentially dissatisfied people (PPD 6.935%)—the PMV being nearer to the neutral value. MP-A00003 was just within the upper level of the comfort boundary. MP-A00013 had a warm environment according to the PMV. This outcome is, however, also coherent with the previously deduced preference: the user of MP-A00013 being more comfortable with a warmer environment. Clearly, in the same room, different people will experience different sensations and potentially discomfort, as suggested by the higher value of PPD. Additionally, MP-A00003 was characterised by a larger standard deviation for both PMV and PPD, indicating less uniform thermal conditions over time.

6. Discussion and Conclusions

In this paper, we introduced the initial configuration of an IoT monitoring system for detecting thermal comfort conditions in buildings. The kit was conceived to be low-cost, and the initial tests were very positive, even in real environmental conditions, although future improvements are needed to potentially increase the number of connected kits; fix unstable breadboard connections; increase the number of comfort models and parameters to be detected; and increase the robustness of the system, e.g., by reducing the risk for data loss, including local storage capabilities. Focussing on potential sensor faults, the resource catalogue tracks each sensor’s status according to the last measurement received. If a sensor is faulty, it is not sending any live messages to the catalogue, and therefore, after a given inactive time threshold (which can be set by the mobile application), the sensor will be considered dead and removed from the list of available sensors. Users may check the status and the timestamp for each sensor via the application. Through the reboot button, it is possible to reinitialize the process without losing stored information to fix possible software errors. During future expansion, an additional alert message will be included to inform users of the need to physically replace faulty sensors. Furthermore, to allow citizen science usage of a large set of kits, the hardware configuration needs to be upgraded to pass from breadboard conditions to pre-assembled stable solutions, e.g., including PCB development and pre-soldering actions. Additionally, at present, the sensor platform positioning was directly suggested to end-users, whereas in future development steps a short manual will be prepared using standard related suggestions, e.g., one kit for monitoring areas up to 50 m² positioned at about 1.5 m from the soil for CO₂—see ISO 16000-26 [69]. Nevertheless, currently, the system implementation complies with the design objectives set during the planning phase. Moreover, all technical requirements mentioned in Section 2 will be discussed. In particular, to support scalability and modularity, the proposed system was tested under different domestic Wi-Fi connections, leaving to not-expert end-users the task of connecting the prototyped monitoring kits to their local internet routers. Additionally, even though the tested configured server was hosted by a Raspberry Pi with limited capabilities, the back-end was designed to be migrated to a more powerful machine. Thanks to the exploitation of the micro-services approach with the development of a registration catalogue, services can safely run on different nodes to distribute the computational effort. Therefore, scalability is an important strength of the proposed solution. To support the zonal division of buildings and rooms of each user, additional platforms are hierarchically organised by referring them to a single central HUB of the specific user. Focussing on decentralisation and adaptability, the back-end is responsible for mathematical computations and storage activities, hosting the core functionalities of the system. This choice significantly reduces the computational capabilities required by the end-user platforms, reducing correlated costs. The system is, therefore, able to adapt to upgrades and new configurations in terms of both hardware components and software implementation. In addition, the flexibility of the proposed design allows the platforms to properly work even with different sensor network configurations. Software choices are able to support a proper protocol implementation considering the main IoT paradigm, to guarantee an efficient architecture for the communications that are required.

The proposed system is designed to be open to external resources, merging local data with information retrieved from public APIs and databases, i.e., weather services. Finally, the system was designed to automatically manage new users, and additional dashboards and services, and to solve errors. Similarly, large efforts were made to keep the platform kit simple and able to be easily configured and maintained, supporting a plug-and-play approach. When a new kit is prototyped, no particular technical skills are required for end-users to install and use the system, even if the initial configuration may be modified by an expert user at the current stage (beta-version). Flexibility and modularity are key aspects to ensure a competitive product, allowing further updates and improvements in terms of hardware, software and general functionalities. Additionally, new sensors and public APIs could be integrated to extend application fields. During future phases of the ongoing research project, these issues will be faced, and a second version of the system will be produced to be adopted in a large city science activity.

Focussing on the tests we performed, the proposed IoT system underlines the importance of the collection of personal parameters via the developed application and the interesting correlations between user perception and personal expectations. In order to obtain accurate results, proper configurations of clothing insulation and metabolic rate are in fact necessary. A potential development path may include the adoption of machine learning techniques to support customised predictions of user thermal comfort preferences. The flexibility of the proposed system satisfies the demand for potential multiple targets, leaving to different users the possibility to adapt their data via personal interactions. In the planned future citizenship science applications, this specific point will be stressed in rooms characterised by many occupants, i.e., school rooms. However, the already performed tests also show how the system may be used to perform seasonal analyses to study different building responses to variations in ambient conditions. The implemented model supports users making changes thanks to the proposed feedback application’s utility, though the impact of the alerts on the conditions was not studied in this paper. Platforms also individually provide the measured parameters and the associated statistics via the dashboards, increasing the user’s ability to understand his/her building’s behaviour. Therefore, the project was actually able to guarantee an operative beta-version of a low-cost and scalable IoT monitoring system, relying on a back-end fully modelled according to the desired specifications, and providing a proper graphical interface for data visualisation and platform management.

In conclusion, focusing on innovative aspects of the proposed monitoring solutions, it is possible to mention that:

• Despite the educational purpose of the project, the proposed architecture, which is dependent on an extremely limited number of external services, is able to guarantee the system’s flexibility and modularity, ensuring the possibility of easily including new functionalities even at run-time.
• The overall cost of the system is notably low since it is self-monitored and it includes relatively cheap but accurate sensors, including uncommon ones (i.e., air velocity and a globe thermometer), allowing one to retrieve important comfort indicators, i.e., PMV/PPD, but also operative temperature. The system may also be easily reproduced and upgraded.
• The final product is user-friendly, in terms of both setup and user interface. Users are supported by alert messages with coherent tips with the actual conditions, an accurate dashboard to meet different users’ needs, external weather conditions and the possibility to customise and manage the installed platform via an application.

Additionally, the following aspects will be of primary interest for future expansions:

• The subjectivity of thermal comfort is a crucial aspect. Even in similar environmental conditions, different users experience significantly different sensations. This aspect needs to be explored deeper in future works by also including prediction capabilities and supporting machine learning techniques to support personalised suggestions.
• The automation of the system should always be strictly related to the final purpose. Our users confirmed the importance of allowing the possibility to provide feedback, and of editable settings (i.e., clothing level and room activity), measuring which gave us a better understanding of their behaviours. Extra developments are suggested to increase alert types and actions, to eventually include proactive optimisation.
• Data analysis provides important insights concerning the thermal conditions of different buildings. It may underline both individual preferences and building construction types. This aspect could be important also in terms of developing personalised machine-learning driven suggestions, i.e., HVAC scheduling.