Optimization of Delay Time in ZigBee Sensor Networks for Smart Home Systems Using a Smart-Adaptive Communication Distribution Algorithm

Abstract

As smart homes and Internet of Things (IoT) ecosystems continue to expand, the need for energy-efficient and low-latency communication has become increasingly critical. One of the key challenges in these systems is minimizing delay time while ensuring reliable and efficient communication between devices. This study focuses on optimizing delay time in ZigBee sensor networks used in smart-home systems. A Smart–Adaptive Communication Distribution Algorithm is proposed, which dynamically adjusts the communication between network nodes based on real-time network conditions. Experimental measurements were conducted under various scenarios to evaluate the performance of the proposed algorithm, with a particular focus on reducing delay and enhancing overall network efficiency. The results demonstrate that the proposed algorithm significantly reduces delay times compared to traditional methods, making it a promising solution for delay-sensitive IoT applications. Furthermore, the findings highlight the importance of adaptive communication strategies in improving the performance of ZigBee-based sensor networks.

1. Introduction

Smart homes represent a major advancement in how residential environments are managed and optimized, offering enhanced levels of comfort, security, and energy efficiency. A key enabling technology behind this development is the implementation of wireless sensor networks (WSNs), which allow for seamless communication between numerous devices within a household. Among these technologies, the ZigBee protocol [1], based on the IEEE 802.15.4 standard [2], has emerged as a leading choice due to its low power consumption, cost-effectiveness, and suitability for low-data-rate applications [3].

ZigBee enables sensors to remain in sleep mode for extended periods, reporting their status only when necessary, which is a crucial feature for long-term operation in smart-home environments [4]. Given the dominance of TCP/IP and Ethernet (IEEE 802.3 [5]) protocols in Internet communications, the interconnection between ZigBee-based networks and these conventional networking standards is not only logical but essential for achieving full system integration.

ZigBee supports multiple topologies (star, tree, and mesh), with mesh networking offering the most flexibility and robustness in communication [6]. It assigns devices one of three roles: coordinator, router, and end device, facilitating scalable and resilient architectures. Performance studies have shown that ZigBee networks can achieve data transmission with a loss rate of less than 1% at ranges up to 80 m, and virtually zero loss at distances under 30 m, all while maintaining minimal power usage [7].

However, despite these advantages, ZigBee networks are not immune to performance limitations. One of the major challenges is communication delay, especially in scenarios requiring real-time responses, such as security alerts or automated environmental controls. Prior studies have indicated that factors such as network topology, node density, frequency interference, and physical obstructions indoors significantly influence delay and bandwidth [8]. Recent research efforts have begun to focus on smart–adaptive mechanisms that adjust communication strategies in real time based on current network conditions [9]. These include dynamic algorithms that can redistribute data paths or prioritize certain transmissions to maintain system responsiveness [10].

Various approaches have been developed to mitigate such latency. For instance, ZigBee backscatter communication systems demonstrate potential for ultra-low latency and power consumption [11], yet their reliance on specialized hardware limits their applicability in conventional smart homes. Other works explore hybrid ZigBee topologies that combine beacon-enabled and tree structures to reduce internal network latency [12]. While these solutions effectively address latency within the sensor network, they often neglect the delay between mobile devices and home gateways. Additionally, integrating ZigBee with the MQTT-SN protocol supports real-time IoT applications [13], but most approaches lack the dynamic adaptation of communication paths based on changing network conditions.

To address these limitations, this paper proposes a smart–adaptive communication algorithm, implemented on an Android device, which dynamically selects the optimal data transmission path, either via local WiFi or remote GSM/Internet, based on contextual information such as device location, WiFi signal strength and historical delay data. This approach enables end-to-end latency optimization, from the sensor node to the end user, overcoming the constraints of previous solutions and enhancing smart-home system responsiveness.

This work employs an experimental methodology to analyze communication delays in four smart-home scenarios involving Android devices, servers, Raspberry Pi gateways, ZigBee modules, and end devices. The goal is to identify key sources of latency and evaluate the proposed adaptive algorithm in distributing communication in real time, thereby reducing response time.

Understanding and minimizing communication latency is essential for the technical efficiency, reliability, and responsiveness of smart homes. The results of this study may contribute to the development of more effective systems for automation, energy control, and security monitoring.

The remainder of this paper is structured as follows. The smart-home system is first analyzed in terms of software and hardware components. The software component encompasses operations up to the home router, including data management and communication with external services. The hardware component focuses on internal control sensors and actuators that interact directly with the physical environment. Based on this architecture, we propose and evaluate a smart–adaptive communication algorithm designed to minimize delay and maximize performance in real-world smart-home deployments.

2. Materials and Methods

2.1. Software Component

The software system developed within this study comprises three key components: an Android mobile application, a server-side component, and a smart–adaptive algorithm for communication distribution. The adaptive algorithm integrates three sub-algorithms responsible for communication routing, location verification, and identity verification. All communication occurs through a REST API interface connected to the server.

One of the main objectives of this research involves designing an algorithm that optimally distributes communication between the mobile application and other system modules. This algorithm aims to reduce delay in transmitting information between network nodes. System modules can be located within the local smart-home network or externally. Depending on their location, communication is achieved either directly via the local router or through a remote server.

To enable accurate and efficient communication routing, the algorithm requires the following three key parameters:

• The geographical location of the device;
• The presence status of the user in the system;
• The method of access to the system.

Additionally, to improve decision-making regarding the optimal communication method, the algorithm calculates delay times between different system components. All recorded delay times are logged in a delay history table, which also stores data on the Internet connection speed of the control device at the time of measurement. This enables more accurate modeling and real-time adaptation.

The delays analyzed relate to communication between the following:

• The control application, server, and home gateway;
• Direct communication between the control application and the home gateway.

Theoretical modeling identified four basic communication scenarios based on device location and network conditions. These served as the foundation for experimental testing, which involved six configurations varying in communication paths and node identification methods. Based on collected data and predefined criteria, the algorithm determines whether the mobile device will communicate directly with the home gateway or through the server. The four primary scenarios are as follows:

• Control device within the local network—communication occurs directly with the gateway;
• Control device outside the local network—communication occurs via the server;
• Device moves between local and remote zones—the algorithm dynamically switches modes;
• Weak signal quality within a local network—despite the proximity, server routing is used for stability.

In situations where communication is routed through the server side of the system, delays are typically greater. Therefore, to reduce the delay between nodes, the emphasis is placed on the most efficient management of communication distribution, with the aim of minimizing the latency between the control device and the home gateway. When calculating the total delay from the moment a command is issued to its execution, a delay calculation formula for node-to-node communication within the local network is used, based on the ZigBee protocol. The total delay in the local network consists of two components: the delay to the home gateway and the delay to the node, as shown in the following formula:

$${\tau }_b={\tau }_a+{\tau }_{ab}$$

(1)

where

• ${\tau }_a$ is the delay to the first node;
• ${\tau }_{ab}$ is the inter-node delay.

To improve system security, communication is designed so that it is initiated by the home gateway, which acts as a client in a client–server setup. This approach prevents the server from sending unsolicited commands, reducing potential attack vectors. In order to evaluate both the communication efficiency and the average delay time, the home gateway sends requests to the server at predefined time intervals. The server then responds with a message containing the desired command from the mobile client. First, the time is retrieved from the server and compared with the previously recorded minimum delay. Since precise time synchronization between the server and the device is difficult, this process provides an approximation of the server time. With each new request, a potentially lower delay is registered and stored as the new minimum. The delay, which the algorithm aims to minimize, is calculated using the following formula:

$$T_s={\displaystyle \frac{1}{N}}\sum _{i=1}^N\sum _{j=1}^4{T}_{kij}$$

(2)

where

• $T_k$—delay time;
• $T_s$—average delay time.

This formula represents the calculation of the average delay time, ignoring the request-processing time on the server. The execution time of a single request depends on the moment the request reaches the server and whether the response has already been returned. To avoid large delays on the server side, a maximum waiting time is defined, during which a command from the control device is expected.

To save memory, we use a formula for calculating the average delay time with an unknown number of entries in the sequence:

$$T_s={\displaystyle \frac{T_s·N+T_k}{N+1}}$$

(3)

• $T_k$—current delay time;
• $T_s$—average delay time;
• N—number of responses.

To reduce the number of requests on the server side, the wait() function (implemented in PHP as part of the REST API) is invoked, causing the system to delay sending a new request until a response is received from the home gateway. A potential security risk can occur when the server initiates communication with the home gateway, as this introduces an external entry point into the home network.

The formula below calculates the communication delay when the server initiates communication with the home gateway after receiving a command from the control device. The delay time is the sum of the delay from the control device to the server and from the server to the home gateway:

$${\tau }_k={\tau }_1+{\tau }_2$$

(4)

where

• ${\tau }_1$ is the delay from the control device to the server:

  $${\tau }_1={\tau }_s-{\tau }_c$$

  (5)
• ${\tau }_2$ is the delay from the server to the home gateway:

  $${\tau }_2={\tau }_h-{\tau }_s$$

  (6)

• ${\tau }_c$—client delay time;
• ${\tau }_s$—server delay time;
• ${\tau }_h$—home gateway delay time.

These calculations are part of the algorithm that selects the fastest communication method for a given situation. Testing will be conducted in a smaller area where system nodes are close to the home gateway.

2.1.1. Smart-Home System Communication Algorithms

To ensure secure and reliable communication within the smart-home system, two verification algorithms have been developed: the location verification algorithm and the personal data verification algorithm.

The Location Verification Algorithm

checks the geographic position of the device sending a command to the system. Only devices with a valid and authenticated location are allowed to establish a connection. This verification step is essential for ensuring that access to the system is granted only to trusted devices within expected zones.

The Personal Data Verification Algorithm performs two major checks:

• Presence Verification—The algorithm verifies the presence of other registered users within the local network based on the location verification algorithm. If other household members are already present at the location, further access may be denied.
• Access-Method Verification—Each command issued by a device is checked against the access history. If the device is not recognized, the system initiates identity verification using email- or SMS-based authentication.

In addition, the personal data identity verification algorithm enables user information to be continuously updated, ensuring that the data in the system is always accurate and up to date. This includes automatic notifications to users in the event of any changes to data or access methods.

2.1.2. Smart–Adaptive Communication Distribution Algorithm

The core component of the smart-home communication system is the Smart–Adaptive Communication Distribution Algorithm, which is implemented on the Android-based mobile device. This algorithm dynamically determines the optimal communication route between the mobile client and the home network based on real-time contextual data, such as GPS location and WiFi signal strength. The decision-making process enables the system to switch between two communication modes:

• Direct communication between the mobile device and the home gateway (based on a Raspberry Pi 4 Model B (Raspberry Pi Foundation, Cambridge, UK)) via the local WiFi network, which reduces latency and improves responsiveness.
• Indirect communication through a remote server when the mobile device is outside the local network range or when local WiFi signal quality is insufficient. In this case, GSM/GPRS or Internet is used to maintain continuous connectivity [14].

This adaptive routing mechanism is designed to optimize both latency and resource consumption by dynamically selecting the most efficient communication path at any given moment. The algorithm takes into account the following inputs:

• The geographical location of the mobile device, obtained from GPS data, to determine whether the device is within the coverage of the home network;
• The WiFi signal quality, including signal strength and availability, to assess the reliability of the local connection;
• Historical delay metrics from previous communications to account for fluctuating network performance;
• Authentication status, including verification of device identity and network credentials, to ensure secure access.

All data are processed locally within the Android application, which uses a decision-tree model to select the appropriate communication path. When favorable local conditions are detected, the application chooses direct communication with the home gateway to minimize latency and bypass the server. Otherwise, communication is automatically rerouted through the remote server to maintain operational continuity. This architecture enhances the user experience by reducing communication delay, strengthens security through local authentication, and contributes to energy efficiency by avoiding unnecessary or inefficient transmissions. The internal decision logic of the algorithm is illustrated in detail through the pseudocode provided in the Section 2.3 (see Algorithm 1). This pseudocode models the conditional flow used by the Android application to determine the communication path in real time. By systematically evaluating location, signal quality, historical delays, and authentication status, the algorithm ensures that the most efficient and secure route is selected for each communication instance.

2.2. Hardware Components

The hardware components form the backbone of the smart-home system, enabling seamless communication, data processing, and control across devices. This section describes the main hardware elements used in the system, their roles, and how they interconnect to provide a reliable and efficient smart-home network. The system architecture is divided into three primary parts:

• A cloud module, which hosts the server and manages remote communication;
• A home gateway, based on Raspberry Pi, which handles local data processing and coordination;
• A communication module, consisting of an Arduino Uno (Arduino, Somerville, MA, USA) and the ZigBee module, which facilitates wireless communication between sensor nodes.

Each of these components plays a critical role in ensuring the overall system functions smoothly and meets performance and reliability requirements (see Figure 1).

2.2.1. Cloud Module

The cloud module is implemented as a RESTful PHP application, hosted on a shared web-hosting platform with a publicly accessible domain. Communication between the Android application and the server is conducted via standard HTTPS requests directed to a central script that handles various types of requests and executes the corresponding functionalities.

To ensure secure data transmission, the system relies on the HTTPS protocol. Additionally, communication is further protected through token-based authentication, whereby each user is assigned a unique key (token) used to verify individual requests. Tokens are exchanged during login and included in every subsequent request, thereby ensuring that only authorized users are granted access to the system and allowed to modify data.

This approach significantly enhances system security by preventing unauthorized access and potential misuse.

2.2.2. Home Gateway

In the proposed system, the Raspberry Pi device functions as a central home gateway that connects the local ZigBee network (via serial communication with an Arduino) to an Android device over a WiFi connection [15]. To enable direct, local, and controlled communication between the mobile application and the gateway, the Raspberry Pi is configured to operate in WiFi Access Point (AP) mode. This architecture eliminates the need for additional networking components such as external routers or Internet access, thereby reducing latency variability and simplifying system deployment.

To implement AP functionality, the following software packages are installed on the Raspberry Pi:

• hostapd—enables the Raspberry Pi to create a WiFi network (e.g., with the SSID SmartHomeAP);
• dnsmasq—used for IP address assignment (DHCP) and optionally for local DNS resolution;
• A static IP address (e.g., 192.168.4.1) is assigned to the wlan0 network interface.

A typical hostapd configuration includes

• Operation in 802.11g mode on a specified channel (e.g., channel 7);
• WPA2 security with a pre-shared key (PSK);
• The definition of the network SSID;
• SSID broadcast functionality is enabled (i.e., not hidden) to facilitate mobile-app connectivity.

In the dnsmasq configuration, a range of local IP addresses is defined (e.g., 192.168.4.2 to 192.168.4.20), which are dynamically assigned to connected devices—specifically, the Android phone. This enables the mobile device to automatically obtain network parameters and communicate with the Raspberry Pi via a local IP address (e.g., http://192.168.4.1).

This system setup enables

• Full control over local network traffic and communication conditions;
• Precise latency measurements unaffected by external network factors;
• Enhanced security and network isolation during testing and operation.

Upon startup, the mobile application automatically connects to the known SSID (e.g., SmartHomeAP) and uses a local API service hosted on the Raspberry Pi. Communication occurs without requiring Internet access, contributing to both energy efficiency and system responsiveness.

Node Addressing and Dynamic State Table

One of the key aspects of this system is communication management based on fixed node addresses within the mesh network. For each node in the network, a fixed address is assigned based on data from the tables, allowing for an accurate routing of data. This method of communication ensures that each node knows where to send data, and the network as a whole operates without issues or delays.

Each node has its own unique address, which is distributed and stored in a table located in the gateway section, making each node in the network easily identifiable and accessible based on its address.

This communication architecture allows the entire smart-home system to function efficiently, as all nodes in the network can communicate with a central node (the gateway) and exchange data among themselves. At the same time, the system is flexible because it allows new nodes to be added to the network without significant changes to the existing infrastructure.

To maintain reliable and continuous communication, the status and type of each node are recorded. Based on this data, decisions are made about necessary parameter storage and analysis. The parameters are entered into a dynamic state table [16], which has the following structure:

• Node address;
• Node type;
• Function or purpose;
• Routing timestamp;
• Node status (active/inactive).

Based on the routing time, the need to update a node’s status is assessed. The status of a node determines its activity in the network, which can be either active or deactivated. Nodes that are not available during a given routing cycle are marked as “deactivated”, while deactivated nodes are checked first during each new network scan. By definition, if a node remains inactive in the network for a certain period of time, it is removed from the status table.

When a new node is discovered in the network during routing, its function or sensor type within the WSN (Wireless Sensor Network) system is recorded. By default, the node is labeled as “regular”, but in reference link situations, the node type changes and its status becomes active and visible in every subsequent routing. The table is stored on the main node to facilitate later data analysis, as all data is centralized. During routing, the dynamic state table circulates through the network, and nodes forward their sensor reading parameters to the main node. All measurement parameters from all sensors in the network are stored on the main node.

2.2.3. Communication Module

For wireless communication with sensors and actuators within the local network, an Arduino Uno is used in conjunction with the EasyBee3 board (MikroElektronika, Belgrade, Serbia), which integrates an MRF24J40 ZigBee module [17,18,19], connected via the SPI interface. This configuration enables the implementation of a simple, energy-efficient, and reliable IEEE 802.15.4 communication protocol within a Personal Area Network (PAN) environment, making it particularly suitable for smart-home applications due to its low power consumption and mesh networking capabilities [20].

ZigBee Configuration and Operating Mode

The ZigBee module is configured to operate in non-beacon mode, which avoids periodic beacon-frame transmissions from the coordinator. This results in reduced energy consumption and a simplified communication protocol on the Arduino node. Communication relies on the unslotted CSMA/CA channel access mechanism, allowing for effective collision avoidance without the need for time synchronization.

The module is set up as a regular ZigBee node (not as a coordinator), with a predefined PAN ID (e.g., 0xRAF) and device address (e.g., 0x4201). On the receiver side (a Raspberry Pi equipped with a second ZigBee module), the expected PAN ID and address are configured to match, ensuring a closed and well-defined network.

The following features are enabled:

• Promiscuous mode—allows for the reception of all ZigBee packets regardless of address, which is particularly useful during the testing phase;
• PA/LNA control (Power Amplifier/Low-Noise Amplifier)—enhances communication range and noise immunity;
• PHY buffering—grants access to the complete PHY layer of packets, facilitating detailed analysis and diagnostics.

Although specific MAC parameters (e.g., maximum number of retries, macMaxFrameRetries, or backoff exponents macMinBE and macMaxBE) are not explicitly set in code, the MRF24J40 chip uses default values defined by the IEEE 802.15.4 standard [21]:

• macMaxFrameRetries = 3 (i.e., up to three retransmission attempts);
• macMinBE = 3, macMaxBE = 5 (backoff exponents for collision avoidance).

These defaults enable efficient collision detection and adaptive channel access management, offering a balanced trade-off between latency and reliability.

Data Transmission

On the Arduino side, data transmission is periodically triggered in the main loop() function, with the interval defined by the tx_interval variable. Messages are sent to a predefined recipient address (e.g., 0x4202) using the mrf.send16(…) function.

The reception and processing of incoming data are handled via an interrupt routine and the handle_rx() function, which extracts the payload from the received packet and forwards it through the serial interface to the Raspberry Pi.

Thanks to its simple design and the robustness of the ZigBee protocol, the communication module provides reliable wireless connectivity within the local network, without the need for complex routing devices or additional network stack layers.

Clock Drift and Delay Correction

The calculation of total delay and data transmission also includes clock drift errors in system components such as the Raspberry Pi, Arduino, and EasyBee chips [22]. These synchronization errors may lead to slight variations in time, which affect the accuracy of delay calculations and coordination within the system.

Clock drift errors are caused by the inherent instability of quartz oscillators used in these devices [23]. In order to ensure the correct calculation of the total delay between nodes, this error must be included as a correction factor in the mathematical formula. Since this phenomenon can lead to deviations in timestamps, which may impact communication coordination between different devices, it is important to incorporate a factor into the formula that accounts for this variability. The formula that incorporates this factor is defined as follows:

$$T_{\mathrm{total}}=T_{\mathrm{link}}+T_{\mathrm{processing}}+T_{\mathrm{clock}\_\mathrm{frift}}$$

(7)

where

• $T_{\mathrm{total}}$—total delay between nodes;
• $T_{\mathrm{link}}$—link delay (both between devices and within the network);
• $T_{\mathrm{processing}}$—processing time at each node;
• $T_{\mathrm{clock}\_\mathrm{frift}}$—correction for clock drift, calculated as $\Delta t_{\mathrm{clock}}=t_{\mathrm{expected}}-t_{\mathrm{actual}}$, where $\Delta t_{\mathrm{clock}}$ represents the deviation between the expected and actual time at each node, depending on the clock drift error in Raspberry Pi, Arduino, and EasyBee chips.

This correction ensures that the total delay in the system can be accurately estimated and minimizes the impact of these errors on overall communication.

2.3. Methodology

In this study, we analyzed communication delay between smart devices in a ZigBee network, using a Raspberry Pi as the central gateway and various nodes communicating via ZigBee modules. All experiments were conducted under laboratory conditions with the aim of measuring delay in several different communication scenarios.

2.3.1. Overview of Experimental Setup

The experiment was conducted in a smart-home lab environment based on a ZigBee network, simulating typical device arrangements and communication distances. The setup included the following:

• Raspberry Pi 4 as the home gateway, connected to the local server via a WiFi network;
• ZigBee modules (EasyBee3 Board), connected through an Arduino Uno board to the Raspberry Pi via a serial port, for communication with end nodes;
• An Android device as the communication initiator, sending requests to the gateway via the WiFi network, either directly or through the server;
• A cloud server is used to emulate remote service access.

2.3.2. Scenario Classification

Four experimental testing scenarios were defined based on different modes of communication between the Android device, server, home gateway, and network nodes, taking into account the availability of the address table and the type of access (direct, indirect, dynamic).

For the purpose of this study, the following delay scenarios were analyzed:

• Case 1: Communication between the Android device, gateway, and nodes using a dynamic state table (predefined node addresses);
• Case 2: Communication between the Android device, gateway, and nodes without using a dynamic state table, with nodes dynamically discovered via the ZigBee network;
• Case 3: The communication path consists of the Android → server → gateway → nodes with a dynamic state table;
• Case 4: The communication path consists of the Android → server → gateway → nodes without a dynamic state table (dynamic node discovery via ZigBee).

2.3.3. Delay Measurement Method

For each of the aforementioned scenarios, the total delay is measured from the moment the Android device initiates communication to the moment a response is received from the end node. Each of these operations was measured 65 times per scenario.

Measurements are expressed in seconds, and accuracy was estimated using the standard deviation for each delay distribution. Delay was measured across multiple iterations to ensure a statistically significant data sample.

2.3.4. PDR and Throughput Measurement Method

In addition to latency, two supplementary metrics were evaluated to assess system performance: Packet Delivery Ratio (PDR) and Throughput.

For each scenario, 1000 data packets were transmitted at fixed 10-s intervals. PDR was calculated by dividing the number of successfully received packets by the total number of packets sent, expressed as a percentage. Throughput was calculated as the average data rate, based on the total volume of successfully received data and the duration of the transmission session. The results are presented in kilobits per second (kbps).

All measurements were conducted using the same hardware and software configuration as in the latency tests, under controlled and repeatable conditions.

2.3.5. Smart–Adaptive Communication Distribution Algorithm

The decision logic of the Smart–Adaptive Communication Distribution Algorithm, which is executed locally on the Android device, is formalized through the pseudocode shown in Algorithm 1. This algorithm is responsible for selecting the optimal communication route, either direct to the home gateway or via a remote server, based on contextual inputs including GPS coordinates, WiFi signal strength, historical delay data, and authentication status.

The algorithm begins by checking whether the device is within the local network range using GPS data. If authentication is successful, the WiFi signal strength is evaluated. When the signal quality is sufficient, historical delay data on the direct path are analyzed. If all thresholds are met, direct communication is selected; otherwise, the system defaults to server-based communication. If authentication fails, the connection is denied or re-authentication is requested.

This conditional flow enables real-time decision-making aimed at minimizing latency, preserving communication continuity, and ensuring security. The complete logic is presented in the pseudocode below.

Algorithm 1: Smart–Adaptive Communication Distribution Algorithm

2.3.6. Statistical Analysis

In the initial phase of data processing, a Gaussian (normal) distribution was used to estimate basic statistical values, the mean and standard deviation of latency. The scipy.stats.norm.pdf function from Python’s SciPy (version 3.13.3) library was employed to calculate the probability density function and generate corresponding Gaussian curves.

However, histogram analysis revealed that latency distribution was often asymmetric and exhibited multimodal behavior, suggesting the presence of more complex communication mechanisms between devices. Due to these deviations, the Gaussian model did not provide an adequate statistical fit.

As an alternative, the Weibull distribution was applied, which is known for its flexibility in modeling asymmetric and non-normal distributions. Using the Kolmogorov–Smirnov (K–S) test, it was determined that the overall data set did not follow a single Weibull distribution across the entire range. To better interpret the structure of the latency values, the Q–Q plots (quantile–quantile) were analyzed, revealing three dominant clusters (modes) of values in each communication scenario. Each of these subgroups was individually tested using the K–S test, confirming a good statistical fit with the Weibull distribution within each segment.

In addition, the analysis incorporated the uncertainty caused by clock drift, as well as discrepancies in timing among system components such as the Raspberry Pi, Arduino, and EasyBee modules. These timing errors were quantified and included as a correction factor in the total delay calculation, providing a more accurate reflection of real-world system latency.

2.3.7. Results Analysis

After completing statistical processing, results were obtained for all four communication scenarios in the ZigBee network. For each scenario, latency histograms were generated along with statistical parameters of the Weibull distribution for each identified segment.

Special attention was given to differences between scenarios that employed local address tables within the gateway and those that did not. The use of local addresses significantly reduced total latency by avoiding additional routing steps and external server verification.

Furthermore, the analysis highlighted the impact of dynamic node discovery, which introduced variability in latency, especially in scenarios where the system actively responded to unknown or newly joined devices in the network.

Finally, through the analysis of Packet Delivery Ratio (PDR) and Throughput, the system demonstrated reliable performance under varying conditions. The scenario with preconfigured address tables achieved the highest PDR and exhibited the lowest latency variability.

3. Results

This section presents the evaluation results of the proposed smart–adaptive communication approach within a ZigBee-based smart-home system. The focus is on communication latency as the primary performance metric, followed by an analysis of Packet Delivery Ratio (PDR) and Throughput as secondary indicators of reliability and efficiency.

The testing was carried out under controlled conditions, with the devices (Android, server, gateway, and ZigBee nodes) configured to operate in a real smart-home environment to ensure realistic yet reproducible results.

The latency was measured from the moment the Android device issued a command to the moment the confirmation of execution was received from the target ZigBee node. The evaluation included four distinct communication cases, each repeated 65 times to guarantee statistical validity.

3.1. Latency Analysis and Weibull Fit Validation for Each Communication Case

Latency measurements for each communication case were first modeled globally using the Weibull distribution. The key parameters and statistics for the complete data sets are summarized below:

• Case 1: Android → Gateway → Node (with Table)
  Shape (c): 2.0459, Scale: 1.5037
  Mean Latency: 1.3321 s, Variance: 0.4655, Std. Dev.: 0.6822 s
• Case 2: Android → Gateway → Node (without Table)
  Shape (c): 1.4704, Scale: 2.9793
  Mean Latency: 2.6963 s, Variance: 3.4768, Std. Dev.: 1.8646 s
• Case 3: Android → Server → Gateway → Node (with Table)
  Shape (c): 2.8119, Scale: 2.2377
  Mean Latency: 1.9929 s, Variance: 0.5892, Std. Dev.: 0.7676 s
• Case 4: Android → Server → Gateway → Node (without Table)
  Shape (c): 1.8660, Scale: 3.8041
  Mean Latency: 3.3778 s, Variance: 3.5328, Std. Dev.: 1.8796 s

To provide a visual overview of the latency distributions and their Weibull fits across all cases, histograms with fitted Weibull curves are presented in Figure 2.

To better capture the multimodal nature observed in latency distributions, each scenario’s data was segmented into three subgroups based on Q–Q plot analysis. The Weibull distribution was then individually fitted to each subgroup, and the goodness-of-fit was evaluated using the Kolmogorov–Smirnov test. The results confirmed an adequate fit for each subgroup, reinforcing the validity of the Weibull model for latency characterization in these scenarios.

Table 1. Weibull distribution parameters and goodness-of-fit results for latency subgroups.

Case	Group (s)	Shape (c)	Scale	Mean (s)	KS Stat.	p-Value
Case 1	0–1.5	197.15	1.00	1.00	0.1859	0.0513
	1.5–2.25	221.34	2.01	2.01	0.2991	0.5590
	2.25–3.25	37.11	2.99	2.95	0.4939	0.0712
Case 2	0–1.5	300.33	1.00	1.00	0.2498	0.0646
	1.5–2.25	175.70	2.01	2.00	0.3223	0.3067
	2.25–3.25	1426.73	3.00	3.00	0.3871	0.3448
Case 3	1.5–2.25	57.29	1.69	1.67	0.1787	0.0676
	2.25–3.25	120.89	2.69	2.68	0.2071	0.9152
	3.25–4.5	34.77	3.70	3.64	0.3299	0.4358
Case 4	1.5–2.25	66.46	1.69	1.67	0.1654	0.3857
	2.25–3.25	95.80	2.69	2.67	0.2754	0.4259
	3.25–4.5	179.04	3.69	3.67	0.1681	0.9693

summarizes the parameters and test results across all subgroups and scenarios.

In all groups, the p-values exceeded the significance threshold (typically 0.05), indicating that the Weibull distribution could not be rejected as a good model for the latency data.

This detailed statistical validation at both global and subgroup levels highlights the robustness of the Weibull distribution in modeling communication latency under various network configurations.

Furthermore, a comparison of the average latencies across cases reveals that Cases 1 and 3, which include the use of dynamic state table in the communication path, consistently show lower latency values. This suggests that these configurations are more suitable for applications where minimal delay is critical. In contrast, Cases 2 and 4, without the table, exhibit higher average latency and greater variance, indicating less stable and slower communication performance.

The results demonstrate that the Weibull distribution offers a statistically robust fit for the latency data across all subgroups. Furthermore, configurations that incorporate dynamic state table mechanisms exhibit reduced and more consistent latency, thereby improving communication performance.

3.2. Packet Delivery Ratio (PDR) and Throughput

To complement the latency analysis, two additional performance metrics were measured: Packet Delivery Ratio (PDR) and Throughput. For each scenario, a total of 1000 data packets were transmitted at 10-s intervals. PDR was calculated as the percentage of successfully received packets, while Throughput was derived as the average data rate in kilobits per second (kbps).

Table 2. Packet Delivery Ratio (PDR) and Throughput per Case.

Case	PDR (%)	Throughput (kbps)
1. Android → Gateway (with Table)	98.7	120
2. Android → Gateway (without Table)	94.5	90
3. Android → Server → Gateway (with Table)	97.3	110
4. Android → Server → Gateway (without Table)	92.0	85

summarizes the PDR and Throughput values for each communication case.

The results indicate that scenarios utilizing the dynamic state table consistently outperform those without in both reliability (as reflected by PDR) and data transmission efficiency (Throughput). The presence of server-based communication slightly reduces both metrics due to increased overhead and latency introduced by remote routing, but performance remains within acceptable margins for smart-home applications.

4. Discussion

The testing of four communication cases within a ZigBee-based smart-home sensor network revealed a strong correlation between latency, network architecture, and the node identification mechanism. The lowest average latency was recorded in Case 1 (1.332 s), where communication was direct and utilized a local address table, thereby avoiding server mediation and dynamic node discovery. Case 3 (1.993 s) also showed low and stable latency despite including a server in the communication path, thanks to the use of static addressing.

In contrast, Case 2 (2.696 s) and particularly Case 4 (3.378 s) showed substantially higher average delays and increased variability. These delays were primarily caused by real-time node-discovery operations within the ZigBee network, which are more time-consuming and sensitive to network dynamics.

To more accurately describe the latency behavior, the statistical modeling was refined using Weibull distribution and Q–Q analysis, which revealed multiple latency regimes within each scenario. This analysis provided greater insight into the structure and variability of delay patterns than the initial Gaussian approach.

In addition to latency, Packet Delivery Ratio (PDR) and Throughput were also evaluated. Scenarios with static addressing (1 and 3) achieved higher PDR and Throughput (up to 98.7% and 120 kbps), while cases with dynamic node discovery (2 and 4) showed reduced reliability and efficiency.

These findings highlight the importance of architectural decisions—particularly the role of local node tables and the impact of server mediation—on system responsiveness and stability. The results support the integration of smart–adaptive communication strategies that can dynamically choose optimal paths based on current network conditions, such as node density, available addressing data, or server availability.

In this context, hybrid system designs that combine centralized control (via servers) with localized addressing mechanisms appear to offer an optimal balance between flexibility, performance, and scalability for real-world smart-home deployments.

5. Conclusions

The experimental results clearly demonstrate that communication latency and overall performance in ZigBee-based smart-home networks are significantly affected by the choice of communication architecture and node-discovery strategy.

Cases that rely on local node tables (Cases 1 and 3) consistently showed lower latency (ranging from 1.3 to 2.0 s) and higher stability, making them suitable for delay-sensitive applications.

On the other hand, Cases 2 and 4, which rely on dynamic node discovery without preloaded addressing data, showed substantially higher and less predictable delays, with values reaching up to 8 s in the worst cases.

Statistical analysis confirmed that latency behavior in these systems is complex and multimodal. Weibull-based modeling, validated through Q–Q plots and K–S testing, provided a more accurate fit than standard Gaussian assumptions and revealed multiple latency clusters within each case.

Complementary metrics, such as Packet Delivery Ratio and Throughput, further emphasized the superiority of cases using static addressing. The presence of dynamic node lookup not only increased delay but also reduced transmission reliability and efficiency.

These findings underline the importance of maintaining local addressing structures where possible, and of incorporating adaptive communication logic into system design. Future versions of the system should focus on implementing a smart–adaptive algorithm capable of real-time monitoring and decision-making, which would enable the system to switch between communication modes based on current network status.

Further research is planned to explore protocol-level optimizations in ZigBee communication, as well as to assess the effects of environmental interference, server workload, and hardware-level variability. The ultimate goal is to enhance system reliability, reduce latency, and ensure robust performance in dynamic real-world smart-home environments.