Intelligent lighting device group management and location mapping method and system

Abstract

A kind of intelligent lighting device group management and position mapping method and system, the method includes: receiving group configuration information containing group identification, device quantity and the position configuration parameter of each device, the hash value of the physical address of each device is contained in position configuration parameter;According to the information, create device group and distribute group identification;Each device calculates own hash value and is compared with the hash value in configuration, and the device that matches index 0 is determined as master device, and the device that matches index 1 to N is slave device;Master device generates only the data packet containing the position configuration parameter of each slave device, and sends to all slave devices by multicast mode;After receiving, slave device parses and traverses each parameter, compares own hash value with the hash value in package, extracts corresponding X coordinate, Y coordinate, rotation angle and mirror mark when matching succeeds, and configures the coordinate system of this device according to it.The present application realizes the grouping management and position mapping of multiple devices, supports dynamic configuration and flexible adjustment.

Description

Technical Field

[0001] This invention relates to intelligent lighting technology, and in particular to a method and system for intelligent lighting device group management and location mapping. Background Technology

[0002] With the development of smart home and commercial lighting technologies, users have placed higher demands on the management and control of smart lighting devices. In some complex application scenarios, such as large commercial venues, stage lighting, and festival decorations, it is often necessary to control dozens or even hundreds of smart lighting devices simultaneously, and these devices need to work collaboratively according to specific positional relationships.

[0003] In existing technologies, group management of smart lighting devices typically employs a simple grouping approach, assigning the same control parameters to devices within each group to achieve simple synchronous control. This approach suffers from the following problems: 1. Lack of location information management: Existing technologies only focus on the control parameters of the equipment and ignore the location information of the equipment, making it impossible to achieve location-based differentiated control.

[0004] 2. Inflexible location mapping: The location configuration of the device is usually fixed inside the device and cannot be dynamically adjusted, making it difficult to adapt to the needs of different scenarios.

[0005] 3. Unclear master-slave relationship: In multi-device collaboration scenarios, the lack of a clear division of master and slave device roles leads to chaotic control logic.

[0006] 4. Poor group scalability: Existing group management technologies do not support dynamic addition or removal of devices, resulting in poor scalability.

[0007] In summary, existing technologies for intelligent lighting device group management suffer from problems such as lack of location information management, inflexible location mapping, unclear master-slave relationships, and poor group scalability, failing to meet the needs of multi-device collaborative work in complex scenarios. Therefore, it is necessary to provide an intelligent lighting device group management and location mapping method that can achieve device group management, dynamic location mapping, and flexible master-slave role configuration to overcome the aforementioned shortcomings.

[0008] It should be noted that the information disclosed in the background section above is only for understanding the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0009] The main objective of this invention is to overcome the deficiencies in the aforementioned background technology and provide a method and system for intelligent lighting device group management and location mapping.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: A method for intelligent lighting device group management and location mapping includes the following steps: S1. Receive group configuration information, which includes group identifier, number of devices, and location configuration parameters of each device in the group. The location configuration parameters of each device include the hash value of the device's physical address. S2. Create a device group based on the group configuration information, and assign a unique group identifier to the group; S3. Each device calculates the hash value of its own physical address, traverses the device location configuration parameters in the group configuration information, and compares its own hash value with the hash value in the location configuration parameters to determine its index position in the group: if it matches index 0, it is confirmed as a master device; if it matches indices 1 to N, it is confirmed as a slave device, where N is the number of slave devices. S4. The master device generates a location configuration data packet based on the group configuration information. This data packet contains only the location configuration parameters of each slave device and does not contain the location configuration parameters of the master device itself. S5. The master device sends the location configuration data packet to all slave devices in the group via multicast; S6. Each slave device receives the location configuration data packet, parses it to obtain the number of slave devices in the data packet, and iterates through the location configuration parameters of each slave device, comparing the device hash value carried therein with the hash value of its own physical address; S7. When the hash value matches successfully, the current slave device extracts the corresponding location configuration parameters from the location configuration data packet. The location configuration parameters include X coordinate, Y coordinate, rotation angle, and mirror flag. S8. Each slave device configures its coordinate system according to the extracted position configuration parameters.

[0011] A smart lighting device group management system includes: The group creation module is configured to receive group configuration information, create device groups based on the configuration information, assign a unique group identifier to the group, and save the group configuration to local storage. The identification allocation module is configured to calculate the hash value of each device's own physical address, traverse the device location configuration parameters in the group configuration information, and determine the index position of each device in the group by comparing the hash values, thereby identifying the master device and the slave device; The configuration generation module can be set in the master device and configured to generate a location configuration data packet based on the group configuration information. This data packet only contains the location configuration parameters of each slave device and does not contain the configuration of the master device itself. A multicast sending module can be set in the master device and configured to send the location configuration data packet to all slave devices in the group via multicast. The configuration parsing module can be set in each slave device, configured to receive the location configuration data packet, parse the data packet header, group identifier and number of slave devices, and traverse the location configuration parameters of each slave device; The parameter extraction module can be set in each slave device and configured to compare the parsed device hash value with the hash value of its own physical address. When the match is successful, the corresponding X coordinate, Y coordinate, rotation angle and mirror flag are extracted. The coordinate configuration module is located in each slave device and is configured to configure the coordinate system of the device according to the extracted position configuration parameters, including the starting pixel position, display direction rotation correction and horizontal mirror correction.

[0012] The intelligent lighting device group management and location mapping method and system provided by this invention have significant advantages over the prior art.

[0013] This invention achieves multi-device group management and location-based differentiated control by assigning a unique device location identifier to each device within a group and storing its mapping relationship with its physical address, thus solving the problem of lacking location information management in existing technologies. Each device automatically identifies the master and slave devices by calculating the hash value of its own physical address and comparing it with the hash value in the group configuration, clearly defining the master and slave roles within the group and avoiding control logic confusion. Secondly, the master device generates a data packet containing only the slave device's location parameters based on the group configuration information and efficiently distributes it to all slave devices in the group via multicast. Upon receiving the packet, the slave device parses and extracts its own location configuration parameters to complete the coordinate system configuration. The entire process boasts high communication efficiency, accurate configuration distribution, and supports dynamic adjustment of device positions without requiring firmware re-flashing, greatly improving the flexibility of location mapping.

[0014] Furthermore, this invention employs the DJB2 hash algorithm to generate device identifier hash values, which boasts high computational efficiency and a low collision rate, making it particularly suitable for resource-constrained embedded MCU environments. Simultaneously, the hash matching mechanism ensures that configuration parameters are only sent to the target device, improving system reliability and security. In addition, this invention supports location configuration deletion operations. The master device sends a deletion notification packet via multicast, and all devices in the group synchronously clear the corresponding configuration, ensuring consistency in configuration management. Through a delayed write timer mechanism in Flash storage management, configuration information is persistently stored after changes, and the coordinate system can be automatically restored after the device powers on, achieving power-off save and rapid recovery of configuration.

[0015] Furthermore, in response to resource constraints in practical applications, this invention optimizes the maximum number of devices in a single group (determined by the upper limit of the communication protocol data packet length) and the maximum number of groups per device (determined by the balance between memory resources and feature richness), which meets the needs of most scenarios while ensuring stable system operation.

[0016] In summary, this invention effectively overcomes the shortcomings of existing technologies, such as inflexible position mapping, unclear master-slave relationships, and poor group scalability. It is particularly suitable for group collaborative control scenarios of various intelligent lighting devices, such as smart light strips, smart bulbs, and smart panels.

[0017] Other beneficial effects of the embodiments of the present invention will be further described below. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system architecture according to an embodiment of the present invention; Figure 2 A schematic diagram illustrating the location configuration data packet format in an embodiment of the present invention; Figure 3a This is a flowchart of the DJB2 hash algorithm according to an embodiment of the present invention; Figure 3b This is a schematic diagram illustrating the DJB2 hash algorithm calculation and application process according to an embodiment of the present invention. Figure 4 A flowchart illustrating the location configuration in an embodiment of the present invention; Figure 5 This is a flowchart illustrating the deletion location in an embodiment of the present invention; Figure 6 This is a flowchart illustrating the Flash storage management process according to an embodiment of the present invention. Figures 7a to 7b A complete flowchart of configuration generation and transmission for an embodiment of the present invention; Figure 8 is a flowchart of group creation according to an embodiment of the present invention; Figure 9 is a flowchart of the identifier allocation process according to an embodiment of the present invention; Figure 10 This is a flowchart illustrating the multicast transmission process according to an embodiment of the present invention. Figure 11 This is a flowchart of the slave device processing according to an embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the present invention will be described in detail below. It should be emphasized that the following description is merely exemplary and not intended to limit the scope and application of the present invention.

[0020] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] This invention aims to address the shortcomings of inflexible location mapping and unclear master-slave relationships in existing intelligent lighting group management systems. It proposes a method and system for intelligent lighting device group management and location mapping, establishing a self-identification mechanism based on device physical address hash matching: each device automatically distinguishes its master / slave role by comparing its own hash value with the hash value in the group configuration. The master device only encapsulates the location configuration parameters of each slave device into a location configuration data packet and distributes it via multicast. After parsing and matching, the slave devices autonomously complete the coordinate system configuration. Therefore, no firmware re-programming is required, enabling dynamic mapping and flexible adjustment of location information, high communication efficiency, and accurate configuration distribution, making it particularly suitable for resource-constrained embedded multi-device collaborative lighting scenarios.

[0022] See Figures 1 to 11 This invention provides a method for intelligent lighting device group management and location mapping, with the following specific implementation steps: Step S1: Receive group configuration information, which includes a group identifier, the number of devices, and location configuration parameters for each device within the group. Each device's location configuration parameter includes the hash value of its physical address. Specifically, this configuration information can be issued by the control terminal and used as the basis for device grouping and location mapping.

[0023] Step S2: Create device groups based on the group configuration information and assign a unique group identifier to each group. Using a unique group identifier distinguishes different groups and ensures the independence of multi-group management.

[0024] Step S3: Each device calculates the hash value of its own physical address, traverses the device location configuration parameters in the group configuration information, and compares its own hash value with the hash value in the location configuration parameters to determine its index position in the group: if it matches index 0, it is confirmed as a master device; if it matches indices 1 to N, it is confirmed as a slave device, where N is the number of slave devices.

[0025] In some embodiments, the hash value of the device physical address in steps S1 and S3 is generated using the DJB2 hash algorithm, which includes: setting an initial hash value; traversing each character in the device identifier string; for each character, shifting the current hash value to the left by a given number of bits and adding the current hash value, plus the encoded value of the current character, to obtain a new hash value; and returning the hash value after traversal.

[0026] Step S4: The master device generates a location configuration data packet based on the group configuration information. This data packet contains only the location configuration parameters of each slave device and does not contain the location configuration parameters of the master device itself.

[0027] In some embodiments, the process of generating the location configuration data packet in step S4 includes: the master device calculates the number of slave devices based on the total number of devices in the group configuration information, allocates data packet memory, sequentially writes the data packet header identifier, group identifier, and number of slave devices, skips the master device configuration at index 0 in the group configuration information and sequentially extracts the location configuration parameters of each slave device and writes them into the data packet, calculates the checksum and writes it to the end of the data packet, and finally sends the data packet via multicast.

[0028] In step S5, the master device sends the location configuration data packet to all slave devices in the group via multicast. Specifically, local area network multicast transmission can be used to achieve efficient distribution of configuration information to all slave devices in the group.

[0029] Step S6: Each slave device receives the location configuration data packet, parses it to obtain the number of slave devices in the data packet, and iterates through the location configuration parameters of each slave device, comparing the device hash value carried therein with the hash value of its own physical address.

[0030] In some embodiments, the process of receiving and parsing the location configuration data packet by the slave device in step S6 includes: the slave device first checks whether the packet header is a location configuration packet identifier; if not, the packet is discarded directly; after parsing to obtain the group identifier, it compares it with the group identifier stored locally; if they do not match, the packet is discarded; after matching, it parses to obtain the number of slave devices, calculates the hash value of its own physical address, sets the offset, and iterates through the location configuration parameters of each slave device, reading the device hash value one by one and comparing it with its own hash value; if a match is successful, the X coordinate, Y coordinate, mirror flag, and rotation angle are extracted from the current offset position; if no match is found after the traversal ends, the packet is discarded.

[0031] Step S7: When the hash value matches successfully, the current slave device extracts the corresponding location configuration parameters from the location configuration data packet. The location configuration parameters include X coordinate, Y coordinate, rotation angle, and mirror flag. Precise hash value matching ensures that the configuration parameters are only sent to the target slave device.

[0032] Step S8: Each slave device configures its own coordinate system according to the extracted position configuration parameters.

[0033] In some embodiments, the configuration of the coordinate system in step S8 includes: determining the starting pixel position of the device in the virtual canvas based on the extracted X and Y coordinates, for extracting pixel data from the canvas; performing rotation correction on the display direction of the device based on the rotation angle parameter; performing horizontal mirror correction on the display of the device based on the mirror mark parameter; after configuration, the device performs lighting rendering and animation effect display according to the starting position, rotation angle and mirror mark.

[0034] In some embodiments, the method further includes a location configuration deletion step: receiving a location deletion instruction containing a group identifier to be deleted, parsing the group identifier to obtain the group identifier, searching for and deleting the corresponding location configuration information stored locally; the master device generates a deletion notification packet and sends it to all slave devices in the group via multicast; each slave device receives the deletion notification packet, parses the group identifier, and deletes the corresponding group location configuration information stored locally.

[0035] In some embodiments, this method is accompanied by a Flash storage management mechanism: when the group configuration information or device location mapping relationship changes, a delayed write timer is started; after the timer expires, the current configuration information and mapping relationship are serialized and written to the local Flash memory; when the device is powered on, the data is read from the Flash memory and deserialized to restore the group configuration and location mapping information, thereby restoring the device's coordinate system.

[0036] In some embodiments, the maximum number of devices supported within a single group is determined by the upper limit of the data packet length of the communication protocol: the location configuration parameters of each device in the location configuration data packet occupy a fixed number of bytes, and the total length of the data packet header, group identifier, number of slave devices and all device parameters does not exceed the upper limit of the single data length specified in the protocol.

[0037] In some embodiments, the maximum number of groups that a single device can join is determined based on the device's memory resources: each group needs to maintain a group information structure, a device location list, and a synchronization timer during runtime, and the maximum number of groups is set as a balance between feature richness and memory resource consumption.

[0038] See Figure 1This invention also provides an intelligent lighting device group management system, including a group creation module, an identifier allocation module, a configuration generation module, a multicast sending module, a configuration parsing module, a parameter extraction module, and a coordinate configuration module. The group creation module is configured to receive group configuration information, create device groups based on the configuration information, assign a unique group identifier to the group, and save the group configuration to local storage. The identifier allocation module is configured to calculate the hash value of each device's physical address, traverse the device location configuration parameters in the group configuration information, and determine the index position of each device in the group by comparing hash values, thereby identifying the master device and slave devices. The configuration generation module can be set in the master device and is configured to generate a location configuration data packet based on the group configuration information, the data packet containing only the location configuration of each slave device. The parameters do not include the master device's own configuration; the multicast sending module, which can be set in the master device, is configured to send the location configuration data packet to all slave devices in the group via multicast; the configuration parsing module, which can be set in each slave device, is configured to receive the location configuration data packet, parse the data packet header, group identifier, and number of slave devices, and traverse the location configuration parameters of each slave device; the parameter extraction module, which can be set in each slave device, is configured to compare the parsed device hash value with the hash value of its own physical address, and extract the corresponding X coordinate, Y coordinate, rotation angle, and mirror flag when a match is successful; the coordinate configuration module, which is set in each slave device, is configured to configure the coordinate system of the device according to the extracted location configuration parameters, including the starting pixel position, display direction rotation correction, and horizontal mirror correction.

[0039] The intelligent lighting device group management and location mapping method and system provided by this invention introduces the hash value of the device's physical address as a unique identifier, enabling each device to automatically complete hash matching after receiving the group configuration, accurately identifying itself as a master or slave device, thus clarifying the master-slave role division within the group. The master device only extracts and packages the location configuration parameters of the slave devices, efficiently distributing them via multicast. After parsing and matching, the slave devices autonomously complete the coordinate system configuration, achieving dynamic mapping and flexible adjustment of location information. The entire solution does not require re-flashing firmware, has high communication efficiency, and accurate configuration distribution, making it particularly suitable for resource-constrained embedded lighting device group collaborative control scenarios.

[0040] The following further describes the implementation method and working process of specific embodiments of the present invention.

[0041] This solution utilizes a modular system architecture to achieve group management and location mapping for intelligent lighting devices. The overall architecture includes a group creation module, an identifier allocation module, a configuration generation module, a multicast sending module, a configuration parsing module, a parameter extraction module, and a coordinate configuration module. These modules work together to complete the entire process of group creation, identity recognition, configuration distribution, parameter matching, and coordinate configuration. Inter-module communication uses UDP multicast to achieve efficient data transmission within the group. Figure 1 This is a schematic diagram of the system architecture according to an embodiment of the present invention.

[0042] I. Location Configuration Data Packet Format Definition The location configuration data packet is encapsulated in a fixed format, with 0xC1 as the packet header to identify the location update configuration packet. The overall structure includes five parts: data packet header, group identifier, number of slave devices, location configuration data, and checksum. Figure 2 This is a schematic diagram illustrating the location configuration data packet format in an embodiment of the present invention.

[0043] 1. Packet header: 1 byte, fixed at 0xC1, used to identify the data packet type; 2. Group ID: 4 bytes, stored in big-endian order, used to uniquely identify the target group; 3. Number of slave devices: 1 byte, value range 1-29, representing the total number of slave devices in the group; 4. Location configuration data: N×10 bytes (N is the number of slave devices), with 10 bytes of location configuration parameters for each device; 5. Checksum: 1 byte, using CRC8 checksum to ensure data transmission integrity.

[0044] The 10-byte location configuration parameter for a single device is specifically defined as follows: 1. Device ID Hash: 4 bytes, which is the DJB2 hash value of the device's physical address, used for device identity matching; 2. X coordinate: 2 bytes, the device's position on the horizontal axis of the virtual canvas, with a value range of 0-159; 3. Y coordinate: 2 bytes, the device's position on the vertical axis of the virtual canvas, with a value range of 0-89; 4. Mirror flag: 1 byte, 0 indicates normal display, 1 indicates horizontal mirroring; 5. Rotation angle: 1 byte, 0 corresponds to 0°, 1 corresponds to 90°, 2 corresponds to 180°, and 3 corresponds to 270°.

[0045] II. Implementation of Device Identifier Hash Algorithm This scheme generates the hash value of the device's physical address using the DJB2 hash algorithm for accurate device identification matching. The core formula is hash(i) = hash(i-1) × 33 + str[i], where the multiplier 33 is equivalent to (hash << 5) + hash. Figure 3a This is a flowchart of the DJB2 hash algorithm according to an embodiment of the present invention.

[0046] The algorithm is implemented as follows: First, set the initial hash value to 5381. Then, iterate through each character in the device identifier string. For each character, shift the current hash value 5 bits to the left and add it to the current hash value. Then, add it to the encoding value of the current character to obtain a new hash value. After the iteration is completed, return the final 32-bit unsigned integer hash value.

[0047] Taking the device identifier string "China" as an example, the DJB2 hash algorithm calculates the following: The initial hash value is 5381; the first step processes the character 'C', corresponding to ASCII code 67, updating the hash value to 5381 × 33 + 67; the second step processes the character 'h', corresponding to ASCII code 104, updating the hash value to the result of the previous step × 33 + 104; the third step processes the character 'i', corresponding to ASCII code 105, updating the hash value to the result of the previous step × 33 + 105; the fourth step processes the character 'n', corresponding to ASCII code 110, updating the hash value to the result of the previous step × 33 + 110; the fifth step processes the character 'a', corresponding to ASCII code 97, updating the hash value to the result of the previous step × 33 + 97; finally, the lower 32 bits of the calculation result are taken, resulting in a hash value of 0x0CF63E88. See Table 1 for details.

[0048] Table 1 The DJB2 algorithm boasts high computational efficiency, comprising only multiplication and addition operations, making it suitable for resource-constrained embedded MCU environments. Compared to cryptographic hash functions such as MD5 and SHA, it offers significant advantages in computation speed and resource consumption. Furthermore, the algorithm provides a uniform hash distribution, generating relatively even hash distributions for common device identification strings such as MAC addresses and vendor IDs. In the application scenario of this invention, with a maximum of 30 devices in a single group, the probability of hash collisions is extremely low. Moreover, in this invention, the hash value is only used for device matching, eliminating the need for reverse parsing of the original device identifier. The unidirectional nature of the DJB2 algorithm meets the requirements.

[0049] Algorithm application process: The device first obtains its own unique identifier string and calculates a 32-bit hash value using the DJB2 algorithm; the master device writes the hash values ​​of each device into the location configuration data packet and distributes it via multicast; after receiving the data packet, the slave device compares the locally calculated hash value with the hash value in the packet, and if a match is found, the corresponding configuration parameters are extracted.

[0050] Figure 3b is a schematic diagram of the DJB2 hash algorithm calculation and application process according to an embodiment of the present invention, which fully demonstrates the entire process from obtaining the device identifier string and iteratively calculating the hash value to generating the master device configuration and matching the slave device hash.

[0051] III. Complete Workflow for Location Configuration 1. The master device first receives the complete group configuration from the control terminal, confirms that its own hash value matches index 0, then determines the identity of the master device and completes the local coordinate configuration; 2. The master device skips its own configuration (index 0), extracts only the location parameters of all slave devices in the group, and assembles them into a location configuration data packet in 0xC1 format; 3. The master device sends data packets to all slave devices in the group via UDP multicast; 4. After receiving a data packet from the device, first verify the packet header and group ID; if they do not match, discard the packet directly. 5. Calculate its own hash value from the device, traverse the device configuration parameters in the packet, and compare the hash values ​​one by one; 6. For slave devices with successful hash matching, extract the corresponding X coordinates, Y coordinates, mirror flag, and rotation angle parameters; 7. The device completes the local coordinate system configuration based on the extracted parameters to achieve position mapping. Figure 4 This is a flowchart illustrating the location configuration process in an embodiment of the present invention.

[0052] IV. Location Configuration Deletion Process When you need to clear the group location configuration, perform the delete operation: 1. The system receives a location deletion command containing the target group identifier; 2. After parsing the group identifier, locate and delete the locally stored location configuration information for that group; 3. The master device generates a deletion notification packet with a header of 0xC2 and sends it to all slave devices in the group via multicast; 4. Receive the deletion notification packet from the device, parse the group identifier, and delete the corresponding group location configuration stored locally. Figure 5 This is a flowchart illustrating the deletion location in an embodiment of the present invention.

[0053] V. Flash Storage Management Mechanism To ensure that configuration data is not lost even when power is off, this solution employs a persistent Flash storage and delayed write mechanism: 1. Storage identifiers: s_s_layout stores the overall layout information of the group, and s_s_dev_pos stores the location information of a single device; 2. Delayed Write: When the group configuration or location mapping changes, a 500ms delayed write timer is started. After the timer expires, the configuration is serialized into binary data and written to Flash. 3. Power-on recovery: After the device restarts, it reads and deserializes the stored data from Flash, automatically restores the group configuration and location mapping information, and rebuilds the device coordinate system. Figure 6 This is a flowchart of the Flash storage management process according to an embodiment of the present invention.

[0054] VI. Definition and Application of Virtual Coordinate System This solution uses a virtual canvas coordinate system to achieve position mapping: 1. Canvas size: 160×90 pixels, with the top left corner being the origin (0,0); 2. Axial definition: The X-axis is positive to the right, and the Y-axis is positive downwards; 3. Configuration and Application: The device determines the starting point for virtual canvas data extraction based on the X and Y coordinates, and completes the display direction correction by rotating the angle and using the mirror mark. Without adjusting the hardware wiring, it can realize functions such as multi-device collaborative rendering and display of lighting and animation effects.

[0055] VII. Master / Slave Device Designation and Identification Mechanism 1. The master device is designated by the control terminal, and its configuration information is always stored at index 0 of the group configuration; 2. After receiving the group configuration, all devices calculate their own DJB2 hash value and iterate through the configuration parameters to compare the hashes; 3. Devices matching hash index 0 are identified as master devices, responsible for configuration distribution and group maintenance; devices matching indices 1 to N are identified as slave devices, responsible for receiving configurations and executing lighting effects. 4. When replacing the master device, you only need to re-issue the configuration through the control terminal, and the device will automatically re-hash and match the identity without modifying the firmware.

[0056] VIII. Number of Devices and Groups in Preferred Embodiments 1. Maximum number of devices in a single group: Limited by the maximum length of the DP data packet in the communication protocol, a single group can have a maximum of 30 devices; 2. Maximum number of groups per device: Due to the limitation of device RAM memory resources, a single device can join a maximum of 20 groups, which is a reasonable balance between feature richness and system resource consumption.

[0057] The maximum number of devices in a single group is limited to 30 devices, a limit determined by the Tuya DP data packet protocol format. When designing the layout of DP data, the maximum length of a single DP data entry is defined as 306 bytes. Its specific components include a 1-byte version field, a 4-byte group_id field, a 1-byte dev_num field, and an array for storing device location information. Each device's location configuration information occupies 10 bytes, including the device ID hash, X coordinate, Y coordinate, mirror flag, and rotation angle. Calculations show that the location configuration data for 30 devices is 30 × 10 bytes, plus a 6-byte protocol header, totaling exactly 306 bytes. This meets the Tuya DP protocol layer's upper limit requirement for single data entry length; exceeding this length will result in data transmission failure. Supporting groups with more than 30 devices would require simultaneous modifications to the DP protocol specification, involving collaborative modifications between the cloud and application sides, a significant undertaking. Therefore, 30 devices is a reasonable upper limit under the existing protocol framework.

[0058] The maximum number of groups a single device can join is limited to 20, a limit taken into account from the perspective of device RAM memory usage. Taking the T1 chip as an example, it has 288KB of SRAM, but the system does not only load the Scene Show module during operation. After a device joins a group, it needs to maintain resources such as group information structures, device location lists, animation status data, and synchronization timers in RAM. Each group occupies approximately 100-200 bytes of RAM during operation. The memory usage corresponding to 20 groups is 2-4KB. Adding the memory consumption of other modules such as animation algorithms and communication protocol stacks, the 288KB SRAM resources of the T1 chip are actually quite tight. Choosing 20 as the maximum number of groups is a reasonable balance between feature richness and system memory resource usage. It can meet the needs of most practical use cases without putting too much pressure on system memory, ensuring the stability of device operation.

[0059] IX. Definition, Configuration, and Application of Virtual Canvas Coordinate System This solution uses a virtual canvas coordinate system to map device positions. The canvas size is 160×90 pixels, with the top-left corner of the virtual canvas as the origin (0,0). The X-axis points to the right as the positive direction, and the Y-axis points downwards as the positive direction. The coordinate range is 0 to 159 for the X-axis and 0 to 89 for the Y-axis. The device's position information is described by four parameters: X-coordinate, Y-coordinate, mirror flag, and rotation angle. The X and Y coordinates determine the starting pixel position of the device on the virtual canvas, serving as the starting point for the device to extract data from the canvas. The mirror flag is a display attribute of the device itself, used to correct the device's horizontal flip. The rotation angle is also a display attribute of the device, used to correct the device's orientation rotation. For example, a light strip device with coordinates of x=50, y=30, mirror=0, and angle=1 means that the light strip starts at position (50,30) on the canvas and emits light to the right at a 90-degree angle. After the device completes the coordinate configuration, it can realize three core functions: First, multi-device collaborative rendering, where the master device renders the complete picture on the virtual canvas, and each slave device extracts the corresponding pixel data according to its own coordinates; second, lighting animation effects, where animation parameters such as the delay of flowing lights and the color phase of rainbow effects are calculated based on the device coordinates; and third, display direction correction, where the device display direction is adjusted by mirroring and angle parameters without the need for rewiring.

[0060] 10. Specific Implementation of Configuration Generation Module Module Responsibilities The core responsibility of the configuration generation module is to solve the problem of how to accurately transmit the configuration information of the slave devices to each slave device after the master device receives the complete group configuration from the App.

[0061] The group configuration sent by the App contains complete information about the master device and all slave devices in the group. This configuration is uniformly stored in the dev_pos[] array, where dev_pos[0] is the configuration information of the master device in the group, and dev_pos[1] to dev_pos[N] are the configuration information of each slave device. Since the slave devices cannot directly establish a cloud connection with the App and receive the configuration, the master device needs to act as a configuration relay station. After receiving the complete configuration, it extracts the configuration information of the slave devices, repackages it into 0xC1 format data packets, and distributes them to all slave devices in the group via UDP multicast.

[0062] Working principle After receiving the complete data containing all configurations of both master and slave devices from the App, the master device first identifies and matches its own corresponding configuration information to complete the local coordinate setting. Then, it skips the master device's own configuration items, extracts the location configuration parameters of all slave devices, assembles them into a location configuration data packet according to the specified format, and finally sends the data packet to all slave devices in the group via UDP multicast. After receiving the data packet, the slave devices parse and match their own configurations to complete the coordinate setting.

[0063] Data packet format and assembly process The location configuration data packet is identified by 0xC1 in the packet header and has a total length of 27 bytes. The data packet assembly is performed according to a fixed procedure: First, write the packet header and assign the value 0xC1 to the 0th byte of the data packet; Second, write the group ID, which is stored in 4-byte big-endian format. The group ID is split bit by bit and written to the 1st to 4th bytes of the data packet; Third, calculate and write the number of slave devices. The number of slave devices is obtained by subtracting 1 from the total number of devices in the group and the value is written to the 5th byte of the data packet; Fourth, write the configuration parameters of slave device 1, skip the dev_pos [0] corresponding to the master device, extract the configuration information of dev_pos [1], and write the device ID hash value, X coordinate, Y coordinate, mirror flag, and rotation angle to the 6th to 15th bytes of the data packet in byte order; Fifth, write the configuration parameters of slave device 2, extract the configuration information of dev_pos [2], and write the 16th to 25th bytes of the data packet in the same format; Sixth, calculate and write the CRC8 check code and write the check result to the 26th byte of the data packet to complete the data packet assembly.

[0064] The reason for skipping dev_pos [0] in the slave device configuration is that dev_pos [0] corresponds to the master device's own configuration information. After receiving the configuration sent by the App, the master device will first confirm and complete the local location configuration. There is no need to package and send its own configuration information to the slave device. Therefore, dev_pos [0] is skipped directly when generating the data packet. The master device not sending its own configuration can also reduce the size of the data packet and save network bandwidth resources. The slave device only needs to parse the configuration parameters belonging to itself in the data packet to complete the setting.

[0065] Configuration package generation steps The complete process for generating the configuration packet is as follows: First, calculate the number of slave devices based on the total number of devices in the group configuration, and subtract 1 from the total number of devices to get the result; second, calculate the total length of the data packet, which is obtained by adding the 1-byte packet header, 4-byte group ID, 1-byte number of slave devices, the total number of bytes of slave device configuration, and 1-byte CRC8 checksum; next, allocate memory space for the data packet; then, write the packet header, the big-endian format group ID, and the number of slave devices in sequence; then, traverse all slave device configurations, skipping the master device configuration items, and write the device ID hash value, X coordinate, Y coordinate, mirror flag, and rotation angle of each slave device byte by byte to the corresponding position in the data packet; then, calculate the CRC8 checksum for the entire data packet and write it to the end of the data packet; finally, call the multicast sending interface to send the data packet to the slave devices in the group, and release the memory occupied by the data packet after sending is completed.

[0066] Complete configuration generation and sending process Figures 7a to 7b This is a complete flowchart of the configuration generation and sending process in this embodiment of the invention. The process begins with the entry function of the App issuing group layout configuration. First, it checks whether the device already has group information. If an old group exists, it performs a deletion operation first. Then, the complete configuration issued by the App is saved locally. The device calculates the DJB2 hash value of its own device ID and traverses the dev_pos array to find the index that matches the hash of the device. If no match is found, it is determined that the device is not in the group and the device location setting is skipped. If a match is found, the device location configuration is completed. Then, the location configuration data packet sending function is called, which sequentially performs the following operations: data packet memory allocation, writing the 0xC1 packet header, writing the big-endian group ID, calculating and writing the number of slave devices, cyclically packaging the slave device configuration parameters, and calculating the CRC8 checksum. After completion, the UDP multicast interface is called to send the data packet. After sending, the data packet memory is released. Finally, a timer for delayed writing to Flash is started, and the group and location information are uploaded to the cloud. The entire configuration generation and sending process is completed.

[0067] XI. Group Creation Module Module Functions The group creation module is mainly responsible for receiving group configuration information from the application and saving the configuration information stably to the device's local storage area, providing basic data support for subsequent group management, identity recognition and location configuration.

[0068] Core Data Structures This module relies on a dedicated group information structure to manage data. The structure includes a unique group identifier, the total number of devices in the group, the role type of the devices in the group, and an array for storing the location information of all devices. The device location array can support the storage of location configurations for up to 30 devices. The device role types are divided into three categories: no group, master device, and slave device.

[0069] Group creation process Figure 8 is a flowchart of the group creation process according to an embodiment of the present invention. The process begins with the application sending a group layout configuration command. First, the system checks whether there is already valid group information on the current device. If there is an old group configuration, the old group deletion operation is performed first. After the cleanup is completed, the new group configuration sent by the application is completely saved to the device's local control structure. Then, the device calls the DJB2 hash algorithm to calculate the hash value of its physical address and traverses the device location array in the group configuration, comparing the local hash value with the device hash values ​​in the array one by one. If a match is successful, the device role is determined according to the matching array index. If the index is 0, it is set as the master device, and the other indices are set as slave devices. After the role is determined, a timer for writing the configuration to the Flash memory is started. Finally, the group-related information is uploaded to the cloud to complete the synchronization, and the entire group creation process is completed.

[0070] The specific steps for group creation are as follows: First, check if a group identifier already exists on the device. If a valid group exists, call the group deletion function to clear the original group configuration. Then, through a memory copy operation, completely write the group configuration issued by the application to the group control structure on the device. Next, call the DJB2 hash algorithm to calculate the hash value of the local device identifier. Traverse the device location array in the group configuration and match and verify the local hash value with the hash value of each device in the array. When a match is successful, assign device roles according to the matching index position, with index 0 being the master device and non-zero indexes being slave devices. After completing the role configuration, start a delayed write timer to persistently store the configuration data in Flash. Finally, perform a cloud synchronization operation to upload the group information to the cloud for filing.

[0071] XII. Identifier Assignment Module Module Responsibilities The core responsibility of the identifier allocation module is to solve the problem of whether the master device is the group master device after receiving the complete group configuration from the application, and to accurately determine the location coordinates of the local machine in the virtual canvas.

[0072] The group configuration sent by the application contains complete information about all devices in the group. All device configurations are stored in a device location array in a fixed order. The array index 0 is the configuration slot reserved for the master device, and the indexes 1 to N are the configuration slots for the slave devices. Each device's configuration parameters contain the DJB2 hash value of the device's physical address. This hash value serves as a unique identifier and is used by the device to complete self-identification and matching after receiving the configuration.

[0073] Working principle Devices cannot directly determine their role based on the array slots in their configuration; they must use hash value matching for identity verification. The device first calculates its own DJB2 hash value, then iterates through the device location array, comparing its own hash value with each of the other device hash values ​​in the array. If a match is found, the device determines its role and location coordinates based on the corresponding array index. For example, in the sample configuration, if the hash value of the master device slot configuration sent by the application matches the device's own hash value, the device can confirm itself as the master device and load the coordinate parameters of the corresponding slot to complete its local location configuration.

[0074] Identifier allocation implementation process The specific execution steps for identifier allocation are as follows: First, the complete group configuration issued by the application is saved to the device's local control structure through a memory copy operation; then, the DJB2 hash algorithm is called to calculate the hash value of the local device identifier; the device location array in the group configuration is traversed, and the local hash value is compared with the device hash values ​​in the array to mark the matching status; if the match is successful, it is determined that the local device belongs to the current group, the device location parameters corresponding to the matching location are extracted, the location configuration information is assembled, and the device location setting function is called to complete the configuration of the local coordinate system.

[0075] Figure 9 is a flowchart of the identifier allocation process according to an embodiment of the present invention. The process begins with the device receiving the group configuration sent by the application. First, the complete configuration data is saved to local storage. Then, the DJB2 hash value of the local device ID is calculated, and the matching flag and index variable are initialized. The process then enters a loop traversal process, comparing the device hash value in the device location array with the local hash value one by one. If there is no match, the index is incremented and the traversal continues until the traversal is completed. If the match is successful, the local device is marked as a device in the group, and the traversal is terminated. After a successful match, the device role is determined according to the matched index position and the local coordinates are configured. Finally, the local storage of the location parameters and the triggering of subsequent processes are completed, and the entire identifier allocation process is completed.

[0076] 13. Multicast Sending Module Module Functions The multicast sending module is primarily responsible for transmitting configuration data within the group. It is responsible for sending the encapsulated 0xC1 format location configuration packets to all slave devices in the group via UDP multicast communication, thereby achieving efficient broadcasting and distribution of location configuration information.

[0077] Multicast sending process Figure 10 This is a flowchart of the multicast sending process according to an embodiment of the present invention. The process takes the group identifier, the content of the data packet to be sent, and the data packet length as input parameters. First, the corresponding group multicast address is obtained according to the target group identifier. Then, the standard socket sending interface is called to perform the data packet sending operation. After the sending is completed, the sending result is judged. If the sending is successful, a normal sending log is recorded. If the sending fails, an error log is recorded and the process is terminated, thus completing the entire multicast sending operation.

[0078] XIV. From the equipment processing module Module Functions The slave device processing module is responsible for receiving UDP multicast data transmitted over the network, parsing and validating the 0xC1 format location configuration packet, accurately matching and extracting the exclusive location configuration parameters through local hash value, and writing the successfully matched parameters into the local coordinate system to complete the location mapping configuration of the slave device.

[0079] From the equipment handling process Figure 11 This is a flowchart of the slave device processing in an embodiment of the present invention. The process begins with the slave device receiving UDP multicast data. First, the received data is checked for a header to determine if the header is 0xC1. If not, the data packet is discarded. If the header check passes, the group ID in the data packet is parsed, and the parsing result is compared with the group ID stored locally on the device. If they do not match, the data packet is discarded. If the group ID matches, the number of slave devices in the data packet is parsed, and the DJB2 hash algorithm is called to calculate the hash value of the local device identifier. Then, starting from a fixed offset position in the data packet, all slave device configurations are traversed, and the hash value of each device is extracted and compared with the local hash value. If they do not match, the data offset is increased by 10 bytes and the traversal continues. If no hash value is matched after traversing all device configurations, it is determined that the device is not in the configuration, and the process ends directly. If the hash matches successfully, the corresponding X coordinate, Y coordinate, mirror flag, and rotation angle parameters are extracted to complete the setting of the local coordinate system. Then, a timer for delayed writing to Flash is started, and the local position information is uploaded to the cloud. The entire slave device processing process is completed.

[0080] The specific execution steps of the device processing are as follows: First, the received UDP multicast data is checked for header verification. If the packet header is not 0xC1, the data is discarded. After the header verification passes, the group ID is extracted from the packet using big-endian parsing. This group ID is compared with the group identifier stored locally on the device. If the comparison does not match, the packet is discarded. After the group ID matches, the number of slave devices is parsed from the packet, and then the unique hash value of the local device is calculated using the DJB2 hash algorithm. Starting from the offset position of the 6th byte of the packet, the configuration information of all slave devices is traversed sequentially. The hash value of each slave device is extracted one by one and compared with the local hash value. If the current device hash does not match the local hash, the data offset is increased by 10 bytes and the next round of traversal continues. When the hash matches successfully, the X coordinate, Y coordinate, mirror flag, and rotation angle parameters are extracted sequentially from the current offset position, and the position configuration function is called to complete the configuration of the local coordinate system. After the configuration takes effect, a delayed write timer is started to persistently store the position configuration information in the Flash memory, and the local position parameters are uploaded to the cloud to complete data synchronization.

[0081] 15. Configuration Process Reliability Assurance This solution establishes multiple reliability assurance mechanisms for the entire location configuration process. First, it supports application-side re-deployment of configurations, allowing users to proactively trigger the re-deployment of location configurations on the application side, ensuring the validity of configuration transmission. Second, it has master device status synchronization capabilities, with the master device reporting its operating status to the cloud via data points. The application side can detect anomalies such as configuration failures of slave devices in real time, facilitating rapid troubleshooting and handling. In addition, it is equipped with a device restart recovery mechanism. The device's location configuration information is written to Flash memory for power-off preservation. After the slave device restarts, it can read and restore the original configuration information from Flash. After restoration, the configuration process needs to be retried to ensure that the parameters take effect normally.

[0082] XVI. Device Identifier and Hash Matching Mechanism and Master-Slave Role Configuration Device identifier and hash matching mechanism In this solution, device identification and hash matching are integrated throughout the entire process of network configuration, group addition, and location configuration, forming a complete device identity binding and identification link. When a device connects to WiFi or BLE for the first time, the application actively obtains and saves the device's unique identifier, laying the foundation for subsequent device identification. When a user adds a device to a designated group through the application, the application can clearly obtain and know the device's unique ID, ensuring the accuracy of configuration distribution. When a user completes device location configuration by dragging and dropping on the application's virtual canvas, the application binds the DJB2 hash value corresponding to the device ID with parameters such as location coordinates, rotation angle, and mirror flag. The bound complete configuration data is then distributed to each device in the group, providing a core basis for local device identity matching and location mapping.

[0083] Master device election / designation mechanism The designation and election of the master device are entirely controlled by the user on the application side, and the process is clear and flexible. When the user needs to create a smart lighting device group in the local area network, the user first scans and adds the devices to be added to the group on the application side. The application side will automatically discover all devices in the local area network that support the scene show function and display the device list to the user. The user selects the target device from the device list, then long-presses or clicks the specified device and selects the "Set as Master Device" option to complete the designation of the master device. After receiving the user's specified instruction, the application side will package the device ID, position coordinates, rotation angle, mirror flag and other information of the master device, and integrate them with the configuration information of other slave devices to form a complete group configuration data. This data follows the SCENE_SHOW_LAYOUT_CFG_T structure format. In the configuration data, the specified master device configuration information will be placed in the dev_pos[0] reserved slot, and the configuration information of the other slave devices will be filled into the dev_pos[1], dev_pos[2] and other subsequent slots in sequence. The application side will distribute this complete group configuration to all devices in the group through the cloud or local area network.

[0084] After receiving the configuration data, each device executes a unified identity verification logic: First, it calls the DJB2 hash algorithm to calculate the hash value of its local device ID. Then, it traverses the dev_pos[] device location array, comparing the hash value configured for each device in the array with its local hash value. Taking a designated master device A as an example, when device A traverses to the dev_pos[0] slot, it finds that the hash value at that position matches the local hash value perfectly, thus determining itself as the group master device and setting the corresponding identity flag bit, while saving its local location information. Similarly, when device B matches the dev_pos[1] slot, it confirms itself as a slave device; when device C matches the dev_pos[2] slot, it is also determined to be a slave device.

[0085] Once the master device is identified, it assumes the core responsibilities of maintaining group configuration, generating animation data, and sending UDP multicast data, distributing location configurations and animation parameters to slave devices. Slave devices are responsible for receiving multicast data from the master device, parsing it, and executing the corresponding lighting effects. If a user needs to change the master device, they only need to reselect the target device and designate it as the master device in the application. The application will then generate a new group configuration containing the new master device's configuration and redistribute it. All devices will automatically re-execute the hash matching logic to complete the master-slave role switch. The entire process does not require re-flashing the firmware to the devices, achieving flexible and convenient master-slave role configuration.

[0086] In summary, this invention proposes a method and system for group management and location mapping of intelligent lighting devices. By establishing an identity identification and matching mechanism based on physical address hash values ​​for each device, the device can automatically identify its master / slave role after receiving group configuration without re-flashing firmware. The master device only encapsulates the location configuration parameters of each slave device into a location configuration data packet and distributes it efficiently via multicast. After parsing and matching, the slave devices autonomously complete the coordinate system configuration, thereby realizing group management and location mapping of multiple devices. It supports flexible group configuration and dynamic position adjustment, and can adapt to the needs of different application scenarios. This invention has high communication efficiency, accurate configuration distribution, and supports dynamic updates, deletions, and power-off recovery of location configurations. It effectively overcomes the shortcomings of existing technologies such as inflexible location mapping, unclear master / slave relationships, and poor group scalability. It is particularly suitable for group collaborative control scenarios of various intelligent lighting devices such as intelligent light strips, intelligent bulbs, and intelligent panels.

[0087] The above description, in conjunction with specific / preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various substitutions or modifications can be made to these described embodiments without departing from the inventive concept, and all such substitutions or modifications should be considered within the scope of protection of the present invention.

Claims

1. A method for intelligent lighting device group management and location mapping, characterized in that, Includes the following steps: S1. Receive group configuration information, which includes group identifier, number of devices, and location configuration parameters of each device in the group. The location configuration parameters of each device include the hash value of the device's physical address. S2. Create a device group based on the group configuration information, and assign a unique group identifier to the group; S3. Each device calculates the hash value of its own physical address, traverses the device location configuration parameters in the group configuration information, and compares its own hash value with the hash value in the location configuration parameters to determine its index position in the group: if it matches index 0, it is confirmed as a master device; if it matches indices 1 to N, it is confirmed as a slave device, where N is the number of slave devices. S4. The master device generates a location configuration data packet based on the group configuration information. This data packet contains only the location configuration parameters of each slave device and does not contain the location configuration parameters of the master device itself. S5. The master device sends the location configuration data packet to all slave devices in the group via multicast; S6. Each slave device receives the location configuration data packet, parses it to obtain the number of slave devices in the data packet, and iterates through the location configuration parameters of each slave device, comparing the device hash value carried therein with the hash value of its own physical address; S7. When the hash value matches successfully, the current slave device extracts the corresponding location configuration parameters from the location configuration data packet. The location configuration parameters include X coordinate, Y coordinate, rotation angle, and mirror flag. S8. Each slave device configures its own coordinate system according to the extracted position configuration parameters.

2. The method as described in claim 1, characterized in that, The hash value of the device physical address mentioned in steps S1 and S3 is generated using the DJB2 hash algorithm, which includes: setting an initial hash value; traversing each character in the device identifier string; for each character, shifting the current hash value to the left by a given number of bits and adding the current hash value, plus the encoding value of the current character, to obtain a new hash value; and returning the hash value after traversal.

3. The method as described in claim 1, characterized in that, The process of generating the location configuration data packet in step S4 includes: The master device calculates the number of slave devices based on the total number of devices in the group configuration information; allocates data packet memory; writes the data packet header identifier; writes the group identifier; writes the number of slave devices; skips the master device configuration at index 0 in the group configuration information, extracts the position configuration parameters of each slave device in sequence and writes them into the data packet; calculates the checksum and writes it to the end of the data packet; and finally sends it via multicast.

4. The method as described in claim 1, characterized in that, Step S6, which involves receiving and parsing the location configuration data packet from the device, includes: The device checks if the packet header is a location configuration packet identifier; if not, it discards the packet. It parses the packet to obtain the group identifier and compares it with the locally stored group identifier; if they don't match, it discards the packet. It then parses the number of slave devices. It calculates the hash value of its own physical address. It sets the offset and iterates through the location configuration parameters of each slave device, reading the device hash value one by one and comparing it with its own hash value. If a match is found, it extracts the X-coordinate, Y-coordinate, mirror flag, and rotation angle from the current offset position. If no match is found after the iteration ends, the packet is discarded.

5. The method as described in claim 1, characterized in that, The configuration of the coordinate system in step S8 includes: The starting pixel position of the device in the virtual canvas is determined based on the extracted X and Y coordinates, which are used to extract pixel data from the canvas; the display direction of the device is rotated and corrected according to the rotation angle parameter; the display of the device is horizontally mirrored according to the mirror mark parameter; after configuration, the device performs lighting rendering and animation effects display according to the starting pixel position, rotation angle and mirror mark.

6. The method as described in claim 1, characterized in that, It also includes the step of deleting location configuration: Receive a location deletion instruction, the instruction containing a group identifier to be deleted; after parsing to obtain the group identifier, find and delete the location configuration information corresponding to the group identifier stored locally; The master device generates a deletion notification packet and sends it to all slave devices in the group via multicast. Each slave device receives the deletion notification packet, parses it to obtain the group identifier, and deletes the location configuration information of the corresponding group stored locally.

7. The method as described in claim 1, characterized in that, It also includes Flash storage management, which includes: When the group configuration information or device location mapping relationship changes, a delayed write timer is started; when the timer expires, the current configuration information and mapping relationship are serialized and written to the local Flash memory; when the device is powered on, it is read from the Flash memory and deserialized to restore the group configuration and location mapping information, thereby restoring the device's coordinate system.

8. The method according to any one of claims 1 to 7, characterized in that, The maximum number of devices supported within a single group is determined by the upper limit of the data packet length of the communication protocol: the location configuration parameters of each device in the location configuration data packet occupy a fixed number of bytes, and the total length of the data packet header, group identifier, number of slave devices, and all device parameters does not exceed the upper limit of the single data length specified in the protocol.

9. The method according to any one of claims 1 to 7, characterized in that, The maximum number of groups a single device can join is determined based on the device's memory resources: each group needs to maintain a group information structure, a device location linked list, and a synchronization timer during runtime, and the maximum number of groups is set as a balance between feature richness and memory resource consumption.

10. A smart lighting equipment group management system, characterized in that, include: The group creation module is configured to receive group configuration information, create device groups based on the configuration information, and assign a unique group identifier to the group. The identification allocation module is configured to calculate the hash value of each device's own physical address, traverse the device location configuration parameters in the group configuration information, determine the index position of each device in the group by comparing hash values, and identify master devices and slave devices; The configuration generation module is configured to generate a location configuration data packet based on the group configuration information. This data packet only contains the location configuration parameters of each slave device and does not contain the configuration of the master device itself. The multicast sending module is configured to send the location configuration data packet to all slave devices in the group via multicast. The configuration parsing module is configured to receive the location configuration data packet, parse the group identifier and the number of slave devices, and traverse the location configuration parameters of each slave device; The parameter extraction module is configured to compare the parsed device hash value with the hash value of its own physical address, and extract the corresponding X coordinate, Y coordinate, rotation angle and mirror flag when a match is found. The coordinate configuration module is configured to configure the coordinate system of this device based on the extracted location configuration parameters.

Images