Multi-functional LED physical pest repelling lamp control method and system

Abstract

This invention discloses a multifunctional LED physical insect repellent lamp control method and system, relating to the field of insect repellent lamp control technology. The method involves acquiring a device identifier, epoch value, monotonic count value, and executed state version; then generating a composite state version based on the epoch value, the incremented monotonic count value, and the device identifier, and associating it with a target working state to form a pending synchronization frame; next, comparing the corresponding fields of the pending synchronization frame with the executed state version to determine the target synchronization frame; finally, executing the target working state and updating the executed state version. Because the epoch value distinguishes the counting space before and after a restart, and the device identifier handles parallel events with the same epoch and count, this method ensures that cross-node control events form a definite version position, thereby reducing the possibility of disordered state replacement and indistinguishable order of concurrent events.

Description

Technical Field

[0001] This invention relates to the field of insect repellent lamp control technology, specifically to a control method and system for a multifunctional LED physical insect repellent lamp. Background Technology

[0002] Multifunctional LED physical insect repellent lamps can create corresponding lighting or physical insect repellent states in agricultural planting areas by adjusting the start / stop, brightness, and heat dissipation component operation of different LED light source channels. In order to enable multiple lamps in the same area to switch states according to the same control event, each lamp node can exchange synchronization frames carrying the target working status through a local area network or Mesh network, and complete the synchronization process by combining the device identifier and local status version.

[0003] In peer-to-peer lighting networks without a fixed host, state change commands can be sent to any lighting node. Synchronization frames generated by different nodes may arrive concurrently, repeatedly, or out of order. Since each lighting node independently generates its state version, local count values ​​may be identical, and the count space may change before and after a node restart. This makes it difficult for the receiving node to continuously determine the sequence of cross-node control events, leading to earlier states replacing already executed states. Therefore, a version sorting criterion that can distinguish the source of events and persist across restarts is needed. Summary of the Invention

[0004] The purpose of this invention is to provide a control method and system for a multifunctional LED physical insect repellent lamp.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a multifunctional LED physical insect repellent lamp control method, executed by lamp nodes in a peer-to-peer lamp network without a fixed host, the method comprising: Retrieve the local device identifier, epoch value, incrementing monotonic counter value, and executed state version; A composite state version is generated based on the epoch value, the incrementing monotonic count value, and the device identifier. The composite state version is associated with the target working state to form a synchronization frame to be processed. The epoch value, incrementing monotonic count value, and device identifier in the synchronization frame to be processed are compared with those in the executed state version. Based on the comparison results, the synchronization frame to be processed with a higher version order than the executed state version is determined and defined as the target synchronization frame. The target working state associated with the target synchronization frame is determined as the state to be executed. The target working state is the lamp operating state that the lamp node needs to achieve after executing the state change instruction. When executing a pending state, if the local machine is a temporary synchronization source, send the target synchronization frame and update the executed state version with the composite state version of the target synchronization frame.

[0006] A further preferred method is to generate a composite state version based on the epoch value, an increasing monotonically increasing count value, and the device identifier, including: Read the epoch value before restart from non-volatile storage; when the node restarts, generate the current epoch value whose sorting position is higher than the epoch value before restart. Upon receiving a valid state change instruction, the monotonic count value is incremented in the counting space corresponding to the current epoch value, and a composite state version is encapsulated in the order of the current epoch value, the incremented monotonic count value, and the field of the local device identifier.

[0007] Further preferred methods involve sequentially comparing the epoch value, incremental monotonic count value, and device identifier of the synchronization frame to be processed with those of the executed state version, including: Compare the epoch values; if the epoch values ​​are the same, compare the incremental monotonic count values; if both are the same, determine the version position according to the preset order of the device identifier. From the pending synchronization frames whose version rank is higher than that of the executed version, select the synchronization frame with the highest version rank as the target synchronization frame, and discard the remaining synchronization frames and duplicate synchronization frames with the same version rank as the composite state.

[0008] Further preferred steps, before selecting the synchronization frame with the highest version ranking as the target synchronization frame, include: Extract logical partition identifiers and verification information from the synchronization frames to be processed. Add the synchronization frames to be processed that match the logical partition identifiers with the pre-stored logical partition identifiers on the local machine and pass the verification to the candidate synchronization frame set. Perform version ranking comparison based on the candidate synchronization frame set. The pre-stored logical partition identifiers on the local machine are also used to determine the validity of the status change commands sent by the wireless remote controller.

[0009] Further preferred determination of valid status change instructions includes: Receive status change commands generated by device physical buttons, wireless remote control or mobile terminal. The status change commands include control terminal identifier, target lighting fixture identifier or logical partition identifier, target working status, command sequence number or time information and verification information. Based on the verification information, the verified status change command is determined, and the verified status change command is concurrently screened according to the command sequence number or time information. The screened status change command is determined as a valid status change command, and the lamp node that receives the valid status change command is determined as the temporary synchronization source of the corresponding control event. The background status update formed after the target working state is executed is not used as a new control event triggering source.

[0010] More preferably, the target operating state also includes the cooling fan start / stop state, and the determination of the cooling fan start / stop state includes: Obtain the rated power, junction temperature, or temperature rise calibration data of each LED light source channel at different brightness levels, and determine the predicted heat load corresponding to the current light source combination based on the calibration data; The predicted heat load is compared with the fan start threshold and the shutdown hysteresis threshold. When the predicted heat load reaches the fan start threshold, the fan start state is determined. When the predicted heat load drops to the shutdown condition determined by the shutdown hysteresis threshold, the fan shutdown state is determined. The determined fan start and shutdown states are added to the target operating state.

[0011] A further preferred embodiment, after obtaining the device identifier of the local machine, includes: The system receives a device discovery request from a mobile terminal and feeds back device information to the mobile terminal, including the local device identifier, logical partition identifier, and online status. This enables the mobile terminal to map the device identifiers of multiple lighting nodes to the same partition object according to the logical partition identifier. When partition members are added, removed, or offline, the system updates the member information, online ratio, and anomaly flags of the corresponding partition object.

[0012] A further preferred embodiment of the method, after executing the pending state and updating the version of the executed state, includes: Write the target working state and its composite state version associated with the target synchronization frame into the non-volatile memory as the comparison benchmark for the last working state and restart. When a node restarts, it reads the last working state and the version of the executed state before the restart. Based on the last working state, it restores the start / stop state and brightness level of the LED light source channel. After updating the epoch value, it retains the version of the executed state before the restart and uses the version of the executed state to participate in the version comparison of the pending synchronization frames received after the restart.

[0013] More preferably, sending the target synchronization frame includes: The target synchronization frame is sent via a UDP broadcast link of a Wi-Fi LAN or a Bluetooth Mesh network, and one of the following propagation methods is used: single broadcast, limited hop forwarding, or partitioned proxy forwarding. In the case of single broadcast, a round of target synchronization frames is sent by a temporary synchronization source. When using hop-limited forwarding, the receiving node forwards the data within the network hop count limit specified by the target synchronization frame; When using partitioned proxy forwarding, the target synchronization frame is forwarded by the proxy node of the corresponding logical partition; Background state updates resulting from the execution of the target working state do not trigger the regeneration of synchronization frames.

[0014] This application also provides a multifunctional LED physical insect repellent lamp control system, including multiple lamp nodes, which form a peer-to-peer lamp network without a fixed host. Each lamp node includes: The data acquisition module is used to acquire the local device identifier, epoch value, incremental monotonic count value, and executed version. The composite version generation module is used to generate a composite state version based on the epoch value, the incremental monotonic count value and the device identifier, and associate the composite state version with the target working state to form a synchronization frame to be processed. The version arbitration module is used to compare the epoch value, incremental monotonic count value and device identifier in the pending synchronization frame with the executed version in turn, and determine the target synchronization frame and pending execution state based on the comparison results. The state execution module is used to execute the state to be executed and update the executed state version with the composite state version of the target synchronization frame; The communication module is used to send the target synchronization frame when the corresponding lighting node is a temporary synchronization source; The restart processing module is used to update the epoch value when the lighting node restarts and to maintain the version of the executed state before the restart.

[0015] The technical effects and advantages provided by the present invention in the above technical solution are as follows: Compared to state synchronization methods where a single node generates a standard version number or each lighting node records its local count, this application obtains the device identifier, epoch value, monotonic count value, and executed state version. Next, it generates a composite state version based on the epoch value, the incremented monotonic count value, and the device identifier, and associates this with the target working state to form a pending synchronization frame. Then, it compares the corresponding fields of the pending synchronization frame with the executed state version to determine the target synchronization frame. Finally, it executes the target working state and updates the executed state version. Because the epoch value distinguishes the counting space before and after a restart, and the device identifier handles parallel events with the same epoch and count, cross-node control events form a definite version position, thereby reducing the possibility of out-of-order state replacements and indistinguishable order of concurrent events. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0017] Figure 1 This is a flowchart of the control method for the multifunctional LED physical insect repellent lamp in this invention.

[0018] Figure 2 This is a flowchart of the linkage control logic between the lamp light source and the fan in this invention.

[0019] Figure 3 This is a schematic diagram illustrating the interaction of control permissions among the three terminal devices in this invention.

[0020] Figure 4 This is the event source versioning peer-to-peer synchronization topology diagram in this invention.

[0021] Figure 5 This is a diagram of the logic partitioning and grouping control system architecture for greenhouse lighting fixtures in this invention.

[0022] Figure 6 This is a flowchart illustrating the switching process of the lamp's power-off memory state in this invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0025] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0026] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0027] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0028] The multifunctional LED physical insect-repelling lamp control solution provided in this application can be deployed in agricultural greenhouses, seedling rooms, plant factories, or other locations requiring multi-lamp zone operation. Each lamp node can independently control its own light source and heat dissipation components, or exchange synchronization frames with other lamp nodes in the same peer-to-peer network via a wireless communication module. No fixed host is continuously assigned to control the network; each lamp node processes control events according to the same state version structure and comparison rules, ensuring that any node can synchronously transmit the control event upon receiving a valid state change command.

[0029] The lighting node may include a microcontroller, non-volatile memory, wireless communication circuitry, LED driver circuitry, fan driver circuitry, and power management circuitry. The microcontroller is used to run instruction verification, state version generation, synchronization frame filtering, and state execution programs; the non-volatile memory is used to store device identifiers, logical partition identifiers, epoch values, monotonic count values, executed state versions, and last operating state; the wireless communication circuitry may employ Wi-Fi communication circuitry, Bluetooth Mesh communication circuitry, or other communication circuitry capable of performing local area network broadcasting, multicasting, and inter-node forwarding.

[0030] The following embodiments are described in the order of basic synchronization process, composite state version arbitration, partitioning and multi-terminal processing, light source and heat dissipation control, power failure recovery, and system deployment. Data with the same name in each embodiment has the same meaning, and processing steps in different embodiments can be combined without technical conflict.

[0031] Example 1 like Figure 1 As shown, in one embodiment, the lighting node executes a peer-to-peer synchronization control process based on a composite state version. This process includes: acquiring the local device identifier, epoch value, incrementing monotonic count value, and executed state version; generating a composite state version based on the epoch value, incrementing monotonic count value, and device identifier; associating the composite state version with a target working state to form a synchronization frame to be processed; sequentially comparing the epoch value, incrementing monotonic count value, and device identifier in the synchronization frame to be processed with those in the executed state version, determining the synchronization frame to be processed with a higher version order than the executed state version based on the comparison result, and using it as the target synchronization frame; determining the target working state associated with the target synchronization frame as the state to be executed; executing the state to be executed, sending the target synchronization frame when the local machine is a temporary synchronization source, and updating the executed state version with the composite state version in the target synchronization frame.

[0032] Device identifiers are used to distinguish different lighting nodes within a peer-to-peer network. They can be derived from the microcontroller's unique chip number, the physical address of the network interface, the serial number written at the factory, or a combination of these. Device identifiers remain unique within the same peer-to-peer network and can be represented as integers, byte sequences, or character sequences. To facilitate consistent version comparisons across nodes, device identifiers can be converted into fixed-length sortable fields during network configuration. When a byte sequence is used for the device identifier, nodes compare according to the same byte order; when an integer is used, nodes compare according to an unsigned integer.

[0033] The epoch value is used to divide the counting space corresponding to different start-up cycles of the lighting node. The monotonic count value is used to indicate the sequence in which the machine forms valid control events within the current start-up cycle. The executed state version indicates the composite state version corresponding to the target working state that the machine has actually executed and confirmed. The target working state is the lighting operating state that the lighting node needs to achieve after executing the state change command, which may include the start / stop status, brightness level, lighting working mode formed by the combination of multiple channels, and cooling fan start / stop status of at least one of the red, yellow, blue, green, and white LED channels.

[0034] In this embodiment, the composite state version is represented by three sequential fields. For ease of explanation, the composite state version corresponding to the i-th control event is represented as: V i =(E i C i D i ).

[0035] Where Vᵢ represents the composite state version of the i-th control event, Eᵢ represents the current epoch value of the lighting node that generated the control event, Cᵢ represents the monotonic count value of the lighting node after incrementing within the current epoch, and Dᵢ represents the device identifier of the lighting node that generated the control event. The epoch value and monotonic count value can be unsigned integers, and the device identifier can be a fixed-length byte sequence. This expression is used to describe the organizational relationship between data fields and does not limit the number of bits occupied by each field.

[0036] As a reproducible field implementation, the epoch value and monotonic count value can each be a 64-bit unsigned integer, while the device identifier can be a 128-bit fixed-length value. Synchronization frames are transmitted according to a unified network byte order. During comparison, each lighting node first parses the field into an unsigned integer or a fixed-length byte sequence, without using the decimal display digits, string length, or processor native byte order as the basis for comparison. The bit widths described above are examples; nodes within the same logical partition should use the same field length, byte order, and comparison rules.

[0037] When a lighting node receives a valid state change command locally, it first reads the current epoch value and the current monotonic count value, increments the monotonic count value once, and then encapsulates the incremented value with the current epoch value and the local device identifier to form a composite state version. This increment operation is only triggered by valid state change commands that can form new control events. When a lighting node executes a target operating state sent by other nodes, reports its current state to a mobile terminal, or writes to the background database, it does not increment its local monotonic count value, nor does it reinterpret the aforementioned background updates as new control events. This avoids the situation where a single control event is repeatedly expanded into multiple new synchronization events after execution by multiple nodes.

[0038] The synchronization frames to be processed can come from two data paths. The first data path is the local synchronization frame generated by the local device after receiving a valid state change command, based on the target operating state and the composite state version generated by the local device. The second data path is the synchronization frame sent by other lighting nodes received by the wireless communication module. Both data paths enter the same version arbitration process, comparing the state generated by the local device with the state received by the network in a consistent field order. The synchronization frame may also include logical partition identifier, source device identifier, target operating state, composite state version, command type, payload length, and verification information.

[0039] Synchronization frames can be configured sequentially with protocol version, frame type, payload length, logical partition identifier, source device identifier, epoch value, monotonic count value, target operating state, remaining hops, and verification information. The device identifier in the composite state version should be consistent with the source device identifier of the synchronization frame; synchronization frames that are inconsistent, whose field lengths do not conform to the protocol, or whose verification fails will not be included in the candidate synchronization frame set. The target operating state uses a fixed field or type-length-value structure encoding, enabling the receiving node to determine the data boundaries corresponding to each LED channel, brightness level, operating mode, and fan status.

[0040] The version arbitration process uses a lexicographical comparison based on field order. First, the epoch value in the synchronization frame to be processed is compared with the epoch value in the executed version. If the epoch values ​​are different, the version with the higher epoch ranking has a higher version order. If the epoch values ​​are the same, the monotonic count values ​​are compared; if the monotonic count values ​​are different, the version with the larger monotonic count value has a higher version order. If both the epoch value and the monotonic count value are the same, a parallel arbitration is performed according to the preset device identifier comparison order. The preset order of device identifiers is consistent across all lighting nodes, so even if two nodes generate concurrent control events with the same epoch value and the same monotonic count value, each receiving node will still obtain the same sorting result.

[0041] To ensure a continuous logical order for composite state versions generated by different lighting nodes, each node maintains a local epoch value, a local monotonic count value, and an upper bound for observed versions. For synchronization frames with matching logical partition identifiers and successful verification, when the received epoch value is higher than the local epoch value, the local epoch value is updated to the received epoch value, and the local monotonic count value is updated to the received count value; when the two epoch values ​​are the same, the local monotonic count value is updated to the larger of the local count value and the received count value; when the received epoch value is lower, the local logical clock remains unchanged. Subsequently, when a new local control event is generated, the local monotonic count value is incremented and combined with the local device identifier, ensuring that a new event generated by a node after observing a network event does not fall before that network event.

[0042] The composite state version represents the deterministic logical order of the protocol layer, which is not equivalent to the physical time sequence of different control terminals. The device identifier provides parallel decision only when both the epoch value and the monotonic count value are the same, so that each node obtains the same sorting result for concurrent control events; a higher sorting position of the device identifier does not necessarily mean that the corresponding control event is later in real time.

[0043] The microcontroller can process synchronization frames to be processed frame by frame according to the receive queue, or it can add multiple synchronization frames that have passed the initial verification to the candidate synchronization frame set within a scheduling cycle. During frame-by-frame processing, the composite state version of the current frame is compared with the executed state version; if the version order is higher, the current frame replaces the current target synchronization frame, and processing of subsequent frames continues. During set processing, the same field comparison is performed on the composite state versions in the candidate synchronization frame set, and the synchronization frame with the highest version order is selected. Both processing methods can obtain the highest version within the candidate range.

[0044] When the composite state version of a pending synchronization frame is the same as the executed state version, it indicates that the state corresponding to that synchronization frame has already been executed, and the microcontroller will no longer drive the LED channel or cooling fan repeatedly. When multiple pending synchronization frames carry the same composite state version, one synchronization frame can be retained for subsequent processing, and the remaining synchronization frames can be discarded as duplicate synchronization frames. For synchronization frames with a version order lower than the executed state version, the current working state and the executed state version of the microcontroller remain unchanged.

[0045] After determining the target synchronization frame, the microcontroller parses the target operating state and writes the corresponding control values ​​into the LED driver circuit and fan driver circuit. After the state execution is completed, the composite state version of the target synchronization frame is written into the executed version storage area. For target synchronization frames generated locally, the microcontroller also acts as a temporary synchronization source and transmits the target synchronization frame via the wireless communication module; for target synchronization frames received from other lighting nodes, the microcontroller decides whether to forward them according to the selected propagation method, but this forwarding does not change the source device identifier and composite state version in the synchronization frame.

[0046] After receiving a valid state change instruction, the synchronization frame generated by the local machine is first used as a local candidate synchronization frame in version arbitration. If the local candidate synchronization frame is determined to be the target synchronization frame, the local machine maintains its temporary synchronization source identity for the corresponding control event and sends the frame. If a network synchronization frame with a higher version order exists during arbitration, the local machine terminates its temporary synchronization source identity for the local control event, executes the target working state associated with the higher version, and does not regenerate or rewrite the network synchronization frame in its own name. When using concurrent broadcasting, different temporary synchronization sources can send their own generated candidate synchronization frames, and receiving nodes still converge to the same target synchronization frame in the same order through the same fields.

[0047] In the above embodiments, the epoch value, monotonic count value, and device identifier form a cross-node comparable data structure. The epoch value separates different startup cycles, the monotonic count value represents the event order within the same startup cycle, and the device identifier resolves the parallel sorting when different nodes have the same first two fields. Since all nodes use the same field order, duplicate, out-of-order, or concurrently arriving synchronization frames can fall into a consistent version order. The lighting node can then select the target working state to be executed, reducing the situation where an old state replaces an already executed state and the same state is repeatedly executed.

[0048] Example 2 like Figure 6 As shown, in one embodiment, the generation of composite state versions, node restart, and non-volatile memory processing are further explained. After the lamp node is powered on, the microcontroller first reads the epoch value before restart, the previously executed state version, and the last operating state from the non-volatile memory. After successful reading, before receiving a new local state change instruction, it generates a current epoch value with a sorting position higher than the epoch value before restart and writes the current epoch value back to the non-volatile memory. The monotonic count value within the current startup cycle starts from a preset initial value and increments each time a valid state change instruction is determined.

[0049] The epoch value can be updated incrementally. For example, the epoch value before the reboot stored in non-volatile memory is E. p The epoch value used in the current startup cycle is E. c Then it can be updated according to the following formula: E c =E p +1.

[0050] Among them, E c E represents the current epoch value. pThis represents the epoch value before the restart. The epoch value field should have a bit width sufficient to cover the number of restarts within the expected lifespan of the device. When the epoch value approaches the upper limit of its representable range, the luminaire node stops generating new local control events and switches the same logical partition to an epoch field with a larger bit width or a unified new epoch reference via the maintenance terminal. Before the new reference is written and verified, the node only receives and executes verifiable synchronization frames. The epoch value does not use direct wrap-around or random number replacement for incrementing values, because these methods cannot guarantee that the sorting position of the new startup cycle will be higher than the epoch value before the restart.

[0051] To mitigate the impact of incomplete storage during abnormal power outages, the epoch value and executed state version can be stored using a dual-storage area approach. The first and second storage areas store the data content, write sequence number, and checksum, respectively. During writing, the microcontroller first writes new data to a non-currently valid storage area, performs verification, and then updates the valid marker. During reading, it selects the storage area that passed verification and has the highest write sequence number. Alternatively, flash memory pages, ferroelectric memory, or other non-volatile storage media with power-loss protection can be used.

[0052] When a node starts up, the update and verification of the current epoch value should be completed before receiving control commands from local buttons, wireless remote controls, or mobile terminals. Only after the new current epoch value has been written to the valid storage area and passed readback verification is the node allowed to generate a local composite state version. If the write or verification fails, the node enters a degraded state that only receives synchronization frames, maintaining or restoring its last operating state, but does not generate new control events as a temporary synchronization source to avoid reusing the same combination of epoch value and monotonic count value after an abnormal restart.

[0053] Upon initial power-on and without a valid epoch value being read, the microcontroller can establish the current epoch based on the factory-configured initial epoch value. If a storage verification failure is detected, the lamp node can enter a version recovery state: maintaining the LED channel in a preset safe state, receiving synchronization frames from other nodes in the same logical partition, and saving its composite state version as a new executed state version after obtaining a valid target synchronization frame. For implementations that require continued generation of local control events, an epoch value higher than the known network version can be re-established after confirmation from the maintenance terminal.

[0054] The timing for writing the executed state version is set after the target operating state has been driven. Specifically, the microcontroller first writes the target operating state to the LED driver register and the fan driver register, and then reads the driver feedback or local status register to confirm the write result. After confirmation, the target operating state and the corresponding composite state version are combined to form a state record, which is then written to non-volatile memory. If the drive writing is not complete, the executed state version is not updated, thus ensuring that the state version record corresponds to the actual lamp state.

[0055] The last operating state may include the on / off state, brightness level, operating mode indicator, and cooling fan status of each LED channel. For example, if the red channel is at 50% brightness, other color channels are off, the white channel is off, and the cooling fan is off, the state record will save the red channel enable flag, the red brightness level, and the off flags for the other channels, respectively. After a power outage and power-on, the microcontroller reads this state record and restores the outputs of each driver, while retaining the state version executed before the restart as the comparison benchmark for subsequent synchronization frames.

[0056] Maintaining the executed state version before restart means that after a node restarts, the executed version will not be cleared to zero, nor will the historical comparison benchmark be replaced simply with the local monotonic count value of the new startup cycle. The current epoch value is used for new control events subsequently generated on the local machine, while the executed state version before restart is used for comparison at the receiving end. If a network synchronization frame is received first after restarting, the composite state version of that synchronization frame is compared with the executed state version before restart; synchronization frames with a version order higher than the comparison benchmark enter the target state execution process.

[0057] For example, before restarting, luminaire node A had executed state version (8, 35, A), and its last operating state was 75% brightness in the white light channel with the fan running. After restarting, node A generates the current epoch value 9 and restores the aforementioned last operating state. If a delayed synchronization frame with composite state version (8, 30, B) is received at this time, the epoch value of this version is the same as the executed version but the monotonic count value is lower, and node A maintains its current state; if a synchronization frame with composite state version (8, 36, C) is received, this version has a higher order than the executed version, node A executes its target operating state and updates the executed state version; when node A is subsequently triggered by a new event by the local terminal, it can generate (9, 1, A) as the new composite state version.

[0058] In another implementation, non-volatile memory controls writes based on the degree of state change. No writes are performed when the target synchronization frame is a duplicate or older version frame; the state record is only updated when the target working state or the version of the executed state changes. For flash memory with limited write cycles, circular paging, logging, or delayed merge write methods can be used to make state memory and version retention independent of storing every received message.

[0059] In the above embodiments, during the startup phase, the node first updates the current epoch value and continues to save the version of the executed state before the restart. Thus, the local control events generated in the new startup cycle are separated from the local counting space before the restart, while the receiving end still has a continuous historical comparison benchmark. The target operating state and the composite state version are persisted together after confirmation of execution, ensuring that the actual output, the last state record, and the version arbitration benchmark after the lamp restart remain consistent, reducing the possibility that the delayed synchronization frame will be re-executed after the restart.

[0060] Example 3 like Figure 4 As shown in one embodiment, logical partition filtering, multi-terminal state change instructions, and synchronization frame propagation are explained. Each lighting node stores a unique device identifier as well as a logical partition identifier. The logical partition identifier indicates the control area to which the lighting node belongs and can be implemented using a group identifier, subnet identifier, multicast address, or network signature. Different logical partitions within the same physical network can share communication links, but the synchronization frame only controls the state of lighting nodes whose logical partition identifiers match.

[0061] After receiving a synchronization frame, the lighting node first parses the logical partition identifier, payload length, and verification information in the frame header. If the logical partition identifier matches the pre-stored logical partition identifier and the verification result is correct, the synchronization frame is added to the candidate synchronization frame set; if the logical partition identifier does not match, the target operating state within it is not parsed; if the verification fails, the synchronization frame is discarded and the number of communication anomalies can be recorded. After the candidate synchronization frame set is formed, the epoch value, monotonic count value, and version bit of the source device identifier are compared.

[0062] The logical partition identifier is also used to determine the validity of wireless remote control commands. When a wireless remote control is bound to a zoned lighting fixture, it can save the remote control identifier, logical partition identifier, and binding confirmation code. After receiving a status change command from the wireless remote control, the lighting fixture node verifies the remote control identifier, logical partition identifier, and binding confirmation code in the command. If the verification result matches the local binding relationship, it proceeds to the subsequent command verification and concurrent identification process; if they do not match, no new control event is generated.

[0063] like Figure 5 As shown, in one logical partition configuration method, the program upgrade rack or configuration terminal writes a unique device identifier and a logical partition identifier to each lighting node, and establishes a binding relationship between the remote control identifier and the corresponding logical partition identifier. The lighting node only performs subsequent processing on the control commands and synchronization frames that match the logical partition identifier; the program upgrade rack is used for writing configuration data, does not act as a fixed host in the peer-to-peer lighting network, and does not participate in the generation and arbitration of composite state versions during normal operation.

[0064] like Figure 3As shown, status change commands can be generated by physical buttons on the device, wireless remote controls, or mobile terminals. Status change commands include a control terminal identifier, a target luminaire identifier or logical partition identifier, a target operating status, a command sequence number or time information, and verification information. The control terminal identifier distinguishes the command entry point, the target luminaire identifier specifies a single luminaire, the logical partition identifier specifies a group of luminaires, the target operating status describes the LED channel and fan status to be executed, the command sequence number or time information identifies commands repeatedly sent from the same terminal, and the verification information determines the completeness of the transmitted content.

[0065] For commands generated by physical buttons, the control terminal identifier can be the local button interface number, and the command sequence number is generated by the local button event counter. For commands generated by a wireless remote control, the control terminal identifier can be the remote control identifier, and the command sequence number is generated by incrementing the remote control identifier. For commands generated by a mobile terminal, the control terminal identifier can consist of an application instance identifier and a user session identifier; the command sequence number can be generated by the mobile terminal or use time information with sufficient resolution. Commands from different terminals are all converted into a unified internal command structure after entering the lighting fixture node.

[0066] Command sequence numbers or time information are only used for repeated identification and order determination within the instruction stream corresponding to the same control terminal identifier, and are not directly compared with the local time of different control terminals. Valid state change commands generated simultaneously by different control terminals are processed by each receiving lighting node to generate a composite state version, and cross-terminal arbitration is completed through the order of epoch value, monotonic count value, and device identifier. This eliminates the requirement for the wireless remote controller, mobile terminal, and lighting nodes to maintain physical clock synchronization.

[0067] The process of determining a valid state change instruction can sequentially include integrity verification, target matching, and duplication screening. Integrity verification confirms that the verification information corresponds to the instruction payload; target matching confirms that the target luminaire identifier points to the local machine, or that the logical partition identifier is the same as the local partition; duplication screening compares the most recent command sequence number or time information corresponding to the control terminal identifier. Instructions processed through the above steps are determined to be valid state change instructions, and the luminaire node receiving the instruction is determined as the temporary synchronization source for this control event.

[0068] When multiple terminals send valid state change commands to different lighting nodes within a similar time period, each receiving node forms a temporary synchronization source and generates a composite state version. For example, if node A and node B both have a current epoch value of 12 and a current monotonic count value of 7, after receiving valid commands from the mobile terminal and wireless remote control respectively, they both increment their monotonic count values ​​to 8, forming (12, 8, A) and (12, 8, B). Each node first compares the epoch value and the monotonic count value; if they are the same, it then compares the device identifier. Since the device identifier comparison order is consistent throughout the network, each node ultimately selects the same synchronization frame as the target synchronization frame.

[0069] When a temporary synchronization source sends a target synchronization frame, it can use a UDP broadcast link on a Wi-Fi LAN or a Bluetooth Mesh network. When using a UDP broadcast link, the temporary synchronization source sends the synchronization frame to a preset broadcast port, and lighting nodes in the same LAN listen to this port and perform partition filtering. When using a Bluetooth Mesh network, the synchronization frame can be encapsulated as a model message, which is then propagated by nodes with forwarding capabilities according to controlled forwarding rules. Changes in the communication medium do not alter the composition and comparison order of the composite state version.

[0070] Synchronization frame propagation can employ single broadcast, hop-limited forwarding, or partition proxy forwarding. In single broadcast, the temporary synchronization source sends only one round of the target synchronization frame, suitable for networks where nodes can communicate directly. In hop-limited forwarding, the synchronization frame carries the remaining hop count; after the receiving node completes partition verification and duplicate frame detection, it decrements the remaining hop count by one and forwards it if it is greater than zero; the composite state version, source device identifier, and target operating state remain unchanged during forwarding. In partition proxy forwarding, the target synchronization frame is forwarded by a pre-configured or dynamically determined proxy node within the partition; ordinary receiving nodes do not retransmit it.

[0071] The remaining hop count segment belongs to propagation control information and is not part of the composite state version. When the receiving node performs a limited-hop-count forwarding, it only decrements the remaining hop count and recalculates the synchronization frame check information before forwarding; the logical partition identifier, source device identifier, epoch value, monotonic count value, and target operating state remain unchanged. The index of the seen version cache can be constructed by both the logical partition identifier and the composite state version to avoid versions with the same value in different partitions from overwriting cache records.

[0072] To limit broadcast storms, lighting nodes can be configured with a seen version cache. The seen version cache stores a preset number of composite state versions and their reception times. When a synchronization frame already existing in the cache is received, it is not forwarded again. The cache is only used for communication deduplication and does not replace executed state versions; even if a cache entry is removed due to capacity limitations, newly arriving old synchronization frames will still be identified by comparing them with executed state versions.

[0073] Background status update refers to the process by which a lighting node, after executing a target working state, reports its current status to a mobile terminal, gateway, or management platform. The background status update includes the device identifier, current working state, and executed state version, but it is not converted into a new status change instruction, does not increment the monotonic counter value, and does not change the event source of the original target synchronization frame. Therefore, after a control event completes state propagation within a partition, it will not cause circular synchronization due to status reports from multiple nodes.

[0074] In the above embodiments, the logical partition identifier is used simultaneously for synchronization frame reception filtering and wireless remote control permission determination, ensuring that communication range and control permissions use the same partition basis. Instructions generated by multiple terminals are converted into a unified field and undergo verification, target matching, and duplicate detection. Any node receiving a valid instruction can become a temporary synchronization source. The propagation method, combined with version arbitration, maintains the identity of the synchronization frame under broadcast, mesh forwarding, or proxy forwarding conditions, and reduces duplicate forwarding and cross-partition execution.

[0075] Example 4 In one embodiment, the LED light source status, cooling fan status, and mobile terminal partitioning aggregation in the target operating state are described. The lighting node includes red, yellow, blue, green, and white LED channels, each controlled by an independent LED driver branch. The center wavelength of the red channel can be set to approximately 630 nm, the yellow channel to approximately 600 nm, the blue channel to approximately 470 nm, the green channel to approximately 520 nm, and the white channel can use a full-spectrum plant growth light source. The above wavelengths illustrate one implementation method; different light source devices can be adjusted according to the photoresponse characteristics of the target crop and target pests.

[0076] Each LED channel can be configured with multiple brightness levels. For example, brightness levels include 0%, 25%, 50%, 75%, and 100%, where 0% indicates that the corresponding channel is off. The target operating state can specify only one LED channel or a combination of multiple channels. After receiving the target synchronization frame, the luminaire node converts the brightness level of each channel into a pulse width modulation duty cycle, constant current drive level, or digital dimming value, and then writes it to the corresponding LED driver branch.

[0077] The physical pest-repelling state referred to in this application refers to the lighting operation state formed by selecting at least one LED light source channel, corresponding brightness level, duration, and cycle period based on the target pest's response data to the spectrum and irradiation rhythm or on-site calibration results. Different pest-repelling mode identifiers and parameter tables can be configured for different target pests or planting environments, and the lighting nodes execute and synchronize the lighting state according to the selected parameter table. This embodiment does not assume that any fixed wavelength has the same repelling effect on all pests; the specific light source combination and irradiation parameters should be determined in conjunction with the target pest species and application environment.

[0078] The start / stop status of the cooling fan is not simply synchronized with any one light source channel, but is determined based on the calibration data of each LED channel at different brightness levels. Calibration data may include rated power, junction temperature, or temperature rise data. Taking rated power and heat load contribution coefficient as an example, the predicted heat load Q of the current light source combination can be determined according to the following formula: Q=ΣP i ·a i ·k i .

[0079] Wherein, Pᵢ represents the rated power of the i-th LED channel, in watts; aᵢ represents the normalized drive ratio corresponding to the current brightness level of the i-th LED channel, ranging from 0 to 1; kᵢ represents the heat load contribution coefficient determined based on the temperature rise test of this channel, which is a dimensionless parameter; and Q represents the equivalent predicted heat load of the current light source combination, in watts. Pᵢ and kᵢ for each channel are written into the luminaire node after factory calibration or maintenance calibration.

[0080] Fan control employs a start-up threshold and a stop-down hysteresis threshold. Let the fan start-up threshold be Q. on The threshold for closing is Q. off If the hysteresis is H, then Q can be set. off =Q on -H, and H is greater than zero. When the fan is off and the predicted heat load Q reaches or exceeds Q... on When the fan is running, determine the fan startup status; when the fan is running and the predicted heat load Q drops to Q0... off When Q is below or equal to Q, the fan is confirmed to be off; when Q is at Q... off With Q on During this period, keep the fan in its original state.

[0081] By employing the aforementioned hysteresis relationship, frequent fan start-stop cycles can be avoided when the predicted heat load fluctuates around a single threshold. If the calibration is based on junction temperature or casing temperature rise, the corresponding temperature prediction and temperature threshold can be used to perform the same hysteresis judgment, but the compared quantity and threshold in the same judgment use the same units. The microcontroller can also correct the predicted heat load based on temperature sensor feedback, adapting the rated power calibration to changes in actual ambient temperature.

[0082] When the luminaire model, LED rated power, and heat dissipation structure are consistent within the same logical partition, the fan start / stop status can be determined and synchronized by a temporary synchronization source. When there are different power specifications within the partition, the target operating status can also carry the light source combination and calibration version identifier. Each luminaire node uses calibration data matched with its own unit to verify the fan status. If the temperature sensor detects that the unit temperature exceeds the safe condition, the local protection logic can correct the fan from off to on and report the protection status. However, this protection status report does not convert into a new status change instruction, nor does it trigger a monotonic count increment.

[0083] For example, when a single color light source is running at a lower brightness level, if the predicted heat load obtained from calibration data is below the fan start threshold, the fan remains off. When a white light channel or a combination of multiple LED channels is running, if the predicted heat load reaches the fan start threshold, the fan starts. The fan shuts off when the channel brightness decreases and the predicted heat load drops to the shutdown threshold. These control results, as part of the target operating state, are written into the target synchronization frame along with the LED channel state, ensuring that all luminaires within the same logical partition switch according to the same state.

[0084] like Figure 2 As shown, in the calibration results of a certain lamp specification, when the predicted heat load is below the fan start threshold during single-channel operation of red, yellow, blue, or green light, the cooling fan remains off; when the predicted heat load reaches the fan start threshold during white light channel operation, the cooling fan starts. The linkage states in the figure are examples under the corresponding lamp specifications and brightness conditions. The actual fan status is still determined based on the comparison results of the machine calibration data, fan start threshold, and shutdown hysteresis threshold.

[0085] When a mobile terminal needs to manage multiple lighting nodes, it can send a device discovery request. Upon receiving the request, the lighting node provides device information including its local device identifier, logical partition identifier, and online status. It can also report the current execution version and current operating status. Device discovery can be accomplished via the Wi-Fi LAN discovery protocol or by proxy nodes in a Bluetooth Mesh network aggregating and reporting the information.

[0086] The mobile terminal maps the device identifiers of multiple lighting nodes to the same partition object according to the logical partition identifier. The partition object stores the partition identifier, the set of member device identifiers, the online status of members, and the overall working status. The mobile terminal interface can display the partition name and the current lighting mode of the partition, without having to arrange each lighting node as an independent control object. When the user selects a partition object and sets the target working status, the mobile terminal generates a status change instruction containing the logical partition identifier.

[0087] When a member is added, removed, or their online status changes, the mobile terminal updates the member information of the partition object. The online ratio can be determined based on the current number of online members and the number of registered members. Let the number of online members be N. o The number of registered members is N t The online proportion R can be expressed as: R=N o / N t .

[0088] Where, N t Greater than zero. Mobile terminals can add an anomaly flag when R falls below a preset display condition, or list offline device identifiers. The online ratio and anomaly flags reflect the communication status of partitioned devices and are not involved in the field comparison of composite status versions. After a partitioned member comes back online, its lamp nodes compare the received synchronization frames with the executed status versions stored locally, and decide whether to update the status according to the version order.

[0089] In the above embodiments, the brightness status and fan status of each LED channel form a synchronized target operating state. The predicted heat load is determined based on rated power, brightness ratio, and calibration coefficient, ensuring that fan start / stop corresponds to the heat dissipation requirements of the current light source combination; start-up thresholds and shutdown hysteresis thresholds reduce frequent switching near the thresholds. The mobile terminal aggregates device information according to logical partition identifiers, providing partition-level status display and control entry without changing the node-level version arbitration process.

[0090] Example 5 In one embodiment, a multifunctional LED physical insect repellent lamp control system is provided. The system includes multiple lamp nodes forming a peer-to-peer lamp network without a fixed host. Each lamp node includes a data acquisition module, a composite version generation module, a version arbitration module, a status execution module, a communication module, and a restart processing module. These modules can be implemented by program functional units running on a microcontroller, or by a combination of processing circuits, memory, and communication circuits.

[0091] The data acquisition module is used to read device identifier, epoch value, monotonic count value, and executed state version from local non-volatile memory. It also acquires state change commands and synchronization frames from the button interface, remote control receiver interface, mobile terminal communication interface, or network receive queue. The data acquisition module adds source types to data from different sources to help subsequent modules distinguish between local control events and network synchronization events.

[0092] The composite version generation module increments a monotonic counter value when a valid state change command is received locally, and encapsulates the composite state version in the order of epoch value, incremented monotonic counter value, and local device identifier field. The module encapsulates the target operating state, logical partition identifier, source device identifier, composite state version, and verification information into a synchronization frame to be processed. For synchronization frames received from the network, the module does not regenerate the version field but retains the original composite state version of the synchronization frame.

[0093] The version arbitration module includes a partition filtering unit, a verification unit, and a version comparison unit. The partition filtering unit verifies the logical partition identifier of the synchronization frame, the verification unit verifies the verification information of the synchronization frame, and the version comparison unit compares the filtered composite state versions with the executed state versions in the order of epoch value, monotonic count value, and device identifier. The version arbitration module determines the target synchronization frame from the candidate synchronization frames and outputs the target working state associated with the target synchronization frame as the pending execution state.

[0094] The state execution module is connected to the LED driver circuit and the fan driver circuit. The state execution module converts the state to be executed into drive parameters for each LED channel and fan control parameters, and updates the machine's operating status after completing the drive. The state execution module also submits the target operating state and the composite state version to the storage management unit. The storage management unit updates the executed state version and the last operating state after confirming that the state execution has been completed.

[0095] The communication module is used to send and receive synchronization frames. When the corresponding lighting node is a temporary synchronization source, the communication module sends the target synchronization frame using one of the following methods: single broadcast, limited hop forwarding, or partition proxy forwarding. When the corresponding lighting node is a regular receiving node, the communication module hands the received synchronization frame over to the version arbitration module and decides whether to forward it based on the propagation configuration. The communication module can also respond to device discovery requests from mobile terminals, providing feedback on device identifiers, logical partition identifiers, and online status.

[0096] The restart processing module reads non-volatile storage content when the lighting node starts up, generates a current epoch value with a sorted position higher than the epoch value before restart, and retains the previously executed state version. The restart processing module also restores the LED channel and cooling fan states based on the last operating state. The current epoch value is used to generate a new composite state version after the machine starts up, while the previously executed state version continues to serve as the comparison benchmark when receiving synchronization frames.

[0097] In one hardware implementation, the microcontroller's internal unique identifier is encoded to form a device identifier. External flash memory stores the logical partition identifier, epoch value, monotonic count value, executed state version, and last operating state. A Wi-Fi or Bluetooth chip constitutes the communication module. Multiple constant current drivers are connected to red, yellow, blue, green, and white LED arrays, respectively. A fan driver controls a DC fan via switching devices. The microcontroller processes the communication receive queue through a timed task, receives physical button events through an interrupt interface, and acquires data from the wireless communication circuit through a serial interface.

[0098] In one software implementation, the system program includes an instruction access task, a synchronization frame reception task, a version arbitration task, a state execution task, and a storage task. The instruction access task converts instructions generated by different terminals into a unified internal format; the synchronization frame reception task performs frame boundary identification and verification; the version arbitration task selects the target synchronization frame according to field order; the state execution task drives the LED channel and fan; and the storage task uses a queue to receive data that needs to be persisted and completes writing to both storage areas. Data can be exchanged between tasks via message queues or a shared state structure.

[0099] To prevent the communication receiving task and the local instruction task from simultaneously modifying the executed state version, version comparison, driver confirmation, and version writing are completed by the same serial arbitration task or protected by a mutual exclusion mechanism. Newly arrived synchronization frames during the execution of a target working state enter the processing queue; after the current state execution is completed and the executed state version is updated, the updated version is used as the comparison benchmark for processing synchronization frames in the queue. When a driver feedback anomaly or non-volatile memory verification fails, the corresponding composite state version is not submitted, and the fault status is recorded for the mobile terminal or maintenance terminal to read.

[0100] The following scenario illustrates the synchronization of lights in a partitioned greenhouse. The greenhouse is divided into a first planting area and a second planting area. Each planting area is configured with multiple light nodes. The two planting areas use the same wireless LAN but store different logical partition identifiers. A mobile terminal in the first planting area sends a state change command to any of the light nodes, setting the blue light channel to 50% brightness. After verifying the command, the light node becomes a temporary synchronization source, increments its local monotonic counter value, forms a composite state version, and sends the target synchronization frame.

[0101] After receiving the synchronization frame, other lighting nodes in the first planting area match the logical partition identifier, add the synchronization frame to the candidate set, and perform a version comparison. If the version order is higher than the already executed state version, the blue light channel is adjusted to 50% brightness and the already executed state version is updated. Although the lighting nodes in the second planting area can receive the wireless message, they do not execute the target working state because the logical partition identifier does not match.

[0102] Subsequently, the wireless remote control in the first planting area sends a state change command for the white light channel to 75% brightness to another lighting node. This node becomes the new temporary synchronization source and forms a new composite state version. If the previous blue light synchronization frame arrives again due to network latency, each node compares its version with the already executed white light synchronization frame version; the node with the lower version number maintains the white light state. Based on the calibrated heat load of the white light channel, when the predicted heat load reaches the fan start threshold, each node simultaneously starts its cooling fan.

[0103] When one of the lighting nodes experiences a power outage and restarts, it reads the last white light state and the previously executed state version, restores the white light channel and fan state, and updates the current epoch value. If synchronization frames earlier than the previously executed version are still propagating in the network, the node identifies their version order based on the saved comparison benchmark and does not execute the old state due to a restart of its local monotonic count value. When the node subsequently receives a new local button command, it uses the updated epoch value to generate a new composite state version.

[0104] In the above scenario, the mobile terminal can also initiate device discovery, aggregating lighting nodes within the first planting area according to logical partition identifiers, and displaying the number of members, online ratio, and current working status. When a node goes offline, the mobile terminal updates the anomaly flag; after the node comes back online, it completes the status transition by receiving a new target synchronization frame or comparing it with the previously executed status version. The mobile terminal's aggregation display and status reporting do not trigger new synchronization events.

[0105] In the above embodiments, the system modules correspond to the hardware resources of the lighting nodes, and data acquisition, version generation, version arbitration, state execution, communication, and restart processing form a continuous data processing chain. Any node can form a temporary synchronization source based on a valid state change instruction, and events generated by multiple nodes are ordered in a unified manner through composite state versions; partition identifiers limit the scope of synchronization frames, non-volatile storage maintains the state and version baseline across restarts, and light source thermal load control enables the fan state and target operating state to jointly complete partition synchronization.

[0106] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method of controlling a multi-functional LED physical insect repellent light, characterized in that, The method, executed by luminaire nodes in a peer-to-peer luminaire network without a fixed host, includes: Retrieve the local device identifier, epoch value, incrementing monotonic counter value, and executed state version; A composite state version is generated based on the epoch value, the incrementing monotonic count value, and the device identifier. The composite state version is associated with the target working state to form a synchronization frame to be processed. The epoch value, incrementing monotonic count value, and device identifier in the synchronization frame to be processed are compared with those in the executed state version in turn. Based on the comparison results, the synchronization frame to be processed with a higher version order than the executed state version is determined and defined as the target synchronization frame. The target working state associated with the target synchronization frame is determined as the state to be executed. The target working state is the lamp operating state that the lamp node needs to achieve after executing the state change instruction. When executing a pending state, if the local machine is a temporary synchronization source, send the target synchronization frame and update the executed state version with the composite state version of the target synchronization frame.

2. The method of claim 1, wherein, The generation of a composite state version based on the epoch value, an incremental monotonically increasing count value, and the device identifier includes: Read the epoch value before restart from non-volatile storage; when the node restarts, generate the current epoch value whose sorting position is higher than the epoch value before restart. Upon receiving a valid state change instruction, the monotonic count value is incremented in the counting space corresponding to the current epoch value, and a composite state version is encapsulated in the order of the current epoch value, the incremented monotonic count value, and the field of the local device identifier.

3. The method of claim 2, wherein, The step of sequentially comparing the epoch value, the incrementing monotonic count value, and the device identifier in the synchronization frame to be processed with the executed state version includes: Compare the epoch values; if the epoch values ​​are the same, compare the incremental monotonic count values; if both are the same, determine the version position according to the preset order of the device identifier. From the pending synchronization frames whose version rank is higher than that of the executed version, select the synchronization frame with the highest version rank as the target synchronization frame, and discard the remaining synchronization frames and duplicate synchronization frames with the same version rank as the composite state.

4. The method of claim 3, wherein, Before selecting the synchronization frame with the highest version ranking as the target synchronization frame, the following steps are included: Extract logical partition identifiers and verification information from the synchronization frames to be processed. Add the synchronization frames to be processed that match the logical partition identifiers with the pre-stored logical partition identifiers on the local machine and pass the verification to the candidate synchronization frame set. Perform version ranking comparison based on the candidate synchronization frame set. The pre-stored logical partition identifiers on the local machine are also used to determine the validity of the status change commands sent by the wireless remote controller.

5. The method of claim 4, wherein, The determination of the valid state change instruction includes: Receive a status change command generated by the device's physical buttons, wireless remote control, or mobile terminal. The status change command includes a control terminal identifier, a target lighting fixture identifier or logical partition identifier, a target working status, a command sequence number or time information, and verification information. Based on the verification information, the verified status change command is determined, and the verified status change command is concurrently screened according to the command sequence number or time information. The screened status change command is determined as a valid status change command, and the lamp node that receives the valid status change command is determined as the temporary synchronization source of the corresponding control event. The background status update formed after the target working state is executed is not used as a new control event triggering source.

6. The method of any one of claims 1 to 5, wherein, The target operating state also includes the cooling fan start / stop state, and the determination of the cooling fan start / stop state includes: Obtain the rated power, junction temperature, or temperature rise calibration data of each LED light source channel at different brightness levels, and determine the predicted heat load corresponding to the current light source combination based on the calibration data; The predicted heat load is compared with the fan start threshold and the shutdown hysteresis threshold. When the predicted heat load reaches the fan start threshold, the fan start state is determined. When the predicted heat load drops to the shutdown condition determined by the shutdown hysteresis threshold, the fan shutdown state is determined. The determined fan start and shutdown states are added to the target operating state.

7. The method of claim 6, wherein, After obtaining the device identifier of the local machine, the method further includes: The system receives device discovery requests from mobile terminals and feeds back device information to the mobile terminals, including local device identifier, logical partition identifier, and online status. This enables the mobile terminals to map the device identifiers of multiple lighting nodes to the same partition object according to the logical partition identifier. When partition members are added, removed, or offline, the system updates the member information, online ratio, and anomaly flags of the corresponding partition object.

8. The method of claim 5, wherein, After executing the pending state and updating the version of the executed state, the method further includes: Write the target working state and its composite state version associated with the target synchronization frame into the non-volatile memory as the comparison benchmark for the last working state and restart. When a node restarts, it reads the last working state and the version of the executed state before restarting. Based on the last working state, it restores the start / stop state and brightness level of the LED light source channel. After updating the epoch value, it retains the version of the executed state before restarting and uses the executed state version to participate in the version comparison of the synchronization frames to be processed received after restarting.

9. The method of claim 5, wherein, The transmission of the target synchronization frame includes: The target synchronization frame is sent via a UDP broadcast link of a Wi-Fi LAN or a Bluetooth Mesh network, and one of the following propagation methods is used: single broadcast, limited hop forwarding, or partitioned proxy forwarding. In the case of single broadcast, a round of target synchronization frames is sent by a temporary synchronization source. When using hop-limited forwarding, the receiving node forwards the data within the network hop count limit specified by the target synchronization frame; When using partitioned proxy forwarding, the proxy node of the corresponding logical partition forwards the target synchronization frame; Background state updates resulting from the execution of the target working state do not trigger the regeneration of synchronization frames.

10. A multi-functional LED physical insect repellent lamp control system for implementing the control method of any one of claims 1-9, characterized in that, It includes multiple lighting nodes, which form a peer-to-peer lighting network without a fixed host. Each lighting node includes: The data acquisition module is used to acquire the local device identifier, epoch value, incremental monotonic count value, and executed version. The composite version generation module is used to generate a composite state version based on the epoch value, the incremental monotonic count value and the device identifier, and associate the composite state version with the target working state to form a synchronization frame to be processed. The version arbitration module is used to compare the epoch value, incremental monotonic count value and device identifier in the pending synchronization frame with the executed version in turn, and determine the target synchronization frame and pending execution state based on the comparison results. The state execution module is used to execute the state to be executed and update the executed state version with the composite state version of the target synchronization frame; The communication module is used to send the target synchronization frame when the corresponding lighting node is a temporary synchronization source; The restart processing module is used to update the epoch value when the lighting node restarts and to maintain the version of the executed state before the restart.

Images