A method and system for keeping alive between multiple APP clients of a door lock

Abstract

The application discloses a kind of keep-alive method and system between door lock multiple APP client, method includes: according to the user information table in door lock platform database, generating APP queue containing APP-ID, IP address and initial state according to serial number order;According to the keep-alive interval time set by system, keep-alive message is sent to the first APP in queue by door lock, after the APP receives, update own state and pass to next serial number APP, in turn pass until the end of queue;According to the keep-alive message returned to door lock by APP at the end of queue, containing all APP state information, the online state of each APP in platform database is updated after being received by door lock;According to the offline situation encountered by APP in keep-alive message transmission process, offline state is recorded by current sending APP and continues to pass, and finally, abnormal state is updated uniformly by door lock.Utilizing the embodiment of the application, the keep-alive message pressure of door lock when multiple APP client can be reduced, the network message frequency of door lock is reduced, and the battery consumption of door lock is saved.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular, it is a method and system for keeping multiple APP clients of a door lock alive. Background Technology

[0002] In multi-user scenarios for smart locks, each user's app needs to send a keep-alive message to the lock individually to confirm their online status. In existing keep-alive solutions, the number of apps is directly proportional to the number of keep-alive messages. When there are many users, the lock needs to frequently receive and send keep-alive messages, which not only consumes significant network resources but also accelerates battery consumption and shortens battery life. Furthermore, traditional solutions lack efficient mechanisms for handling offline app states. Offline apps can easily interrupt the keep-alive process, requiring the lock to repeatedly initiate requests, further increasing resource consumption. These issues result in a heavy workload and poor battery life for locks operating in multi-app scenarios, making it difficult to meet the needs of long-term stable use. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for keeping a door lock alive across multiple APP clients, in order to overcome the shortcomings of the prior art, reduce the pressure on the door lock to keep alive multiple APP clients, reduce the frequency of door lock network messages, and save door lock battery consumption.

[0004] One embodiment of this application provides a method for keeping multiple APP clients of a door lock alive, the method comprising:

[0005] Keep-alive message queue initialization: Based on the user information table in the door lock platform database, generate an APP queue containing APP-ID, IP address and initial state in sequence;

[0006] Keep-alive message initiation and transmission: According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving the message, the APP updates its own status and passes it to the next APP in the sequence, and so on until the end of the queue.

[0007] Status summary and update: Based on the APP at the end of the queue, a keep-alive message containing the status information of all APPs is returned to the door lock. After receiving the message, the door lock updates the online status of each APP in the platform database.

[0008] Abnormal status handling: Based on the APP offline status encountered during the keep-alive message transmission, the currently sending APP records the offline status and continues to transmit it, and finally the door lock updates the abnormal status uniformly.

[0009] Optionally, the keep-alive message queue initialization includes:

[0010] Data retrieval: Based on the user information table in the door lock platform database, retrieve the serial number, APP-ID, and IP address information of all registered apps;

[0011] Queue generation: Generate an APP queue in sequence according to the read APP information. Each element in the queue contains APP-ID, IP address and initial state value;

[0012] Message encapsulation: Based on the generated APP queue information, the message is encapsulated into an initial message body for keep-alive messages. The message body contains the identifiers, network addresses, and status information of all APPs.

[0013] Optionally, the initiation and transmission of the keep-alive message includes:

[0014] Message Initiation: Based on the keep-alive interval set by the system, the door lock sends a keep-alive message to the IP address of the first APP in the queue;

[0015] Status Update and Transmission: Based on the keep-alive message received by the current APP, update its own status to online, and transmit the updated status information to the next APP in the sequence number in the keep-alive message;

[0016] Sequential transmission: According to the order of the APP queue, each APP repeats the process of state update and transmission until the message is transmitted to the APP at the end of the queue;

[0017] End-of-line processing: After receiving the keep-alive message from the APP at the end of the queue, update its own status and return the complete keep-alive message to the door lock.

[0018] Optionally, the status aggregation and update includes:

[0019] Message reception: Based on the keep-alive message returned by the APP at the end of the queue received by the door lock, parse the status information of each APP in the message body;

[0020] Status comparison: The status information of each APP obtained from the parsing is compared with the status recorded in the platform database;

[0021] Database update: Based on the comparison results, update the online status field of each APP in the platform database;

[0022] Periodic loop: Based on the keep-alive interval set by the system, repeat steps S2-S3 to achieve periodic keep-alive detection.

[0023] Optionally, the abnormal state handling includes:

[0024] Offline detection: If the current APP sends a keep-alive message to the next APP and waits for a response timeout, the APP is determined to be offline.

[0025] Status recording: Based on the offline determination result, the current APP records the identifier and offline status of the offline APP in the keep-alive message;

[0026] Continue passing on: According to the keep-alive message passing rules, the current APP will pass the keep-alive message containing offline records to the next online APP;

[0027] Anomaly Summary: Based on the offline records accumulated in the keep-alive messages, the door lock will eventually update the anomaly status in the platform database.

[0028] Optionally, the method further includes offline app recovery processing:

[0029] Online notification: Once the offline APP is restored to online status, an online notification message will be sent to the door lock immediately;

[0030] Status determination: Compare the status based on the time when the door lock receives the online notification message and the current keep-alive message;

[0031] Conflict handling: Determine the final status based on the chronological order of the online notification message time and the status record time in the keep-alive message;

[0032] Status Update: Based on the judgment result, update the online status of the APP in the platform database.

[0033] Another embodiment of this application provides a keep-alive system between multiple APP clients of a door lock, the system comprising:

[0034] The initialization module is used for initializing the keep-alive message queue: based on the user information table in the door lock platform database, it generates an APP queue containing APP-ID, IP address and initial state in sequence.

[0035] The initiation module is used for initiating and transmitting keep-alive messages: According to the keep-alive interval time set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving the message, the APP updates its own status and passes it to the next APP in the sequence, and so on until the end of the queue.

[0036] The summary module is used for status summary and update: based on the APP at the end of the queue, a keep-alive message containing the status information of all APPs is returned to the door lock. After receiving the message, the door lock updates the online status of each APP in the platform database.

[0037] The processing module is used for handling abnormal states: based on the APP offline status encountered during the keep-alive message transmission, the currently sending APP records the offline status and continues to transmit it, and finally the door lock updates the abnormal status uniformly.

[0038] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0039] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0040] Compared with existing technologies, the present invention provides a keep-alive method for multiple APP clients of a door lock. Based on the user information table in the door lock platform database, an APP queue containing APP-ID, IP address, and initial state is generated in sequence. According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the first APP in the queue. Upon receiving the message, the APP updates its own state and passes it to the next APP in sequence, continuing until the end of the queue. The APP at the end of the queue returns a keep-alive message containing the status information of all APPs to the door lock. Upon receiving this message, the door lock updates the online status of each APP in the platform database. Based on APP offline situations encountered during keep-alive message transmission, the currently sending APP records the offline status and continues transmission. Finally, the door lock uniformly updates the abnormal status, thereby reducing the keep-alive message pressure on the door lock when dealing with multiple APP clients, reducing the frequency of network messages, and saving door lock battery consumption. Attached Figure Description

[0041] Figure 1 A hardware structure block diagram of a computer terminal for a method of keeping multiple APP clients of a door lock alive, provided in an embodiment of the present invention;

[0042] Figure 2 A flowchart illustrating a method for keeping multiple APP clients of a door lock alive, provided in an embodiment of the present invention;

[0043] Figure 3 This is a schematic diagram illustrating the process of several rounds of queue keep-alive messages and the online time of two apps, provided for an embodiment of the present invention.

[0044] Figure 4 This is a schematic diagram illustrating two possibilities for a certain round of queue keep-alive messages in progress and the online time of a certain APP, provided in an embodiment of the present invention.

[0045] Figure 5 This is a schematic diagram of a keep-alive system between multiple APP clients for a door lock, provided in an embodiment of the present invention. Detailed Implementation

[0046] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0047] Smart locks typically have multiple owners, each with their own device and an app. When there are many owners, each app needs to send a keep-alive message to the lock individually to confirm its online / offline status. Since keep-alive messages are network messages that need to be sent periodically and continuously, the number of keep-alive messages increases exponentially with the number of apps, consuming significant network resources, especially the lock's battery.

[0048] This invention first provides a method for keeping multiple APP clients of a door lock alive. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0049] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a method of keeping multiple APP clients of a door lock alive, provided in an embodiment of the present invention. (See diagram below.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0050] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any keep-alive method among multiple door lock clients.

[0051] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0052] The internal memory provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to perform any kind of keep-alive method between multiple door lock APP clients.

[0053] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0054] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0055] See Figures 2-4 The present invention provides a method for keeping multiple APP clients of a door lock alive, which may include the following steps:

[0056] S201, Keep-alive message queue initialization: Based on the user information table in the door lock platform database, generate an APP queue containing APP-ID, IP address, and initial state in sequence; specifically, the keep-alive message queue initialization includes:

[0057] Data retrieval: Based on the user information table in the door lock platform database, retrieve the serial number, APP-ID, and IP address information of all registered apps;

[0058] Queue generation: Generate an APP queue in sequence according to the read APP information. Each element in the queue contains APP-ID, IP address and initial state value;

[0059] Message encapsulation: Based on the generated APP queue information, the message is encapsulated into an initial message body for keep-alive messages. The message body contains the identifiers, network addresses, and status information of all APPs.

[0060] S202, Keep-alive message initiation and transmission: According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving the message, the APP updates its own status and passes it to the next APP in the sequence, and so on until the end of the queue; specifically, the keep-alive message initiation and transmission includes:

[0061] Message Initiation: Based on the keep-alive interval set by the system, the door lock sends a keep-alive message to the IP address of the first APP in the queue;

[0062] Status Update and Transmission: Based on the keep-alive message received by the current APP, update its own status to online, and transmit the updated status information to the next APP in the sequence number in the keep-alive message;

[0063] Sequential transmission: According to the order of the APP queue, each APP repeats the process of state update and transmission until the message is transmitted to the APP at the end of the queue;

[0064] End-of-line processing: After receiving the keep-alive message from the APP at the end of the queue, update its own status and return the complete keep-alive message to the door lock.

[0065] S203, Status Summary and Update: Based on the APP at the end of the queue, a keep-alive message containing the status information of all APPs is returned to the door lock. After receiving the message, the door lock updates the online status of each APP in the platform database. Specifically, the status summary and update includes:

[0066] Message reception: Based on the keep-alive message returned by the APP at the end of the queue received by the door lock, parse the status information of each APP in the message body;

[0067] Status comparison: The status information of each APP obtained from the parsing is compared with the status recorded in the platform database;

[0068] Database update: Based on the comparison results, update the online status field of each APP in the platform database;

[0069] Periodic loop: Based on the keep-alive interval set by the system, repeat steps S2-S3 to achieve periodic keep-alive detection.

[0070] S204, Abnormal Status Handling: Based on the APP offline status encountered during the keep-alive message transmission process, the currently sending APP records the offline status and continues to transmit it, and finally the door lock updates the abnormal status uniformly.

[0071] Specifically, the abnormal state handling includes: offline detection: if the current APP sends a keep-alive message to the next sequence number APP and waits for a response timeout, it is determined that the APP is offline;

[0072] Status recording: Based on the offline determination result, the current APP records the identifier and offline status of the offline APP in the keep-alive message;

[0073] Continue passing on: According to the keep-alive message passing rules, the current APP will pass the keep-alive message containing offline records to the next online APP;

[0074] Anomaly Summary: Based on the offline records accumulated in the keep-alive messages, the door lock will eventually update the anomaly status in the platform database.

[0075] Specifically, the method also includes offline APP recovery processing:

[0076] Online notification: Once the offline APP is restored to online status, an online notification message will be sent to the door lock immediately;

[0077] Status determination: Compare the status based on the time when the door lock receives the online notification message and the current keep-alive message;

[0078] Conflict handling: Determine the final status based on the chronological order of the online notification message time and the status record time in the keep-alive message;

[0079] Status Update: Based on the judgment result, update the online status of the APP in the platform database.

[0080] In practical applications, a specific implementation scheme includes the following:

[0081] 1. Core idea:

[0082] This technical solution proposes a distributed keep-alive method and mechanism among multiple user apps of a smart door lock. The multiple user apps are sequentially numbered into a queue. The door lock first sends a keep-alive message to the app with the first number in the queue (hereinafter referred to as APP ①), carrying a list of app numbers and IP addresses. APP ① replies with a confirmation message to the door lock, indicating that everything is normal. Then, APP ① sends a keep-alive message to the app with the second number (hereinafter referred to as APP ②) according to the app number list. APP ② replies with a confirmation message to APP ①, indicating that everything is normal. This process continues, with keep-alive messages being sent sequentially from app to app with the last number. The last app then sends a keep-alive message to the door lock, carrying the status information of each app from the previous steps, informing the door lock of the status of all apps. This completes one round of queue keep-alive messages. Afterward, the door lock initiates a new round of queue keep-alive messages according to the system-defined keep-alive interval, and this cycle continues.

[0083] If any app goes offline during the first round of queue keep-alive message sending, preventing it from responding to the keep-alive message, the sender of the current message adds the offline app's ID and offline status to the queue keep-alive message and sends it to the next app with that ID. This process continues, with the queue keep-alive message potentially recording offline information for multiple apps, until the last app in the queue sends a message back to the lock. At this point, the lock has obtained the status of all apps in the queue, completing one round of queue keep-alive with offline status. Afterward, the lock initiates a new round of queue keep-alive messages according to the system-defined keep-alive interval, and this cycle repeats.

[0084] When an app changes from offline to online, the app directly sends a status update message to the lock. The lock updates the app's status in the database table. If there is an ongoing queue keep-alive message, the lock waits for the current queue keep-alive message to return to the lock. Then, it combines the app's status recorded in the queue keep-alive message with the record time of the two statuses to determine the latest status information of the app and performs the status update.

[0085] 2. The complete technical implementation process is as follows:

[0086] (1) Prerequisites:

[0087] A smart lock is installed on the front door of the homeowner's house. The lock has multiple owners, each with a corresponding app installed on their phone. Upon initial registration, the app obtains the lock's IP address from the platform and stores it locally (for subsequent communication with the lock). Each app has a unique ID (e.g., username + phone number used during registration) and can report its app ID, username, IP address, and online status to the lock platform. The lock platform's database stores user information for multiple owners, including serial number, app ID, username, IP address, and online status. See Table 1 below:

[0088] Table 1. User information recorded in the door lock platform database.

[0089]

[0090] (2) Initiation of Keep-alive Messages and Processing of a Round of Keep-alive Messages: The keep-alive message between the door lock and the APP is initiated by the door lock. The door lock first reads the user list of the APP in the platform's database, records the APP-ID, IP address and online status (at this time the online status is still empty) in the order of the serial number in the database table, forms the APP list, carries it in the message body, and sends the first "keep-alive message" to APP-001. After receiving the message, APP-001 parses the message body, obtains the APP-ID and IP address list, updates its own status information to online in the table, carries the updated message body and sends the "keep-alive message" to APP-002, and at the same time replies to the door lock with a "keep-alive response message". Afterwards, APP-002 parses the message body in the same way as APP-001, obtains the APP-ID and IP address list, updates its own status information to online, and then sends the "keep-alive message" to APP-003. This process continues until the message is sent to the last APP-ID in the APP list, illustrated here as APP-005. After parsing the message body and updating its own status information as described above, there are no more APP-IDs to send to. Therefore, it directly sends the keep-alive message to the door lock, carrying the complete list of APPs and the status of each APP. After receiving the message, the door lock parses it and records the status of each APP in the database. This completes one round of queue keep-alive messages. Specific message examples are shown in Table 2 below:

[0091] Table 2. Examples of relationships and message content for a single-round queue keep-alive message.

[0092]

[0093] Thus, through one round of queue keep-alive messages, the door lock obtained the status information of all apps by sending only one keep-alive message. Afterwards, the door lock can periodically send a new round of queue keep-alive messages based on system settings (such as sending every 30 seconds).

[0094] (3) Handling when there are offline APPs in the queue keep-alive message: When any APP in the queue is offline and cannot respond to the keep-alive message, taking APP-002 and APP-004 as offline as an example: The door lock sends a "keep-alive message" to APP-001. APP-001 responds normally and sends a "keep-alive message" to APP-002 with its own status. APP-002 cannot respond to the message because it is offline. APP-001 waits for a timeout (the timeout period is set by the system and should be less than the interval between keep-alive messages). After that, APP-001 updates the status of APP-002 to offline, then sends a "keep-alive message" to APP-003. APP-003 responds normally and continues to send a "keep-alive message" to APP-004. Since APP-004 is also offline, it cannot respond to the message. After APP-003 waits for a timeout, it updates the status of APP-004 to offline, then sends a "keep-alive message" to APP-005. APP-005 responds normally and continues to send a "keep-alive message" to the door lock, carrying the status information of all APPs. At this time, the specific message examples are shown in Table 3 below:

[0095] Table 3. Examples of relationships and message content for a single-round queue keep-alive message.

[0096]

[0097] Exception handling:

[0098] If the offline app happens to be the last app in the queue, and the second-to-last app doesn't receive a response after sending a keep-alive message, then the second-to-last app, after querying the list, cannot continue sending messages. Therefore, the second-to-last app updates the status of the last app and sends the message directly to the door lock. Specific message examples are shown in Table 4 below:

[0099] Table 4. Examples of relationships and message content for a single-round queue keep-alive message.

[0100]

[0101] (4) Handling when an offline APP becomes online again: When an offline APP becomes online again, an "online notification message" is immediately sent to the door lock. After receiving the notification, the door lock first checks its own "keep-alive messages" and confirms whether there are any queued keep-alive messages that have not yet been completed based on the message status:

[0102] —①If not (indicating that the current period is within the keep-alive message interval): The "online notification message" reported by this APP is the latest message, and the status of this APP in the door lock update database is online;

[0103] ——② If there is one (indicating that there is exactly one queue keep-alive message in progress): The door lock needs to wait for the current queue keep-alive message to return to the door lock, and then make a judgment based on the status of this APP in the queue keep-alive message. At this time, the status of this APP may have two situations:

[0104] ——① If the status of this APP in the queue keep-alive message is also online, the door lock confirms that the status of this APP is online and updates the status of this APP in the database to online;

[0105] ——② If the status of this APP in the queue keep-alive message is offline, the door lock combines the time of these two message statuses to further judge. Whichever message has the latest time, the status information of that message is adopted and the database is updated.

[0106] Here, taking the example of APP-002 and APP-004 changing from offline to online respectively, the update process of messages and status is specifically described. The time axis of the entire keep-alive message sending cycle, and the time points when APP-002 / APP-004 go online, are as Figure 3 Shown: (It can be seen that there is no queue keep-alive message in progress when the APP-002 online notification is sent, and when the APP-004 online notification is sent, there is exactly one round of queue keep-alive message in progress).

[0107] When APP-002 goes online, an "online notification message" is sent to the door lock. After the door lock queries the keep-alive message status, it finds that it is currently in the keep-alive message interval period. Therefore, the door lock obtains the status of APP-002 and then updates the status of APP-002 in the database to online;

[0108] When APP-004 goes online, an "online notification message" is sent to the door lock. After the door lock queries the keep-alive message status, it finds that it is currently in the keep-alive message progress period. Therefore, the door lock temporarily records the time of the current "online notification message" as T1, and then waits for the queue keep-alive message to return. When the queue keep-alive message returns, the door lock obtains the status M of APP-004 and the recording time T2 of its status from it (if APP-004 is online, then T2 = the time when APP-004 responds to APP-003; if APP-004 is offline, then T2 = the time when APP-003 sends a keep-alive message to APP-005). At this time, if M = "online", the door lock updates the status of APP-004 in the database to online; if M = "offline", the door lock compares T1 and T2: If T1 >= T2 (indicating that the online notification message is after the time when APP-004 updates its status in the queue keep-alive message), the door lock confirms that APP-004 is online and updates the database to online; if T1 < T2 (indicating that the online notification message is before the time when APP-004 updates its status in the queue keep-alive message), the door lock confirms that APP-004 is offline and updates the database to offline. This process is shown as Figure 4 .

[0109] Beneficial effects: When there are multiple users on the door lock, the number of keep-alive messages from multiple APP clients can be effectively reduced, significantly reducing the frequency of keep-alive messages sent by the door lock. The reduction in the number of messages is (N-1) / N, and the larger N is, the more obvious the effect. At the same time, the battery consumption of the door lock is reduced.

[0110] 1. The lock initiates a keep-alive message, which is then sent sequentially among the apps in a queue. During this process, each app effectively records its own status and ultimately returns it to the lock. 2. When an app goes offline, its status can be updated in the keep-alive queue through mutual recording between apps, and then returned to the lock. This method can record the offline status of one or any number of apps. 3. When an offline app comes back online, it can send an online notification to the lock. The lock then combines the app's status, status reporting time, and other information to comprehensively determine the app's latest status and update it accordingly, completing the status update for any app from offline to online.

[0111] As can be seen, based on the user information table in the door lock platform database, an APP queue containing APP-ID, IP address, and initial state is generated in sequence. According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving it, the APP updates its own state and passes it to the next APP in sequence, and so on until the end of the queue. The APP at the end of the queue returns a keep-alive message containing the status information of all APPs to the door lock. After receiving it, the door lock updates the online status of each APP in the platform database. According to the offline status of APPs encountered during the keep-alive message transmission, the currently sending APP records the offline status and continues to transmit it. Finally, the door lock updates the abnormal status uniformly. This can reduce the keep-alive message pressure on the door lock when dealing with multiple APP clients, reduce the frequency of door lock network messages, and save door lock battery consumption.

[0112] Another embodiment of the present invention provides a keep-alive system between multiple APP clients of a door lock, see [link to relevant documentation]. Figure 5 The system may include:

[0113] Initialization module 501 is used for keep-alive message queue initialization: based on the user information table in the door lock platform database, it generates an APP queue containing APP-ID, IP address and initial state in sequence.

[0114] The initiation module 502 is used for initiating and transmitting keep-alive messages: according to the keep-alive interval time set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving the message, the APP updates its own status and passes it to the next APP in the sequence number, and so on until the end of the queue.

[0115] The summary module 503 is used for status summary and update: based on the APP at the end of the queue, it returns a keep-alive message containing the status information of all APPs to the door lock. After receiving the message, the door lock updates the online status of each APP in the platform database.

[0116] Processing module 504 is used for abnormal status handling: based on the APP offline status encountered during the keep-alive message transmission, the currently sending APP records the offline status and continues to transmit it, and finally the door lock updates the abnormal status uniformly.

[0117] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0118] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0119] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0120] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for keeping multiple APP clients of a door lock alive, characterized in that, The method includes: Keep-alive message queue initialization: Based on the user information table in the door lock platform database, generate an APP queue containing APP-ID, IP address and initial state in sequence; Keep-alive message initiation and transmission: According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the first APP in the queue. After receiving the message, the APP updates its own status and passes it to the next APP in sequence, and so on until the end of the queue. The keep-alive message initiation and transmission includes: Message initiation: According to the keep-alive interval set by the system, the door lock sends a keep-alive message to the IP address of the first APP in the queue; Status update and transmission: Upon receiving the keep-alive message, the current APP updates its own status to online and carries the updated status information in the keep-alive message to the next APP in sequence; Sequential transmission: According to the APP queue order, each APP repeats the status update and transmission process until the message reaches the APP at the end of the queue; End processing: Upon receiving the keep-alive message, the APP at the end of the queue updates its own status and returns the complete keep-alive message to the door lock. Status Summarization and Update: Based on the keep-alive message containing the status information of all apps returned by the last app in the queue, the lock updates the online status of each app in the platform database upon receiving the message. The status summarization and update includes: Message Reception: Based on the keep-alive message returned by the last app in the queue, the lock parses the status information of each app in the message body; Status Comparison: Based on the parsed status information of each app, compares it with the status recorded in the platform database; Database Update: Based on the comparison result, updates the online status field of each app in the platform database; Periodic Loop: Based on the keep-alive interval set by the system, repeatedly executes the steps of keep-alive message initiation and transmission, status summarization and update to achieve periodic keep-alive detection. Abnormal Status Handling: Based on the offline status of the APP encountered during the keep-alive message transmission process, the currently sending APP records the offline status and continues the transmission, and finally the door lock updates the abnormal status uniformly; the abnormal status handling includes: offline detection: if the current APP sends a keep-alive message to the next sequence number APP and waits for a response timeout, it is determined that the APP is offline; status recording: based on the offline determination result, the current APP records the identifier and offline status of the offline APP in the keep-alive message; continued transmission: according to the keep-alive message transmission rules, the current APP passes the keep-alive message containing the offline record to the next online APP; abnormal summary: based on the accumulated offline records in the keep-alive messages, the door lock finally updates the abnormal status in the platform database uniformly; The method also includes offline APP recovery processing: online notification: immediately send an online notification message to the door lock upon the offline APP returning to online status; status judgment: compare the status with the current keep-alive message based on the time the door lock receives the online notification message; conflict handling: determine the final status based on the order of the online notification message time and the status record time in the keep-alive message; status update: update the online status of the APP in the platform database based on the judgment result.

2. The method according to claim 1, characterized in that, The initialization of the keep-alive message queue includes: Data reading: Based on the user information table in the door lock platform database, read the serial number, APP-ID, and IP address information of all registered APPs; Queue generation: Generate an APP queue in sequence according to the read APP information. Each element in the queue contains APP-ID, IP address and initial state value; Message encapsulation: Based on the generated APP queue information, the message is encapsulated into an initial message body for keep-alive messages. The message body contains the identifiers, network addresses, and status information of all APPs.

3. A keep-alive system for multiple APP clients of a door lock, characterized in that, The system includes: The initialization module is used for initializing the keep-alive message queue: based on the user information table in the door lock platform database, it generates an APP queue containing APP-ID, IP address and initial state in sequence. The initiation module is used for initiating and transmitting keep-alive messages: Based on the system-set keep-alive interval, the door lock sends a keep-alive message to the first app in the queue. Upon receiving the message, the first app updates its status and passes it to the next app in the sequence, continuing this process until the end of the queue. The keep-alive message initiation and transmission includes: Message initiation: Based on the system-set keep-alive interval, the door lock sends a keep-alive message to the IP address of the first app in the queue; Status update and transmission: Upon receiving the keep-alive message, the current app updates its status to online and carries the updated status information in the keep-alive message, transmitting it to the next app in the sequence; Sequential transmission: According to the app queue order, each app repeats the status update and transmission process until the message reaches the app at the end of the queue; End processing: Upon receiving the keep-alive message, the last app in the queue updates its status and returns the complete keep-alive message to the door lock. The aggregation module is used for status aggregation and updating: based on the keep-alive message containing the status information of all apps returned by the last app in the queue, the lock updates the online status of each app in the platform database after receiving it. The status aggregation and updating includes: message reception: based on the keep-alive message returned by the last app in the queue, the lock parses the status information of each app in the message body; status comparison: based on the parsed status information of each app, compares it with the status recorded in the platform database; database update: based on the comparison result, updates the online status field of each app in the platform database; periodic loop: based on the keep-alive interval set by the system, repeatedly executes the steps of keep-alive message initiation and transmission, status aggregation and updating, to achieve periodic keep-alive detection; The processing module handles abnormal states: based on the offline status of an app encountered during the keep-alive message transmission process, the currently sending app records the offline status and continues the transmission, with the door lock ultimately updating the abnormal status uniformly. The abnormal state handling includes: offline detection: if the current app sends a keep-alive message to the next app and waits for a response timeout, it determines that the app is offline; status recording: based on the offline determination result, the current app records the identifier and offline status of the offline app in the keep-alive message; continued transmission: according to the keep-alive message transmission rules, the current app transmits the keep-alive message containing the offline record to the next online app; and abnormal summary: based on the accumulated offline records in the keep-alive messages, the door lock ultimately updates the abnormal status in the platform database uniformly. The system also includes offline APP recovery processing: Online notification: Upon the offline APP returning to online status, an online notification message is immediately sent to the door lock; Status judgment: The status is compared with the current keep-alive message based on the time the door lock receives the online notification message; Conflict handling: The final status is determined based on the order of the online notification message time and the status record time in the keep-alive message; Status update: Based on the judgment result, the online status of the APP in the platform database is updated.

4. The system according to claim 3, characterized in that, The initialization module is specifically used for: Data retrieval: Based on the user information table in the door lock platform database, retrieve the serial number, APP-ID, and IP address information of all registered apps; Queue generation: Generate an APP queue in sequence according to the read APP information. Each element in the queue contains APP-ID, IP address and initial state value; Message encapsulation: Based on the generated APP queue information, the message is encapsulated into an initial message body for keep-alive messages. The message body contains the identifiers, network addresses, and status information of all APPs.

5. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of claim 1 or 2 when it is run.

6. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of claim 1 or 2.

Images