A processing method and system of a door lock APP cooperative agent

Abstract

The application discloses a kind of door lock APP collaborative agent's processing method and system, method includes: according to the APP list obtained from user information table of door lock, first round of keep-alive message is initiated to the first APP of queue and is specified as proxy role, trigger sequential delivery queue keep-alive process;According to the keep-alive interval set by system, queue keep-alive message is initiated by proxy APP actively, sequentially transferred between each APP and updates state information;According to APP response timeout event in queue keep-alive process, detect APP offline state, and change information is synchronized to door lock by proxy APP;For proxy APP offline event, trigger proxy role re-election process by queue end APP timeout detection or other APP timer monitoring mechanism.Utilize the embodiment of the application, it can realize the low power consumption, high reliable state synchronization between door lock and multiple APP, and seamless completion role election and transfer when proxy fails, improve the overall robustness of system and user experience.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of intelligent door lock, and particularly relates to a door lock APP cooperative agent processing method and system. BACKGROUND

[0002] At present, intelligent door lock systems supporting multi-terminal APP control are increasingly popular. In such systems, how to ensure state synchronization between the door lock and multiple APPs and maintain a stable and reliable communication channel in the case of network fluctuations or user switching devices has become a technical difficulty. Existing solutions mostly adopt the door lock and all APPs for point-to-point communication or the way of specifying a single fixed agent. The former will lead to high communication load of the door lock, increased power consumption, and difficulty in unifying the states of various APPs; the latter will cause the entire communication link to be interrupted when the agent APP is offline due to process closing, network interruption, etc., lacking an effective failover mechanism, resulting in insufficient system robustness and poor user experience. SUMMARY

[0003] The application aims to provide a door lock APP cooperative agent processing method and system to solve the problems in the prior art and realize low-power and high-reliability state synchronization between the door lock and multiple APPs and seamless role election and transfer in the case of agent failure, thereby improving the overall robustness of the system and user experience.

[0004] One embodiment of the application provides a door lock APP cooperative agent processing method, which comprises the following steps:

[0005] Agent initialization and first round of keep-alive: according to an APP list obtained by the door lock from a user information table, a first round of keep-alive messages is initiated to an APP at the head of a queue and the APP is specified as an agent role, a sequentially transmitted queue keep-alive process is triggered, and initial state collection of each APP is completed;

[0006] Periodic queue keep-alive execution: according to a keep-alive interval set by the system, a queue keep-alive message is actively initiated by the agent APP, sequentially transmitted among the APPs, and state information is updated, thereby forming a periodic state synchronization mechanism;

[0007] State abnormality detection and processing: according to an APP response timeout event in the queue keep-alive process, an offline state of the APP is detected, and state change information is synchronized to the door lock by the agent APP;

[0008] Agent failure recovery and switching: for an offline event of the agent APP, a queue end APP timeout detection or other APP timer monitoring mechanism is used to trigger an agent role re-election process, and agent right transfer is completed.

[0009] Optionally, the agent initialization and first round of keep-alive comprise the following steps:

[0010] APP list retrieval: Based on the door lock's access to the platform database, retrieve a user information table containing APP-ID, IP address, online status, and role information;

[0011] Proxy designation and first round initiation: Based on the order of the APPs in the list, the APP role at the top of the queue is designated as the proxy, and a first round keep-alive message is sent to it carrying the complete list of APPs;

[0012] Queue Sequential Transmission: Based on the result of the agent APP receiving the keep-alive message, the keep-alive message is transmitted to the next APP in the order of the APP list. Each APP updates its own status information during the transmission process.

[0013] Status summary return: After the last APP in the queue completes the status update, a keep-alive message containing the status of all APPs is returned to the agent APP, and the agent APP is finally synchronized to the door lock.

[0014] Optionally, the periodic queue keep-alive execution includes:

[0015] Periodic trigger judgment: Based on the system's preset keep-alive interval, the agent APP periodically initiates a new round of queue keep-alive messages;

[0016] Silent processing with unchanged state: Based on the result that the state of each APP does not change during the queue keep-alive process, the agent APP does not need to repeatedly synchronize with the door lock after completing the state collection.

[0017] Active reporting of status changes: Based on the APP status changes detected during the queue keep-alive process, the agent APP will actively synchronize the change information to the door lock;

[0018] Message body is continuously updated: Based on the sequential transmission of keep-alive messages between apps, each app updates the status information in the message body in real time to ensure the real-time nature of the status information.

[0019] Optionally, the state anomaly detection and handling includes:

[0020] Offline status detection: Based on the APP response timeout event during the keep-alive message transmission process, the previous hop APP updates the APP status to offline;

[0021] Abnormal status transmission: Based on the detected offline status, abnormal status information is continuously carried during subsequent keep-alive message transmission;

[0022] Status Change Summary: Based on the results of messages returned from the agent APP's receive queue, identify APP information whose status has changed;

[0023] Door lock status synchronization: Based on the status change detection results, the agent APP proactively sends a status change notification message to the door lock.

[0024] Optionally, the agent failure recovery and switching includes:

[0025] Proxy offline detection: The proxy offline detection mechanism is triggered based on the message timeout event returned by the APP at the end of the queue to the proxy APP;

[0026] Automatic agent switching: Based on the result that the APP at the end of the queue detects that the agent is offline, it automatically sets itself as the new agent role;

[0027] Forced state synchronization: Based on the new agent role establishment event, directly send a synchronization message containing the status of each APP and agent changes to the door lock;

[0028] New cycle keep-alive start: Based on the completed status of the agent role switch, the new agent APP initiates subsequent queue keep-alive messages according to the keep-alive interval.

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

[0030] Active online notification: Based on the offline APP's return to online status, a notification message is sent directly to the door lock;

[0031] Door lock message forwarding: Based on the door lock receiving the online notification, forward the online information to the current agent APP;

[0032] State conflict handling: In scenarios where the agent APP receives both online notifications and queue keep-alive messages simultaneously, state conflict resolution is performed based on message timestamps;

[0033] Final Status Confirmation: Based on the conflict resolution results, determine the final status of the APP and send a confirmation message to the door lock.

[0034] Optionally, the method further includes agent offline processing during the keep-alive interval:

[0035] Timer monitoring mechanism: Based on the keep-alive timeout timer set by each APP, monitor the initiation status of a new round of keep-alive messages;

[0036] Timeout proactive reporting: Based on the event that the timer expires and no keep-alive message is received, the monitoring APP sends an agent offline notification to the door lock;

[0037] Door lock agent reassignment: Based on the result of the door lock receiving the agent offline notification, select the next online APP in the APP list in order and designate it as the agent role;

[0038] New Agent Keep-alive Startup: Once the new agent role is specified, the door lock sends a keep-alive initialization message to it, restarting the queue keep-alive process.

[0039] Another embodiment of this application provides a processing system for a door lock APP collaborative agent, the system comprising:

[0040] The keep-alive module is used for agent initialization and the first round of keep-alive: based on the list of APPs obtained by the door lock from the user information table, it sends the first round of keep-alive message to the APP at the top of the queue and designates it as the agent role, triggering the sequentially passed queue keep-alive process and completing the collection of the initial state of each APP.

[0041] The execution module is used for periodic queue keep-alive execution: according to the keep-alive interval set by the system, the agent APP actively initiates queue keep-alive messages, which are sequentially transmitted and updated between the APPs to form a periodic state synchronization mechanism.

[0042] The detection module is used for abnormal status detection and handling: based on the APP response timeout event during the queue keep-alive process, it detects the APP offline status and synchronizes the status change information to the door lock through the proxy APP;

[0043] The recovery module is used for agent failure recovery and switching: For agent APP offline events, the agent role re-election process is triggered through the APP timeout detection at the end of the queue or other APP timer monitoring mechanisms to complete the transfer of agent rights.

[0044] 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.

[0045] 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.

[0046] Compared with existing technologies, the present invention provides a method for processing door lock APP collaborative agents. Based on the APP list obtained by the door lock from the user information table, it initiates a first-round keep-alive message to the APP at the head of the queue and designates it as the agent role, triggering a sequential queue keep-alive process to complete the initial state collection of each APP. According to the keep-alive interval set by the system, the agent APP actively initiates queue keep-alive messages, sequentially transmitting and updating state information among the APPs, forming a periodic state synchronization mechanism. Based on APP response timeout events during the queue keep-alive process, the offline status of the APP is detected, and the state change information is synchronized to the door lock through the agent APP. For agent APP offline events, a agent role re-election process is triggered through queue end APP timeout detection or other APP timer monitoring mechanisms to complete the transfer of agent rights. This enables low-power, high-reliability state synchronization between the door lock and multiple APPs, and seamlessly completes role election and transfer in the event of agent failure, improving the overall robustness of the system and user experience. Attached Figure Description

[0047] Figure 1 A hardware structure block diagram of a computer terminal for a door lock APP collaborative agent processing method provided in an embodiment of the present invention;

[0048] Figure 2 A flowchart illustrating a door lock APP collaborative agent processing method provided in an embodiment of the present invention;

[0049] 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.

[0050] 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.

[0051] Figure 5 This is a schematic diagram of the processing system for a door lock APP collaborative agent provided in an embodiment of the present invention. Detailed Implementation

[0052] 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.

[0053] Smart locks typically have multiple owners, each with their own device and an app. When the lock distributes key videos / images across these owners' devices, keyframes of the video are distributed across each owner's phone. If any owner is interested in a keyframe, the phones need to quickly synchronize data to recover the complete video. In this scenario, each app plays a crucial role; therefore, the lock needs to be aware of the online status of each app, and the apps themselves need to be able to know each other's online status. This invention aims to create a method for synchronizing the online status of apps in this scenario, replacing the traditional keep-alive mechanism between the lock and the apps. When there are many owners, this method not only effectively enables collaborative online status monitoring between apps but also significantly reduces the need for keep-alive message transmission between the lock and the other apps, thus reducing network performance and battery consumption.

[0054] This invention first provides a method for processing door lock APP collaborative agents. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0055] 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 door lock APP collaborative agent processing method provided in an embodiment of the present invention. 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.

[0056] 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 processing method of the door lock app's collaborative agent.

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

[0058] 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 processing method of the door lock APP collaborative agent.

[0059] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1The 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.

[0060] 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.

[0061] See Figures 2-4 The present invention provides a method for processing a door lock APP collaborative agent, which may include the following steps:

[0062] S201, Proxy Initialization and First Round Keep-Alive: Based on the APP list obtained by the door lock from the user information table, a first round keep-alive message is sent to the APP at the top of the queue and it is designated as the proxy role, triggering the sequential queue keep-alive process and completing the collection of the initial state of each APP; specifically, the proxy initialization and first round keep-alive include:

[0063] APP list retrieval: Based on the door lock's access to the platform database, retrieve a user information table containing APP-ID, IP address, online status, and role information;

[0064] Proxy designation and first round initiation: Based on the order of the APPs in the list, the APP role at the top of the queue is designated as the proxy, and a first round keep-alive message is sent to it carrying the complete list of APPs;

[0065] Queue Sequential Transmission: Based on the result of the agent APP receiving the keep-alive message, the keep-alive message is transmitted to the next APP in the order of the APP list. Each APP updates its own status information during the transmission process.

[0066] Status summary return: After the last APP in the queue completes the status update, a keep-alive message containing the status of all APPs is returned to the agent APP, and the agent APP is finally synchronized to the door lock.

[0067] S202, Periodic Queue Keep-Alive Execution: According to the keep-alive interval set by the system, the agent APP actively initiates a queue keep-alive message, which is sequentially transmitted and updates the status information among the APPs, forming a periodic status synchronization mechanism; specifically, the periodic queue keep-alive execution includes:

[0068] Periodic trigger judgment: Based on the system's preset keep-alive interval, the agent APP periodically initiates a new round of queue keep-alive messages;

[0069] Silent processing with unchanged state: Based on the result that the state of each APP does not change during the queue keep-alive process, the agent APP does not need to repeatedly synchronize with the door lock after completing the state collection.

[0070] Active reporting of status changes: Based on the APP status changes detected during the queue keep-alive process, the agent APP will actively synchronize the change information to the door lock;

[0071] Message body is continuously updated: Based on the sequential transmission of keep-alive messages between apps, each app updates the status information in the message body in real time to ensure the real-time nature of the status information.

[0072] S203, Status Anomaly Detection and Handling: Based on the APP response timeout event during the queue keep-alive process, detect the APP's offline status and synchronize the status change information to the door lock through the proxy APP; specifically, the status anomaly detection and handling includes:

[0073] Offline status detection: Based on the APP response timeout event during the keep-alive message transmission process, the previous hop APP updates the APP status to offline;

[0074] Abnormal status transmission: Based on the detected offline status, abnormal status information is continuously carried during subsequent keep-alive message transmission;

[0075] Status Change Summary: Based on the results of messages returned from the agent APP's receive queue, identify APP information whose status has changed;

[0076] Door lock status synchronization: Based on the status change detection results, the agent APP proactively sends a status change notification message to the door lock.

[0077] S204, Proxy Failure Recovery and Switching: For proxy APP offline events, the proxy role re-election process is triggered through APP timeout detection at the end of the queue or other APP timer monitoring mechanisms to complete the transfer of proxy rights. Specifically, the proxy failure recovery and switching includes:

[0078] Proxy offline detection: The proxy offline detection mechanism is triggered based on the message timeout event returned by the APP at the end of the queue to the proxy APP;

[0079] Automatic agent switching: Based on the result that the APP at the end of the queue detects that the agent is offline, it automatically sets itself as the new agent role;

[0080] Forced state synchronization: Based on the new agent role establishment event, directly send a synchronization message containing the status of each APP and agent changes to the door lock;

[0081] New cycle keep-alive start: Based on the completed status of the agent role switch, the new agent APP initiates subsequent queue keep-alive messages according to the keep-alive interval.

[0082] Furthermore, the method also includes offline app recovery processing:

[0083] Active online notification: Based on the offline APP's return to online status, a notification message is sent directly to the door lock;

[0084] Door lock message forwarding: Based on the door lock receiving the online notification, forward the online information to the current agent APP;

[0085] State conflict handling: In scenarios where the agent APP receives both online notifications and queue keep-alive messages simultaneously, state conflict resolution is performed based on message timestamps;

[0086] Final Status Confirmation: Based on the conflict resolution results, determine the final status of the APP and send a confirmation message to the door lock.

[0087] Furthermore, the method also includes agent offline processing during the keep-alive interval:

[0088] Timer monitoring mechanism: Based on the keep-alive timeout timer set by each APP, monitor the initiation status of a new round of keep-alive messages;

[0089] Timeout proactive reporting: Based on the event that the timer expires and no keep-alive message is received, the monitoring APP sends an agent offline notification to the door lock;

[0090] Door lock agent reassignment: Based on the result of the door lock receiving the agent offline notification, select the next online APP in the APP list in order and designate it as the agent role;

[0091] New Agent Keep-alive Startup: Once the new agent role is specified, the door lock sends a keep-alive initialization message to it, restarting the queue keep-alive process.

[0092] In practical applications, this invention aims to create a method for synchronizing the online status of client-side apps in the aforementioned business scenario. This method involves setting up a proxy role to enable collaborative proxying and keep-alive mechanisms among the various apps of the door lock. This approach not only effectively establishes collaborative online status monitoring among the apps but also significantly reduces the transmission of keep-alive messages between the door lock itself and other client-side devices, thereby reducing network performance and battery consumption.

[0093] I. Technical Solution:

[0094] 1. Core idea:

[0095] This technical solution proposes a method and mechanism for a smart door lock to delegate keep-alive messages from multiple user apps to one app for proxy execution. Initially, the door lock first sends a keep-alive message to the app with the first queue number (hereinafter referred to as APP ①) and sets it as the proxy. The message carries a list of app IDs 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 ID 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 ID. The last app then sends a keep-alive message to APP ① (the proxy), carrying the status information of each app from the previous process, completing one round of queue keep-alive messages. At this point, APP ① has collected the status of all apps and synchronized the messages to the door lock. Thus, the door lock has completed the initial acquisition of the app status and delegated the initiation of keep-alive messages and the reception of app status to APP ①.

[0096] Afterwards, the queue keep-alive message is initiated by APP ① (hereinafter referred to as the agent APP) at the interval agreed upon by the system, and this cycle repeats. If the status of any APP does not change during this process, the agent APP does not need to send a synchronization message to the door lock again after receiving one round of queue keep-alive messages; if the status of any APP changes during this process, it will be recorded in the queue keep-alive message, and the agent APP will eventually send a synchronization message to the door lock.

[0097] When an app (not a proxy app) changes from offline to online, the app directly sends a status update message to the door lock, and the door lock then synchronizes the app's status to the proxy app.

[0098] When the proxy app is offline, two scenarios need to be considered:

[0099] —Scenario 1: While the current queue keep-alive message is in progress, when the last app (let's say app 5) sends a message to the proxy app, the proxy app doesn't respond. After the proxy app's response times out, app 5 confirms that the proxy app is offline. It then sets itself as the new proxy app and sends a synchronization message to the lock, showing the original proxy app's offline status and the status of all other apps. Upon receiving this, the lock updates the status of each app and the new proxy app's role. The next round of keep-alive messages is then initiated by the new proxy app, app 5. Thereafter, regardless of whether the original app 1 returns to online, the proxy role is always assumed by app 5 until app 5 also goes offline.

[0100] —Second Scenario: No keep-alive messages are currently being sent, and the app is in the interval between keep-alive messages. Therefore, if the proxy app goes offline, no one will initiate the next round of keep-alive messages. In this case, timers need to be set in advance on each app to proactively detect if no one initiates a new round of keep-alive messages. For example, app ③, by setting a timer (e.g., setting two keep-alive cycles), is the first to detect that the keep-alive message has timed out and no one has initiated it. App ③ then proactively sends a notification message to the lock, informing it that no one has initiated keep-alive (i.e., the original proxy app is offline). Upon receiving this message, the lock sets the original proxy app offline and simultaneously selects the next online app (e.g., app ②) from the app list as the proxy, sending the next round of keep-alive messages to it, specifying app ② as the proxy. Afterward, regardless of whether the original app ① returns to online, the proxy role is always assumed by app ② until app ② also goes offline.

[0101] In this way, by setting up a proxy role, the door lock delegates the right to initiate keep-alive messages and collect the status of each APP to the proxy APP. When the status of each APP does not change, the door lock can effectively save the status of each APP without initiating any keep-alive messages. When the status of each APP changes, it can be detected in time by the proxy APP and other APPs and conveniently notified to the door lock.

[0102] This method can effectively reduce the pressure on the door lock's keep-alive messages when the door lock performs distributed storage of key images. At the same time, the way the agent APP collects the status of each APP allows the terminal side to understand the status of each APP on its own, and quickly synchronize data between the terminals when data synchronization is required.

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

[0104] (1) Prerequisites:

[0105] 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, online status, and role. See Table 1 below:

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

[0107]

[0108] (2) Initiation of Keep-alive Messages and Processing of the First Round of Keep-alive Messages: The keep-alive message between the lock and the APP is initiated by the lock. The lock first reads the user list of the APP in the platform's database, and records the APP-ID, IP address, online status (which is currently empty), and role (which is currently not empty) in the order of the serial number in the database table to form the APP list. When initiating the message for the first time, the role of APP-001 is set to 1 (which means that it is set as a proxy role), and is carried in the message body. The first "keep-alive message" is sent to APP-001. After receiving the message, APP-001 parses the message body, confirms that it is a proxy role, and obtains the APP-ID and IP address list. Then, it updates its own status information to online and its role information to 1 in the table, and sends the updated message body to APP-002. At the same time, it replies to the 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 a "keep-alive message" to APP-003. This 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 in the same way, it finds no more APP-IDs to send to, so it directly sends the keep-alive message to the proxy APP, APP-001, carrying the complete APP list and the status of each APP. APP-001 receives the message and forwards it to the lock. The lock parses the message and records the status of each APP and the proxy role in the database. This completes the first round of queue keep-alive messages, and the lock obtains the initial status and role of each APP. Specific message examples are shown in Table 2 below:

[0109] Table 2. Examples of relationships and message content for the first round of queue keep-alive messages.

[0110]

[0111] Thus, through the first round of queue keep-alive messages, the door lock obtained the status information of all apps by sending only one keep-alive message, and at the same time, it set up the role of a proxy app (APP-001 in this case). Afterwards, the proxy app (APP-001) can periodically send a new round of queue keep-alive messages based on the system settings (such as sending once every 90 seconds), and the door lock no longer needs to participate in keep-alive messages until the status of an app changes.

[0112] (3) Handling when the status of an APP changes in the queue keep-alive message: When any APP in the queue is offline and cannot respond to the keep-alive message, taking APP-003 offline as an example: the agent APP (APP-001) sends a "keep-alive message" to APP-002. APP-002 responds normally and sends a "keep-alive message" to APP-003 with its own status. Since APP-003 is offline, it cannot respond to the message. After APP-002 waits for the timeout (the timeout period is set by the system and should be less than the keep-alive message interval), APP-002 updates the status of APP-003 to offline and then sends a "keep-alive message" to APP-004. APP-004 responds normally and continues to send a "keep-alive message" to APP-005. APP-005 responds normally and continues to send a "keep-alive message" to the agent APP (APP-001) with the status information of all APPs. At this point, the agent APP (APP-001) detects that APP-003's status has changed from online to offline, so it sends a notification message to the door lock, informing it that APP-003 is offline. Specific message examples are shown in Table 3 below:

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

[0114]

[0115] (4) Handling when an offline APP comes back online: When an offline APP comes back online, it immediately sends an "online notification message" to the door lock. The door lock then sends the message to the agent APP. After receiving the notification, the agent APP 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:

[0116] —①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. After the agent APP updates the status of this APP, it replies to the door lock. The door lock updates the status of this APP in the database to online.

[0117] —②If there is one (meaning there is currently a queue keep-alive message in progress): the agent app needs to wait for the current queue keep-alive message to return before making a judgment based on the app's status in the queue keep-alive message. At this time, the app's status may be in two states:

[0118] ——①If the APP status is also online in the queue keep-alive message, then the agent APP confirms that the APP status is online, updates the APP status to online and replies to the door lock;

[0119] —②If the APP status is offline in the queue keep-alive message, the agent APP needs to combine the times of the two messages to make a further judgment. The status information of the message with the latest time should be adopted.

[0120] Here, taking APP-002 and APP-004 as examples of switching from offline to online, the process of updating messages and status is explained in detail. The timeline of the entire keep-alive message sending cycle and the time points when APP-002 / APP-004 went online are shown below. Figure 3 As shown in the illustration, when APP-002 went online, there were no queue keep-alive messages in progress, while when APP-004 went online, there was exactly one round of queue keep-alive messages in progress.

[0121] When APP-002 goes online, it sends an "online notification message" to the door lock. The door lock forwards the message to the agent APP. After checking the keep-alive message status, the agent APP finds that it is currently in the keep-alive message interval period. Therefore, the agent APP obtains the status of APP-002, updates the status of APP-002 to online, and replies to the door lock.

[0122] When APP-004 is launched, a "launch notification message" is sent to the door lock. The door lock forwards it to the proxy APP. After the proxy APP queries the status of the keep-alive message and finds that the current status is the keep-alive message progress period, the proxy APP temporarily records the time of the current "launch notification message" as T1, and then waits for the queue keep-alive message to return. When the queue keep-alive message returns, the proxy APP obtains the status M of APP-004 and its status record time T2 from it (if APP-004 is online, then T2 = the response time of APP-004 to APP-003; if APP-004 is offline, then T2 = the time when APP-003 sends the keep-alive message to APP-005). At this time, if M = "online", the proxy APP updates the status of APP-004 to online and replies to the door lock; if M = "offline", the proxy APP compares T1 and T2: if T1 >= T2 (indicating that the launch notification message is after the time when APP-004 updates its status in the queue keep-alive message), the proxy APP confirms that APP-004 is online and replies to the door lock; if T1 < T2 (indicating that the launch notification message is before the time when APP-004 updates its status in the queue keep-alive message), the proxy APP confirms that APP-004 is still offline and replies with a message to notify the door lock. This process is illustrated in Figure 2 .

[0123] (5)Handling when the proxy APP is offline: When the proxy APP is offline, two cases need to be handled:

[0124] Case 1: The current queue keep-alive message is in progress. When the last APP-ID returns the keep-alive message to the proxy APP, the proxy APP is offline and unable to respond. At this time, after the last APP-ID waits for the response timeout, it confirms that the proxy APP is offline. Therefore, the last APP-ID updates the status of the proxy APP to offline, sets itself as the new proxy role, and then sends a synchronization message to the door lock with the aggregated APP status and the new proxy role. After that, the next round of queue keep-alive messages is initiated by the new proxy APP. Regardless of whether the original proxy APP resumes online, subsequent queue keep-alive messages are borne by the new proxy APP until it itself goes offline.

[0125] Scenario 2: Currently, no queue keep-alive messages are in progress. Therefore, due to the offline status of the proxy app, no one will proactively initiate the next round of keep-alive messages. At this time, other app-IDs, through their pre-set timers, sense that the new round of keep-alive messages has timed out (the timeout period can be set by the system, such as two keep-alive intervals). The app that first detects the timeout will proactively send a notification message to the door lock, informing it that the proxy app is offline. After receiving the message, the door lock selects the next online app-ID (after the original proxy app-ID) from the app list, sets it as the new proxy role, and initiates a new round of keep-alive messages. Subsequently, the new proxy app replaces the original proxy app in proactively initiating subsequent queue keep-alive messages. Regardless of whether the original proxy app later returns to online status, the new proxy app will handle all subsequent queue keep-alive messages until it also goes offline.

[0126] II. Beneficial Effects: When the door lock uses distributed storage on the terminal side, this solution can keep the online status of each terminal side active and handle collaboratively in real time, which is timely and efficient. When there are multiple users of the door lock, the number of keep-alive messages from multiple APP clients can also be effectively reduced, significantly reducing the frequency of the door lock sending keep-alive messages. Especially when the online status of each APP client does not change frequently, the number of keep-alive messages will be greatly reduced. The larger the number of users, the more obvious the effect will be, while reducing the battery consumption of the door lock.

[0127] 1. The door 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. 2. When the door lock first initiates a keep-alive message, it assigns a proxy role. This proxy role will then be fully responsible for initiating keep-alive messages in the queue and collecting the status of each app. 3. When an app that is not a proxy role goes offline, its status can be updated in the keep-alive message queue through mutual recording between apps. The proxy app will then return the update to the door lock. This method can record the offline status of one or more apps. 4. When an offline app that is not a proxy role returns online, it can directly send a notification to the door lock, which then forwards the notification to the proxy app. The proxy app, combining the app's status and status reporting time, comprehensively judges the app's latest status and updates it accordingly, completing the status update for any app transitioning from offline to online. 5. When an app that is a proxy role goes offline, each app can detect this autonomously and notify the door lock to replace it with a new proxy role, thus replacing the old proxy role.

[0128] As can be seen, based on the list of apps obtained by the door lock from the user information table, the first round of keep-alive messages is sent to the app at the top of the queue and designated as the proxy role, triggering a sequential queue keep-alive process to complete the initial state collection of each app. According to the keep-alive interval set by the system, the proxy app actively initiates queue keep-alive messages, which are sequentially transmitted and update the state information among the apps, forming a periodic state synchronization mechanism. Based on the app response timeout event during the queue keep-alive process, the offline status of the app is detected, and the state change information is synchronized to the door lock through the proxy app. For the proxy app offline event, the proxy role re-election process is triggered through the timeout detection of the app at the end of the queue or other app timer monitoring mechanisms to complete the transfer of proxy rights. This enables low-power, high-reliability state synchronization between the door lock and multiple apps, and seamless role election and transfer can be completed in the event of proxy failure, improving the overall robustness of the system and the user experience.

[0129] Another embodiment of the present invention provides a processing system for a door lock APP collaborative agent, see [link to relevant documentation]. Figure 5 The system may include:

[0130] Keep-alive module 501 is used for agent initialization and first-round keep-alive: based on the list of APPs obtained by the door lock from the user information table, it sends the first-round keep-alive message to the APP at the top of the queue and designates it as the agent role, triggers the sequentially passed queue keep-alive process, and completes the collection of the initial state of each APP.

[0131] Execution module 502 is used for periodic queue keep-alive execution: according to the keep-alive interval set by the system, the agent APP actively initiates the queue keep-alive message, which is sequentially transmitted and the status information is updated among the APPs to form a periodic status synchronization mechanism.

[0132] Detection module 503 is used for abnormal status detection and handling: based on the APP response timeout event during the queue keep-alive process, it detects the APP offline status and synchronizes the status change information to the door lock through the proxy APP;

[0133] Recovery module 504 is used for agent fault recovery and switching: For agent APP offline events, the agent role re-election process is triggered through the APP timeout detection at the end of the queue or other APP timer monitoring mechanisms to complete the transfer of agent rights.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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 processing collaborative agents in a door lock app, characterized in that, The method includes: Agent initialization and first round of keep-alive: Based on the list of apps obtained by the door lock from the user information table, the first round of keep-alive message is sent to the app at the top of the queue and it is designated as the agent role, triggering the sequentially passed queue keep-alive process and completing the collection of the initial state of each app. Periodic queue keep-alive execution: According to the keep-alive interval set by the system, the agent APP actively initiates the queue keep-alive message, which is sequentially transmitted and the status information is updated among the APPs, forming a periodic status synchronization mechanism. Status Anomaly Detection and Handling: Based on the APP response timeout event during the queue keep-alive process, the offline status of the APP is detected, and the status change information is synchronized to the door lock through the proxy APP; the status anomaly detection and handling includes: Offline status detection: Based on the APP response timeout event during the keep-alive message transmission process, the previous hop APP updates the APP status to offline; Anomaly status transmission: Based on the detected offline status, the anomaly status information is continuously carried in the subsequent keep-alive message transmission process; Status change summary: Based on the result of the proxy APP receiving the queue return message, the APP information of the APP whose status has changed is identified; Door lock status synchronization: Based on the status change detection result, the proxy APP actively sends a status change notification message to the door lock; Proxy Failure Recovery and Switching: For proxy APP offline events, a proxy role re-election process is triggered through queue end APP timeout detection or other APP timer monitoring mechanisms to complete the transfer of proxy rights. The proxy failure recovery and switching includes: Proxy offline detection: The proxy offline detection mechanism is triggered based on the queue end APP returning a message timeout to the proxy APP; Automatic proxy switching: Based on the queue end APP detecting the proxy offline result, it automatically sets itself as the new proxy role; Forced state synchronization: Based on the new proxy role establishment event, a synchronization message containing the status of each APP and the proxy change is directly sent to the door lock; New cycle keep-alive start: Based on the proxy role switching completion status, the new proxy APP initiates subsequent queue keep-alive messages according to the keep-alive interval.

2. The method according to claim 1, characterized in that, The method also includes offline APP recovery processing: Active online notification: Based on the offline APP regaining online status, a notification message is sent directly to the door lock; Door lock message forwarding: Based on the result of the door lock receiving the online notification, forward the online information to the current agent APP; State conflict handling: In scenarios where the agent APP receives both online notifications and queue keep-alive messages simultaneously, state conflict resolution is performed based on message timestamps; Final Status Confirmation: Based on the conflict resolution results, determine the final status of the APP and send a confirmation message to the door lock.

3. The method according to claim 2, characterized in that, The method also includes agent offline processing during the keep-alive interval: Timer monitoring mechanism: Based on the keep-alive timeout timer set by each APP, monitor the initiation status of a new round of keep-alive messages; Timeout proactive reporting: Based on the event that the timer expires and no keep-alive message is received, the monitoring APP sends an agent offline notification to the door lock; Door lock agent reassignment: Based on the result of the door lock receiving the agent offline notification, select the next online APP in the APP list in order and designate it as the agent role; New Agent Keep-alive Startup: Once the new agent role is specified, the door lock sends a keep-alive initialization message to it, restarting the queue keep-alive process.

4. The method according to any one of claims 1-3, characterized in that, The agent initialization and first round of keep-alive include: APP list retrieval: Based on the door lock's access to the platform database, retrieve a user information table containing APP-ID, IP address, online status, and role information; Proxy designation and first round initiation: Based on the order of the APPs in the list, the APP role at the top of the queue is designated as the proxy, and a first round keep-alive message is sent to it carrying the complete list of APPs; Queue Sequential Transmission: Based on the result of the agent APP receiving the keep-alive message, the keep-alive message is transmitted to the next APP in the order of the APP list. Each APP updates its own status information during the transmission process. Status summary return: After the last APP in the queue completes the status update, a keep-alive message containing the status of all APPs is returned to the agent APP, and the agent APP is finally synchronized to the door lock.

5. The method according to claim 4, characterized in that, The periodic queue keep-alive execution includes: Periodic trigger judgment: Based on the system's preset keep-alive interval, the agent APP periodically initiates a new round of queue keep-alive messages; Silent processing with unchanged state: Based on the result that the state of each APP does not change during the queue keep-alive process, the agent APP does not need to repeatedly synchronize with the door lock after completing the state collection. Active reporting of status changes: Based on the APP status changes detected during the queue keep-alive process, the agent APP will actively synchronize the change information to the door lock; Message body is continuously updated: Based on the sequential transmission of keep-alive messages between apps, each app updates the status information in the message body in real time to ensure the real-time nature of the status information.

6. A processing system for door lock APP collaborative agents, characterized in that, The system includes: The keep-alive module is used for agent initialization and the first round of keep-alive: based on the list of APPs obtained by the door lock from the user information table, it sends the first round of keep-alive message to the APP at the top of the queue and designates it as the agent role, triggers the sequentially passed queue keep-alive process, and completes the collection of the initial state of each APP. The execution module is used for periodic queue keep-alive execution: according to the keep-alive interval set by the system, the agent APP actively initiates queue keep-alive messages, which are sequentially transmitted and updated between APPs to form a periodic state synchronization mechanism. The detection module is used for status anomaly detection and handling: based on the APP response timeout event during the queue keep-alive process, it detects the APP's offline status and synchronizes the status change information to the door lock through the proxy APP; the status anomaly detection and handling includes: offline status detection: based on the APP response timeout event during the keep-alive message transmission process, the previous hop APP updates the APP's status to offline; abnormal status transmission: based on the detected offline status, it continuously carries abnormal status information during subsequent keep-alive message transmission; status change summary: based on the result of the proxy APP receiving the queue return message, it identifies the APP information whose status has changed; door lock status synchronization: based on the status change detection result, the proxy APP actively sends a status change notification message to the door lock; The recovery module is used for agent fault recovery and switching: For agent APP offline events, the agent role re-election process is triggered through queue end APP timeout detection or other APP timer monitoring mechanisms to complete the agent right transfer; the agent fault recovery and switching includes: agent offline detection: the agent offline detection mechanism is triggered based on the queue end APP returning a message timeout event to the agent APP; automatic agent switching: based on the queue end APP detecting the agent offline result, it automatically sets itself as the new agent role; forced state synchronization: based on the new agent role establishment event, a synchronization message containing the status of each APP and agent changes is directly sent to the door lock; new cycle keep-alive start: based on the agent role switching completion status, the new agent APP initiates subsequent queue keep-alive messages according to the keep-alive interval.

7. The system according to claim 6, characterized in that, The system also includes offline app recovery processing: Active online notification: Based on the offline APP's return to online status, a notification message is sent directly to the door lock; Door lock message forwarding: Based on the door lock's receipt of the online notification, the online information is forwarded to the current agent APP; State conflict handling: In scenarios where the agent APP receives both the online notification and the queue keep-alive message simultaneously, state conflict resolution is performed based on the message timestamp; Final state confirmation: Based on the conflict resolution result, the final state of the APP is determined and a confirmation message is sent to the door lock.

8. The system according to claim 7, characterized in that, The system also includes offline processing of the keep-alive interval agent: Timer monitoring mechanism: Based on the keep-alive timeout timer set by each APP, monitor the initiation status of a new round of keep-alive messages; Timeout proactive reporting: Based on the event of timeout and no keep-alive message received, the monitoring APP sends a proxy offline notification to the door lock; Door lock agent reassignment: Based on the result of the door lock receiving the agent offline notification, select the next online APP in the APP list in order and designate it as the agent role; New agent keep-alive start: After the new agent role is assigned, the door lock sends a keep-alive initialization message to it to restart the queue keep-alive process.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-5 when it is run.

10. 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 any one of claims 1-5.

Images