Methods and systems for synchronous control of lighting equipment across protocols, electronic devices and media

Abstract

This application provides a method and system for cross-protocol lighting device synchronization control, an electronic device, and a medium. The method includes: dividing the communication link between the bridge-end device and the lighting device into four logical stages; the four logical stages include a device discovery stage, a queue scheduling stage, a wireless transmission stage, and a device execution stage; dynamically allocating jitter delay budgets for each logical stage; generating corresponding lighting control commands based on user-triggered lighting scenes; the lighting control commands include a target execution time point, a luminous efficacy transition curve, and the jitter delay budget; and sending the lighting control commands to the lighting device based on a reliable multicast protocol. This application, by employing a refined delay budget allocation mechanism and combining it with closed-loop feedback control of execution errors, can maintain high-precision, smooth, and stable synchronization between multi-protocol lighting devices under adverse conditions such as complex electromagnetic environments, high network loads, or sudden interference.

Description

Technical Field

[0001] This application belongs to the field of intelligent lighting control technology, and relates to a method and system for synchronous control of cross-protocol lighting devices, electronic devices and media. Background Technology

[0002] In intelligent lighting control systems, with the increasing number of lamps and the diversification of communication protocols used, achieving precise synchronous control of multiple lamps in the time dimension presents significant challenges.

[0003] In practical applications, when multiple lights need to switch states simultaneously, a visually perceptible "asynchrony" often occurs. The root cause of this problem lies in the fact that multiple processing stages must occur between the issuance of a control command and the actual execution by the lights. Each processing stage has varying degrees of time delay and jitter, and these delays are both random and cumulative. When multiple lights experience inconsistent processing delays due to differences in protocols, network load, hardware performance, or communication paths, their response times ultimately deviate, thus disrupting the synchronization and consistency of the overall lighting effect. Summary of the Invention

[0004] This application provides a method and system for synchronous control of cross-protocol lighting equipment, an electronic device, and a medium to improve the synchronous control accuracy of multi-protocol lighting equipment.

[0005] In a first aspect, this application provides a cross-protocol lighting device synchronization control method, applied to a bridge-end device, wherein multiple lighting devices of the bridge-end device are connected via different communication protocols; the method includes: dividing the communication link between the bridge-end device and the lighting devices into four logical stages; the four logical stages include a device discovery stage, a queue scheduling stage, a wireless transmission stage, and a device execution stage; dynamically allocating jitter latency budgets for each logical stage; generating corresponding lighting control instructions based on a user-triggered lighting scene; the fields in the lighting control instructions include a target execution time point, a light effect transition curve, and the jitter latency budget; and sending the lighting control instructions to the lighting devices based on a reliable multicast protocol, wherein the lighting devices synchronously execute the lighting actions defined by the light effect transition curve within the jitter latency budget and according to the target execution time point.

[0006] In one implementation of the first aspect, sending the lighting control command to the lighting device based on a reliable multicast protocol includes: fragmenting the lighting control command to obtain multiple command fragments; performing forward error correction coding on each command fragment to generate a coded packet containing redundancy check information; concurrently sending the coded packet to all lighting devices via the air interface based on a multi-round multicast mechanism; obtaining the reception confirmation signal fed back by each lighting device and performing aggregation processing on the reception confirmation signal to obtain aggregated confirmation information; determining whether the current multicast cycle has successfully covered all lighting devices based on the aggregated confirmation information; when there are unacknowledged lighting devices, initiating a multi-round multicast retransmission mechanism to retransmit the corresponding coded packet in one or more subsequent multicast cycles; if after a preset maximum number of retransmissions, there are still unacknowledged lighting devices, then triggering a point-to-point unicast retransmission operation for the unacknowledged lighting devices; and dynamically executing packet throttling control based on the load status of the air interface during multicast and retransmission.

[0007] In one implementation of the first aspect, before issuing the lighting control command to the lighting device, the method further includes: periodically broadcasting an anchor clock signal to each lighting device; the anchor clock signal is used to establish and maintain a unified time reference shared by all lighting devices.

[0008] In one implementation of the first aspect, dynamically allocating jitter latency budget for each logical stage includes: obtaining the allowable jitter allowance of the communication link; the allowable jitter allowance is jointly determined by the historical real jitter latency of each logical stage, the local clock drift of the lighting device, the type of communication protocol, and the load of the communication link; dynamically allocating the jitter budget weight of each logical stage according to the real-time jitter ratio of each logical stage; and allocating the allowable jitter allowance to the four logical stages according to the jitter budget weight; wherein the logical stage with a higher real-time jitter ratio is allocated more jitter latency budget.

[0009] In one implementation of the first aspect, based on a statistical analysis algorithm, the historical true jitter latency of each logical stage is calculated respectively; wherein the calculation process includes: recording the bridge-side timestamp; the bridge-side timestamp includes: T0, representing the moment when the bridge-side device initiates scanning of the lighting device; T1, representing the moment when the bridge-side device receives the scanning response from the lighting device; T2, representing the enqueue moment when the historical control command is written into the bridge-side scheduling queue; T3, representing the dequeue moment of the historical control command; recording the device-side timestamp; the device-side timestamp includes: T4, representing the moment when the lighting device receives the historical control command; T5, representing the moment when the lighting device completes the execution of the historical control command; based on the bridge-side timestamp and the device-side timestamp, the historical true jitter latency of each logical stage is calculated respectively; wherein the device discovery latency is Δ_discovery = T1-T0; the queue scheduling latency is Δ_queue = T3-T2; the wireless transmission latency is Δ_wireless = T4-T3; and the device execution latency is Δ_execute. =T5-T4.

[0010] In one implementation of the first aspect, the method further includes: acquiring current network status parameters; the current network status parameters include at least one of wireless signal strength, packet loss rate, and bridge-end queue level; acquiring feedback information reported by each lighting device to the bridge-end device after synchronously completing the lighting action; the feedback information includes the local clock drift and execution error of the lighting device; the execution error is the deviation between the actual execution time of the lighting device and the target execution time point; and dynamically adjusting the target execution time point and the jitter delay budget in the lighting control command based on the current network status parameters and the feedback information.

[0011] In one implementation of the first aspect, the method further includes: automatically switching to a smooth degradation mode when the execution error exceeds the jitter delay budget of the corresponding logic stage; the smooth degradation mode includes at least one of the following operations: extending the luminous efficacy transition time of the lighting device; reducing the slope of the luminous efficacy transition curve; replacing the luminous efficacy transition curve with a degradation transition curve; the degradation transition curve includes a slow-in / slow-out function, a low-order Bezier curve, or an exponential decay function.

[0012] Secondly, this application provides a cross-protocol lighting device synchronous control system, comprising: a bridge-end device configured to perform the method as described in any of the above claims; and a plurality of lighting devices, each of which is connected to the bridge-end device via a different communication protocol and is configured to receive lighting control commands sent by the bridge-end device and synchronously execute lighting actions based on the lighting control commands.

[0013] Thirdly, this application provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program stored in the memory to cause the electronic device to perform the method described in any of the preceding claims.

[0014] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the preceding claims.

[0015] As described above, the cross-protocol lighting device synchronization control method and system, electronic equipment and medium described in this application, by adopting a refined time delay budget allocation mechanism and combining it with closed-loop feedback control of execution error, can maintain a high-precision, smooth and stable synchronization effect between multi-protocol lighting devices under adverse conditions such as complex electromagnetic environment, high network load or sudden interference. Attached Figure Description

[0016] Figure 1 The diagram shown is a structural schematic of a cross-protocol lighting equipment synchronization control system according to an embodiment of this application.

[0017] Figure 2 The flowchart shown is a cross-protocol lighting device synchronization control method according to an embodiment of this application.

[0018] Figure 3 The diagram shown illustrates the allocation flowchart of the jitter latency budget according to an embodiment of this application.

[0019] Figure 4 The flowchart shown is a calculation flowchart of the historical real jitter latency according to an embodiment of this application.

[0020] Figure 5 The diagram shows a message of a lighting control command according to an embodiment of this application.

[0021] Figure 6 The flowchart shown is a process for issuing lighting control commands based on a reliable multicast protocol according to an embodiment of this application.

[0022] Figure 7 The diagram shown illustrates the timing of the issuance and execution of lighting control commands according to an embodiment of this application.

[0023] Figure 8 The flowchart shown is a cross-protocol lighting device synchronization control method according to another embodiment of this application.

[0024] Figure 9 The diagram shown is a structural schematic of a cross-protocol lighting device synchronization control system according to another embodiment of this application.

[0025] Figure 10The diagram shown is a structural schematic of an electronic device according to an embodiment of this application. Detailed Implementation

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

[0027] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0028] The following embodiments of this application provide a method, system, electronic device, and medium for cross-protocol lighting device synchronization control, which addresses the problem of decreased synchronization of lighting devices caused by factors such as network dynamism, transmission delay fluctuations, and external interference in environments with coexisting heterogeneous communication protocols. This application, by employing a refined delay budget allocation mechanism combined with closed-loop feedback control of execution errors, can maintain high-precision, smooth, and stable synchronization between multi-protocol lighting devices under adverse conditions such as complex electromagnetic environments, high network loads, or sudden interference.

[0029] Please see Figure 1 The diagram shown is a structural schematic of a cross-protocol lighting equipment synchronization control system according to an embodiment of this application.

[0030] like Figure 1 As shown, this application provides a cross-protocol lighting device synchronization control system, including a bridge-end device and multiple lighting devices.

[0031] The bridge-end device is configured to perform the cross-protocol lighting device synchronization control method described in this application.

[0032] Each of the lighting devices communicates with the bridge-end device via a different communication protocol, and is configured to receive lighting control commands sent by the bridge-end device, and synchronously execute lighting actions based on the lighting control commands. The communication protocols include Zigbee, Thread, and Wi-Fi.

[0033] The following will describe in detail the principles and implementation methods of a cross-protocol lighting device synchronization control method and system, electronic equipment and medium of this embodiment, so that those skilled in the art can understand the cross-protocol lighting device synchronization control method and system, electronic equipment and medium of this embodiment without creative effort.

[0034] The cross-protocol lighting device synchronization control method described in this embodiment is applied to a bridge-end device, which is connected to multiple lighting devices through different communication protocols.

[0035] Please see Figure 2 The above is a flowchart of a cross-protocol lighting device synchronization control method according to an embodiment of this application.

[0036] like Figure 2 As shown, this embodiment provides a method for synchronous control of cross-protocol lighting devices, including the following steps S100 to S400.

[0037] In step S100, the communication link between the bridge-end device and the lighting device is divided into four logical stages.

[0038] In one embodiment of this application, the four logical stages include a device discovery stage, a queue scheduling stage, a wireless transmission stage, and a device execution stage.

[0039] Specifically, the device discovery phase is used to complete the identification and protocol adaptation of lighting devices by the bridge-end devices. In this phase, the bridge-end devices actively probe for active lighting devices in the network via broadcast or multicast, and parse the device type, communication protocol version, capability set, and unique identifier based on the returned response messages, thereby establishing an initial device mapping table. The latency in this phase mainly comes from protocol handshake overhead and device response delay.

[0040] During the queue scheduling phase, the bridge-end device prioritizes and aligns the generated lighting control commands according to the objective of the current synchronization task and the communication characteristics of each lighting device, and then inserts them into the local transmission queue. The latency in this phase is reflected in the waiting and preprocessing time of the lighting control commands in the scheduler.

[0041] The wireless transmission phase refers to the process by which lighting control commands are actually transmitted from the bridge-end device to the target lighting device via a wireless medium. Due to factors such as multipath effects, co-channel interference, or channel congestion, the transmission delay in this phase exhibits significant randomness and fluctuation.

[0042] During the device execution phase, after successfully receiving and parsing the lighting control command, the lighting device activates its internal execution unit to complete the corresponding lighting action. The latency of this phase includes the time consumed by command parsing, hardware response delay, and the time required to complete the execution action.

[0043] In step S200, jitter latency budgets are dynamically allocated to each logic stage.

[0044] Please see Figure 3 The diagram shows a flowchart of the jitter latency budget allocation according to an embodiment of this application.

[0045] like Figure 3 As shown, dynamically allocating jitter latency budget for each logic stage includes the following steps S210 to S230.

[0046] In step S210, the allowable jitter limit of the communication link is obtained.

[0047] The allowable jitter limit refers to the maximum total latency jitter that the entire end-to-end communication link can tolerate within the current synchronization task cycle. The allowable jitter limit is not a fixed value; it is determined by the historical actual jitter latency of each logical stage, the local clock drift of the lighting device, the type of communication protocol, and the load of the communication link.

[0048] Specifically, based on statistical analysis algorithms, the historical true jitter latency of each logical stage is calculated.

[0049] Please see Figure 4 The diagram shows a flowchart of the calculation of historical real jitter latency according to an embodiment of this application.

[0050] like Figure 4 As shown, the calculation process of the historical real jitter latency in each logical stage includes the following steps S211 to S213.

[0051] In step S211, the bridge-end timestamp is recorded. The bridge-end timestamp includes T0, T1, T2, and T3.

[0052] T0 represents the moment when the bridge-end device initiates a scan of the lighting device.

[0053] T1 represents the moment when the bridge-end device receives the scanning response from the lighting device.

[0054] T2 represents the enqueue time when the historical control instructions are written into the bridge-side scheduling queue.

[0055] T3 represents the dequeue time of the historical control command.

[0056] In step S212, a device-side timestamp is recorded. The device-side timestamp includes T4 and T5.

[0057] T4 represents the moment when the lighting device receives the historical control command.

[0058] T5 indicates the moment when the lighting device completes the execution of the historical control command.

[0059] In step S213, the historical true jitter delay for each logical stage is calculated based on the bridge-side timestamp and the device-side timestamp.

[0060] The device discovery delay is Δ_discovery = T1 - T0.

[0061] The queue scheduling delay is Δ_queue = T3-T2.

[0062] The wireless transmission delay is Δ_wireless = T4-T3.

[0063] The device execution delay is Δ_execute = T5-T4.

[0064] In step S220, the jitter budget weight of each logical stage is dynamically allocated according to the real-time jitter ratio of each logical stage.

[0065] In this step, the proportion of real-time jitter to the total jitter can be calculated based on the historical real jitter latency of each logic stage within the most recent several synchronization control cycles.

[0066] For example, if the jitter in the wireless transmission phase was 8 ms and the total link jitter was 20 ms in the previous control cycle, then the jitter percentage is 40%. This percentage reflects the contribution of each phase to the overall synchronization instability. The system dynamically adjusts the jitter budget weight for each phase accordingly, making resource allocation more aligned with actual network behavior and avoiding overly conservative allocation for low-jitter phases while neglecting budget allocation for high-jitter phases.

[0067] In step S230, the allowable jitter allowance is allocated to the four logical stages according to the jitter budget weight; wherein, the logical stage with a higher proportion of real-time jitter is allocated more jitter latency budget.

[0068] In this implementation, logic stages with a higher proportion of real-time jitter are allocated more jitter latency budget, thereby reserving sufficient fault tolerance space to prevent synchronization failure due to sudden jitter exceeding the budget.

[0069] In another embodiment of this application, dynamically allocating jitter latency budget for each logic stage includes the following steps S240 and S250.

[0070] In step S240, the current network status parameters are obtained; the current network status parameters include at least one of wireless signal strength, packet loss rate, and bridge-end queue level.

[0071] In step S250, the allowable jitter quota is allocated to the four logical stages based on the current network state parameters.

[0072] For example, when a significant decrease in wireless signal strength or an increase in packet loss rate is detected, it indicates that the quality of the wireless transmission link has deteriorated. At this time, the system automatically allocates a larger proportion of the allowable jitter to the wireless transmission stage to accommodate additional delay fluctuations caused by retransmission, channel contention, or modulation downgrading.

[0073] For example, when the water level in the bridge queue remains high, it indicates that the scheduling pressure is increasing and the instruction queuing time is prolonged. In this case, the jitter budget in the queue scheduling stage can be appropriately increased.

[0074] In step S300, a corresponding lighting control command is generated based on the lighting scene triggered by the user.

[0075] In this embodiment, the lighting control command is used to guide the lighting device to synchronously execute the lighting action defined by the transition curve at a target time point.

[0076] Please see Figure 5 The image shown is a schematic diagram of a lighting control command message according to an embodiment of this application.

[0077] like Figure 5 As shown, the fields in the lighting control segment include the target execution time point, the lighting effect transition curve, and the jitter delay budget. The meanings of each field are as follows:

[0078] The target execution time point represents the precise moment when the lighting action should be triggered on the global timeline, typically based on the unified time maintained by the bridge-end equipment. All controlled lighting devices perform local scheduling based on this timestamp and their own communication link latency to achieve millisecond-level synchronization across devices.

[0079] The light effect transition curve is used to describe the dynamic trajectory of the light state changing over time. The types of light effect transition curves include linear curves, quadratic Bézier curves, and S-shaped curves.

[0080] The jitter latency budget includes the jitter latency budget values ​​allocated to the four logical stages in step S200. The specific generation mechanism of this field has been detailed in step S200 above and will not be repeated here.

[0081] The fields in the lighting control segment also include version number, batch number, node mask, and degradation policy. The meanings of each field are as follows:

[0082] The version number is used to identify the protocol version followed by the lighting control commands, ensuring forward / backward compatibility.

[0083] The batch number is used to group multiple associated instructions into the same batch, which facilitates atomic scheduling, status rollback or fault tracing by the bridge-end device.

[0084] The node mask, in the form of a bitmap or group address, specifies the set of target lighting devices to which the lighting control command applies, supports unicast, multicast, or broadcast semantics, and improves command distribution efficiency.

[0085] The degradation strategy defines the alternative behaviors to be taken when a device cannot perform as originally planned due to communication failure, latency exceeding limits, or hardware malfunction. This strategy enhances the availability and security of the system in non-ideal environments.

[0086] In one embodiment of this application, generating a corresponding lighting control command based on a user-triggered lighting scene includes the following steps S301 to S305.

[0087] In step S301, the user's lighting requirements information is obtained.

[0088] The lighting requirement information includes at least one of the following: user manual settings, preset lighting scenes, environmental audio signals, video content, or sensor-triggered events.

[0089] In step S302, based on the lighting demand information and combined with the hardware capability parameters of each lighting device, device capability mapping is performed to generate target state values ​​that each lighting device can execute.

[0090] The target state value includes at least one of the following: target brightness, color temperature, color coordinates, on / off state, or dynamic lighting effect mode.

[0091] In step S303, the anchor clock signal periodically broadcast by the bridge-end device is used as a unified time reference to time-align the execution actions of all lighting devices.

[0092] In step S304, a suitable light effect transition curve is selected based on the target state value and the light effect performance expected by the user.

[0093] In step S305, based on the anchor clock signal and the light effect transition curve, the target execution time point of the lighting control command is determined, and the target execution time point is bound to the anchor clock signal to form a complete lighting control command containing a time synchronization context.

[0094] In step S400, based on a reliable multicast protocol, the lighting control command is sent to the lighting device, and the lighting device synchronously executes the lighting action defined by the light effect transition curve within the jitter delay budget and according to the target execution time point.

[0095] Please see Figure 6The above is a flowchart illustrating the issuance of lighting control commands based on a reliable multicast protocol according to an embodiment of this application.

[0096] like Figure 6 As shown, sending the lighting control command to the lighting device based on a reliable multicast protocol includes the following steps S401 to S408.

[0097] In step S401, the lighting control command is processed into multiple command fragments.

[0098] Specifically, the bridge-end device will logically divide the complete lighting control command into N ordered command fragments (Fragment_0, Fragment_1, ..., Fragment_{N-1}) according to a preset block size. Each command fragment carries a fragment sequence number and a total fragment count identifier so that the receiving end can reassemble them.

[0099] In step S402, forward error correction coding is performed on each instruction fragment to generate a coded group containing redundancy check information.

[0100] To avoid the problem of some lighting devices failing to receive instructions completely due to packet loss in the wireless channel, which could lead to asynchronous execution between lamps, this application introduces a forward error correction coding mechanism.

[0101] In one embodiment of this application, Reed-Solomon (RS) codes or XOR-based FEC can be used to achieve efficient fault tolerance. This mechanism can recover the original complete instruction from only the received partial fragments without relying on retransmission feedback from the receiver.

[0102] In step S403, based on the multi-round multicast mechanism, the encoded packets are sent concurrently to all lighting devices via the air interface.

[0103] The multi-round multicast mechanism increases the probability of devices successfully receiving sufficient fragments in weak signal or high interference environments by repeatedly broadcasting the same set of coded packets in multiple consecutive time slots (e.g., 2-3 rounds), while avoiding synchronization interruptions due to single transmission failures. Microsecond-level intervals can be introduced between rounds to adapt to the channel access rules of the underlying protocol, balancing efficiency and compliance.

[0104] In step S404, the reception confirmation signals fed back by each lighting device are obtained, and the reception confirmation signals are aggregated to obtain aggregated confirmation information.

[0105] To avoid channel congestion and bridge-end processing overload caused by the traditional device-to-device acknowledgment (ACK) mechanism, this application can adopt a delayed random convergence acknowledgment strategy, the specific process of which includes the following Step 1 to Step 5.

[0106] In Step 1, the lighting equipment does not immediately send an ACK separately.

[0107] After successfully decoding and verifying the complete lighting control command, each lighting device does not immediately send an independent acknowledgment message back to the bridge end, but instead enters a waiting state to avoid instantaneous concurrent ACK conflicts.

[0108] In Step 2, the lighting equipment backs off within a preset random delay window.

[0109] Each device randomly selects a backoff delay value from a uniformly distributed interval of [1 ms, 10 ms] and remains silent within this window. This randomization mechanism effectively disperses the ACK transmission times, reducing the probability of multiple devices simultaneously competing for the channel.

[0110] In Step 3, the lighting equipment sends a lightweight acknowledgment signal to the bridge end lighting.

[0111] After the backoff is completed, the device encapsulates its acknowledgment information into a compact acknowledgment message and sends it to the bridge or a designated aggregation node via the uplink.

[0112] In Step 4, the aggregation node merges the multi-source confirmation signals.

[0113] In one embodiment, the bridge-end device itself acts as the aggregation node; in another embodiment, a relay device with strong processing capabilities in the network can be designated as the aggregation node. After receiving acknowledgment messages from multiple lighting devices, the aggregation node performs the following operations: deduplication and verification; count the number of successfully decoded devices and the list of failed devices; extract key metadata; and generate structured aggregated acknowledgment information.

[0114] In Step 5, the bridge-end device only needs to process one aggregated confirmation message.

[0115] In this implementation, by adopting a collaborative design of multi-round multicast and convergence confirmation mechanism, it can effectively suppress uplink channel load and bridge-end computing pressure while ensuring highly reliable command delivery. It is particularly suitable for large-scale synchronous control scenarios involving dozens to hundreds of heterogeneous lighting devices, and has scalability, real-time performance and engineering practicality.

[0116] In step S405, it is determined whether the current multicast cycle has successfully covered all lighting devices based on the aggregation confirmation information.

[0117] Specifically, the bridge-end device parses the device status list in the aggregated confirmation information and compares it with the preset target device set. If all target devices return valid confirmations, the current multicast cycle is determined to be a successful coverage. Otherwise, if one or more devices fail to return confirmations, return a failure status, or the confirmation information times out, the coverage is determined to be incomplete.

[0118] In step S406, when there is an unconfirmed lighting device, a multi-round multicast retransmission mechanism is initiated to retransmit the corresponding coded packets in one or more subsequent multicast cycles.

[0119] In this implementation, by introducing a multi-round multicast retransmission mechanism, the system can significantly improve its fault tolerance and service continuity in complex wireless environments while ensuring high synchronization accuracy of large-scale heterogeneous lighting equipment. This effectively solves the technical defects of traditional broadcast / multicast schemes, which are characterized by "loss of data once lost and irrecoverable".

[0120] In step S407, if there are still unacknowledged lighting devices after the preset maximum number of retransmissions, a point-to-point unicast retransmission operation is triggered for the unacknowledged lighting devices.

[0121] In this implementation, by introducing a unicast retransmission mechanism, it is possible to maintain efficient multicast backbone transmission while taking into account the reliability requirements of extreme edge devices, thus achieving a hybrid reliable transmission architecture.

[0122] In step S408, during multicast and retransmission, packet throttling control is dynamically executed based on the load status of the air interface.

[0123] Specifically, the load status of the air interface includes channel occupancy, recent collision / backoff count, bridge-side transmit queue depth, and receiver ACK / NACK feedback density.

[0124] Based on the load status of the air interface, the following throttling strategy can be adopted:

[0125] (1) When the air interface load is detected to exceed the first threshold (e.g., channel utilization > 70%), the interval between multicast rounds is automatically extended to reduce the instantaneous transmission density;

[0126] (2) When the load further increases to the second threshold (e.g., queue level > high water level), the transmission of non-critical instructions is suspended, and priority is given to ensuring the retransmission and resending of the current synchronization task;

[0127] (3) During the throttling period, the system can cache some non-emergency control commands to the local scheduler and resume sending them according to priority after the load falls back to the safe range.

[0128] In this implementation, the reliable multicast mechanism is deeply integrated with key technologies such as forward error correction coding and acknowledgment aggregation, which achieves a significant reduction in air interface resource consumption while ensuring high reliability, thus achieving a technical effect of being both stable and saving traffic.

[0129] It should be noted that this application supports a multi-protocol optimized distribution mechanism, which is compatible with and can efficiently schedule various mainstream low-power or high-bandwidth wireless communication protocols, including but not limited to Zigbee, Thread, and Wi-Fi. Through protocol-aware instruction encapsulation, link adaptive scheduling, and unified synchronization semantic mapping, it achieves collaborative, reliable, and low-jitter lighting control instruction distribution in a heterogeneous protocol coexistence environment.

[0130] In one embodiment of this application, before issuing the lighting control command to the lighting device, the method further includes: periodically broadcasting an anchor clock signal to each lighting device; the anchor clock signal is used to establish and maintain a unified time reference shared by all lighting devices.

[0131] Bridge-end devices maintain a highly stable, unified time across the entire network internally, based on either Precision Time Protocol or Fast Internet Time Protocol.

[0132] Specifically, the bridge-end equipment maintains a unified time mapping formula for each lighting device:

[0133] device_global_time = device_local_time + offset - drift_compensation;

[0134] In the formula, device_global_time represents the unified time across the entire network; device_local_time is the reading of the device's local timer; offset is the initial clock offset, estimated by comparing the round-trip time of anchor messages or one-way timestamps; drift_compensation is a linear or non-linear compensation term calculated based on historical drift rates, used to offset the cumulative effect of the crystal frequency deviation of microcontrollers (MCUs) from different manufacturers over time.

[0135] As the master time control node for the entire network, the bridge-end device periodically publishes synchronization messages for the time anchor. Upon receiving the message, all lighting devices use the timestamp it carries as a reference to correct their local clock offset and align with the global timeline. Through this mechanism, even if the devices use different communication protocols, are equipped with microcontrollers (MCUs) from different manufacturers, and have inherent clock drift, they can still achieve millisecond-level consistent lighting actions in the physical world.

[0136] Please see Figure 7The diagram shows the timing of the issuance and execution of lighting control commands according to an embodiment of this application.

[0137] In one embodiment of this application, the cross-protocol lighting device synchronization control method further includes the following steps S500 to S700.

[0138] In step S500, the current network status parameters are obtained; the current network status parameters include at least one of wireless signal strength, packet loss rate, and bridge-end queue level.

[0139] In step S600, feedback information reported by each lighting device to the bridge-end device after synchronously completing the lighting action is obtained; the feedback information includes the local clock drift and execution error of the lighting device.

[0140] The execution error is the deviation between the actual execution time of the lighting device and the target execution time.

[0141] In step S700, based on the current network status parameters and the feedback information, the target execution time point and the jitter delay budget in the lighting control command are dynamically adjusted.

[0142] In one embodiment of this application, the cross-protocol lighting device synchronization control method further includes step S800.

[0143] In step S800, when the execution error exceeds the jitter delay budget of the corresponding logic stage, the system automatically switches to smooth degradation mode.

[0144] The smooth degradation mode includes at least one of the following operations;

[0145] (1) Extend the light effect transition time of the lighting equipment;

[0146] (2) Reduce the slope of the light effect transition curve;

[0147] (3) Replace the light effect transition curve with a degradation transition curve; the degradation transition curve includes a slow-in slow-out function, a low-order Bezier curve or an exponential decay function.

[0148] It should be noted that the smooth degradation mode is a temporary and recoverable fault-tolerant mechanism. Once the timing deviation of the subsequently received new lighting control commands falls back within the allocated jitter delay budget, i.e., the communication link returns to stability, clock alignment is effective, and scheduling is normal, the lighting equipment will automatically exit the smooth degradation mode and seamlessly switch back to the complete luminous efficacy transition curve defined by the original command, continuing to perform high-fidelity synchronization actions.

[0149] In this implementation, by introducing a smooth degradation mode, continuous and gentle changes in optical effect can be achieved, effectively avoiding optical effect jumps, flickering or discontinuity caused by sudden changes in link delay, thereby significantly improving the stability of cross-protocol synchronization.

[0150] Please see Figure 8 The flowchart shown is a cross-protocol lighting device synchronization control method according to another embodiment of this application.

[0151] like Figure 8 As shown, the bridge-end device generates time anchors based on Precision Time Protocol or Fast Internet Time Protocol, providing a unified and accurate time reference for all lighting devices in the network.

[0152] The jitter budgeter is used to allocate corresponding latency jitter budgets for each logic stage. By properly allocating the latency jitter budget, the system can optimize overall synchronization performance and ensure high-precision collaborative control even when there are certain latency fluctuations in the network.

[0153] During the scheduling and multicast phase, the bridge-end equipment schedules instructions according to the specific requirements of the synchronization task and uses multicast technology to efficiently send lighting control instructions to multiple target nodes.

[0154] During the confirmation and convergence phase, feedback information from each target node is collected to verify that all devices have correctly received the instructions and are in a ready state to execute synchronization actions.

[0155] Taking node A, representing a certain lighting device, as an example, it calibrates its local execution timing based on the aforementioned unified time reference, thereby achieving precise synchronization with other nodes. If the preset synchronization accuracy requirements cannot be met due to channel interference, processing delays, or other factors, the node can automatically switch to degradation mode, ensuring the stable operation of basic lighting functions while sacrificing some performance indicators.

[0156] It should be noted that the scope of protection of the cross-protocol lighting equipment synchronization control method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0157] Please see Figure 9 The diagram shown is a structural schematic of a cross-protocol lighting device synchronization control system according to another embodiment of this application.

[0158] like Figure 9 As shown, this embodiment provides a cross-protocol lighting device synchronization control system, including:

[0159] Bridge-end equipment, used to send anchor clock signals and lighting control segments to lighting equipment;

[0160] Multiple lighting devices, each of which is communicatively connected to the bridge-end device, are configured to receive lighting control segments sent by the bridge-end device, synchronously execute lighting actions defined by transition curve parameters in the lighting control segments, and report feedback information to the bridge-end device after synchronously executing the lighting actions; the feedback information includes the local clock drift and execution error of the lighting device.

[0161] Please see Figure 10 The image shown is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0162] like Figure 10 As shown, this application provides an electronic device, including:

[0163] The memory is used to store computer programs;

[0164] A processor, the processor being configured to execute a computer program stored in the memory, so as to cause the electronic device to perform the method described in any of the preceding descriptions.

[0165] Preferably, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0166] This embodiment also includes one or more of the following: a multimedia component, an input / output (I / O) interface, and a communication component.

[0167] The multimedia component may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in memory or transmitted via a communication component. The audio component also includes at least one speaker for outputting audio signals. The I / O interface provides an interface between the processor and other interface modules, such as a keyboard, mouse, buttons, etc. These buttons may be virtual or physical buttons. The communication component is used for wired or wireless communication between the timer and other devices. Wireless communication includes, for example, Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination of these. Therefore, the corresponding communication component may include a Wi-Fi module, a Bluetooth module, or an NFC module.

[0168] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0169] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0170] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the methods described in any of the above embodiments. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0172] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

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

Claims

1. A method for synchronous control of lighting devices across protocols, characterized in that, The method is applied to bridge-end equipment, which is connected to multiple lighting devices via different communication protocols; the method includes: The communication link between the bridge-end device and the lighting device is divided into four logical phases; the four logical phases include the device discovery phase, the queue scheduling phase, the wireless transmission phase, and the device execution phase. Dynamically allocate jitter latency budgets for each logical stage; Based on the lighting scene triggered by the user, a corresponding lighting control command is generated; the fields in the lighting control command include the target execution time point, the light effect transition curve, and the jitter delay budget; Based on a reliable multicast protocol, the lighting control command is sent to the lighting device, and the lighting device synchronously executes the lighting action defined by the light effect transition curve according to the target execution time point within the jitter delay budget. Dynamically allocating jitter latency budgets for each logic stage includes: Obtain the allowable jitter limit of the communication link; the allowable jitter limit is jointly determined by the historical actual jitter delay of each logic stage, the local clock drift of the lighting device, the type of communication protocol, and the load of the communication link; The jitter budget weight of each logical stage is dynamically allocated according to the real-time jitter percentage of each logical stage. Based on the jitter budget weight, the allowed jitter allowance is allocated to the four logical stages; wherein, the logical stage with a higher proportion of real-time jitter is allocated more jitter latency budget.

2. The method according to claim 1, characterized in that, Sending the lighting control command to the lighting device based on a reliable multicast protocol includes: The lighting control command is processed into multiple command fragments. Forward error correction coding is performed on each instruction fragment to generate a coded group containing redundancy check information; Based on a multi-round multicast mechanism, the coded packets are sent concurrently to all lighting devices via the air interface; Acquire the reception confirmation signals fed back by each lighting device, and perform aggregation processing on the reception confirmation signals to obtain aggregated confirmation information; Based on the aggregated confirmation information, determine whether the current multicast cycle has successfully covered all lighting devices; When an unconfirmed lighting device is present, a multi-round multicast retransmission mechanism is initiated to retransmit the corresponding coded packets in one or more subsequent multicast cycles; If, after the preset maximum number of retransmissions, there are still lighting devices that have not been confirmed, a point-to-point unicast retransmission operation will be triggered for the unconfirmed lighting devices. During multicast and retransmission, packet throttling control is dynamically executed based on the load status of the air interface.

3. The method according to claim 1, characterized in that, Before issuing the lighting control command to the lighting device, the method further includes: periodically broadcasting an anchor clock signal to each lighting device; the anchor clock signal is used to establish and maintain a unified time reference shared by all lighting devices.

4. The method according to claim 1, characterized in that, Based on statistical analysis algorithms, the historical true jitter latency of each logical stage is calculated respectively; The calculation process includes: Record the bridge-side timestamp; the bridge-side timestamp includes: T0, representing the time when the bridge-side device initiates scanning of the lighting device; T1, representing the time when the bridge-side device receives the scanning response from the lighting device; T2, representing the enqueue time when the historical control command is written into the bridge-side scheduling queue; T3, representing the dequeue time of the historical control command. Record device-side timestamps; the device-side timestamps include: T4, representing the time when the lighting device receives the historical control command; T5, representing the time when the lighting device completes the execution of the historical control command; Based on the bridge-side timestamp and the device-side timestamp, the historical real jitter latency for each logical stage is calculated respectively; wherein the device discovery latency is Δ_discovery = T1-T0; the queue scheduling latency is Δ_queue = T3-T2; the wireless transmission latency is Δ_wireless = T4-T3; and the device execution latency is Δ_execute = T5-T4.

5. The method according to claim 1, characterized in that, Also includes: Obtain current network status parameters; the current network status parameters include at least one of wireless signal strength, packet loss rate, and bridge-end queue level. The system acquires feedback information reported by each lighting device to the bridge-end device after synchronously completing the lighting action; the feedback information includes the local clock drift and execution error of the lighting device; the execution error is the deviation between the actual execution time of the lighting device and the target execution time. Based on the current network status parameters and the feedback information, the target execution time point and the jitter delay budget in the lighting control command are dynamically adjusted.

6. The method according to claim 5, characterized in that, Also includes: When the execution error exceeds the jitter latency budget of the corresponding logic stage, it automatically switches to the smooth degradation mode; the smooth degradation mode includes at least one of the following operations; Extend the light effect transition time of the lighting device; Reduce the slope of the light effect transition curve; Replace the luminous efficacy transition curve with a degradation transition curve; the degradation transition curve includes a slow-in / slow-out function, a low-order Bézier curve, or an exponential decay function.

7. A cross-protocol lighting equipment synchronization control system, characterized in that, include: The bridge-end device is configured to perform the method as described in any one of claims 1 to 6; Multiple lighting devices, each communicating with the bridge-end device via different communication protocols, are configured to receive lighting control commands sent by the bridge-end device and synchronously execute lighting actions based on the lighting control commands.

8. An electronic device, characterized in that, include: The memory is used to store computer programs; A processor for executing a computer program stored in the memory to cause the electronic device to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images