Intelligent lighting network node management method, bridge-side compiler, medium, and system

Abstract

The application provides a smart lighting network node management method, a bridge compiler, a medium and a system. The method comprises: in response to receiving a re-joining request of a lamp device, performing lamp identity verification and security state verification on the lamp device; generating a temporary session key for the lamp device, configuring network parameters, and delivering the network parameters to the lamp device, so that the lamp device establishes a temporary communication link with the bridge compiler; generating a preferred parent node list based on the historical profile of the lamp device and the current network information, and sending the preferred parent node list to the lamp device through the temporary communication link; after the lamp device establishes a connection relationship with the corresponding parent node in the preferred parent node list, obtaining migration data based on the historical profile of the lamp device, and delivering the migration data to the lamp device, so that the lamp device runs based on the migration data. The application can greatly improve the re-entry efficiency of the lamp device and improve the overall performance of the home smart lighting network.

Description

Technical Field

[0001] This application belongs to the field of intelligent lighting control technology, and in particular relates to the field of intelligent lighting network equipment management technology. Background Technology

[0002] With the rapid development of IoT technology and the smart home industry, smart home lighting networks have become a core component of smart home systems. Through wireless communication protocols such as ZigBee, WiFi, and Bluetooth Mesh, they enable intelligent functions such as remote control of lighting devices, scene linkage, and brightness adjustment, greatly improving the convenience and comfort of home living. Currently, smart home lighting networks mostly adopt a hierarchical topology architecture. Terminal lighting devices (such as smart bulbs and smart spotlights) connect to the network through associated parent nodes (such as smart gateways and repeaters), forming a network structure where multiple devices work collaboratively. Furthermore, as user needs upgrade, the network scale continues to expand, with the number of lighting devices connected in a single home network reaching dozens or even hundreds.

[0003] However, in practical applications, the networking and maintenance technologies of existing home smart lighting networks still have many shortcomings that urgently need to be addressed, seriously affecting network stability and user experience. These shortcomings are specifically manifested as follows:

[0004] First, traditional re-entry mechanisms suffer from slow re-entry speed and high failure rate when devices occasionally disconnect or their parent nodes change. In home scenarios, wireless signals are easily affected by factors such as wall obstruction, electrical interference, and changes in distance, leading to temporary interruptions in the communication link between the terminal lighting device and the parent node, or requiring a change of the associated parent node due to network optimization or parent node failure. In existing technologies, when offline devices reconnect to the network, they must go through a cumbersome process of scanning the network, initiating an association request, authentication, and parameter configuration, and the re-entry strategy is not optimized for link interruption scenarios, resulting in re-entry times that are usually several seconds or even tens of seconds. At the same time, due to factors such as channel contention and signal interference, re-entry requests are easily lost or rejected, resulting in a high failure rate. Device re-entry delays and failures directly lead to the inability to respond to lighting control commands in a timely manner, interrupting scene linkage, and seriously affecting the user experience, especially in scenarios with high real-time lighting requirements (such as getting up at night or receiving visitors), where this deficiency is more prominent.

[0005] Secondly, offline devices are prone to becoming ghost nodes, consuming network resources and causing control anomalies. In existing home smart lighting networks, when terminal devices go offline (e.g., due to battery depletion, manual power-off, or prolonged offline status), the network system typically lacks effective offline detection and resource release mechanisms. The network addresses, group binding relationships, and scene linkage configurations of offline devices continue to be occupied. On one hand, the occupation of network address resources can lead to address allocation conflicts when new devices connect, increasing the difficulty of networking new devices. On the other hand, when a user initiates group control or scene linkage commands, the system sends commands to all bound devices, including "ghost nodes." When commands are transmitted to offline devices, a retry mechanism is triggered due to link interruptions, causing command transmission delays. Furthermore, retrying can occupy channel resources, leading to control failures of normal devices and severely reducing the reliability of network control.

[0006] Finally, in large-scale networking scenarios, topology decay intensifies, further reducing the stability of device re-entry. As the number of home lighting devices increases, network topologies exhibit a multi-hop extension trend. Edge lighting devices need to connect to the core gateway through multiple relay nodes, and some nodes form weak links due to installation location limitations (such as corners or obstructions). Existing topology maintenance technologies lack dynamic optimization and decay warning mechanisms. Signal attenuation in multi-hop links and unstable transmission in weak links lead to frequent device disconnections. When a disconnected device reconnects, it may still be associated with the original weak link parent node, forming a vicious cycle of "disconnection-re-disconnection." Simultaneously, topology decay leads to network channel congestion and increased data transmission error rates, further reducing the success rate of device re-entry. In severe cases, it can cause local network paralysis, affecting the normal operation of the entire lighting system.

[0007] In summary, existing smart home lighting networks have significant technical deficiencies in areas such as device re-entry mechanisms, offline resource management, and topology maintenance. These deficiencies result in poor network stability, low control reliability, and a poor user experience, failing to meet the demands of large-scale, high-reliability smart home lighting applications. Therefore, there is an urgent need for a technical solution that can address these issues and improve the overall performance of smart home lighting networks. Summary of the Invention

[0008] This application provides a smart lighting network node management method, bridge compiler, media, and system for improving the overall performance of a home smart lighting network.

[0009] In a first aspect, embodiments of this application provide a method for managing intelligent lighting network nodes, applied to a bridge-end compiler, comprising: responding to a received rejoin request from a lighting device, performing lighting device identity verification and security status verification on the lighting device based on the rejoin request; generating a temporary session key for the lighting device, configuring network parameters, and sending the temporary session key to the lighting device, thereby enabling the lighting device to establish a temporary communication link with the bridge-end compiler based on the temporary session key and the network parameters; generating a preferred parent node list based on the historical profile and current network information of the lighting device, and sending the preferred parent node list to the lighting device through the temporary communication link; after the lighting device establishes a connection relationship with the corresponding parent node in the preferred parent node list, obtaining migration data based on the historical profile of the lighting device, and sending the migration data to the lighting device, thereby enabling the lighting device to operate based on the migration data.

[0010] In one implementation of the first aspect, the method further includes: establishing the historical profile for the lighting device that is accessing the lighting network for the first time, and updating the historical profile when the operating status of the lighting device changes; wherein, the historical profile includes a unique identifier of the lighting device, the parent-child connection relationship between the lighting device and other lighting devices in the network, the link quality parameters between the lighting device and the parent node, the lighting device access / communication failure count, the heartbeat interaction timestamp between the lighting device and the bridge compiler, historical access channel information, network identifier, configured group / scene / automation binding relationship, and multiple combinations of relay function enabled status.

[0011] In one implementation of the first aspect, generating a temporary session key and configuring network parameters for the lighting device includes: generating a temporary session key based on the unique identifier of the lighting device, the current timestamp, and a random number, and configuring the validity period of the temporary session key; configuring a working channel, a network identifier, and communication parameters for the lighting device; wherein the working channel is configured based on the historical access channel information and / or the current network-wide channel load.

[0012] In one implementation of the first aspect, generating a preferred parent node list based on the historical profile and current network information of the lighting device includes: filtering multiple candidate parent nodes based on historical parent-child nodes in the historical profile, link quality in the current network, relay load, and hop count of the lighting device; evaluating and sorting the multiple candidate parent nodes based on a multi-dimensional evaluation model and multi-dimensional evaluation indicators to generate a preferred parent node list; wherein, the multi-dimensional evaluation indicators include multiple of the following: the quality of the nearest link between the lighting device and the candidate parent node, the current network congestion of the candidate parent node, the hop count from the candidate parent node to the bridge compiler, and the current load of the candidate parent node.

[0013] In one implementation of the first aspect, obtaining migration data based on the historical profile of the lighting device includes: in response to receiving a binding migration request from the lighting device, retrieving binding configuration data from the historical profile of the lighting device based on the unique identifier of the lighting device, and generating a migration dataset; performing deduplication processing on duplicate name groups, duplicate name scenarios / automated tasks in the migration dataset, and generating migration data.

[0014] In one implementation of the first aspect, the method further includes detecting and reclaiming ghost nodes in the smart lighting network, including: determining ghost nodes based on whether heartbeat response information from the lighting fixtures is received in multiple consecutive polling cycles, multi-cycle no-heartbeat interaction data recorded in the lighting fixture historical profile, data transmission and reception information of the lighting fixtures, and polling response information; releasing the network address occupied by the ghost node, deleting all routing data of the ghost node, removing all group / scene / automation binding relationships of the ghost node, and updating the profile of the ghost node.

[0015] In one implementation of the first aspect, the method further includes: updating the profile of the lighting device after it rejoins the smart lighting network; monitoring multiple preset core status indicators of each lighting device in the smart lighting network in real time, and calling the self-healing measure corresponding to the core status indicator when any of the core status indicators is detected to achieve closed-loop self-healing of the smart lighting network.

[0016] Secondly, embodiments of this application provide a bridge compiler, including: a processor and a memory; the memory stores program instructions; the processor is used to run the program instructions to execute the intelligent lighting network node management method described above.

[0017] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the intelligent lighting network node management method as described above.

[0018] Secondly, embodiments of this application provide an intelligent lighting network node management system, including: a bridge-end compiler as described above and multiple lighting devices; wherein, the lighting devices include: a processor and a memory; the memory stores program instructions; the processor is configured to run the program instructions to perform: sending a rejoin request to the bridge-end compiler and establishing a temporary communication link with the bridge-end compiler based on a temporary session key and network parameters returned from the bridge-end compiler; selecting a parent node based on a preferred parent node list received from the bridge-end compiler and establishing a connection relationship with the parent node; requesting and obtaining migration data from the bridge-end compiler and configuring operation according to the migration data.

[0019] The intelligent lighting network node management method, bridge compiler, medium, and system provided in this application have the following beneficial effects:

[0020] This application uses a bridge-end compiler to distribute temporary session keys and dedicated network parameters, quickly establishing temporary communication links. Combined with the allocation of preferred parent nodes supported by historical profiles, it significantly improves the re-entry efficiency of lighting devices and enhances the overall performance of home smart lighting networks. Attached Figure Description

[0021] Figure 1 The diagram shown is an overall flowchart of an intelligent lighting network node management method according to an embodiment of this application.

[0022] Figure 2 The diagram shown illustrates the principle of establishing a temporary communication link in an intelligent lighting network node management method according to an embodiment of this application.

[0023] Figure 3 The diagram shows a flowchart illustrating the generation of a preferred parent node list in a smart lighting network node management method according to an embodiment of this application.

[0024] Figure 4 The flowchart shown is a process for obtaining migration data in a smart lighting network node management method according to an embodiment of this application.

[0025] Figure 5 The diagram shows the timing of lamp re-addition in a smart lighting network node management method according to an embodiment of this application.

[0026] Figure 6 The diagram shown is a topology comparison before and after ghost node cleanup in an intelligent lighting network node management method according to an embodiment of this application.

[0027] Figure 7 The diagram shown is a schematic representation of the overall implementation process of an intelligent lighting network node management method according to an embodiment of this application.

[0028] Figure 8 The diagram shown is a schematic representation of the principle structure of an intelligent lighting network node management system in one embodiment of this application. Detailed Implementation

[0029] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0030] This embodiment provides a smart lighting network node management method, bridge compiler, medium, and system applied to a home smart lighting network. All lighting devices within the smart lighting network communicate with the bridge compiler (bridge) via Zigbee / Thread / Wi-Fi Mesh to construct a mesh network topology. The bridge compiler acts as the master control node, coordinating the entire network. A mobile app remotely controls and configures the lighting devices through the bridge compiler. Addressing the pain points of traditional re-entry processes—cumbersome, time-consuming, prone to failure, and requiring repeated configuration—when lighting devices temporarily disconnect due to power outages or other reasons in home smart lighting scenarios, this embodiment proposes a method for rapid re-entry of lighting devices and network self-healing based on historical profiles. The bridge compiler maintains a unique historical profile for each lighting device. Upon re-entry, a fast access path consisting of a temporary session key, network parameters, and a preferred parent node is provided, simultaneously migrating bound data. Multi-dimensional verification identifies and cleans up ghost nodes, while ensuring the effectiveness of the lighting device's relay function. Ultimately, this achieves the technical effects of rapid re-entry of lighting devices, seamless configuration, and continuous network self-healing.

[0031] The following will refer to the appendices in the embodiments of this application. Figure 1 To be continued Figure 7 This application provides a detailed description of the technical solution for the intelligent lighting network node management method in its embodiments. This allows those skilled in the art to understand and implement the intelligent lighting network node management method of this embodiment without inventive effort.

[0032] This embodiment provides a method for managing smart lighting network nodes, which is applied to a bridge-end compiler. Figure 1 The flowchart shown is a method for managing smart lighting network nodes in an embodiment of this application. Figure 1 As shown, the intelligent lighting network node management method provided in this application embodiment includes the following steps S100 to S400.

[0033] Step S100: In response to receiving a rejoin request from a lighting device, perform lighting device identity verification and security status verification based on the rejoin request;

[0034] Step S200: Generate a temporary session key for the lighting device, configure network parameters, and send them to the lighting device, so that the lighting device establishes a temporary communication link with the bridge compiler based on the temporary session key and the network parameters;

[0035] Step S300: Generate a preferred parent node list based on the historical profile and current network information of the lighting device, and send the preferred parent node list to the lighting device through the temporary communication link;

[0036] Step S400: After the lighting device establishes a connection with the corresponding parent node in the preferred parent node list, migration data is obtained based on the historical profile of the lighting device, and the migration data is sent to the lighting device so that the lighting device runs based on the migration data.

[0037] The following combination Figure 2 and Figure 7 The steps S100 to S400 of the intelligent lighting network node management method in this embodiment will be described in detail.

[0038] In one implementation of this embodiment, a historical profile is established for the lighting device that accesses the lighting network for the first time, and the historical profile is updated when the operating status of the lighting device changes. The historical profile includes a unique identifier for the lighting device, parent-child connection relationships between the lighting device and other lighting devices in the network, link quality parameters between the lighting device and its parent node, lighting device access / communication failure count, heartbeat interaction timestamps between the lighting device and the bridge compiler, historical access channel information, network identifier, configured group / scene / automation binding relationships, and various combinations of relay function activation status.

[0039] In this embodiment, the triggering conditions for establishing the historical profile include, but are not limited to, the following situations:

[0040] 1) When a lighting device successfully connects to the smart lighting network for the first time, the bridge-end compiler automatically initializes the profile;

[0041] 2) When the binding relationship of lighting equipment changes, such as when joining / leaving a group or modifying scene configuration, the profile association fields are updated in real time;

[0042] 3) When the communication status of lighting equipment is abnormal, such as link quality fluctuations or brief disconnections, the profile status field is updated synchronously.

[0043] 4) After the lighting equipment completes the re-entry process, all relevant access data will be updated and updated in a comprehensive manner;

[0044] 5) When the bridge compiler periodically (default interval of 5 minutes, configurable via APP) performs inspections, it will complete any missing or invalid data.

[0045] In this embodiment, the profile of the lighting device is indexed by the unique identifier (UUID) of the lighting device and stored in the local database of the bridge-end compiler (supporting power failure backup), while also being synchronized to the home private cloud (optional). The core fields and parameters of the profile of the lighting device are as follows:

[0046] 1) Basic identity fields: including the unique identifier UUID of the lamp (generated by the MAC address of the lamp + the factory serial number, 128 bits), device model, factory batch, first access time, and most recent access time, used for identity verification and device traceability;

[0047] 2) Connection relationship field (parent-child connection relationship between the lamp and other lamps in the network): historical parent-child node list (including connection duration and disconnection reason of each parent node), current parent-child node ID (empty when not connected), relay node association record (marks whether the lamp has ever acted as a relay for other nodes, and relay duration and forwarded data volume);

[0048] 3) Link quality field (link quality parameters between the lamp and the parent node): the most recent (e.g., 10) link quality sample values ​​(including RSSI signal strength: -30dBm~-100dBm, default qualified threshold ≥-85dBm; packet loss rate: 0%~100%, default qualified threshold ≤5%; latency: 0ms~500ms, default qualified threshold ≤100ms), link quality mean / variance, and best link history.

[0049] 4) Status statistics fields: access failure count (more than 3 consecutive failures in a single instance are marked as abnormal), communication failure count, heartbeat interaction timestamp (the time of the most recent heartbeat reception, accurate to milliseconds), and status before disconnection (normal / abnormal disconnection / security violation).

[0050] 5) Network configuration fields: historical access channel list (adapting to different communication protocols: Zigbee channels 11~26, Thread channels 15 / 20 / 25, Wi-Fi Mesh channels 1 / 6 / 11), commonly used network identifiers (PAN ID / SSID), and the currently configured communication protocol type;

[0051] 6) Binding relationship fields: Group binding list (including group ID, group name, and join time), Scene binding list (including scene ID, scene trigger condition, and associated action), Automation task binding list (including task ID, trigger event, and execution action), Binding relationship status (valid / invalid);

[0052] 7) Relay function fields: Relay function enabled status (on / off), relay load threshold (default 80%, relay will be suspended if exceeded), historical relay performance statistics (forwarding success rate, average load).

[0053] In this embodiment, a combination of real-time updates and periodic completion mechanisms is adopted: Real-time updates: When events such as identity verification, link quality sampling, and binding relationship changes are triggered, the corresponding fields are updated within 100ms; Periodic completion: The bridge-end compiler performs a profile inspection every 5 minutes to clean up invalid data (such as historical connection records that have not been connected for 3 months) and complete missing data (such as unsynchronized heartbeat timestamps) to ensure the timeliness and conciseness of the profile data of lighting equipment.

[0054] Step S100: In response to receiving a rejoin request from the lighting device, perform lighting device identity verification and security status verification based on the rejoin request.

[0055] In this embodiment, the lighting device generates and sends a rejoin request to the bridge compiler when it detects that its own power is cut off and then re-energizes, or when it detects that the communication link with the parent node / bridge compiler is interrupted.

[0056] In this embodiment, the lighting device prioritizes loading locally cached historical network parameters (communication protocols, commonly used channels) and encapsulates the re-entry request data packet according to the standard format of the corresponding protocol (Zigbee / Thread / Wi-Fi Mesh). The re-entry request data packet includes a UUID (unique identifier for the lighting device), a request type (fast re-entry / standard re-entry, with fast re-entry preferred by default), and a status indicator before disconnection (0 = normal disconnection, 1 = abnormal disconnection, 2 = security violation disconnection). The re-entry request data packet is transmitted using AES-128 encryption to prevent the leakage of identity information. The lighting device broadcasts the re-entry request through historical commonly used channels.

[0057] Specifically, in a smart lighting network, if a luminaire experiences a brief disconnection due to a power outage, it will automatically initiate a re-entry function upon power restoration. The luminaire prioritizes following the Zigbee / Thread / Wi-Fi Mesh standard re-entry process to initiate a re-entry request, carrying its unique identifier in the request. After receiving the re-entry request, the bridge-end compiler performs dual verification based on the luminaire's historical profile. The verification standards are adapted to the smart lighting scenario: first, identity verification, matching the luminaire's identifier in the profile to confirm it is a legitimate access device for the smart lighting network; second, security status verification, checking for security violations in the luminaire's historical access history and whether the communication status before the disconnection was normal. If the verification passes, the fast re-entry process begins; if the verification fails, the request is rejected according to the standard process, and the abnormality record is retained.

[0058] In some possible implementations, the lamp identification verification includes:

[0059] Extract the UUID from the data packet and perform an exact match with the UUID in the bridge compiler's local profile database. If the match is successful: confirm that the lamp is a legitimate access device and enter the security status verification; if the match fails: determine that it is an illegal lamp device, reject the request, and send an identity verification failure response to the lamp device (while recording the request source channel and time for security auditing); if the UUID partially matches (the first 64 bits of the UUID match, but the last 64 bits do not match): determine that the lamp device is abnormal, temporarily store the request, and push an abnormal lamp device identity reminder to the mobile APP for the user to confirm whether to allow access.

[0060] In some possible implementations, the security status verification includes:

[0061] Retrieve the status field before disconnection from the lamp's profile. If it indicates a security violation disconnection (such as incorrect password or unauthorized configuration modification) and the violation record has not expired (default expiration time is 24 hours), the request is rejected directly. Verify the lamp's historical security violation records. For example, if the number of violations exceeds 3 in the past 30 days and the user has not manually lifted the restrictions, the request is rejected. Confirm that the lamp is not marked as a deregistered device (devices deleted by the user through the APP are retained in the profile but marked as deregistered, and are permanently denied re-entry into the network).

[0062] Step S200: Generate a temporary session key for the lighting device, configure network parameters, and send them to the lighting device, so that the lighting device establishes a temporary communication link with the bridge compiler based on the temporary session key and the network parameters.

[0063] Figure 2 This diagram illustrates the principle of establishing a temporary communication link in a smart lighting network node management method according to an embodiment of this application. Figure 2 As shown, in one implementation of this embodiment, generating a temporary session key and configuring network parameters for the lighting device includes:

[0064] 1) Generate a temporary session key based on the unique identifier of the lamp, the current timestamp, and a random number, and configure the validity period of the temporary session key;

[0065] 2) Configure the working channel, network identifier, and communication parameters for the lighting equipment; wherein, the working channel is configured based on the historical access channel information and / or the current network channel load.

[0066] In this embodiment, the cumbersome configuration of the Zigbee / Thread / Wi-Fi Mesh standard re-entry process is avoided. A communication link is quickly established through a temporary key and network parameters, which greatly shortens the time for lamps to re-enter the network and reduces the access failure rate.

[0067] In this embodiment, the network parameters are precisely configured for this re-entry scenario, adapted to the corresponding communication protocol, and avoid channel conflicts and network chaos. The specific parameters and configuration logic are as follows:

[0068] 1) Working Channel: Prioritize the channel with the best link quality (RSSI≥-75dBm, packet loss rate≤2%) in the historical access channel list of the lamp profile; if the current congestion of the best channel exceeds 70% (default threshold), then select the second best channel in order; when there is no available historical channel, the bridge compiler allocates the idle channel with the lowest load based on the current network channel load (scanning the number of devices and data transmission volume of each channel).

[0069] 2) Network Identifier: Zigbee / Thread protocol assigns AN ID, Wi-Fi Mesh protocol assigns SSID (consistent with the dedicated SSID for home smart lighting) and child node identifier.

[0070] 3) Communication parameters: including communication baud rate (Zigbee default 250kbps, Thread default 600kbps, Wi-FiMesh default 867Mbps), heartbeat interval (default 30 seconds, configurable), number of data retransmissions (default 3 times), etc.

[0071] Network parameters and temporary session keys are sent synchronously. After receiving them, the lighting equipment completes parameter initialization and then sends a parameter configuration activation response to the bridge compiler.

[0072] Specifically, in this embodiment, for re-entering lighting devices that pass verification, the bridge-end compiler first issues a temporary session key. This key has a limited validity period and only supports the current re-entry process and initial access communication. It automatically expires after the validity period, preventing unauthorized devices from impersonating it. Simultaneously, dedicated network parameters are issued to clearly indicate the working channel and network identifier of the lighting device for this re-entry, adapting to the communication requirements of Zigbee / Thread / Wi-Fi Mesh. After receiving the key and parameters, the lighting device quickly completes initialization and establishes a temporary communication link with the bridge-end compiler. There is no need to perform the complex negotiation process of standard re-entry, which greatly shortens the access time.

[0073] After the lighting equipment completes the key and network parameter configuration, it sends a temporary communication request to the bridge compiler based on the temporary session key encryption. After the bridge compiler decrypts and verifies the validity of the key, it establishes a temporary communication link (the link bandwidth is adapted to the lighting control requirements, with a default of 1Mbps, which is sufficient to meet the transmission of commands such as switching and dimming). After the temporary communication link is established, the lighting equipment suspends the standard re-entry process and completes subsequent parent node association, binding migration and other operations entirely through its own temporary communication link, which greatly shortens the access time (compared to the standard process, the time is reduced from 20-30 seconds to 2-3 seconds).

[0074] Step S300: Generate a preferred parent node list based on the historical profile and current network information of the lighting device, and send the preferred parent node list to the lighting device through the temporary communication link.

[0075] Figure 3 This diagram illustrates the process of generating a preferred parent node list in a smart lighting network node management method according to an embodiment of this application. Figure 3 As shown, in one implementation of this embodiment, generating a preferred parent node list based on the historical profile and current network information of the lighting equipment includes:

[0076] Step S310: Based on the historical parent-child nodes in the historical profile, the link quality in the current network, the relay load, and the number of hops for lighting fixtures, multiple candidate parent nodes are selected.

[0077] The bridge compiler prioritizes filtering candidate parent nodes from the following range:

[0078] 1) Online nodes (normal heartbeat, communication is possible) in the historical parent-child node list of the lamp image;

[0079] 2) Nodes in the current network with acceptable link quality (RSSI ≥ -85dBm, packet loss rate ≤ 5%);

[0080] 3) Nodes whose relay load does not exceed the threshold (default 80%);

[0081] 4) Nodes that are ≤3 hops away from the light fixture (the more hops, the higher the delay; if more than 3 hops, they will be removed).

[0082] If the number of candidate parent nodes after filtering is less than 3, expand to nodes with a hop count of ≤4 hops to ensure the diversity of the candidate list.

[0083] Step S320: Evaluate and sort the multiple candidate parent nodes based on the multi-dimensional evaluation model and multi-dimensional evaluation indicators to generate a list of preferred parent nodes.

[0084] The multi-dimensional evaluation metrics include several of the following: the quality of the nearest link between the luminaire and the candidate parent node, the current network congestion of the candidate parent node, the number of hops from the candidate parent node to the bridge compiler, and the current load of the candidate parent node.

[0085] Configure scoring rules for each evaluation indicator, and calculate the score for each evaluation indicator according to the corresponding scoring rules. For example, the recent link quality is calculated based on the average of the link quality samples of the lamp and the candidate parent node in the most recent 10 times: RSSI≥-75dBm and packet loss rate≤2%, 40 points are obtained; RSSI is in the range of -76~-85dBm and packet loss rate is 3%~5%, 20~39 points are obtained; RSSI<-85dBm or packet loss rate>5%, 0~19 points are obtained.

[0086] The multi-dimensional evaluation model, for example, adopts a weighted summation plus penalty scoring model, where the total score = Σ (score of each evaluation indicator × indicator weight) - penalty score.

[0087] All candidate parent nodes are sorted from highest to lowest total score to generate a preferred parent node list. This list includes the priority (e.g., level 1-5, with level 1 being the highest), core indicator score, and current status (online / idle / busy) of each parent node, facilitating the selection of the best connection for lighting equipment.

[0088] In this embodiment, the preferred parent node list is encrypted and sent to the lighting device through the temporary communication link, along with the connection parameters (node ​​ID, communication channel, encryption key) of each parent node. The bridge compiler synchronously retains the preferred parent node list. If the lighting device fails to associate with the first parent node, the bridge compiler actively pushes a sequence selection instruction, indicating that the lighting device selects a subsequent parent node from the preferred parent node list to ensure the association success rate.

[0089] After receiving the preferred parent node list, the lighting device first initiates an association request directly with the parent node ranked first, and completes the parent-child relationship establishment according to the Zigbee / Thread / Wi-Fi Mesh communication protocol. If the association is successful, it will be fed back to the bridge compiler. If the association fails, it will select the next node in the list in order until the association is successful.

[0090] Specifically, after receiving the preferred parent node list, the lighting device prioritizes selecting a level 1 priority parent node, encapsulates an association request data packet (including its own UUID, temporary session key, and association request identifier), and sends it to the parent node through the corresponding channel. After receiving the request, the parent node sends an association verification request to the bridge compiler. After verifying the lighting device's identity and the validity of the temporary key, the bridge compiler sends an association permission instruction to the parent node. After receiving the instruction, the parent node establishes a parent-child connection with the lighting device and synchronously sends a successful association response to both the bridge compiler and the lighting device.

[0091] If no response is received within a preset time (e.g., 1 second) after the association request is sent, or if an association failure response is received (e.g., a sudden increase in the load on the parent node), the lighting device will automatically switch to a level 2 priority parent node and repeat the association process. If all parent nodes in the preferred parent node list fail to associate, the bridge compiler will trigger an emergency mechanism to temporarily use itself as the parent node (only applicable to scenarios where the bridge compiler and the lighting device have ≤1 hop count) to ensure that the lighting device can access the network.

[0092] Step S400: After the lighting device establishes a connection with the corresponding parent node in the preferred parent node list, migration data is obtained based on the historical profile of the lighting device, and the migration data is sent to the lighting device so that the lighting device runs based on the migration data.

[0093] After a lighting device is successfully associated with its parent node, it sends a binding migration request to the bridge compiler. The request includes its own UUID and the binding type to be migrated (group / scene / automation, multiple selections are allowed). After receiving the request, the bridge compiler retrieves the binding relationship data from the lighting device profile based on the UUID, and organizes the migration dataset in the order of group → scene → automation. The migration dataset contains information such as the ID, name, configuration parameters, effective status, and list of associated devices for each binding relationship. Invalid bindings are marked synchronously (e.g., the scene has been deleted by the user, or the automation task has expired), and will not participate in the migration in the future.

[0094] Figure 4 The flowchart shown is a process for obtaining migration data in a smart lighting network node management method according to an embodiment of this application. For example... Figure 4 As shown, in one implementation of this embodiment, obtaining migration data based on the historical profile of the lighting equipment includes:

[0095] Step S410: In response to receiving a binding migration request from the lighting device, retrieve the binding configuration data from the lighting device's historical profile based on the lighting device's unique identifier, and generate a migration dataset;

[0096] Step S420: Deduplication of duplicate name groups, duplicate name scenarios / automated tasks in the migration dataset is performed to generate migration data.

[0097] In this embodiment, the bridge compiler retrieves the original binding configuration data based on the historical profile of the lamp and performs automatic binding migration. The migration process is adapted to the optimization of smart lighting scenarios: before migration, deduplication is performed on scenes / groups with the same name. If the scene / group with the same name has been bound to other valid lamps, the original valid binding is retained and redundant binding is removed. If the original binding has no conflict, the migration is completed.

[0098] In this embodiment, deduplication of duplicate name groups, duplicate name scenarios / automated tasks in the migration dataset includes:

[0099] 1) Deduplication criteria: The binding name + binding ID is used as the unique identifier. If there are binding relationships with the same name and ID in the same network, they are judged as duplicates.

[0100] 2) Group deduplication: If a group with the same name is already bound to another valid light fixture, the original binding relationship will be retained, and the current light fixture will only be added to the group (without creating a new group); if a group with the same name has no valid binding (the associated devices are all ghost nodes), the original group will be deleted, and the historical configuration will be migrated to the current light fixture's exclusive group.

[0101] 3) Scene / Automation Deduplication: If a scene / automation task with the same name is already associated with other valid lights and the configuration parameters are the same, only add the current light as the associated device; if the configuration parameters are different, create a new scene / task with the original name plus a suffix (re-entry time), migrate the historical configuration, and push a duplicate name reminder to the mobile APP, allowing the user to choose whether to merge.

[0102] After deduplication, redundant binding data is removed, generating a deduplicated migration dataset, and deduplicated records are labeled (including the deleted redundant binding IDs and retained binding information). The migration data is then sent to the lighting equipment: the bridge-end compiler encrypts and sends the deduplicated migration dataset to the lighting equipment via a temporary communication link. The migration data is transmitted in fragments (each fragment ≤ 1KB to avoid transmission timeouts), and each fragment is accompanied by a checksum (MD5) to ensure data transmission integrity.

[0103] After receiving the migration data, the lighting equipment loads the configuration in the order of group → scene → automation, restarts the control module to make the configuration effective, and then stores the configuration in the local cache (supports power failure backup).

[0104] After the migration is completed, the bridge-end compiler sends a migration receipt to the lighting fixture. After receiving the receipt, the lighting fixture verifies the integrity of the data. If the verification passes, it sends a confirmation to the bridge-end compiler. If the verification fails, it triggers a migration retransmission, ensuring that the lighting fixture can restore its original control functions without manual configuration after re-entering the network.

[0105] Specifically, after the lighting configuration takes effect, a migration receipt data packet is generated. The receipt includes: migration completion status (success / failure), number of migration binding entries, deduplication records, checksums for each binding configuration (consistent with the checksums issued by the bridge compiler), and any missing binding entries (if any). After receiving the receipt, the bridge compiler performs dual checks: quantity check: compares the number of binding entries in the receipt with the number issued to confirm that there are no missing entries; checksum check: compares the checksums for each binding configuration to confirm that the configuration parameters are consistent.

[0106] Verification passed: The bridge compiler sends a migration success command to the luminaire and updates the binding relationship field and access status (marked as normal access) in the luminaire profile; Verification failed: If the failure is due to missing data, the bridge compiler triggers the migration retransmission mechanism to resend the missing binding data; If the failure is due to inconsistent checksums, the luminaire's local misconfiguration is deleted, and the complete migration process is re-executed. The retransmission can be done up to 3 times. If it still fails, a migration exception reminder is pushed to the mobile APP, and the user can manually trigger the migration.

[0107] In this embodiment, duplicate names are removed before migration and receipt verification is performed after migration. After the lighting equipment re-enters the network, the original group / scene / automation configuration is automatically restored without manual operation by the user, thus improving the user experience of smart home lighting.

[0108] like Figure 5 As shown, in one implementation of this embodiment, the method further includes detecting and recovering ghost nodes in the smart lighting network, including:

[0109] 1) Ghost Node Detection: Ghost nodes are identified based on whether heartbeat response information is received from the lighting fixtures for multiple consecutive polling cycles, multi-cycle no-heartbeat interaction data recorded in the lighting fixture's historical profile, data transmission and reception information of the lighting fixtures, and polling response information. Specifically, if the lighting fixture's historical profile records multiple cycles of no heartbeat interaction, no data transmission and reception, and no polling response, exceeding a preset disconnection threshold, it is confirmed as a ghost node.

[0110] 2) Reclaim ghost nodes: Release the network address occupied by the ghost node, delete all routing data of the ghost node, remove all group / scene / automation binding relationships of the ghost node, and update the profile of the ghost node.

[0111] In this embodiment, while processing the re-entry process of lighting fixtures, the bridge-end compiler relies on the historical profiles of lighting fixtures and the intelligent lighting network polling mechanism to monitor the status of all lighting fixtures in the network in real time, accurately identify and clean up ghost nodes.

[0112] The bridge-end compiler periodically performs polling communication on all lights in the network. This confirms whether the lights are online and controllable, and also verifies the availability of relay functionality for online lights. The polling records are synchronously updated to the historical profile. In this embodiment, the intelligent lighting network polling mechanism includes:

[0113] 1) Polling cycle and scope: The bridge compiler performs a full network polling at a preset cycle. The polling scope covers all connected lighting devices (including valid nodes in the historical profile). The polling order is sorted from closest to furthest from the bridge compiler by the number of hops to avoid network congestion.

[0114] 2) Polling data packet structure: It includes polling instructions (status query / relay check), bridge compiler ID, and polling timestamp. It adopts lightweight encapsulation (data packet size ≤ 64 bytes) to reduce network transmission burden.

[0115] 3) Polling response requirements: After receiving the polling command, the lighting equipment shall send back a response data packet, including its own UUID, current status (online / offline / fault), link quality, relay function status, and load status; if the lighting equipment does not send back a response, the bridge compiler shall poll it multiple times (e.g., 3 times, with an interval of 5 seconds). If there is still no response, it shall be marked as disconnected.

[0116] Furthermore, in this embodiment, the passive scan results from the bridge-end compiler are combined to detect no communication signal from the lighting device, thus avoiding misjudgment due to signal obstruction. For example, the bridge-end compiler initiates a passive scan (the scan frequency is consistent with the polling period, covering all communication channels), and no communication signal from the lighting device is detected after three consecutive scans; if a signal is detected but there is no response, it is determined to be a faulty node (not a ghost node), and a fault alert is pushed to the user's mobile APP.

[0117] Once a node is identified as a ghost node, the bridge-side compiler marks it as a ghost node in the image, records the time and reason for the identification, and provides a basis for subsequent cleanup.

[0118] In this embodiment, the ghost node cleanup and resource recycling process includes:

[0119] 1) Pre-cleanup confirmation: The bridge compiler sends a final disconnection confirmation request to the ghost node (broadcast, 3 times consecutively). If there is no response, the cleanup operation is performed to avoid accidental cleanup.

[0120] 2) Resource recycling operations:

[0121] 2-1) Address release: Release the network address (such as Zigbee short address, IP address) occupied by the node and add the address to the free address pool for new device access or address allocation for other devices.

[0122] 2-2) Route cleanup: Delete all routing data (including parent-child routes and relay routes) of the node, update the routing table of the entire network, and ensure that the route forwarding path does not point to the ghost node.

[0123] 2-3) Binding and Unbinding: Remove all group / scene / automation binding relationships for this node, delete redundant binding data, and avoid affecting the binding function of other devices.

[0124] 2-4) Profile processing: Mark the lamp node profile as a failed node, retain core identity information (for easy reconnection later), delete redundant data (such as historical link quality, binding records), and reduce database storage pressure.

[0125] After the cleanup is complete, the bridge-side compiler can push ghost node cleanup notifications to users via a mobile app, including the node ID, the reason for cleanup, and the released resource information. At the same time, based on the current network link quality and node status, the Dijkstra algorithm is used to reallocate routes, prioritizing nodes with low relay load and good link quality to undertake relay functions, ensuring smooth mesh network communication.

[0126] In this embodiment, ghost nodes can be accurately cleaned up: multi-cycle heartbeat + passive scanning dual judgment avoids the accidental deletion of valid nodes, releases redundant addresses and routing resources, and reduces network burden.

[0127] Figure 6 This diagram illustrates a topology comparison before and after ghost node cleanup in an intelligent lighting network node management method according to an embodiment of this application. Figure 6 As shown, the topology before cleanup had the following key issues due to the presence of ghost nodes, affecting network operating efficiency:

[0128] 1) Redundant and chaotic topology: Ghost nodes are attached to the topology, retaining invalid connections and forming redundant link branches, increasing the complexity of bridge compiler management; 2) Communication link failure: The routing table retains paths pointing to ghost nodes, causing effective lighting communication to detour, exceed the latency limit (over 100ms), or even fail; 3) Network resource occupation: Ghost nodes occupy network addresses and storage resources, leading to a shortage of free addresses and an increased burden on bridge compiler management; 4) Relay function imbalance: If it is a historical relay node, it is easy to cause the effective relay load to be too high (over 80% threshold), causing local network congestion; 5) Decreased stability: The bridge compiler polls ghost nodes, consuming bandwidth, which can easily cause network status judgment errors and miss real communication anomalies.

[0129] After ghost node cleanup, the bridge-side compiler performs operations such as address release, route deletion, and route reallocation, resulting in comprehensive topology optimization: 1) Concise and clear topology: Ghost nodes and invalid links are removed, retaining only valid nodes and normal connections, making management logic clearer; 2) Efficient and smooth communication: Routes are reconstructed using the Dijkstra algorithm, planning optimal links (hop count ≤ 3 hops), reducing latency; 3) Comprehensive resource release: Idle addresses and redundant data are reclaimed, ensuring access for new devices and reducing the management pressure on the bridge-side compiler; 4) Relay load balancing: Relay tasks are redistributed to high-quality nodes, avoiding single-node overload and ensuring no blind spots in relay coverage; 5) Enhanced self-healing capability: Improved accuracy of valid node monitoring, rapid response to anomalies and triggering self-healing, effectively improving the success rate of lighting control.

[0130] In one implementation of this embodiment, the method further includes: updating the profile of the lighting device after it rejoins the smart lighting network; monitoring multiple preset core status indicators of each lighting device in the smart lighting network in real time; and calling the self-healing measure corresponding to the core status indicator when any of the core status indicators is detected to achieve closed-loop self-healing of the smart lighting network.

[0131] This step achieves a closed loop of profile updates, status monitoring, and network self-healing, and clarifies profile update fields, anomaly judgment criteria, rollback mechanisms, and security hardening rules to ensure long-term stable network operation.

[0132] In this embodiment, after the luminaire completes its re-entry into the network and the binding migration verification passes, the profile is updated in real time. Subsequently, dynamic fields such as link quality, load, and heartbeat timestamp are updated synchronously every minute. The updated fields include, but are not limited to: ① Connection relationship field: update the current parent and child node IDs, association time, and link quality sampling value; ② Status statistics field: reset the access failure count, update the most recent access time and heartbeat timestamp; ③ Binding relationship field: update the list of binding relationships after migration and deduplicated records; ④ Relay function field: update the relay function enabled status and current load; ⑤ New field: record the time taken for this re-entry into the network, the number of times the parent node is associated, and the binding migration success rate, providing data support for subsequent optimization.

[0133] In this embodiment, the lighting device profile is updated by first updating the local database and then synchronizing it to the cloud. Locking is used during the update process to avoid data conflicts. After the update is completed, the bridge compiler sends a profile update confirmation command to the lighting device, and the lighting device synchronously updates the locally cached profile summary information.

[0134] Therefore, in this embodiment, after the lighting device rejoins the smart lighting network, the profile of the lighting device is updated: after the lighting device completes the re-entry into the network, and the binding migration verification passes and the smart lighting network is stably connected, the bridge-end compiler updates its historical profile in real time, and synchronously records the parent node information, access link quality, re-entry time, relay function activation status, etc., covering the original failed data and ensuring the timeliness of the profile.

[0135] In this embodiment, the preset core status indicators include, but are not limited to, link quality (RSSI, packet loss rate, latency), communication status (online / offline / disconnected), relay load, and binding relationship validity; simultaneously, the overall network status (channel congestion, routing success rate, number of connected devices) is monitored. Preset anomaly detection thresholds are set, such as: link quality continuously below the acceptable threshold for 10 seconds (RSSI < -85dBm, packet loss rate > 5%), communication disconnections exceeding 2 times / minute, relay load exceeding 80% for 30 seconds, and binding relationship failure exceeding 5 minutes.

[0136] In this embodiment, the self-healing measures corresponding to the core state indicator are invoked to achieve closed-loop self-healing of the intelligent lighting network. The specific implementation is as follows:

[0137] 1) Link anomaly fallback and reselection: If the link quality of a certain lamp is detected to be continuously declining and exceeding the threshold, or if communication is frequently disconnected, the bridge compiler will automatically trigger the link fallback mechanism, re-execute the parent node scoring and selection process, and assign a new parent node to the lamp; after the new parent node is successfully associated, the routing table and profile data will be updated to ensure the stability of the communication link.

[0138] 2) Congestion mitigation optimization: If the congestion level of a certain channel is detected to exceed 70%, the bridge-side compiler analyzes the cause of congestion (such as too many devices or large data transmission volume), sends channel switching instructions to some lights in that channel, allocates idle channels, and alleviates congestion; at the same time, it adjusts the heartbeat interval (extended to 60 seconds when congested, and restored to 30 seconds when idle) to reduce network load.

[0139] 3) Binding relationship repair: If a binding relationship of a certain lamp is detected to be invalid (such as scene configuration loss or abnormal group association), the bridge compiler will automatically retrieve the historical binding data in the image, trigger the binding migration and retransmission mechanism, and repair the invalid binding; after the repair is completed, the configuration is verified through receipt to ensure that the configuration is complete;

[0140] 4) Relay function optimization: If the load of a relay node is detected to exceed the threshold, the bridge compiler will pause its relay function and switch to other idle relay nodes; at the same time, the relay load record in the profile will be updated, and high-load relay nodes will be avoided in subsequent parent node selection.

[0141] To address abnormal retry scenarios during the re-entry of lighting fixtures into the network, this embodiment employs an exponential backoff strategy for abnormal retrying. The retry interval increases by a preset multiple to avoid network congestion caused by frequent retries. The exponential backoff strategy works as follows: During the re-entry of a lighting fixture into the network (e.g., parent node association failure, binding migration failure), an exponential backoff strategy is activated, with the retry interval increasing by multiples of the initial interval from 1 second to 2 seconds to 4 seconds to 8 seconds to 16 seconds, with a maximum interval of 30 seconds, to avoid network congestion caused by frequent retries. If five consecutive retries fail, the re-entry is paused and retried after one minute. The bridge-side compiler continuously monitors the communication status, link quality, and relay load of the lighting fixtures. If it detects a continuous decline in link quality exceeding a threshold or frequent communication interruptions, it automatically triggers a link fallback mechanism, re-executing the multi-dimensional scoring and optimization process for parent nodes to reassign parent nodes to the lighting fixtures. Combined with ghost node cleanup, route reallocation, and binding deduplication, a continuous self-healing closed loop is formed in the intelligent lighting mesh network, ensuring stable operation of the entire network.

[0142] Figure 7 This diagram illustrates the overall implementation principle of an intelligent lighting network node management method according to an embodiment of this application. Figure 7As shown, this embodiment enables smart lighting devices to quickly re-enter the network and achieve network self-healing. The overall implementation process is based on the bridge-end compiler and supported by historical profiles, forming a closed-loop process, as detailed below:

[0143] 1) Initialization preparation: The bridge-end compiler builds a unique historical profile for each lamp (including 7 major categories of fields such as identity, connection relationship, and binding configuration), and adopts a real-time update + periodic completion mechanism to provide data support for subsequent processes.

[0144] 2) Re-entry Trigger and Verification: After a lamp is powered off and then powered on again or the disconnection exceeds the threshold, an encrypted re-entry request is automatically initiated; after receiving the request, the bridge compiler performs dual verification of identity and security, and rejects the access of illegal / non-compliant devices.

[0145] 3) Rapid access and networking: After verification, the bridge compiler issues a temporary session key and exclusive network parameters to establish a temporary communication link; then, the parent node is selected through multi-dimensional scoring, and the lamp completes the association and access to the mesh network. If it fails, the selection is made in order or the bridge compiler is used as an emergency backup.

[0146] 4) Binding configuration migration: The bridge compiler automatically retrieves the historical binding data of the lamps (groups / scenes / automation), performs duplicate name removal, and distributes the data in segments. The lamps load the configuration and it takes effect. The data integrity is ensured through receipt verification, without the need for manual operation by the user.

[0147] 5) Ghost node optimization: The bridge-side compiler polls all lights on the network and uses passive scanning to double-identify ghost nodes (multiple periods of no response, no signal), cleans them up, releases resources, reconstructs routes, and optimizes the topology.

[0148] 6) Continuous self-healing and adaptation: Real-time updates of lamp profiles, continuous monitoring of link quality, load and other statuses, triggering self-healing operations such as link reselection and congestion mitigation; compatible with multiple communication protocols, and able to handle special situations such as bridge compiler restarts and lamp failures, ensuring long-term stable network operation.

[0149] The entire implementation process is fully automated, requiring no manual intervention, and achieves the core objectives of rapid network access, functional recovery, topology optimization, and continuous self-healing, significantly improving the efficiency and stability of intelligent lighting systems.

[0150] As can be seen from the above, this embodiment addresses the technical pain points in smart lighting networks, such as the cumbersome, time-consuming, and prone-to-failure process of traditional re-entry procedures after lighting devices temporarily disconnect due to power outages or other reasons. These issues include repetitive configuration operations, redundancy of ghost nodes, unstable links, and weak self-healing capabilities. The embodiment employs a technical solution driven by bridge-side historical profiles, a rapid re-entry path, binding migration, ghost node cleanup, and network self-healing, achieving multiple significant benefits and comprehensively improving the efficiency, stability, security, and ease of use of the smart lighting system.

[0151] 1) Significantly improve re-entry efficiency: By using a temporary key and a preferred parent node for rapid access, the re-entry time is reduced from 20-30 seconds to 2-3 seconds, with a success rate of over 99%. This avoids the cumbersome problems of traditional processes and is fully automated without user intervention.

[0152] 2) Ensure seamless integration of functions: Automatically completes group / scene / automation binding migration, front-end deduplication + post-end verification ensures complete and non-redundant configuration, and the original control functions are restored immediately after the lights re-enter the network.

[0153] 3) Enhance network security and stability: dual identity verification + temporary key encryption to prevent unauthorized access; multi-dimensional selection of parent nodes to ensure link stability; periodic polling to confirm the effectiveness of relay function; and adaptation to multiple communication protocols.

[0154] 4) Optimize network resources and self-healing capabilities: Dual judgment accurately identifies ghost nodes and cleans up redundant resources to alleviate congestion; constructs an anomaly monitoring-dynamic adjustment-self-healing closed loop to adapt to complex home environments and special working conditions.

[0155] 5) Reduced costs and easy industrialization: Full-process automated management and control, no need for professional operation and maintenance; compatible with existing hardware architecture, low transformation cost, can be iteratively optimized based on lighting equipment profile data, easy to promote and implement.

[0156] The scope of protection of the intelligent lighting network node management method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, deleting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0157] This application provides a bridge compiler, including: a processor and a memory; the memory stores program instructions; the processor is used to run the program instructions to execute the intelligent lighting network node management method described above. The intelligent lighting network node management method has already been described in detail above, and will not be repeated here.

[0158] The memory is used to store computer programs; preferably, the memory includes various media that can store program code, such as ROM, RAM, magnetic disk, USB flash drive, memory card or optical disk.

[0159] Specifically, the memory may include computer system readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory. The bridge compiler may further include other removable / non-removable, volatile / non-volatile computer system storage media. The memory may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0160] The processor is connected to the memory and is used to execute the computer program stored in the memory, so that the bridge-end compiler executes the intelligent lighting network node management method provided in any embodiment of this application.

[0161] Optionally, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0162] Optionally, in this embodiment, the bridge-end compiler may also include a display. The display is communicatively connected to the memory and the processor, and is used to display the relevant GUI interactive interface of the smart lighting network node management method.

[0163] This application provides an intelligent lighting network node management system. Figure 8 The diagram shown is a schematic representation of the principle structure of an intelligent lighting network node management system according to one embodiment of this application. Figure 8 As shown, in this embodiment, the intelligent lighting network node management system 100 includes: the bridge compiler 110 as described above and a plurality of lighting devices 120; the intelligent lighting network node management method executed by the bridge compiler 110 has been described in detail above, and will not be repeated here.

[0164] In this embodiment, the lighting device 120 includes a processor and a memory; the memory stores program instructions; the processor is used to execute the program instructions to perform the following: sending a rejoin request to the bridge compiler 110 and establishing a temporary communication link with the bridge compiler 110 based on the temporary session key and network parameters returned from the bridge compiler 110; selecting a parent node based on the preferred parent node list received from the bridge compiler 110 and establishing a connection relationship with the parent node; requesting and obtaining migration data from the bridge compiler 110 and configuring operation according to the migration data. The execution process of the lighting device 120 has been described in detail above and will not be repeated here.

[0165] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the intelligent lighting network node management method provided in any embodiment of this application.

[0166] In this embodiment, any combination of one or more storage media can be used. The storage medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0167] In summary, this application rapidly establishes temporary communication links by issuing temporary session keys and dedicated network parameters at the bridge end. Combined with the optimal parent node allocation supported by historical data profiles, this significantly improves the re-entry efficiency of lighting devices and enhances the overall performance of the home smart lighting network. Therefore, this application effectively overcomes the various shortcomings of existing technologies and possesses high industrial applicability.

[0168] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A smart lighting network node management method applied to a bridge-side compiler, characterized in that, Comprising: In response to receiving a re-joining request of a luminaire device, performing luminaire identity verification and security state verification on the luminaire device based on the re-joining request; Generating a temporary session key for the luminaire device and configuring network parameters and downlink to the luminaire device, so that the luminaire device establishes a temporary communication link with a bridge-side compiler based on the temporary session key and the network parameters; Generating a preferred parent node list based on the historical profile of the luminaire device and the current network information, and sending the preferred parent node list to the luminaire device through the temporary communication link; After the luminaire device establishes a connection relationship with the corresponding parent node in the preferred parent node list, obtaining migration data based on the historical profile of the luminaire device, and downlinking the migration data to the luminaire device, so that the luminaire device runs based on the migration data; Further comprising: establishing the historical profile for the luminaire device first accessing the lighting network, and updating the historical profile when the running state of the luminaire device changes; Wherein, the historical profile includes a combination of multiple types of luminaire unique identity, parent-child connection relationship between the luminaire and other luminaires in the network, link quality parameters between the luminaire and the parent node, luminaire access / communication failure count, heartbeat interaction timestamp between the luminaire and the bridge-side compiler, historical access channel information, network identifier, configured group / scene / automation binding relationship, relay function enabled state; Generating a preferred parent node list based on the historical profile of the luminaire device and the current network information includes: Filtering multiple candidate parent nodes based on historical parent-child nodes in the historical profile, link quality in the current network, relay load, and luminaire hop count; Evaluating and sorting multiple candidate parent nodes based on a multi-dimensional evaluation model and multi-dimensional evaluation indicators to generate a preferred parent node list; wherein the multi-dimensional evaluation indicators include multiple types of recent link quality between the luminaire and the candidate parent node, candidate parent node current network congestion, candidate parent node hop count to the bridge-side compiler, and candidate parent node current load.

2. The intelligent lighting network node management method of claim 1, wherein, The temporary session key for the luminaire device includes: Generating a temporary session key based on the luminaire unique identity, current timestamp, and random number, and configuring the validity period of the temporary session key; Configuring the working channel, network identifier, and communication parameters for the luminaire device; wherein the working channel is configured based on the historical access channel information and / or current network channel load.

3. The intelligent lighting network node management method of claim 1, wherein, The migration data based on the historical profile of the luminaire device includes: In response to receiving a binding migration request from the luminaire device, retrieving binding configuration data in the luminaire historical profile based on the luminaire unique identity to generate a migration data set; De-duplicating the duplicate group, scene / automation task in the migration data set to generate migration data.

4. The intelligent lighting network node management method of claim 1, wherein, Further comprising detecting and recycling ghost nodes in the intelligent lighting network, comprising: Determine the ghost node based on whether the light fixture heartbeat response information is received in a plurality of consecutive polling cycles, the multi-cycle no heartbeat interaction data information recorded in the light fixture historical profile, the light fixture device data transceiving information, and the polling response information; Release the network address occupied by the ghost node, delete all routing data of the ghost node, remove all group / scene / automation binding relationships of the ghost node, and update the profile of the ghost node.

5. The intelligent lighting network node management method of claim 1, wherein, Further comprising: After the light fixture device re-joins the intelligent lighting network, update the profile of the light fixture device; Real-time monitoring of the preset plurality of core state indicators of each light fixture device in the intelligent lighting network, and when any of the core state indicators is detected to be abnormal, invoking the self-healing measure corresponding to the core state indicator to realize the closed-loop self-healing of the intelligent lighting network.

6. A bridge end compiler characterized in that, Comprise: A processor and a memory; The memory stores program instructions; The processor is configured to execute the program instructions to perform the intelligent lighting network node management method according to any one of claims 1 to 5.

7. A computer readable storage medium characterized by A computer program is stored thereon, which is executed by a processor to implement the intelligent lighting network node management method according to any one of claims 1 to 5.

8. A smart lighting network node management system, characterized by Comprise: The bridge compiler and a plurality of light fixture devices according to claim 6; wherein the light fixture devices comprise: a processor and a memory; the memory stores program instructions; and the processor is configured to execute the program instructions to perform: Send a re-joining request to the bridge compiler and establish a temporary communication link with the bridge compiler based on the temporary session key and network parameters returned from the bridge compiler; Select a parent node based on the preferred parent node list received from the bridge compiler and establish a connection relationship with the parent node; Request and obtain migration data from the bridge compiler, and configure and run according to the migration data.

Images