A method and system for nighttime guidance using multi-lock coordination

Abstract

This invention discloses a nighttime guidance method and system for multi-lock collaboration. The method includes: based on the smart lock's discovery that the public service resource is unavailable when it is reserved, the initiating lock constructs a multicast data packet; upon receiving the multicast data packet, the router forwards the packet to the potential target lock; upon receiving the reservation request, the potential target lock generates a reservation confirmation reply message; based on the router detecting reservation confirmation reply messages from multiple potential target locks, the first arriving reply message is allowed to proceed to the initiating lock; upon receiving the confirmation reply from the first responding lock, the target lock releases its original resource reservation and notifies the public service facility to update the reservation information. Using this invention, rapid and orderly resource reservation without a central server can be achieved, avoiding resource conflicts caused by multiple users reserving resources and ensuring strong consistency in resource status updates.

Description

Technical Field

[0001] This invention belongs to the field of smart door lock technology, and in particular to a nighttime guidance method and system for multi-door lock collaboration. Background Technology

[0002] Currently, smart door locks and online booking systems are commonly used for resource management in hotels, public venues, and other locations that provide shared resources (such as meeting rooms and shared parking spaces). However, when resources are fully booked for a certain period, existing systems often only display a "resources full" message, failing to provide a flexible reallocation mechanism for users with urgent or high-priority needs. While existing technologies offer simple "preemption" or "transfer" functions, they largely rely on sequential polling by a central server, resulting in significant response latency. Furthermore, simultaneous preemption by multiple users can easily lead to resource conflicts and inconsistent states. In addition, centralized processing mechanisms are susceptible to single-point-of-failure risks under network latency or server pressure, making it difficult to meet the demands of high-concurrency, real-time scenarios such as nighttime guidance. Therefore, there is an urgent need for a distributed, low-latency, and atomic multi-device collaborative preemption method to achieve rapid and orderly reallocation of public resources. Summary of the Invention

[0003] The purpose of this invention is to provide a nighttime guidance method and system with multi-lock collaboration to overcome the shortcomings of the prior art. It can achieve rapid and orderly resource preemption without a central server, avoid resource conflicts caused by multiple users preempting resources, and ensure strong consistency of resource status updates.

[0004] One embodiment of this application provides a nighttime guidance method using multiple locks working together, the method comprising: Preemption request initiation and multicast construction: When the smart lock finds that there are no available public service resources when it is reserving them, the preemption initiating lock constructs a multicast data message carrying its own identifier, priority and preemption intention, and sends it to the preset multicast address; Routing priority filtering and targeted forwarding: Based on the multicast data packets received by the router, the priority information in the packets is parsed, and the local preset priority mapping table is queried. The packets are then forwarded to all potential target locks whose priority is lower than that of the preemption initiator. Local judgment and preemption response of target door lock: Based on the result of the potential target door lock judging its current preemption status after receiving the preemption request, a preemption confirmation reply message is generated; Routing acknowledgment message filtering and first response locking: Based on the preemption acknowledgment reply messages sent by multiple potential target locks detected by the router, only the first reply message that arrives is allowed to be passed to the preemption initiator by comparing the timestamps, and the identifier of the first response lock is cached. At the same time, other subsequent response locks are intercepted and notified that the preemption has been confirmed. Confirmation of preemption and update of resource status: After the door lock that initiates the preemption receives the confirmation reply from the first responding door lock, the two parties complete the confirmation interaction. The target door lock that was preempted releases the original resource reservation and notifies the public service facility to update the reservation information. At the same time, its own status is updated to waiting.

[0005] Optionally, the preemption request initiation and multicast construction include: Resource status query: Based on the night-time event triggered by the sensor device, the smart door lock initiates a resource reservation request to the public service facility and receives the current resource occupancy status and a list of door lock identifiers corresponding to the reserved but unused resources; Preemption decision trigger: Based on the query result that the resource occupancy status is no longer available, the preemption decision process for the door lock is triggered; Multicast message construction: Based on the preemption decision, the fields in the standard multicast data message format are extended to encapsulate the unique identifier of the preemption initiator's lock, IP address, MAC address, preemption intent identifier, its own priority, and a list of potential target lock identifiers; Multicast transmission: Send the constructed multicast data packets according to the preset multicast address associated with the public service facility.

[0006] Optionally, the route priority filtering and directed forwarding include: Message parsing: Based on the message received by the router with the destination address being the preset multicast address, its extended fields are parsed to extract the priority of the preemption initiator and the list of potential target door lock identifiers; Priority mapping table query: Based on the list of potential target door lock identifiers, query the locally stored priority mapping table to obtain the priority value corresponding to each door lock in the list; Target filtering: Filter out all locks in the potential target lock list whose priority value is higher than or equal to the priority of the preemption initiator, and obtain the final target lock list to be forwarded; Targeted multicast forwarding: Based on the final target lock list, forward the multicast data packets from the physical interfaces connecting these target locks.

[0007] Optionally, the local determination and preemption response of the target door lock includes: Preemptible status determination: Based on the preemption request received by the potential target door lock, check the preemptible status of its own maintenance; the status is dynamically set by the door lock according to local events such as whether the associated user has left the room; Decision generation: If the preemptible flag is marked as non-preemptible, the preemption request is discarded and no response is given; if it is preemptible, a preemption confirmation reply message is generated. Reply message construction: The preemption confirmation reply message is a unicast message with the destination address being the IP address of the door lock that initiated the preemption, which carries its own identifier and confirmation information of agreeing to the preemption.

[0008] Optionally, the routing acknowledgment message filtering and first response locking include: First response listening and letting: After forwarding the preemption request, the router starts a listening mechanism for packets from the target door lock side with the destination address being the IP of the preemption initiator, and forwards the first preemption confirmation reply packet normally. First response information caching: While allowing the first reply packet, extract the source IP, source MAC address and corresponding session identifier of the packet and cache them locally on the router; Timer start: After allowing the first reply message to pass, start a timer of a preset duration; Subsequent response interception and notification: Before the timer expires, intercept other preemption confirmation reply messages that are detected and belong to the same preemption session, and construct a notification message to send to the subsequent response lock. The notification message carries the cached first response lock identifier to inform it that the preemption confirmation has been completed by another party. Session termination: After the timer expires, the router stops listening to and processing messages related to the preemption session.

[0009] Optionally, the preemption confirmation and resource status update further include: Successful takeover termination: After the takeover initiating lock receives the confirmation reply from the first responding lock, it sends a final confirmation message to the first responding lock to complete the handover of authority; subsequently, the target lock notifies the public service facility to update the resource reservation information, changing the reservation party to the takeover initiating party, and adds itself to the waiting queue for the resource; both locks update the status of their local indicator lights according to the results; No target termination: If the router finds that the final target lock list to be forwarded is empty after filtering in the routing priority filtering and directed forwarding steps, it will directly send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of public service resources and update the indicator light status. No response termination: If the router does not hear any valid preemption confirmation reply after the timer for filtering the routing confirmation message and locking the first response expires, it will send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of the public service resource and update the indicator light status.

[0010] Another embodiment of this application provides a multi-lock collaborative nighttime guidance system, the system comprising: The initiation module is used for preemption request initiation and multicast construction: when the smart lock finds that the resources are no longer available when it reserves public service resources, the preemption initiator lock constructs a multicast data packet carrying its own identifier, priority and preemption intention, and sends it to the preset multicast address; The filtering module is used for route priority filtering and targeted forwarding: based on the multicast data packets received by the router, it parses the priority information in the packets, queries the local preset priority mapping table, and forwards the packets to all potential target locks with lower priority than the preemption initiator. The judgment module is used for local judgment and preemption response of the target door lock: based on the result of the potential preempted target door lock judging its current preemption status after receiving the preemption request, it generates a preemption confirmation reply message; The filtering module is used for routing confirmation message filtering and first response locking: based on the preemption confirmation reply messages sent by multiple potential target locks detected by the router, it only allows the first reply message to arrive to the preemption initiator by comparing the timestamps, and caches the identifier of the first response lock, while intercepting and notifying other subsequent response locks that the preemption has been confirmed; The confirmation module is used for preemption confirmation and resource status update: After the preempting door lock receives the confirmation reply from the first responding door lock, the two parties complete the confirmation interaction. The preempted target door lock releases the original resource reservation and notifies the public service facility to update the reservation information. At the same time, its own status is updated to waiting.

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

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

[0013] Compared with existing technologies, the present invention provides a nighttime guidance method with multi-lock collaboration, which can realize rapid and orderly resource preemption without a central server, avoid resource conflicts caused by multiple users preempting resources, and ensure strong consistency of resource status updates. Attached Figure Description

[0014] Figure 1 A hardware structure block diagram of a computer terminal for a multi-lock collaborative nighttime guidance method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating a nighttime guidance method using multiple locks in coordination, provided in an embodiment of the present invention; Figure 3This is a schematic diagram of a multi-lock collaborative nighttime guidance system provided in an embodiment of the present invention. Detailed Implementation

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

[0016] With the development of IoT and smart home technologies, smart door locks have been widely used in collective residential areas such as student apartments, factory dormitories, and elderly care facilities. Existing smart door locks typically possess basic capabilities such as identity recognition and network communication, and can work in conjunction with other smart devices (such as sensor lights, service robots, and public restroom access control systems) to expand their application scenarios.

[0017] In collective housing environments, the number of public service facilities (such as public restrooms and public service robots) is typically limited. When multiple users request the same public service at the same time, resource competition can easily arise. Existing solutions often employ the following approaches: 1. Centralized cloud scheduling: Requests are received and resources are allocated uniformly by the cloud server; 2. Central control node scheduling: Scheduling is performed through the central controller in the local area network.

[0018] The above solution has the following shortcomings: 1. Cloud-based scheduling increases network communication overhead and is highly dependent on the network; 2. The central node is prone to becoming a single point of failure; 3. As the number of devices increases, communication congestion and response delays become more pronounced; 4. It is difficult to flexibly support priority preemption strategies based on personnel attributes (such as the elderly or pregnant women).

[0019] Therefore, there is an urgent need for a distributed public resource preemption method that does not require cloud participation or a central node and is completed autonomously by smart locks, in order to reduce network load and improve system real-time performance and robustness.

[0020] This invention first provides a nighttime guidance method using multiple door locks in coordination. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0021] 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 multi-lock collaborative nighttime guidance method 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.

[0022] See Figure 2 The present invention provides a nighttime guidance method for multi-lock coordination, which may include the following steps: S201, Preemption Request Initiation and Multicast Construction: Based on the smart lock's discovery that there are no available public service resources when reserving them, the preemption initiating lock constructs a multicast data packet carrying its own identifier, priority, and preemption intention, and sends it to a preset multicast address; specifically, the preemption request initiation and multicast construction includes: Resource status query: Based on the night-time event triggered by the sensor device, the smart door lock initiates a resource reservation request to the public service facility and receives the current resource occupancy status and a list of door lock identifiers corresponding to the reserved but unused resources; Preemption decision trigger: Based on the query result that the resource occupancy status is no longer available, the preemption decision process for the door lock is triggered; Multicast message construction: Based on the preemption decision, the fields in the standard multicast data message format are extended to encapsulate the unique identifier of the preemption initiator's lock, IP address, MAC address, preemption intent identifier, its own priority, and a list of potential target lock identifiers; Multicast transmission: Send the constructed multicast data packets according to the preset multicast address associated with the public service facility.

[0023] S202, Route priority filtering and targeted forwarding: Based on the multicast data packets received by the router, the priority information is parsed, and a local preset priority mapping table is queried. The packets are then forwarded to all potential target locks with priorities lower than the preemption initiator. Specifically, the route priority filtering and targeted forwarding includes: Message parsing: Based on the message received by the router with the destination address being the preset multicast address, its extended fields are parsed to extract the priority of the preemption initiator and the list of potential target door lock identifiers; Priority mapping table query: Based on the list of potential target door lock identifiers, query the locally stored priority mapping table to obtain the priority value corresponding to each door lock in the list; Target filtering: Filter out all locks in the potential target lock list whose priority value is higher than or equal to the priority of the preemption initiator, and obtain the final target lock list to be forwarded; Targeted multicast forwarding: Based on the final target lock list, forward the multicast data packets from the physical interfaces connecting these target locks.

[0024] S203, Target Lock Local Judgment and Preemption Response: Based on the result of the potential target lock's judgment of its current preemptibility status after receiving the preemption request, a preemption confirmation reply message is generated; specifically, the target lock local judgment and preemption response includes: Preemptible status determination: Based on the preemption request received by the potential target door lock, check the preemptible status of its own maintenance; the status is dynamically set by the door lock according to local events such as whether the associated user has left the room; Decision generation: If the preemptible flag is marked as non-preemptible, the preemption request is discarded and no response is given; if it is preemptible, a preemption confirmation reply message is generated. Reply message construction: The preemption confirmation reply message is a unicast message with the destination address being the IP address of the door lock that initiated the preemption, which carries its own identifier and confirmation information of agreeing to the preemption.

[0025] S204, Route acknowledgment message filtering and first response locking: Based on the router's detection of multiple preemption acknowledgment reply messages sent by potential target locks, only the first arriving reply message is allowed to proceed to the preemption initiator by comparing timestamps, and the identifier of the first responding lock is cached. Simultaneously, other subsequent responding locks are intercepted and notified that the preemption has been confirmed. Specifically, the route acknowledgment message filtering and first response locking includes: First response listening and letting: After forwarding the preemption request, the router starts a listening mechanism for packets from the target door lock side with the destination address being the IP of the preemption initiator, and forwards the first preemption confirmation reply packet normally. First response information caching: While allowing the first reply packet, extract the source IP, source MAC address and corresponding session identifier of the packet and cache them locally on the router; Timer start: After allowing the first reply message to pass, start a timer of a preset duration; Subsequent response interception and notification: Before the timer expires, intercept other preemption confirmation reply messages that are detected and belong to the same preemption session, and construct a notification message to send to the subsequent response lock. The notification message carries the cached first response lock identifier to inform it that the preemption confirmation has been completed by another party. Session termination: After the timer expires, the router stops listening to and processing messages related to the preemption session.

[0026] S205, Preemption Confirmation and Resource Status Update: After the preempting lock receives confirmation from the first responding lock, both parties complete the confirmation interaction. The preempted target lock releases its original resource reservation and notifies the public service facility to update the reservation information, while its own status is updated to waiting. Specifically, the preemption confirmation and resource status update also include: Successful takeover termination: After the takeover initiating lock receives the confirmation reply from the first responding lock, it sends a final confirmation message to the first responding lock to complete the handover of authority; subsequently, the target lock notifies the public service facility to update the resource reservation information, changing the reservation party to the takeover initiating party, and adds itself to the waiting queue for the resource; both locks update the status of their local indicator lights according to the results; No target termination: If the router finds that the final target lock list to be forwarded is empty after filtering in the routing priority filtering and directed forwarding steps, it will directly send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of public service resources and update the indicator light status. No response termination: If the router does not hear any valid preemption confirmation reply after the timer for filtering the routing confirmation message and locking the first response expires, it will send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of the public service resource and update the indicator light status.

[0027] The purpose of this invention is to provide a negotiation method that combines multicast data packets from the terminal with collaborative filtering by routing devices. This method achieves precise matching directly at the network layer, implementing a "bidirectional target matching" approach on the routing side, thereby completing decentralized priority preemption through autonomous negotiation at the terminal side. Compared to unicast chain transmission schemes, this method directly achieves lower latency public resource preemption strategy negotiation at the network layer. This method also enables multiple smart locks to autonomously negotiate and allocate public service resources without cloud-based scheduling, bringing the following benefits and advantages: 1. To achieve efficient and rational use of public service facilities; 2. Support differentiated services for users with different priorities; 3. Reduce communication interference caused by network broadcasting or multicasting; 4. Improve the system's scalability and reliability; 5. Extremely high efficiency and network latency.

[0028] Technical solution: 1. Core idea: The core improvement of this invention lies in the network communication mechanism level, providing a gate priority preemption negotiation method based on the coordination of multicast data packets (carrying priority attributes) and routing device filtering and forwarding. The preemption initiator constructs a multicast data packet carrying a priority attribute field and sends the message to the multicast group. The multicast router filters and selects messages according to a pre-configured "priority mapping table," thus directing the preemption message to potential preemptible targets. When a potential preemptible target replies, the routing device listens and directly allows the first reply, designating the gate of that reply message as the final preemption target. The message is then temporarily cached and sent back to other potential preemptible target gates that may reply. Compared to unicast chaining, this method directly achieves faster negotiation and lower latency public resource preemption negotiation at the network level.

[0029] 2. The complete technical implementation process is as follows: (1) Prerequisites: The system should at least have the following basic requirements: 1. Smart door lock node (Smart door locks are installed and connected to the network in each dormitory room. The door lock can interact with users, recognize user requests, maintain its own status and priority information, and perform preemption judgment through network communication. The door lock has an indicator light that can indicate the preemption result to the user through red and green lights or audio). 2. Sensor-linked devices (including motion-activated nightlights and human body sensors inside the room; these devices can communicate and link with door locks to trigger events such as getting up at night). 3. Access control nodes for public service facilities (such as sensor doors in public restrooms, used to receive lock reservation and occupancy instructions, and to determine their own occupancy and vacancy status, etc.). 4. Communication network (pre-configured multicast communication group); 5. The "priority mapping table" on the router (based on the priority of each lock, the system pre-configures the IP address and priority mapping relationship of each lock on the router so that the router can determine the forwarding based on the priority).

[0030] (2) Procedure under normal conditions: Under normal circumstances, the procedure for someone getting up to use the toilet at night is as follows: 1. The motion-sensor night light detects human activity; 2. The night light sends a notification of nighttime activity to the corresponding smart door lock via the network; 3. The door lock reserves services from the public restroom and its indicator light is set to green; 4. Public restrooms update their availability status and availability data, allowing people to use the restrooms at night; 5. When a person leaves the public restroom after using the toilet at night, the public restroom updates its own availability status and availability data.

[0031] The normal process is now complete. When the total number of people getting up at night does not exceed the number of available public restrooms at the same time, the process for handling nighttime toilet use will always follow the above procedure. When the number of people getting up at night exceeds the number of available public restrooms at the same time, a priority process is required, which is the key content of this invention (as described below).

[0032] (3) Seizure Process (Key Content of this Invention): Step 1: Initiating the preemption request and constructing the multicast data packet message; When dormitory occupants get up at night, the following events occur within the system: 1. The motion-sensor night light detects human activity; 2. The night light sends a notification of nighttime activity to the corresponding smart door lock via the network; 3. The smart door lock allows users to reserve public restroom services and learn that the public restrooms are unavailable; 4. The smart door lock, acting as the originator, constructs a multicast data packet, carrying its own ID, priority, and other information in the extended fields, and sends it to the multicast address corresponding to the public restroom; Taking door lock 001 initiating a preemption request as an example, when door lock 001 reserves service from the public restroom, the public restroom knows from its own status table that there are no available spaces. Table 1 below illustrates the status table of the public restroom: Table 1 ; Note: There are two reservation statuses: unreserved / reserved. There are three usage statuses: in use / unused / released. Because there is a status of unreserved but directly used, when actually grabbing the door lock, it can only grab the reserved but unused resources, indicating that the person has gotten up at night but has not yet used the toilet resources.

[0033] The public restroom, based on the information in the aforementioned status table, reports the current resource status to lock 001, along with information about the stall reservation holders. As shown in the example above, the stalls that have been reserved but not yet used are: locks 011-015. Upon receiving this information, lock 001 sends a multicast data packet to the multicast group. This packet carries lock 001's unique device identifier (Lock_ID_001), its IP address (10.10.10.1), MAC address (00-1A-2B-3C-4D-5E), intent identifier (e.g., 0x01, representing a high-priority initiator preempting a low-priority reserved resource), its own priority (e.g., 2), and the potential preemptible target resources (locks 011-015).

[0034] Step 2: Routing devices perform priority-based directed forwarding; After receiving a multicast data packet, the routing device executes the following logic: 1. After receiving a message, the routing device parses the message source, intent identifier, priority, and other information carried in the message; 2. The routing device matches the message in its own "priority mapping table" and forwards it to all potential target locks with a lower priority than the current preemption source; 3. Send the message to the aforementioned potential targets that can be preempted.

[0035] After receiving the message from door lock 001, the routing device parses the message content. Through the intent identifier 0x01, it discovers that the message's purpose is to perform priority-based resource preemption. The priority information clarifies that the preemption source's priority is 2. Therefore, the router matches priority 2 with its own "priority mapping table," an example of which is shown in Table 2 below. Table 2 ; Based on this mapping table, the router determines that among the potential preemptible targets (locks 011-015), after priority filtering, the actual potential preemptible targets are locks 013-015. Therefore, the router forwards the preemption message to locks 013, 014, and 015. The message also carries information such as the lock ID, IP address, and MAC address of the preemption source lock 001 to facilitate subsequent communication between the target lock and the source lock.

[0036] Step 3: Local assessment and response to potential preemption of target door locks; When a potential target lock receives a preemption request forwarded via a route, the following logic is executed: 1. Determine whether the current state of the lock allows it to be preempted (e.g., if the user has left the house, the lock will set its state to non-preemptible; if the user has not yet left the house, the lock will set its state to preemptible). 2. If it is determined that the content cannot be preempted, then ignore the message. 3. If it is determined that the public service resources can be preempted, then proceed to the process of releasing public service resources reservation (step four).

[0037] After receiving the preemption message from the router, door locks 013, 014, and 015 will actually perform the same processing. The following explanation uses door lock 015 as an example: Door lock 015 only needs to check its own preemptibility flag. If it is currently "non-preemptible" (meaning the person has already left or other non-preemptible factors are being triggered), door lock 015 ignores the message and does not perform any processing; if the current flag is "preemptible," it proceeds to the next step. Similarly, door locks 013 and 014 will perform the same judgment and processing.

[0038] Step 4: Filtering process for preemption confirmation messages of potential target door locks; When a door lock determines that it can be preempted: 1. Send a confirmation message to the source door lock to confirm the preemption; 2. The status and permissions for resource reservations will not be released or updated at this time; confirmation will be made after a response is received. 3. After the router detects a message, it only allows the first message to arrive and caches the IP and MAC addresses of the terminal lock that sent the first message. (By caching the information of the first replying lock, it informs other locks that the confirmation message has been sent by someone else first, as detailed below.) 4. Set a timer (e.g., 3 seconds) for the router to wait for other door locks to reply with a preemption confirmation message; 5. After other locks reply with the preemption confirmation message (which is not the first reply), the router intercepts it and sends the IP and MAC address of the lock that first replied in the cache to these subsequent locks in the form of a data packet (that is, to tell the other locks that someone has already replied to the preemption confirmation message). 6. Once the routing wait timer expires, it will no longer accept preemption confirmation messages for that session.

[0039] Taking the example where both locks 014 and 015 confirm their ability to preempt the resource, they will both reply with a preemption confirmation message to the source lock. The router only allows the first message sent (assuming lock 014 sends it first). That is, lock 014's preemption confirmation message has been sent to the source lock 001. At this point, the router synchronously caches lock 014's IP address and MAC address locally and starts a timer. Before the timer expires, lock 015 also sends a preemption confirmation message. The router detects this, intercepts the message (i.e., only allows the first reply message), and replies to lock 015 with lock 014's IP and MAC address in a datagram, notifying lock 014 that the preemption confirmation has been completed. Afterward, the router terminates the resource preemption session after the timer expires.

[0040] Step 5: Update the reservation status of the target door lock that has been seized; Once the target lock that was finally captured successfully sends the message to the capture source: 1. The unicast reply "OK" from the source lock confirmed the handover of permissions between the two parties; 2. The target door lock being seized notifies public service resources to update the previously scheduled seizure party to the current seizure source; 3. Public restrooms will be placed on a pre-arranged queue for those who have been scrambling to use them, and users will be notified when the restrooms become available.

[0041] 4. The target door lock that has been seized updates the display status of its indicator light (turns red) to notify the user that they need to wait; After door lock 014 successfully sends a pre-booking confirmation message to the pre-booking source door lock 001, door lock 001 replies with "OK". Door lock 014 then notifies the public restroom to update its previous reservation information, changing the reservation source from itself to door lock 001. After updating the relevant information, the public restroom adds door lock 014 to the reservation queue list so it can be notified when it becomes available. Door lock 014 then updates its indicator light to red to indicate that the user needs to wait.

[0042] Note: Preemptive termination condition.

[0043] The preemption message will automatically terminate when the following conditions are met: 1. The target has been confirmed, meaning the target door lock has been confirmed by both parties (step five). 2. There is no potential target to preempt (i.e., the route cannot find a target to preempt in the "priority mapping table", in which case the route directly replies with a preemption source termination message); 3. None of the potential preemptible targets responded (i.e., after the route sends the preemption message to the potential target, it does not receive any response within the timeout period, and at this time the route directly replies with the preemption source termination message).

[0044] After the event concludes, the system updates its status based on the result and provides feedback to the user via indicator lights and sounds. If no user successfully grabs a spot, the public restroom adds them to a pre-booked queue and notifies them when a spot becomes available.

[0045] In the example of step five above, door lock 001 has successfully preempted the target door lock 014, thus the preemption process ends after step five. If, in step two, the router queries the "priority mapping table" and finds no lower-priority target available, it directly replies to door lock 001 with a preemption failure message. Upon receiving this message, door lock 001 displays a red light on its device, indicating that the user needs to wait. Door lock 001's reservation message will be registered in the public restroom's reservation queue list, awaiting notification when a public restroom becomes available. If, in step three, the preemptibility flags for door locks 013-015 are all "unpreemptible," then no door locks will reply. After the message wait timeout, the router notifies door lock 001 of a preemption failure message. Upon receiving this message, door lock 001 displays a red light on its device, indicating that the user needs to wait. Door lock 001's reservation message will be registered in the public restroom's reservation queue list, awaiting notification when a public restroom becomes available.

[0046] Beneficial effects: Compared with existing technologies, this method has the following advantages and beneficial effects: 1. No cloud-based scheduling required, reducing network and central dependency; 2. Employ multicast or unicast communication with limited filtering to reduce broadcast storms in the network; 3. Supports distributed priority preemption to avoid central node failure; 4. Improve the utilization rate of public resources; 5. Flexibly adapt to the different priority needs of users, improving system scalability and flexibility; 6. Negotiation and judgment are performed directly at the network layer, improving system efficiency.

[0047] Innovation points: 1. Extended multicast datagram messages use extended fields to carry intent, priority, etc., to negotiate and determine the routing level; 2. A "priority mapping table" pre-configured on the router is used in conjunction with multicast data packets to perform priority filtering and judgment; 3. When multiple confirmation messages are received, the routing system listens for and selects only the first reply to proceed, based on the reply time. 4. At the same time, the router will also cache the information of the first replying terminal and then notify other subsequent terminals to claim the reply that has been confirmed by others.

[0048] Another embodiment of the present invention provides a nighttime guidance system with multi-door lock coordination, see [link to relevant documentation]. Figure 3 The system may include: Initiation module 301 is used for preemption request initiation and multicast construction: based on the state that the smart lock finds that the resources are not available when reserving public service resources, the preemption initiator lock constructs a multicast data message carrying its own identifier, priority and preemption intention, and sends it to the preset multicast address; The filtering module 302 is used for route priority filtering and targeted forwarding: based on the multicast data packets received by the router, it parses the priority information in the packets, queries the local preset priority mapping table, and forwards the packets to all potential target locks with lower priority than the preemption initiator. The judgment module 303 is used for local judgment and preemption response of the target door lock: based on the result of the potential preempted target door lock judging its current preemption status after receiving the preemption request, it generates a preemption confirmation reply message; The filtering module 304 is used for routing confirmation message filtering and first response locking: based on the preemption confirmation reply messages sent by multiple potential target locks detected by the router, it only allows the first reply message to arrive to the preemption initiator by comparing the timestamps, and caches the identifier of the first response lock, while intercepting and notifying other subsequent response locks that the preemption has been confirmed; The confirmation module 305 is used for preemption confirmation and resource status update: After the preemption initiating lock receives the confirmation reply from the first responding lock, the two parties complete the confirmation interaction. The preempted target lock releases the original resource reservation and notifies the public service facility to update the reservation information. At the same time, its own status is updated to waiting.

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

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

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

[0052] 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 nighttime guidance method using multiple locks in coordination, characterized in that, The method includes: Preemption Request Initiation and Multicast Construction: Based on the smart lock's discovery that no public service resources are available when reserving them, the preemption initiating lock constructs a multicast data packet carrying its own identifier, priority, and preemption intention, and sends it to a preset multicast address. The preemption request initiation and multicast construction includes: Resource Status Query: Based on a nighttime event triggered by a sensor, the smart lock initiates a resource reservation request to the public service facility and receives the returned current resource occupancy status and a list of lock identifiers corresponding to reserved but unused resources; Preemption Decision Trigger; Multicast Packet Construction; Multicast Transmission; Routing priority filtering and targeted forwarding: Based on the multicast data packets received by the router, the priority information in the packets is parsed, and the local preset priority mapping table is queried. The packets are then forwarded to all potential target locks whose priority is lower than that of the preemption initiator. Local judgment and preemption response of target door lock: Based on the result of the potential target door lock judging its current preemption status after receiving the preemption request, a preemption confirmation reply message is generated; Routing acknowledgment message filtering and first response locking: Based on the router's detection of preemption acknowledgment reply messages from multiple potential target locks, only the first arriving reply message is allowed to proceed to the preemption initiator by comparing timestamps, and the identifier of the first responding lock is cached. Simultaneously, other subsequent responding locks are intercepted and notified that the preemption has been confirmed. The routing acknowledgment message filtering and first response locking includes: First response listening and allowing: After forwarding the preemption request, the router initiates a listening mechanism for packets originating from the target lock side with a destination address equal to the preemption initiator's IP address. The first detected preemption acknowledgment reply packet is forwarded normally; first response information... Caching: Upon allowing the first reply packet, the router extracts the source IP, source MAC address, and corresponding session identifier of the packet and caches them locally. Timer Start: After allowing the first reply packet, a timer of a preset duration is started. Subsequent Response Interception and Notification: Before the timer expires, other preemption acknowledgment reply packets belonging to the same preemption session are intercepted, and a notification packet is constructed and sent to the subsequent response gate. The notification packet carries the cached first response gate identifier, informing it that the preemption acknowledgment has been completed by another party. Session Termination: After the timer expires, the router terminates the listening and processing of messages for the preemption session. Confirmation of preemption and update of resource status: After the door lock that initiates the preemption receives the confirmation reply from the first responding door lock, the two parties complete the confirmation interaction. The target door lock that was preempted releases the original resource reservation and notifies the public service facility to update the reservation information. At the same time, its own status is updated to waiting.

2. The method according to claim 1, characterized in that, The preemption request initiation and multicast construction include: Based on the query result that the resource occupancy status is no longer available, the door lock preemption decision process is triggered; Based on the preemption decision, the standard multicast data packet format is extended with fields to encapsulate the unique identifier of the preemption initiator's lock, IP address, MAC address, preemption intent identifier, its own priority, and a list of potential target lock identifiers. The constructed multicast data packets are sent according to the preset multicast address associated with the public service facility.

3. The method according to claim 2, characterized in that, The route priority filtering and redirection include: Message parsing: Based on the message received by the router with the destination address being the preset multicast address, its extended fields are parsed to extract the priority of the preemption initiator and the list of potential target door lock identifiers; Priority mapping table query: Based on the list of potential target door lock identifiers, query the locally stored priority mapping table to obtain the priority value corresponding to each door lock in the list; Target filtering: Filter out all locks in the potential target lock list whose priority value is higher than or equal to the priority of the preemption initiator, and obtain the final target lock list to be forwarded; Targeted multicast forwarding: Based on the final target lock list, forward the multicast data packets from the physical interfaces connecting these target locks.

4. The method according to claim 3, characterized in that, The target door lock local determination and preemption response include: Preemptible status determination: Based on the preemption request received by the potential target door lock, check the preemptible status of its own maintenance; the status is dynamically set by the door lock according to whether the associated user has left the room. Decision generation: If the preemptible flag is marked as non-preemptible, the preemption request is discarded and no response is given; if it is preemptible, a preemption confirmation reply message is generated. Reply message construction: The preemption confirmation reply message is a unicast message with the destination address being the IP address of the door lock that initiated the preemption, which carries its own identifier and confirmation information of agreeing to the preemption.

5. The method according to claim 4, characterized in that, The preemption confirmation and resource status update also include: Successful takeover termination: After the takeover initiating lock receives the confirmation reply from the first responding lock, it sends a final confirmation message to the first responding lock to complete the handover of authority; subsequently, the target lock notifies the public service facility to update the resource reservation information, changing the reservation party to the takeover initiating party, and adds itself to the waiting queue for the resource; both locks update the status of their local indicator lights according to the results; No target termination: If the router finds that the final target lock list to be forwarded is empty after filtering in the routing priority filtering and directed forwarding steps, it will directly send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of public service resources and update the indicator light status. No response termination: If the router does not hear any valid preemption confirmation reply after the timer for filtering the routing confirmation message and locking the first response expires, it will send a preemption failure notification to the preemption initiating lock via unicast. After receiving the notification, the preemption initiating lock will add itself to the waiting queue of the public service resource and update the indicator light status.

6. A multi-lock coordinated nighttime guidance system, characterized in that, The system includes: The initiation module is used for preemption request initiation and multicast construction: Based on the smart lock's discovery that no public service resources are available when reserving them, the initiating lock constructs a multicast data packet carrying its own identifier, priority, and preemption intention, and sends it to a preset multicast address. The preemption request initiation and multicast construction include: resource status query: based on a nighttime event triggered by a sensor, the smart lock initiates a resource reservation request to the public service facility and receives the returned current resource occupancy status and a list of lock identifiers corresponding to reserved but unused resources; preemption decision triggering; multicast packet construction; and multicast transmission. The filtering module is used for route priority filtering and targeted forwarding: based on the multicast data packets received by the router, it parses the priority information in the packets, queries the local preset priority mapping table, and forwards the packets to all potential target locks with lower priority than the preemption initiator. The judgment module is used for local judgment and preemption response of the target door lock: based on the result of the potential preempted target door lock judging its current preemption status after receiving the preemption request, it generates a preemption confirmation reply message; The filtering module is used for route confirmation message filtering and first response locking: based on the router's detection of multiple preemption confirmation reply messages sent by potential target locks, it compares timestamps and only allows the first arriving reply message to be passed to the preemption initiator, and caches the identifier of the first responding lock, while intercepting and notifying other subsequent responding locks that the preemption has been confirmed; wherein, the route confirmation message filtering and first response locking includes: first response listening and passing: after forwarding the preemption request, the router starts a listening mechanism for packets from the target lock side with the destination address being the preemption initiator's IP, and forwards the first preemption confirmation reply packet normally; Response information caching: While allowing the first reply packet, the source IP, source MAC address, and corresponding session identifier of the packet are extracted and cached locally on the router; Timer start: After allowing the first reply packet, a timer of preset duration is started; Subsequent response interception and notification: Before the timer expires, other preemption confirmation reply packets belonging to the same preemption session are intercepted, and a notification packet is constructed and sent to the subsequent response gate. The notification packet carries the cached first response gate identifier, informing it that the preemption confirmation has been completed by another party; Session termination: After the timer expires, the router terminates the listening and processing of messages for this preemption session; The confirmation module is used for preemption confirmation and resource status update: After the preempting door lock receives the confirmation reply from the first responding door lock, the two parties complete the confirmation interaction. The preempted target door lock releases the original resource reservation and notifies the public service facility to update the reservation information. At the same time, its own status is updated to waiting.

7. The system according to claim 6, characterized in that, The initiating module is specifically used for: Based on the query result that the resource occupancy status is no longer available, the door lock preemption decision process is triggered; Based on the preemption decision, the standard multicast data packet format is extended with fields to encapsulate the unique identifier of the preemption initiator's lock, IP address, MAC address, preemption intent identifier, its own priority, and a list of potential target lock identifiers. The constructed multicast data packets are sent according to the preset multicast address associated with the public service facility.

8. 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.

9. 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