A hybrid Zigbee–LoRa sensor network with integrated machine learning for ignition-stage wildfire risk monitoring

1 Introduction

Wildfires are an increasing threat to ecosystems, infrastructure, and public safety, driven by hotter temperatures, prolonged drought conditions, and expanding development near fire-prone landscapes. The time window with the highest operational value is often the ignition stage, when a fire is still small and rapid intervention can prevent escalation. However, many deployed monitoring approaches primarily detect fires after visible smoke or flames emerge, which can be too late to capture the ignition window reliably.

Wide-area remote sensing systems provide important coverage but have practical limitations for ignition-stage monitoring. Satellite-based detection can be delayed by revisiting timing and can be affected by clouds and occlusion. Camera towers and UAV-based monitoring can provide greater spatial detail, but performance depends on visibility and line-of-sight, and can increase operational complexity and power requirements. In practice, these constraints often shift detection toward later stages when smoke and flames are more apparent.

Ground-based sensing using low-power IoT nodes provides a complementary approach because it measures conditions close to surface fuels. Near-ground temperature and relative humidity capture microclimate states that correlate with ignition risk and can be sampled at high spatial density. The central challenge becomes network design: the system must support dense local sampling while delivering data reliably across longer distances under strict energy limits.

In this work, we design and evaluate a hybrid Zigbee–LoRa sensor network for ignition-stage wildfire risk monitoring. Zigbee mesh networking is used for short-range, low-power, multi-hop connectivity among sensing nodes, while LoRa is used only for long-range backhaul of aggregated records to a gateway connected to the cloud and dashboard. To provide immediate interpretation without introducing an additional cloud inference service, we integrate a lightweight Random Forest model into the web dashboard to classify incoming readings into a recall-oriented warning level in real time.

In summary, the contributions to this article are.

• A hybrid Zigbee–LoRa network architecture that separates dense local sensing traffic from long-range backhaul and uses coordinator-side batching to reduce long-range airtime under multi-node reporting.
• An end-to-end sensing-to-dashboard pipeline with real-time visualization and client-side machine learning inference.
• Experimental results quantifying packet delivery and latency across Zigbee hops, the LoRa backhaul, and the complete sensor-to-cloud path under multi-node operation, together with added short-range field measurements that compare open-field and forested non-line-of-sight LoRa conditions.

2 Related work

2.1 Remote sensing for wildfire detection

Remote sensing systems are widely used for wildfire monitoring because they can cover large areas, but they mainly identify events after visible or thermal fire cues are present. A practical limitation for ignition-stage use is time-to-observation and visibility: satellite-based detection can be delayed by revisiting timing, and performance can be degraded by cloud cover and occlusion (Mohapatra and Trinh, 2022). Camera-tower approaches detect smoke/flame patterns in images and therefore depend on line-of-sight and lighting; they can also be disrupted by weather conditions such as haze or fog, which affects the reliability of vision features used by deep-learning models (Saleh et al., 2023). UAV-based monitoring can improve viewpoint flexibility, but it introduces operational constraints such as flight time, launch/landing logistics, and weather dependence, making continuous ignition-stage coverage difficult without significant operational support (Ramadan et al., 2024). Survey work on AI-enabled wildfire observation similarly emphasizes that many vision-centric systems are strong for situational awareness when visible cues exist but are less reliable for early ignition-stage conditions where cues are weak or obscured (Boroujeni et al., 2024).

2.2 IoT ground sensing for early warning

Ground IoT systems address the visibility problem by measuring environmental variables near surface fuels. Surveys of IoT wildfire sensing describe architectures that continuously sample local microclimate conditions (e.g., temperature and relative humidity) and push measurements to a gateway for alerting (Chan et al., 2024). Across these systems, the key bottleneck is typically not sensor cost but network delivery under deployment constraints: the architecture must support (i) dense sampling where conditions vary locally, (ii) long-range connectivity to an access point, and (iii) low power for unattended operation (Chan et al., 2024).

2.3 Communication technologies: LoRa/LoRaWAN and Zigbee trade-offs

LoRa/LoRaWAN is a common choice for environmental sensing because it supports long-range links at low power. However, LoRaWAN scalability is constrained by duty-cycle limits and contention-based medium access, which reduces delivery reliability as the number of transmitting nodes and reporting rate increase (Adelantado et al., 2017; Jouhari et al., 2023). Measurement work also shows that LoRa performance depends strongly on deployment geometry and environment, reinforcing the need to manage airtime and configuration when reliable delivery is required at range (Masek et al., 2021). Zigbee (IEEE 802.15.4) provides short-range, low-power communication and supports multi-hop mesh forwarding, making it suitable for dense local sensing where nodes can relay traffic over multiple hops; performance studies report Zigbee’s suitability for IoT deployments in obstructed/cluttered environments (Haque et al., 2022). The main limitation for wide-area monitoring is that Zigbee’s short per-hop range increases the number of gateways (or backhaul points) needed if Zigbee is used alone for a large coverage area.

3 Motivation

The above trade-offs motivate hierarchical hybrid designs that separate dense local sensing from long-range transport instead of relying on a single protocol for both roles. In this work, Zigbee is used for dense near-ground collection and short-range forwarding, while LoRa is reserved for sparse long-range backhaul of aggregated records. This approach aligns with known LoRa/LoRaWAN scalability constraints by reducing long-range airtime use under multi-node operation (Adelantado et al., 2017; Jouhari et al., 2023) while leveraging Zigbee’s mesh reliability for local connectivity (Haque et al., 2022). The contribution of this study is therefore system-level rather than algorithmic. It does not propose a new radio protocol or a new classifier. Instead, it presents and experimentally evaluates an end-to-end wildfire-monitoring architecture that combines role-separated networking, coordinator-side payload aggregation, cloud-connected visualization, and browser-side risk scoring within a single prototype workflow. The added field measurements further bound the communication claims by showing how the LoRa backhaul behaves in short-range forested non-line-of-sight conditions.

4 Methods

4.1 System implementation

The system is implemented as a two-tier network consisting of a near-ground Zigbee mesh layer and a LoRa point-to-point backhaul to a cloud gateway. Near-ground sensing nodes use Arduino Uno Rev3 boards with an XBee Shield V2 and Digi XBee S2C Zigbee modules operating in API mode, connected to a DHT11 sensor sampling temperature and relative humidity at 1 Hz. The Zigbee layer is deployed in a mesh-capable configuration in which one XBee acts as the Zigbee coordinator and the remaining nodes operate as mesh participants; depending on placement, a node’s packets can reach the coordinator either directly (single hop) or via intermediate nodes (multi-hop forwarding). The long-range backhaul uses Arduino MKR WAN 1310 boards configured at 433 MHz with spreading factor 7, 125 kHz bandwidth, and 17 dBm transmit power. A cloud gateway built on an Arduino MKR WiFi 1010 receives LoRa payloads via I²C and uploads structured JSON records to Firebase Realtime Database over HTTPS. Figure 1 summarizes the end-to-end pipeline from near-ground sensing to cloud and dashboard.

Each sensor record contains a node identifier, temperature, relative humidity, battery voltage, received signal strength, and a device timestamp. Zigbee nodes transmit records using Zigbee API frames, and in the mesh layer, records are delivered to the Zigbee coordinator either directly or through multi-hop forwarding when intermediate nodes are present. The coordinator serves as the collection point and as the bridge to the long-range tier. It receives Zigbee records from multiple nodes, buffers them, and batches up to four records into a single LoRa payload to reduce LoRa airtime usage and collision probability. The LoRa sender transmits the payload to a LoRa receiver, which forwards the received payload to the WiFi gateway. The gateway appends a gateway timestamp and uploads each record to Firebase. A web-based dashboard built with Next.js. subscribes to Firebase updates in real time and visualizes node status and risk levels on an interactive map (Supplementary Figure S1). An estimated bill of materials for the prototype is provided in Supplementary Table S2 to indicate the approximate hardware cost range for one prototype sensing node and receiver-side bridge.

4.2 Machine learning model

Fire-risk classification is performed using a Random Forest model trained on the Forest Fires dataset introduced by Cortez and Morais (2007). For supervised wildfire-risk classification, the target was converted to a binary fire/no-fire label, with area >0 coded as fire and area = 0 coded as no-fire. Numeric variables were checked for missing values and used on their native physical scales. For the full-feature benchmark, month and day were one-hot encoded. The data were split with an 80:20 stratified holdout using random_state = 42, giving 413 training samples and 104 test samples.

Two feature sets were examined. The full-feature model used FFMC, DMC, DC, ISI, temperature, relative humidity, wind, rain, month, and day. The sensor-proxy model used only temperature and relative humidity, matching the measurements available on the field node. The Random Forest classifier was trained with fixed hyperparameters to keep the run reproducible: n_estimators = 200, criterion = gini, max_depth = 10, min_samples_split = 2, min_samples_leaf = 1, max_features = sqrt, bootstrap = True, class_weight = balanced, and random_state = 42. The same random_state = 42 was used for the stratified train-test split. The decision threshold for the reported offline benchmark was 0.50. The model was fit only on the training subset. The held-out test subset was used for ROC-AUC, average precision, accuracy, and weighted F1-score. Five-fold stratified cross-validation was used as a stability check for ROC-AUC. The 7770 local no-fire field log rows were scored only to inspect the normal operating probability range and threshold behaviour; they were not treated as labeled fire examples.

To compare the selected Random Forest classifier against common supervised baselines, five models were evaluated on the UCI Forest Fires benchmark using the same train-test split and feature set. Numeric variables were passed directly for tree-based models and standardized for Logistic Regression and SVM. Month and day were one-hot encoded. Class weighting was used where supported because the target classes were close but not perfectly balanced. The comparative benchmark results are summarized in Supplementary Table S1.

The purpose of the deployed model is conservative risk screening rather than final alarm adjudication, and the classifier is therefore evaluated here as a proof-of-concept risk-scoring component rather than as a site-calibrated wildfire detector. Inference runs directly in the dashboard (client-side) and completes in under 100 ms per record on standard hardware during live dashboard operation.

4.3 Power design

All nodes used a 5 V solar panel, a maximum power point tracking (MPPT)-based charging and power-management module, and a lithium-ion battery. To clarify the power profile of the sensing tier, current draw was measured at the sensing node during idle operation, sensor readout, and Zigbee transmission. The measured currents were approximately 42 mA in idle operation, 58 mA during sensor readout, and 90 mA during Zigbee transmission bursts. Under the implemented reporting behaviour, these measurements correspond to an average load of approximately 43–44 mA, or about 1.0 A h per day. A nominal 2,000 mA h battery, therefore, provides roughly 2 days of operation in battery-only mode, while a small solar contribution reduces the daily net drain but does not yet provide a large endurance margin for unattended deployment.

The sensing choice and reporting rate were selected for slow environmental variables rather than for combustion imaging. Temperature and relative humidity change gradually relative to packet-level communication timescales, so the 1 Hz sensing configuration is sufficient for trend monitoring and for the real-time warning interface used in this prototype. At the same time, the measured duty-cycle budget shows that longer autonomous operation will require more aggressive duty cycling, lower-power hardware, or a larger harvesting margin.

Solar contribution depends strongly on season, shading, and panel orientation and was not separately characterized over an extended deployment; the present energy analysis should therefore be read as a first-order duty-cycle budget rather than a seasonal autonomy model.

4.4 Evaluation metric

Zigbee performance is evaluated as per-hop link performance in an indoor line-of-sight corridor at hop distances of 10, 30, 50, and 80 m using a fixed packet count per distance run; these measurements characterize the hop reliability that underpins multi-hop mesh delivery in larger deployments. LoRa backhaul performance is evaluated in an outdoor open field under line of sight at distances of 100, 300, 500, and 800 m using the fixed LoRa configuration described in Section 4.1. Packet delivery ratio (PDR) is reported as the percentage of transmitted packets successfully received for each distance run. End-to-end sensor-to-cloud latency is computed as the difference between the device timestamp carried in each record and the gateway timestamp appended immediately before upload to Firebase; this end-to-end metric captures Zigbee delivery, including any forwarding, coordinator batching, LoRa transmission, gateway handling, and cloud upload under multi-node operation.

To examine vegetation and non-line-of-sight effects more directly, additional LoRa field measurements were conducted in open-field and forested settings at 25 m and 50 m, together with a short 5 m indoor baseline. Each outdoor condition was repeated three times over 600 s runs. The total transmitted packet counts were 872 for open-field 25 m, 872 for open-field 50 m, 871 for forest 25 m, and 870 for forest 50 m. For these repeated runs, PDR is reported together with the mean, standard deviation, and 95% confidence interval. The resulting summary statistics and packet totals are presented in Table 1. Receiver-log inter-arrival time is reported for comparison across repeated runs and is not used in place of the end-to-end latency metric.

TABLE 1. Summary of repeated LoRa field trials. Mean inter-arrival time is the average time between consecutive packets received and is reported here for comparison across runs, not as end-to-end latency.

PDR, packet delivery ratio; NLOS, non-line-of-sight; SD, standard deviation; CI, confidence interval.

Because PDR was near saturation across conditions, RSSI was treated as the primary continuous response variable for inferential comparison. Statistical comparisons were therefore performed on run-mean RSSI to avoid treating individual packet rows as independent runs. A one-way analysis of variance (ANOVA) was used across the five conditions, and a two-way ANOVA was used for the outdoor subset with environment, distance, and their interaction as factors. Welch two-sample t-tests were then used to compare open-field and forest non-line-of-sight RSSI at 25 m and 50 m. Receive-interval comparisons at the same ranges were also tested to assess whether the environment materially affected receiver logging cadence.

5 Results

5.1 Zigbee performance

In the indoor line-of-sight corridor hop tests (10, 30, 50, and 80 m), Zigbee achieved packet delivery ratios of at least 96% up to 50 m and 91.7% at 80 m. The application-layer round-trip time remained below 100 milliseconds at short hop distances. The measured hop-level reliability and delay are consistent with Zigbee performance reported for low-power Internet of Things deployments in cluttered settings (Haque et al., 2022).

These measurements provide baseline indoor hop-level characterization only and should not be interpreted as direct estimates of outdoor forest performance.

5.2 LoRa performance

In the outdoor open-field line-of-sight backhaul tests (100, 300, 500, and 800 m) using the fixed configuration (433 MHz, spreading factor 7, 125 kHz bandwidth, 17 dB-milliwatts), LoRa sustained packet delivery ratios of at least 90% at 800 m. One-way link latency remained at or below 384 milliseconds under the same configuration. These range and latency values fall within the behaviour reported in LoRa field-measurement studies using comparable low-spreading-factor configurations (Masek et al., 2021; Jouhari et al., 2023). This 800 m result should be read as a baseline open-field, line-of-sight measurement for the selected radio settings.

Additional repeated receiver-side trials were performed in open-field and forested non-line-of-sight settings at 25 m and 50 m. Across the repeated outdoor runs summarized in Table 1, mean PDR remained between 99.77% and 100.00%. The received signal strength indicator (RSSI) distributions, however, showed a clear vegetation penalty. Mean RSSI was approximately −42.5 dB m in the open field and −54.1 dB m in the forest at 25 m, and approximately −50.6 dB m in the open field and −61.1 dB m in the forest at 50 m. The field measurements, summarized in Table 1 and visualized in Figure 2, indicate that foliage and obstructions reduce link margin, even when short-range packet delivery remains high under the tested configuration. Application-level throughput, calculated as packets sent divided by run duration, was approximately 0.48 packets/s for the outdoor trials (290–291 packets over 600 s) and 0.49 packets/s for the indoor baseline (59 packets over 120 s), consistent with the intended low-frequency environmental monitoring cadence rather than high-bandwidth transfer.

Statistical testing supported the same interpretation. A one-way ANOVA on run-mean RSSI across the five conditions showed a significant condition effect, with p < 0.001. For the outdoor subset, a two-way ANOVA showed significant effects of environment and distance, with p < 0.001 for both factors and for their interaction. Welch two-sample t-tests confirmed that forest non-line-of-sight RSSI was significantly lower than open-field RSSI at both 25 m and 50 m (p < 0.001 in both cases), whereas receive-interval comparisons at the same ranges were not significant (p = 0.598 at 25 m; p = 0.956 at 50 m). These results indicate that the main environmental effect was on link strength rather than receiver logging cadence.

5.3 End-to-end performance

With five concurrent sensing nodes active, the mean sensor-to-cloud latency was approximately 1.8 s, with a maximum observed delay of 2.4 s. End-to-end packet delivery ratio over the same run was 94.7%. Figure 2 summarizes packet delivery across the Zigbee hop tests, the LoRa backhaul tests, the added short-range field comparisons, and the end-to-end run. These results demonstrate integration-scale operation for the present prototype; they do not by themselves establish performance under substantially larger node counts or heavier reporting loads. The measured delay therefore reflects not only link transmission but also coordinator buffering and batching, gateway handling, and cloud upload.

5.4 Classification performance

On the held-out UCI benchmark subset, the selected Random Forest achieved ROC-AUC 0.692, average precision 0.702, accuracy 0.673, and weighted F1-score 0.672. Supplementary Table S1 compares this result with Decision Tree, SVM, XGBoost, and Logistic Regression baselines evaluated on the same split and feature set. At the recall-oriented operating point selected for early warning, the Random Forest classifier achieved a recall = 0.907, precision = 0.605, F1 score = 0.726, accuracy = 0.644, and specificity = 0.360.

Figure 3 shows the confusion matrix for this operating point. Out of 54 true Fire samples, the classifier correctly labelled 49 as Fire and missed 5 (false negatives). Out of 50 true No-fire samples, 18 were correctly labelled No-fire while 32 were labelled Fire (false positives). The selected operating point therefore reduces missed Fire cases at the cost of increased false alarms and should be interpreted as a conservative screening threshold rather than as a stand-alone dispatch decision rule.

6 Discussion

6.1 Architecture implications

The measured results support the role separation of the hybrid architecture. Zigbee provides the near-ground tier with hop-level delivery above 90% across the tested hop distances, which supports dense sensing and local forwarding in a mesh-capable configuration. LoRa provides the backhaul tier with delivery above 90% at 800 m line-of-sight under the fixed configuration, enabling long-range transport without requiring multiple internet-connected gateways. The end-to-end measurements show that the integrated pipeline maintains high delivery while keeping dashboard-visible update delays within a few seconds under multi-node operation. The contribution of the present study is therefore system-level rather than algorithmic: it shows how role-separated local collection, coordinator-side batching, long-range backhaul, and browser-side inference can be combined and evaluated within a single prototype workflow. These measurements provide baseline indoor hop-level characterization only and should not be interpreted as direct estimates of outdoor forest performance.

6.2 Timeliness

The end-to-end sensor-to-cloud delay provides an operator-facing measure of system timeliness because it includes collection, buffering, and batching at the coordinator, backhaul transport, gateway processing, and cloud upload. In this system, the measured end-to-end delay indicates that newly sampled near-ground conditions are reflected on the dashboard within seconds during concurrent node activity, which is appropriate for continuous monitoring and time-sensitive warning interfaces.

6.3 Backhaul airtime and scaling

Batching up to four sensor records into each LoRa payload reduces the number of backhaul transmissions required when multiple sensing nodes are active. This is a direct mechanism for limiting long-range channel occupancy while preserving dense sampling in the near-ground tier. The five-node end-to-end run demonstrates stable pipeline behaviour under concurrent reporting with the implemented batching strategy. Larger deployments will require additional evaluation across higher node counts, longer durations, and heavier reporting loads to characterize scaling limits under sustained operation.

6.4 Alerting behaviour

The confusion matrix clarifies the operational meaning of the selected threshold: missed Fire cases are limited (five false negatives), while false alarms are more frequent (32 false positives). Precision and specificity are correspondingly modest at this operating point, which is consistent with the deliberate choice to favor recall for early warning. In operational use, this output should therefore be interpreted as a risk-screening signal rather than as an automatic fire declaration. Because the classifier was trained on a public dataset rather than on fire-labelled measurements from the intended deployment site, threshold calibration on a site-specific no-fire baseline will be important before field deployment. In practice, nuisance alerts can be reduced at the dashboard level without changing the communication pipeline by applying persistence rules, for example, requiring repeated high-risk outputs from the same node, and confirmation rules, for example, requiring agreement among nearby nodes before escalation.

6.5 Deployment conditions

The LoRa backhaul measurements at 800 m were obtained under line-of-sight in an open field and should be interpreted as baseline performance for the selected configuration. The added short-range field trials show that forested non-line-of-sight conditions preserve high PDR at 25 m and 50 m under the tested settings but reduce mean RSSI by roughly 10–12 dB relative to open field at the same nominal range. This result indicates reduced link margin under vegetation even when packet delivery remains high. The Zigbee hop behaviour was measured under indoor line-of-sight corridor conditions; mesh deployments in cluttered outdoor environments would be expected to benefit from shorter hop spacing and greater path diversity to maintain delivery as conditions change (Haque et al., 2022). The present measurements do not yet capture mountainous terrain, seasonal canopy variation, or adverse weather, and the environmental claims of this study should therefore remain bounded by the conditions actually tested.

6.6 Limitations and future work

This study evaluates hop-level Zigbee behaviour, line-of-sight LoRa backhaul behaviour, added short-range LoRa field comparisons, and end-to-end performance under five concurrently active nodes. The classification model was trained on the public Forest Fires dataset rather than on fire-labelled records collected at the deployment site. Accordingly, the present results should be understood as demonstrating the feasibility of client-side risk scoring within the prototype pipeline, not as a site-calibrated fire detector. The energy budget is likewise a first-order duty-cycle estimate rather than a long-term seasonal autonomy study. Future work should therefore extend testing in four directions: (i) obstructed outdoor Zigbee and longer-range forest LoRa trials, (ii) higher node counts and longer-duration stress testing, (iii) site-specific calibration using labeled local fire/no-fire intervals, and (iv) long-term energy characterization under variable reporting intervals and seasonal solar conditions.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Supplementary material

The Supplementary Material for this article can be found online at: https://www.frontiersin.org/articles/10.3389/frcmn.2026.1783392/full#supplementary-material

Supplementary material Supplementary material at the source

Supplementary material Supplementary material at the source

Supplementary material Supplementary material at the source

Footnotes

Edited by: Ying Huang, North Dakota State University, United States

Reviewed by: V. Venkataramanan, K J Somaiya College Of Engineering, India

Jozef Papán, University of Žilina, Slovakia