Comparing Monitoring Networks to Assess Urban Heat Islands in Smart Cities

Abstract

The increasing frequency and intensity of heat waves, combined with urban heat islands (UHIs), pose significant public health challenges. Implementing low-cost, real-time monitoring networks with distributed stations within the smart city framework faces obstacles in transforming urban spaces. Accurate data are essential for assessing these effects. This paper compares different network types in a medium-sized city in western Spain and their implications for UHI identification quality. The study first presents a purpose-built monitoring network using Open-Source platforms, IoT technology, and LoRaWAN communications, adhering to World Meteorological Organization guidelines. Additionally, it evaluates two citizen weather observer networks (CWONs): one from a commercial smart device company and another from a global community connecting environmental sensor data. The findings highlight several advantages of bespoke monitoring networks over CWON, including enhanced data accessibility and greater flexibility to meet specific requirements, facilitating adaptability and scalability for future upgrades. However, specialization is crucial for effective deployment and maintenance. Conversely, CWONs face limitations in network uniformity, data shadow zones, and insufficient knowledge of real sensor situations or component characteristics. Furthermore, CWONs exhibit some data inconsistencies in probability distribution and scatter plots during extreme heat periods, as well as improbable UHI temperature values.

1. Introduction

Currently, more than half of the world’s population lives in cities, a figure projected to increase to two-thirds by 2050 [1]. This rapid urbanization presents one of the most pressing challenges of the 21st century: the sustainable management of urban planning and the enhancement of urban public spaces to promote both physical and mental well-being at individual and societal levels [2].

In response to these challenges, the convergence of effective urban governance and the digital revolution has precipitated the metamorphosis of ‘traditional cities’ into ‘smart cities’. These cities leverage environmental data collection, integration, and analysis to improve citizens’ quality of life and optimize decision-making and management processes [3].

Numerous networks and organizations play a critical role in fostering global collaboration among stakeholders to advance and implement smart city technologies. Key initiatives include Open and Agile Smart Cities [4], Global Smart Cities Alliance [5], Program on Smart Cities and Inclusive Growth [6], and The Smart Communities Network [7]. Within this framework, the Internet of Things (IoT) has enabled diverse applications in smart cities and buildings, spanning mobility [8], waste management [9], healthcare [10], environment, and more [11].

Monitoring indoor comfort and occupant well-being has seen significant progress [12]. The Public Space Charter underscores the importance of adapting public spaces to local climatic conditions, not only to enhance environmental quality but also to mitigate climate change and urban heat island (UHI) effects [13]. This issue has become increasingly salient due to the significant impact of climate change on urban environments. The IPCC warns of rising global temperatures and more frequent, intense heatwaves, which are expected to increase heat-related mortality, especially in densely populated cities—necessitating robust adaptation strategies [14].

A key phenomenon in this context is the urban heat island effect, characterized by elevated temperatures in urban areas compared to their rural surroundings, particularly during summer [15]. The phenomenon is primarily attributable to anthropogenic activity and urban infrastructure, deforestation and shading, and using heat-absorbing materials [16]. Long-term, high-resolution studies of diurnal surface temperatures reveal that 3-day extreme temperature differences between urban and rural areas can exceed the seasonal median by more than double, with local variations reaching up to 10 °C [17]. In small and medium-sized cities, these differences typically range from 2 to 7 °C [18,19,20,21,22].

To define and assess UHIs and develop mitigation strategies, it is essential to analyze hygrothermal data from sources such as satellites, meteorological stations, climatological records, and Earth observation systems [23]. The WMO provides guidelines for measuring climatic variables at different scales to ensure measurements’ accuracy, consistency, and quality from in situ sensors (e.g., those used in weather stations) and complementary sources such as satellites, weather radars, and climate prediction models. These guidelines encompass a range of aspects, including measurement instruments (the definition of sensor requirements in terms of accuracy, consistency, quality standards, calibration, and so forth) and the measurement techniques, which encompass both manual observations (with traditional weather stations) and automated methods (with remote monitoring) [24].

Satellite and remote sensing data have enabled systematic SUHI studies [25], including MODIS [26], Landsat [27], and, to a lesser extent, Sentinel [28]. However, satellite data face inherent limitations, including inadequate resolution, the difficulty correlating surface and canopy temperatures [29], the necessity of clear sky conditions for precise measurements, and the complexity of providing three-dimensional urban information [30]. Consequently, using auxiliary sources, such as weather stations, as evidenced by a substantial study conducted in China, becomes imperative to substantiate remotely sensed data [31].

Urban sensor networks have emerged as vital tools for weather data collection and analysis, supported by initiatives like the Smart Cities Marketplace [32] and the Smart Cities Information System [33]. The EUMETNET community, comprising European National Meteorological and Hydrological Services (NMHSs), has promoted citizen cooperation in weather monitoring [34]. This community obtains data mainly from four sources: Netatmo, a manufacturer of smart home devices; Sencrop and WEENAT, which are used for agricultural purposes; and the Weather Observations Website (WOW), which enables users to register CWS from different providers to automatically upload weather observations [35].

Numerous studies have utilized CWS data for UHI research. For instance, WU and HetWeerActueel were used to investigate urban effects on temperature and precipitation in the Netherlands [36]. In London, Netatmo data revealed temperature differences of 1 to 6 °C [37], while a Berlin study using 1500 stations highlighted the importance of data quality and representativeness [38]. In Vienna and Amsterdam, comparisons were made with reference stations [39,40]. These findings underscore the potential of CWS networks in UHI research, while also emphasizing the need for rigorous quality control due to their variability and lack of standardization compared to NMHS stations. A range of quality control procedures have been the subject of study; notably, A. Napoly et al. [41] developed a statistically based quality control system for crowdsourced air temperature data.

Other experiences are based on deploying their own networks to provide CWS availability in a particular area or density. Several notable instances of success with commercial devices have been documented. In Taiwan, mobile transect measurements were combined with fixed stations using low-cost sensors [42]. A similar approach was developed in Chile, identifying UHI ranging from 0.5 °C to 13 °C [43]. In Rome, a study utilized monthly maximum and minimum climate data from urban fixed stations and reference airport stations to dynamically simulate the impact on building energy performance, with maximum UHI intensities ranging from 3.1 °C during the day to 3.5 °C at night [44]. Regarding the use of proprietary networks and custom-built stations, a study conducted in Taipei investigated the impact of vehicular traffic on UHI intensity. This was achieved through the deployment of high-precision sensors shielded from solar radiation, Arduino-based devices, and installations positioned between 3 and 4.5 m above ground level [45]. Similarly, in London, Arduino technology was employed to assess whether low-cost sensors could detect small-scale temperature variations [46]. The Birmingham Urban Climate Laboratory provides an overview of the logistical aspects of implementing an urban weather network, including selecting suitable locations, equipment testing and calibration, quality control mechanisms, and using existing Wi-Fi networks for data transmission [47].

Furthermore, other issues have received less attention. These include selecting IoT communication protocols that optimize range, data transmission speed, energy efficiency, and cost-effectiveness [48]. The utilization of RTD, which is pivotal for smart city networks [49], and the implementation of scalable information system architecture and open-source hardware and software should be incorporated into any current network.

Moreover, the quality of RTD network records based on low-cost stations for UHI identification has not been systematically validated [38]. While CWSs are fundamental in collecting urban climate data, sensor precision variability, station location differences, and lack of standardization in data collection methods can affect the reliability of results [50].

Consequently, it is essential to benchmark these systems against WMO standards in order to identify areas for improvement and develop best practices in urban climate monitoring [51]. Despite the fact that the WMO provides recommendations for measuring climatic variables, there is a paucity of detailed documentation on the design and implementation process in specific environments, which limits replicability in other cities.

2. Materials and Methods

The main objective of this article is to compare the characteristics (components, performance, and placement of measuring points), value, and quality of the registers of numerous RTD monitoring networks made up of low-cost devices, currently used to identify UHI in research. In addition, the following specific objectives are also considered:

• To describe the research process for the design and implementation of a purpose-built monitoring network to measure the UHI in the medium-sized city of Cáceres. This procedure can also serve as a model for other implementations.
• To review the characteristics of the principal CWON and the Citizen Weather Stations (CWSs) incorporated in them, which supply urban temperature data for the city of Cáceres.
• To compare the abovementioned networks’ characteristics with the WMO recommendations concerning climatic measurements taken in urban environments.

2.1. Materials

This research is based on the study of the RTD networks for measuring urban temperatures in Cáceres, a medium-sized city in western Spain of around 96,000 inhabitants [52] and a surface area of around 2300 hectares, over a typical period of extreme heat between 1 and 26 August 2024.

On the one hand, a bespoke network was studied. This is made up of 25 AWSs and was deployed in July 2024 by researchers from the Polytechnic School of Cáceres as part of the project Heat Waves and Cities: Adaptation and Resilience of the Built Environment [53]. One of the principal specific objectives was the digital modeling of the city through low-cost, open-source, and continuous monitoring.

On the other hand, two CWON were analyzed. These are collaborative systems through which private users or organizations (such as educational institutions, meteorological organizations, and other entities) can install and use commercial AWS, usually low cost, to generate a climate database accessible to both researchers and the general public [34]. In this study, the two CWONs selected have the greatest number of devices deployed around the city. The two networks are those of the commercial enterprise Netatmo, with 14 AWSs in the city. This enterprise specializes in the creation of intelligent devices for the home and their integration into their own system [54,55]. The second network belongs to the Weather Underground network platform [56], with 10 AWSs in the city from different manufacturers and of differing types. This network provides data concerning hyperlocal air quality and other meteorological data through the information from CWSs. Other CWON, such as Meteoclimatic [57], Noromet [58], and NCEI [59], were discarded due to their low or null presence in the city.

The density of the measuring devices of these networks in the city oscillates between approximately three units and one unit per 200 Ha, respectively. This supposes homogeneously distributed squares or grids measuring between 800 by 1400 m.

2.2. Methods

The methodology used first evaluates the characteristics of the three networks mentioned above, concerning the determining considerations of the ‘Guide to Instruments and Methods of Observation’ (WMO) for systems measuring urban climate data. This guide [60] provides guidance and specific recommendations based on national and international norms and the specific bibliography. This first part is structured following the order, terminology, and constituent parts of the monitoring systems proposed by the said guide: choice of components and system programming (Section 3), followed by the placement and installation of the measuring devices (Section 4). Each section first details the most relevant specific considerations of the WMO with respect to each question, later contextualizing them for each network. This work examines, on the one hand, the extent to which the monitoring systems are aligned with the recommended requisites of the WMO; and on the other, allows the characteristics of each network that define their final performance to be known and therefore the recommended scope in the use of said data for measuring UHI.

A comparative analysis is then carried out of the hourly thermal records from the meteorological stations of the three networks over the same period, on the understanding that the said records correspond directly to the accumulated urban heat (Section 5). The analysis of relative humidity records was excluded from this study, not a commonly used variable in the scientific literature [45,61,62]. Furthermore, it does not significantly impact climate comfort within the context of this case study. Before carrying out the data analysis, a quality control was performed to locate those values that could possibly be considered anomalous due to isolated errors in the measuring systems and also to evaluate the consistency and uniformity of the data in the entire set of each of the networks. The analysis was carried out considering two different scenarios: first, by checking the coherence of the data between the networks through the definition of the control points, i.e., through the nearby stations belonging to the different networks (an average distance of 160 m and a maximum of 300 m), and the analysis was later contextualized within a typical period of seven days; second, by differentiating between the control zones (UCZ corresponding to the local scale, i.e., HUZ) with similar topographical altitudes and vegetation that have a sufficient density of AWSs in all three networks; in this case, a typical sub-period of seven days within the general period was used. This work allows the quality of the registers to be known, and the variability of the data obtained to be evaluated according to whether they come from one network or another.

Finally, there is a comparative discussion of the results obtained in the previous sections from the three networks, analyzing the differences, as well as the scope and performance of each one for monitoring and identifying UHI in smart cities (Section 6).

3. Choice of System Components and Programming

3.1. Considerations of the WMO

The WMO establishes that the principal parts of a climate data monitoring system are the AWSs and the centralized processing system. It also specifies that such scenarios as interruptions in the energy supply, security failures, adverse climatic conditions, and other factors that could compromise the continuous registration of data must be foreseen and managed.

3.1.1. Automatic Weather Stations

The WMO defines an AWS as a meteorological station at which observations are made and transmitted automatically, and it must fulfill certain requirements to guarantee the quality, accuracy, and representativeness of the measurements, minimizing any possible distortions. It prioritizes the use of the AWSs that provide RTD over those that are offline and store data. Depending on the number of climate variables monitored, AWSs are considered to be either light (generally air temperature, relative humidity, precipitation and, sometimes, atmospheric pressure), basic (adding wind speed and direction), extended (with the additional measurement of solar radiation, sunshine duration, soil temperature, evaporation and so forth), or AWOS (which include automatic observation of visibility, cloud-base height and present weather).

Similarly, the WMO highlights the current tendency towards low-cost AWSs, which are usually offered as compact solutions developed through electronic embedded sensors and adapted software. Three main classes are considered: compact AWS, similar to professional meteorological stations that feature individual, calibratable instruments for each variable, housed in a cabinet with data-logging and transmission capabilities; all in one, a single unit that integrates multiple sensors, with the option to add more instruments; and stand-alone instruments, IoT devices that use low-power networks such as Wi-Fi or Bluetooth to transmit data to centralized servers and phone add-ons.

Furthermore, the firmware can be developed by the manufacturer and stored in the memory of the CPU, thus limiting user access to certain functions, or it can be open programming, which allows the user to design and develop the software, generating more flexible platforms.

Each component is described below.

(a)

Sensors

To measure the basic climatic conditions, it is necessary to integrate air temperature and humidity sensors that are robust, need low maintenance, and do not suffer distortions when recording data. They may consist of various sensors connected to data gathering units via interfaces, or independent sensors connected to a CPU. As for uncertainty and performance, for the air temperature, the WMO recommends a measuring range of −80 °C to 60 °C, with a resolution of ±0.1 °C and a measurement uncertainty of ±0.1 °C between −40 °C and 40 °C, and of ±0.3 °C for other ranges. The measurement range of relative humidity should be from 0% to 100% with a measurement uncertainty of ±1%.

(b)

Central Processing Unit

This centralizes the data input/output operations, as well as their conversion, processing, and temporal storage, depending on the type of station and use required. The data can also be distributed among several specialized digitally connected units. As for their location, if they are situated close to the sensors, then the in situ processing is optimized and the amount of data to be transmitted is minimized; however, protection against atmospheric and electrical failures is needed. On the other hand, placing them inside increases the cabling needs and requires signal conditioning, but it does offer a greater energy stability, as well as a controlled environment.

The CPU centralizes the programming tasks of the AWS, whose main functions are initialization, sampling, raw data conversion, message coding, quality control, local data storage, data transmission, and remote diagnostics and maintenance. There are other, less frequent operations in AWS, such as the averaged measurements, the manual entry of observations, data reduction, or data visualization.

(c)

Peripheral equipment

This equipment complements such functions of the CPU as: continuous energy supply with 12 V accumulators or batteries (which can be rechargeable or not); temporal accuracy using RTC, which keeps the clock ticking during short power cuts, thus guaranteeing accurate readings, sampling intervals and exact timings; and the system’s quality control through incorporated testing equipment, which supervises the performance of the components of the AWS, providing visual information available locally or sent to the CPU for analysis, thus facilitating both predictive and corrective maintenance.

(d)

Auxiliary elements

In order to ensure that the measuring devices reflect the true temperature of the environment, it is best to use radiation screens or shields as they allow the free circulation of the air, thus maintaining a uniform internal temperature equivalent to that of the surrounding air. These screens exclude radiant heat, precipitation, and other phenomena, minimizing errors and accidental damage. A screen with a high thermal conductivity, such as a metal, dark colors, and sizes smaller than 200 mm in diameter and 250 mm in height, will result in a poorer performance. There should be forced or natural ventilation to favor the convective process within the radiation screen.

3.1.2. Centralized System for Processing the Data from the Networks

The data collected by the AWS can be processed locally, in the AWS itself, or in a central processor of the network. In a complex meteorological network, the centralized processing system receives the data that the AWSs transmit via various means; it acquires them, decodes them, supervises their quality, processes and stores them, and finally transfers them, permitting their visualization. Furthermore, it can remotely control the AWS. Powerful computers integrated into the local networks are used to distribute the tasks efficiently.

Centralized processing facilitates the transmission and management of the data through a central system that optimizes such tasks as complex calculations and codification, thus alleviating the load on the AWS; however, such a specification (functional and technical) requires multidisciplinary collaboration.

3.2. Bespoke Network

An architecture divided into five layers is presented, ranging from the AWSs to the internal VM. The network of AWSs captures and sends data to a central node, from where users can consult the data. This data transfer is carried out using LoRaWAN technology, a long-range, low energy consumption open-source protocol [63]. In addition, it provides high data transmission security by encrypting packets at the network and application level, which means that the measuring devices can only be read by authorized servers that have registered the devices with their corresponding keys (Figure 1).

3.2.1. Automatic Weather Stations

A stand-alone AWS RTD has been designed, which is both light (measuring temperature and relative humidity) and made to measure, in collaboration with the enterprise Electronic Engineering iRay [64] (Figure 2). The components, listed below, are mounted on a stainless-steel sheet 316, 2 mm thick, which allows easy placement and removal.

(a)

Sensors

A high performance sensor is used for temperature (from −40 °C to 125 °C, with an accuracy of ±0.1 °C from 20 °C to 60 °C and of ±0.2 °C in the rest) and for relative humidity (from 0% to 100%, typical accuracy of ±1.5% from 0% to 80% and of ±2.0% in the rest), with double insulation against water and dust (Sensirion SHT35 [65]). Measurements have a resolution of 0.1 °C and 0.1%, respectively. Given that the SHT35 sensor is of the integrated type, it does not require signal conditioning. Sensors exhibit an LTD of less than ±0.03 °C/year, which, given their recent deployment, July 2014, results in a maximum accumulated LTD of ±0.0025 °C.

(b)

Central processing unit or microcontroller

In this case, the manufactured device has an MCU that centralizes all the acquisition, conversion, processing, and transmission functions of the monitored data. The MCU (ATMega328P [66]), with an Arduino UNO architecture, allows the different actions to be adjusted during the data capture and transmission processes. It is programmed using the IDE from Arduino. The firmware, based on an example from the manufacturer, has been adapted to comply with the requirements of the system concerning the communication protocol, dispatch frequency, sleep time, and the activation of the sensors connected to the MCU.

The MCU is contained in a polycarbonate waterproof box measuring 84 × 82 × 55 mm that has an external, detachable antenna of +2.5 dBi [67], which improves signal coverage. The box is situated close to the sensor and is connected via a cable and a cable gland. For the transmission of sensor data to the MCU, it uses an I2C communication protocol and functions with an operating voltage of between 2.4 V and 5.5 V. As for its functions, they are as follows:

• Initialization: The measuring functions are included in the base code, and the SHT library is modified to use the SHT35.
• Sampling rate: A default sampling period of 15 min is established, which allows compliance with the Duty Cycle (Air Time) that requires the use of ISM bands, which avoids passing the emissions limit of 1% [68]. This can be modified up to a maximum of one minute if necessary.
• Raw data conversion: The raw data are packaged in a message with the units converted to whole numbers, multiplying the values by 10 to eliminate the decimals. The server later carries out the inverse operation to obtain the decimal value.
• Message coding: To be able to use the LoRaWAN protocol, a series of keywords and addresses have been included that allow the data from the device to be identified and decoded. The ABP method has been used. This programs a Device Address identifier and two keywords (NetworkSessionKey and ApplicationSessionKey) into each AWS that is necessary for connecting to the server that distributes the system’s data, ChirpStack [69].
• Data quality control: This is carried out solely by the SHT35 sensor itself through the basic factory-programmed functions. In addition, although the SHT35 sensor is delivered already calibrated, the various registers of the AWSs have been compared before their definitive installation, placing them in a controlled site for a measurement period of 72 h (the devices registered maximum temperature differences of 0.2 °C and relative humidity differences of 5%, with data being registered every 15 min). On the other hand, as a digital communication bus is used, no loss of accuracy occurs in the data readings.
• Local data storage: Data are temporarily stored in the dynamic memory of the MCU, where the unit conversion takes place and from where the data are sent.
• Data transmission: The IoT connectivity is carried out via LoRa using the RFM95 transceiver [70] on the frequency band 868 MHz, integrated in the motherboard of the device for sending transmissions within the frequency range permitted by the European Union for LoRaWAN (863–870 MHz) [71].

In this case, the AWS does not have averaging functions, manual entry of observations, data reduction, local data visualization, or remote diagnostics and maintenance. These functions are performed through the centralized system, using alerts.

(c)

Peripheral equipment

Continuous energy supply is provided through two long-life lithium LR6 batteries of 3000 mAh. The battery life is made even longer by activating the “deep sleep” mode, which reduces the functions of the AWS to a minimum between readings. The quartz clock inside the MCU is used to ensure accuracy in the timing and the established periodicity of the sampling.

The system’s quality control starts with an Automated Optical Inspection to detect possible manufacturing defects in the electronics, such as faults in the soldering, a lack of or bad positioning of components, and errors in assembly. After that, a functional test is carried out that consists of loading a specific firmware designed to verify the correct functioning of all the components of the equipment, including inputs and outputs, actuators, LED indicators, sensors, and communication interfaces, among other things. Then, the SHT35 sensor uses the JEDEC JESD47 qualification test method to ensure that there are no faults in the module [72].

(d)

Auxiliary elements

The sensor is situated in a protected place below a radiation screen RIKA RK95-01 [73] made of white ABS anti-radiation engineering plastic. It consists of 11 plates, 180 mm high, with an interior diameter of 62 mm and an exterior diameter of 140/180 mm that provide openings for unforced ventilation.

3.2.2. Centralized Processing System for Network Data

This complex centralized system has the following functions:

(a)

Data acquisition and transmission

LoRaWAN technology was selected as the communication system between the AWSs and the central processing unit. The use of a communication device that includes a LoRA gateway (Figure 3) is necessary for it to function. The components of the device are as follows:

• Waterproof box for outdoors, the outdoor enclosure model for WisGate Developer D4+ [74]: This box houses the gateway and must have SIM coverage.
• Gateway, RAK WIRELESS 7248C D4H+ model [75]: It consists of a Raspberry Pi processor linked to an RAK2013 Cellular Pi HAT module for connecting to the mobile phone network using a SIM card. It is responsible for receiving and decoding the LoRA packages and sending them to a remote database. It is powered by the electricity grid.
• Omnidirectional LoRa 868 MHz antenna of 8 dBi [76]: This is placed on the upper part of the box and aids in the reception of data packages emitted by the AWSs in the LoRa bandwidth.

Figure 3. (a) Characteristics of the communication device antenna, radiation pattern. (b) Appearance of the communication device. (c) Inside the waterproof box.

Figure 3. (a) Characteristics of the communication device antenna, radiation pattern. (b) Appearance of the communication device. (c) Inside the waterproof box.

The gateway processor admits a Linux operating system that includes such pre-installed components as the ChirpStack server and connection to the internet via SIM. The ChirpStack server must be configured to fix the bandwidth frequency, the port, and the MQTT service for publishing data. The measurements are published in the MQTT broker installed in the RaspberryPi and specific scripts read them, package them, and send them to the central server using 4G and the HTTP protocol.

(b)

Receiving and storing data

The data from the gateways are received in the VM 1 virtual machine, situated in the infrastructure of the University of Extremadura in Cáceres. Data reception is managed through microservices written in Python (version 3.7.3) and stored in Docker containers. These services put the data in a PostgreSQL database placed in a private network with no access from outside. A system of alerts has been implemented in which a script verifies the last entries in the databases of the AWSs and the gateways, generating, in the case of some device fails, alert messages which are sent via Telegram [77] to a designated user, through a bot and the API of the application. It also makes daily and weekly summaries of the state of the system.

The static data are organized into related tables that associate each numerical ID of the AWS (from 1 to 25) with its location, latitude, and longitude. The dynamic data include the values for temperature, relative humidity, battery level, Received Signal Strength Indicator, SNR, and the Gateway number of origin with the numerical ID of the AWS.

(c)

Data visualization

The visualization is carried out using Grafana software (version v9.4.3) [78], which allows the data to be represented in a dynamic and simple way that can be personalized in different graphics, lists, tables, or maps. This tool obtains the data in real time directly from the PostgreSQL database.

3.3. Citizen Weather Observer Networks

The citizen networks studied provide little open information concerning the choice of components and programming of their systems; so, this section has to rely on the information available on their websites.

Nts are made up of independent AWSs, acquired and installed by the users, which become part of a global compilation and storage system for meteorological data. The data are transmitted and dealt with in the central data processing unit of the private network.

WU uses AWSs from different commercial brands [79], registering and associating them to their web platform, where they become part of a global system.

3.3.1. Automatic Weather Stations

Both networks are RTD. The AWSs of Nt are: light (measuring temperature, relative humidity, and atmospheric pressure) or all in one, while the WU can integrate AWSs of various commercial brands with different characteristics, although the majority are Basic (adding rainfall and wind speed and direction) or Compact AWS.

(a)

Sensors, central processing unit, and peripheral equipment

The AWS of Nt integrates the sensors, the central processing unit, and the peripheral equipment in a compact, aluminum anodized module with the following dimensions: 45 × 45 × 105 mm.

• The sensor used (SHTC3 [80]) measures temperature in a range from −40 °C to 125 °C, with an accuracy of ±0.2 °C, and relative humidity, within a range of 0% to 100%, offering a typical accuracy of ±2%. Measurements have a resolution of 0.01 °C and 0.01%, respectively. Sensors reported LTD ranging from ±0.02 to ±0.04 °C/year. The stations were installed between 2014 and 2024, resulting in accumulated LTD values ranging from ±0.02 °C to ±0.39 °C, depending on the sensor’s age.
• The CPU automatically acquires the data registered by the sensors and then processes and prepares them for internal dispatch. The data transmission between the AWSs and the Nt server is through a Wi-Fi connection that is compatible with the standard 802.11 b/g/n in the frequency band of 2.4 GHz, reinforced with Open, WEP, WPA, and WPA2-personal security protocols. It enables wireless communication via long-range radio between the interior and exterior module, reaching up to 100 m in open field conditions (868 MHz [81]).
• These devices are controlled from a mobile application provided by the manufacturer. It is from this application that the programming is carried out. Many of the operations of the CPU are fixed, programmed from the factory (raw data conversion, local data storage, sampling (five minutes), message coding, and data transmission); as such, it is only necessary to initialize using the internet with a Wi-Fi connection. Once the device has been activated, an initial calibration is automatically executed, and this enables remote diagnostics and maintenance. Similarly, the periodic device updates are carried out automatically.
• Data quality control is carried out in the centralized servers using validation algorithms that compare the data collected from the adjacent AWSs, within the same geographic area, in order to identify atypical values due to faults in the device or to an inadequate installation [82].
• It does not have averaging operations, manual entry of observations, data reduction, or local data visualization.
• As for the peripheral equipment, this device is powered by two AAA batteries with an approximate autonomy of two years for data collection occurring every five minutes. In order to ensure the accuracy of the timings, temporal synchronization mechanisms based on network protocols (such as NTP) are used. Although the manufacturer does not detail the implementation of a clock in real time, the network architecture guarantees that the data from each sensor are coherently integrated in the cloud, allowing precise chronologies [82,83]. Whether the AWSs have specific devices for quality control is not known.

The models compatible with WU [79] and their characteristics can be seen in Appendix A. It has been verified that there is no Netatmo station registered in the WU network in the city of Cáceres. All the pieces of equipment are made of resistant materials and are made up of totally functional measuring devices that include such auxiliary elements from the factory as a radiation screen. They are also connected to the CPU. The WU network includes stations installed between 2020 and 2024.

Thermistors, thermopars, and RTD probes are used to measure the temperature, and for the relative humidity, a condenser-type hygrometer [84]. In most AWSs, the measuring range for the temperature goes from −40 to 60 °C or 65 °C, except for the Bloomsky Weather Station model, which has a smaller range (from −20 to 55 °C). The accuracy is variable, from ±0.3 to ±2 °C, depending on the device. As for humidity, the range is from 0% to 100%, with an approximate accuracy of ±2%.

The data registered by the sensors are automatically acquired by the CPU for processing later and preparing dispatch via Wi-Fi using different transmission frequencies. The characteristics and functions of the CPU vary depending on the model used and are not clearly specified. However, many of their functions can be programmed in the factory, such as raw data conversion, local data storage, message coding, and transmission. In all cases, it is necessary to carry out an initialization of the equipment through the internet, using the company’s own app. It is thus possible to adjust the configuration of the AWSs, such as the periodicity of the data collection (sampling), which by default is one minute. Some stations, such as the RainWise MK4-C Compact Cellular Weather Station, automatically average the data in order to provide values at intervals of 15 min.

The data quality control is performed from the centralized system, using validation algorithms to ensure the quality of the data with quality verification rules and to identify discrepancies and errors on the basis of the shared reviews, which compare the data with that collected by adjacent AWSs [85].

For most AWSs, it is possible to incorporate an additional visualization console to view the data locally. There is no record of them performing manual entry of observations or data reduction functions.

As for the peripheral equipment, these devices are powered by solar energy, including capacitors. They also have long-life backup batteries to ensure the electrical supply. The equipment used to guarantee accuracy in the timing of the registers from the AWSs is unknown, as is whether the test equipment is incorporated to supervise the performance of the components.

(b)

Auxiliary elements

The Nt AWSs does not possess forced ventilation but can have an optional radiation screen with apertures to ventilate naturally. This white screen is made of materials resistant to solar radiation.

The sensor of the WU AWSs comes from the factory with solar radiation protection (and protection from other phenomena) incorporated. Therefore, it is not necessary to include any auxiliary elements to ensure correct functioning. In addition, the AcuRite 5-in-1 Weather Environment System model [86] has an internal suction ventilator powered by solar panels.

3.3.2. Centralized Network Data Processing System

Given that the centralized network data processing system used in CWON is proprietary and common to all the AWSs, its components are defined, and its programmed functions are fixed and therefore cannot be personalized. Furthermore, the complete information concerning these questions is not available to the user.

In Nt, the centralized system carries out its functions automatically. Data acquisition is performed via wireless Wi-Fi. The data are then processed and stored in the manufacturer’s database, connecting the AWS to the internet via Wi-Fi. Finally, they are available to the user for extraction or visualization. The data can be downloaded thanks to the available API using Python scripts to do so [87]. As for visualization in real time, it is possible to publicly access the measurements from all the stations installed via the visor web of Weathermap [88], or individually and privately from the mobile application, where the historical registers are also available. Alerts are also created.

The centralized system of the WU collects the data registered by the different AWSs via the Internet. To do so, devices that work as network bridges are used, connecting the AWSs to the Internet and thus allowing direct communication with the system. WU offers two options: AirBridge [89,90], which is wireless, and WeatherBridge [91], which connects to the AWS through a USB connection to the router via an Ethernet cable or Wi-Fi. However, WeatherBridge allows the configuration of the AWS and establishes system function alerts. In addition, it automatically reinitiates if there is a power cut, as all the configurations are stored. Once all the data have been collected, it processes them in centralized servers, stores them in historical archives, and provides access to them. Data visualization is publicly performed using panels and graphics through the visor web [92] or the WU app [93], where all the AWSs in the network can be seen in an interactive map using high-resolution satellite images, or historical archives using tables or complete graphics of each variable and AWS. Similarly, the data can be seen privately from the app of the commercial company.

4. Location and Installation of the Measuring Devices

4.1. Considerations of the WMO

The WMO establishes that, to provide representative measurements of the urban fabric, the AWSs must be situated in the urban canopy, within the UCZ, and in uniform placements with respect to the height of measurement, the distance to obstacles, and obstruction of the horizon. The following two sections set out the specific considerations concerning the horizontal and vertical scales; however, in urban areas, the WMO considers that it may be necessary to install the devices in places that are not recommended, such as close to buildings or sources of artificial heat. Similarly, it establishes that it is essential to ensure a complete, exact, and up-to-date collection of metadata, including information concerning the station, its geographical location, characteristics of the surroundings, and the date of installation, among other things.

4.1.1. Concerning the Horizontal Scales

The AWSs should operate on the local scale, in environments of one to several kilometers and with a similar urban development with respect to the built-up surface, the size, and spacing of the buildings. In order to determine the limits of the UCZ, the morphometrics of the urban area should be evaluated using aerial photographs, satellite images, or city planning documents. Then, representative locations should be identified for each AWS, avoiding possible microscale effects (far from such obstacles as trees, buildings or walls) and mesoscale effects (i.e., building envelopes, being close to a concentrated heat source, transition zones between different UCZ types, etc.); furthermore, the streets should preferably be north–south oriented (to guarantee a more constant solar radiation).

4.1.2. Concerning the Vertical Scales

According to the WMO, heat exchanges occur in the urban canopy layer (UCL), and its height is approximately equivalent to that of the mean height of the main rough elements (buildings and trees), (zH). The roughness sublayer, or blending height (zr), can be as low as 1.5 zH for densely built sites, but greater than 4 zH in low density areas. An instrument placed below zr may register microclimate anomalies; however, above that, it sees a blended, spatially averaged signal that is representative of the local scale. Based on the above, the source area (or footprint) is calculated as “100(zr − zd)”, where “zd” is the zero-plane displacement length, expressed as follows: 0.5 zH, 0.6 zH, and 0.7 zH for the roughness classes 5 (scattered obstacles (buildings) at a relative distance of 8 to 12 obstacle heights for low solid objects), 6 (area moderately covered by low building at relative separations of 3 to 7 obstacle heights and no high trees), and 7 (densely built-up area without much building height variation), respectively (Davenport classification [94]).

On the other hand, measurements at heights of 3 to 5 m above ground level are considered equally accurate to those collected at standard heights for non-urban areas (1.25 to 2 m.) and, in addition, more convenient for avoiding damage and proximity to vehicles.

4.2. Bespoke Network

In this section, the procedure for establishing the location and installation of the AWSs is described, which is necessary for communication devices for the deployment of the network, since smart city communication networks have been used. The locations of the AWSs were determined jointly to guarantee the representative nature of the UCZ and the uniformity of the data, following the recommendations of the WMO.

4.2.1. Automatic Weather Stations

The city’s UCZ is defined using maps, city planning maps, and field work. In the horizontal scale, two predominant situations are identified, both of roughness class 7: the first, zH 10 m and HUZ collective block (closed or open), with a footprint of 0.80 km in radius; and the second, zH 4 m and HUZ single family house (detached, semi-detached or terraced), of 0.32 km in radius. The distribution of 25 AWSs (numbered from “1” to “25”) was optimized, minimizing the superposition of the footprints, in order to achieve an efficient coverage of the city (Figure 4). As for the vertical scale, the proposal was to place the devices on the public streetlamps, at a height of five meters. In the two scales, special attention was paid to the uniformity in the distribution of the placements.

4.2.2. Communication Devices

The process starts with an initial design for the distribution of the communication devices, taking into account high places, to maximize reach and coverage in the city (which is set at between 300 and 600 m above sea level), and also that they have an electrical power supply. Then, the RF propagation is simulated [95] considering specific parameters, estimated for the city: average height (22 m, as the most unfavorable value, taking into account that the buildings can act as a screen), built-up density (75%) and electromagnetic conditions of the surrounding area; and of the devices: height (5 m for AWSs and 3 m for the communication device), transmitter power (23 dBm), sensitivity of the receivers (−139 dBm), antenna gain (2 dB emitters, 10 dB receivers), internal loss in the devices, reception threshold (−139 dB), and radiation patterns.

The locations are validated when the simulated theoretical coverage between the communication devices and the AWS is acceptable (a value of 50 is equivalent to an SNR of 0 dB; each unit represents 1 dB in the SNR) (Figure 5). An error margin of 10 dB is established, considering that the simulator provides values above the real ones due to the lack of measurements from the electromagnetic background noise (from buildings, trees, and other signal barriers). It can be seen that, of the 25 AWSs, 16 are covered by the three antennas and nine are covered by two, which backs up the effectiveness of the data dispatch, ensuring reception.

Then, an in situ verification is carried out, using an emitter device, with AWS and a pole to simulate the projected height, as well as a receiver with a LoRa antenna and gateway connected to the internet via a router or SIM and powered by a transformer connected to a vehicle. The ChirpStack is accessed, configured in the local network, and the AWS plots are captured in real time. This allows the signal levels to be evaluated until an SNR higher than 3 dB is found. Thus, the final placing of the 25 AWSs and the communication devices in small perimeter chains around the city are decided: A, fixed to a lamppost (at an altitude of 454 m above sea level on the ‘La Montaña’ road), and B and C in potable water treatment stations (at 490 m above sea level in ‘Sierrilla’ and 519 m above sea level in the ‘Cerro de los Pinos’, both in an enclosed area). Finally, the detailed characteristics of the surroundings of the devices are registered.

4.3. Citizen Weather Observer Networks

The web of both networks shows the location of their AWSs, registered by the users themselves, without confirmation or the provision of detailed information concerning the characteristics of the surroundings; however, it has been verified in situ that, as in “ι”, the AWSs are not exactly or really in the specific locations that have been registered. In any case, it has also been noted that neither of the two CWON, Nt (AWSs denominated as “a” to “j”) or WU (AWSs from “α” to “ι”) present a uniform distribution in Cáceres (Figure 6). It could be said that the most probable placements, in the case of citizens, are balconies, terraces, or windows of the houses and, for buildings belonging to institutions, they could also be on the roof. In addition, it is not possible to know whether the users have taken into account the recommendations of the manufacturers concerning the installation of each AWS. Nt advises installing them in a place protected from the rain, direct sunlight, and other possible adverse weather conditions, as well as being far from sources of heat or cold. WU recommends a height of between 1.2 and 1.8 m above the ground, and a vertical distance from paved surfaces of at least 15 m. As for horizontal distances, at least four times the height of the nearest obstacle [96,97]; furthermore, the sensor should be well ventilated and should never receive direct sunlight, in which case a radiation shield must be used.

5. Analysis of the Measurement Data

In this section, the data registered in the AWSs of the different networks during the period in question are compared. First of all, a data quality control is carried out, including an analysis of the data distribution in the entire set of AWSs in each network, following the different temperature ranges, to determine the existence of possible patterns and symmetries. The registers of the official weather station of the State Meteorological Service (AEMET [99]) of Cáceres have been used as reference. This station is situated to the East of the city, far from the urban center.

In order to deal with the analysis, eight control points and three control zones are defined (Figure 6). Their complete definition can be found in Appendix B and Appendix C. The evolution over time of the data between the different networks in a typical week of hot weather from 12 to 18 August (which also has a greater number of heat registers from the three networks) is then analyzed. Similarly, representative indicators for measuring UHI have been defined; they are absolute values for temperature differences, daily values of the mean weekly maximum and minimum temperatures, the weekly average, and amplitude. In addition, the calculation of the CDD (in °C·day) is added to quantify the impact of urban heat on the demand for air-conditioning over a period of time (this is calculated through the difference between the hourly data of the AWSs and a reference temperature, in this case 18 °C [100], which accumulate daily and whose impact is calculated over the 24 h). In addition, to identify the accumulation of solar radiation that manifests itself during the night, the CDD has been broken down into those corresponding to daytime and nighttime periods (from 7 to 21 h and 21 to 7 h, following the mean time of sunset for that week).

5.1. Data Quality Control

A data quality control is performed in two stages. The first takes into account the details of the hourly urban climatic databases [101,102] and of the AWSs [103,104]. Successive control processes are then followed:

• Selection of AWSs according to the amount of data, discarding those that do not reach at least 80% (a smaller percentage is considered insufficient to characterize the period).
• Verification of the temperature range for the period in question, which is set from 11 °C to 47 °C (corresponding to ±6 °C with respect to the absolute minimum and maximum temperatures registered by the city’s AEMET station in the month of August 2024, 17 °C and 41 °C, respectively [105]).
• Checking the consistency of the readings for the same value continuously, fixing as outliers those hourly values repeated over 5 consecutive hours.
• Searching for sudden or significant changes between consecutive time marks, defining as outliers those hourly registers with variations above 12 °C with respect to the previous one (to maintain the stability and relevance of the data, ensuring coherent data and eliminating the infrequent sudden changes that are usually due to extreme phenomena or measuring errors).
• Checking the validity of the continuity of the data in between observations and the average of the remaining AWS, fixing a threshold of four standard deviations (guaranteeing the detection of really extreme values, eliminating extremely rare values possibly due to measuring errors or real anomalies, while also minimizing the elimination of legitimate data).
• Checking the daily oscillation in temperatures, eliminating those registers of the days in which the said oscillation is lower than 9 °C (minimum value of thermal oscillation registered by the AEMET in the city in the period in question).
• Checking sensor aging, devices with a total uncertainty exceeding ±0.5 °C were excluded, while those with an accumulated LTD above ±0.3 °C were critically reviewed. As a result, three situations were identified: no evidence of aging in the Bs network; a lack of knowledge for WU network sensors; and a cumulative LTD of ±0.39 °C for devices “h” and “i” in the Nt network; however, these are not associated with any control points or analysis zones, and are therefore of limited relevance to the study.

Thus, following the data quality control performed in this first stage, 20 AWSs of Bs with 12144 registers (97.3% of those available) are maintained, as are 10 AWSs of Nt with 6075 registers (97.4% of the total) and nine AWSs of WU, with 5597 registers (99.7% of the total).

In the second stage of the control, and based on the now clean registers, the similarities of the two sets of data between the networks are evaluated with respect to the following questions:

• The probability distribution and density of the registers from each AWS, according to different temperature ranges (Figure 7): it can be seen that the registers of the AWSs of Bs and WU are uniformly distributed between the different levels, which happens with those of the AEMET, with similar mean values (29.5 ± 0.4 °C in Bs and WU and 29.4 °C in AEMET) and quartiles (first 25.2 ± 0.6 °C and second 34.4 ± 0.6 °C in Bs and WU and 25.2 and 34.5 °C in AEMET). However, those of the Nt show a great heterogeneity (mean 29.5 ± 1.1 °C, first quartile 25.9 ± 1.2 °C, and second quartile 34.8 ± 1.9 °C). The differences between the amplitude of data registered in the AWSs of the different networks are similarly worth noting, while Bs and WU show 3.7 °C (from 20.1 to 23.8 °C) and 6.7 °C (from 19.7 to 26.4 °C), respectively; Nt registers 8.7 °C (from 18.2 to 26.9 °C). On the other hand, the AWS of the AEMET presents an oscillation of 23.1 °C.
• Hourly differences between the values registered by all the AWSs of each network (Figure 8): Bs and WU have minimums between 0.9 °C and 0.8 °C, and maximums between 7.6 °C and 7.4 °C, respectively; while in Nt, these values are 2.2 °C and 14.0 °C, respectively.

5.2. Control Points

Eight control points are identified (CP1 to CP8) (Appendix B and Appendix C), distributed throughout the city, that are used to compare all the networks: on five occasions AWSs of Bs and WU (CP3 to CP7), on one occasion AWSs of Bs and Nt (CP2) and AWSs of Nt and WU (CP8) and, at one of the control points (CP1), three AWSs, one corresponding to each network.

This study uses scatter plots to check the intensity of the existing relation between the data pairs from the AWSs via linear and quality adjustments of the regression obtained from the determination coefficient R² (in general, the closer the R² value is to 1, the stronger the connection between the two variables, allowing the regression model to be trusted with a high level of confidence).

Looking at the results obtained (Figure 9), there is an evident linear relation in general terms between the data pairs. However, it is worth noting that R² between Bs and Nt, in CP1 and CP2 (0.95458 and 0.91868), is notably lower than those obtained in four of the Bs and WU, in CP3 to CP6 (0.98038 ± 0.00857). It should be pointed out that the behavior of Bs and WU in CP7 (0.93031) is different. When visiting the area, it is possible to see that there is in fact, no AWS in that location. Between Nt and WU in CP8, there is a high R² (0.97411), and in this case, the distance between the sensors is less than 20 m.

In CP1, a lower consistency in the data from the AWS of Nt can be appreciated. The pairs between Nt and Bs (R² = 0.95458) and Nt and WU (R² = 0.94581) present a similar scattering with respect to the cloud of general points. Nevertheless, when the projection of the Bs and WU pairs of data are analyzed, the correlation is greater (R² = 0.98202) (Figure 10).

Typical Week

In general, the weekly analysis (Figure 11) shows that the data from the AWSs of Bs and the WU fluctuate in a similar way (practically identical from CP3 to CP6), with hourly mean differences of 0.8 ± 0.8 °C (less than 1 °C in 70% of the registers) considering the total number of control points of the two networks. However, the values of the AWSs of Nt present an hourly mean difference of 1.8 ± 1.0 °C and 1.7 ± 1.4 °C, respectively, with respect to the AWSs of Bs and WU (less than 1 °C in 27% and 40% and in 38% and 33% greater than 2 °C of the registers, respectively). This difference between the AWSs of Nt and the rest are greater than 12 h and 15 h, even surpassing 6 °C of difference.

The following general conclusions have been obtained from the analysis of the indicators for each of the CP (Table 1):

• Similar amplitude with small deviations with respect to the mean, from 0 °C to ±1.0 °C.
• Higher daily registers in the Nt AWSs with respect to the rest, with a mean of 1.6 ± 0.4 °C in the minimum and 2.5 ± 0.4 °C in the maximum with respect to the Bs AWSs, and 1.0 ± 0.2 °C and 2.4 ± 0.3.1 °C, respectively, with respect to the WU AWSs. The differences between the values of the WU and Bs AWSs are small (0.6 ± 0.4 °C in the minimums and 1.1 ± 0.8 °C in the maximums).
• Weekly average greater in the Nt AWSs, with a mean of 1.4 ± 0.1 °C and 1.4 ± 1 °C with respect to the Bs and WU AWSs. There is a mean difference of 0.4 ± 0.3 °C in the weekly average of Bs and WU AWSs.
• A greater average of CDD in the Nt AWSs, with respect to the rest, in totals: 15% and 14% more with respect to the Bs and WU AWS; during daylight: 10% and 9%, respectively; and during the night: 27% and 23%, respectively.

Table 1. Temperature indicators in the week of 12 to 18 August 2024 in the different AWSs of the control points.

Control Point and AWS		Weekly Amplitude (°C)	Minimum (°C)		Maximum (°C)		Weekly Average (°C)	CDD (°C·Day)
			Absolute	Daily Average	Absolute	Daily Average		Totals	Daytime (% of Total)	Nighttime (% of Total)
CP1	Bs 11	20.8	19.3	21.8	40.1	37.1	29.4	141	94 (67%)	46 (33%)
	Nt a	20.6	21.1	23.1	41.7	39.8	30.7	169	114 (68%)	55 (32%)
	WU β	19.1	19.1	22.3	38.2	35.2	28.6	141	94 (67%)	47 (33%)
CP2	Bs 23	21.5	17.1	21.7	38.6	35.4	28.3	136	93 (69%)	43 (31%)
	Nt c	21.4	18.7	23.6	40.1	37.6	29.9	159	101(64%)	57 (36%)
CP3	Bs 15	20.8	16.7	21.2	37.5	34.4	28.0	133	90 (68%)	43 (32%)
	WU γ	20.1	16.8	21.7	36.9	34.2	28.0	138	100 (72%)	38 (28%)
CP4	Bs 20	20.1	17.1	21.6	37.2	34.3	28.5	138	95 (68%)	44 (32%)
	WU η	21.1	17.1	21.6	38.2	35.3	28.4	136	94 (69%)	42 (31%)
CP5	Bs 6	20.4	18.1	21.7	38.5	35.3	28.5	136	94 (69%)	43 (31%)
	WU ζ	20.3	17.4	21.1	37.7	34.7	27.9	130	90 (70%)	39 (30%)
CP6	Bs 24	20.1	19.4	21.2	39.4	36.3	28.7	140	100 (72%)	40 (28%)
	WU θ	18.9	19.6	21.9	38.5	35.8	28.9	143	98 (69%)	45 (31%)
CP7	Bs 25	18.3	18.4	22.1	36.7	34.0	28.1	135	90 (67%)	45 (33%)
	WU ι	18.9	19.4	23.4	38.3	36.2	28.9	148	93 (63%)	55 (37%)
CP8	Nt j	17.2	20.4	23.3	37.6	34.4	29.0	146	94 (65%)	52 (35%)
	WU α	18.6	18.8	22.1	37.4	34.2	28.2	135	90 (67%)	45 (33%)

Table 1. Temperature indicators in the week of 12 to 18 August 2024 in the different AWSs of the control points.

Control Point and AWS		Weekly Amplitude (°C)	Minimum (°C)		Maximum (°C)		Weekly Average (°C)	CDD (°C·Day)
			Absolute	Daily Average	Absolute	Daily Average		Totals	Daytime (% of Total)	Nighttime (% of Total)
CP1	Bs 11	20.8	19.3	21.8	40.1	37.1	29.4	141	94 (67%)	46 (33%)
	Nt a	20.6	21.1	23.1	41.7	39.8	30.7	169	114 (68%)	55 (32%)
	WU β	19.1	19.1	22.3	38.2	35.2	28.6	141	94 (67%)	47 (33%)
CP2	Bs 23	21.5	17.1	21.7	38.6	35.4	28.3	136	93 (69%)	43 (31%)
	Nt c	21.4	18.7	23.6	40.1	37.6	29.9	159	101(64%)	57 (36%)
CP3	Bs 15	20.8	16.7	21.2	37.5	34.4	28.0	133	90 (68%)	43 (32%)
	WU γ	20.1	16.8	21.7	36.9	34.2	28.0	138	100 (72%)	38 (28%)
CP4	Bs 20	20.1	17.1	21.6	37.2	34.3	28.5	138	95 (68%)	44 (32%)
	WU η	21.1	17.1	21.6	38.2	35.3	28.4	136	94 (69%)	42 (31%)
CP5	Bs 6	20.4	18.1	21.7	38.5	35.3	28.5	136	94 (69%)	43 (31%)
	WU ζ	20.3	17.4	21.1	37.7	34.7	27.9	130	90 (70%)	39 (30%)
CP6	Bs 24	20.1	19.4	21.2	39.4	36.3	28.7	140	100 (72%)	40 (28%)
	WU θ	18.9	19.6	21.9	38.5	35.8	28.9	143	98 (69%)	45 (31%)
CP7	Bs 25	18.3	18.4	22.1	36.7	34.0	28.1	135	90 (67%)	45 (33%)
	WU ι	18.9	19.4	23.4	38.3	36.2	28.9	148	93 (63%)	55 (37%)
CP8	Nt j	17.2	20.4	23.3	37.6	34.4	29.0	146	94 (65%)	52 (35%)
	WU α	18.6	18.8	22.1	37.4	34.2	28.2	135	90 (67%)	45 (33%)

5.3. Control Zones

The three selected areas are on the edge of the city: North, West, and South (definition in Appendix B and Appendix C) and include AWSs from all three networks.

Figure 12 shows a similar hourly general oscillation between the networks in all three zones and between their AWSs during the week in question. In a more specific analysis, the following should be highlighted:

• The superposition of registers between Bs and WU (mostly in the North and South zones).
• The great similarity between the registers of the AWSs of Bs in each of the three zones (means of 1.6 °C and 0.7 °C in West and South).
• The great difference between the values of the AWSs of WU in the West zone (mean of 1.7 °C and maximum of 4.2 °C).
• The lack of continuity in the registers of the AWSs of Nt (some had to be excluded in the data quality control) and large differences between their registers in the West zone (mean of 2.8 °C and maximum of 7.4 °C), especially in the maximums, which were also very high in the North zone (up to 8.8 °C more than Bs and 9.3 °C more than WU, on August 15th at 16:00 h).

Figure 12. Hourly evolution of AWS temperatures for each zone (North, West, and South) for the week of 12 to 18 August 2024.

Figure 12. Hourly evolution of AWS temperatures for each zone (North, West, and South) for the week of 12 to 18 August 2024.

From the analysis of the indicators in each of the zones (Table 2), the following general conclusions have been obtained:

• Large absolute differences between the registers of the AWSs of Nt, with a mean of 2.6 ± 0.7 °C and a maximum of 6.8 ± 0.8 °C. Bs and WU show greater compactness between their AWSs, with a mean of 1 ± 0.4 °C and 1.3 ± 0.9 °C, and a maximum of 3.7 ± 1.4 °C and 4.5 ± 0.4 °C, respectively.
• A similar amplitude (mean of the AWS) between the networks of the West and South zones, while in the North zone, the Nt measures 2.9 °C and 3.7 °C more with respect to the Bs and WU, respectively.
• Larger daily maximum and minimum registers in Nt with respect to Bs and WU, with a mean of 1.4 ± 0.3 °C and 1.2 ± 0.1 °C more in the minimums and 2.9 ± 2.9 °C and 3.6 ± 3.4 °C more in the maximums, respectively. Small differences between Bs and WU, of 0.8 ± 1.0 °C in the minimums and 0.5 ± 0.5 °C in the maximums.
• Weekly average larger in Nt with respect to Bs and WU, with 1.1 ± 1.0 °C and 1.2 ± 1.2 °C more on average, respectively. Mean difference of 0.2 ± 0.2 °C between Bs and WU.
• Similar daytime and nighttime totals for CDD in Bs and WU (difference of 2%). Larger values in Nt with respect to Bs and WU, over 6 °C and 8 °C·day, respectively, in the daytime and approximately 10 °C·day at night. This supposes an increase with respect to Bs and WU of 8 ± 8% and 11 ± 12% in the daytime and 23 ± 4% and 21 ± 0% at night, respectively.
• A similar share between daytime and nighttime CDD, with respect to the total, in all three networks, around 68% and 32%.

Table 2. Temperature indicators for the week of 12–18 August 2024, in the different networks in the control zones.

No. of AWSs per Network		Between AWSs of Each Network: Absolute Difference (°C)		Between Networks
				Weekly Amplitude (°C)	Average Daily Values (°C)		Weekly Average (°C)	CDD (°C·Day)
								Totals	Daytime (% of Total)	Nighttime (% of Total)
		Max	Average		Min	Max
North zone
Bs	5	4.7	1.5	19.9	21.9	36.3	28.9	143	98 (69%)	45 (31%)
Nt	2	6.2	2.0	22.8	23.5	41.2	30.7	168	112 (67%)	56 (33%)
WU *	1	-	-	19.1	22.3	35.2	28.6	141	94 (67%)	47 (33%)
West zone
Bs	3	2.1	0.8	21.1	21.6	35.0	28.3	135	92 (68%)	43 (32%)
Nt	3	7.4	3.1	20.1	22.8	35.9	28.6	142	90 (63%)	52 (37%)
WU	3	4.2	2.0	20.2	21.7	34.7	28.2	135	92 (68%)	43 (32%)
South zone
Bs	2	4.2	0.8	20.3	21.6	34.8	28.5	137	94 (69%)	43 (31%)
Nt	0
WU	2	4.8	0.7	20.7	23.5	35.0	28.1	133	92 (69%)	41 (31%)

* As only one AWS is present in the network, differences between stations cannot be calculated. Reported maximum, minimum, range, mean values, and CCD correspond solely to this AWS.

Table 2. Temperature indicators for the week of 12–18 August 2024, in the different networks in the control zones.

No. of AWSs per Network		Between AWSs of Each Network: Absolute Difference (°C)		Between Networks
				Weekly Amplitude (°C)	Average Daily Values (°C)		Weekly Average (°C)	CDD (°C·Day)
								Totals	Daytime (% of Total)	Nighttime (% of Total)
		Max	Average		Min	Max
North zone
Bs	5	4.7	1.5	19.9	21.9	36.3	28.9	143	98 (69%)	45 (31%)
Nt	2	6.2	2.0	22.8	23.5	41.2	30.7	168	112 (67%)	56 (33%)
WU *	1	-	-	19.1	22.3	35.2	28.6	141	94 (67%)	47 (33%)
West zone
Bs	3	2.1	0.8	21.1	21.6	35.0	28.3	135	92 (68%)	43 (32%)
Nt	3	7.4	3.1	20.1	22.8	35.9	28.6	142	90 (63%)	52 (37%)
WU	3	4.2	2.0	20.2	21.7	34.7	28.2	135	92 (68%)	43 (32%)
South zone
Bs	2	4.2	0.8	20.3	21.6	34.8	28.5	137	94 (69%)	43 (31%)
Nt	0
WU	2	4.8	0.7	20.7	23.5	35.0	28.1	133	92 (69%)	41 (31%)

* As only one AWS is present in the network, differences between stations cannot be calculated. Reported maximum, minimum, range, mean values, and CCD correspond solely to this AWS.

6. Discussion of Results

This section examines the implications derived from the previous sections (Section 3, Section 4 and Section 5), focusing on how the use of data from different networks may affect the quality and reliability of the results.

Table 3. Summary of the considerations of WMO recommendations by the networks mentioned in the paper.

		Bs	Nt	WU
Uniformity of devices		Yes	Partially	No
Uniformity of device locations		Partially	No	No
Sensor’s characteristics				*1
Temperature range		Partially	Partially	Partially
Temperature accuracy		Partially	Partially	No
Temperature resolution		Yes	Yes	Yes
Relative humidity range		Yes	Yes	Yes
Relative humidity accuracy		No	No	No
Relative humidity resolution		Yes	Yes	Yes
Rugged, low-maintenance, and minimally distorted		Yes	Yes	*1
Air temperature control elements
Radiation screen		Yes	-	- *1
Ventilated radiation screens		Yes	Yes	*1
Forced ventilation		No	No	*1
Materials and thermal conductivity		Yes	Yes	*1
Diameter and height		No	No	*1
Sampling frequency and accuracy				*1
Minimum sampling interval		Yes	Yes	Yes *1
Local storage or preferred RTD		Yes	Yes	Yes
Prioritizing automatic stations with respect to manual stations		Yes	Yes	Yes
Height and location of sensors
Sensor height		Yes	-	-
Proximity and distance to obstacles		Yes	-	-
Location with representative HUZ		Yes	Partially	Partially
Calibration and quality control
Sensors periodic calibration in laboratory or on-site		*2	-	-
Reporting of the periodic calibrations		*2	No	No
Automatic quality control	Verification of data: continuity, stability and consistency	Partially	Partially	Partially
	Comparison with nearby stations	No	Yes	Yes
Metadata	GPS coordinates and altitude	Yes	No	No
	Environmental characteristics	Yes	No	No
	Sensor type and model	Yes	Yes	No
	Installation date	Yes	No	No
	Maintenance	Yes	No	No

*¹ It depends on the model; *² Not yet.

adds a summary of the consideration of the WMO recommendations by the networks mentioned in the document. Furthermore, the question arises as to whether these issues can be corrected in the analysis process. These considerations are critical, as they can lead to significant errors in the identification and interpretation of the UHI effect.

6.1. Concerning the Choice of Components and Programming of the System

A fundamental distinction lies in the flexibility of purpose-built monitoring systems, which can be tailored to specific research needs. These systems allow for customization of AWS components such as sensor type, resolution, uncertainty, radiation shielding, power supply (e.g., deep sleep mode), sampling frequency, transmission protocol, clock synchronization, and data storage. Additionally, open-source firmware enables users to implement advanced functionalities like alarms, quality control, and remote calibration, enhancing transparency and control.

In contrast, CWONs often rely on closed-source hardware and software. This limits users’ understanding of system constraints, which can compromise data interpretation. Moreover, the heterogeneity of CWON equipment (due to varying AWS models or the absence of optional components like radiation shielding or forced ventilation) can lead to inconsistencies in data quality that cannot be fully corrected, even with post-processing quality control.

All networks analyzed use low-cost RTD-based AWSs, which meet WMO standards for temperature measurement in UHI studies. However, power supply remains a challenge. Battery-powered AWSs require periodic replacement, which can be logistically complex and costly, especially for remote installations, as evidenced by the case of the purpose-built monitoring situated far from facades. In contrast, CWON devices, typically installed in accessible domestic settings, are easier to maintain. Solar panels offer greater autonomy but require higher initial investment and are dependent on sunlight availability, often necessitating battery backups, as observed with select AWSs offered by WU.

Data transmission protocols also play a crucial role. LoRaWAN, for example, offers long-range, low-power communication and supports scalable, open-technology infrastructures. This enables integration with broader smart city applications—such as mobility and waste management—beyond UHI monitoring. However, CWONs are limited to the capabilities provided by their commercial vendors.

Cross-quality control is essential for ensuring data integrity. Purpose-built systems can be configured for ensemble pre-calibration, allowing for controlled verification of sensor performance. Such measures facilitate the verification of recorded data within a controlled environment, thereby ensuring the reliability of the results. In contrast, CWONs require a minimum device density for effective centralized quality control, which was not achieved in the case study.

Additionally, while proprietary networks allow for programmable data downloads and customizable dashboards, CWONs typically restrict users to predefined visualizations and limited data export options.

Finally, it is important to note that purpose-built systems require specialized personnel with expertise in electronics, telecommunications, and sensor technologies. CWONs, by design, eliminate this need, offering plug-and-play solutions that are accessible to the general public.

6.2. Concerning the Location and Installation of Measuring Devices

The development of proprietary networks enables the creation of dense and spatially uniform monitoring systems that align with LCZ classifications, as recommended by the WMO. In these networks, the geographic coordinates and relevant environmental metadata for each AWS are carefully documented, ensuring spatial accuracy and consistency.

In contrast, CWONs often exhibit spatial data gaps (particularly in urban areas with lower socioeconomic status), resulting in “data shadows”. Furthermore, the recorded coordinates of CWON AWSs are not always reliable. As discussed in Section 4.3, inaccuracies may arise from several factors, including data privacy concerns, changes in residential addresses without corresponding updates, and limited cooperation from property owners. These issues can lead to a disconnect between the recorded data and the actual measurement location, undermining the spatial validity of the observations.

Another critical limitation of CWONs is the lack of vertical consistency in AWS placement. Devices may be installed at varying heights (on low or high floors) without regard to urban canopy height or surface roughness, both of which are essential for accurate UHI characterization. Moreover, CWONs typically do not record metadata such as installation height or other micro-environmental factors. As a result, the data may reflect hyper-local microclimates that are not representative of the broader LCZ. These discrepancies cannot be identified or corrected through standard data quality control procedures.

6.3. Concerning the Analysis of Measurement Data

The individual quality control performed on each network revealed a high proportion of valid data across all three, supporting their initial and interchangeable use in UHI research. However, it is important to consider that WU network stations may have suffered an impact of sensor aging that has not been possible to identify. Sensor aging can degrade device performance and compromise data accuracy, particularly in long-term analyses or studies requiring high precision.

In a more advanced quality control phase, where data from the three networks were cross-compared, notable differences emerged. The bespoke network displayed a highly uniform distribution of temperature records across various ranges. In contrast, the CWONs exhibited significant variability. This may be attributable to the absence of uniformity in CWON with regard to devices and their locations, which may lead to deficiencies in the interpretation of UHIs. The maximum difference in recorded amplitudes reaches approximately 9 °C, and discrepancies of up to 14 °C were observed between the hourly readings from different CWON AWSs, an implausible value for UHI conditions in any medium-sized city or for total uncertainty sensor.

Further analysis at selected control points and zones revealed substantial inconsistencies in the local behavior of the two CWONs, both in weekly and monthly datasets. While the WU network demonstrated strong internal consistency and high correlation among its stations, the Nt network consistently reported higher values, especially in the upper temperature ranges, with differences exceeding 2 °C. This discrepancy may be attributed to the superior quality and calibration of the commercial devices used in the WU network.

7. Conclusions

The integration of urban monitoring technologies is essential for enhancing urban liveability and accurately identifying the UHI effect. This study has conducted a comprehensive evaluation of several low-cost, real-time monitoring networks operating in a medium-sized city, revealing significant disparities in data quality and system limitations. These findings underscore the need for rigorous data analysis that accounts for the specific characteristics of each network in climate-related research.

Equally important is the implementation of regular maintenance, calibration, and quality control procedures to ensure data reliability. However, these measures alone are insufficient. A precise characterization of each station, including its location, surrounding environment, and regularly updated metadata, is imperative for meaningful analysis.

A key objective of this study was to document the deployment of a purpose-built monitoring network, offering a replicable model for similar initiatives. Although the pilot was implemented in Cáceres, it forms part of a broader coordinated project aimed at replicating the system in other urban areas, such as Bilbao. The use of open-source hardware and software enhances adaptability, allowing the system to evolve with emerging needs. Nonetheless, rapid technological advancements may render systems obsolete, necessitating timely upgrades.

Purpose-built monitoring systems are particularly well-suited for multidisciplinary projects of limited duration in small to medium-sized cities. Their ability to meet specific project requirements enables the development of cost-effective, tailored solutions. However, their deployment and maintenance require specialized personnel, making it essential to delegate responsibility to capable institutions or organizations.

In contrast, large cities, where UHI effects are more pronounced, can benefit from existing CWONs, which offer immediate access to historical data without the need for prior deployment, provided that the particular characteristics of each station are taken into consideration. However, reliance on CWON does not guarantee long-term system continuity or data consistency.

This research also identifies future directions and challenges. While the primary focus has been on UHI, the monitoring infrastructure developed here is adaptable to other smart city domains, including air quality, noise, mobility, and waste management. To remain relevant, network design must be modular and adaptable, accommodating rapid advancements in sensing, telecommunications, data processing, and storage technologies.

To reduce long-term maintenance costs and minimize manual interventions, the integration of internal self-diagnosis and predictive maintenance modules is proposed. These would monitor component health, detect anomalies, and issue alerts. The potential for self-healing mechanisms, such as automated reboots or remote reconfiguration, has also been considered.

In order to ensure the reliability of citizen devices in research contexts, CWON providers should require operators to properly install the devices, following the guidelines provided by them and the WMO, and provide precise metadata, including installation height, accurate georeferencing (e.g., by incorporating GPS), sensor type, AWS type, and the presence of solar protection and ventilation. Furthermore, the provision of precise information regarding identification, the type of AWS, and the presence of solar protection and ventilation is imperative. Furthermore, the CWON should provide detailed information on the calibration process carried out, if applicable.