A dual wireless communication cooperative control method for a photovoltaic tracking controller
Patent Information
- Application Number
- CN202610928407.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-25
- Publication Date
- 2026-09-22
AI Technical Summary
现有技术多采用单一无线通信方式承担远程数据交互,其中部分方案利用远距离通信技术实现主站与分散节点之间的主干连接,但在节点规模较大时难以兼顾局部节点间的实时状态共享;另有方案采用近距离组网技术实现区域内节点互联,但其远距离穿透和回传能力有限,难以独立承担远程主干通信
本发明通过周期性采集两条异构通信链路的状态参数并评估其健康状态,使得控制器能够实时感知远距离主干链路与区域协同链路的实际可用性,从而为后续通信模式的自适应调整提供依据;进而根据健康状态在主通信链路、备用通信链路及通信失联保护模式之间进行动态切换,使得当单条链路异常时可通过另一条链路维持控制通道与状态上报能力,避免单一链路失效即导致节点失联,而在双链路均异常时则主动进入通信失联保护模式,停止普通自动跟踪并依据本地传感器数据执行安全保护动作,防止控制器在无法接收远程保护指令的情况下继续运行而诱发安全风险;同时通过对来自不同链路的控制命令进行去重、校验和优先级仲裁,有效消除了因双链路并发传输或区域转发带来的重复执行、过期命令生效及安全命令被普通命令覆盖等冲突隐患,确保最终执行命令的合法性与时效性;因此,本发明实现了通信链路健康状态的持续监测与通信角色的动态优化,在保障远程主站管理权限的同时,借助区域协同链路提升局部通信韧性,并通过通信失联保护机制将通信完全中断时的系统状态约束在安全可控范围内,显著增强光伏跟踪控制器在复杂工况和通信不稳定环境下的抗扰能力与运行安全性,且可以为通信恢复后的状态追溯与参数同步奠定数据基础。
Smart Images

Figure CN122802943A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of photovoltaic tracking control technology, and in particular to a dual wireless communication cooperative control method for photovoltaic tracking controllers. Background Technology
[0002] Photovoltaic tracking systems are typically deployed across large areas, comprising numerous dispersed tracking brackets and their controllers. Each controller needs to communicate with a remote master station or gateway to receive control commands and report its operational status. Existing technologies mostly employ a single wireless communication method for remote data interaction. Some solutions utilize long-distance communication technology to establish a backbone connection between the master station and distributed nodes, but this is insufficient for real-time status sharing between local nodes when the node scale is large. Other solutions use short-range networking technology to interconnect nodes within a region, but their long-distance penetration and backhaul capabilities are limited, making it difficult to independently handle remote backbone communication. When the main communication link malfunctions due to obstruction, interference, or equipment failure, the controller often lacks an effective backup link takeover mechanism, failing to receive timely safety protection commands or maintenance commands, thus increasing the risk of node disconnection. Furthermore, with multiple communication links coexisting, the lack of deduplication, verification, and conflict arbitration for control commands from different links can easily lead to problems such as duplicate execution, expired commands overwriting new commands, or ordinary commands overwriting safety commands, affecting the reliability and security of the tracker's operation. Furthermore, if the controller continues to execute unconfirmed remote commands or maintains normal automatic tracking mode when communication is completely interrupted, it may cause mechanical damage under severe weather conditions. If the machine is shut down directly without a protection strategy, the on-site condition will be uncontrollable and difficult to recover. At the same time, if the operating status and alarm information during the offline period are not reported in a timely manner after communication is restored, the remote platform will make inaccurate judgments on the actual on-site working conditions. Summary of the Invention
[0003] To address the aforementioned shortcomings, the present invention aims to propose a dual wireless communication cooperative control method for photovoltaic tracking controllers. This method involves coordinating the long-distance backbone communication link and the regional cooperative communication link within the same photovoltaic tracking controller, dynamically selecting the primary / backup communication mode or the communication failure protection mode based on the link health status, and simultaneously deduplicating, verifying, and prioritizing control commands from different links. This ensures that the tracking controller maintains effective control and traceability even in the event of communication anomalies, avoiding malfunctions, missed actions, and uncontrollable states caused by communication failures. Ultimately, this improves the reliability and safety of the photovoltaic tracking system in complex electromagnetic environments and long-term unattended scenarios.
[0004] To achieve this objective, the present invention adopts the following technical solution: A dual wireless communication cooperative control method for a photovoltaic tracking controller includes the following steps: S1: Periodically collect the LoRa link status parameters of the LoRa communication module and the Zigbee link status parameters of the Zigbee communication module; S2: Determine the health status of the two communication links based on the LoRa link status parameters and the Zigbee link status parameters respectively; S3: Based on the health status, dynamically switch between the main communication link, the backup communication link, or the communication disconnection protection mode; S4: Deduplicatize, verify, and prioritize the control commands from the LoRa communication module and the Zigbee communication module to determine the final command to be executed; S5: When it is determined that both communication links are abnormal, the communication disconnection protection mode is entered, normal automatic tracking is stopped, and safety protection actions are performed based on local sensor data.
[0005] Preferably, step S3 includes: When the health status of the LoRa communication link is normal, the LoRa communication link is set as the main communication link and the Zigbee communication link is set as the auxiliary link. The auxiliary link is used for adjacent node status sharing, area broadcasting and maintenance terminal access. When the LoRa communication link is in an abnormal state while the Zigbee communication link is in a normal state, the Zigbee communication link takes over the area to forward or maintain communication, and the photovoltaic tracking controller marks the communication status as LoRa downgrade and records it. When the Zigbee communication link is in an abnormal state while the LoRa communication link is in a normal state, the LoRa communication link is maintained as the primary communication link, and regional forwarding is stopped.
[0006] Preferably, determining the health status of the two communication links includes: Collect at least two of the following as link status parameters: heartbeat timeout status, number of consecutive communication failures, signal strength, signal-to-noise ratio, packet loss rate, last effective communication time, node network entry status, command verification result, and communication queue congestion level; Based on the combined logic of the link status parameters, the health status of the communication link is determined as normal, weak connection, abnormal or offline. When the number of consecutive failures exceeds the threshold and the most recent effective communication time exceeds the preset duration, it is judged as abnormal or offline. When the signal strength is detected to be lower than the preset threshold or the packet loss rate increases, it is judged as a weak connection.
[0007] Preferably, dynamically switching between the primary communication link, the backup communication link, or the communication disconnection protection mode based on the health status includes: When the LoRa communication link is in an abnormal state and the Zigbee communication link is in a normal state, the communication state is marked as LoRa downgraded, and the abnormal state is broadcast to adjacent nodes or regional nodes through the Zigbee communication link in order to receive remote control commands, maintenance commands or regional protection commands forwarded through the Zigbee communication link. When both the LoRa and Zigbee communication links are in an abnormal state, the communication disconnection protection mode is entered, and the execution of unconfirmed, expired, or normal-level remote commands is stopped. Normal automatic tracking, remote parameter updates, and unnecessary timed actions are stopped, and the system is preferentially switched to a preset safe angle, maintained at the current safe angle, or the motor output is locked. In the communication loss protection mode, local sensor data, including wind speed, rain and snow, tilt angle, current, battery status and limit status, are continuously monitored.
[0008] Preferably, step S4 includes: Pre-configure control command fields, including command type, serial number, validity period, permission flag, checksum, target node ID, target area ID, and forwarding hop count; Upon receiving a control command, its validity is verified using the permission flag and the verification code. If the verification fails, the control command is discarded. The sequence number is used for deduplication. If the sequence number of the control command already exists in the processed queue, or the current time exceeds the validity period of the control command, then the control command is discarded. For control commands forwarded via the Zigbee communication module, target matching is determined based on the target node ID or the target region ID. The command is executed if the target matches and the forwarding hop count does not exceed a preset limit; otherwise, it is discarded. When multiple valid control commands are received, arbitration is performed based on the priority determined by the command type, wherein the priority of the safety protection command is higher than the shutdown or maintenance command, and the priority of the shutdown or maintenance command is higher than the automatic tracking command. If the command types have the same priority, the control command with the newer timestamp is selected as the final execution command.
[0009] Preferably, it also includes severe weather protection steps: When a severe weather protection order is received, the priority of the severe weather protection order is set to the highest level; Dual-link broadcasting is performed through the LoRa communication module and the Zigbee communication module. The severe weather protection command includes the disaster type, protection action, command sequence number, release timestamp, validity period, number of repeated broadcasts, and confirmation receipt requirements. When the photovoltaic tracking controller receives a severe weather protection command through either the LoRa communication module or the Zigbee communication module, it executes the corresponding protection action, records the sequence number of the severe weather protection command, and returns a confirmation receipt through an available link. When the photovoltaic tracking controller receives a severe weather protection command with the same serial number again, it will only send a confirmation receipt or continue to forward the command, and will not execute the corresponding protection action. The severe weather protection command has a higher priority than other ordinary control commands, and the execution status of the severe weather protection command is maintained until a disaster relief command or a manual authorization recovery command is received.
[0010] Preferably, in the communication loss protection mode, it further includes: Periodically check the recovery status of the communication link; Continuously monitor local sensor data, including wind speed, rain and snow, tilt angle, current, battery status, and limit status; When the local sensor data meets the preset security risk conditions, the local security protection strategy for the security risk conditions is executed first. If an anomaly is detected in the local clock or a critical sensor, the photovoltaic tracking controller is controlled to enter a safety hold state or switch to a preset safety angle, and maintain this state until communication is restored or on-site maintenance confirms the change.
[0011] Preferably, it further includes communication recovery and state synchronization steps: When it is detected that at least one of the LoRa communication module or the Zigbee communication module has recovered from an abnormal state to a normal or weak connection state, the communication recovery process is triggered. The communication recovery process includes: uploading alarm records during the offline period, the last executed command and its result, the current angle of the photovoltaic tracker, the operating mode, the RTC time, and the communication status; Request parameter version verification from the remote master station and compare the local parameter version with the remote master station parameter version; After the parameter version verification passes, clear or downgrade the communication anomaly alarm and restore the reception of remote control commands; If the local parameter version is inconsistent with the remote master station parameter version, the authorized parameters of the remote master station shall prevail for synchronization, or the system shall enter a state of waiting for manual confirmation.
[0012] One of the above technical solutions has the following advantages or beneficial effects: This invention periodically collects the status parameters of two heterogeneous communication links and evaluates their health status, enabling the controller to perceive the actual availability of the long-distance backbone link and the regional collaborative link in real time, thus providing a basis for adaptive adjustment of the subsequent communication mode. Furthermore, it dynamically switches between the main communication link, the backup communication link, and the communication disconnection protection mode based on the health status. This allows the control channel and status reporting capability to be maintained through the other link when one link is abnormal, preventing node disconnection due to a single link failure. When both links are abnormal, it actively enters the communication disconnection protection mode, stops normal automatic tracking, and executes safety protection actions based on local sensor data, preventing the controller from continuing to operate without receiving remote protection commands and thus inducing safety risks. Simultaneously, it... By deduplicating, verifying, and prioritizing control commands from different links, this invention effectively eliminates potential conflicts such as duplicate execution, expired command activation, and security commands being overridden by ordinary commands caused by concurrent transmission of dual links or regional forwarding, ensuring the legality and timeliness of the final executed command. Therefore, this invention achieves continuous monitoring of the health status of communication links and dynamic optimization of communication roles. While ensuring the management authority of the remote master station, it enhances local communication resilience by leveraging regional collaborative links and constrains the system state during complete communication interruption within a safe and controllable range through a communication loss protection mechanism. This significantly enhances the anti-interference capability and operational safety of the photovoltaic tracking controller in complex operating conditions and unstable communication environments, and lays a data foundation for status traceability and parameter synchronization after communication is restored. Attached Figure Description
[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0014] Figure 1 This invention provides a dual wireless communication cooperative control method for photovoltaic tracking controllers. Figure 2 This is a diagram of the LoRa and Zigbee hierarchical collaborative communication structure provided in an embodiment of the present invention; Figure 3 This is a flowchart of dual-link health assessment and redundancy switching provided in an embodiment of the present invention; Figure 4 This is a flowchart of the dual-link command conflict arbitration process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of dual-link broadcast of disaster weather protection commands provided in an embodiment of the present invention. Detailed Implementation
[0015] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.
[0016] In this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0017] A dual wireless communication cooperative control method for photovoltaic tracking controllers, such as Figure 1 As shown, a preferred embodiment of the present invention includes the following steps: S1: Periodically collect the LoRa link status parameters of the LoRa communication module and the Zigbee link status parameters of the Zigbee communication module; It should be noted that the LoRa communication module is a long-range wireless communication unit based on LoRa modulation technology. It transmits data in the Sub-GHz band via spread spectrum modulation and is suitable for low-power long-distance communication between photovoltaic tracking controllers and remote gateways or control boxes. In step S1, it provides the physical transmission capability of the backbone communication link and generates raw state data reflecting the link transmission quality. The Zigbee communication module is a short-range, low-power wireless communication unit based on the IEEE 802.15.4 standard. It supports self-organizing network topologies and is suitable for local network communication between photovoltaic tracking controllers in the same area or adjacent areas. In step S1, it provides regional collaborative communication capabilities and generates local link state data. Link state parameters refer to quantitative or state-based indicators that characterize the current transmission performance and connection reliability of the wireless communication link. These include, but are not limited to, heartbeat response status, signal reception strength, signal-to-noise ratio, packet loss, communication failure records, timestamp of the most recent successful communication, node network registration status, data verification results, and communication buffer occupancy. In step S1, these parameters serve as the basic input information for evaluating the actual availability of the communication link. Periodic acquisition refers to the data acquisition behavior that is repeatedly executed according to a preset time interval or task scheduling cycle. It is completed by the microcontroller unit by calling the communication protocol stack interface or reading hardware registers. In step S1, it is used to continuously track the real-time performance changes of the two heterogeneous communication links and avoid misjudgment caused by a single instantaneous sampling.
[0018] Understandably, by having the microcontroller unit repeatedly read the link status parameters of the LoRa and Zigbee communication modules according to a preset cycle, continuous monitoring of the operation status of long-distance backbone communication links and regional collaborative communication links can be achieved, thus providing a real-time and complete data foundation for subsequent link health status assessment. Due to the complex deployment environment of photovoltaic power plants and the variety of electromagnetic interference sources, the link status at a single moment is difficult to accurately reflect the long-term trend of communication quality. The periodic sampling mechanism can effectively smooth out instantaneous fluctuations and capture the link performance degradation process, thereby effectively distinguishing between temporary interference and persistent faults, and providing a reliable basis for the dynamic management of communication links.
[0019] like Figure 2 As shown, the photovoltaic tracking system adopts a hierarchical collaborative communication architecture. The remote master station or control box establishes a long-distance backbone communication link with each photovoltaic tracking controller through a LoRa gateway to realize the issuance of remote control commands, reporting of operating status, and parameter synchronization. Within the same area or row, multiple photovoltaic tracking controllers form a local network through Zigbee modules, forming a regional collaborative communication link for adjacent node status sharing, regional broadcasting, and maintenance terminal access. When the LoRa link of a node is abnormal, it can be forwarded by a neighboring node through the Zigbee network to report remote commands or abnormal status, thus achieving complementarity between regional collaboration and backbone communication.
[0020] S2: Determine the health status of the two communication links based on the LoRa link status parameters and the Zigbee link status parameters respectively; It should be noted that health status is a qualitative or semi-quantitative characterization of the current availability level of a communication link. It is derived by comparing collected link status parameters with preset judgment criteria, and is typically categorized into levels such as normal, weak connection, abnormal, or offline. In step S2, it provides a basis for decision-making regarding the allocation of primary and backup roles and mode switching of the communication link. Combinational logic judgment refers to a decision-making method that comprehensively judges multiple input conditions according to preset Boolean logic or weighted rules, drawing conclusions without relying on a single indicator. In step S2, it is used to avoid misjudging the link status due to an abnormality in a single instantaneous indicator. A normal state indicates that the link can currently transmit data stably, meeting the functional requirements of the primary communication link; a weak connection state indicates that the link can still transmit data but there is a risk of performance degradation, making it suitable as an auxiliary monitoring channel; an abnormal state indicates that the link has exhibited obvious fault characteristics and is not suitable for undertaking primary communication tasks; an offline state indicates that the link has lost basic communication capabilities and requires the activation of protection mechanisms.
[0021] Understandably, by inputting LoRa link status parameters and Zigbee link status parameters into combinational logic judgment rules for comprehensive evaluation, the health levels of the two communication links can be independently and accurately determined, thereby effectively identifying the current availability level of each link. Single indicators such as signal strength or packet loss rate are easily affected by instantaneous environmental interference. Using multi-parameter combinational logic for comprehensive judgment can effectively filter out occasional noise and improve the robustness of link status evaluation, thus providing reliable link quality information for subsequent dynamic switching strategies and avoiding frequent switching of communication modes or omission of real link faults due to misjudgment.
[0022] S3: Based on the health status, dynamically switch between the main communication link, the backup communication link, or the communication disconnection protection mode; It should be noted that the primary communication link refers to the link that prioritizes core communication tasks such as receiving remote control commands, reporting operating status, and issuing parameters in the dual-link collaborative architecture. In step S3, it is used to ensure the smooth operation of the main data interaction channel between the photovoltaic tracking controller and the remote master station or gateway. The backup communication link refers to an alternative link that can take over some or all communication functions when the performance of the primary communication link degrades or is interrupted. In step S3, it is used to maintain the controller's basic communication capability in the event of a single link failure. The communication disconnection protection mode is a safe operating state that the controller actively enters when both communication links lose their effective communication capability. In this mode, the controller suspends ordinary business logic that relies on remote communication and activates local security protection strategies. In step S3, it is used to prevent the controller from being in an uncontrollable state after a complete communication interruption. Dynamic switching refers to the decision-making and execution process of automatically adjusting the communication role allocation and operating mode based on the real-time assessed link health status. This is completed by the microcontroller unit according to preset switching rules. In step S3, it is used to achieve optimal configuration of communication resources and fault adaptation.
[0023] Understandably, by having the microcontroller unit adaptively allocate roles and adjust operating modes among the main communication link, backup communication link, and communication disconnection protection mode based on the health status determined in step S2, dynamic optimization configuration and fault degradation management of communication link resources are achieved. This aims to maintain necessary communication capabilities when a single link fails and ensure system safety when both links fail. This switching mechanism makes decisions based on real-time link quality rather than a fixed topology, enabling the photovoltaic tracking controller to flexibly adjust communication strategies according to changes in the field electromagnetic environment. This avoids complete node disconnection due to a single link failure and prevents the continued execution of remote commands that may cause safety risks when communication is completely unavailable.
[0024] S4: Deduplicatize, verify, and prioritize the control commands from the LoRa communication module and the Zigbee communication module to determine the final command to be executed; It should be noted that control commands refer to instruction data generated and sent to the photovoltaic tracking controller by the remote master station, gateway, maintenance terminal, or neighboring nodes in the area. These commands are used to adjust the tracker's operating mode, update control parameters, or trigger protection actions, and are the input objects that need to be processed and filtered in step S4. Deduplication refers to the process of identifying and eliminating duplicate control commands through unique identifiers. In step S4, this is used to prevent the same command from being executed multiple times due to concurrent transmission across dual links or regional broadcast forwarding. Verification refers to the process of verifying the integrity and legality of the control command data using a preset algorithm. This typically includes checksum verification and authorization flag checking, and in step S4, it is used to filter out damaged, tampered, or unauthorized command frames. Priority arbitration refers to the decision-making process of selecting the command to be executed last based on a preset importance level when multiple valid commands exist simultaneously or conflict. In step S4, this is used to ensure that security protection commands take precedence over ordinary business commands. The final execution command refers to the unique control instruction that should be executed by the photovoltaic tracking controller in the current cycle after source identification, legality verification, duplicate elimination and timeliness judgment. In step S4, it is used as the output result to drive subsequent motor control or mode switching actions.
[0025] Understandably, by sequentially performing validity checks, sequence number deduplication, target matching checks, and priority arbitration on control commands from the LoRa and Zigbee communication modules, conflicts and validity screening of input commands from heterogeneous communication links are achieved. This avoids duplicate execution, expired commands taking effect, and security commands being overwritten by ordinary commands. Since the same command may arrive through different paths in a dual-link collaborative architecture, and commands from different sources have different importance, the deduplication mechanism can eliminate redundant operations, the verification mechanism can ensure the authenticity and integrity of commands, and the priority arbitration mechanism can ensure that emergency security commands are responded to first, thereby improving the accuracy of control command execution and the security of system response.
[0026] S5: When it is determined that both communication links are abnormal, the communication disconnection protection mode is entered, normal automatic tracking is stopped, and safety protection actions are performed based on local sensor data.
[0027] It should be noted that local sensor data refers to physical quantity information collected by environmental monitoring and operational status detection devices deployed around the photovoltaic tracker or controller, including but not limited to wind speed detection values, rain and snow presence status, current tilt angle measurement values, motor drive current, energy storage battery voltage, and mechanical limit trigger signals. In step S5, this data is used to guide local safety decisions in place of remote commands when communication is completely interrupted. Safety protection actions refer to preset physical operations performed by the photovoltaic tracking controller to protect the mechanical structure and power generation equipment when a safety risk or communication failure is detected. These typically include adjusting the tracking bracket to a preset safe angle, maintaining the current safe posture, or cutting off the motor drive output. In step S5, this is used to prevent the tracker from suffering wind load impacts or other environmental damage due to continued automatic tracking without monitoring. Normal automatic tracking refers to the regular operating mode where the photovoltaic tracking controller automatically adjusts the bracket angle to track the sun's position based on astronomical algorithms or light sensor data under normal communication conditions. In step S5, this is a service function that needs to be suspended under communication loss protection mode to reduce operational risks in the absence of remote monitoring.
[0028] Understandably, by entering the communication loss protection mode and stopping normal automatic tracking when both communication links are determined to be abnormal in step S3, and simultaneously executing safety protection actions based on local sensor data, autonomous safety control is achieved in the event of a complete communication interruption. This aims to prevent the controller from continuing to execute automatic tracking actions that may cause mechanical damage when it cannot receive remote protection commands. This mechanism deeply links the communication status with the photovoltaic tracking service control, enabling the system to default to a safe posture when it loses external monitoring capabilities. It continuously monitors environmental risks through local sensors and triggers corresponding protection strategies, thereby maintaining the basic safety protection capabilities of the equipment under conditions of no communication and avoiding uncontrollable on-site conditions due to loss of communication.
[0029] Preferably, step S3 includes: When the health status of the LoRa communication link is normal, the LoRa communication link is set as the main communication link and the Zigbee communication link is set as the auxiliary link. The auxiliary link is used for adjacent node status sharing, area broadcasting and maintenance terminal access. When the LoRa communication link is in an abnormal state while the Zigbee communication link is in a normal state, the Zigbee communication link takes over the area to forward or maintain communication, and the photovoltaic tracking controller marks the communication status as LoRa downgrade and records it. When the Zigbee communication link is in an abnormal state while the LoRa communication link is in a normal state, the LoRa communication link is maintained as the primary communication link, and regional forwarding is stopped.
[0030] It should be noted that the auxiliary link refers to the communication channel that plays a supporting role in the dual-link collaborative architecture. When the LoRa communication link is in normal health, the Zigbee communication link assumes an auxiliary role, used for adjacent node status sharing, area broadcasting, and maintenance terminal access. Adjacent node status sharing refers to the process of photovoltaic tracking controllers within the same Zigbee network exchanging operating modes, alarm statuses, and maintenance information through periodic data frames. Area broadcasting refers to sending data frames with a common target area identifier to all nodes in the same area or row via the Zigbee link to achieve local information synchronization. Maintenance terminal access allows field maintenance equipment to establish a temporary connection with the photovoltaic tracking controller via the Zigbee network for local diagnostics and parameter viewing. Area forwarding refers to the process where, when the LoRa backbone link is abnormal, nodes in the Zigbee network receive or transmit control commands or status information from the remote master station relayed through other normal LoRa nodes. Maintenance communication refers to the communication process where field maintenance personnel send maintenance, debugging, or parameter reading instructions to the controller via the Zigbee link through a maintenance terminal. LoRa degradation refers to the controller internally setting the communication status register or flag to a state indicating that the LoRa link is functionally limited. This indicates that the current primary link is unavailable and triggers the secondary link to take on more collaborative tasks. Stop area forwarding means that the controller suspends the transmission or relay of area broadcast frames and status sharing frames to neighboring nodes through the Zigbee link to reduce invalid radio frequency occupation and energy consumption of abnormal links.
[0031] Understandably, after periodically collecting link status parameters of the LoRa and Zigbee communication modules in step S1 and determining the health status of the two links in step S2, step S3 dynamically allocates the communication roles of the two links based on their health status. When the LoRa communication link is in normal health, it is set as the primary communication link to prioritize long-distance backbone communication between the remote master station and the controller. Simultaneously, the Zigbee communication link is set as an auxiliary link, utilizing its short-range networking characteristics to achieve status sharing between adjacent nodes, regional broadcasting, and maintenance terminal access, thus realizing layered complementarity between long-distance coverage and regional collaboration. When the LoRa communication link is abnormal while the Zigbee communication link is normal, the Zigbee communication link is switched to a regional forwarding or maintenance communication takeover state, and the communication status is marked as LoRa degraded. While maintaining local network interconnection, the degraded event is recorded, providing a basis for subsequent status tracing. When the Zigbee communication link fails while the LoRa communication link is functioning normally, the LoRa communication link maintains its primary status and regional forwarding is stopped. This avoids meaningless broadcasting during Zigbee failures that consume radio frequency resources and battery power, ensuring that backbone communication resources are concentrated on remote interaction. Through these three dynamic role allocation strategies, adaptive collaborative division of labor between the two links under different health states is achieved, preventing a single link failure from causing a node to completely lose its communication capability and improving the communication resilience of the photovoltaic tracking controller in complex electromagnetic environments.
[0032] Preferably, determining the health status of the two communication links includes: Collect at least two of the following as link status parameters: heartbeat timeout status, number of consecutive communication failures, signal strength, signal-to-noise ratio, packet loss rate, last effective communication time, node network entry status, command verification result, and communication queue congestion level; Based on the combined logic of the link status parameters, the health status of the communication link is determined as normal, weak connection, abnormal or offline. When the number of consecutive failures exceeds the threshold and the most recent effective communication time exceeds the preset duration, it is judged as abnormal or offline. When the signal strength is detected to be lower than the preset threshold or the packet loss rate increases, it is judged as a weak connection.
[0033] It should be noted that the heartbeat timeout status refers to the communication status indicator that the photovoltaic tracking controller has not received a periodic heartbeat response frame from the remote master station or gateway within a preset time window, reflecting the real-time activity of the underlying link connection. The number of consecutive communication failures refers to the cumulative number of times the controller has continuously sent or received data frames without receiving a valid acknowledgment or response since the last successful communication, used to measure the deterioration trend of link quality. Signal strength refers to the received signal strength indication, expressed in dBm, characterizing the power level of the wireless signal reaching the receiver, used to assess the quality of the link's physical layer transmission conditions. Signal-to-noise ratio (SNR) is the ratio of signal power to noise power, expressed in dB, characterizing the clarity of the signal in the wireless channel, used to determine the link's anti-interference capability. Packet loss rate is the ratio of the number of lost data frames to the total number of transmitted data frames within a specific statistical period, reflecting the link's transmission reliability as a percentage. The last valid communication time refers to the time interval from the current moment back to the last successful completion of a complete data frame transmission and reception and verification, used to assess the current effective connectivity of the link. Node network entry status refers to the registration and association status of a LoRa or Zigbee communication module in the corresponding network, including indicators such as network entry successful, network failure successful, or network entry failed, used to determine whether the link is qualified for communication at the network layer. Command verification result refers to the pass or fail status of the received control command frame after performing cyclic redundancy check or integrity check, used to identify whether data tampering or bit errors have occurred during link transmission. Communication queue congestion level refers to the ratio of the occupied depth of pending data frames in the transmit and receive buffers to the total queue capacity, used to assess the data processing pressure and potential congestion risk of the link at the protocol layer. Threshold refers to a pre-set boundary value used to trigger a state change. Preset duration refers to a pre-set maximum tolerable time interval used to determine whether the link has entered an abnormal or offline state. Preset threshold refers to a pre-set boundary value used to determine whether signal strength or packet loss rate has deteriorated.
[0034] It is understandable that step S1 involves periodically collecting link status parameters from the LoRa and Zigbee communication modules, and step S2 uses a combination of logic based on at least two parameters to determine the link health status. When the number of consecutive failures exceeds a threshold and the most recent effective communication time exceeds a preset duration, the link is determined to be abnormal or offline. When the signal strength is detected to be lower than a preset threshold or the packet loss rate increases, the link is determined to be a weak connection. By replacing single-indicator judgment with multi-indicator combination logic, the link status is avoided from being misjudged as abnormal due to momentary electromagnetic interference or brief obstruction. At the same time, it prevents the link from being actually failed but still misjudged as normal due to occasional noise. This achieves accurate classification of link health status, provides a reliable status basis for the dynamic switching of primary and backup links in step S3, and reduces unnecessary changes in communication roles and system oscillations.
[0035] like Figure 3 As shown, after the photovoltaic tracking controller is powered on, it initializes the communication module and then periodically collects link status parameters such as heartbeat response, signal strength, signal-to-noise ratio, packet loss rate, number of consecutive failures, last effective communication time, network access status, and verification results of the LoRa and Zigbee links. Based on the combinational logic judgment criteria, it evaluates the health status of the two links as normal, weak connection, abnormal, or offline. According to the health status evaluation results, it dynamically selects the LoRa main link, Zigbee takeover link, dual-link cooperative mode, or communication loss protection mode. When both links are abnormal, it stops normal automatic tracking and switches to local safety protection state.
[0036] Preferably, dynamically switching between the primary communication link, the backup communication link, or the communication disconnection protection mode based on the health status includes: When the LoRa communication link is in an abnormal state and the Zigbee communication link is in a normal state, the communication state is marked as LoRa downgraded, and the abnormal state is broadcast to adjacent nodes or regional nodes through the Zigbee communication link in order to receive remote control commands, maintenance commands or regional protection commands forwarded through the Zigbee communication link. When both the LoRa and Zigbee communication links are in an abnormal state, the communication disconnection protection mode is entered, and the execution of unconfirmed, expired, or normal-level remote commands is stopped. Normal automatic tracking, remote parameter updates, and unnecessary timed actions are stopped, and the system is preferentially switched to a preset safe angle, maintained at the current safe angle, or the motor output is locked. In the communication loss protection mode, local sensor data, including wind speed, rain and snow, tilt angle, current, battery status and limit status, are continuously monitored.
[0037] It should be noted that unconfirmed remote commands refer to control instructions that the controller has received but have not yet passed verification, receipt, or execution confirmation; their authenticity and timeliness cannot be guaranteed. Expired remote commands refer to instructions whose timestamp, defined by the validity period field in the control command frame, is earlier than the current local real-time clock time; these are invalid commands. Normal-level remote commands refer to general control instructions other than safety protection commands and shutdown / maintenance commands, such as automatic tracking adjustment and parameter queries. Preset safety angle refers to the safe posture angle of the support stored in the controller's non-volatile memory, typically 0 degrees horizontal or a windproof angle set according to local climate conditions. Maintaining the current safety angle means that the controller maintains the current angular position of the support when communication is lost, and no longer performs tracking actions; this is applicable when the current angle is already within the safe range. Locking motor output means that the controller cuts off the enable signal of the motor drive circuit or shuts off the power output, prohibiting any motor rotation and preventing displacement of the support in an unknown state. Wind speed refers to the ambient airflow speed measured by a wind speed sensor installed on the tracking support or controller housing, used to assess wind load risk. Rain and snow refer to the presence of precipitation detected by rain and snow sensors, used to assess the risk of slippery conditions or snow accumulation. Tilt angle refers to the current angle of inclination of the photovoltaic support relative to the horizontal plane, measured by a tilt sensor, used to determine the deviation between the actual and expected attitude. Current refers to the operating current of the drive motor, measured by a current sensor in the motor drive circuit, used to detect stall or overload. Battery status refers to the comprehensive parameters such as voltage, current, and temperature of the energy storage battery or backup power supply, used to assess power supply capacity. Limit status refers to the position boundary signals triggered by mechanical limit switches or electronic limit sensors, used to prevent the support from rotating beyond its range.
[0038] Understandably, after obtaining the link health status through steps S1 and S2, dynamic switching is performed in step S3. When the LoRa communication link is abnormal and the Zigbee communication link is normal, the controller can receive remote control commands, maintenance commands, or regional protection commands forwarded via the Zigbee network by marking the communication status as LoRa downgraded and broadcasting the abnormal status to adjacent nodes or regional nodes. This maintains regional coordination and indirect control channels when the backbone link is interrupted. When both the LoRa and Zigbee communication links are abnormal, the system enters a communication disconnection protection mode, stopping the execution of unconfirmed, expired, or ordinary level remote commands, stopping normal automatic tracking, remote parameter updates, and unnecessary timed actions. It prioritizes switching to a preset safety angle, maintaining the current safety angle, or locking the motor output, and continuously monitors local sensor data. Through a tiered response mechanism, control accessibility is maintained using the regional network during single link downgrade, and the system state is constrained within a safe range when both links are completely interrupted. This prevents the controller from continuing to operate without receiving remote protection commands, thus avoiding safety risks. At the same time, continuous monitoring by local sensors provides data support for autonomous safety decisions.
[0039] Preferably, step S4 includes: Pre-configure control command fields, including command type, serial number, validity period, permission flag, checksum, target node ID, target area ID, and forwarding hop count; Upon receiving a control command, its validity is verified using the permission flag and the verification code. If the verification fails, the control command is discarded. The sequence number is used for deduplication. If the sequence number of the control command already exists in the processed queue, or the current time exceeds the validity period of the control command, then the control command is discarded. For control commands forwarded via the Zigbee communication module, target matching is determined based on the target node ID or the target region ID. The command is executed if the target matches and the forwarding hop count does not exceed a preset limit; otherwise, it is discarded. When multiple valid control commands are received, arbitration is performed based on the priority determined by the command type, wherein the priority of the safety protection command is higher than the shutdown or maintenance command, and the priority of the shutdown or maintenance command is higher than the automatic tracking command. If the command types have the same priority, the control command with the newer timestamp is selected as the final execution command.
[0040] It should be noted that the command type refers to the code that identifies the service category of the control command, used to distinguish different command types such as security protection, shutdown maintenance, manual control, parameter configuration, automatic tracking, and status query. The sequence number is a unique, incrementing number generated by the command initiator, used to identify a single command issuance and as a basis for deduplication. The validity period is the expiration timestamp carried in the command frame, used to define the legal execution time window of the command. The authorization flag is the code that identifies the authorization level of the command initiator, used to distinguish the command permissions of remote master stations, gateways, maintenance terminals, or regional nodes. The checksum is a cyclic redundancy check value or hash value appended to the end of the command frame, used by the receiving end to verify the integrity of the frame. The target node ID is the identifier of a single execution object specified in the command frame, used to limit the command to be executed only by a specific photovoltaic tracking controller. The target area ID is the identifier of the area execution object specified in the command frame, used to limit the command to be executed by multiple nodes belonging to the same area. The forwarding hop count is the count of the number of times the command frame is relayed through nodes in the Zigbee network, used to limit broadcast storms and loop forwarding. The control command field refers to multiple information units organized at fixed offset positions in the control command data frame, used to carry the command's attributes and execution conditions. The processed queue is a list of recently executed command sequence numbers stored locally by the controller, used to identify and discard duplicate commands. Target matching refers to the process by which the controller compares the target node ID or target region ID in the command frame with its own identifier. The timestamp is the command generation time recorded in the command frame, used to determine the age of commands with the same priority.
[0041] Understandably, step S4 pre-sets control command fields including command type, sequence number, validity period, permission flag, checksum, target node ID, target area ID, and forwarding hop count. Upon receiving a control command from the LoRa or Zigbee communication module, the system sequentially verifies its legitimacy using the permission flag and checksum, deduplicates it by comparing the sequence number with the processed queue, and determines its timeliness by comparing the current time with the validity period. For Zigbee forwarding commands, it matches the target using the target node ID or target area ID and checks the forwarding hop count limit. Finally, it arbitrates based on command type priority and timestamp. Through this multi-layered filtering and arbitration mechanism, conflicts arising from concurrent dual-link transmission or area forwarding, such as duplicate execution, expired commands taking effect, and security commands being overridden by ordinary commands, are eliminated. This ensures the legitimacy and timeliness of the final executed command, guaranteeing the controller's correct response to remote commands in a heterogeneous link environment.
[0042] like Figure 4As shown, when the photovoltaic tracking controller receives a control command through the LoRa or Zigbee communication module, it first extracts the permission flag and checksum from the command frame for legality verification. If the verification fails, the command is discarded. For commands that pass the verification, the sequence number is extracted for deduplication. If the sequence number already exists in the processed queue or the current time has expired, the command is discarded. For commands forwarded via Zigbee, the matching of the target node identifier or target area identifier is further checked, and the forwarding hop count is checked to see if it exceeds the limit. For multiple valid commands that pass the above screening, arbitration is performed based on the priority determined by the command type. Safety protection commands take precedence over shutdown and maintenance commands, and shutdown and maintenance commands take precedence over automatic tracking commands. Under the same priority level, the command with the newest timestamp is selected as the final execution command.
[0043] Preferably, it also includes severe weather protection steps: When a severe weather protection order is received, the priority of the severe weather protection order is set to the highest level; Dual-link broadcasting is performed through the LoRa communication module and the Zigbee communication module. The severe weather protection command includes the disaster type, protection action, command sequence number, release timestamp, validity period, number of repeated broadcasts, and confirmation receipt requirements. When the photovoltaic tracking controller receives a severe weather protection command through either the LoRa communication module or the Zigbee communication module, it executes the corresponding protection action, records the sequence number of the severe weather protection command, and returns a confirmation receipt through an available link. When the photovoltaic tracking controller receives a severe weather protection command with the same serial number again, it will only send a confirmation receipt or continue to forward the command, and will not execute the corresponding protection action. The severe weather protection command has a higher priority than other ordinary control commands, and the execution status of the severe weather protection command is maintained until a disaster relief command or a manual authorization recovery command is received.
[0044] It should be noted that severe weather protection commands refer to emergency safety control instructions generated by remote master stations, weather stations, or gateways for extreme weather conditions such as strong winds, hail, floods, heavy rain, or blizzards. These commands force photovoltaic trackers to perform protective actions to avoid mechanical damage. Dual-link broadcasting refers to simultaneously sending the same command frame via a LoRa long-distance link and a Zigbee regional link to improve command delivery rate. Disaster type refers to the code identifying the current extreme weather category, such as strong winds, hail, floods, heavy rain, or blizzards. Protection action refers to the specific safety operation that the command requires the controller to perform, such as stopping automatic tracking, turning to a preset safe angle, locking motor output, or disabling ordinary command overriding. The release timestamp is the absolute time stamp generated by the command, used to determine the timeliness and order of the command. The number of rebroadcasts refers to the number of rounds the command initiator plans to send the same command frame, used to ensure that unacknowledged nodes can receive the message. The acknowledgment requirement refers to the flag in the command frame indicating whether the receiver needs to return an execution confirmation. The acknowledgment is the response frame returned by the receiver to the initiator after successfully executing the protection action, used to inform that the command has been delivered and executed. Available links refer to LoRa or Zigbee communication channels that are currently in a normal or weak connectivity state. Identical serial numbers refer to serial number codes that are completely identical to those of executed severe weather protection commands, used to identify duplicate commands. Disaster deactivation commands are instructions issued by remote master stations or weather stations to terminate severe weather protection status and restore normal operation. Manually authorized recovery commands are instructions sent by on-site maintenance personnel through maintenance terminals to manually deactivate disaster protection status.
[0045] Understandably, by setting severe weather protection commands to the highest priority and utilizing dual-link broadcasting via LoRa and Zigbee communication modules, the command frame carries the disaster type, protection action, command sequence number, release timestamp, validity period, number of repeat broadcasts, and confirmation receipt requirements. When the controller receives a valid severe weather protection command through either link, it executes the protection action and records the sequence number. A confirmation receipt is then returned via an available link. Upon receiving the same sequence number again, only a receipt is sent or the command is forwarded without further execution, maintaining the execution state until the disaster is resolved or manual authorization is granted. This dual-link redundant broadcasting and deduplication execution mechanism improves the coverage and arrival rate of disaster commands in complex photovoltaic sites, avoids missed protection actions by some nodes due to single-link obstruction or interference, and prevents repeated motor actions caused by multiple broadcasts, ensuring that all trackers synchronously enter a safe state under extreme weather conditions.
[0046] like Figure 5As shown, when severe weather such as strong winds, hail, floods, heavy rain, or blizzards is detected, the control box or remote platform generates a severe weather protection command and sets its priority to the highest level. This command is broadcast via the LoRa gateway on the main link and simultaneously propagated across regional links via the Zigbee coordinator or regional nodes. Upon receiving the command via any link, the photovoltaic tracking controller executes the corresponding protection action and records the sequence number, returning a confirmation receipt via an available link. If some nodes fail to respond within a preset time, the gateway node or adjacent nodes can repeatedly broadcast or forward the command to the unconfirmed area via Zigbee, while the control box broadcasts multiple times via LoRa. For commands with the same sequence number received again, the node only confirms the response or continues forwarding the command, without repeating the protection action.
[0047] Preferably, in the communication loss protection mode, it further includes: Periodically check the recovery status of the communication link; Continuously monitor local sensor data, including wind speed, rain and snow, tilt angle, current, battery status, and limit status; When the local sensor data meets the preset security risk conditions, the local security protection strategy for the security risk conditions is executed first. If an anomaly is detected in the local clock or a critical sensor, the photovoltaic tracking controller is controlled to enter a safety hold state or switch to a preset safety angle, and maintain this state until communication is restored or on-site maintenance confirms the change.
[0048] It should be noted that periodic monitoring of the communication link recovery status refers to the photovoltaic tracking controller sending probe frames at fixed time intervals and listening for responses during the communication disconnection protection mode to determine whether the LoRa or Zigbee link has recovered from an anomaly to a normal or weak connection. Preset safety risk conditions refer to combinations of various sensor thresholds pre-stored in the controller, used to define the critical conditions for triggering local safety protection strategies. Local safety protection strategies refer to the set of safety actions independently decided and executed by the controller based on local sensor data during the communication disconnection protection mode, such as turning to a safe angle during strong winds or cutting off the drive during overcurrent. The local clock refers to the controller's built-in real-time clock, used to provide a local time reference. Critical sensors refer to sensors that directly affect the correctness of safety protection decisions, such as wind speed sensors, tilt sensors, and limit sensors. Safety hold state refers to a conservative operating state that the controller enters when it detects an anomaly in the local clock or critical sensors. In this state, the controller stops automatic tracking, locks the bracket in its current position or turns it to a preset safe angle, and shuts down unnecessary peripherals, awaiting external recovery or manual intervention.
[0049] Understandably, by periodically checking whether the communication link has been restored in the communication loss protection mode and continuously monitoring local sensor data, the local safety protection strategy is executed first when the sensor data meets the preset safety risk conditions. If an anomaly is detected in the local clock or a critical sensor, the system enters a safety hold state or switches to a preset safety angle and maintains that state. Through local autonomous monitoring and hierarchical response mechanisms, in the event of a complete communication interruption and inability to receive remote commands, the controller can independently execute safety strategies based on field environmental data. At the same time, by detecting anomalies in the local clock and critical sensors, it avoids inaccurate protection actions due to time base failure or sensor data errors, maintaining the equipment in a safe and controllable state until communication is restored or maintenance is confirmed.
[0050] Preferably, it further includes communication recovery and state synchronization steps: When it is detected that at least one of the LoRa communication module or the Zigbee communication module has recovered from an abnormal state to a normal or weak connection state, the communication recovery process is triggered. The communication recovery process includes: uploading alarm records during the offline period, the last executed command and its result, the current angle of the photovoltaic tracker, the operating mode, the RTC time, and the communication status; Request parameter version verification from the remote master station and compare the local parameter version with the remote master station parameter version; After the parameter version verification passes, clear or downgrade the communication anomaly alarm and restore the reception of remote control commands; If the local parameter version is inconsistent with the remote master station parameter version, the authorized parameters of the remote master station shall prevail for synchronization, or the system shall enter a state of waiting for manual confirmation.
[0051] It should be noted that the communication recovery and status synchronization steps refer to a series of data replenishment and configuration alignment operations performed by the photovoltaic tracking controller after the communication link recovers from an anomaly, used to eliminate information gaps during offline periods. The communication recovery process refers to the status reporting and parameter verification procedures executed by the controller in a fixed sequence after the link is restored. The offline period refers to the complete time period from when the link enters an abnormal or offline state until effective communication is restored. Alarm logs refer to the event logs stored locally by the controller during the offline period, such as wind speed exceeding limits, current anomalies, and limit switch triggers. The last executed command and execution result refer to the sequence number, type, execution time, and success or failure flag of the last control command executed by the controller before or during offline periods. The operating mode refers to the current control state of the controller, such as automatic tracking, communication loss protection, or safety maintenance. Parameter version verification refers to the process by which the controller requests the current authorized parameter version number from the remote master station and compares it with the locally stored version number. The local parameter version refers to the currently effective parameter configuration version identifier in the controller's non-volatile memory. The remote master station parameter version refers to the latest authorized parameter configuration version identifier currently issued by the remote master station or platform. Authorized parameters refer to configuration data that has been issued by the remote master station and is eligible for validity, including tracking algorithm coefficients, security thresholds, and latitude and longitude information. The "awaiting manual confirmation" status refers to a conservative state where, when the local and remote parameter versions are inconsistent and involve changes to critical security thresholds, the controller pauses automatic synchronization and awaits confirmation from on-site maintenance personnel.
[0052] Understandably, the communication recovery process is triggered when at least one LoRa or Zigbee communication module recovers from an abnormal state to a normal or weakly connected state. This involves uploading offline alarm records, the last executed command and its result, the current angle, operating mode, real-time clock, and communication status. A parameter version verification request is sent to the remote master station, and the local and remote versions are compared. If the verification passes, the communication anomaly alarm is cleared or downgraded, and remote command reception is restored. If the versions are inconsistent, the remotely authorized parameters are used for synchronization, or the system enters a state awaiting manual confirmation. Through status reporting and parameter synchronization mechanisms, the information gap between the remote platform and the local controller is eliminated after communication recovery. This ensures the master station can accurately grasp the offline operating conditions and restore control based on the latest authorized parameters, avoiding malfunctions after recovery due to parameter inconsistencies and achieving a smooth transition before and after communication interruption.
[0053] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0054] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.
Claims
1. A dual wireless communication cooperative control method for a photovoltaic tracking controller, characterized in that, Includes the following steps: S1: Periodically collect the LoRa link status parameters of the LoRa communication module and the Zigbee link status parameters of the Zigbee communication module; S2: Determine the health status of the two communication links based on the LoRa link status parameters and the Zigbee link status parameters respectively; S3: Based on the health status, dynamically switch between the main communication link, the backup communication link, or the communication disconnection protection mode; S4: Deduplicatize, verify, and prioritize the control commands from the LoRa communication module and the Zigbee communication module to determine the final command to be executed; S5: When it is determined that both communication links are abnormal, the communication disconnection protection mode is entered, normal automatic tracking is stopped, and safety protection actions are performed based on local sensor data.
2. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, Step S3 includes: When the health status of the LoRa communication link is normal, the LoRa communication link is set as the main communication link and the Zigbee communication link is set as the auxiliary link. The auxiliary link is used for adjacent node status sharing, area broadcasting and maintenance terminal access. When the LoRa communication link is in an abnormal state while the Zigbee communication link is in a normal state, the Zigbee communication link takes over the area to forward or maintain communication, and the photovoltaic tracking controller marks the communication status as LoRa downgrade and records it. When the Zigbee communication link is in an abnormal state while the LoRa communication link is in a normal state, the LoRa communication link is maintained as the primary communication link, and regional forwarding is stopped.
3. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, Determining the health status of the two communication links includes: Collect at least two of the following as link status parameters: heartbeat timeout status, number of consecutive communication failures, signal strength, signal-to-noise ratio, packet loss rate, last effective communication time, node network entry status, command verification result, and communication queue congestion level; Based on the combined logic of the link status parameters, the health status of the communication link is determined as normal, weak connection, abnormal or offline. When the number of consecutive failures exceeds the threshold and the most recent effective communication time exceeds the preset duration, it is judged as abnormal or offline. When the signal strength is detected to be lower than the preset threshold or the packet loss rate increases, it is judged as a weak connection.
4. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, Based on the health status, dynamic switching between the primary communication link, backup communication link, or communication disconnection protection mode includes: When the LoRa communication link is in an abnormal state and the Zigbee communication link is in a normal state, the communication state is marked as LoRa downgraded, and the abnormal state is broadcast to adjacent nodes or regional nodes through the Zigbee communication link in order to receive remote control commands, maintenance commands or regional protection commands forwarded through the Zigbee communication link. When both the LoRa and Zigbee communication links are in an abnormal state, the communication disconnection protection mode is entered, and the execution of unconfirmed, expired, or normal-level remote commands is stopped. Normal automatic tracking, remote parameter updates, and unnecessary timed actions are stopped, and the system is preferentially switched to a preset safe angle, maintained at the current safe angle, or the motor output is locked. In the communication loss protection mode, local sensor data, including wind speed, rain and snow, tilt angle, current, battery status and limit status, are continuously monitored.
5. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, Step S4 includes: Pre-configure control command fields, including command type, serial number, validity period, permission flag, checksum, target node ID, target area ID, and forwarding hop count; Upon receiving a control command, its validity is verified using the permission flag and the verification code. If the verification fails, the control command is discarded. The sequence number is used for deduplication. If the sequence number of the control command already exists in the processed queue, or the current time exceeds the validity period of the control command, then the control command is discarded. For control commands forwarded via the Zigbee communication module, target matching is determined based on the target node ID or the target region ID. The command is executed if the target matches and the forwarding hop count does not exceed a preset limit; otherwise, it is discarded. When multiple valid control commands are received, arbitration is performed based on the priority determined by the command type, wherein the priority of the safety protection command is higher than the shutdown or maintenance command, and the priority of the shutdown or maintenance command is higher than the automatic tracking command. If the command types have the same priority, the control command with the newer timestamp is selected as the final execution command.
6. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, It also includes severe weather protection measures: When a severe weather protection order is received, the priority of the severe weather protection order is set to the highest level; Dual-link broadcasting is performed through the LoRa communication module and the Zigbee communication module. The severe weather protection command includes the disaster type, protection action, command sequence number, release timestamp, validity period, number of repeated broadcasts, and confirmation receipt requirements. When the photovoltaic tracking controller receives a severe weather protection command through either the LoRa communication module or the Zigbee communication module, it executes the corresponding protection action, records the sequence number of the severe weather protection command, and returns a confirmation receipt through an available link. When the photovoltaic tracking controller receives a severe weather protection command with the same serial number again, it will only send a confirmation receipt or continue to forward the command, and will not execute the corresponding protection action. The severe weather protection command has a higher priority than other ordinary control commands, and the execution status of the severe weather protection command is maintained until a disaster relief command or a manual authorization recovery command is received.
7. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, The communication loss protection mode also includes: Periodically check the recovery status of the communication link; Continuously monitor local sensor data, including wind speed, rain and snow, tilt angle, current, battery status, and limit status; When the local sensor data meets the preset security risk conditions, the local security protection strategy for the security risk conditions is executed first. If an anomaly is detected in the local clock or a critical sensor, the photovoltaic tracking controller is controlled to enter a safety hold state or switch to a preset safety angle, and maintain this state until communication is restored or on-site maintenance confirms the change.
8. The dual wireless communication cooperative control method for a photovoltaic tracking controller according to claim 1, characterized in that, It also includes communication recovery and state synchronization steps: When it is detected that at least one of the LoRa communication module or the Zigbee communication module has recovered from an abnormal state to a normal or weak connection state, the communication recovery process is triggered. The communication recovery process includes: uploading alarm records during the offline period, the last executed command and its result, the current angle of the photovoltaic tracker, the operating mode, the RTC time, and the communication status; Request parameter version verification from the remote master station and compare the local parameter version with the remote master station parameter version; After the parameter version verification passes, clear or downgrade the communication anomaly alarm and restore the reception of remote control commands; If the local parameter version is inconsistent with the remote master station parameter version, the authorized parameters of the remote master station shall prevail for synchronization, or the system shall enter a state of waiting for manual confirmation.