A method, system, and computer-readable storage medium for intelligent retransmission based on Redis caching.

Abstract

This invention discloses an intelligent retransmission method and system based on Redis caching, as well as a computer-readable storage medium. The method includes: calculating the execution time of a scenario, wherein the scenario includes one or more device execution queues, each scenario is contained in a project, and each project contains one or more scenarios; when executing a scenario, the device serial number and scenario calculation time within the scenario are stored in a Redis cache, the scenario project ID is locked, a detection thread is started to sleep on the scenario execution time, and after the detection thread finishes sleeping, the cache is queried sequentially according to the scenario devices. If the cache still contains the information, it indicates that the device execution has failed, and the device is added to the second-round instruction sending list; a second-round instruction is issued according to the devices in the list, and the project ID of the current scenario is unlocked simultaneously. This invention can reduce server load and improve instruction execution efficiency and device control success rate.

Description

Technical Field

[0001] This invention relates to the field of server caching technology, and more specifically, to a method, system, and computer-readable storage medium for intelligent retransmission based on Redis caching. Background Technology

[0002] With the rapid development of computer and chip technologies, smart homes have also seen rapid growth in China. Servers are a crucial component in realizing smart homes. Servers are responsible for communicating with smart devices, synchronizing with them, or issuing commands to achieve the goals of smart home functionality. The server's programming and algorithms determine the overall system's functionality and efficiency.

[0003] Existing smart home servers typically execute commands only once, which is simple and straightforward, but it also has certain problems. When encountering network fluctuations, poor device communication, or a large number of devices, commands may fail to execute correctly—a phenomenon commonly known as "packet loss." If only a few devices fail to execute, the scene control must be re-executed on all devices, which is inefficient and increases the server's workload. These unpredictable problems can lead to a poor user experience.

[0004] The existing server command issuance method has a high server load, low execution efficiency, and poor user experience. Therefore, there is an urgent need for an intelligent resending method based on Redis caching. Summary of the Invention

[0005] In view of the above problems, the purpose of this invention is to provide a method, system and computer-readable storage medium for intelligent retransmission based on Redis caching, which can reduce the server load and improve the control success rate of remote devices.

[0006] The first aspect of this invention provides an intelligent retransmission method based on Redis caching, comprising the following steps:

[0007] Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes;

[0008] When the scenario is executed, the device serial number and scenario calculation time in the scenario are stored in the Redis cache, the scenario project ID is locked, the detection thread is started to sleep the scenario execution time, and after the detection thread finishes sleeping, it will query the cache according to the scenario device in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list.

[0009] The second round of instructions is issued to the devices in the list, and the ID lock of the project in the current scene is released at the same time.

[0010] In this solution, the specific steps for calculating the execution time of the scenario are as follows:

[0011] The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency.

[0012] Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list.

[0013] In this solution, the iterative calculation of the equipment list is performed as follows:

[0014] If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is:

[0015] New scene execution time = current delay time + total number of devices in the group × execution time per device

[0016] If the scene execution time is greater than the group delay time, it means that when the delay time expires, there are still devices in the group that are executing. These devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is:

[0017] The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

[0018] In this solution, once the project ID of a scene is locked, if there are still scene execution instructions for that project, the instructions will be temporarily stored to prevent multiple scenes from executing simultaneously and affecting each other.

[0019] In this solution, the current thread is released after the sleep scenario execution time is started to avoid user lag.

[0020] In this solution, when the server receives a response packet from the device, it will query the cache and delete the cache.

[0021] In this solution, after issuing the second round of instructions based on the devices in the list and simultaneously unlocking the project ID of the current scenario, if there are other temporarily stored scenarios for the project, the new scenario will be executed. If a third round of instructions is needed, the response packet can be checked repeatedly. If not, the data in the Redis cache will be cleared and the execution of this scenario will end.

[0022] A second aspect of the present invention provides an intelligent retransmission system based on Redis caching, comprising a memory and a processor. The memory includes an intelligent retransmission method program based on Redis caching. When the processor executes the intelligent retransmission method program based on Redis caching, it performs the following steps:

[0023] Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes;

[0024] When executing a scenario, the device serial number and scenario calculation time within the scenario are stored in the Redis cache, the scenario project ID is locked, and the detection thread is started to sleep the scenario execution time. After the detection thread finishes sleeping, it will query the cache according to the scenario devices in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list.

[0025] The second round of instructions is issued to the devices in the list, and the ID lock of the project in the current scene is released at the same time.

[0026] In this solution, the specific steps for calculating the execution time of the scenario are as follows:

[0027] The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency.

[0028] Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list.

[0029] A third aspect of the present invention provides a computer-readable storage medium including a Redis-based intelligent retransmission method program, wherein when the Redis-based intelligent retransmission method program is executed by a processor, it implements the steps of the Redis-based intelligent retransmission method.

[0030] This invention discloses an intelligent retransmission method and system based on Redis caching, as well as a computer-readable storage medium. By intelligently calculating the scenario execution time, the device serial number and scenario execution time are stored in the Redis cache. The device response packet status is detected to obtain the corresponding device list. Based on the response packet status, the execution command is resent to the corresponding device, which reduces the server load and improves the execution efficiency of the command and the success rate of device control. Attached Figure Description

[0031] Figure 1 A flowchart of a smart retransmission method based on Redis caching according to this application is shown.

[0032] Figure 2 The flowchart of the execution time of the computation scenario in this application is shown.

[0033] Figure 3 A block diagram of a smart retransmission method system based on Redis caching according to this application is shown. Detailed Implementation

[0034] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0035] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0036] Figure 1 A flowchart of a smart retransmission method based on Redis caching according to this application is shown.

[0037] like Figure 1 As shown, this application discloses an intelligent retransmission method based on Redis caching, including the following steps:

[0038] S102, Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes;

[0039] S104, when executing a scenario, the device serial number and scenario calculation time in the scenario are stored in the Redis cache, the scenario project ID is locked, the detection thread is started to sleep the scenario execution time, and after the detection thread finishes sleeping, it will query the cache according to the scenario device in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list.

[0040] S106, issue a second round of instructions based on the devices in the list, and simultaneously unlock the project ID of the current scene.

[0041] It should be noted that the method of this invention is applicable to systems built on servers and remote devices, such as smart home systems. In specific embodiments, because the gateway needs time to send signals, the maximum delay time of the scene cannot be directly regarded as the execution time of the scene. First, the scene execution time is calculated, then the device serial number in the scene and the scene calculation time are stored in the Redis cache, the scene project ID is locked, and the detection thread is started to sleep the scene execution time. After the detection thread finishes sleeping, it will query the cache sequentially according to the scene devices. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list. The second round of instructions is issued according to the devices in the list, and at the same time, the lock on the project ID of the current scene is released.

[0042] Figure 2 The flowchart of the computation scenario execution time is shown.

[0043] According to an embodiment of the present invention, the specific steps for calculating the execution time of the scenario are as follows:

[0044] S202, group the devices in the execution scenario according to their respective latency times, and arrange them from low to high latency;

[0045] S204, Set the initial value of the scene execution time and the execution time of each device, and perform loop calculations on the device list.

[0046] It should be noted that in this invention, the devices within the execution scenario are first grouped according to their respective latency times and arranged from lowest to highest latency. For example, if there are 5 devices in the execution scenario, with 2 devices having a latency of 3000 milliseconds, 2 devices having a latency of 4000 milliseconds, and 1 device having a latency of 5000 milliseconds, then all devices are arranged in ascending order of latency to form a device list. In a specific embodiment, the initial value of the scenario execution time is 0, the execution time of each device is set to 130 milliseconds, and then the device list is iteratively calculated.

[0047] According to an embodiment of the present invention, the cyclic calculation of the device list specifically involves:

[0048] If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is:

[0049] New scene execution time = current delay time + total number of devices in the group × execution time per device

[0050] If the scene execution time is greater than the group's delay time, it means that when the delay time expires, there are still devices in the group executing, and these devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is:

[0051] The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

[0052] It should be noted that, for example, in a scenario with 10 devices, each requiring 200ms to execute, the first 3 devices execute immediately, devices numbered 4 to 9 execute with a 1000ms delay, and the last device executes with a 2000ms delay. That is, the scenario is divided into three groups of delay methods. Calculating the first group, the current delay is 0ms, and the old execution time is 0ms, so using the first calculation method, the new scenario execution time is 0ms + 3 * 200ms = 600ms. Calculating the second group, the current delay is 1000ms, and the old execution time is 600ms. Using the first algorithm, the new scenario execution time is 1000ms + 6 * 200ms = 2200ms. Calculating the third group, the old execution time of 2200ms is greater than the current delay, so using the second calculation method, the new scenario execution time is 2200ms + 1 * 200ms = 2400ms; therefore, the entire scenario will take 2400ms to complete.

[0053] According to an embodiment of the present invention, once the project ID of a scene is locked, if there are still scene execution instructions for that project, the instructions are temporarily stored to prevent multiple scenes from executing simultaneously and affecting each other.

[0054] It should be noted that in a specific embodiment, each project has several scenarios. For example, in a smart home system, lighting, air conditioning, and curtains correspond to different scenarios of the device. Once the project ID is locked, if there are still execution instructions for the project's scenarios, the instructions will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other. For example, if the execution scenarios include the room's lighting switch, and there are still execution instructions to turn on the air conditioner, the air conditioner turn-on instruction will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other.

[0055] According to an embodiment of the present invention, the current thread is released after the execution time of the sleep scenario of the detection thread is started to avoid user lag.

[0056] It should be noted that after calculating the scene execution time, the thread currently connected to the user is released to prevent the user from being stuck, and a new thread is started to delay the scene execution time before performing packet return statistics on the devices in the scene.

[0057] According to an embodiment of the present invention, when the server receives a response packet from the device, it will query the cache and delete the cache.

[0058] It should be noted that after the device in the scenario executes the instructions issued by the server, the device will return a data packet, and the server will delete the corresponding cache based on the data packet returned by the device.

[0059] According to an embodiment of the present invention, after issuing the second round of instructions based on the devices in the list and simultaneously unlocking the project ID of the current scenario, if there are other temporarily stored scenarios for the project, the new scenario will be executed; if a third round of instructions is needed, the return packet detection can be repeated; if not, the data in the Redis cache will be cleared and the execution of this scenario will end.

[0060] It should be noted that in this embodiment of the invention, the server issues a second round of instructions based on the devices in the list, and simultaneously unlocks the project ID of the current scenario. At this time, if there are other temporarily stored scenarios for this project, the new scenario is executed. As mentioned above, there is also an instruction to turn on the air conditioner, so the air conditioner is turned on. If a third round of instructions is needed, the return packet detection can be repeated. In a specific embodiment, whether to start issuing the third round of instructions can be determined based on the device return packet detection in the second round of execution. If all devices in the device class table return packets, there is no need to start issuing the third round of instructions, and the data in the Redis cache will be cleared, ending the execution of this scenario. If there are devices that do not return packets, then the third round of instructions is issued.

[0061] Figure 3 A block diagram of an intelligent retransmission system based on Redis caching is shown.

[0062] A second aspect of the present invention provides an intelligent retransmission system based on Redis caching, comprising a memory 31 and a processor 32. The memory includes an intelligent retransmission method program based on Redis caching. When the processor executes the intelligent retransmission method program based on Redis caching, it performs the following steps:

[0063] Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes;

[0064] When executing a scenario, the device serial number and scenario calculation time within the scenario are stored in the Redis cache, the scenario project ID is locked, and the detection thread is started to sleep the scenario execution time. After the detection thread finishes sleeping, it will query the cache according to the scenario devices in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list.

[0065] The second round of instructions is issued to the devices on the list, and the project ID of the current scene is unlocked at the same time.

[0066] It should be noted that the method of this invention is applicable to systems built on servers and remote devices, such as smart home systems. In specific embodiments, because the gateway needs time to send signals, the maximum delay time of the scene cannot be directly regarded as the execution time of the scene. First, the scene execution time is calculated, then the device serial number in the scene and the scene calculation time are stored in the Redis cache, the scene project ID is locked, and the detection thread is started to sleep the scene execution time. After the detection thread finishes sleeping, it will query the cache sequentially according to the scene devices. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list. The second round of instructions is issued according to the devices in the list, and at the same time, the lock on the project ID of the current scene is released.

[0067] According to an embodiment of the present invention, the specific steps for calculating the execution time of the scenario are as follows:

[0068] The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency.

[0069] Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list.

[0070] It should be noted that in this invention, the devices within the execution scenario are first grouped according to their respective latency times and arranged from lowest to highest latency. For example, if there are 5 devices in the execution scenario, with 2 devices having a latency of 3000 milliseconds, 2 devices having a latency of 4000 milliseconds, and 1 device having a latency of 5000 milliseconds, then all devices are arranged in ascending order of latency to form a device list. In a specific embodiment, the initial value of the scenario execution time is 0, the execution time of each device is set to 130 milliseconds, and then the device list is iteratively calculated.

[0071] According to an embodiment of the present invention, the cyclic calculation of the device list specifically involves:

[0072] If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is:

[0073] New scene execution time = current delay time + total number of devices in the group × execution time per device

[0074] If the scene execution time is greater than the group's delay time, it means that when the delay time expires, there are still devices in the group executing, and these devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is:

[0075] The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

[0076] It should be noted that, for example, in a scenario with 10 devices, each requiring 200ms to execute, the first 3 devices execute immediately, devices numbered 4 to 9 execute with a 1000ms delay, and the last device executes with a 2000ms delay. That is, the scenario is divided into three groups of delay methods. Calculating the first group, the current delay is 0ms, and the old execution time is 0ms, so using the first calculation method, the new scenario execution time is 0ms + 3 * 200ms = 600ms. Calculating the second group, the current delay is 1000ms, and the old execution time is 600ms. Using the first algorithm, the new scenario execution time is 1000ms + 6 * 200ms = 2200ms. Calculating the third group, the old execution time of 2200ms is greater than the current delay, so using the second calculation method, the new scenario execution time is 2200ms + 1 * 200ms = 2400ms; therefore, the entire scenario will take 2400ms to complete.

[0077] According to an embodiment of the present invention, once the project ID of a scene is locked, if there are still scene execution instructions for that project, the instructions are temporarily stored to prevent multiple scenes from executing simultaneously and affecting each other.

[0078] It should be noted that in a specific embodiment, each project has several scenarios. For example, in a smart home system, lighting, air conditioning, and curtains correspond to different scenarios of the device. Once the project ID is locked, if there are still execution instructions for the project's scenarios, the instructions will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other. For example, if the execution scenarios include the room's lighting switch, and there are still execution instructions to turn on the air conditioner, the air conditioner turn-on instruction will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other.

[0079] According to an embodiment of the present invention, the current thread is released after the execution time of the sleep scenario of the detection thread is started to avoid user lag.

[0080] It should be noted that after calculating the scene execution time, the thread currently connected to the user is released to prevent the user from being stuck, and a new thread is started to delay the scene execution time before performing packet return statistics on the devices in the scene.

[0081] According to an embodiment of the present invention, when the server receives a response packet from the device, it will query the cache and delete the cache.

[0082] It should be noted that after the device in the scenario executes the instructions issued by the server, the device will return a data packet, and the server will delete the corresponding cache based on the data packet returned by the device.

[0083] According to an embodiment of the present invention, after issuing the second round of instructions based on the devices in the list and simultaneously unlocking the project ID of the current scenario, if there are other temporarily stored scenarios for the project, the new scenario will be executed; if a third round of instructions is needed, the return packet detection can be repeated; if not, the data in the Redis cache will be cleared and the execution of this scenario will end.

[0084] It should be noted that in this embodiment of the invention, the server issues a second round of instructions based on the devices in the list, and simultaneously unlocks the project ID of the current scenario. At this time, if there are other temporarily stored scenarios for this project, the new scenario is executed. As mentioned above, there is also an instruction to turn on the air conditioner, so the air conditioner will continue to be executed. If a third round of instructions is needed, the return packet detection can be repeated. In a specific embodiment, whether to start issuing the third round of instructions can be determined based on the device return packet detection in the second round of execution. If all devices in the device class table return packets, there is no need to start issuing the third round of instructions, and the data in the Redis cache will be cleared, ending the execution of this scenario. If there are devices that do not return packets, then the third round of instructions will be issued.

[0085] A third aspect of the present invention provides a computer-readable storage medium comprising a Redis-based intelligent retransmission method program. When executed by a processor, the Redis-based intelligent retransmission method program implements the steps of the Redis-based intelligent retransmission method, as detailed below:

[0086] Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes;

[0087] When executing a scenario, the device serial number and scenario calculation time within the scenario are stored in the Redis cache, the scenario project ID is locked, and the detection thread is started to sleep the scenario execution time. After the detection thread finishes sleeping, it will query the cache according to the scenario devices in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list.

[0088] The second round of instructions is issued to the devices on the list, and the project ID of the current scene is unlocked at the same time.

[0089] It should be noted that the method of this invention is applicable to systems built on servers and remote devices, such as smart home systems. In specific embodiments, because the gateway needs time to send signals, the maximum delay time of the scene cannot be directly regarded as the execution time of the scene. First, the scene execution time is calculated, then the device serial number in the scene and the scene calculation time are stored in the Redis cache, the scene project ID is locked, and the detection thread is started to sleep the scene execution time. After the detection thread finishes sleeping, it will query the cache sequentially according to the scene devices. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list. The second round of instructions is issued according to the devices in the list, and at the same time, the lock on the project ID of the current scene is released.

[0090] According to an embodiment of the present invention, the specific steps for calculating the execution time of the scenario are as follows:

[0091] The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency.

[0092] Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list.

[0093] It should be noted that in this invention, the devices within the execution scenario are first grouped according to their respective latency times and arranged from lowest to highest latency. For example, if there are 5 devices in the execution scenario, with 2 devices having a latency of 3000 milliseconds, 2 devices having a latency of 4000 milliseconds, and 1 device having a latency of 5000 milliseconds, then all devices are arranged in ascending order of latency to form a device list. In a specific embodiment, the initial value of the scenario execution time is 0, the execution time of each device is set to 130 milliseconds, and then the device list is iteratively calculated.

[0094] According to an embodiment of the present invention, the cyclic calculation of the device list specifically involves:

[0095] If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is:

[0096] New scene execution time = current delay time + total number of devices in the group × execution time per device

[0097] If the scene execution time is greater than the group's delay time, it means that when the delay time expires, there are still devices in the group executing, and these devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is:

[0098] The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

[0099] It should be noted that, for example, in a scenario with 10 devices, each requiring 200ms to execute, the first 3 devices execute immediately, devices numbered 4 to 9 execute with a 1000ms delay, and the last device executes with a 2000ms delay. That is, the scenario is divided into three groups of delay methods. Calculating the first group, the current delay is 0ms, and the old execution time is 0ms, so using the first calculation method, the new scenario execution time is 0ms + 3 * 200ms = 600ms. Calculating the second group, the current delay is 1000ms, and the old execution time is 600ms. Using the first algorithm, the new scenario execution time is 1000ms + 6 * 200ms = 2200ms. Calculating the third group, the old execution time of 2200ms is greater than the current delay, so using the second calculation method, the new scenario execution time is 2200ms + 1 * 200ms = 2400ms; therefore, the entire scenario will take 2400ms to complete.

[0100] According to an embodiment of the present invention, once the project ID of a scene is locked, if there are still scene execution instructions for that project, the instructions are temporarily stored to prevent multiple scenes from executing simultaneously and affecting each other.

[0101] It should be noted that in a specific embodiment, each project has several scenarios. For example, in a smart home system, lighting, air conditioning, and curtains correspond to different scenarios of the device. Once the project ID is locked, if there are still execution instructions for the project's scenarios, the instructions will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other. For example, if the execution scenarios include the room's lighting switch, and there are still execution instructions to turn on the air conditioner, the air conditioner turn-on instruction will be temporarily stored to avoid multiple scenarios from being executed simultaneously and affecting each other.

[0102] According to an embodiment of the present invention, the current thread is released after the execution time of the sleep scenario of the detection thread is started to avoid user lag.

[0103] It should be noted that after calculating the scene execution time, the thread currently connected to the user is released to prevent the user from being stuck, and a new thread is started to delay the scene execution time before performing packet return statistics on the devices in the scene.

[0104] According to an embodiment of the present invention, when the server receives a response packet from the device, it will query the cache and delete the cache.

[0105] It should be noted that after the device in the scenario executes the instructions issued by the server, the device will return a data packet, and the server will delete the corresponding cache based on the data packet returned by the device.

[0106] According to an embodiment of the present invention, after issuing the second round of instructions based on the devices in the list and simultaneously unlocking the project ID of the current scenario, if there are other temporarily stored scenarios for the project, the new scenario will be executed; if a third round of instructions is needed, the return packet detection can be repeated; if not, the data in the Redis cache will be cleared and the execution of this scenario will end.

[0107] It should be noted that in this embodiment of the invention, the server issues a second round of instructions based on the devices in the list, and simultaneously unlocks the project ID of the current scenario. At this time, if there are other temporarily stored scenarios for this project, the new scenario is executed. As mentioned above, there is also an instruction to turn on the air conditioner, so the air conditioner will continue to be executed. If a third round of instructions is needed, the return packet detection can be repeated. In a specific embodiment, whether to start issuing the third round of instructions can be determined based on the device return packet detection in the second round of execution. If all devices in the device class table return packets, there is no need to start issuing the third round of instructions, and the data in the Redis cache will be cleared, ending the execution of this scenario. If there are devices that do not return packets, then the third round of instructions will be issued.

[0108] This invention discloses an intelligent retransmission method and system based on Redis caching, as well as a computer-readable storage medium. By intelligently calculating the scenario execution time, the device serial number and scenario execution time are stored in the Redis cache. The device response packet status is detected to obtain the corresponding device list. Based on the response packet status, the execution command is resent to the corresponding device, which reduces the server load and improves the execution efficiency of the command and the success rate of device control.

[0109] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0110] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0111] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0112] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0113] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A smart retransmission method based on Redis caching, characterized in that, Includes the following steps: Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes; When executing a scenario, the device serial number and scenario calculation time within the scenario are stored in the Redis cache, the ID of the project where the scenario is located is locked, and the detection thread is started to sleep the scenario execution time. After the detection thread finishes sleeping, it will query the cache according to the scenario devices in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list. The second round of instructions is issued based on the devices in the list, and the ID lock of the project in the current scene is released at the same time; The specific steps for calculating the execution time of the scenario are as follows: The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency. Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list; The specific steps for performing a loop calculation on the device list are as follows: If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is: New scene execution time = current delay time + total number of devices in the group × execution time per device If the scene execution time is greater than the group delay time, it means that when the delay time expires, there are still devices in the group that are executing. These devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is: The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

2. The intelligent retransmission method based on Redis caching according to claim 1, characterized in that, Once the project ID of a scene is locked, if there are still scene execution instructions for that project, the instructions will be temporarily stored to prevent multiple scenes from executing simultaneously and affecting each other.

3. The intelligent retransmission method based on Redis caching according to claim 1, characterized in that, Release the current thread after the sleep scenario execution time is started to prevent user lag.

4. The intelligent retransmission method based on Redis caching according to claim 1, characterized in that, When the server receives a response packet from the device, it will query the cache and delete the cached data.

5. The intelligent retransmission method based on Redis caching according to claim 1, characterized in that, After issuing the second round of instructions based on the devices in the list and simultaneously unlocking the project ID of the current scenario, if there are other temporarily stored scenarios for the project, the new scenario will be executed. If a third round of instructions is needed, the response packet can be checked repeatedly. If not, the data in the Redis cache will be cleared and the execution of this scenario will end.

6. A Redis-based intelligent retransmission system, further characterized in that it includes a memory and a processor, wherein the memory includes a Redis-based intelligent retransmission method program, which, when executed by the processor, performs the following steps: Calculate the scene execution time, wherein the scene includes one or more device execution queues, each scene is contained in a project, and each project contains one or more scenes; When executing a scenario, the device serial number and scenario calculation time within the scenario are stored in the Redis cache, the ID of the project where the scenario is located is locked, and the detection thread is started to sleep the scenario execution time. After the detection thread finishes sleeping, it will query the cache according to the scenario devices in turn. If the cache is still there, it means that the device has failed to execute and is added to the second round of instruction sending list. The second round of instructions is issued based on the devices in the list, and the ID lock of the project in the current scene is released at the same time; The specific steps for calculating the execution time of the scenario are as follows: The devices within the execution scenario are grouped according to their respective latency times and arranged from low to high latency. Set the initial value for the scene execution time and the execution time for each device, and then perform loop calculations on the device list; The specific steps for performing a loop calculation on the device list are as follows: If the scene execution time is less than the set delay time, it means that when the delay time expires, all previous devices have completed their execution, and the new scene execution time is: New scene execution time = current delay time + total number of devices in the group × execution time per device If the scene execution time is greater than the group delay time, it means that when the delay time expires, there are still devices in the group that are executing. These devices need to wait for the previous devices to finish executing before they can execute. The new scene execution time is: The new scenario execution time = old execution time + total number of devices in the group × execution time per device.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a Redis-based intelligent retransmission method program, which, when executed by a processor, implements the steps of a Redis-based intelligent retransmission method as described in any one of claims 1 to 5.

Images