A bluetooth lamp remote control system

Abstract

The present application relates to the technical field of Bluetooth lamps, and more particularly to a Bluetooth lamp remote control system, which first acquires real-time running data of the lamp and dynamically divides control domains; secondly, combines lighting targets and domain data to perform Mesh networking grouping decomposition; then, performs dynamic brightness compensation estimation according to regional brightness nodes and decomposition data; finally, constructs a control dependency graph based on compensation data, quantifies networking conflicts, and generates collaborative control instructions. This method improves network adaptability through dynamic domain division, ensures precise and smooth lighting through brightness compensation, and solves the problems of channel congestion and timing disorder under high concurrency by means of the dependency graph and conflict quantification mechanism, thereby realizing efficient and stable remote dynamic collaborative control of large-scale lighting systems.

Description

Technical Field

[0001] This invention relates to the field of Bluetooth lighting technology, and more particularly to a Bluetooth lighting remote control system. Background Technology

[0002] With the rapid development of IoT technology, smart lighting systems have been widely applied in smart cities, large commercial complexes, and industrial plants. Bluetooth Mesh self-organizing network protocol, with its advantages of low power consumption, high reliability, and many-to-many communication, has become one of the mainstream technologies for large-scale node lighting control. However, in complex deployment environments involving hundreds or thousands of lighting nodes, existing collaborative control methods still face significant technical bottlenecks.

[0003] First, traditional control strategies often employ static grouping or simple broadcast flooding mechanisms, lacking dynamic awareness of the coupling relationship between the real-time operating status of lighting fixtures and physical space. This results in rigid control domain partitioning, making it difficult to adapt to local faults or topology changes, leading to wasted network resources and delayed control response. Second, when facing complex lighting target adjustment needs (such as scene switching and constant illuminance maintenance), existing solutions often ignore the timing dependence and multi-hop delay characteristics of signal transmission in mesh networks, lacking dynamic compensation mechanisms based on real-time brightness node data. This easily leads to local brightness fluctuations or over-adjustment, affecting lighting quality. More critically, when a large number of nodes concurrently execute control commands, the lack of refined conflict quantification and dependency graph construction methods easily leads to network conflicts such as channel congestion, packet collisions, and disordered command execution order. Existing solutions typically rely on retransmission mechanisms or simple priority queues, failing to address resource contention at its root, resulting in a significant decrease in system real-time performance and stability under high load.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a Bluetooth lighting remote control system, which aims to solve the technical problems of existing Bluetooth Mesh lighting control technology, which lacks dynamic perception and accurate compensation mechanisms, resulting in rigid control domain division, large fluctuations in brightness adjustment, and severe channel conflicts in large-scale node concurrent scenarios, making it difficult to meet the requirements of high real-time performance and stability in collaborative scheduling.

[0006] To achieve the above objectives, the present invention provides a Bluetooth lighting remote control system, the system comprising: The control domain partitioning module is used to acquire real-time operating data of multi-node lighting fixtures and partition the lighting fixture control domains based on the real-time operating data of multi-node lighting fixtures to obtain lighting fixture control domain data. The network decomposition module is used to acquire lighting target adjustment data; it performs Bluetooth Mesh network group decomposition on the lighting target adjustment data and the luminaire control domain data to obtain network decomposition data; The brightness compensation module is used to acquire the brightness node data of the current area and perform dynamic brightness compensation estimation based on the current area brightness node data and network decomposition data to obtain brightness compensation estimation data. The collaborative control module is used to construct a control dependency graph based on the brightness compensation estimation data to obtain control dependency graph data; to quantify network conflicts based on the control dependency graph data to obtain luminaire conflict quantification data; and to generate collaborative control based on the luminaire conflict quantification data to obtain luminaire collaborative control data, so as to realize remote dynamic collaborative control of multi-node lighting fixtures.

[0007] Optionally, the luminaire control domain division, to obtain luminaire control domain data, includes: Based on the real-time operation data of multi-node lighting fixtures, the node-communication link coupling relationship is analyzed to obtain node-link coupling matrix data; Acquire lighting control timing data, and calculate the adjustment coordination frequency based on the lighting control timing data to obtain adjustment coordination frequency data; Based on the node-link coupling matrix data and the adjustment coordination frequency data, a Bluetooth Mesh twin domain is constructed to obtain the lighting control domain data.

[0008] Optionally, the Bluetooth Mesh twin domain construction, to obtain the lighting control domain data, includes: Based on the node-link coupling matrix data and the adjustment and coordination frequency data, virtual networking coverage feature extraction and dynamic signal transmission feature extraction are performed to obtain virtual networking coverage feature data and dynamic signal transmission feature data, respectively. Based on the virtual network coverage characteristic data and dynamic signal transmission characteristic data, a twin coupling graph is generated from the node-link coupling matrix data to obtain twin coupling graph data; The virtual-real mismatch region detection is performed on the twin coupling graph data to obtain virtual-real calibration graph data. The virtual-real mismatch region detection includes signal strength mismatch detection, communication abnormal interruption detection, and node permission dynamic verification detection. By injecting operating condition time series constraints into the virtual and real calibration map data, time series constraint map data is obtained; The control connectivity subdomains are extracted from the time-series constraint diagram data to obtain the lighting control domain data.

[0009] Optionally, the Bluetooth Mesh network group decomposition to obtain network decomposition data includes: Mesh multicast topology partitioning is performed on lighting target adjustment data and luminaire control domain data to obtain topology partitioning data; Based on the topology partitioning data, lighting optical attributes and key brightness nodes are extracted to obtain lighting optical attribute data and key brightness node data, respectively. Based on the lighting optical attribute data and key brightness node data, the topology partitioning data is processed to control the temporal dependency, resulting in temporal dependency data. Dynamic dependency graphs are constructed based on temporal dependency data to obtain network decomposition data.

[0010] Optionally, the dynamic brightness compensation estimation, which yields brightness compensation estimation data, includes: Based on the current brightness node data and network decomposition data, the arrival time sequence of ambient light is superimposed to obtain the time sequence superimposed data. Illumination intensity kernel distribution is calculated based on time-series superimposed data to obtain local brightness concentration intensity data; Based on the current brightness node data, the regional carrying capacity and the luminaire response cycle are calculated to obtain the carrying capacity data and response cycle data, respectively. Based on the carrying capacity data and response period data, dynamic brightness compensation time extrapolation is performed on the local brightness concentration intensity data to obtain brightness compensation estimation data.

[0011] Optionally, the construction of the control dependency graph, resulting in control dependency graph data, includes: Based on the current brightness node data and network decomposition data, a network grouping control dependency subgraph is constructed to obtain control dependency subgraph data; Dynamic weighting is performed on the control dependency subgraph data based on the brightness compensation estimation data to obtain dynamic weighted graph data. Directed acyclic control optimization is performed based on dynamic weight graph data to obtain control dependency graph data.

[0012] Optionally, the network conflict quantization, to obtain lighting conflict quantization data, includes: Based on the control dependency graph data, the communication channel resource occupancy is mapped to obtain resource occupancy data; Conflicting tuples are extracted from resource usage data to obtain conflicting tuple data. Signal overlap tension quantization is performed based on the conflict tuple data to obtain the luminaire conflict quantization data.

[0013] Optionally, the signal overlap tension quantization to obtain luminaire conflict quantization data includes: The non-steady-state signal overlap and temporal occupancy intersection are calculated based on the conflict tuple data, and the dynamic boundary overlap data and temporal occupancy intersection data are obtained respectively. Based on the dynamic boundary overlap data and the timing occupancy intersection data, the shared channel node contention is analyzed to obtain node contention analysis data; Based on the node competition analysis data, signal tension propagation modeling is performed to obtain tension propagation matrix data; Based on the tension propagation matrix data, high-priority task gravity compensation control is performed to obtain quantitative data on lighting conflict.

[0014] Optionally, the collaborative control generation, which obtains luminaire collaborative control data to achieve remote dynamic collaborative control of multi-node lighting fixtures, includes: Conflict core clusters are identified based on the quantification data of lighting conflicts, and conflict core cluster data is obtained. Based on the conflict core cluster data, Mesh networking-level control sequence optimization is performed to obtain optimized control sequence data; Based on the control sequence optimization data, lighting collaborative control data is generated to drive the Bluetooth Mesh control platform to perform remote dynamic collaborative control of multi-node lighting fixtures.

[0015] Optionally, generating lighting collaborative control data based on control sequence optimization data includes: encapsulating the control sequence optimization data into a broadcast message conforming to the Bluetooth Mesh protocol standard, and transmitting it to the lighting node corresponding to the corresponding lighting control domain data via multi-hop transmission through relay nodes.

[0016] In this invention, a Bluetooth-enabled remote control system for lighting fixtures dynamically divides the control domain of the lighting fixtures by acquiring real-time operating data, breaking the rigid limitations of traditional static grouping. This method can flexibly adjust the control boundary according to the actual online status, location distribution, and load of the lighting fixtures, effectively isolating the impact range of local faults, reducing invalid broadcast flooding, significantly reducing the communication overhead of the Mesh network, and improving the network robustness in a large-scale node environment. A dynamic brightness compensation estimation mechanism is introduced, combining the current area brightness node data with the network decomposition data for closed-loop correction. This not only eliminates brightness deviations caused by node aging, ambient light changes, or signal attenuation, but also ensures a smooth transition of illuminance changes during scene switching or target adjustment, avoiding flickering or over-adjustment, and greatly improving the user's visual experience and lighting quality. Furthermore, an innovative control dependency graph is constructed and network conflict quantification is performed, transforming the complex concurrent control problem into a quantifiable optimization problem. By identifying and resolving potential timing conflicts and resource contention before generating control data, packet collisions and out-of-order command execution are effectively avoided, significantly improving the real-time response speed and execution reliability of the system in multi-node concurrent control scenarios. This method organically integrates domain partitioning, network decomposition, brightness compensation, and conflict resolution to form a complete closed-loop collaborative control logic. It not only achieves a leap from single-point control to full-domain collaboration but also maximizes the lifespan of battery-powered nodes (by reducing retransmissions and invalid operations) while ensuring lighting effects, providing efficient and stable technical support for intelligent lighting management in complex scenarios such as smart cities and large venues. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the structure of the first embodiment of the Bluetooth lighting remote control system of the present invention; Figure 2 This is a flowchart illustrating the specific steps involved in obtaining lighting control domain data in the Bluetooth lighting remote control system of the present invention. Figure 3 This is a flowchart illustrating the specific steps involved in obtaining network decomposition data in the Bluetooth lighting remote control system of the present invention.

[0018] 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

[0019] 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 are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] In one embodiment, such as Figure 1 As shown, a Bluetooth lighting remote control system is provided, the system comprising: The control domain division module 10 is used to acquire real-time operating data of multi-node lighting fixtures and divide the lighting fixture control domain according to the real-time operating data of multi-node lighting fixtures to obtain lighting fixture control domain data. The control domain partitioning module can be a processing unit used to dynamically generate logical control areas based on the real-time operating status of the lighting fixtures. It can dynamically adjust control boundaries according to the online status, location distribution, and load of the lighting fixtures, isolating the impact of local faults and reducing invalid broadcast flooding. In this embodiment, the control domain partitioning module can receive real-time operating data from multiple lighting fixtures and dynamically group the nodes using clustering or graph segmentation algorithms. Furthermore, the control domain partitioning module can output lighting fixture control domain data for use by the network decomposition module; it relies on real-time operating data from multiple lighting fixtures as input. Real-time operating data from multiple lighting fixtures can be a multi-dimensional information set reflecting the current operating status of the lighting fixtures, which can be used to provide a basis for dynamic control domain partitioning. In an exemplary embodiment, the real-time operating data from multiple lighting fixtures can include, but is not limited to, one or more of the following: lighting fixture online status data, lighting fixture spatial location data, and lighting fixture load status data.

[0021] Acquiring real-time operating data of multi-node lighting fixtures can be achieved by periodically polling or triggering events through a Bluetooth Mesh network to collect the status information of each fixture. Furthermore, this data can be obtained by periodically reporting online status and load information using a heartbeat mechanism, or by aggregating data from neighboring fixtures through proxy nodes and transmitting it back uniformly, thus providing real-time input for dynamic control domain partitioning. Lighting fixture control domain partitioning based on real-time operating data can be achieved through dynamic clustering or graph segmentation based on node status, location, and load similarity. In a specific embodiment, lighting fixture control domain partitioning based on real-time operating data can be achieved by using spectral clustering algorithms to partition domains based on node connectivity and physical distance, or by triggering local domain reconstruction based on online status change detection using a sliding window, thereby forming a logical control region that adapts to topology changes and reducing broadcast overhead.

[0022] The network decomposition module 20 is used to acquire lighting target adjustment data; and to perform Bluetooth Mesh network group decomposition on the lighting target adjustment data and the luminaire control domain data to obtain network decomposition data. The network decomposition module can be a processing unit that combines lighting target adjustment requirements with dynamic control domain structure to logically group the Bluetooth Mesh network. It can provide a network structure foundation adapted to the current topology and target for subsequent refined control. In this embodiment, the network decomposition module can parse the scene or illuminance requirements in the lighting target adjustment data and perform logical mapping and subnetting in conjunction with the luminaire control domain data. Further, the network decomposition module can receive luminaire control domain data and lighting target adjustment data, and output network decomposition data for use by the brightness compensation module. The lighting target adjustment data can be lighting scene or illuminance target parameters set by the user or system, which can be used to drive the network decomposition module to perform target-oriented logical grouping. In a specific embodiment, the lighting target adjustment data can include, but is not limited to, scene switching instructions, constant illuminance target values, and area dimming ratios, among others. The luminaire control domain data can be the logical grouping results output by the control domain division module, which can be used to characterize the dynamic control area to which each luminaire belongs in the current network. For example, the luminaire control domain data can include, but is not limited to, one or more of the following: master control domain identifier, slave node list, and intra-domain communication path information.

[0023] Acquiring lighting target adjustment data can be achieved by receiving lighting adjustment requests from the user interface, timing policies, or external systems (such as building automation). Furthermore, this can be done by parsing JSON-formatted scene configuration files or listening to illuminance target messages in MQTT topics, thus clearly defining the control target to drive subsequent networking and compensation logic. Bluetooth Mesh networking grouping and decomposition of the lighting target adjustment data and luminaire control domain data can be performed by mapping target requirements to a dynamic control domain structure to generate logical subnet configurations. In an exemplary embodiment, Bluetooth Mesh networking grouping and decomposition of the lighting target adjustment data and luminaire control domain data can be achieved by matching target scenes by domain and assigning an independent subnet ID to each domain, or by decomposing cross-domain targets into tasks and generating multi-subnet collaborative instruction templates, thereby enabling target-oriented network logic slicing and supporting fine-grained control.

[0024] The brightness compensation module 30 is used to acquire the brightness node data of the current area, and to perform dynamic brightness compensation estimation based on the brightness node data of the current area and the network decomposition data to obtain brightness compensation estimation data. The brightness compensation module can be a processing unit that corrects brightness deviations based on real-time illumination feedback and network structure. It can eliminate brightness deviations caused by changes in ambient light, device aging, or signal attenuation, ensuring a smooth illumination transition. In this embodiment, the brightness compensation module can fuse current area brightness node data with network decomposition data and calculate the compensation amount through a closed-loop feedback model. Further, the brightness compensation module can receive network decomposition data and current area brightness node data, and output brightness compensation estimation data for use by the collaborative control module. The current area brightness node data can be actual illuminance feedback collected by light sensors deployed within the area or by the built-in photosensitive unit of the luminaire, which can be used to detect the deviation between the actual brightness and the target value. In a specific embodiment, the current area brightness node data can include, but is not limited to, one or more of ambient light intensity data, luminaire output luminous flux feedback, and brightness reference values ​​of neighboring nodes. The network decomposition data can be a logical subnet configuration generated after joint analysis of the lighting target and control domain structure, which can be used to guide the topology basis for subsequent brightness compensation and command scheduling. For example, the network decomposition data can include, but is not limited to, one or more of subnet node sets, subnet communication priorities, and subnet target illuminance mappings.

[0025] Obtaining current area brightness node data can be achieved by reading real-time illumination values ​​from deployed light sensors or light fixture nodes with photosensitive capabilities. Furthermore, obtaining current area brightness node data can be achieved by uploading data through dedicated ambient light sensor nodes or by periodically sampling and reporting using photodiodes built into the light fixtures, thus providing a measured basis for brightness deviation detection. Dynamic brightness compensation estimation based on current area brightness node data and network decomposition data can be performed by combining measured brightness with target illuminance to calculate the required compensation amount for each node. In an exemplary embodiment, dynamic brightness compensation estimation based on current area brightness node data and network decomposition data can be achieved by using a PID controller to dynamically adjust the compensation coefficient based on error, or by using historical aging curves and current output to calculate and correct theoretical deviations, thereby eliminating brightness deviations and ensuring a smooth illumination transition. The brightness compensation estimation data can be the brightness adjustment amount for each node generated after closed-loop correction, which can be used as the basic input for constructing dependency relationships in the collaborative control module.

[0026] The collaborative control module 40 is used to construct a control dependency graph based on the brightness compensation estimation data to obtain control dependency graph data; to perform network conflict quantification based on the control dependency graph data to obtain luminaire conflict quantification data; and to generate collaborative control based on the luminaire conflict quantification data to obtain luminaire collaborative control data, so as to realize remote dynamic collaborative control of multi-node lighting fixtures.

[0027] The collaborative control module is a processing unit that performs dependency modeling and conflict prediction on concurrent control commands and generates the final execution command. It avoids data packet collisions and command out-of-order delivery, improving real-time performance and execution reliability under high concurrency. In this embodiment, the collaborative control module can construct a control dependency graph based on brightness compensation estimation data, quantify resource and timing conflicts, and generate a conflict-free command sequence. Further, the collaborative control module can receive brightness compensation estimation data and output lighting collaborative control data to the Bluetooth Mesh network execution layer. The control dependency graph data can be a directed graph structure that explicitly expresses the timing and resource dependencies between control commands, providing structured input for conflict quantification. For example, the control dependency graph data can include, but is not limited to, one or more of node execution order constraints, channel occupancy time slot allocation, and power adjustment dependency chains. The lighting conflict quantification data can be the result of a numerical evaluation of potential network conflicts, guiding the collaborative control generation stage to avoid resource contention. For example, the lighting conflict quantification data can include, but is not limited to, one or more of channel contention strength indicators, command timing overlap, and multi-hop path interference probability. The lighting fixture collaborative control data can be a final executable control instruction set generated after conflict resolution, which can be used to realize remote dynamic collaborative control of multi-node lighting fixtures. For example, the lighting fixture collaborative control data can include, but is not limited to, one or more of the following: conflict-free instruction sequences, dimming commands with time tags, and domain broadcast optimization strategies.

[0028] Constructing a control dependency graph based on brightness compensation estimation data can involve converting compensation commands for each node into directed graph nodes with dependencies. Further, this construction can be achieved by using luminaires as nodes, establishing edge relationships if they share channels or have multi-hop paths, or by setting command execution order constraints based on compensation magnitude and response time, thus explicitly modeling the timing and resource constraints between commands. Network conflict quantification based on the control dependency graph data can involve numerically evaluating potential resource contention and timing overlaps in the graph. In a specific embodiment, network conflict quantification based on the control dependency graph data can be achieved by calculating the channel occupancy time overlap corresponding to each edge, or by evaluating the buffer contention probability on multi-hop forwarding paths, thereby identifying high-risk conflict points to support pre-emptive resolution. Cooperative control generation based on luminaire conflict quantification data can optimize command scheduling order and transmission parameters while satisfying dependency constraints. For example, collaborative control based on lighting conflict quantification data can be generated by using topological sorting to generate an acyclic execution sequence and inserting idle time slots for avoidance, or by merging or batching instructions on high-conflict subgraphs, thereby generating conflict-free and reliably executable final control instructions.

[0029] Taking the lighting control of the atrium in a large commercial complex as an example, the Bluetooth lighting remote control system in this embodiment can receive holiday mode switching instructions (lighting target adjustment data). The control domain division module dynamically divides the system into 5 control domains based on the online status and location information of all current lighting fixtures. The network decomposition module maps the high-brightness target at the top of the atrium and the gradually darkening target around it to each domain, generating network decomposition data. The brightness compensation module, combined with the feedback from the light sensors deployed on the ground (current area brightness node data), discovers that the west side is too bright due to the reflection of the curtain wall, and calculates the negative compensation amount accordingly. The collaborative control module constructs a control dependency graph based on the compensation data, identifies that the top lighting fixture group has a high risk of conflict due to sharing a relay node, and after conflict quantification, sends the instructions in two batches at off-peak times, ultimately achieving flicker-free and over-adjustment-free holiday atmosphere lighting.

[0030] In one embodiment, the luminaire control domain is divided to obtain luminaire control domain data, including: Based on the real-time operation data of multi-node lighting fixtures, the node-communication link coupling relationship is analyzed to obtain node-link coupling matrix data; Acquire lighting control timing data, and calculate the adjustment coordination frequency based on the lighting control timing data to obtain adjustment coordination frequency data; Based on the node-link coupling matrix data and the adjustment coordination frequency data, a Bluetooth Mesh twin domain is constructed to obtain the lighting control domain data.

[0031] The node-communication link coupling analysis can be an analytical process that extracts the dynamic correlation characteristics between nodes and their communication links from real-time operating data of multi-node lighting fixtures. This analysis can be used to generate a structured matrix reflecting physical connectivity, communication quality, and latency characteristics to accurately characterize the network dynamic topology. In this embodiment, the node-communication link coupling analysis can construct mapping weights between nodes and links based on operating data such as signal strength, hop count, packet loss rate, and adjacency relationships. The node-link coupling matrix data can be a structured matrix characterizing the coupling strength and quality between each lighting fixture node and its dependent communication links, providing dynamic network topology features for Bluetooth Mesh twin domain construction. Analyzing the node-communication link coupling relationship based on real-time operating data of multi-node lighting fixtures can extract the quality, stability, and latency characteristics of communication links between nodes from the real-time operating data to construct a coupling matrix. In an exemplary embodiment, this operation can be achieved by calculating link coupling strength based on RSSI and LQI weighted averages, or by using multi-hop forwarding path logs to infer the node's dependence on the link, thereby accurately characterizing the network dynamic topology and providing a communication-level basis for control domain partitioning.

[0032] Lighting control timing data can be a dataset recording the execution time sequence of historical control commands and their response behaviors. This data can be used to support the calculation of adjustment coordination frequency and reflect the control linkage patterns between lighting fixtures. In one specific embodiment, lighting control timing data may include, but is not limited to, dimming command timestamp sequences, response delay logs, and collaborative trigger event records. Adjustment coordination frequency data can be a statistical indicator quantifying the frequency of collaborative execution of different lighting fixtures in control tasks. This data can be used to identify subsets of high-frequency linked lighting fixtures and guide semantic control domain partitioning. For example, adjustment coordination frequency data may include, but is not limited to, statistics on co-dimming frequency, scene switching synchronization rate, and regional linkage tightness scores. Obtaining lighting control timing data can involve extracting the command execution time and response behavior sequence of the lighting fixtures from system logs or control history records. Further, this operation can be performed by extracting timestamped dimming commands from the central controller's command queue or by obtaining historical operation logs stored locally on the lighting fixtures, thus providing a behavioral data basis for coordination frequency calculation. Calculating the adjustment coordination frequency based on lighting control timing data can involve statistically analyzing the frequency at which different lighting fixtures are simultaneously controlled within the same or similar time periods. In one specific embodiment, this operation can be achieved by using a sliding time window to count the number of co-occurrences and normalizing them to a frequency value, or by calculating the coupling strength of the luminaire control behavior based on mutual information or correlation coefficients, thereby identifying luminaire groups with high coordination requirements and supporting semantic domain segmentation.

[0033] The construction of a Bluetooth Mesh twin domain can be a virtual logical control domain generated by integrating communication topology and control behavior semantics. This can be used to form a dynamic control boundary that combines network state awareness and cooperative behavior understanding, replacing traditional static grouping. In this embodiment, the Bluetooth Mesh twin domain construction can jointly input node-link coupling matrix data and adjustment coordination frequency data into a clustering or graph neural network model to output a semantic control domain. The Bluetooth Mesh twin domain can be a virtual logical control unit constructed driven by both communication topology and control behavior semantics. It can be used as the basis for generating lighting control domain data, achieving adaptive, low-conflict control boundary partitioning. The construction of the Bluetooth Mesh twin domain based on node-link coupling matrix data and adjustment coordination frequency data can be achieved by fusing communication topology features and control behavior features, generating a semantic control domain through clustering or graph embedding methods. In an exemplary embodiment, this operation can be achieved by concatenating the two types of data into a node feature vector and inputting it into a spectral clustering algorithm for domain partitioning, or by constructing a heterogeneous graph neural network to jointly optimize the objective function of communication connectivity and behavioral consistency, thereby generating a dynamic control boundary that combines network state awareness and cooperative behavior understanding.

[0034] Taking the optimization of zoned lighting in an industrial plant as an example, the Bluetooth remote control system for lighting fixtures in this embodiment can collect real-time operating data of lighting fixtures at each workstation, analyze the significant degradation of link quality in some areas due to metal structure obstruction, and form a node-link coupling matrix; at the same time, analysis of historical data reveals that lighting fixtures in assembly line areas A and B are often synchronously dimmed during shift changes, calculating the high frequency of adjustment coordination; the Bluetooth Mesh twin domain construction module integrates these two types of information, classifying areas A and B into the same twin domain, even though their physical distance is far but their behavior is highly coordinated, while the warehouse area, which has a fragile link but independent behavior, is separated into a separate domain; the final generated lighting control domain data effectively avoids cross-weak link broadcasting and ensures that commands in the coordinated area are sent synchronously, reducing retransmissions and delays.

[0035] In one embodiment, the Bluetooth Mesh twin domain is constructed to obtain lighting control domain data, including: Based on the node-link coupling matrix data and the adjustment and coordination frequency data, virtual networking coverage feature extraction and dynamic signal transmission feature extraction are performed to obtain virtual networking coverage feature data and dynamic signal transmission feature data, respectively. The virtual networking coverage feature data can be a set of features extracted from the node-link coupling matrix and the adjustment coordination frequency, reflecting the coverage capability of the logical control domain over physical nodes. This data can be used to characterize the spatial and functional coverage integrity and redundancy of virtual packets. In an exemplary embodiment, the virtual networking coverage feature data may include, but is not limited to, one or more of the following: intra-domain node coverage rate, cross-domain boundary ambiguity, and logical networking connectivity density. The dynamic signal transmission feature data can be a set of features characterizing the time-varying properties of multi-hop signal transmission in a Bluetooth Mesh network. This data can be used to reflect dynamic communication behaviors such as channel delay, throughput bottlenecks, and path stability. For example, the dynamic signal transmission feature data may include, but is not limited to, one or more of the following: multi-hop cumulative delay characteristics, path throughput fluctuation indicators, and forwarding node load sensitivity.

[0036] Based on node-link coupling matrix data and adjusted coordination frequency data, virtual network coverage feature extraction can be performed. This can involve analyzing the coverage integrity and boundary clarity of logical groups for nodes, generating coverage feature vectors. Furthermore, this operation can be achieved by calculating the mean and variance of node coordination frequency within each potential domain as a coverage cohesion index, or by evaluating the ambiguity of cross-domain node affiliation based on graph cut theory and generating boundary uncertainty features, thereby quantifying the coverage effectiveness of virtual networks in both spatial and functional dimensions. Based on node-link coupling matrix data and adjusted coordination frequency data, dynamic signal transmission feature extraction can be performed. This can involve modeling dynamic transmission characteristics such as latency accumulation and throughput fluctuations on multi-hop paths. In a specific embodiment, this operation can be achieved by fitting path delay distribution using historical forwarding logs and extracting statistical moment features, or by measuring end-to-end throughput change rate through online probe packets and encoding it as edge attributes, thus characterizing the time-varying behavior of signals transmitted in the mesh network and supporting high-fidelity twin modeling.

[0037] Based on the virtual network coverage characteristic data and dynamic signal transmission characteristic data, a twin coupling graph is generated from the node-link coupling matrix data to obtain twin coupling graph data; The twin coupling graph data can be an enhanced network graph structure generated by fusing virtual network coverage features and dynamic signal transmission features. It can be used as a high-fidelity digital mapping between the physical network and control semantics, supporting subsequent mismatch detection and constraint injection. In this embodiment, the twin coupling graph data can be constructed by weighting edges or node attributes with feature vectors based on the original node-link coupling matrix to create a semantically enhanced graph. Generating a twin coupling graph from the node-link coupling matrix data based on virtual network coverage feature data and dynamic signal transmission feature data can involve using the two types of features as additional attributes for nodes or edges, reconstructing the original coupling matrix into a semantic graph. Furthermore, this operation can be achieved by constructing a heterogeneous graph using coverage features as node embedding vectors and signal transmission features as edge weights, or by using a graph neural network encoder to fuse multi-source features into a unified graph representation, thereby generating a high-fidelity network twin model that integrates communication, coverage, and behavioral semantics.

[0038] The virtual-real mismatch region detection is performed on the twin coupling graph data to obtain virtual-real calibration graph data. The virtual-real mismatch region detection includes signal strength mismatch detection, communication abnormal interruption detection, and node permission dynamic verification detection. The virtual-physical mismatch zone can be a set of regions where there is a significant deviation between the physical network state and the twin coupled graph model. It can be used to identify abnormal or changed areas requiring calibration, ensuring consistency between the model and reality. In a specific embodiment, the virtual-physical mismatch zone may include, but is not limited to, one or more of the following: signal strength mismatch zone, communication anomaly interruption zone, and node permission inconsistency zone. Signal strength mismatch detection can be a detection process that compares the predicted signal strength of the twin model with the measured value to identify deviations. It can be used to detect link quality degradation caused by environmental changes or equipment aging. Communication anomaly interruption detection can identify abnormal situations where the physical link is suddenly interrupted but the model still marks it as connected. It can be used to promptly detect node offline or link breakage, avoiding the issuance of invalid commands. Dynamic node permission verification detection can verify whether the current node still has the permission status to participate in a specific control domain. It can be used to prevent miscontrol due to permission changes (such as maintenance lockout, role switching). Furthermore, dynamic node permission verification detection may include, but is not limited to, one or more of the following: role token validity verification, real-time matching of domain access policies, and security key lifecycle checks.

[0039] Detecting virtual-real mismatch regions in twin coupled graph data can involve comparing the predicted state of the graph model with the actual physical network state to identify three types of mismatch regions. In one specific embodiment, this operation can be achieved by periodically polling the signal strength of key nodes and comparing it with the predicted values ​​in the graph to trigger mismatch alarms, or by listening for communication failure events and backtracking the corresponding path connectivity assumptions in the graph to locate the interruption zone. This proactively detects deviations between the model and reality, ensuring the accuracy of the twin graph. The virtual-real calibration graph data can be a twin coupled graph corrected after virtual-real mismatch region detection, eliminating deviations between the model and the physical state. It can be used to provide a calibrated graph structure consistent with the actual network state for subsequent constraint injection. For example, the virtual-real calibration graph data can include, but is not limited to, one or more of the following: mismatch region mask graph, link weight dynamic correction graph, and topology graph after permission filtering.

[0040] By injecting operating condition time series constraints into the virtual and real calibration map data, time series constraint map data is obtained; Operating condition timing constraint injection can be a process of embedding time-sensitive requirements from lighting service logic into a calibration graph. This can be used to ensure that the control domain partitioning conforms to the timing rhythm and response window of the actual application scenario. In an exemplary embodiment, operating condition timing constraint injection may include, but is not limited to, one or more of the following: scene switching synchronization window injection, dimming ramp time constraint embedding, and multi-region linkage timing alignment marking. Performing operating condition timing constraint injection on virtual and real calibration graph data can encode the time logic (such as scene switching rhythm) in the lighting service into timing constraints for nodes or edges in the graph. Further, this operation can be achieved by adding maximum allowable instruction interval constraints to high-frequency collaborative node pairs, or by injecting synchronization waiting window markings on the scene switching path, thereby ensuring that the control domain partitioning conforms to the time-sensitive requirements of the actual application. The timing constraint graph data can be a calibration graph after fusing operating condition timing constraints, containing communication, behavior, and timing semantics, and can be used as the structural basis for the final control connectivity subdomain extraction. Exemplarily, the timing constraint graph data may include, but is not limited to, one or more of the following: control dependency graph with time windows, timing-topology joint graph, and response consistency constraint graph.

[0041] The control connectivity subdomains are extracted from the time-series constraint diagram data to obtain the lighting control domain data.

[0042] The control connectivity subdomain can be a logical control unit extracted from the timing constraint graph that satisfies communication connectivity, behavioral coordination, timing consistency, and legal permissions. It can be used as the output data for the lighting control domain, ensuring high cohesion within the domain and low interference between domains. Extracting the control connectivity subdomain from the timing constraint graph data can be achieved by extracting a cohesive subgraph as the control domain, provided that communication connectivity, legal permissions, and timing consistency are satisfied. Furthermore, this operation can be implemented by using a constrained community detection algorithm for subdomain partitioning, or by using a depth-first search traversal to retain only connected components that satisfy all timing and permission constraints, thereby generating a highly cohesive, low-conflict, and executable final lighting control domain.

[0043] Taking the switching of nighttime street lighting modes in smart cities as an example, the Bluetooth lighting remote control system in this embodiment can be as follows: The system constructs a twin coupling graph based on historical data, but detects that some road sections experience a sudden drop in signal strength due to water accumulation (signal strength mismatch) during a rainstorm night. At the same time, a maintenance vehicle temporarily locks a group of street light permissions (node ​​permissions are inconsistent). The virtual-real mismatch area detection module identifies the area and generates a virtual-real calibration graph. Then, the working condition timing constraint of "nighttime mode switching must be completed within 30 seconds" is injected. Finally, the extracted control connectivity subdomain automatically excludes the locked nodes and merges the weak signal area into the nearest strong relay domain to ensure that the switching command is reliably delivered within the timing window, avoiding delayed lighting or over-adjustment in some road sections.

[0044] In one embodiment, Bluetooth Mesh network group decomposition yields network decomposition data including: Mesh multicast topology partitioning is performed on the lighting target adjustment data and the luminaire control domain data to obtain topology partitioning data.

[0045] Mesh multicast topology partitioning can be a process of combining lighting target adjustment data with luminaire control domain data to generate a logical multicast subnet structure adapted to the multi-hop communication characteristics of Bluetooth Mesh. This can be used to construct physically connected and logically efficient multicast paths, avoiding network-wide flooding and reducing communication redundancy. In an exemplary embodiment, Mesh multicast topology partitioning can be based on the spatial adjacency of the luminaire control domain and the regional consistency of the lighting target, using graph traversal or minimum spanning tree algorithms to generate multicast trees or multicast clusters. Mesh multicast topology partitioning of the lighting target adjustment data and luminaire control domain data can combine the spatial requirements of the lighting target with the dynamic boundaries of the control domain to generate logical subnets optimized for multicast efficiency. For example, this operation can be achieved by using luminaires within the control domain that meet the target illuminance requirements as seeds to expand outwards and generate a minimum multicast tree, or by matching the control domain to the geometry of the lighting area and dividing it into multiple parallel multicast clusters, thereby reducing invalid broadcasts and improving multicast transmission efficiency. Topology partitioning data can be the logical subnet structure information output by Mesh multicast topology partitioning, which can be used as the basic input for subsequent optical attribute extraction and key node identification. In a specific embodiment, topology partitioning data may include, but is not limited to, multicast root node identifier, subnet member node list, multi-hop forwarding path configuration, etc.

[0046] Based on the topology partitioning data, lighting optical attributes and key brightness nodes are extracted to obtain lighting optical attribute data and key brightness node data, respectively.

[0047] The extraction of lighting optical attributes can be a process of abstracting key optical parameters affecting lighting quality from a topological subnet, providing a physical-space constraint basis for brightness compensation and timing control. In this embodiment, the extraction of lighting optical attributes can be calculated and derived based on the luminaire installation location, beam angle, color temperature specifications, and illuminance superposition model. Extracting lighting optical attributes based on topology partitioning data can be done by calculating the regional illumination characteristics based on the physical deployment parameters and optical specifications of the luminaires within the subnet. For example, this operation can be achieved by estimating the illuminance superposition effect using a ray tracing model or by calculating regional uniformity through the integral of the luminaire light distribution function, thereby providing a physical basis for subsequent compensation and timing control.

[0048] Key brightness node extraction can be the process of identifying the most representative luminaire nodes for regional illuminance perception from a topological subnet. This can be used to determine the core observation points in closed-loop feedback, reducing data acquisition overhead and improving feedback representativeness. In an exemplary embodiment, key brightness node extraction can be based on characteristics such as node location (e.g., edge, center), whether it integrates a light sensor, and load sensitivity. Extracting key brightness nodes based on topology partitioning data can involve selecting nodes with high representativeness for regional illuminance from the subnet nodes. For example, this operation can be achieved by selecting nodes located at the edge of the lighting area and without obstruction as key nodes, or by prioritizing smart luminaires with integrated photosensitive elements as feedback sources, thereby focusing feedback acquisition and improving closed-loop control efficiency. Lighting optical attribute data can be a multi-dimensional parameter set describing the characteristics of light distribution within the subnet, which can be used to model regional illuminance consistency and dynamic response characteristics. In a specific embodiment, lighting optical attribute data may include, but is not limited to, spatial attenuation coefficient of light intensity, color temperature uniformity index, and lighting coverage overlap. Key brightness node data can be luminaire nodes identified as key observation points and their status information, which can be used as the core feedback source for dynamic brightness compensation and conflict prediction. In this embodiment, key brightness node data may include, but is not limited to, edge region representative nodes, high-load and easily aging nodes, and nodes with built-in ambient light sensors.

[0049] Based on the lighting optical attribute data and key brightness node data, the topology partitioning data is processed to control the temporal dependency, resulting in temporal dependency data.

[0050] The control timing dependency processing can be a process of integrating illumination optical attribute data and key brightness node data to perform timing modeling of the instruction execution order in the topology partitioning data. This can be used to explicitly characterize multi-hop delay, signal propagation order, and execution coupling relationships, ensuring the coordination of control instructions in the time dimension. In an exemplary embodiment, the control timing dependency processing can calculate the time window for instruction activation and dependency constraints based on the number of hops between nodes, link quality, and optical response inertia. Performing control timing dependency processing on the topology partitioning data based on illumination optical attribute data and key brightness node data can be a comprehensive analysis of optical response characteristics and key node states to deduce the time dependency relationship of instruction execution for each node. For example, this operation can be achieved by allocating an early trigger time offset to high-latency paths or setting a synchronization execution window for strongly optically coupled regions, thereby ensuring that multi-node dimming is coordinated in time and avoiding over-modulation or flicker. The timing dependency data can be instruction execution order and time constraint information generated after timing modeling, which can be used as direct input for constructing a dynamic dependency graph. In a specific embodiment, the timing dependency data can include, but is not limited to, instruction activation delay estimation, cross-node synchronization windows, and predecessor-successor execution relationships.

[0051] Dynamic dependency graphs are constructed based on temporal dependency data to obtain network decomposition data.

[0052] Dynamic dependency graph construction can be a process of transforming temporal dependency data into a structured graph model, which can be used to generate a computable and optimizable dependency graph to support subsequent conflict quantification and scheduling optimization. In this embodiment, dynamic dependency graph construction can use lamps or subnets as nodes and temporal constraints or resource contention as edges to construct a weighted directed graph. Dynamic dependency graph construction based on temporal dependency data can transform temporal constraints into node and edge relationships in a graph structure. For example, this operation can be achieved by using an adjacency list to store predecessor-successor execution relationships, or by embedding timestamp tags in the graph to support scheduling algorithm parsing, thereby forming a structured dependency model that can be parsed by the conflict quantification module.

[0053] Taking the scenario of maintaining constant illuminance in an industrial plant as an example, the Bluetooth lighting remote control system in this embodiment can receive the constant illuminance target (500 lux), combine it with the dynamic control domain (containing 3 areas) output by the control domain partitioning module, and generate corresponding 3 multicast subnets through Mesh multicast topology partitioning; the lighting optical attribute extraction identifies that area A has high overlap due to the dense lighting fixtures, and area B has illuminance attenuation at the edge; the key brightness node extraction selects the center node of area A and the edge node of area B as feedback sources; the control timing dependency processing finds that the instruction for area B needs to be issued 80ms earlier than that for area A to offset the multi-hop delay; the dynamic dependency graph construction encodes this timing difference as graph edge weights; the final output network decomposition data guides the collaborative control module to generate conflict-free instructions with timing offset, thereby achieving stable maintenance of illuminance throughout the plant.

[0054] In one embodiment, dynamic brightness compensation estimation, obtaining brightness compensation estimation data includes: Based on the current brightness node data and network decomposition data, the arrival time sequence of ambient light is superimposed to obtain the time sequence superimposed data. Illumination intensity kernel distribution is calculated based on time-series superimposed data to obtain local brightness concentration intensity data; Based on the current brightness node data, the regional carrying capacity and the luminaire response cycle are calculated to obtain the carrying capacity data and response cycle data, respectively. Based on the carrying capacity data and response period data, dynamic brightness compensation time extrapolation is performed on the local brightness concentration intensity data to obtain brightness compensation estimation data.

[0055] The ambient light arrival time-series superposition calculation can be based on the network decomposition structure and current brightness node data to simulate the actual superposition process of multiple light source signals in space after multi-hop transmission via Bluetooth Mesh. This can be used to reconstruct the dynamic process of real light arrival and avoid the disconnect between control commands and actual lighting conditions caused by network transmission delays. In this embodiment, the ambient light arrival time-series superposition calculation can combine the subnet topology path and delay estimation in the network decomposition data, as well as the brightness timestamps reported by each lamp, to perform time-series modeling of the order and intensity of light signals arriving at the observation point. For example, the ambient light arrival time-series superposition calculation can use the Dijkstra algorithm to estimate the minimum hop path from each lamp to the observation point and allocate typical transmission delays for time-series alignment, or use historical communication logs to statistically analyze the average end-to-end delay of each path to construct a probabilistic arrival time distribution model. The time-series superposition data can be a synthetic lighting sequence representing the superposition of light signals emitted by different lamps in the target area in time sequence, which can be used as input for the calculation of the kernel distribution of light intensity, reflecting the real light accumulation process. Furthermore, the time-series overlay data may include, but is not limited to, one or more of the following: single-node contribution time-series sequences, cross-domain optical signal fusion trajectories, and optical intensity sequences after multi-hop delay compensation.

[0056] Illuminance kernel distribution calculation can employ kernel function methods to spatially weight model time-series superimposed data, characterizing the contribution distribution of each luminaire to the total illuminance within a local area. This can be used to accurately identify brightness concentration areas and their formation mechanisms, providing a spatially perceptual basis for compensation. In an exemplary embodiment, the illuminance kernel distribution calculation can use the luminaire position as the kernel center, setting the kernel width according to the light attenuation model and directionality, and then convolving or weighting the time-series superimposed data. For example, the illuminance kernel distribution calculation can use an isotropic Gaussian kernel, the kernel width of which is determined by the luminaire beam angle and installation height, or use an asymmetric kernel function to model the spot distribution of directional luminaires, combined with wall reflectance coefficient correction. Local brightness concentration intensity data can be a regionalized illuminance hotspot intensity characterization obtained after kernel distribution calculation, which can be used to identify potentially overbright or uneven areas to guide compensation strategies. In a specific embodiment, local brightness concentration intensity data can include, but is not limited to, one or more of the following: center concentration intensity value, edge diffusion gradient, multi-source interference peak value, etc.

[0057] Regional carrying capacity calculation can assess the maximum effective illuminance that a current lighting sub-region can stably maintain under constraints of power supply, heat dissipation, and luminaire density. This is used to prevent compensation commands from exceeding physical feasibility and avoid overload or ineffective adjustments. In this embodiment, regional carrying capacity calculation can comprehensively consider luminaire rated power, power margin, temperature rise limit, and deployment density, and estimate the upper limit of regional illuminance through a constraint optimization model. Furthermore, regional carrying capacity calculation can be achieved by dynamically estimating the maximum adjustable power based on real-time current monitoring and power margin, or by combining ambient temperature sensor data and luminaire thermal resistance models to calculate the thermal balance illuminance threshold. Luminaire response cycle calculation can quantify the time characteristics required for each luminaire to complete brightness adjustment from receiving control commands. This can be used to characterize the asynchronous nature of node responses and provide individual dynamic parameters for time extrapolation. For example, luminaire response cycle calculation can establish a response delay model based on historical execution logs or device specifications (such as driver circuit response speed and LED rise time). In a specific embodiment, luminaire response cycle calculation can be achieved by fitting the time constant of a first-order inertial element through online step response testing, or by dynamically correcting the response cycle using factory calibration parameters combined with an aging factor.

[0058] The carrying capacity data can be the upper limit constraint parameter of illuminance output from the regional carrying capacity calculation, which can be used as the boundary condition for dynamic brightness compensation time extrapolation. Further, the carrying capacity data can include, but is not limited to, one or more of the following: steady-state illuminance upper limit, instantaneous power tolerance, and thermal balance illuminance threshold. The response cycle data can be the set of time delay parameters of each node output from the luminaire response cycle calculation, which can be used for timing alignment and look-ahead scheduling of compensation actions. In an exemplary embodiment, the response cycle data can include, but is not limited to, one or more of the following: instruction parsing delay, drive circuit response time, and light output stabilization duration. Dynamic brightness compensation time extrapolation can be a process of feed-forward prediction and reverse correction of local brightness concentration intensity in the time dimension under the constraints of carrying capacity and response cycle, which can be used to generate brightness compensation estimation data with time-series foresight, achieving a smooth transition. In this embodiment, dynamic brightness compensation time extrapolation can construct differential equations or discrete state transition models, jointly solving for the optimal compensation trajectory by considering the target illuminance, current concentration intensity, response delay, and capacity limit. Furthermore, dynamic brightness compensation time extrapolation can employ a model predictive control (MPC) framework to optimize the compensation sequence in the rolling time domain, or construct a state machine model to issue progressive dimming commands in stages based on the current concentration intensity and response delay. This can achieve the technical effect of generating forward-looking and feasible compensation commands, avoiding over-adjustment and flicker.

[0059] Taking intelligent dimming in an underground parking lot as an example, the Bluetooth lighting remote control system in this embodiment can be as follows: the system detects a vehicle entering a certain zone and triggers enhanced lighting. The brightness compensation module first performs ambient light arrival time sequence superposition calculation based on the network decomposition data (this zone is an independent subnet) and the brightness timestamps reported by each lamp. It finds that there is a 200ms delay due to some lamps being located at the network edge. Then, through the calculation of the light intensity kernel distribution, it identifies the brightness hotspots formed at the entrance due to the superposition of multiple lamps. At the same time, the regional carrying capacity calculation shows that this zone can only support 80% full power operation due to cable voltage drop, and the lamp response cycle calculation shows that the old lamps respond 30% slower. Based on the dynamic brightness compensation time extrapolation, a phased compensation strategy is generated: first, the brightness of the main lamps is increased at a low slope, and then fine-tuned after the edge nodes are in place, ultimately achieving smooth supplementary lighting without overshoot or dark areas.

[0060] In one embodiment, the control dependency graph is constructed, and the resulting control dependency graph data includes: Based on the current brightness node data and network decomposition data, a network grouping control dependency subgraph is constructed to obtain control dependency subgraph data; Dynamic weighting is performed on the control dependency subgraph data based on the brightness compensation estimation data to obtain dynamic weighted graph data. Directed acyclic control optimization is performed based on dynamic weight graph data to obtain control dependency graph data.

[0061] The network group control dependency subgraph can be a local dependency graph structure built based on the communication and spatial relationships between nodes within a logical control group. It is used to establish topological constraints for the execution of internal instructions in each dynamically partitioned control domain, reflecting physical proximity and multi-hop communication paths. In this embodiment, the network group control dependency subgraph can utilize network decomposition data to determine subnet boundaries and combine the position or hop count information in the current brightness node data to establish inter-node dependency edges. Furthermore, the network group control dependency subgraph can be the basis for generating control dependency subgraph data; its structure is influenced by both network decomposition data and current brightness node data. The control dependency subgraph data can be unweighted local dependency relationship data output by the network group control dependency subgraph, which can be used to characterize the original timing or resource dependencies between lighting instructions within each control domain. For example, the control dependency subgraph data can include, but is not limited to, one or more of the following: intra-domain master-slave dependency relationships, multi-hop forwarding order constraints, and neighboring node synchronization trigger chains. Based on the current brightness node data and network decomposition data, a network group control dependency subgraph is constructed. This can be done by establishing local dependencies within each logical subnet based on node location, communication hop count, or brightness feedback correlation. Furthermore, this operation can be achieved by constructing adjacency dependencies based on Bluetooth RSSI values ​​between nodes, using the subnets defined by the network decomposition data as units, or by establishing synchronous trigger edges for lights in the same area based on the spatial coordinate proximity in the current brightness node data. This allows each logical control group to possess a local topology that reflects physical proximity and communication hop count.

[0062] Dynamic weight assignment can be a process of assigning scheduling priority values ​​to edges or nodes in a dependency graph based on the urgency of brightness compensation. It can be used to quantify control importance as graph weights, guiding subsequent optimization scheduling. In an exemplary embodiment, dynamic weight assignment can parse parameters such as deviation magnitude and response time requirements in the brightness compensation estimation data and map them to graph element weights. Dynamic weighted graph data can be a weighted directed dependency graph after dynamic weight assignment, which can simultaneously carry temporal dependency and control priority information, providing input for acyclic optimization. In a specific embodiment, dynamic weighted graph data can include, but is not limited to, node weighted graphs (using lamps as weight carriers), edge weighted graphs (using the strength of inter-instruction dependencies as weights), and hybrid weighted graphs (both nodes and edges are weighted). Dynamically weighting the control dependency subgraph data based on the brightness compensation estimation data can map the deviation, aging coefficient, or environmental disturbance index in the brightness compensation estimation data to the weight values ​​of nodes or edges in the graph. Furthermore, this operation can be implemented by assigning high node weights to nodes with large compensation magnitudes so that they are executed first in the scheduling, or by assigning high edge weights to compensation instruction edges across multi-hop paths to reflect their transmission delay sensitivity. In this way, the dependency graph can not only express the execution order, but also reflect the urgency and influence weight of the control task.

[0063] Directed acyclic control optimization (DAG) can be an algorithmic process of restructuring a dynamic weighted graph to eliminate circular dependencies and optimize the execution sequence. It can be used to ensure that the final control dependency graph meets schedulability and real-time constraints. In this embodiment, DAG can employ topological sorting combined with the critical path method to reconstruct the instruction execution order while preserving weight priorities. DAG optimization based on dynamic weighted graph data can involve adjusting the node execution order or merging conflicting paths according to weight priorities while maintaining the graph's DAG status. Furthermore, this operation can be achieved by using weighted topological sorting to prioritize the output of instructions from high-weight nodes, or by identifying and pruning low-weight redundant edges to simplify the graph structure and reduce scheduling complexity. This results in a deadlock-free final control dependency graph with high-priority tasks pre-positioned and meeting real-time constraints.

[0064] For example, in a scenario where constant illuminance is maintained in an industrial plant, the Bluetooth lighting remote control system of this embodiment can detect a sudden drop in illuminance in the northern area due to window obstruction. The brightness compensation module calculates that multiple lights in this area need to be significantly brightened (brightness compensation estimation data). The collaborative control module first identifies that the area belongs to the same control subnet based on the network decomposition data, and constructs a network group control dependency subgraph by combining the spatial position in the current brightness node data, establishing a serial dimming chain of lights A→B→C. Subsequently, nodes A, B, and C are assigned high, medium, and low weights respectively according to the compensation magnitude, forming a dynamic weight graph. Finally, through directed acyclic control optimization, it ensures that the high-weight light A executes the dimming command first, avoiding channel congestion due to concurrency, and achieving fast and orderly illuminance recovery.

[0065] In one embodiment, network conflict quantization, obtaining luminaire conflict quantization data includes: Based on the control dependency graph data, the communication channel resource occupancy is mapped to obtain resource occupancy data.

[0066] The communication channel resource occupancy mapping can be a process model that transforms the logical dependencies in the control dependency graph into a time-frequency resource usage plan. It can be used to concretize abstract control dependencies into a schedulable physical / MAC layer channel occupancy representation. In this embodiment, the communication channel resource occupancy mapping can be explained in context, i.e., parsing the nodes and edges in the control dependency graph and mapping them to specific time-frequency resource allocation schemes. Resource occupancy data can be a data structure describing the communication resources occupied by each control command in the time, frequency, or spatial dimensions. It can be used as the basic input for conflict identification, characterizing the actual demand of commands for network resources. For example, resource occupancy data can include time-domain occupancy intervals, frequency-domain sub-channel identifiers, multi-hop path node sequences, etc. Mapping communication channel resource occupancy based on control dependency graph data can involve parsing the nodes and edges in the control dependency graph and mapping them to specific time-frequency resource allocation schemes. Furthermore, mapping communication channel resource occupancy based on control dependency graph data can be achieved by allocating non-overlapping time slots according to the execution order in the dependency graph, or by estimating the transmission window based on the multi-hop path length and binding channel resources, thereby transforming logical dependencies into schedulable physical resource usage plans.

[0067] Conflict tuples are extracted from resource usage data to obtain conflict tuple data.

[0068] Conflict tuple extraction can be a set of high-risk concurrent instruction combinations output by the conflict tuple extraction operation. This set can be used as input for signal overlap tensor modeling, focusing on conflict scenarios requiring quantization evaluation. In an exemplary embodiment, conflict tuple extraction can include dual-instruction conflict pairs, multi-node broadcast conflict clusters, and cross-domain forwarding interference groups. Conflict tuple data can describe the operation process of instruction combinations with resource overlap risks and can be used to locate potential packet collisions or resource contention units. In a specific embodiment, conflict tuple data can include time-domain overlapping tuples, co-channel interference tuples, and shared relay conflict tuples. Conflict tuple extraction based on resource occupancy data can involve scanning resource occupancy data to identify instruction combinations that overlap in time, frequency, or relay path. Furthermore, conflict tuple extraction based on resource occupancy data can be achieved by identifying time-domain conflict pairs using interval overlap detection algorithms or by dividing the shared relay instruction group into conflict clusters based on graph coloring methods, thereby accurately locating potential conflict units and narrowing the subsequent quantization range.

[0069] Signal overlap tension quantization is performed based on the conflict tuple data to obtain the luminaire conflict quantization data.

[0070] The signal overlap tensor can be a high-order array structure used for multidimensional modeling of the overlap degree of signals in conflict tuples across dimensions such as time, power, and hop count. It can provide a computable mathematical expression to quantify conflict severity. In this embodiment, the acquisition method of the signal overlap tensor can be explained in context: a multidimensional tensor is constructed based on the transmission parameters of each instruction in the conflict tuple (such as transmission time offset, transmission power, and path hop count). Signal overlap tension quantification based on conflict tuple data can be achieved by constructing a tensor containing dimensions such as time offset, power interference, and hop count delay for each conflict tuple and calculating its norm or entropy value. Furthermore, signal overlap tension quantification based on conflict tuple data can be achieved by constructing a three-dimensional tensor (time difference, power ratio, hop count difference) and calculating the Frobenius norm as the conflict intensity, or by using tensor decomposition to extract principal components and using the energy proportion of the principal components to characterize the dominant conflict factor. This allows for the generation of comparable and optimizable numerical indicators of conflict severity.

[0071] For example, in a scenario of concurrent dimming of high-density lighting fixtures in an industrial plant, the Bluetooth lighting remote control system of this embodiment can be: the system needs to adjust the brightness of 200 lighting fixtures simultaneously. The collaborative control module first constructs a control dependency graph based on brightness compensation estimation data; then it performs communication channel resource occupancy mapping, allocating expected transmission time slots and relay paths to each dimming command; in the conflict tuple extraction stage, 15 sets of command pairs that share the same relay and have overlapping time slots are identified; for each signal overlap tensor pair, a time-hop count-power three-dimensional tensor is constructed, quantifying that the conflict intensity of 3 sets exceeds the threshold; finally, in the collaborative control generation stage, the transmission timing of these 3 sets of commands is adjusted or the relay path is changed to avoid actual collisions.

[0072] In one embodiment, signal overlap tension quantization yields luminaire conflict quantization data including: The non-steady-state signal overlap and temporal occupancy intersection are calculated based on the conflict tuple data, and the dynamic boundary overlap data and temporal occupancy intersection data are obtained respectively. Based on the dynamic boundary overlap data and the timing occupancy intersection data, the shared channel node contention is analyzed to obtain node contention analysis data; Based on the node competition analysis data, signal tension propagation modeling is performed to obtain tension propagation matrix data; Based on the tension propagation matrix data, high-priority task gravity compensation control is performed to obtain quantitative data on lighting conflict.

[0073] Among them, non-stationary signal overlap can be an indicator measuring the degree of instantaneous signal waveform overlap caused by environmental dynamics in Bluetooth Mesh multi-hop transmission, and can be used to reflect the risk of non-stationary signal collisions caused by node movement, interference, or power fluctuations. In an exemplary embodiment, non-stationary signal overlap can be obtained by analyzing the instantaneous spectrum overlap of signals using a sliding window FFT. Timing occupancy intersection can characterize the degree of overlap of multiple control commands in the scheduling time window, and can be used to characterize the intensity of timing resource contention in the Mesh network caused by multi-hop delay and command dependency. For example, timing occupancy intersection can be obtained by calculating the intersection ratio of timing windows based on the command plan timestamp and the estimated multi-hop delay. In a specific embodiment, timing occupancy intersection may include, but is not limited to, one or more of the following: command transmission time slot overlap rate, relay forwarding window intersection ratio, and end-to-end response delay coupling degree.

[0074] Dynamic boundary overlap data can be a quantized result obtained from non-steady-state signal overlap calculations, used to describe the dynamic boundary of signal overlap, and can be used as the signal dimension input for shared channel contention analysis. In this embodiment, dynamic boundary overlap data can include, but is not limited to, one or more of the following: boundary ambiguity intervals, overlap probability density distribution, instantaneous interference confidence level, etc. Timing occupancy intersection data can be a quantized result obtained from timing occupancy intersection calculations, characterizing the degree of instruction time resource conflict, and can be used as the timing dimension input for shared channel contention analysis. Further, timing occupancy intersection data can include, but is not limited to, one or more of the following: concurrent instruction quantity threshold, critical path delay sensitivity, multi-hop synchronization deviation, etc. Calculating non-steady-state signal overlap and timing occupancy intersection based on conflict tuple data can assess the overlap risk within conflict tuples from two dimensions: signal waveform dynamics and instruction scheduling timing, respectively. Furthermore, this operation can be achieved by using sliding window FFT to analyze the instantaneous spectral overlap of the signal to calculate the non-steady-state overlap, and by calculating the intersection ratio of the timing window based on the instruction plan timestamp and the estimated multi-hop delay, thereby generating two-dimensional conflict features to support refined competition analysis.

[0075] Shared channel node contention analysis can be an analytical process based on two-dimensional conflict data to identify a set of nodes competing for shared channel resources. It can be used to transform abstract congestion into a structured competition relationship topology. In a specific embodiment, shared channel node contention analysis may include, but is not limited to, one or more of the following: co-frequency concurrent node clustering, relay bottleneck node identification, and broadcast domain competition hotspot detection. Node contention analysis data can be structured data describing nodes with resource contention relationships in the shared channel and their competition intensity, which can be used to provide a network competition topology basis for tension propagation modeling. For example, node contention analysis data may include, but is not limited to, one or more of the following: a list of competing node pairs, a channel contention intensity matrix, and a multi-hop path conflict graph. Shared channel node contention analysis based on dynamic boundary overlap data and temporal occupancy intersection data can be achieved by fusing conflict features of the signal and time dimensions to identify a set of nodes competing for shared channel resources. Furthermore, this operation can be implemented by using a multi-dimensional clustering algorithm to group nodes with high overlap and temporal intersection into the same competition group, or by using a graph neural network to jointly score the competition intensity of node pairs, thereby constructing a structured competition topology and clarifying resource contention relationships.

[0076] Signal tension propagation modeling can model the competition relationship between nodes as a physical field analogy of tension propagation in the network, and can be used to predict the diffusion path and impact range of conflicts in the mesh topology. In this embodiment, signal tension propagation modeling can include, but is not limited to, one or more of the following: tension attenuation path model, multi-hop cumulative tension calculation, and identification of local tension concentration areas. The tension propagation matrix data can be a data structure that expresses the intensity and direction of tension propagation between nodes in matrix form, and can be used to quantify the potential propagation effect of conflicts in the entire network. Further, the tension propagation matrix data can include, but is not limited to, one or more of the following: node pair tension weights, path cumulative tension values, and tension gradient vector fields. Signal tension propagation modeling based on node competition analysis data can map the competition relationship as a tension propagation process in the network topology and calculate the cumulative tension borne by each node. For example, this operation can be achieved by using the competition intensity as the initial tension source and performing iterative diffusion calculations along the mesh adjacency relationship, or by constructing a Laplace matrix to solve for the steady-state tension distribution, thereby predicting the conflict diffusion effect and identifying high-risk propagation paths.

[0077] Gravity compensation regulation for high-priority tasks can be an active regulation mechanism that grants tasks stronger resource attraction capabilities based on their priority and suppresses low-priority tasks. This mechanism is used to proactively resolve conflicts and ensure the deterministic execution of critical instructions. In an exemplary embodiment, gravity compensation regulation for high-priority tasks may include, but is not limited to, one or more of the following: priority-driven time slot preemption, gravity-guided power suppression, and critical task path reservation. Gravity compensation regulation for high-priority tasks based on tension propagation matrix data can adjust the gravity weight of a task in the tension field according to its priority, dynamically reallocating resources or suppressing low-priority launches. Furthermore, this operation can be achieved by allocating negative tension (i.e., gravity) to high-priority tasks, attracting neighboring nodes to postpone their launches, or by implementing power backoff or time slot migration for low-priority tasks in high-gradient tension regions, thereby proactively avoiding conflicts and ensuring the reliable execution of critical instructions.

[0078] Taking the emergency dimming response of smart city road lighting as an example, the Bluetooth lighting remote control system in this embodiment can be configured to immediately dim the main road lights upon receiving a rainstorm warning (high-priority task). Conflict tuples identify channel contention between this command and the ongoing energy-saving inspection (low-priority). Non-steady-state signal overlap detection shows that rain and fog exacerbate signal attenuation, and timing occupancy intersection indicates a high degree of overlap between the relay windows of the two tasks. Shared channel contention analysis confirms that five intersection nodes are contention hotspots. Tension propagation modeling shows that without intervention, the conflict will spread to 12 surrounding nodes. The high-priority task gravity compensation control is then activated: strong gravity is applied to the main road dimming command, causing it to seize the original time slot, while the inspection task is delayed by 200ms and its transmission power is reduced at the competing nodes. Ultimately, the emergency dimming is completed without conflict, and the inspection task resumes execution in a low-interference window.

[0079] In one embodiment, collaborative control generation, obtaining luminaire collaborative control data to achieve remote dynamic collaborative control of multi-node lighting fixtures, includes: Conflict core clusters are identified based on the quantification data of lighting conflicts, and conflict core cluster data is obtained. The conflict core cluster can be a local conflict subset composed of lighting fixture nodes with strong resource competition or close temporal dependencies. It can be used to structure and localize global concurrent conflict problems, facilitating targeted scheduling optimization. In an exemplary embodiment, the conflict core cluster can be obtained by clustering high-conflict correlations or extracting graph connected components from the lighting fixture conflict quantification data. Furthermore, the conflict core cluster can be a scheduling optimization input unit. For example, the conflict core cluster can include, but is not limited to, one or more of the following: channel contention clusters, multi-hop path interference clusters, and command timing coupling clusters. Identifying conflict core clusters based on lighting fixture conflict quantification data can be achieved by clustering high-conflict correlations or extracting graph connected components from the lighting fixture conflict quantification data. In a specific embodiment, identifying conflict core clusters based on lighting fixture conflict quantification data can be achieved by constructing an undirected graph based on a conflict intensity threshold and extracting connected subgraphs as core clusters, or by using a density clustering algorithm (such as DBSCAN) to group nodes in the conflict index space. This allows dispersed conflict points to be aggregated into schedulable local units, reducing the complexity of subsequent optimization.

[0080] Based on the conflict core cluster data, Mesh networking-level control sequence optimization is performed to obtain optimized control sequence data; The Mesh networking-level control sequence can be an ordered execution sequence formed by spatiotemporally arranging control commands under the constraints of the Bluetooth Mesh network topology. It can be used to ensure that commands from highly conflicting nodes are delivered according to the optimized timing and path, avoiding channel contention. In this embodiment, the operating principle of the Mesh networking-level control sequence can be explained in context, namely, rearranging the command transmission order based on network topology, channel state, and timing constraints. Furthermore, the Mesh networking-level control sequence can be a carrier form of the conflict core cluster optimization results. For example, the Mesh networking-level control sequence can include, but is not limited to, time-division multiplexing command sequences, multi-hop route-aware scheduling sequences, and power-timing joint optimization sequences. Optimizing the Mesh networking-level control sequence based on conflict core cluster data can involve rearranging the command transmission order for each conflict core cluster, taking into account the Mesh network topology, channel state, and timing constraints. Furthermore, Mesh networking-level control sequence optimization based on conflicting core cluster data can be achieved by arranging instruction transmission time slots in ascending order of multi-hop path length within the core cluster, or by allocating non-overlapping transmission windows and inserting idle intervals for lamps sharing relay nodes. This can avoid concurrent transmission of highly conflicting nodes in the same time period and reduce channel contention and packet collisions.

[0081] Based on the control sequence optimization data, lighting collaborative control data is generated to drive the Bluetooth Mesh control platform to perform remote dynamic collaborative control of multi-node lighting fixtures.

[0082] The Bluetooth Mesh control platform can be a low-level network execution entity responsible for parsing and executing lighting coordinated control data. It can be used to transform optimized control commands into physical layer operations conforming to the Bluetooth Mesh protocol stack. In a specific embodiment, the Bluetooth Mesh control platform's operating principle can be explained in context: it receives lighting coordinated control data, generates messages according to the MeshProfile specification, and broadcasts or multicasts them to target nodes according to the scheduling sequence. Furthermore, the Bluetooth Mesh control platform can be the final execution carrier of the lighting coordinated control data. Generating lighting coordinated control data based on control sequence optimization data can be achieved by encapsulating the optimized timing scheduling results into a message format conforming to the Bluetooth Mesh protocol. For example, generating lighting coordinated control data based on control sequence optimization data can be achieved by encoding the scheduling sequence into Mesh messages with TTL and publication period parameters, or by generating independent application keys and address allocations for different clusters to achieve logical isolation, thereby forming a low-conflict instruction set that can be directly executed by the network platform.

[0083] Driving the Bluetooth Mesh control platform to perform remote dynamic collaborative control of multi-node lighting fixtures can be achieved by submitting the collaborative control data of the lighting fixtures to the upper-layer interface of the Bluetooth Mesh protocol stack to trigger message distribution. In an exemplary embodiment, driving the Bluetooth Mesh control platform to perform remote dynamic collaborative control of multi-node lighting fixtures can be achieved by forwarding control data to the Mesh network entry node through the GATT proxy service, or by using a configuration client model to batch write the state parameters of the target nodes, thereby enabling the reliable execution of the optimized control strategy in the physical network.

[0084] Taking the switching of nighttime inspection mode in an industrial plant as an example, the Bluetooth lighting remote control system in this embodiment can simultaneously dim 80% of the area and illuminate the inspection channel. The collaborative control module has previously output lighting conflict quantification data, showing that the lights on both sides of the channel have high conflict due to sharing 3 relay nodes. The conflict core cluster identification group them into two channel competition clusters; the Mesh networking level control sequence optimization allocates a 50ms staggered transmission window to each cluster and prioritizes scheduling nodes closer to the gateway; the final generated lighting collaborative control data contains dimming commands with time-series tags, which are sent batch by batch by the Bluetooth Mesh control platform according to the optimized sequence, avoiding command loss due to concurrency, ensuring that the inspection channel completes flicker-free lighting within 2 seconds, and the remaining areas are synchronously and smoothly dimmed.

[0085] In one embodiment, generating luminaire collaborative control data based on control sequence optimization data includes: encapsulating the control sequence optimization data into a broadcast message conforming to the Bluetooth Mesh protocol standard, and transmitting it to the luminaire node corresponding to the luminaire control domain data via multi-hop transmission through relay nodes.

[0086] The Bluetooth Mesh protocol standard broadcast message is a control message format that conforms to the Bluetooth Mesh Profile specification and uses broadcast transmission. It can be used to achieve efficient one-to-many distribution, ensuring protocol compatibility and low power consumption. Relay nodes can be lighting fixtures or dedicated device nodes with message forwarding capabilities in the Bluetooth Mesh network. They can be used to support multi-hop transmission and extend the coverage of control commands. For example, a relay node can receive broadcast messages from the control platform and decide whether to forward them to the next hop based on the TTL and address information.

[0087] The luminaire nodes corresponding to the luminaire control domain data can be a set of target luminaires belonging to the currently dynamically partitioned control domain, and can be used as the final execution objects of control commands. In an exemplary embodiment, the luminaire nodes corresponding to the luminaire control domain data can include, but are not limited to, luminaires within the main control domain, edge slave luminaires, and cross-domain shared luminaires. Multi-hop transmission can be a communication mechanism in which control messages are forwarded hop-by-hop to the target node through one or more relay nodes, which can be used to overcome the single-hop communication distance limitation and accurately deliver to remote luminaire nodes. Furthermore, multi-hop transmission can employ single-relay forwarding paths, multi-level cascaded relay paths, parallel multi-path relays, etc.

[0088] Encapsulating the optimized control sequence data into a broadcast message conforming to the Bluetooth Mesh protocol standard can be achieved by mapping the scheduled command parameters to the Bluetooth Mesh model message field and setting the TTL, publication period, and application key. In one specific embodiment, this operation can be achieved by encapsulating the brightness compensation value using the LightLightness model and setting the target address to the control domain group address, or by encoding the timing scheduling information into the PublishPeriod parameter to achieve periodic automatic retransmission. This results in a standardized control message that is protocol-compatible and can be recognized and routed by the Mesh network. The message is then transmitted via relay nodes to the corresponding lighting nodes in the lighting control domain data. This can be achieved by utilizing nodes in the Mesh network with relay functionality enabled to forward the broadcast message hop-by-hop to all lighting fixtures within the target domain, according to the TTL limit. For example, this operation can be achieved by pre-configuring the group address based on the lighting control domain data, ensuring that only nodes within the domain subscribe to and process the broadcast message, or by dynamically adjusting the TTL value to precisely cover the farthest target node, preventing over-propagation. This avoids flooding to irrelevant nodes and reduces energy consumption and channel interference for non-target nodes.

[0089] Taking smart city street lighting zone dimming as an example, the Bluetooth lighting remote control system in this embodiment can generate a dimming sequence for control domain 3 in the East Zone after the system completes conflict resolution. The collaborative control module encapsulates this sequence into a LightLightnessSet broadcast message, with the target address set to the domain group address. After the message is sent by the gateway, it is forwarded in two hops through two street light nodes with relay functions, and the TTL is set to 3 to ensure coverage of the end lights. Since the message is only processed by lights in domain 3, nodes in other areas ignore the message, avoiding invalid wake-ups. The entire process is completed within 200ms, with no retransmissions, and non-target nodes maintain a low-power state.

[0090] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A Bluetooth lighting remote control system, characterized in that, The system includes: The control domain partitioning module is used to acquire real-time operating data of multi-node lighting fixtures and partition the lighting fixture control domains based on the real-time operating data of multi-node lighting fixtures to obtain lighting fixture control domain data. The network decomposition module is used to acquire lighting target adjustment data; it performs Bluetooth Mesh network group decomposition on the lighting target adjustment data and the luminaire control domain data to obtain network decomposition data; The brightness compensation module is used to acquire the brightness node data of the current area and perform dynamic brightness compensation estimation based on the current area brightness node data and network decomposition data to obtain brightness compensation estimation data. The collaborative control module is used to construct a control dependency graph based on the brightness compensation estimation data to obtain control dependency graph data; to quantify network conflicts based on the control dependency graph data to obtain luminaire conflict quantification data; and to generate collaborative control based on the luminaire conflict quantification data to obtain luminaire collaborative control data, so as to realize remote dynamic collaborative control of multi-node lighting fixtures.

2. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The division of the lighting control domain yields lighting control domain data including: Based on the real-time operation data of multi-node lighting fixtures, the node-communication link coupling relationship is analyzed to obtain node-link coupling matrix data; Acquire lighting control timing data, and calculate the adjustment coordination frequency based on the lighting control timing data to obtain adjustment coordination frequency data; Based on the node-link coupling matrix data and the adjustment coordination frequency data, a Bluetooth Mesh twin domain is constructed to obtain the lighting control domain data.

3. The Bluetooth lighting remote control system as described in claim 2, characterized in that, The Bluetooth Mesh twin domain construction yields lighting control domain data including: Based on the node-link coupling matrix data and the adjustment and coordination frequency data, virtual networking coverage feature extraction and dynamic signal transmission feature extraction are performed to obtain virtual networking coverage feature data and dynamic signal transmission feature data, respectively. Based on the virtual network coverage characteristic data and dynamic signal transmission characteristic data, a twin coupling graph is generated from the node-link coupling matrix data to obtain twin coupling graph data; The virtual-real mismatch region detection is performed on the twin coupling graph data to obtain virtual-real calibration graph data. The virtual-real mismatch region detection includes signal strength mismatch detection, communication abnormal interruption detection, and node permission dynamic verification detection. By injecting operating condition time series constraints into the virtual and real calibration map data, time series constraint map data is obtained; The control connectivity subdomains are extracted from the time-series constraint diagram data to obtain the lighting control domain data.

4. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The Bluetooth Mesh network group decomposition yields network decomposition data including: Mesh multicast topology partitioning is performed on lighting target adjustment data and luminaire control domain data to obtain topology partitioning data; Based on the topology partitioning data, lighting optical attributes and key brightness nodes are extracted to obtain lighting optical attribute data and key brightness node data, respectively. Based on the lighting optical attribute data and key brightness node data, the topology partitioning data is processed to control the temporal dependency, resulting in temporal dependency data. Dynamic dependency graphs are constructed based on temporal dependency data to obtain network decomposition data.

5. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The dynamic brightness compensation estimation yields brightness compensation estimation data including: Based on the current brightness node data and network decomposition data, the arrival time sequence of ambient light is superimposed to obtain the time sequence superimposed data. Illumination intensity kernel distribution is calculated based on time-series superimposed data to obtain local brightness concentration intensity data; Based on the current brightness node data, the regional carrying capacity and the luminaire response cycle are calculated to obtain the carrying capacity data and response cycle data, respectively. Based on the carrying capacity data and response period data, dynamic brightness compensation time extrapolation is performed on the local brightness concentration intensity data to obtain brightness compensation estimation data.

6. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The control dependency graph construction yields control dependency graph data including: Based on the current brightness node data and network decomposition data, a network grouping control dependency subgraph is constructed to obtain control dependency subgraph data; Dynamic weighting is performed on the control dependency subgraph data based on the brightness compensation estimation data to obtain dynamic weighted graph data. Directed acyclic control optimization is performed based on dynamic weight graph data to obtain control dependency graph data.

7. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The network conflict quantization yields lighting conflict quantization data including: Based on the control dependency graph data, the communication channel resource occupancy is mapped to obtain resource occupancy data; Conflicting tuples are extracted from resource usage data to obtain conflicting tuple data. Signal overlap tension quantization is performed based on the conflict tuple data to obtain the luminaire conflict quantization data.

8. The Bluetooth lighting remote control system as described in claim 7, characterized in that, The signal overlap tension quantization yields the following lighting conflict quantization data: The non-steady-state signal overlap and temporal occupancy intersection are calculated based on the conflict tuple data, and the dynamic boundary overlap data and temporal occupancy intersection data are obtained respectively. Based on the dynamic boundary overlap data and the timing occupancy intersection data, the shared channel node contention is analyzed to obtain node contention analysis data; Based on the node competition analysis data, signal tension propagation modeling is performed to obtain tension propagation matrix data; Based on the tension propagation matrix data, high-priority task gravity compensation control is performed to obtain quantitative data on lighting conflict.

9. The Bluetooth lighting remote control system as described in claim 1, characterized in that, The collaborative control generation, which obtains lighting fixture collaborative control data to achieve remote dynamic collaborative control of multi-node lighting fixtures, includes: Conflict core clusters are identified based on the quantification data of lighting conflicts, and conflict core cluster data is obtained. Based on the conflict core cluster data, Mesh networking-level control sequence optimization is performed to obtain optimized control sequence data; Based on the control sequence optimization data, lighting collaborative control data is generated to drive the Bluetooth Mesh control platform to perform remote dynamic collaborative control of multi-node lighting fixtures.

10. The Bluetooth lighting remote control system as described in claim 9, characterized in that, The step of generating lighting collaborative control data based on control sequence optimization data includes: encapsulating the control sequence optimization data into a broadcast message conforming to the Bluetooth Mesh protocol standard, and transmitting it to the lighting node corresponding to the corresponding lighting control domain data through multi-hop transmission via relay nodes.

Images