A lighting control system with embedded intelligent control nodes cooperating with wireless networking
Patent Information
- Application Number
- CN202610670777.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-15
- Publication Date
- 2026-08-28
AI Technical Summary
[0002]现有照明控制系统多采用集中式管控模式,控制指令依赖中心平台统一下发,嵌入式控制节点仅能被动执行指令,节点间无法自主建立协同交互关系,局部照明场景的控制响应速度慢,无法适配动态场景的实时调整需求
1.本发明通过嵌入式智能控制节点自主完成邻居扫描、信息交互与本地邻居表构建,结合节点供电方式、运算能力及通信可达性完成代理节点自主选举,快速搭建自适应的自组织网络拓扑,依托表决式协同决策机制将控制请求拆解为子任务并广播表决,结合节点剩余电量、历史协同成效、当前任务负载与通信稳定度完成权重统计,精准选取最优节点执行控制任务,有效提升照明控制任务分配的科学性与执行效率,加快系统整体控制响应速度。
Smart Images

Figure CN122661982A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of lighting control technology, and in particular to a lighting control system that integrates an embedded intelligent control node with wireless networking. Background Technology
[0002] Existing lighting control systems mostly adopt a centralized management and control mode, with control commands relying on a central platform for unified issuance. Embedded control nodes can only passively execute commands, and nodes cannot autonomously establish collaborative interaction relationships. The control response speed for local lighting scenes is slow, and it cannot adapt to the real-time adjustment needs of dynamic scenes. The topology of traditional wireless network lighting nodes is fixed, and after deployment, nodes cannot autonomously scan neighbors and build dynamic networks. Agent nodes lack an autonomous election mechanism, and node management relationships cannot be adaptively adjusted.
[0003] Existing lighting control solutions lack voting-based collaborative decision-making capabilities, cannot select the optimal execution node based on node status, have insufficient rationality in control task allocation, and suffer from low execution success rates. After node failure, topology self-healing cannot be triggered quickly, making it difficult to guarantee network continuity and control stability. Furthermore, the lack of direct collaboration and closed-loop feedback mechanisms between local nodes means that actual and target values cannot be compared promptly after lighting parameter adjustments, and control deviations cannot be quickly corrected. Overall, the intelligent control effect and system robustness fail to meet the requirements for efficient collaborative lighting management. Summary of the Invention
[0004] To achieve the above objectives, the present invention provides a lighting control system that integrates an embedded intelligent control node with a wireless network, characterized in that the system comprises a topology construction module, a voting-based collaborative decision-making module, a local node-to-node direct collaborative control module, and a topology self-healing feedback module, wherein: The topology building module is used to build a local neighbor table by automatically scanning neighbors and exchanging information through a self-organizing network of nodes, with elected agent nodes managing ordinary nodes. The voting-based collaborative decision-making module is used by proxy nodes to break down control requests into sub-tasks and broadcast voting requests. Each ordinary node calculates the voting weight value and returns a response. The proxy node then performs a weighted statistical analysis and sends an execution command to the node with the highest weight to establish a proxy voting-based collaborative decision-making mechanism. The local node direct collaborative control module is used to query neighboring nodes and send collaborative queries when any node detects a trigger event. Based on the returned collaborative suggestions, it generates control decisions so that the source node and neighboring nodes can adjust lighting parameters synchronously to establish a direct collaborative control mechanism between local nodes. The topology self-healing feedback module is used for ordinary nodes to periodically report their status to the agent nodes. The agent nodes then summarize the reports and report them to the management platform. When a node fails, a new agent node is re-elected to achieve topology self-healing. Finally, the execution node adjusts the lighting parameters, collects the actual values and compares them with the target values, and feeds back the deviation to complete the control closed loop.
[0005] In a preferred embodiment, when the topology building module executes the self-organizing network of nodes, with each embedded intelligent control node automatically scanning neighbors, exchanging information, and establishing a local neighbor table, it is specifically used for: Upon completion of deployment, each embedded intelligent control node broadcasts a neighbor discovery request containing its own node identifier, node type, power supply method, and geographic location tag. Upon receiving a neighbor discovery request, the node parses the information in the request and returns a neighbor discovery response containing the aforementioned information to the source node. The source node records the identifier, signal strength, link stability, and most recent communication timestamp of each neighbor node based on the received neighbor discovery response, forming a local neighbor node table.
[0006] In a preferred embodiment, when the topology building module executes the management of ordinary nodes by elected proxy nodes, it is specifically used for: Each embedded intelligent control node determines an initial value for agent suitability based on its own power supply method, computing power, and communication reachability with the external management platform; Each embedded intelligent control node compares its initial suitability value with the initial suitability values of all neighboring nodes in its local neighbor node table. If its own initial suitability value is higher than that of all neighboring nodes, it declares itself to be a proxy node. When multiple nodes simultaneously declare themselves as proxy nodes, they communicate with each other to compare node identifiers and select the node with the best identifier value as the final proxy node, while the remaining nodes revert to being ordinary nodes.
[0007] In a preferred embodiment, when the voting collaborative decision-making module executes the proxy node to break down the control request into sub-tasks and broadcasts the voting request, and each ordinary node calculates the voting weight value and returns a response, it is specifically used for: Ordinary nodes obtain their current remaining power value, historical successful collaboration count, and current task load rate; Ordinary nodes determine the communication reliability factor based on the average signal strength of neighboring nodes related to this voting task recorded in the neighboring node table; Ordinary nodes calculate voting weight values based on remaining power, historical successful collaboration counts, current task load rate, and communication reliability factors.
[0008] In a preferred embodiment, the voting weight value is calculated using the following formula: ; In the formula, For voting weight values, This represents the node's current remaining battery power. The node is at its rated full power. The current task load rate of the node. The maximum allowed task load rate for the node. For communication reliability factor, This serves as a reference scalar value for the communication reliability factor. This represents the number of times a node has successfully collaborated in the past. This represents the total number of times a node has participated in collaboration throughout its history.
[0009] In a preferred embodiment, when the voting-based collaborative decision-making module issues an execution instruction to the node with the highest weight after performing weighted statistics on the proxy nodes to establish a proxy voting-based collaborative decision-making mechanism, it is specifically used for: For each subtask, the proxy node establishes an agreement weight accumulator and a rejection weight accumulator respectively; When the proxy node receives a voting response message, it parses out the voting weight value and execution intention. If the execution intention is to agree, the voting weight value is added to the agree weight accumulator; if the execution intention is to reject, the voting weight value is added to the reject weight accumulator. After all expected response messages have arrived or the timeout has occurred, the proxy node compares the value of the agree weight accumulator with the value of the reject weight accumulator. If the value of the agree weight accumulator is greater than the value of the reject weight accumulator, the subtask is determined to have passed the vote. Select the ordinary node with the largest voting weight value from all voting response messages that return agreement as the execution node, and issue an execution confirmation instruction to the execution node to establish a proxy voting collaborative decision-making mechanism.
[0010] In a preferred embodiment, the local node direct collaboration control module, when performing a query of neighboring nodes and sending a collaboration query, is specifically used for: After detecting the triggered event, the source node reads the identifiers of all neighboring nodes recorded in its local neighbor node table; The source node unicasts a collaborative query message to each neighbor node in its local neighbor node table. The collaborative query message contains the trigger event type and the source node's current control parameters. The source node starts a waiting timer. Before the timer expires, it only receives cooperative response messages from neighboring nodes. After the timer expires, it no longer waits for new responses.
[0011] In a preferred embodiment, the local node direct collaboration control module, when executing the control decision generation based on the returned collaboration suggestions, is specifically used for: The source node parses the brightness adjustment direction and brightness adjustment range suggestions provided by the neighboring nodes from each received collaborative response message; The source node counts the brightness adjustment direction suggestions in all collaborative response messages. If the number of responses agreeing to increase brightness is greater than the number of responses agreeing to decrease brightness, the final direction is determined to be to increase brightness; otherwise, it is to decrease brightness. The source node takes the most frequently occurring brightness adjustment range suggestion in the collaborative response message as the final adjustment range, and combines the final direction with the final adjustment range to generate the final control decision.
[0012] In a preferred embodiment, the topology self-healing feedback module, when executing the periodic reporting of status by ordinary nodes to proxy nodes, the aggregation of status reports by proxy nodes to the management platform, and the re-election of new proxy nodes to achieve topology self-healing, is specifically used for: Ordinary nodes package their current working status data into status messages at preset fixed time intervals and send them via unicast to the agent node to which the ordinary node belongs through the wireless link. The agent node receives status messages sent by all ordinary nodes within its jurisdiction, organizes the working status data in the status messages into a regional status summary, and periodically encapsulates the regional status summary and reports it to the external management platform. If any ordinary node fails to receive an acknowledgment response after sending status messages to its assigned proxy node multiple times, the ordinary node determines that the proxy node has failed, broadcasts the proxy failure notification to all neighbor nodes in its local neighbor node table, and re-triggers the proxy node election process.
[0013] In a preferred embodiment, when the topology self-healing feedback module adjusts the lighting parameters at the final execution node, collects actual values, compares them with target values, and feeds back the deviation to complete the control closed loop, it is specifically used for: The node that finally receives the execution confirmation instruction or the collaborative execution instruction parses the target brightness value contained in the instruction and compares the target brightness value with its own current brightness value. If the two are inconsistent, the target brightness value is written to the local control register and waits for the driver module to read it. After completing the above write operation, the node reads the actual brightness feedback value after execution from the local state cache, compares the actual brightness feedback value with the target brightness value, and generates a comparison result flag. The node encapsulates the comparison result flag along with the original sequence number of the execution instruction into an execution feedback message, and forwards it hop by hop along the reverse path of the instruction issuance until the feedback message returns to the agent node or source node that initially initiated the control instruction. The initiator then updates its maintained node status record based on the feedback message.
[0014] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention enables embedded intelligent control nodes to autonomously complete neighbor scanning, information interaction, and local neighbor table construction. By combining node power supply methods, computing power, and communication reachability, it enables the autonomous election of proxy nodes, quickly building an adaptive self-organizing network topology. Relying on a voting-based collaborative decision-making mechanism, it decomposes control requests into sub-tasks and broadcasts them for voting. By combining the node's remaining power, historical collaborative performance, current task load, and communication stability, it performs weight statistics and accurately selects the optimal node to execute the control task, effectively improving the scientific nature and execution efficiency of lighting control task allocation and accelerating the overall control response speed of the system.
[0015] 2. This invention enables direct collaborative interaction between local nodes, rapidly integrating queries and control suggestions from neighboring nodes when a trigger event occurs, and simultaneously adaptively adjusting lighting parameters. It relies on periodic node status reporting and a proxy failure reselection mechanism to achieve autonomous network topology repair, ensuring continuous and stable system operation. By adjusting lighting parameters at execution nodes, comparing actual operating values with target control values, and providing closed-loop feedback on deviations, it precisely corrects control effects, continuously optimizes lighting control accuracy, and comprehensively enhances the system's intelligent collaborative capabilities, operational robustness, and overall management effectiveness. Attached Figure Description
[0016] Figure 1 This is a system architecture diagram of a lighting control system that integrates an embedded intelligent control node with a wireless network, according to an embodiment of the present invention. The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments belong to some, but not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “said” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.
[0019] Depending on the context, the word "if" or "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."
[0020] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.
[0021] In practice, the server-side equipment deployed in a lighting control system that integrates embedded intelligent control nodes and wireless networking may consist of one or more devices. This type of lighting control system can be implemented as a service instance, a virtual machine, or hardware devices. For example, it can be implemented as a service instance deployed on one or more devices in a cloud node. Simply put, it can be understood as software deployed on a cloud node to provide a lighting control system that integrates embedded intelligent control nodes and wireless networking for various user terminals. Alternatively, it can be implemented as a virtual machine deployed on one or more devices in a cloud node, with application software installed to manage various user terminals. Or, it can also be implemented as a server composed of numerous identical or different types of hardware devices, with one or more hardware devices configured to provide a lighting control system that integrates embedded intelligent control nodes and wireless networking for various user terminals.
[0022] In terms of implementation, an embedded intelligent control node and a wirelessly networked collaborative lighting control system are mutually compatible with each other. Specifically, if the embedded intelligent control node and wirelessly networked collaborative lighting control system is implemented as an application installed on a cloud service platform, then the user terminal acts as a client establishing a communication connection with that application; or if the embedded intelligent control node and wirelessly networked collaborative lighting control system is implemented as a website, then the user terminal acts as a webpage; or if the embedded intelligent control node and wirelessly networked collaborative lighting control system is implemented as a cloud service platform, then the user terminal acts as a mini-program within an instant messaging application.
[0023] like Figure 1 The diagram shown is a system architecture diagram of a lighting control system that integrates an embedded intelligent control node with wireless networking, according to an embodiment of the present invention.
[0024] The embedded intelligent control node and wireless network collaborative lighting control system described in this invention can be set up in a cloud server. In terms of implementation, it can be used as one or more service devices, or as an application installed in the cloud (e.g., a mobile service operator's server, server cluster, etc.), or it can be developed as a website. Depending on the implemented functions, the embedded intelligent control node and wireless network collaborative lighting control system may include a topology construction module, a voting-based collaborative decision-making module, a local node direct collaborative control module, and a topology self-healing feedback module. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, stored in the memory of the electronic device.
[0025] In this embodiment of the invention, in a lighting control system that integrates an embedded intelligent control node and a wireless network, each of the aforementioned modules can be implemented independently and can call other modules. This "calling" can be understood as a module connecting to multiple modules of another type and providing corresponding services to those connected modules. In this embodiment of the invention, the applicable scope of the embedded intelligent control node and wireless network collaborative lighting control system architecture can be adjusted by adding modules and directly calling them without modifying the program code, achieving cluster-based horizontal expansion. This allows for quick and flexible expansion of the embedded intelligent control node and wireless network collaborative lighting control system. In practical applications, the aforementioned modules can be set in the same device or different devices, or they can be set in a virtual device, such as a service instance in a cloud server.
[0026] The following describes, with reference to specific embodiments, the various components and specific workflows of a lighting control system that integrates embedded intelligent control nodes and wireless networking: The topology building module is used to build a local neighbor table by automatically scanning neighbors and exchanging information through a self-organizing network of nodes, with elected agent nodes managing ordinary nodes. In this embodiment of the invention, when the topology building module executes the automatic scanning of neighbors and exchange of information to establish a local neighbor table by each embedded intelligent control node through a self-organizing network of nodes, it is specifically used for: Upon completion of deployment, each embedded intelligent control node broadcasts a neighbor discovery request containing its own node identifier, node type, power supply method, and geographic location tag. Upon receiving a neighbor discovery request, the node parses the information in the request and returns a neighbor discovery response containing the aforementioned information to the source node. The source node records the identifier, signal strength, link stability, and most recent communication timestamp of each neighbor node based on the received neighbor discovery response, forming a local neighbor node table.
[0027] When the topology construction module executes the process of having elected proxy nodes manage ordinary nodes, it is specifically used for: Each embedded intelligent control node determines an initial value for agent suitability based on its own power supply method, computing power, and communication reachability with the external management platform; Each embedded intelligent control node compares its initial suitability value with the initial suitability values of all neighboring nodes in its local neighbor node table. If its own initial suitability value is higher than that of all neighboring nodes, it declares itself to be a proxy node. When multiple nodes simultaneously declare themselves as proxy nodes, they communicate with each other to compare node identifiers and select the node with the best identifier value as the final proxy node, while the remaining nodes revert to being ordinary nodes.
[0028] After completing hardware deployment operations such as fixing the physical location, connecting the power supply line, and assembling the communication antenna, the embedded intelligent control node executes the power-on startup and system initialization process. It sequentially completes hardware function self-test, real-time clock module calibration, wireless communication unit parameter configuration and working channel locking. It initiates full-channel broadcast to all online nodes within the current communication coverage area through its own wireless communication unit. The neighbor discovery request message it sends adopts the standard frame structure uniformly defined by the system. The message fully loads its own unique node identifier, hardware node type, actual power supply method and accurate geographical location tag information.
[0029] Upon receiving a neighbor discovery request message, the node uses a dedicated data parsing unit to extract all information carried in the message, including node identifier, node type, power supply method, and geographic location tag, field by field, according to preset field offsets and data parsing rules. After the information extraction is completed, the node sends a neighbor discovery response message to the source node that initiated the request via a wireless communication unit. The response message also loads the node's own unique node identifier, hardware node type, actual power supply method, and precise geographic location tag information.
[0030] When the source node receives each neighbor discovery response message, it measures and records the signal strength value corresponding to the response in real time through the wireless communication module. The duration of continuous communication without data packet loss within a preset detection period is used as the sole criterion to determine the link stability value. Simultaneously, the source node reads the standard current communication timestamp generated by the node's built-in real-time clock module. The node identifier, measured signal strength, determined link stability, and most recent communication timestamp information of each neighbor node are written into the local non-volatile storage unit in a fixed entry format. After all neighbor information is stored, a complete and usable local neighbor node table is finally generated.
[0031] The embedded intelligent control node collects and identifies the actual type of its own power supply in real time through the built-in hardware detection unit, reads the main frequency parameters, cache capacity, data processing rate and other fixed processing performance parameters of the computing core, and determines whether the communication link is continuously connected and without data packet loss through three-way handshake communication detection with the external management platform. Based on three fixed judgment criteria, namely the preset power supply adaptation standard, computing power level classification standard and communication connectivity compliance requirements, it comprehensively evaluates the working capability of its own adapted agent node, determines and generates a unique initial value of agent suitability.
[0032] Each embedded intelligent control node retrieves the initial proxy suitability value of all neighbor nodes in the generated local neighbor node table from the local non-volatile storage unit. It then compares its own generated initial proxy suitability value with the initial proxy suitability value of each neighbor node one by one. When its own initial proxy suitability value is greater than the initial proxy suitability values of all neighbor nodes after traversing the comparison, it broadcasts an identity declaration message of itself as a proxy node to all nodes within the current communication coverage area through the wireless communication module.
[0033] Simultaneously, multiple devices that have declared themselves as proxy nodes establish a point-to-point bidirectional data transmission link through their wireless communication units, and send each other complete digital codes of their unique node identifiers. All node identifier codes participating in the proxy competition are compared one by one according to a preset ascending numerical sorting standard. The node whose code value meets the optimal judgment condition is determined as the final proxy node. Other devices that have declared themselves as proxy nodes automatically switch their working modes, shut down the proxy node-related functional modules, revert to ordinary nodes, and synchronously update their own node identity identifiers.
[0034] This invention enables embedded intelligent control nodes to autonomously broadcast neighbor discovery requests, interact with node information, and automatically construct a local neighbor node table. It can quickly complete neighbor scanning and information recording, accurately retaining neighbor node identifiers, signal strength, link stability, and communication timestamps. It can build a self-organizing network topology without manual intervention, significantly improving the deployment efficiency and convenience of lighting control networks. Based on node power supply methods, computing power, and communication reachability with external management platforms, an initial agent suitability value is determined, objectively quantifying node agent adaptability. Nodes autonomously compare suitability to complete the initial selection of agent nodes, achieving automated division of network jurisdiction and eliminating reliance on centralized control. When multiple nodes simultaneously elect agents, the final agent node is selected based on node identifiers, effectively avoiding election conflicts and ensuring the uniqueness and fairness of agent node selection. This topology construction method realizes self-organizing node networking and autonomous agent node election, allowing the network topology to adapt to the deployment environment. Agent nodes can stably and efficiently manage ordinary nodes, significantly improving the automation level of network construction, enhancing the stability and robustness of the topology structure, and providing a reliable network foundation for subsequent collaborative decision-making, local control, and topology self-healing.
[0035] The voting-based collaborative decision-making module is used by proxy nodes to break down control requests into sub-tasks and broadcast voting requests. Each ordinary node calculates the voting weight value and returns a response. The proxy node then performs a weighted statistical analysis and sends an execution command to the node with the highest weight to establish a proxy voting-based collaborative decision-making mechanism. In this embodiment of the invention, when the execution proxy node breaks down the control request into sub-tasks and broadcasts the voting request, and each ordinary node calculates the voting weight value and returns a response, the voting collaborative decision-making module is specifically used for: Ordinary nodes obtain their current remaining power value, historical successful collaboration count, and current task load rate; Ordinary nodes determine the communication reliability factor based on the average signal strength of neighboring nodes related to this voting task recorded in the neighboring node table; Ordinary nodes calculate voting weight values based on remaining power, historical successful collaboration counts, current task load rate, and communication reliability factors.
[0036] The formula for calculating the voting weight value is as follows: ; In the formula, For voting weight values, This represents the node's current remaining battery power. The node is at its rated full power. The current task load rate of the node. The maximum allowed task load rate for the node. For communication reliability factor, This serves as a reference scalar value for the communication reliability factor. This represents the number of times a node has successfully collaborated in the past. This represents the total number of times a node has participated in collaboration throughout its history.
[0037] When the voting-based collaborative decision-making module executes the weighted statistics of the proxy nodes and then issues an execution instruction to the node with the highest weight to establish the proxy voting-based collaborative decision-making mechanism, it is specifically used for: For each subtask, the proxy node establishes an agreement weight accumulator and a rejection weight accumulator respectively; When the proxy node receives a voting response message, it parses out the voting weight value and execution intention. If the execution intention is to agree, the voting weight value is added to the agree weight accumulator; if the execution intention is to reject, the voting weight value is added to the reject weight accumulator. After all expected response messages have arrived or the timeout has occurred, the proxy node compares the value of the agree weight accumulator with the value of the reject weight accumulator. If the value of the agree weight accumulator is greater than the value of the reject weight accumulator, the subtask is determined to have passed the vote. Select the ordinary node with the largest voting weight value from all voting response messages that return agreement as the execution node, and issue an execution confirmation instruction to the execution node to establish a proxy voting collaborative decision-making mechanism.
[0038] Ordinary nodes collect the output voltage, current, and remaining capacity data of their own power supply modules in real time through a built-in high-precision power detection unit. After hardware sampling and calibration, they directly obtain the accurate current remaining power value. They retrieve the number of successful lighting collaborative control operations since their online launch from the local non-volatile historical operation record storage unit, accurately obtaining the historical collaborative success count. The core task processing unit counts the sum of the number of currently executing lighting control tasks and the number of tasks waiting to be executed in real time. This statistical value is compared with the maximum number of tasks that the node can handle by factory preset as a percentage to calculate the accurate current task load rate.
[0039] Ordinary nodes select related neighboring nodes from the locally generated neighboring node table according to the lighting control area and communication coverage area corresponding to the current voting task. They read the real-time signal strength values of these related neighboring nodes one by one, sum all the selected signal strength values, and then divide the sum by the total number of selected related neighboring nodes to obtain the average signal strength of neighboring nodes strongly related to the current voting task. The average signal strength is then precisely matched with the three preset communication signal strength judgment benchmarks of the system, and the corresponding communication reliability factor is uniquely determined based on the matching result.
[0040] Ordinary nodes use four core data points—current remaining power, historical successful collaboration count, current task load rate, and communication reliability factor—as the comprehensive criteria for determining node execution capabilities. Strictly following the preset node status comprehensive evaluation rules, the nodes categorize the power supply status, collaboration capability, load status, and communication quality corresponding to the four criteria into fixed levels. The categorized status levels are then standardized and integrated to generate a unique voting weight value that can be used for voting comparison.
[0041] The current remaining power of the node is obtained directly by the built-in high-precision power detection unit through real-time continuous sampling of the actual power data of the power supply module, and after hardware calibration.
[0042] The rated full capacity of the node is based on the standard full capacity value of the power supply module calibrated at the time of node manufacturing, which is a fixed hardware baseline parameter.
[0043] The current task load rate of a node is calculated by the core task processing unit in real time, which counts the total number of currently executing and pending tasks, and then converts this total number into a percentage of the node's preset maximum number of tasks.
[0044] The maximum allowable task load rate of a node is based on the standard value of the task capacity limit rated during the node hardware design phase, which is a fixed hardware constraint parameter.
[0045] The communication reliability factor is uniquely determined by matching the average signal strength of neighboring nodes related to this voting task with the communication signal strength judgment benchmark preset by the system.
[0046] The reference scalar value of the communication reliability factor adopts the communication status baseline value preset during system initialization, which is a unified standard parameter.
[0047] The number of successful node collaborations in history is obtained by reading the cumulative number of successful lighting collaboration operations from the local non-volatile historical operation record storage unit. The total number of times a node has participated in collaborations in history is obtained by reading the cumulative total number of times it has participated in lighting collaboration operations from the local non-volatile historical operation record storage unit.
[0048] The power supply status coefficient is obtained by calculating the ratio of the node's remaining power to its rated full power. The load idle coefficient is obtained by calculating the ratio of the node's current task load to its maximum task load. The communication stability coefficient is obtained by calculating the ratio of the communication reliability factor to the reference scalar value. The collaboration reliability coefficient is obtained by calculating the ratio of the number of historical successful collaborations to the total number of collaborations. The final calculation result is obtained by multiplying the above four coefficients in sequence.
[0049] The final calculation result can comprehensively reflect the node's real-time power supply status, remaining task carrying capacity, wireless communication stability and historical collaborative execution performance. It can uniquely determine the node's comprehensive ability level to perform this voting task, providing a precise and unique basis for the proxy node to scientifically select the optimal execution node.
[0050] For each independent subtask after the control request is broken down, the proxy node creates an independent agree weight accumulator and a reject weight accumulator in its local high-speed data storage area. The agree weight accumulator is specifically used to record the total weight value of agreeing to execute the corresponding subtask, and the reject weight accumulator is specifically used to record the total weight value of rejecting to execute the corresponding subtask.
[0051] After receiving the standard voting response message transmitted by the ordinary node through the wireless communication module, the proxy node calls the local dedicated data parsing unit to extract the voting weight value and execution intention information encapsulated in the message field by field according to the preset message format. When the execution intention is determined to be agreed, the extracted voting weight value is added to the agreed weight accumulator for real-time numerical superposition. When the execution intention is determined to be rejected, the extracted voting weight value is added to the rejected weight accumulator for real-time numerical superposition.
[0052] The proxy node starts a high-precision waiting timer unit with a preset fixed duration. When the timer unit reaches the preset duration, or when all expected voting response messages have been received, the final cumulative value of the agree weight accumulator is extracted and directly compared with the final cumulative value of the reject weight accumulator. When the cumulative value of the agree weight accumulator is greater than the cumulative value of the reject weight accumulator, the voting result of the current subtask is officially confirmed as passed.
[0053] The proxy node iterates through all voting response messages that indicate agreement to execute, extracts the voting weight value corresponding to each message, and performs a full comparison of the values. It then locks down the ordinary node with the largest voting weight value and officially sets it as the subtask execution node. The proxy node then sends a standardized execution confirmation instruction to the execution node through a dedicated wireless communication channel, thus completing the construction and official activation of the proxy voting collaborative decision-making mechanism.
[0054] This invention calculates voting weights using multi-dimensional parameters, comprehensively quantifying the real-time power supply status, historical collaborative reliability, task carrying capacity, and communication stability of ordinary nodes, making the assessment of node execution capabilities more objective and accurate. The proxy node breaks down control requests into sub-tasks and initiates voting, refining the control process and improving the parallelism of task processing. Combined with the cumulative statistical analysis of agree and disagreement weights, the voting results of sub-tasks can be objectively determined, avoiding decision-making bias from a single node. Selecting the optimal execution node based on voting weights allocates control tasks to nodes with the best status, significantly improving the execution efficiency and success rate of lighting control commands. The proxy voting collaborative decision-making mechanism achieves decentralized task scheduling, reducing reliance on centralized management and improving system fault tolerance and anti-interference capabilities. The combination of weighted statistics and optimal execution makes control decisions fairer and more reasonable, dynamically adjusting task allocation according to the real-time status of nodes, ensuring more timely lighting control response and more stable operation, comprehensively improving the intelligence level and control effectiveness of the system's collaborative decision-making.
[0055] The local node direct collaborative control module is used to query neighboring nodes and send collaborative queries when any node detects a trigger event. Based on the returned collaborative suggestions, it generates control decisions so that the source node and neighboring nodes can adjust lighting parameters synchronously to establish a direct collaborative control mechanism between local nodes. In this embodiment of the invention, the local node direct collaboration control module, when performing a query of neighboring nodes and sending a collaboration query, is specifically used for: After detecting the triggered event, the source node reads the identifiers of all neighboring nodes recorded in its local neighbor node table; The source node unicasts a collaborative query message to each neighbor node in its local neighbor node table. The collaborative query message contains the trigger event type and the source node's current control parameters. The source node starts a waiting timer. Before the timer expires, it only receives cooperative response messages from neighboring nodes. After the timer expires, it no longer waits for new responses.
[0056] When the inter-node direct collaborative control module executes the control decision generation based on the returned collaborative suggestions, it is specifically used for: The source node parses the brightness adjustment direction and brightness adjustment range suggestions provided by the neighboring nodes from each received collaborative response message; The source node counts the brightness adjustment direction suggestions in all collaborative response messages. If the number of responses agreeing to increase brightness is greater than the number of responses agreeing to decrease brightness, the final direction is determined to be to increase brightness; otherwise, it is to decrease brightness. The source node takes the most frequently occurring brightness adjustment range suggestion in the collaborative response message as the final adjustment range, and combines the final direction with the final adjustment range to generate the final control decision.
[0057] The source node uses its integrated multi-functional sensing and detection units, such as illuminance monitoring, human body sensing, and scene triggering, to monitor changes in the external lighting environment and the operating status of internal nodes in real time. When the monitored parameter values match the system's preset illuminance threshold, human body presence judgment conditions, or scene switching trigger conditions, it retrieves the generated local neighbor node table from the local non-volatile storage unit and accurately reads the unique node identification information of all neighbor nodes recorded in the table, field by field, according to the fixed data format in the table.
[0058] The source node reads the identifier of each independent neighbor node from the local neighbor node table and sends standardized collaborative query messages to the corresponding neighbor nodes one by one through the point-to-point wireless unicast communication link. The collaborative query message is encapsulated in a system-unified frame structure and carries complete lighting control parameter information such as the specific type of the trigger event, the trigger time stamp, and the current lighting brightness and output power of the source node.
[0059] The source node calls the built-in high-precision real-time timing module and writes the system's preset fixed waiting time parameter into the timing module control register. After the timing module starts timing, the source node only opens a dedicated wireless communication port to receive data from neighboring nodes. This port only receives standard cooperative response messages from neighboring nodes. When the timing module's timing value reaches the preset fixed waiting time, the source node immediately closes the dedicated communication port and stops receiving all new cooperative response messages.
[0060] The source node uses a local dedicated data parsing unit to precisely disassemble each received collaborative response message field by field according to the preset message field parsing rules. It extracts the brightness adjustment direction suggestions and brightness adjustment range suggestions fed back by the corresponding neighbor nodes from the valid data segment of the message, and stores the two types of suggestions in the local high-speed temporary data cache in an orderly manner according to the node identifier correspondence.
[0061] The source node uses a local dedicated statistical counting unit to traverse and count each of the brightness adjustment direction suggestions in the temporary data buffer. It accumulates the total number of responses agreeing to increase brightness and the total number of responses agreeing to decrease brightness. The two total counts are then directly compared. If the total number of responses agreeing to increase brightness is greater than the total number of responses agreeing to decrease brightness, the final brightness adjustment direction is determined to be increase brightness. If the comparison condition is not met, the final brightness adjustment direction is determined to be decrease brightness.
[0062] The source node records and categorizes the specific values of all brightness adjustment range suggestions in the temporary data buffer through a local dedicated frequency statistics unit. It counts the total number of times each range value appears in all suggestions in real time, determines the range value with the most occurrences as the final adjustment range, and combines the determined final brightness adjustment direction and final adjustment range into standardized information to generate the final control decision that is directly executed by the lighting driver module.
[0063] This invention enables direct collaborative control between local nodes, allowing for rapid retrieval of neighbor node information and targeted sending of collaborative queries after a triggered event, eliminating the need for intermediary nodes or management platforms and significantly reducing lighting control response time. Unicasting of collaborative query messages and receiving responses within a preset timeframe ensures precise information exchange between neighbor nodes, guaranteeing the effectiveness and timeliness of collaborative communication. Statistical fusion of brightness adjustment suggestions from neighbor nodes determines the adjustment direction through quantity comparison and the adjustment magnitude through frequency of occurrence, ensuring lighting control decisions align with multi-node collaborative consensus and better suit the actual lighting scenario requirements. Local direct collaboration enables synchronized adjustment of lighting parameters between the source node and neighboring nodes, avoiding sudden changes in local illumination or uneven brightness, improving the consistency and comfort of lighting effects. This module breaks free from centralized management, enabling local autonomous collaborative decision-making by nodes, enhancing the system's distributed control capabilities, simplifying control processes, reducing communication overhead, making lighting control more flexible and efficient, and comprehensively enhancing the system's real-time response and scenario adaptability.
[0064] The topology self-healing feedback module is used for ordinary nodes to periodically report their status to the agent nodes. The agent nodes then summarize the reports and report them to the management platform. When a node fails, a new agent node is re-elected to achieve topology self-healing. Finally, the execution node adjusts the lighting parameters, collects the actual values and compares them with the target values, and feeds back the deviation to complete the control closed loop.
[0065] In this embodiment of the invention, the topology self-healing feedback module is specifically used for: periodically reporting the status of ordinary nodes to proxy nodes, the proxy nodes summarizing the reports and reporting them to the management platform, and re-electing new proxy nodes when a node fails to achieve topology self-healing. Ordinary nodes package their current working status data into status messages at preset fixed time intervals and send them via unicast to the agent node to which the ordinary node belongs through the wireless link. The agent node receives status messages sent by all ordinary nodes within its jurisdiction, organizes the working status data in the status messages into a regional status summary, and periodically encapsulates the regional status summary and reports it to the external management platform. If any ordinary node fails to receive an acknowledgment response after sending status messages to its assigned proxy node multiple times, the ordinary node determines that the proxy node has failed, broadcasts the proxy failure notification to all neighbor nodes in its local neighbor node table, and re-triggers the proxy node election process.
[0066] When the topology self-healing feedback module adjusts lighting parameters, collects actual values, compares them with target values, and feeds back the deviation at the final execution node to complete the control closed loop, it is specifically used for: The node that finally receives the execution confirmation instruction or the collaborative execution instruction parses the target brightness value contained in the instruction and compares the target brightness value with its own current brightness value. If the two are inconsistent, the target brightness value is written to the local control register and waits for the driver module to read it. After completing the above write operation, the node reads the actual brightness feedback value after execution from the local state cache, compares the actual brightness feedback value with the target brightness value, and generates a comparison result flag. The node encapsulates the comparison result flag along with the original sequence number of the execution instruction into an execution feedback message, and forwards it hop by hop along the reverse path of the instruction issuance until the feedback message returns to the agent node or source node that initially initiated the control instruction. The initiator then updates its maintained node status record based on the feedback message.
[0067] Ordinary nodes collect various operational status data in real time, such as remaining battery power, wireless signal strength, task load status, lighting output parameters, and hardware operating conditions, at fixed time intervals preset during system initialization, through their integrated operational status acquisition units. All collected operational status data are combined into a standard status message by adding node identifiers, data check bits, and timestamps according to the system's unified message encapsulation rules. The status message is then sent to the agent node to which the ordinary node is pre-bound via a point-to-point wireless unicast communication link.
[0068] The agent node receives all status messages sent by ordinary nodes within its jurisdiction through a dedicated wireless communication receiving unit. It then calls the local data processing unit to classify and collect the working status data in all status messages according to the node identifier and status type, and unify the format to form a regional status summary containing the operating information of all nodes in the region. After adding the platform communication identifier to the regional status summary according to the system's preset reporting time period, the message is encapsulated and reported to the external centralized lighting management platform through an external wired or wireless communication channel.
[0069] Each time a regular node sends a status message to its home agent node, it opens a dedicated acknowledgment response receiving port and starts a short-term waiting timer. If it fails to receive a standard acknowledgment response message from the agent node after sending a system-preset number of status messages, the regular node confirms that the agent node is in a failed state based on the no-response judgment rules through its built-in status judgment unit. It then sends an agent failure notification carrying the failed agent identifier to all neighbor nodes recorded in its local neighbor node table through the full-channel wireless broadcast unit. At the same time, it automatically triggers a preset agent node election process to complete the autonomous repair and reconstruction of the network topology.
[0070] The node that finally receives the execution confirmation command or collaborative execution command uses its local dedicated command parsing unit to completely disassemble the command data content according to the command frame structure, accurately extracts information such as the target brightness value, command type, and original sequence number encapsulated within the command, and obtains its own current output actual brightness value in real time through photoelectric sampling and hardware calibration by the high-precision lighting brightness acquisition unit. The target brightness value is directly compared with the current actual brightness value. If the target brightness value is not equal to the current actual brightness value, the target brightness value is written to the node's local dedicated control register to ensure that the lighting drive module can normally obtain the target brightness value and perform lighting brightness adjustment actions according to a fixed reading cycle.
[0071] After the node completes the operation of writing the target brightness value into the local control register, it collects the actual lighting brightness data after the brightness adjustment is completed through the real-time lighting brightness detection unit. After calibrating, the data is stored in the local high-speed status cache area. The actual brightness feedback value after the adjustment is executed is read from the local status cache. The actual brightness feedback value is accurately compared with the target brightness value. Based on the comparison result, a comparison result flag is generated to indicate whether the adjustment meets the standard.
[0072] The node combines the generated comparison result flag with the unique original sequence number carried in the execution command, adds a forwarding identifier and a check bit according to the system's preset feedback message encapsulation rules, and generates a standard execution feedback message. Following the reverse transmission path of the command, the node forwards the execution feedback message hop by hop through the wireless communication unit until the execution feedback message is completely transmitted to the agent node or source node that initially initiated the control command. After receiving the execution feedback message, the initiator updates its own maintained records of node brightness, execution result, running status, etc., based on the brightness feedback information and execution status in the message.
[0073] The topology self-healing feedback module of this invention enables routine reporting of node operating status and comprehensive visual monitoring. Ordinary nodes report their working status to proxy nodes at fixed intervals. The proxy nodes summarize the regional status into a regional summary and synchronize it to the management platform, allowing the system to monitor node operating conditions throughout the process, improving control transparency and traceability. When a proxy node fails, ordinary nodes can autonomously determine and broadcast a failure notification, quickly triggering a new round of proxy election to complete autonomous network topology repair, avoiding system paralysis caused by single-point failures, and significantly improving network robustness and operational continuity. Simultaneously, the module constructs a complete lighting control closed loop. After the executing node adjusts the brightness according to instructions, it collects the actual brightness in real time and compares it with the target value, accurately generating a feedback identifier and transmitting it back along the original path. The initiator updates the node status record accordingly, achieving real-time correction of control deviations. This mechanism makes lighting parameter adjustment more precise, ensuring continuous control effectiveness and completely eliminating execution deviations. The combination of topology self-healing and closed-loop feedback not only ensures dynamic stability of the network topology but also optimizes the entire control execution process, reducing system maintenance costs and comprehensively improving the reliability, stability, and intelligent control level of the lighting control system.
[0074] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.
[0075] This application embodiment can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.
[0076] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.
Claims
1. A lighting control system that integrates an embedded intelligent control node with wireless networking, characterized in that, The system includes a topology construction module, a voting-based collaborative decision-making module, a local node direct collaborative control module, and a topology self-healing feedback module, wherein: The topology building module is used to build a local neighbor table by automatically scanning neighbors and exchanging information through a self-organizing network of nodes, with elected agent nodes managing ordinary nodes. The voting-based collaborative decision-making module is used by proxy nodes to break down control requests into sub-tasks and broadcast voting requests. Each ordinary node calculates the voting weight value and returns a response. The proxy node then performs a weighted statistical analysis and sends an execution command to the node with the highest weight to establish a proxy voting-based collaborative decision-making mechanism. The local node direct collaborative control module is used to query neighboring nodes and send collaborative queries when any node detects a trigger event. Based on the returned collaborative suggestions, it generates control decisions so that the source node and neighboring nodes can adjust lighting parameters synchronously to establish a direct collaborative control mechanism between local nodes. The topology self-healing feedback module is used for ordinary nodes to periodically report their status to the agent nodes. The agent nodes then summarize the reports and report them to the management platform. When a node fails, a new agent node is re-elected to achieve topology self-healing. Finally, the execution node adjusts the lighting parameters, collects the actual values and compares them with the target values, and feeds back the deviation to complete the control closed loop.
2. The lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, When the topology building module executes the self-organizing network of nodes, with each embedded intelligent control node automatically scanning neighbors, exchanging information, and building a local neighbor table, it is specifically used for: Upon completion of deployment, each embedded intelligent control node broadcasts a neighbor discovery request containing its own node identifier, node type, power supply method, and geographic location tag. Upon receiving a neighbor discovery request, the node parses the information in the request and returns a neighbor discovery response containing the aforementioned information to the source node. The source node records the identifier, signal strength, link stability, and most recent communication timestamp of each neighbor node based on the received neighbor discovery response, forming a local neighbor node table.
3. The lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, When the topology construction module executes the process of having elected proxy nodes manage ordinary nodes, it is specifically used for: Each embedded intelligent control node determines an initial value for agent suitability based on its own power supply method, computing power, and communication reachability with the external management platform; Each embedded intelligent control node compares its initial suitability value with the initial suitability values of all neighboring nodes in its local neighbor node table. If its own initial suitability value is higher than that of all neighboring nodes, it declares itself to be a proxy node. When multiple nodes simultaneously declare themselves as proxy nodes, they communicate with each other to compare node identifiers and select the node with the best identifier value as the final proxy node, while the remaining nodes revert to being ordinary nodes.
4. The lighting control system with embedded intelligent control node and wireless networking collaboration as described in claim 1, characterized in that, The voting-based collaborative decision-making module, when the execution agent node breaks down the control request into sub-tasks and broadcasts the voting request, and each ordinary node calculates the voting weight value and returns a response, is specifically used for: Ordinary nodes obtain their current remaining power value, historical successful collaboration count, and current task load rate; Ordinary nodes determine the communication reliability factor based on the average signal strength of neighboring nodes related to this voting task recorded in the neighboring node table; Ordinary nodes calculate voting weight values based on remaining power, historical successful collaboration counts, current task load rate, and communication reliability factors.
5. A lighting control system with embedded intelligent control node and wireless networking collaboration as described in claim 4, characterized in that, The formula for calculating the voting weight value is as follows: ; In the formula, For voting weight values, This represents the node's current remaining battery power. The node is at its rated full power. The current task load rate of the node. The maximum allowed task load rate for the node. For communication reliability factor, This serves as a reference scalar value for the communication reliability factor. This represents the number of times a node has successfully collaborated in the past. This represents the total number of times a node has participated in collaboration throughout its history.
6. A lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, When the voting-based collaborative decision-making module executes the weighted statistics of the proxy nodes and then issues an execution command to the node with the highest weight to establish the proxy voting-based collaborative decision-making mechanism, it is specifically used for: For each subtask, the proxy node establishes an agreement weight accumulator and a rejection weight accumulator respectively; When the proxy node receives a voting response message, it parses out the voting weight value and execution intention. If the execution intention is to agree, the voting weight value is added to the agree weight accumulator; if the execution intention is to reject, the voting weight value is added to the reject weight accumulator. After all expected response messages have arrived or the timeout has occurred, the proxy node compares the value of the agree weight accumulator with the value of the reject weight accumulator. If the value of the agree weight accumulator is greater than the value of the reject weight accumulator, the subtask is determined to have passed the vote. Select the ordinary node with the largest voting weight value from all voting response messages that return agreement as the execution node, and issue an execution confirmation instruction to the execution node to establish a proxy voting collaborative decision-making mechanism.
7. A lighting control system with embedded intelligent control node and wireless networking collaboration as described in claim 1, characterized in that, The local node direct collaboration control module, when performing a query of neighboring nodes and sending a collaboration query, is specifically used for: After detecting the triggered event, the source node reads the identifiers of all neighboring nodes recorded in its local neighbor node table; The source node unicasts a collaborative query message to each neighbor node in its local neighbor node table. The collaborative query message contains the trigger event type and the source node's current control parameters. The source node starts a waiting timer. Before the timer expires, it only receives cooperative response messages from neighboring nodes. After the timer expires, it no longer waits for new responses.
8. A lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, When the inter-node direct collaborative control module executes the control decision generation based on the returned collaborative suggestions, it is specifically used for: The source node parses the brightness adjustment direction and brightness adjustment range suggestions provided by the neighboring nodes from each received collaborative response message; The source node counts the brightness adjustment direction suggestions in all collaborative response messages. If the number of responses agreeing to increase brightness is greater than the number of responses agreeing to decrease brightness, the final direction is determined to be to increase brightness; otherwise, it is to decrease brightness. The source node takes the most frequently occurring brightness adjustment range suggestion in the collaborative response message as the final adjustment range, and combines the final direction with the final adjustment range to generate the final control decision.
9. A lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, The topology self-healing feedback module, when executing the periodic reporting of status from ordinary nodes to proxy nodes, the aggregation of status reports by proxy nodes to the management platform, and the re-election of new proxy nodes to achieve topology self-healing when a node fails, is specifically used for: Ordinary nodes package their current working status data into status messages at preset fixed time intervals and send them via unicast to the agent node to which the ordinary node belongs through the wireless link. The agent node receives status messages sent by all ordinary nodes within its jurisdiction, organizes the working status data in the status messages into a regional status summary, and periodically encapsulates the regional status summary and reports it to the external management platform. If any ordinary node fails to receive an acknowledgment response after sending status messages to its assigned proxy node multiple times, the ordinary node determines that the proxy node has failed, broadcasts the proxy failure notification to all neighbor nodes in its local neighbor node table, and re-triggers the proxy node election process.
10. A lighting control system with embedded intelligent control node and wireless networking as described in claim 1, characterized in that, When the topology self-healing feedback module adjusts lighting parameters, collects actual values, compares them with target values, and feeds back the deviation at the final execution node to complete the control closed loop, it is specifically used for: The node that finally receives the execution confirmation instruction or the collaborative execution instruction parses the target brightness value contained in the instruction and compares the target brightness value with its own current brightness value. If the two are inconsistent, the target brightness value is written to the local control register and waits for the driver module to read it. After completing the above write operation, the node reads the actual brightness feedback value after execution from the local state cache, compares the actual brightness feedback value with the target brightness value, and generates a comparison result flag. The node encapsulates the comparison result flag along with the original sequence number of the execution instruction into an execution feedback message, and forwards it hop by hop along the reverse path of the instruction issuance until the feedback message returns to the agent node or source node that initially initiated the control instruction. The initiator then updates its maintained node status record based on the feedback message.