Multi-level networking control method and system for LED street lamp based on Z-wave gateway

Abstract

The application discloses a kind of LED street lamp multilevel networking control method and system based on Z-Wave gateway, it is related to wireless communication technical field, it introduces this role, and the link quality of its adjacent node is periodically detected by the role of signal node, maintains a real-time local link health table.When receiving the command of gateway, signal node first tries direct communication or selects the best neighbor node to perform relay forwarding using its local health table.If a local path fails due to sudden obstacles, the signal node does not need to report to the gateway, but can immediately retry according to the alternative path in the health table, intelligently bypassing the failure point.This combination of global routing macro guidance and local node autonomous decision-making effectively avoids transient communication interruptions caused by dynamic environmental changes, significantly improving the success rate of control commands in complex environments and system robustness.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of wireless communication, and more particularly, to a multi-level networking control method and system for LED street lamps based on a Z-Wave gateway. BACKGROUND

[0002] With the advancement of smart city construction, LED street lamps, as the main carrier of urban public lighting, their intelligent management and control become crucial. The traditional street lamp control method is mostly centralized or timing switch, which is difficult to achieve precise regulation and control of single lamp, and cannot meet the needs of modern cities in energy saving, on-demand lighting and rapid response to failure. Therefore, it has become a trend to build a large-scale, low-power and high-reliability intelligent street lamp control system. As a low-power wireless mesh network protocol, Z-Wave provides a feasible solution for fine control of LED street lamps due to its low cost, easy deployment and self-organizing network characteristics. Through the Z-Wave gateway, remote monitoring, brightness adjustment, state query and fault alarm of a large number of street lamps can be realized, and the management efficiency and energy saving level of the urban lighting system are improved.

[0003] In the existing Z-Wave networking control scheme, the central gateway is usually relied on to maintain the whole network routing topology, and the control command is forwarded based on the cached static routing table. However, this static mechanism has obvious defects in the complex and changeable urban outdoor environment. The urban street environment often changes due to factors such as large vehicle parking, construction or bad weather, which causes the wireless signal propagation condition to change suddenly, and the original optimal link may be interrupted or attenuated at once. At this time, if the gateway still uses the static path to forward data, the data packet may be lost at a certain intermediate node due to the failure of the next hop in the transmission process. Although the Z-Wave protocol has retransmission and self-healing mechanisms, in the face of sudden local link failure, its network recovery process is slow, and it is difficult to switch to the standby path in time. Finally, the gateway can only know that the command execution fails, but cannot locate the specific fault link, and cannot take effective measures immediately, but has to rely on the costly whole network routing update or repeated attempts on the failed path. This routing failure problem caused by environmental dynamic changes seriously affects the reliability of single lamp control and weakens the management efficiency and core value of the intelligent street lamp system.

[0004] Therefore, a new method is needed to give the node local path decision-making ability without relying on the gateway global routing update, so that it can quickly find an alternative path when the link is interrupted, ensure the reliable delivery of commands, and improve the system robustness and response speed. SUMMARY

[0005] To solve the problem of static routing failure and command issuing failure of the existing Z-Wave network caused by sudden change of physical environment, according to an aspect of the present application, a multi-level networking control method for LED street lamps based on a Z-Wave gateway is provided, which comprises:

[0006] locally triggering a local link health degree detection periodically in each messenger node to obtain a local link health table;

[0007] finding, by the Z-Wave gateway, the nearest messenger node to the target node according to a global routing topology graph;

[0008] sending, by the Z-Wave gateway, a messenger command packet to the messenger node, the messenger command packet comprising a messenger request ID, a final target ID and an original load;

[0009] after receiving the messenger command packet, the messenger node parses the messenger command packet to obtain the final target ID and the original load;

[0010] the messenger node queries whether the final target ID exists in the local link health table, and if yes, sends a standard Z-Wave command to the target node, and if no, selects a first best neighbor node closer to the target node from the local link health table as a next relay point and sends a standard Z-Wave command to the next relay point;

[0011] in response to the messenger node not receiving an ACK signal from the next relay point, the messenger node updates the state of the first best neighbor node in the local link health table to failure, and again selects a second best neighbor node closer to the target node from the local link health table as a next relay point and sends a standard Z-Wave command to the next relay point;

[0012] after receiving the standard Z-Wave command of the first best neighbor node or the second best neighbor node, the target node returns an execution confirmation packet to the messenger node along the path of the command transmission.

[0013] According to another aspect of the present application, a multi-level networking control system for LED street lamps based on a Z-Wave gateway is provided, which comprises:

[0014] a local link health table generation module for locally triggering a local link health degree detection periodically in each messenger node to obtain a local link health table;

[0015] a nearest messenger node finding module for finding, by the Z-Wave gateway, the nearest messenger node to the target node according to a global routing topology graph;

[0016] a messenger command packet sending module, configured to send a messenger command packet to the messenger node through the Z-Wave gateway, the messenger command packet comprising a messenger request ID, a final target ID and an original load;

[0017] a parsing module, configured to, after receiving the messenger command packet, parse the messenger command packet by the messenger node to obtain the final target ID and the original load;

[0018] a standard Z-Wave command sending module, configured to, by the messenger node, query whether the final target ID exists in a local link health table of the messenger node, and if yes, send a standard Z-Wave command to the target node, and if no, select a first best neighbor node closest to the target node from the local link health table as a next relay point, and send a standard Z-Wave command to the next relay point;

[0019] a node selection module, configured to, in response to the messenger node not receiving an ACK signal from the next relay point, update a state of the first best neighbor node in the local link health table to failure by the messenger node, and select a second best neighbor node closest to the target node from the local link health table as a next relay point again, and send a standard Z-Wave command to the next relay point;

[0020] a confirmation module, configured to, in response to the target node receiving the standard Z-Wave command of the first best neighbor node or the second best neighbor node, return an execution confirmation packet to the messenger node along a path of the command.

[0021] Compared with the prior art, the LED street lamp multi-level networking control method and system based on a Z-Wave gateway provided by the application introduce a messenger node as a role, which is a proxy of the gateway in a target area. The gateway no longer directly specifies a complete static path, but only sends a command to a messenger node closest to a target. The messenger node then maintains a real-time local link health table by periodically detecting a link quality of a neighboring node. After receiving a command of the gateway, the messenger node first attempts to directly communicate or selects a best neighbor node to relay and forward. If a local path fails due to a sudden obstacle, the messenger node does not need to report to the gateway, but can immediately perform a retry according to an alternative path in the health table, and intelligently bypasses a failure point. This combination of macroscopic guidance of global routing and autonomous decision of a local node endows the network with a fast self-healing capability at a link end, effectively avoids instantaneous communication interruption caused by dynamic changes of an environment, and significantly improves a delivery success rate of a control command in a complex environment and system robustness. BRIEF DESCRIPTION OF DRAWINGS

[0022] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0023] Figure 1 This is a flowchart of a multi-level network control method for LED streetlights based on a Z-Wave gateway, according to an embodiment of this application.

[0024] Figure 2 This is a flowchart of step S5 in the multi-level networking control method for LED streetlights based on a Z-Wave gateway according to an embodiment of this application.

[0025] Figure 3 This is a flowchart of step S6 in the multi-level networking control method for LED streetlights based on a Z-Wave gateway according to an embodiment of this application.

[0026] Figure 4 This is a block diagram of a multi-level networking control system for LED streetlights based on a Z-Wave gateway, according to an embodiment of this application. Detailed Implementation

[0027] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0028] In response to the problems mentioned in the background description, this application proposes a multi-level networking control method for LED streetlights based on a Z-Wave gateway. Figure 1 This is a flowchart illustrating a multi-level network control method for LED streetlights based on a Z-Wave gateway, according to an embodiment of this application. Figure 1As shown, the multi-level network control method for LED streetlights based on a Z-Wave gateway according to an embodiment of this application includes: S1, periodically triggering local link health detection within each messenger node to obtain a local link health table; S2, the Z-Wave gateway searching for the messenger node closest to the target node according to the global routing topology map; S3, the Z-Wave gateway sending a messenger command packet to the messenger node, the messenger command packet including a messenger request ID, a final target ID, and an original payload; S4, after receiving the messenger command packet, the messenger node parsing the messenger command packet to obtain the final target ID and the original payload; S5, the messenger node querying its local link health table to see if the final target ID exists, and if it does, sending a standard Z-Wave command to the target node. If the node does not exist, select the first best neighbor node closer to the target node from the local link health table as the next relay point, and send the standard Z-Wave command to the next relay point; S6, in response to the signaling node not receiving the ACK signal from the next relay point, the signaling node updates the status of the first best neighbor node in the local link health table to failure, and selects the second best neighbor node closer to the target node from the local link health table again as the next relay point, and sends the standard Z-Wave command to the next relay point; S7, after receiving the standard Z-Wave command from the first best neighbor node or the second best neighbor node, the target node returns an execution acknowledgment packet to the signaling node along the path from which the command was transmitted.

[0029] In S1, local link health probes are periodically triggered within each messenger node to obtain a local link health table. It should be understood that in existing technologies, Z-Wave networks primarily rely on a global static routing table maintained by a central gateway for communication. This mechanism is particularly vulnerable to instantaneous link quality changes caused by factors such as vehicles and construction in urban streets. Once a hop on a preset path is interrupted, the gateway struggles to detect the specific location of the fault in real time, resulting in low command retransmission success rates and slow system response. To overcome this deficiency, this application periodically triggers local link health probes within each messenger node to obtain a local link health table, enabling the messenger node to proactively and in real-time grasp the communication link status of its surrounding neighboring nodes. By constructing and dynamically maintaining this local health table, when performing forwarding tasks, the messenger node no longer blindly relies on potentially outdated global routing information. Instead, it can intelligently select the most reliable next-hop node based on the latest, quantified link quality data, thereby achieving rapid path adaptation and fault avoidance within a local scope and ensuring the reliability of control command transmission in complex and ever-changing environments.

[0030] In one embodiment of this application, S1, periodically triggering local link health probes within each signaling node to obtain a local link health table includes: S11, the signaling node sending a health probe data packet to a first neighbor node; S12, recording the round-trip time of the health probe data packet using a timer; S13, obtaining a signal strength indication from the API of the Z-Wave chip of the Z-Wave gateway; S14, calculating the link quality score of the first neighbor node based on the round-trip time and the signal strength indication.

[0031] In the above embodiment, the specific process of S1 is as follows: First, S11 is performed. In a specific implementation scenario, such as street light node LEDU_056 being configured as a signaling node, and its neighbor list containing node LEDU_057, which is taken as an example of the first neighbor node. When the internal timer of LEDU_056 triggers a probe cycle, it will initiate a link health probe on LEDU_057. The input of this process is the network ID of the target neighbor node, i.e., the node ID of LEDU_057. Specifically, the processor of the signaling node LEDU_056 constructs a health probe data packet in a specific format. This data packet is encapsulated under the Z-Wave protocol framework, and its essence can be a lightweight application layer command, such as a PING command or a custom ECHO_REQUEST command. The payload of this data packet is very small; it does not convey complex business logic, but only requests the other node to immediately return an acknowledgment response. The key fields of the data packet include: the source node ID (LEDU_056's ID), the destination node ID (LEDU_057's ID), and a command identifier indicating that this is a health probe request. For example, the data packet can be defined as an 8-byte frame, specifying the source and destination addresses and the probe command type. After the data packet is constructed, the Z-Wave transceiver module of the signaling node LEDU_056 will transmit this data packet via radio frequency signal according to the standard Z-Wave physical layer and MAC layer protocol.

[0032] Next, proceed to S12. The moment the processor of the signaling node LEDU_056 delivers the constructed probe packet targeting its neighboring node LEDU_057 to its Z-Wave transceiver module and confirms the transmission, the processor's firmware immediately triggers the start of a high-precision timer. This timer, part of the node's internal microcontroller (MCU), provides millisecond or even microsecond-level timing accuracy to ensure measurement accuracy. After the timer starts, the signaling node LEDU_056 enters a waiting state, listening for response packets from the target neighboring node LEDU_057. When the Z-Wave transceiver module of LEDU_056 successfully receives a valid response packet from LEDU_057, such as a PONG or ECHO_REPLY command, and the protocol stack confirms that the response packet matches the previously sent probe request, the processor immediately reads the current count value of the timer and stops the timer. This time elapsed from sending the probe packet to receiving the response packet is recorded as the round-trip time (RTT) of this probe. For a concrete example, in S11, the signaling node LEDU_056 sends a health probe data packet to its neighboring node LEDU_057 at time T1 and simultaneously starts a timer. After wireless transmission, processing by LEDU_057, and the return transmission of the response signal, LEDU_056 successfully receives the response from LEDU_057 at time T2. At this point, the processor reads and stops the timer, obtaining a duration of T2-T1. If this duration is 50 milliseconds, then this 50 millisecond value is the round-trip time.

[0033] Next, proceed to S13. When the Z-Wave transceiver module of LEDU_056 receives this response data packet at the physical layer, its hardware circuitry automatically measures the strength of the RF signal and stores this measurement value in a specific register inside the chip. This value is the Received Signal Strength Indicator (RSSI) in dBm (decibels per milliwatt). Specifically, after confirming the receipt of a valid response from LEDU_057, the processor firmware of the signaling node LEDU_056 immediately calls a specific application programming interface (API) function provided by the Z-Wave chip vendor through its software driver layer. The function of this API function is to read and return the RSSI value corresponding to the previous reception event. For example, the processor might call a function called get_last_packet_rssi(). After the Z-Wave protocol stack processes the received data frame at the lower level, it associates this signal strength indicator value with the data frame for upper-layer applications to query. For a concrete example, in S12, the signaling node LEDU_056 receives a response packet from LEDU_057 at time T2. While the data content of the packet is being passed up to the application layer for parsing, the underlying protocol stack has already recorded the received RSSI value, for example, -65dBm. At this point, the application layer program can successfully obtain this -65dBm value by calling the corresponding API function. This output value is the Received Signal Strength Indicator (RSSI).

[0034] Finally, proceed to S14. In one embodiment of this application, S14, based on the round-trip time and signal strength indication, calculates the link quality score of the first neighbor node, including: S141, normalizing the round-trip time and the signal strength indication to obtain a normalized round-trip time and a normalized signal strength indication; S142, based on the normalized round-trip time and the normalized signal strength indication, calculating the link quality score of the first neighbor node using the following formula, the formula being:

[0035]

[0036] in, and These are the normalized signal strength indication and the normalized round-trip time, respectively. and Preset weighting weights for signal strength indication and round-trip time. This is the link quality score of the first neighbor node. First, S141 is performed, which normalizes these two input values. The purpose of normalization is to eliminate the influence of different physical dimensions and numerical ranges, mapping them to a unified, dimensionless interval, such as [0,1], for subsequent weighted calculations. Normalization requires a pre-defined reasonable empirical range. These ranges can be determined through extensive testing and statistical analysis in actual deployment environments to cover most normal and critical communication situations. For example, the effective range for round-trip time can be set to [RTTmin, RTTmax] = [20ms, 200ms], and the effective range for signal strength indication (RSSImin, RSSImax) can be set to [-90dBm, -50dBm]. For an input RTT value such as 50ms, the normalized value RTTnorm is calculated as (RTT - RTTmin) / (RTTmax - RTTmin). Substituting the data, we get: (50 - 20) / (200 - 20) ≈ 0.167. For an input RSSI value such as -65dBm, the normalized value RSSInorm is calculated as (RSSI - RSSImin) / (RSSImax - RSSImin). Substituting the data, we get: (-65 - (-90)) / (-50 - (-90)) = 0.625. Next, S142 is executed, and based on the normalized value, the final Link Quality Score (LQS) is calculated using a linear weighted summation model. The specific formula for this model is: In this formula, A larger value indicates a stronger signal, which contributes positively to LQS. However... A higher value indicates higher latency and worse performance, therefore it should be used... To ensure that it also makes a positive contribution to LQS, that is, the smaller the latency, The larger the value, the better. and These are preset weighted weights for signal strength and round-trip time, representing the relative importance of signal strength and round-trip time in the overall evaluation, respectively. Their sum is set to 1. Notably, the weight settings are flexible and can be adjusted according to the specific application scenario. For example, in scenarios with extremely high real-time requirements, the weights can be increased. The weighting can be increased in areas with severe signal interference; however, in areas with severe signal interference, the weighting can be increased. The weight. In a general scenario, the weight can be set. =0.6, =0.4. These weight values ​​can be obtained by machine learning methods, such as logistic regression models, using a large amount of historical communication data (including RTT, RSSI) and their corresponding labels for communication success or failure, to obtain the optimal weight parameters. The LQS value of 0.7082 obtained by substituting the above data into the formula is the link quality score of the first neighbor node LEDU_057. This value will be recorded in the local link health table of the signaling node LEDU_056, associated with the neighbor node IDLEDU_057, as the final quantitative representation of its current link health status. The signaling node LEDU_056 will repeat the above probe and calculation process for all neighbor nodes, and record and update the local link health table stored internally with information such as the ID, link quality score, probe timestamp, and link status of each neighbor node. The link status field is used to mark whether the neighbor has successfully responded in the most recent probe period. For example, it can be defined as an enumeration value: 1 represents active, 0 represents failure.

[0037] Specifically, the aforementioned link quality assessment treats signal strength indicators and round-trip time as linear relationships and combines them with fixed weights. This simplified model fails to accurately reflect the nonlinear effects in real physical environments and cannot adapt to the complex situation of link bottlenecks dynamically shifting between physical stability and network congestion. Therefore, this application introduces dynamic weights to establish an intelligent link quality assessment model that can accurately simulate nonlinear effects and dynamically adjust the assessment focus based on the real-time health logic of the link, thereby providing a more reliable and accurate basis for subsequent routing decisions.

[0038] Based on this, in a preferred embodiment of this application, S14, calculating the link quality score of the first neighbor node based on the round-trip time and signal strength indication includes:

[0039] The signal strength indicator is normalized using the Sigmoid function to obtain a normalized signal strength indicator, i.e.:

[0040]

[0041] in, It is a signal strength indicator. yes The midpoint value of the curve's dramatic / critical region, for example, empirically -78dBm. The steepness coefficient of the curve is an optimization parameter preset through experimental testing or experience. The larger the value, the steeper the curve. The more drastic the changes in the vicinity, the higher the differentiation of the key area, through adjustment. It can be precisely controlled The normalization sensitivity. For example, Set it to 0.2. This is a normalized signal strength indicator. It should be understood that the impact of the signal strength indicator on link quality exhibits a saturation effect, with its influence curve resembling an S-shape. This includes a very poor region where the signal is almost unusable (<-90dBm, signal is almost unusable, quality approaches 0), a critical or volatile region where signal quality improves dramatically with a small increase in strength (-90dBm to -70dBm, within which a small increase in RSSI greatly improves link quality and stability), and a high-quality or saturated region where the signal is already very strong but further enhancement has little marginal benefit on transmission success rate (>-65dBm, signal is already very strong; for example, increasing from -60dBm to -50dBm increases signal energy tenfold, but the marginal benefit on data transmission success rate is small). Using the Sigmoid function for normalization accurately simulates this non-linear process, allowing the normalized signal strength indicator to truly reflect its actual impact in different ranges, especially amplifying the differentiation within the critical region. For example, the midpoint value of the critical or volatile region can be determined empirically. Set to -78dBm, and finely control the sensitivity of the normalization process to changes in signal strength by adjusting the steepness factor k (e.g., set to 0.2).

[0042] The round-trip time is normalized using an exponential decay function to obtain the normalized round-trip time, i.e.:

[0043]

[0044] in, It is the round-trip time. The attenuation constant / scaling factor is a baseline value pre-set through experience that determines the rate of fraction decay; it can be understood as... At this value, the score decays to a preset ratio, for example... Specifically, it can be set as a baseline for an acceptable latency, such as 350ms. This refers to the normalized round-trip time (RTT). Correspondingly, the impact of RTT on link quality exhibits a penalized amplification effect; that is, the higher the latency, the more exponentially the negative impact on link quality is amplified, potentially indicating severe network congestion or impending timeouts. Modeling this using an exponential decay function effectively reflects this penalized amplification effect. When the RTT is in the optimal zone (e.g., <50ms, extremely low latency, uninterrupted link), the normalized value decreases gradually; in the availability zone (50ms-300ms, latency increases, quality decreases gradually); and once it enters the degraded zone (e.g., >400ms), the normalized value decays sharply to near zero, thus imposing a significant penalty on high-latency links in the final score.

[0045] Based on signal strength indicators, a preset weighted weight for signal strength indicators and a preset weighted weight for round-trip time are constructed. It should be understood that the bottleneck of link quality shifts with the link status, and fixed weights cannot adapt to this change. Considering the specific health logic of the link, namely, ensuring the stability of the physical connection of the link first, and then pursuing network performance under this premise, when the signal strength indicator is on the verge of danger, its importance far outweighs the round-trip time; while when the signal strength indicator is at a very healthy level, the round-trip time becomes the main factor distinguishing link quality. Therefore, this application implements dynamic weight setting by region.

[0046] Specifically, in response to the signal strength indicator being located below the midpoint value of a rapidly changing / critical region within a predetermined area, the preset weighting weight of the signal strength indicator is greater than the preset weighting weight of the round-trip time, i.e.:

[0047]

[0048] in, It is a signal strength indicator with preset weighting. It is a preset weighted weighting of round-trip time. This is a threshold parameter preset based on experience, used to define the width range of the equilibrium region centered on the midpoint value of the critical zone, for example, 5 dBm. That is, when the RSSI is in a predetermined area below the midpoint value of the drastic / critical zone, for example, <-82 dBm, the RSSI is considered to be in a danger zone, and physical stability needs to be prioritized. It is believed that physical stability should be prioritized, and in this case, the preset weighting of the signal strength indicator is adjusted. Set it to a large value (e.g., 0.8), and the weight of round-trip time is... .

[0049] In response to the signal strength indicator falling within the midpoint of a rapidly changing / critical region, the preset weighting of the signal strength indicator is equal to the preset weighting of the round-trip time, i.e.:

[0050]

[0051] In other words, when RSSI is within the range of the midpoint of the drastic / critical region, stability and performance are considered equally important and need to be considered in a balanced way. In this case, the preset weighting weight of both is set to 0.5.

[0052] In response to a signal strength indicator being located in a predetermined area above the midpoint value of a sudden change / critical zone, the preset weighting weight of the signal strength indicator is less than the preset weighting weight of the round-trip time, i.e.:

[0053]

[0054] In other words, when the RSSI is above the midpoint of the dramatic / critical zone, within a predetermined range (e.g., <-68dBm), the physical connection is considered highly reliable. At this point, the bottleneck is network congestion, and the focus should be on RTT (Round-Trip Time). Therefore, the preset weighting weight β of the signal strength indicator is set to a small value (e.g., 0.3), focusing on round-trip time.

[0055] Based on preset weighted weights for signal strength indication and round-trip time, a linear weighted calculation is performed on the normalized signal strength indication and normalized round-trip time to obtain the link quality score of the first neighbor node. In other words, the components, after nonlinear processing and dynamic weighting, are integrated. This produces a single value that comprehensively, intelligently, and adaptively reflects the current overall health of the link, ensuring that under any circumstances, this score points to the optimal choice, providing a precise and reliable decision-making basis for enabling the node to select the best forwarding path among multiple neighbor nodes. Specifically, the weighting here uses the same formula as the link quality score mentioned above.

[0056] In S2, the Z-Wave gateway finds the nearest messenger node to the target node based on the global routing topology. Correspondingly, the core idea of ​​this application is to combine the macro-level guidance of global routing with dynamic pathfinding of local nodes to address the problem of transient link failures. Completely abandoning the gateway's global perspective and allowing commands to be blindly transmitted through the network would result in huge network overhead and uncontrollable latency. Conversely, relying entirely on the gateway to specify a complete static path accurate to the last hop would return to the fragile state described in the background art. Therefore, this application achieves a division and decentralization of responsibility by having the Z-Wave gateway find the nearest messenger node to the target node based on the global routing topology. The gateway utilizes its global topology information to efficiently and reliably deliver commands to the most suitable messenger node near the target node. This step ensures that commands can quickly approach the target, completing most of the routing work. The local pathfinding task, most susceptible to environmental changes, is dynamically completed by this messenger node, leveraging the gateway's global scheduling advantages while providing flexibility for the network endpoints to handle emergencies, achieving a balance between efficiency and robustness.

[0057] In one embodiment of this application, the specific process of S2 is as follows: This process is executed by the Z-Wave gateway after receiving control commands from an upper-layer application (such as a central control platform). In a specific implementation scenario, for example, the central control platform needs to adjust the brightness of street light LEDU_101. Therefore, the input is the final target node ID: LEDU_101. Simultaneously, the gateway itself maintains two key data structures: a global routing topology map and a signaling node list. The global routing topology map is constructed and maintained by the gateway through network initialization, periodic probing, or the self-healing mechanism of the Z-Wave protocol. It records the connection relationships and routing hop count information between all nodes in the network. The signaling node list is pre-configured or dynamically specified, containing the IDs of all nodes in the network with signaling capabilities. For example, this list may contain nodes such as LEDU_025, LEDU_056, and LEDU_098. Specifically, the control logic of the Z-Wave gateway traverses each signaling node in its maintained signaling node list. For each messenger node in the list, such as LEDU_025, the gateway queries its global routing topology to calculate the shortest path hop count from that messenger node to the final destination node LEDU_101. This hop count represents their distance in the network topology. For example, after querying, the gateway finds that the topological distance from messenger node LEDU_025 to destination node LEDU_101 is 5 hops. The topological distance from messenger node LEDU_056 to destination node LEDU_101 is 3 hops. The topological distance from messenger node LEDU_098 to destination node LEDU_101 is 1 hop, meaning LEDU_098 is a direct neighbor of LEDU_101. The gateway performs this distance calculation process for all messenger nodes and compares them. By comparison, it can be found that the topological distance from messenger node LEDU_098 to destination node LEDU_101 is the smallest. Therefore, the gateway selects LEDU_098 as the best messenger node for this command delivery, that is, the messenger node closest to the destination node. In another implementation, the criterion for determining proximity can be physical geographic location. In this case, the gateway needs to pre-store the geographic coordinate information of all street light nodes, such as GPS coordinates. Upon receiving a command from the control target LEDU_101, the gateway calculates the straight-line physical distance between the coordinates of LEDU_101 and the coordinates of each messenger node in the messenger node list, and selects the one with the shortest physical distance as the messenger node.

[0058] In S3, the Z-Wave gateway sends a messenger command packet to the messenger node. This messenger command packet includes a messenger request ID, a final destination ID, and the original payload. It is understood that the gateway has determined the most suitable messenger node to act as the proxy for this task. However, this messenger node itself is not the final executor of the control command. It needs to clearly know its task: which command to forward to which final destination. Standard Z-Wave commands only contain source, destination, and payload, which cannot bear this complex logic of proxy forwarding. Therefore, this application uses the Z-Wave gateway to send the messenger command packet to the messenger node to construct and send a special data packet to clearly convey all elements of its proxy task to the messenger node. By encapsulating the final destination ID and the original payload in a new messenger command packet, the gateway can convey the complete control intent... Figure 1 It is passed to the messenger node in a one-time, structured manner.

[0059] In one embodiment of this application, the specific process of S3 is as follows: This process is performed using the ID of the selected best signaling node and the raw control command from the upper-layer application. Continuing the previous example, if the output of S2 is the signaling node ID: LEDU_098, the raw command from the upper-layer application is to adjust the brightness of the street light LEDU_101 to 50%. This raw command corresponds to a standard control command frame in the Z-Wave protocol, namely the "raw load". For example, this raw load may be a frame conforming to the Z-Wave "COMMAND_CLASS_SWITCH_MULTILEVEL" command set, which contains the target brightness value of 50%.

[0060] Specifically, the Z-Wave gateway's processor constructs a special data structure: the messenger command packet. This packet is not a standard Z-Wave command, but a custom data structure defined in this application and carried at the application layer. This packet is designed to encapsulate and deliver proxy tasks. Its core content includes three parts: a messenger request ID, a unique identifier for this messenger task, such as an auto-incrementing sequence number or a timestamp-generated ID. Its purpose is to help the gateway and messenger nodes track specific tasks, especially when handling execution confirmations and possible timeout retries. For example, the ID for this task is MSG_REQ_007. The final destination ID, which explicitly specifies the node to which the control command should ultimately be delivered. In this example, this ID is LEDU_101. The raw payload, which is the unmodified standard Z-Wave command frame that needs to be ultimately delivered to the target node. In this example, it is the command frame to adjust the brightness to 50%. The gateway combines these three pieces of information (MSG_REQ_007, LEDU_101, [brightness adjustment command frame]) into the payload of a messenger command packet.

[0061] The gateway then encapsulates this payload in a standard Z-Wave data frame, with the destination address set to the ID of the nearest messenger node, LEDU_098. After the packet is constructed, the gateway's Z-Wave transceiver module uses its maintained global routing topology map to find the optimal path using LEDU_098 and transmits the encapsulated messenger command packet via radio frequency signal.

[0062] In S4, upon receiving a messenger command packet, the messenger node parses the packet to obtain the final target ID and the original payload. It should be understood that the messenger command packet is a black box containing instructions for the messenger node, carrying the gateway's control intent. For the messenger node to correctly fulfill its proxy duties, it must first understand the specific content of the task. It cannot directly forward the entire messenger command packet because the packet's format and target address (even the messenger node itself) are not understandable to the final target node. Therefore, the purpose of parsing is to allow the messenger node to decipher the task instruction packet sent by the gateway and extract the core information necessary for executing subsequent actions. Through parsing, the messenger node can accurately identify the end customer it needs to serve (final target ID) and the specific goods to be delivered (original payload), laying the information foundation for subsequent intelligent forwarding.

[0063] In one embodiment of this application, the specific process of S4 is as follows: The control logic program running on the processor of the messenger node LEDU_098 immediately starts a dispatch routine after receiving application layer data from the underlying protocol stack. This routine first checks the command class identifier of the incoming data frame. In this application, all messenger command packets are encapsulated under a pre-defined, custom command class, such as COMMAND_CLASS_MESSENGER_PROXY. When the dispatch routine recognizes this specific command class, it knows that the data packet is not a standard control command that needs to be executed directly by this node, but a proxy task that needs to be parsed and forwarded. Subsequently, it passes the payload of the data packet to a dedicated messenger command parsing module.

[0064] Once a messenger command packet is confirmed, the parsing module strictly follows a predefined binary data structure for byte-level parsing. This format is completely consistent with the format followed by the gateway when constructing data packets in S3, ensuring semantic consistency between the communicating parties. For example, the payload data structure of the messenger command packet is predefined as follows: the first four bytes are the messenger request ID, the fifth byte is the final destination ID, and the sixth byte and thereafter are the variable-length raw payload. The parser of the messenger node LEDU_098 extracts information sequentially from the received payload byte stream. The program first locates the beginning of the payload and reads bytes 1 to 4. These four bytes, for example [0x00, 0x00, 0x00, 0x07], are treated by the program as a 32-bit big-endian unsigned integer. Bitwise operations such as shift and OR operations are used to combine them into a complete integer value of 7, thus obtaining the messenger request ID: MSG_REQ_007. This ID is immediately stored in a dynamic task table, associated with the current timestamp, for matching and task status management during subsequent execution confirmation. Next, the program's read pointer moves to the 5th byte. It reads the value of this byte, for example, 0x65, and interprets it as an 8-bit node ID. The program queries the internal node information table or uses the value directly to obtain the final target ID: LEDU_101. Finally, the program moves the read pointer to the 6th byte and copies all remaining bytes from that position to the end of the payload data stream as a single, continuous byte array. This data is the raw payload. This raw payload itself is a complete, independent, standard command frame conforming to the Z-Wave protocol specification. It contains its own command class, command, and parameters. For example, it might contain a byte sequence such as [COMMAND_CLASS_SWITCH_MULTILEVEL, SWITCH_MULTILEVEL_SET, value=0x32], representing a command requesting to set the brightness to 50%. The parsing module does not modify this content; it simply extracts and caches it completely.

[0065] In this way, the signaling node LEDU_098 successfully separated the task metadata from the core instructions from a well-encapsulated messenger command package, extracting two crucial information fragments: the final target ID (LEDU_101) and the original payload (brightness adjustment command).

[0066] In S5, the messenger node queries its local link health table to see if the final target ID exists. If it does, it sends a standard Z-Wave command to the target node. If it doesn't exist, it selects the first best neighbor node closer to the target node from the local link health table as the next relay point and sends a standard Z-Wave command to that next relay point. Accordingly, after successfully resolving the task details, the messenger node knows what to send and to whom. At this point, it needs to decide how to send it. Traditional Z-Wave nodes rely on static routes provided by the gateway, but in this application, the messenger node is given local decision-making power. It cannot blindly broadcast or arbitrarily select a neighbor, but needs to make the optimal choice based on its real-time perception of the local network environment. Therefore, this application introduces the messenger node querying and selecting from its local link health table, enabling the messenger node to truly apply its self-maintained local link health table to routing decisions. By querying this dynamically updated local link health table, the information node can execute an intelligent, case-based routing logic based on the location of the final target, realizing the key link of transforming the information node from an information holder into an intelligent actor.

[0067] In one embodiment of this application, Figure 2 This is a flowchart of step S5 in the multi-level network control method for LED streetlights based on a Z-Wave gateway according to an embodiment of this application. Figure 2 As shown, S5, the signaling node queries its local link health table to check if the final target ID exists, including: S51, the signaling node extracts all active neighbor nodes from the local link health table; S52, it determines whether the final target ID exists among all active neighbor nodes. In one embodiment of this application, S5, selecting the first best neighbor node closer to the target node from the local link health table as the next relay point, and sending a standard Z-Wave command to the next relay point, includes: S53, selecting neighbor nodes closer to the target node's physical location or network topology location from the local link health table as a set of candidate neighbor nodes; S54, selecting the neighbor node with the highest LQS score from the set of candidate neighbor nodes as the first best neighbor node.

[0068] In the above embodiment, the specific process of S5 is as follows: First, the control logic of the signaling node, such as LEDU_098, executes a branch judgment. It traverses all active neighbor nodes in its local link health table and determines whether the final target ID (LEDU_101) exists in this list of active neighbors.

[0069] Specifically, first, S51 is executed. The control logic program of the signaling node LEDU_098 performs a filtering query on its internal local link health table. The condition for this query is that the value of the link status field is equal to 1, indicating activity. The program iterates through each record in the table, extracting the neighbor IDs from the records that meet the condition, forming a temporary list of active neighbor IDs. For example, LEDU_098's local link health table contains 5 neighbors, of which LEDU_097, LEDU_099, and LEDU_101 are active, while the other two neighbors are marked as failed due to probe timeout. Therefore, a list containing three IDs is obtained: {LEDU_097, LEDU_099, LEDU_101}. This list represents all currently available, directly reachable neighbor nodes. Next, S52 is executed. The control logic program performs a search operation on this list of active neighbor IDs, aiming to find whether there is an element that matches the final target ID. In this example, the program compares each element in the list, LEDU_097, LEDU_099, and LEDU_101, with the target ID LEDU_101. When comparing the third element in the list, it finds that LEDU_101 == LEDU_101, indicating a successful match, and therefore the result is that the element exists.

[0070] Once its existence is confirmed, it indicates that the final target is within a one-hop reachable range and the link is currently healthy. This is the most efficient delivery path, requiring no intermediate forwarding. At this point, the signaling node LEDU_098 will immediately take action: it will extract the original payload, namely the brightness adjustment command, cached in S4. Then, it will call the transmit function of the Z-Wave protocol stack to construct a new standard Z-Wave data frame. The payload of this frame is the original payload, and its data link layer destination address is explicitly set to the final target ID, namely LEDU_101. Finally, this data frame is transmitted to the wireless channel through the node's Z-Wave transceiver module.

[0071] If the result is "not found," it means that the final target ID (e.g., LEDU_101) is not in the active neighbor list of the messenger node LEDU_098. The messenger node LEDU_098 then needs to select the most suitable next node from its healthy neighbors to relay the command.

[0072] First, step S53 is executed, which filters out all neighbors with the correct orientation, forming a candidate set. The signaling node LEDU_098 iterates through all active neighbors in its local link health table. For each active neighbor, it needs to determine if that neighbor is closer to the final target LEDU_101 than itself. This proximity determination can be based on two methods: physical location or network topology location. If physical location is used, the signaling node LEDU_098 pre-stores its own and all its neighboring nodes' geographic coordinates, for example, through installation configuration or the location reporting function in a Z-Wave network. Simultaneously, it also needs to obtain the geographic coordinates of the final target node LEDU_101. These coordinates are represented in latitude and longitude. The logic for determining closer neighbors is: calculating the straight-line physical distance from the signaling node LEDU_098 to the target LEDU_101, and the straight-line physical distance from each active neighbor to the target LEDU_101. If the distance from an active neighbor to the target LEDU_101 is less than the distance from LEDU_098 to LEDU_101, then that neighbor is considered to be in the correct orientation. For example, LEDU_098 is located at (X1, Y1), LEDU_101 is located at (X_target, Y_target), and its neighbor LEDU_099 is located at (X2, Y2). If the Euclidean distance from LEDU_099 to LEDU_101 is less than the distance from LEDU_098 to LEDU_101, then LEDU_099 is included in the candidate set. When using network topology location as a metric, the signaling node LEDU_098 utilizes simplified global topology information that it maintains and periodically synchronizes from the Z-Wave gateway. This information contains hop count relationships between nodes in the network. The signaling node LEDU_098 queries its current known hop count to the target LEDU_101, for example, 3 hops. Then, it queries the hop count to the target LEDU_101 for each of its active neighbors, such as LEDU_097, LEDU_099, and LEDU_120. If the number of hops from an active neighbor to the target LEDU_101 is less than the number of hops from LEDU_098 to LEDU_101, then that neighbor is considered to be in the correct direction. For example, if LEDU_097 requires 4 hops or more to reach LEDU_101, while LEDU_099 and LEDU_120 both only require 2 hops or less, then LEDU_099 and LEDU_120 together constitute the set of candidate neighbor nodes. It is worth mentioning that in actual deployment, the system will choose one of the judgment methods or set priorities according to specific needs. Once the candidate set is formed, the process proceeds to S54. The signaling node LEDU_098 will query its local link health table to find the Link Quality Score (LQS) corresponding to each neighbor in the candidate set. The LQS score is calculated in S14 and comprehensively reflects the link's round-trip time and signal strength.For example, if the table records that the LQS score of the link to LEDU_099 is 0.85, while the LQS score of the link to LEDU_120 is 0.72, the program finds that 0.85 is a higher score, indicating that the current wireless link quality to LEDU_099 is better than that to LEDU_120. Therefore, LEDU_099 is selected as the first best neighbor node. Once the best relay point is determined, the relay node LEDU_098 encapsulates the raw payload (brightness adjustment command) parsed from S4 into a new standard Z-Wave data frame. The destination address of this frame is set to the ID of the newly selected first best neighbor node, namely LEDU_099. Finally, this data frame is sent out through the node's Z-Wave transceiver module.

[0073] In S6, in response to the messenger node not receiving an ACK signal from the next relay point, the messenger node updates the status of the first best neighbor node in the local link health table to failure, and again selects the second best neighbor node closer to the target node from the local link health table as the next relay point, and sends a standard Z-Wave command to the next relay point. It is understandable that in a wireless network environment, even the best path selected based on real-time link quality may suddenly fail due to transient interference, temporary node failures, or sudden environmental changes, resulting in data packets failing to be delivered. If the messenger node immediately gives up or reports the problem to the gateway after the first failed attempt, this not only introduces additional communication delays and network overhead, but more importantly, it weakens the core advantage of local autonomous routing in dealing with dynamic environments. Therefore, this example endows the messenger node with strong local self-healing capabilities. By immediately updating the link status and quickly switching to a suboptimal path for retry after the first failed transmission, the messenger node can efficiently avoid transient failures and unnecessary global route recalculation, thereby significantly improving the robustness of command delivery and the overall reliability of the network.

[0074] In one embodiment of this application, Figure 3 This is a flowchart of step S6 in the multi-level networking control method for LED streetlights based on a Z-Wave gateway according to an embodiment of this application. Figure 3As shown, S6, the signaling node updates the status of the first best neighbor node in the local link health table to failure, including: S61, the signaling node does not report the failure to the Z-Wave gateway. In one embodiment of this application, S6, again selecting a second best neighbor node closer to the target node from the local link health table as the next relay point, and sending a standard Z-Wave command to the next relay point, includes: S62, excluding the first best neighbor node from the local link health table to obtain an updated local link health table; S63, selecting a neighbor node closer to the target node's physical location or network topology location from the updated local link health table as a set of candidate neighbor nodes; S64, selecting the neighbor node with the highest LQS score from the set of candidate neighbor nodes as the second best neighbor node.

[0075] In the above embodiment, the specific process of S6 is as follows: It is worth mentioning that the Z-Wave protocol stipulates that when a node sends a unicast data frame, the receiver must return an ACK signal within a short period of time, ranging from tens to hundreds of milliseconds, depending on the Z-Wave version and network configuration, to confirm the successful reception of the data packet. The Z-Wave communication module of the signaling node LEDU_098 starts a high-precision timer after sending the command and waits for an ACK. If the timer times out within a preset number of retries, such as 3, and no ACK is received, the Z-Wave protocol stack will report the transmission failure to the control logic above the signaling node.

[0076] In response to a transmission failure event reported by the Z-Wave protocol stack, the control logic of the signaling node LEDU_098 immediately initiates a fault handling procedure. It first identifies the neighbor node ID that caused the failure, namely LEDU_099. Then, the program accesses its in-memory local link health table. The control logic of signaling node LEDU_098 locates the entry in the local link health table corresponding to LEDU_099. It then updates the value of the link state field in that entry from currently active to failed. This status update is immediate and limited to the local view of signaling node LEDU_098 itself. For example, if the original health table entry for LEDU_099 was {ID:LEDU_099, Status: Active, LQS:0.85}, the updated entry will be {ID:LEDU_099, Status: Failed, LQS:0.85}. Specifically, the LQS score does not change immediately because LQS reflects the average quality of the link, while a failure may only be a transient phenomenon.

[0077] A key feature of this application, while performing this state update, is reflected in S61: the messenger node LEDU_098 will not proactively send any report messages to the Z-Wave gateway regarding the failure of the LEDU_099 link. This means that the messenger node will not trigger specific commands in the Z-Wave network management protocol used to report node failures or link interruptions, such as certain private commands or the network health reporting mechanism in Z-Wave Plus. This non-reporting strategy is to avoid reporting transient, localized link problems to the global network, thereby reducing the burden on the gateway, avoiding unnecessary global route recalculation and network topology updates, and maintaining network stability and response speed. The messenger node chooses to perform rapid self-healing locally, and will only consider reporting the final result of the task failure to the gateway if multiple attempts fail and no alternative path can be found.

[0078] Next, the signaling node LEDU_098 initiates the process of selecting the second best neighbor node. First, S62 is executed. When selecting subsequent neighbors, the control logic of signaling node LEDU_098 actively filters out all neighbor nodes with a failed status, ensuring that links already confirmed as unavailable are not retried. For example, if its local link health table originally contained LEDU_097 (active), LEDU_099 (failed), and LEDU_120 (active), then in this selection, LEDU_099 will be excluded, and the actual set of neighbors used for filtering will be {LEDU_097, LEDU_120}. Then, S63 is executed, which filters out all neighbors with the correct direction from this updated local link health table, forming a set of candidate neighbor nodes. Signaling node LEDU_098 will iterate through the remaining active neighbors and determine whether each neighbor is closer to the final target LEDU_101 than itself. This proximity determination can be based on two methods: If physical location is used, the signaling node LEDU_098 will utilize pre-stored geographic coordinates of itself, its active neighbors, and the final target LEDU_101. This physical location method is the same as the method used to determine the first best neighbor node. For example, if the distance from LEDU_098 to LEDU_101 is greater than the distance from its active neighbor LEDU_120 to LEDU_101, then LEDU_120 is included in the candidate set. If network topology location is used, the signaling node LEDU_098 will query the simplified global topology information synchronized from the Z-Wave gateway. This network topology method is the same as the method used to determine the first best neighbor node. For example, if it takes 4 hops to get from LEDU_097 to LEDU_101, while it takes 2 hops to get closer, then the candidate set will be {LEDU_120}. Once the candidate set is formed, the process proceeds to sub-S64. The signaling node LEDU_098 selects the neighbor with the highest LQS score from this candidate set as the second best neighbor. It queries the local link health table to find the LQS score for each neighbor in the candidate set. For example, if the candidate set is {LEDU_120, LEDU_130}, and LEDU_120 has an LQS of 0.72 while LEDU_130 has an LQS of 0.68, then LEDU_120 is selected as the second best neighbor due to its higher LQS score. Once the second best neighbor LEDU_120 is determined, the signaling node LEDU_098 retrieves the original payload (brightness adjustment command) and encapsulates it in a new standard Z-Wave data frame. The data link layer destination address of this frame is set to the ID of the newly selected second best neighbor, LEDU_120. Finally, this data frame is sent out through the node's Z-Wave transceiver module.

[0079] In S7, after receiving the standard Z-Wave command from the first or second best neighbor node, the target node returns an execution confirmation packet to the messenger node along the path from which the command was transmitted. That is, after one or more hops of intelligent forwarding by the messenger node, the standard Z-Wave command finally reaches the target node. However, simply sending the command is insufficient to ensure task integrity. As a gateway proxy, the messenger node not only needs to ensure the command is delivered but also needs to confirm that the command is successfully executed at the target node. Without this end-to-end execution confirmation mechanism, the messenger node will be unable to report the final status of the task to the gateway and will be unable to promptly detect and handle faults at the target node level (e.g., the command is received but cannot be executed). Therefore, this application enables the messenger node to accurately grasp the final execution result of the command by having the target node actively return execution confirmation, thereby completing the closed-loop management of its proxy task and providing the gateway with accurate task status reports, greatly improving the reliability and traceability of the entire control system.

[0080] In one embodiment of this application, the specific process of S7 is as follows: The target node, such as LEDU_101, successfully receives a standard Z-Wave command. This command may come directly from the messenger node LEDU_098 if LEDU_101 is a direct neighbor of LEDU_098, or be forwarded by a first best neighbor node such as LEDU_099 or a second best neighbor node such as LEDU_120. Continuing the previous example, if LEDU_101 receives a standard Z-Wave command forwarded by LEDU_099 requesting that the brightness be set to 50%, when the Z-Wave transceiver module of the target node LEDU_101 receives the data frame, its protocol stack will perform a link layer acknowledgment (ACK) and pass the payload of the command to the upper layer application logic. The control program of LEDU_101 will parse the command, identify its command class, such as COMMAND_CLASS_SWITCH_MULTILEVEL and the specific command SWITCH_MULTILEVEL_SET, and parameters such as the brightness value 0x32, i.e., 50%.

[0081] After successfully parsing the command, LEDU_101 will immediately execute it. For example, it will drive its internal LED dimming module to adjust the street light brightness to 50%. After the command is executed, LEDU_101 needs to return an execution confirmation packet to the original messenger node LEDU_098. To achieve this, when forwarding the original payload in S5 or S6, the messenger node LEDU_098 embeds its own node ID LEDU_098 and the original messenger request ID, such as MSG_REQ_007, in a specific field of the standard Z-Wave command, such as a parameter field reserved in a custom Z-Wave command class or an existing command class. In this way, when the target node LEDU_101 receives and parses the command, in addition to obtaining the brightness adjustment instruction, it can also extract two key pieces of information: who the proxy sender is (LEDU_098) and which task this request is for (MSG_REQ_007).

[0082] To return an execution confirmation packet, the target node LEDU_101 constructs a new Z-Wave command. This command is a custom execution status report command, for example, belonging to the COMMAND_CLASS_MESSENGER_PROXY_REPORT command class. The payload of this report command will include the original messenger request IDMSG_REQ_007 and an execution status code, such as 0x00 for success and 0x01 for failure.

[0083] Regarding the specific implementation of returning along the path from the command, the target node LEDU_101 does not strictly trace every hop of the data packet backwards. Instead, it utilizes its own Z-Wave routing capabilities to send the execution acknowledgment packet back to the messenger node LEDU_098. This is similar to the logic of the messenger node selecting the next hop in S5 and S6. LEDU_101 uses its own maintained local link health table as a reference, combined with global topology information synchronized from the gateway, to intelligently select the currently optimal path. Specifically, LEDU_101 sets the destination address of its constructed execution acknowledgment packet to the ID of the messenger node LEDU_098. Then, it queries its local link health table to determine whether LEDU_098 is its direct neighbor. If LEDU_098 is a direct neighbor of LEDU_101 and its link is active, LEDU_101 directly sends the execution acknowledgment packet to LEDU_098. If LEDU_098 is not a direct neighbor of LEDU_101, LEDU_101 will select a neighbor closer to LEDU_098 from its active neighbors as the next hop relay point, prioritizing the link with the highest LQS score for transmission. This process continues until the acknowledgment packet finally reaches the signaling node LEDU_098, thus supporting precise control of the streetlights and rapid fault response.

[0084] In summary, the multi-level network control method for LED streetlights based on a Z-Wave gateway, as described in this application, is explained. It introduces the role of a messenger node, which acts as a proxy for the gateway in the target area. The gateway no longer directly specifies the complete static path but instead sends commands only to the messenger node closest to the target. The messenger node maintains a real-time local link health table by periodically probing the link quality of its neighboring nodes. Upon receiving a command from the gateway, the messenger node first attempts direct communication or selects the best neighbor node for relay forwarding using its local health table. If a local path fails due to a sudden obstacle, the messenger node does not need to report to the gateway but can immediately retry autonomously based on alternative paths in the health table, intelligently bypassing the fault point. This approach, combining macro-level guidance of global routing with autonomous decision-making by local nodes, endows the network with rapid self-healing capabilities at the link end, effectively avoiding instantaneous communication interruptions caused by dynamic environmental changes, and significantly improving the delivery success rate of control commands and system robustness in complex environments.

[0085] Figure 4 This is a block diagram of a multi-level network control system for LED streetlights based on a Z-Wave gateway, according to an embodiment of this application. Figure 4As shown, the LED street light multi-level networking control system 100 based on a Z-Wave gateway according to an embodiment of this application includes: a local link health table generation module 110, used to periodically trigger local link health detection within each messenger node to obtain a local link health table; a nearest messenger node lookup module 120, used to find the messenger node closest to the target node through the Z-Wave gateway according to the global routing topology map; a messenger command packet sending module 130, used to send a messenger command packet to the messenger node through the Z-Wave gateway, the messenger command packet including a messenger request ID, a final target ID, and an original payload; a parsing module 140, used to parse the messenger command packet after receiving it to obtain the final target ID and the original payload; and a standard Z-Wave command sending module 150, used to query the messenger node's local link health table to see if the final target ID exists. If an ID exists, a standard Z-Wave command is sent to the target node; otherwise, a first best neighbor node closer to the target node is selected from the local link health table as the next relay point, and a standard Z-Wave command is sent to the next relay point. The node selection module 160 is configured to, in response to the signaling node not receiving an ACK signal from the next relay point, update the status of the first best neighbor node in the local link health table to "failure," and again select a second best neighbor node closer to the target node from the local link health table as the next relay point, and send a standard Z-Wave command to the next relay point. The acknowledgment module 170 is configured to, in response to the target node receiving the standard Z-Wave command from either the first or second best neighbor node, return an execution acknowledgment packet along the path from which the command was transmitted to the signaling node.

[0086] Here, those skilled in the art will understand that the specific operations of each step in the above-described multi-level networking control system for LED streetlights based on Z-Wave gateways have been referenced above. Figures 1 to 3 The multi-level networking control method for LED streetlights based on Z-Wave gateways has been described in detail, and therefore, its repeated description will be omitted.

Claims

1. A multi-level networking control method for LED street lamps based on a Z-Wave gateway, characterized in that, The application relates to a method for transmitting a command from a Z-Wave gateway to a target node in a Z-Wave network, comprising: periodically triggering a local link health detection in each messenger node to obtain a local link health table; the Z-Wave gateway searching for a nearest messenger node to the target node according to a global routing topology; the Z-Wave gateway sending a messenger command packet to the messenger node, the messenger command packet comprising a messenger request ID, a final target ID and an original load; after receiving the messenger command packet, the messenger node parsing the messenger command packet to obtain the final target ID and the original load; the messenger node querying whether the final target ID exists in the local link health table, and if yes, sending a standard Z-Wave command to the target node, and if not, selecting a first best neighbor node closer to the target node from the local link health table as a next relay point and sending a standard Z-Wave command to the next relay point; in response to the messenger node not receiving an ACK signal from the next relay point, the messenger node updating a state of the first best neighbor node in the local link health table as failed, and again selecting a second best neighbor node closer to the target node from the local link health table as a next relay point and sending a standard Z-Wave command to the next relay point; the target node returning an execution acknowledgement packet to the messenger node along a path of the command after receiving the standard Z-Wave command of the first best neighbor node or the second best neighbor node. 2.The Z-Wave gateway-based multi-level networking control method for LED street lamps according to claim 1, wherein, periodically triggering a local link health detection in each messenger node to obtain a local link health table, comprising: the messenger node sending a health detection data packet to a first neighbor node; recording a round trip time of the health detection data packet by a timer; obtaining a signal strength indication from an API of a Z-Wave chip of the Z-Wave gateway; calculating a link quality score of the first neighbor node based on the round trip time and the signal strength indication. 3.The multi-level networking control method of LED street lamp based on Z-Wave gateway according to claim 2, characterized in that, calculating a link quality score of the first neighbor node based on the round trip time and the signal strength indication, comprising: normalizing the round trip time and the signal strength indication to obtain a normalized round trip time and a normalized signal strength indication; calculating the link quality score of the first neighbor node based on the normalized round trip time and the normalized signal strength indication according to a formula as follows: ； wherein, and are normalized signal strength indication and normalized round trip time, respectively, and are signal strength indication preset weighting weight and round trip time preset weighting weight, respectively, is a link quality score of the first neighbor node. 4.The method of claim 1, wherein, the messenger node querying whether the final target ID exists in the local link health table, comprising: the messenger node extracting all neighbor nodes with a state of active from the local link health table; judging whether the final target ID exists in all the neighbor nodes with the state of active.

5. The LED street light multi-level networking control method based on the Z-Wave gateway according to claim 4, characterized in that, selecting a first best neighbor node closer to the target node from the local link health table as a next relay point and sending a standard Z-Wave command to the next relay point, comprising: selecting neighbor nodes closer to a physical position or a network topology position of the target node from the local link health table as a set of candidate neighbor nodes; The neighbor node with the highest LQS score is selected from the set of candidate neighbor nodes as the first best neighbor node. 6.The method of claim 1, wherein, The signaling node updates the status of the first best neighbor node in the local link health table to failure, including: the signaling node does not report the failure to the Z-Wave gateway. 7.The multi-level networking control method of LED street lamp based on Z-Wave gateway according to claim 6, characterized in that, Again, select the second best neighbor node closer to the target node from the local link health table as the next relay point, and send the standard Z-Wave command to the next relay point, including: The first best neighbor node is excluded from the local link health table to obtain an updated local link health table; Select neighboring nodes that are closer to the target node in terms of physical location or network topology from the updated local link health table as a set of candidate neighboring nodes; Select the neighbor node with the highest LQS score from the set of candidate neighbor nodes as the second best neighbor node.

8. A multi-level networking control system for LED street lamps based on a Z-Wave gateway, characterized in that, include: The local link health table generation module is used to periodically trigger local link health detection within each messenger node to obtain the local link health table. The nearest messenger node lookup module is used to find the nearest messenger node to the target node based on the global routing topology map through the Z-Wave gateway; The messenger command packet sending module is used to send a messenger command packet to the messenger node through the Z-Wave gateway. The messenger command packet includes a messenger request ID, a final target ID, and a raw payload. The parsing module is used to parse the messenger command packet after receiving it to obtain the final target ID and the original payload. The standard Z-Wave command sending module is used to query the local link health table of the messenger node to see if the final target ID exists. If it exists, the standard Z-Wave command is sent to the target node. If it does not exist, the first best neighbor node closer to the target node is selected from the local link health table as the next relay point, and the standard Z-Wave command is sent to the next relay point. The node selection module is used to respond to the fact that the signaling node does not receive an ACK signal from the next relay point, update the status of the first best neighbor node in the local link health table to failure, and select the second best neighbor node that is closer to the target node from the local link health table as the next relay point, and send the standard Z-Wave command to the next relay point. The acknowledgment module is used to respond to the target node returning an execution acknowledgment packet to the messenger node along the path from which the command was transmitted after receiving the standard Z-Wave command from the first best neighbor node or the second best neighbor node.

Images