A Low-Cost IoT Architecture for Micro-Zone Climate Prediction and Meteorological Forecasting

1. Introduction

Urban climate in high-altitude Latin American cities presents particular characteristics that hinder prediction using conventional meteorological models designed for regional or national scales. Bogotá, Colombia, located on the Cundiboyacense savanna at approximately 2,600 metres above sea level, experiences marked intra-diurnal climate variability, with temperature changes that may exceed 10°C between early morning and midday. Such variability becomes even more significant when analysed at the micro-zone scale, where local topography, land use, urban density, vegetation, and proximity to water bodies produce highly heterogeneous thermal behaviour [1].

This challenge is part of a broader transformation in digital infrastructures for smart environments, where sensing, communication, prediction, automation, and decision support increasingly operate as integrated layers rather than isolated components. Recent studies show that artificial intelligence has become a core enabler for adaptive and data-driven systems in domains such as smart buildings, e-learning, operational command, and smart environments [5,10]. In these contexts, the value of AI does not lie only in prediction accuracy, but also in the system’s capacity to support timely decisions, automate workflows, and remain usable and trustworthy for end users [6]. The challenge of processing heterogeneous and multi-scenario data is well-documented in the machine learning literature: Zhou et al. [35] demonstrate that models operating on multi-source datasets require dedicated strategies to handle variability across scenarios, a concern directly applicable to multi-station IoT deployments where each node exhibits distinct temporal coverage and environmental exposure.

In climate-sensitive urban environments, this perspective is particularly relevant. Weather station networks from official agencies such as Colombia’s Institute of Hydrology, Meteorology and Environmental Studies (IDEAM) provide reliable observations at regional scale, but their spatial density is often insufficient to capture gradients at the micro-zone level. This limitation affects practical domains such as precision agriculture, thermal comfort assessment, urban planning, local risk management, and real-time operational response. Therefore, hyperlocal climate intelligence requires not only low-cost sensing infrastructure, but also robust data engineering, predictive analytics, service orchestration, and secure digital connectivity [2]. Machine learning has proven effective for quality diagnostics and pattern recognition in resource-constrained deployments [37], reinforcing the case for data-driven approaches in low-cost IoT architectures.

The democratization of low-cost hardware platforms such as Raspberry Pi, combined with open-source software ecosystems for machine learning and workflow automation, enables the deployment of local climate intelligence systems at a fraction of the cost of traditional meteorological infrastructure [2]. At the same time, recent research in smart environments emphasizes that predictive systems must be designed with adaptability, resilience, and trustworthiness in mind, especially when they operate in operational or semi-critical contexts [8,27]. Likewise, studies on human interaction with intelligent systems highlight that usability, acceptance, and transparent delivery channels strongly influence whether predictive information is effectively incorporated into decision processes [7,9].

Recent work has established conceptual and technical foundations for Raspberry Pi-based weather station networks targeting micro-zone climate monitoring in Colombian cities, defining hardware architectures, database schemas, and integration frameworks for machine learning-based prediction. Building upon these foundations, the present article documents the complete implementation and validation of a fully operational end-to-end system named ClimaBogotá v1.2. The system integrates four Raspberry Pi weather stations, a Python data-cleaning and feature-engineering pipeline, a Random Forest forecasting model with 43 predictors, a Flask REST API for real-time inference, automated n8n orchestration executing prediction cycles every 5 minutes, persistent PostgreSQL cloud storage, Telegram-based dissemination to subscribers, and Grafana Cloud visualization.

The principal scientific contributions of this work lie in three methodological advances that address persistent challenges in hyperlocal IoT-based climate prediction. First, the session-based feature engineering scheme enables supervised learning from temporally asynchronous and heterogeneous historical datasets without requiring strict time alignment between stations, overcoming a fundamental limitation of conventional multi-sensor fusion approaches that discard non-overlapping observations. Second, the fault-tolerant orchestration architecture ensures continuous operation and partial prediction delivery even when individual sensor nodes fail, a critical requirement for operational deployment that is absent from most research prototypes. Third, the complete integration of the prediction pipeline with accessible end-user delivery channels (Telegram subscription bot, web dashboard) demonstrates that hyperlocal climate intelligence can be made operationally usable at zero marginal cost, addressing the well-documented gap between technically accurate models and systems that non-expert users can trust and incorporate into decision-making workflows. These contributions extend beyond the specific case of Bogotá micro-zones and provide reusable design patterns for low-cost IoT-based environmental monitoring in resource-constrained settings.

The remainder of this article is organized as follows. Section 2 reviews the literature on low-cost environmental sensing, short-term predictive analytics, smart-environment orchestration, and trustworthy digital infrastructures, and positions the present work within the broader research trajectory on adaptive environmental intelligence. Section 3 describes the complete methodology, including the five-layer microservices architecture, the BME280 sensor network, the session-based data processing pipeline with mathematical formulations of the feature engineering operators, the Random Forest ensemble and confidence estimation, the Flask REST API, and the n8n orchestration, Telegram messaging, and PostgreSQL persistence subsystems. Section 4 presents the experimental results on the temporal validation set, feature importance analysis, error patterns, end-to-end latency breakdown, and operational continuity metrics. Section 6 concludes with a summary of contributions, limitations, and the roadmap for future system versions.

2. Related Work

The literature relevant to this study spans four convergent areas: low-cost environmental sensing, short-term predictive analytics, smart-environment orchestration, and trustworthy digital infrastructures. In the first area, the use of Raspberry Pi and low-cost sensors for environmental monitoring has been widely discussed as a viable alternative to expensive proprietary weather stations. Alali et al. [2] show that low-cost sensing infrastructures can provide sufficiently reliable measurements for localized monitoring applications, especially when combined with appropriate quality-control procedures. Camera-based and sensor-based low-cost approaches have also been validated in other monitoring domains: Vasta et al. [36] demonstrate that affordable sensing hardware can match the accuracy of scientific-grade instruments when combined with appropriate signal processing, a finding that supports the use of BME280-class sensors in the ClimaBogotá deployment. These works validate the feasibility of affordable sensor deployments, but generally focus on acquisition and monitoring rather than on complete predictive and operational ecosystems.

In the second area, machine learning techniques have demonstrated usefulness for short-term forecasting in environmental and time-series contexts. Random Forest remains attractive because it balances predictive capacity, robustness to noisy data, limited tuning requirements, and interpretability through feature importance analysis [3,12,13]. Naskinova et al. [42] provide a comprehensive comparative study of ML models for physiological prediction, showing that even well-engineered Random Forest and CatBoost pipelines yield modest $R^2$ values (0.19–0.27) when the target variable is inherently complex, which contextualises the $R^2=0.6286$ achieved by ClimaBogotá as a strong result for a similarly constrained prediction problem. Santamaría et al. [39] further demonstrate that compact, clinically relevant feature sets can yield robust predictive performance in ML-based decision-support systems, reinforcing the feature selection rationale adopted in this work. Hybrid AI systems have also been proposed in other data-intensive domains, such as smart education, where the integration of machine learning with heterogeneous big-data pipelines improves prediction and operational support [5]. Although these studies are not focused on meteorological micro-zones, they reinforce the methodological argument that predictive performance depends not only on the algorithm, but also on the quality of the full data-processing pipeline.

A third relevant line of work concerns smart environments and adaptive infrastructures. Recent studies highlight that AI-based systems are increasingly being deployed as part of broader digital ecosystems that must combine sensing, automation, optimization, resilience, and interoperability. Khan et al. [10] discuss the synergy between AI and blockchain in smart buildings to improve efficiency and security; Noetzold et al. [27] propose a self-adaptive architecture for predictive and reinforcement-based optimization in smart environments; and Holgado et al. [4], Tari et al. [8], and the work in [2] show that security, cryptographic agility, and human-centric resilience are increasingly necessary in connected infrastructures. The challenge of aligning heterogeneous temporal signals from multiple sources is also addressed in the multimodal detection literature: Luo et al. [43] propose a cross-modal temporal alignment module that maps signals from different sources into a unified temporal semantic space, a conceptual parallel to the session-based alignment strategy adopted in ClimaBogotá for multi-station data fusion. These works are especially important to position ClimaBogotá not merely as a weather-prediction model, but as a distributed smart-environment service in which data integrity, service continuity, and secure connectivity matter for future operational deployments.

A fourth area concerns trust, adoption, and human interaction with intelligent systems. Ibrahim et al. [9] show that digital interfaces affect decision-making performance and user experience in operational scenarios; Sasongko et al. [7] and Emon et al. [6] highlight the importance of perceived usefulness, self-efficacy, and attitudes in technology adoption; and Narayan et al. [11] discuss how trust and governance become central when AI-generated outputs influence user behaviour. The design of context-aware delivery channels is also relevant: Karlović et al. [41] demonstrate that LLM-based systems integrating contextual signals (user profile, environmental conditions) can produce more relevant and personalized outputs, a direction that informs the planned Version 2.0 of ClimaBogotá, which will incorporate a large language model for natural-language climate summaries. Although these studies address domains such as virtual reality, e-learning, professional AI adoption, and e-commerce governance, they are relevant here because micro-zone climate prediction systems ultimately depend on user trust, accessibility, and reliable information delivery. In this sense, the adoption of Telegram notifications and dashboard-based dissemination in ClimaBogotá is aligned with the broader need to make predictive systems operationally usable rather than merely technically accurate.

Furthermore, lightweight inference architectures designed for resource-constrained edge devices are increasingly relevant for IoT deployments. Riaz et al. [40] show that compact models combining local and global feature extraction can achieve real-time inference performance on edge hardware, a design principle that informs the Flask-based inference layer of ClimaBogotá, where the 269 MB Random Forest model must respond within 2.5 seconds on a standard cloud instance.

Despite these advances, the existing literature rarely combines all the layers required for a fully operational hyperlocal climate prediction service. Prior works typically emphasise either sensing, or prediction, or smart-environment architecture, or user-facing dissemination. In contrast, the present work integrates low-cost IoT sensing, data cleaning for non-standard field exports, session-based temporal feature engineering, machine learning inference, workflow orchestration with n8n, persistent cloud storage, Telegram-based subscription delivery, and Grafana Cloud visualization in a single reproducible architecture.

2.1. Positioning Within Prior Research

The development of ClimaBogotá represents the culmination of a systematic research trajectory focused on adaptive intelligent systems for environmental and smart-environment applications. Table 1 summarizes the internal evolution of these contributions and illustrates how each prior phase informs the current hyperlocal climate intelligence architecture.

This progression begins with the cryptographic performance analysis in PRISEC [17], which establishes the computational feasibility of secure data transmission on resource-constrained IoT devices such as Raspberry Pi. PRISEC II [18] introduces the conceptual framework for integrating multi-layer contextual information—device state, network conditions, environmental parameters—into adaptive security policies, a principle directly applied in ClimaBogotá’s fault-tolerant consolidation logic that adapts predictions based on station availability. PRISEC III [19] advances this concept by demonstrating dynamic cryptographic switching, analogous to the session-based feature engineering in ClimaBogotá that adapts to varying temporal coverage across stations.

Table 2 summarizes the main differences between representative prior works and the system proposed in this article. The Oraculum framework [20] introduces reinforcement learning-based self-adaptive optimization for smart environments, providing the methodological foundation for autonomous orchestration that informed the design of the n8n pipeline’s fault-tolerant consolidation and the confidence-based prediction delivery mechanism. Finally, the DN25 protocol [21] establishes quantum-safe communication primitives for distributed IoT systems, representing a future-proofing pathway for ClimaBogotá when the network scales beyond the current four-station prototype and requires secure inter-station coordination.

2.2. Q-OPSEC and DN25: Secure Adaptive Frameworks as Foundations for ClimaBogotá

A research trajectory directly connected to the present work is the line of contributions by Noetzold et al. on secure and adaptive architectures for distributed IoT environments, which constitutes both a methodological antecedent and a future-proofing pathway for ClimaBogotá. This trajectory begins with the PRISEC series  [???], which benchmarks symmetric cryptographic algorithms on Raspberry Pi-class hardware and demonstrates that AES-128 and ChaCha20 can sustain secure sensor-to-server communication at the sampling rates required by ClimaBogotá’s 5-second acquisition cycle without exceeding the computational budget of the ARM Cortex-A72 processor. This result is directly relevant to the four BME280 stations deployed in Bogotá: as the system transitions from CSV-based data export to direct MariaDB streaming (planned for v1.3), each station will require an authenticated and encrypted channel to the Flask inference server, and the PRISEC benchmarks provide the empirical basis for selecting the appropriate cipher without degrading the 5-second sampling interval.

PRISEC II [?] extends this foundation by introducing a multi-layer contextual security model in which cryptographic policies adapt dynamically to the operational state of each node—device load, network quality, and environmental conditions. This principle is structurally analogous to the fault-tolerant consolidation logic of ClimaBogotá’s n8n orchestration layer, which adapts the zone prediction based on the number of active stations: when Este or Oeste are unavailable (as occurred during the initial deployment in December 2024, when these stations had only 9 days and 3 weeks of data respectively), the pipeline substitutes the missing readings with the most recent valid prediction rather than aborting the cycle. Both systems share the same design philosophy: operational continuity under partial node failure, with graceful degradation rather than hard failure.

PRISEC III [?] advances this concept further by demonstrating dynamic cryptographic switching based on runtime context, a mechanism analogous to the session-based feature engineering of ClimaBogotá (Equation (1)), where the definition of a valid session ${\mathcal{S}}_k$ adapts to the temporal coverage available from each station. Just as PRISEC III selects the cipher that best fits the current resource profile, the session operator selects the feature window that best fits the available data density—both mechanisms implement context-aware adaptation at the operational layer.

The Oraculum framework [?] introduces reinforcement learning-based self-adaptive optimization for smart environments, providing the methodological reference for the autonomous orchestration design of ClimaBogotá’s n8n pipeline. Specifically, the confidence-based prediction delivery mechanism (Equation (8)), which maps the Random Forest’s inter-tree standard deviation $\sigma \left(\mathbf{x}\right)$ to a $[0,1]$ confidence score reported via Telegram, implements a lightweight version of the adaptive output modulation principle of Oraculum: the system communicates not only the predicted temperature but also its epistemic uncertainty, enabling end users to calibrate their trust in the prediction based on the current state of the sensor network.

Finally, the DN25 protocol [?] and its underlying Q-OPSEC framework address the challenge of securing inter-node communication in heterogeneous distributed IoT networks where nodes differ in computational capacity, connectivity, and data availability—conditions that precisely characterise the four-station ClimaBogotá network, where Norte and Sur have 18 months of history while Este and Oeste were deployed only in December 2024. DN25 defines an adaptive quantum-safe handshake that negotiates post-quantum cryptographic parameters based on the endpoint’s resource profile, making it directly applicable to a scenario where Raspberry Pi 4B stations (ARM Cortex-A72, 4 GB RAM) must communicate securely with a Flask server hosted on a free-tier cloud instance with variable latency. The integration of DN25 into ClimaBogotá v1.3 is identified as the primary security upgrade for the transition from prototype to operational service.

3. Methodology

ClimaBogotá v1.2 follows a five-layer microservices architecture with clear separation of responsibilities, as illustrated in Figure 1. This design allows each layer to be independently modified, replaced, or scaled without affecting the others, which constitutes a fundamental decision for the long-term sustainability of the project. The five layers defined in the system are: (1) IoT hardware data acquisition; (2) processing and inference with Python/Flask; (3) orchestration with n8n; (4) persistence with PostgreSQL; and (5) distribution and visualisation with Telegram and Grafana. Communication between these layers is performed exclusively via HTTP REST, guaranteeing interoperability and facilitating the replacement of any component within the ecosystem.

The microservices architecture follows the principle of loose coupling and high cohesion, where each layer exposes a well-defined contract through RESTful interfaces. This architectural pattern enables independent scalability: the Flask inference layer can be horizontally scaled by deploying multiple instances behind a load balancer, while the n8n orchestration layer can be parallelised across multiple workflow executions. The separation of concerns also facilitates incremental updates: the machine learning model can be retrained and redeployed without modifying the orchestration logic, and new visualisation endpoints can be added to the Grafana dashboard without affecting the prediction pipeline. The Flask server acts as the central hub of the system and is the only component with direct access to the trained machine learning model. All other components interact with the model exclusively through the REST API endpoints, which enforces a strict separation between inference logic and orchestration logic. This design choice also simplifies future model updates: replacing the model file requires only restarting the Flask server, with no changes to the orchestration pipeline or the distribution layer.

3.1. Data Acquisition Layer

Each weather station consists of a Raspberry Pi 4B (4 GB RAM, ARM Cortex-A72 quad-core processor at 1.5 GHz) with a Bosch Sensortec BME280 sensor connected via the I²C protocol. The BME280 was selected for its precision (±1.0°C absolute accuracy for temperature, ±1 hPa for atmospheric pressure, and ±3% for relative humidity), low power consumption, and availability in the Colombian market. The use of affordable, widely available sensing hardware is consistent with recent findings showing that low-cost sensor platforms can match the accuracy of more expensive instruments when paired with appropriate data processing pipelines [36]. Figure 2 shows one of the deployed weather stations.

The sensor specifications of the BME280 are particularly well-suited for the climatic conditions of Bogotá. At 2,600 m above sea level, atmospheric pressure ranges between 730 and 760 hPa, well within the sensor’s operational range of 300–1100 hPa. The temperature range of the city, which rarely falls below 5°C or exceeds 25°C, is also comfortably within the sensor’s measurement range. The I²C protocol operates at 400 kHz (Fast Mode) on the Raspberry Pi, enabling a theoretical maximum sampling rate of approximately 30 Hz for the BME280, although the current implementation uses a conservative 0.2 Hz (5-second interval) to balance data granularity with storage overhead and sensor lifespan. The I²C address of the BME280 is configurable via the SDO pin (0x76 or 0x77), allowing multiple sensors on the same bus, although the current deployment uses one sensor per Raspberry Pi to simplify wiring and reduce the risk of address conflicts.

The data collection script on each Raspberry Pi executes a reading cycle every 5 seconds, storing each record in a local MariaDB database with fields for timestamp (ISO 8601), device identifier, temperature in degrees Celsius, pressure in hectopascals, and relative humidity in percentage. The 5-second sampling interval was chosen as a balance between data granularity and storage requirements: at this rate, each station generates approximately 17,280 records per day, or roughly 6.3 million records per year. The four stations accumulated a total of 310,448 raw records during the operating period, of which 216,949 were retained after quality filtering. A significant temporal asymmetry was identified: the Norte and Sur stations have 18 months of history (March 2023 to December 2024), while the Este and Oeste stations have only 9 days and 3 weeks of data respectively, both from December 2024. Table 3 presents the unified view of the sensor specifications and the historical data distribution across the four stations.

3.2. Data Processing Pipeline

The difference between raw and valid records is attributable to three distinct categories of anomalies. The first category consists of cross-contamination records: 7,240 readings from the Este station file that were actually generated by the Norte station device (rasberry_1), resulting from an incorrect database export that merged two tables. The second category consists of overheating records: 4,985 readings from the Oeste station with temperatures above 27°C, which correspond to sensor failures caused by direct solar radiation on the enclosure. The third category consists of integrity failures: 1,274 records with null values or invalid timestamp formats distributed across all four stations.

The first significant technical challenge encountered during data processing was the format of the CSV files exported from MariaDB. The standard exports generated files where all records were concatenated into a single line of text without line breaks, making them unreadable by conventional tools including pandas.read_csv(), Unix awk/sed commands, and Microsoft Excel. A custom parser (parsear_estaciones.py) was developed using Python’s re module to extract each record via a regular expression that detects the pattern of five quoted fields. After parsing, three cascaded quality filters were applied.

The feature engineering scheme was designed specifically to overcome the temporal asymmetry limitation between stations. The challenge of aligning heterogeneous temporal signals from multiple independent sources is a well-recognised problem in multi-modal data processing: Luo et al. [43] address a similar issue in live-streaming platforms by mapping signals from different modalities into a unified temporal semantic space, while Kim et al. [38] demonstrate that fusing local and global feature representations improves model robustness when input sources have different temporal granularities. A session ${\mathrm{Session}}_k$ is defined as a maximal block of consecutive records where the gap between successive readings does not exceed 5 minutes:

$${\mathrm{Session}}_k={\{r_i:t_{i+1}-t_i\le 5\min \}}_{i\in {\mathcal{I}}_k}$$

(1)

where ${\mathcal{I}}_k$ denotes the index set of the k-th session. This session-based approach is a deliberate departure from the conventional time-alignment strategy, which would require all four stations to have simultaneous records and would therefore discard the majority of the Norte and Sur data when combined with the much shorter Este and Oeste series. The target variable for each sample is defined as:

$$y_i=T_{i+360}(30-\mathrm{minute}\mathrm{ahead}\mathrm{prediction})$$

(2)

where the offset of 360 positions corresponds to $360\times 5\mathrm{s}=1,800\mathrm{s}=30$ minutes at the 5-second sampling rate.

The feature engineering pipeline transforms the raw time series ${\{T_i,P_i,H_i\}}_{i=1}^N$ into a supervised learning dataset where each sample consists of a 43-dimensional feature vector ${\mathbf{x}}_i\in {\mathbb{R}}^{43}$ and a scalar target $y_i=T_{i+360}$ representing the temperature 30 minutes ahead. The transformation includes temporal lag operators ${\mathcal{L}}_k\left[T_i\right]=T_{i-k}$ for $k\in \{1,6,12,36,72,180,360\}$, differential operators ${\mathcal{D}}_w\left[T_i\right]=T_i-T_{i-w}$ for $w\in \{12,72\}$, and rolling window operators ${\mathcal{R}}_w\left[T_i\right]$ as defined in Equation (3). The cyclic encoding of hour-of-day and day-of-year via sine and cosine transforms (Equation (5)) ensures that the model correctly interprets the circular nature of time: hour 23 is close to hour 0, and December 31 is close to January 1.

The rolling mean, differential, and temporal encoding operators are formally defined as:

$${\mathrm{roll}}_w\left(T_i\right)={\displaystyle \frac{1}{w}}{\displaystyle \sum _{j=i-w+1}^i}{T}_j$$

(3)

$${\Delta }_w\left(T_i\right)=T_i-T_{i-w}$$

(4)

$$h_{sin}=sin\left({\displaystyle \frac{2\pi h}{24}}\right),h_{cos}=cos\left({\displaystyle \frac{2\pi h}{24}}\right)$$

(5)

where w is the window size in number of samples and h is the hour of day. Analogous sine/cosine encodings are applied to the day-of-year variable with a period of 365.25 days.

Table 4 provides a unified summary of the quality control filters and the feature engineering categories, including the mathematical formulations applied in each case.

3.3. Random Forest Prediction Model

The ensemble prediction and its associated uncertainty are computed as follows. Given a forest of B decision trees, the predicted temperature is the average of the individual tree outputs:

$$\widehat{y}={\displaystyle \frac{1}{B}}{\displaystyle \sum _{b=1}^B}{T}_b\left(\mathbf{x}\right)$$

(6)

where $T_b\left(\mathbf{x}\right)$ denotes the prediction of the b-th tree for input vector $\mathbf{x}$. The prediction uncertainty is estimated via the empirical standard deviation across trees:

$$\sigma \left(\mathbf{x}\right)=\sqrt{{\displaystyle \frac{1}{B-1}}{\sum }_{b=1}^B{\left(T_b\left(\mathbf{x}\right)-\widehat{y}\right)}^2}$$

(7)

The model confidence score, reported to end users via the Telegram bot and the Grafana dashboard, is derived from $\sigma$ through a logistic transformation that maps the unbounded standard deviation to the $[0,1]$ interval:

$$\mathrm{Confidence}\left(\mathbf{x}\right)={\displaystyle \frac{1}{1+\sigma \left(\mathbf{x}\right)}}$$

(8)

The Random Forest ensemble leverages the bias-variance tradeoff by combining $B=300$ independently trained decision trees, each constructed on a bootstrap sample of the training set (bagging) and using a random subset of $\sqrt{n}$ features at each split (random subspace method). This double randomisation decorrelates the individual trees, reducing the variance of the ensemble prediction without significantly increasing bias. The standard deviation $\sigma \left(\mathbf{x}\right)$ across the 300 tree predictions (Equation (7)) provides a natural measure of prediction uncertainty: low $\sigma$ indicates consensus among trees (high confidence), while high $\sigma$ indicates disagreement (low confidence), often occurring at the boundaries of the training distribution or during rapid transient events.

The choice of Random Forest over alternative algorithms such as gradient boosting or recurrent neural networks was motivated by four considerations: (1) robustness to sensor noise; (2) ability to capture non-linear relationships; (3) interpretability through feature importance analysis; and (4) computational efficiency, with training completing in approximately 4 minutes and inference taking less than 2 seconds per prediction. The final dataset of 210,225 samples was split using a temporal 85%/15% split, preserving chronological order to prevent data leakage. Table 5 lists the complete set of hyperparameters and their mathematical justifications.

3.4. Inference API and Service Layer

The Flask v2.3 server loads the 269 MB serialised model into RAM at startup and exposes it through a REST API. The design of a lightweight inference layer capable of real-time response on standard cloud hardware is consistent with recent work on compact model architectures for resource-constrained environments: Riaz et al. [40] demonstrate that models combining local and global feature extraction can achieve real-time inference at approximately 15 FPS on edge devices, a performance target analogous to the sub-2.5-second response requirement of the ClimaBogotá inference endpoint. Table 6 describes all available API endpoints.

The REST API follows the JSON:API specification for resource naming and response formatting, with CORS headers enabled to allow cross-origin requests from the Grafana Cloud dashboard. All endpoints support HTTP OPTIONS for preflight requests, and the server implements rate limiting (100 requests/minute per IP) to prevent abuse. The /predecir endpoint accepts an array of exactly 400 timestamped readings, validates the temporal ordering, checks for missing fields, and returns a 400 Bad Request if the input is malformed. The inference latency of 1.5–2.5 seconds is dominated by the feature construction step (rolling windows and lags), which requires iterating over the 400-element input array multiple times; the actual Random Forest predict() call takes only 50–100 ms.

3.5. Orchestration, Messaging, and Persistence

The n8n orchestration pipeline executes the complete prediction cycle every 5 minutes through 7 sequential stages: reading the four CSV files, preparing the last 400 readings per station, calling POST /predecir for each of the four stations in parallel, consolidating the four predictions into a single zone report with fault tolerance, saving the consolidated result to PostgreSQL via POST /guardar, formatting the Telegram message, and sending it to all subscribers. The fault-tolerant consolidation node is a key design feature: it reads the results of the four prediction nodes by name using n8n’s $(’NodeName’).first().json syntax, wrapped in try/catch blocks, so that a failure in any individual station branch does not abort the entire pipeline. Figure 3 shows the complete n8n workflow as deployed.

The Telegram bot (@ClimaBogotaBot) supports subscription management via a persistent suscriptores.txt file. The webhook architecture uses ngrok with a fixed domain to expose the Flask /webhook endpoint to the internet, ensuring that the webhook URL remains stable across server restarts. The PostgreSQL database on Render Cloud stores one consolidated row per prediction cycle, with nullable columns for individual station temperatures that allow the system to record partial results when one or more stations are unavailable. Table 7 consolidates the three integration subsystems into a unified view.

The Grafana Cloud dashboard connects to this database via the native PostgreSQL plugin and displays four panels: time series of temperature by station, model confidence over time, current status statistics, and a tabular history of the last 20 records, all updated every 5 minutes. Table 8 provides a complete summary of all system components, their roles, and their associated costs.

The total hardware cost of 160–240 USD covers four Raspberry Pi 4B units with their respective BME280 sensors, power supplies, microSD cards, and ventilated enclosures. The zero monthly cloud cost is achieved by using the free tiers of Render (PostgreSQL, 1 GB), Grafana Cloud (10,000 metrics), Telegram Bot API, and ngrok (one fixed domain). This cost structure makes the system economically viable for academic research, community initiatives, and small organisations in middle-income countries.

3.6. Security Architecture and Q-OPSEC Alignment

The five-layer microservices architecture of ClimaBogotá v1.2 was designed with security extensibility as a first-class requirement, informed by the PRISEC–Oraculum–DN25 research trajectory [???,?,?]. The current prototype deliberately separates the validation of the prediction pipeline from the hardening of the communication layer: the system first demonstrates operational feasibility ($\mathrm{MAE}=2.{59}^{\circ }\mathrm{C}$, $R^2=0.6286$, zero monthly cloud cost) before introducing cryptographic overhead that could complicate performance profiling during the initial deployment phase.

All inter-layer communication in ClimaBogotá v1.2 is performed via plain HTTP REST. Each Raspberry Pi station writes sensor readings to a local MariaDB database and exports them as CSV files, which are consumed by the n8n orchestration pipeline every 5 minutes. This architecture has a measurable security deficit: a compromised station could inject a fabricated reading ${\tilde{y}}_i$ into the feature vector ${\mathbf{x}}_k$ (Equation (3)), producing a corrupted prediction ${\widehat{y}}_{\mathrm{zone}}$ without triggering any integrity check. The magnitude of this attack is bounded by the influence of station i on the zone prediction:

$$\Delta {\widehat{y}}_{\mathrm{zone}}=w_i·\left|{\widehat{y}}_i\left({\mathbf{x}}_k\right)-{\widehat{y}}_i\left({\tilde{\mathbf{x}}}_k\right)\right|\le w_i·{ϵ}_{max},$$

(9)

where ${\tilde{\mathbf{x}}}_k$ is the feature vector with the injected reading and ${ϵ}_{max}$ is the maximum injection magnitude. For the current uniform weighting $w_i=0.25$, a single compromised station can shift the zone prediction by up to $0.25·{ϵ}_{max}$, which for ${ϵ}_{max}={10}^{\circ }\mathrm{C}$ yields a maximum zone error of $2.5^{\circ }\mathrm{C}$—comparable to the current MAE of $2.{59}^{\circ }\mathrm{C}$ and therefore sufficient to render the prediction operationally misleading.

The PRISEC benchmarks [???] establish that, for a BME280 payload of $b=64$ bytes, the encryption latency satisfies ${\tau }_c\left(b\right)<2$ ms on ARM Cortex-A72, representing an overhead fraction:

$$\varphi ={\displaystyle \frac{{\tau }_c\left(b\right)}{\Delta t_s}}<{\displaystyle \frac{2\times {10}^{-3}}{5}}=4\times {10}^{-4},$$

(10)

where $\Delta t_s=5$ s is the sampling interval. This confirms that AES-128-GCM or ChaCha20-Poly1305 can be applied to every sensor reading without affecting the acquisition cycle. The contextual security policy of PRISEC II [?] will govern cipher selection in v1.3, mapping the station’s operational state ${\mathbf{s}}_i=({\rho }_i,{\mu }_i,{\lambda }_i)$ to the optimal cipher $c_i^{*}=\pi \left({\mathbf{s}}_i\right)$ as defined in Equation (2) of the related works section, ensuring that the cryptographic overhead remains within the bound $\varphi <4\times {10}^{-4}$ even under variable CPU load.

The fault-tolerant consolidation logic of the n8n pipeline is formalised as a weighted aggregation over the set of active stations $\mathcal{A}\subseteq \{1,2,3,4\}$:

$${\widehat{y}}_{\mathrm{zone}}={\displaystyle \frac{{\sum }_{i\in \mathcal{A}}{w}_i·{\widehat{y}}_i}{{\sum }_{i\in \mathcal{A}}{w}_i}},w_i={\displaystyle \frac{1}{1+{\mathrm{MAE}}_i}},$$

(11)

where ${\mathrm{MAE}}_i$ is the historical mean absolute error of station i computed over its validation set. This inverse-MAE weighting scheme assigns higher influence to stations with longer and more accurate operational histories (Norte and Sur, with 18 months of data) and lower influence to recently deployed stations (Este and Oeste, with fewer than 30 days at the time of writing), directly addressing the temporal asymmetry in the training corpus of 310,448 records. The Oraculum framework [?] provides the pathway for replacing this deterministic weighting with a learned policy ${\pi }_{\theta }$ that optimises the composite objective:

$$J\left(\theta \right)=-\mathbb{E}\left[{\mathrm{MAE}}_{\mathrm{zone}}\right]+{\lambda }_r·\mathbb{E}\left[n_a\right]-{\lambda }_s·\mathbb{E}\left[{\sigma }_{\mathrm{zone}}\right],$$

(12)

where ${\lambda }_r$ and ${\lambda }_s$ are regularisation coefficients that penalise low station availability and high prediction uncertainty respectively, and ${\sigma }_{\mathrm{zone}}$ is the inter-station standard deviation of individual predictions.

The confidence score delivered via Telegram is computed as:

$$\mathcal{C}\left(\mathbf{x}\right)=1-{\displaystyle \frac{\sigma \left(\mathbf{x}\right)}{{\sigma }_{max}}},\sigma \left(\mathbf{x}\right)=\sqrt{{\displaystyle \frac{1}{T}}{\sum }_{t=1}^T{\left({\widehat{y}}_t\left(\mathbf{x}\right)-\overline{y}\left(\mathbf{x}\right)\right)}^2},$$

(13)

where T is the number of trees in the Random Forest ensemble, ${\widehat{y}}_t\left(\mathbf{x}\right)$ is the prediction of tree t, $\overline{y}\left(\mathbf{x}\right)$ is the ensemble mean, and ${\sigma }_{max}$ is the maximum observed inter-tree standard deviation over the validation set. A confidence score $\mathcal{C}\left(\mathbf{x}\right)\ge 0.75$ indicates that the ensemble is in a low-uncertainty region of the feature space, while $\mathcal{C}\left(\mathbf{x}\right)<0.50$ signals that the current atmospheric conditions are underrepresented in the 310,448-record training corpus.

The integration of DN25 [?] into ClimaBogotá v1.3 will replace the current ngrok HTTP tunnel with a Q-OPSEC-secured channel. Each station $e_i$ will authenticate to the Flask server using a CRYSTALS-Kyber-768 key pair, and the shared session key $K_{\mathrm{session}}$ will be derived as:

$$K_{\mathrm{session}}=\mathrm{KDF}\left(\mathrm{Kyber}.\mathrm{Dec}({\mathrm{sk}}_i,{\mathbf{c}}_i)\parallel {\mathrm{nonce}}_i\right),$$

(14)

where ${\mathrm{sk}}_i$ is the station’s private key, ${\mathbf{c}}_i$ is the ciphertext received from the server, ${\mathrm{nonce}}_i$ is a session-specific random value, and KDF is a key derivation function (HKDF-SHA3-256). This authenticated channel prevents the data injection attack quantified in Equation (6), reducing $\Delta {\widehat{y}}_{\mathrm{zone}}$ to zero for any station operating under a valid Q-OPSEC session. The security roadmap from the current unauthenticated HTTP prototype to a Q-OPSEC-secured operational service reflects the broader design philosophy of ClimaBogotá: each version advances one architectural layer while preserving the validated components of the previous version, ensuring that the transition from research prototype to urban operational service is incremental, reproducible, and grounded in empirically validated security primitives.

4. Results

The model was evaluated on the temporal validation set of 31,534 samples, corresponding to 15% of the total dataset reserved exclusively for validation and never exposed during training. The temporal split strategy, preserving chronological order, is critical in time-series forecasting to prevent data leakage, since a random split would allow the model to implicitly learn future patterns from training samples interleaved with validation samples, artificially inflating performance metrics. The Mean Absolute Error (MAE) achieved was 2.59°C, the Root Mean Square Error (RMSE) was 4.46°C, the coefficient of determination $R^2$ was 0.6286, the Mean Absolute Percentage Error (MAPE) was 16.2%, and the median absolute error was 1.87°C. These results indicate that the model explains approximately 62.9% of the temperature variability in the validation set, and that half of all predictions carry an error below 1.87°C. To contextualise these values, the standard deviation of temperature in the validation dataset is approximately 3.2°C, which means the model captures the majority of the temporal patterns present in the data. It is worth noting that an $R^2$ of 0.6286 represents a strong result for this class of prediction problem: Naskinova et al. [42] report that even well-tuned ensemble models (CatBoost, Random Forest) achieve $R^2$ values of only 0.19–0.27 when predicting physiological variables from routinely collected clinical data, underscoring that modest explained variance is a common outcome when the target variable is inherently complex and the available features capture only a fraction of the underlying dynamics. The gap between MAE (2.59°C) and RMSE (4.46°C) indicates the presence of a subset of high-error predictions, which are analysed in detail below. Table 9 presents the complete set of performance metrics.

The feature importance analysis reveals that the most influential predictors are recent temperature statistics, which is consistent with the physics of short-term prediction: the 6-minute rolling mean of temperature accounts for 15.3% of the model’s decision weight, followed by the 1-minute rolling mean (10.8%) and the current temperature value (9.7%). Together, these three features alone account for 35.8% of the total predictive weight, confirming that the thermal inertia of the local microclimate is the dominant signal at the 30-minute horizon. Temporal cyclic features (hour sine and cosine) appear in positions 8 and 10, confirming that the model has learned the diurnal patterns of Bogotá’s climate, particularly the characteristic morning warming between 08:00 and 13:00 and the afternoon cooling after 16:00 associated with convective activity. Pressure-based features appear from position 9 onwards, suggesting that atmospheric pressure contributes secondary but non-negligible predictive information at the 30-minute horizon. Figure 4 presents the top 10 most important features.

The analysis of prediction errors reveals a systematic pattern: the largest errors (above 5°C) are concentrated in abrupt temperature changes typical of Bogotá afternoons between 14:00 and 17:00, when direct sunlight can rapidly raise the temperature while convective clouds produce sudden drops. This phenomenon, locally known as veranillo de la tarde, is characterised by temperature gradients exceeding 4°C in under 20 minutes, which falls precisely within the 30-minute prediction horizon of the model. The Random Forest architecture, being a tree-based ensemble that interpolates between training observations rather than extrapolating, is inherently limited in its ability to predict temperature values outside the range observed during training for a given feature combination. This structural limitation explains why the RMSE (4.46°C) is disproportionately larger than the MAE (2.59°C). The end-to-end latency of the prediction pipeline was measured across 50 consecutive execution cycles during the testing period. Table 10 presents the latency breakdown by pipeline stage.

The dominant stage is the parallel Flask inference calls (8–12 s), which involve loading the last 400 readings per station from CSV, constructing the 43-feature vector, and invoking the Random Forest’s predict() method on the 269 MB serialised model. The parallelisation of the four station calls via n8n’s native HTTP node reduces this stage from a theoretical sequential maximum of 48 s to the observed 8–12 s. The PostgreSQL persistence stage (3–5 s) is bounded by the round-trip latency to Render Cloud’s free-tier infrastructure in the US-East region, which introduces a fixed network overhead of approximately 180 ms per request. The total cycle latency of 30–45 s represents only 10–15% of the 5-minute cycle period, leaving ample margin for additional processing stages in future versions of the pipeline.

Figure 5. Scatter plot of model predictions versus actual temperature values on the temporal validation set (31,534 samples).

Figure 5. Scatter plot of model predictions versus actual temperature values on the temporal validation set (31,534 samples).

The n8n pipeline operated continuously during the development and testing period without manual errors, with all four stations active simultaneously. The Telegram bot responded to /predecir commands in under 5 seconds. The Grafana dashboard updated every 5 minutes with data from all four stations, and the PostgreSQL database on Render accumulated one consolidated prediction row per cycle with no data loss during the test period, resulting in a database of approximately 2,016 prediction records per week of continuous operation. The total cloud infrastructure cost was 0 USD/month, with a one-time hardware investment of 160–240 USD for the four Raspberry Pi stations.

The most significant limitation of the current model is the temporal asymmetry between stations: Norte and Sur have 18 months of history covering multiple seasons, while Este and Oeste have only 9 days and 3 weeks of data from December 2024. This means the model has not learned the seasonal variation patterns of the Este and Oeste stations, nor the spatial gradients between all four zones. It is estimated that with 6 months of simultaneous data from all four stations, the $R^2$ should improve to a range of 0.72–0.80. Additional current limitations include the operation with historical CSV files rather than real-time Raspberry Pi readings, the dependency on a local machine to run Flask and n8n, and the absence of external validation data from IDEAM stations to quantify the systematic bias of the model with respect to official measurements.

5. Discussion

The results presented in Section 4 confirm that the ClimaBogotá v1.2 architecture achieves its primary design objectives: operational feasibility, economic accessibility, and predictive reliability at the micro-zone scale. The MAE of 2.59°C and $R^2$ of 0.6286 are consistent with the expected performance of a Random Forest model trained on a temporally asymmetric dataset, where two of the four stations contribute only short-term data from a single month. As demonstrated by Naskinova et al. [42], even state-of-the-art ensemble methods face fundamental limits when the available features capture only a fraction of the target variable’s variance; the $R^2$ achieved here is therefore a strong result given the data maturity constraints. The session-based feature engineering scheme proved effective in enabling supervised learning from heterogeneous historical records without discarding the majority of the Norte and Sur data, which would have been the outcome of a conventional time-alignment strategy. This approach is conceptually aligned with the cross-modal temporal alignment strategies proposed by Luo et al. [43] and the local-global feature fusion demonstrated by Kim et al. [38], both of which address the challenge of integrating signals with different temporal granularities.

The fault-tolerant n8n orchestration architecture demonstrated continuous operation throughout the testing period, validating the design decision to use try/catch consolidation logic rather than strict pipeline dependencies. The Telegram-based dissemination channel proved operationally effective, with response latencies under 5 seconds for on-demand predictions, confirming that the system can serve non-expert users without requiring additional applications or proprietary infrastructure. The planned integration of a large language model for natural-language climate summaries in Version 2.0 is supported by recent evidence that context-aware LLM systems can produce more relevant and personalized outputs when environmental and user-profile signals are incorporated into the retrieval pipeline [41].

The identified limitation of temporal asymmetry between stations is not a fundamental architectural constraint but rather a data maturity issue that will be resolved as the Este and Oeste stations accumulate longer operational histories. The projected $R^2$ improvement to 0.72–0.80 after six months of simultaneous four-station operation is consistent with the expected reduction in model uncertainty when spatial gradient features become available across all zones.

6. Conclusions

This work demonstrated that it is possible to implement a fully functional hyperlocal climate prediction system for Colombian micro-zones using low-cost hardware, open-source software, and free cloud services. The successful implementation of the five system layers, from Raspberry Pi data collection to Grafana Cloud visualisation, validates the conceptual proposal of Guerrero Mateus and De Paz Santana (2024) and establishes a concrete experimental platform for subsequent research phases.

The main technical contributions of this work are: (1) the development of a robust parser for the non-standard data format generated by the Raspberry Pi stations, reusable in any similar deployment of the proposed architecture; (2) the design of a session-based feature engineering scheme that enables training machine learning models with temporally spaced and asynchronous data between stations, overcoming the conventional limitation of temporal alignment; (3) the integration of n8n as a low-code orchestrator for IoT climate prediction systems, with a fault-tolerant design that continues operating when one or more stations are inactive; and (4) the implementation of a Telegram-based prediction distribution system with persistent subscriptions that democratises access to predictions without requiring additional applications or proprietary notification infrastructure.

From a cost and accessibility perspective, the system demonstrates that the total implementation budget, estimated at 160–240 USD in hardware plus 0 USD/month in software infrastructure, is compatible with academic projects, community initiatives, and small organisations in middle-income countries such as Colombia. This economic accessibility is fundamental for the replicability of the system in other micro-zones across the country.

Future work is organised into four priority lines. Version 1.3 will connect n8n directly to the MariaDB databases of the four Raspberry Pi stations via the n8n MySQL plugin, eliminating the CSV file dependency, and will deploy Flask on Render with a paid plan to guarantee 24/7 availability. Version 1.4 will retrain the model after six months of simultaneous operation of all four stations in their definitive triangulated locations within the 10 km² micro-zone, enabling the model to learn spatial gradients and complete seasonal patterns, with an expected $R^2$ improvement to 0.72–0.80. Version 1.5 will integrate historical and real-time data from the nearest IDEAM stations as additional model features, enabling external validation and potentially extending the prediction horizon to 1–3 hours. Version 2.0 will integrate a large language model (Gemini 2.0 Flash) to generate climate analyses in accessible colloquial language for non-technical users [41], and will develop a custom web dashboard with an interactive micro-zone map visualising real-time temperature gradients [14,15,16].