Lock device failure handling method, device, medium and product

Abstract

The present disclosure relates to the technical field of communication, and in particular provides a fault processing method and device of a lock equipment, a medium and a product, comprising: in the case of determining that a target lock equipment exists a communication fault, acquiring a communication state parameter of a lock equipment in a surrounding area of the target lock equipment; calculating an assistance priority according to the communication state parameter of a candidate lock equipment in an available state in the lock equipment; wherein the assistance priority is used to indicate a success probability of the candidate lock equipment uploading working data of the target lock equipment to a data platform; determining a first assistance lock equipment of the target lock equipment in the candidate lock equipment based on the assistance priority, and uploading abnormal working data of the target lock equipment through the first assistance lock equipment; wherein the abnormal working data is used to indicate working data that is not successfully sent to the data platform in a communication fault state, thereby improving the fault processing efficiency of the target lock equipment.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and more specifically, to a fault handling method, device, medium, and product for a lock device. Background Technology

[0002] In the field of smart locks, the lock status of the lock device can be remotely controlled and monitored. However, due to problems such as poor network signal and low battery power, the lock device cannot communicate with the network, thus affecting the normal use of the lock device.

[0003] In related technologies, a backup communication module is added to the lock device so that the lock device can upload the data to be sent through the backup communication module in the event of a communication failure. However, due to incompatibility issues between the backup communication module and the lock device, the backup communication module cannot replace the lock device in uploading the data to be sent, thereby affecting the efficiency of fault handling for the lock device. Summary of the Invention

[0004] This disclosure is made in view of the above-mentioned problems. This disclosure provides a method, apparatus, device, medium, and product for troubleshooting lock devices.

[0005] According to one aspect of this disclosure, a fault handling method for a lock device is provided, comprising:

[0006] If a communication failure is determined in the target lock device, obtain the communication status parameters of the lock devices in the surrounding area of ​​the target lock device;

[0007] Based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices, the assistance priority is calculated; wherein, the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform;

[0008] Based on the assistance priority, a first assisting lock device is determined from the candidate lock devices for the target lock device, and abnormal working data of the target lock device is uploaded through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under communication failure conditions.

[0009] Furthermore, according to one aspect of this disclosure, calculating assistance priority based on communication status parameters of candidate lock devices that are in an available state in the lock device includes:

[0010] Candidate lock devices that meet the target lock characteristics are selected from the lock devices; wherein, the target lock characteristics are used to indicate that the lock device is in an available state;

[0011] The communication status parameters of the candidate lock devices are weighted and summed to obtain the assistance priority of the candidate lock devices.

[0012] Furthermore, according to one aspect of this disclosure, the method further includes:

[0013] If it is determined that there are no candidate lock devices in a usable state among the lock devices, a transfer lock device is determined among the lock devices; wherein, the number of lock devices contained in the area surrounding the transfer lock device meets a preset number requirement;

[0014] The target lock device uploads abnormal operating data of the target lock device to the transfer lock device.

[0015] If the transfer lock device fails to upload the abnormal working data a certain number of times consecutively, a second assisting lock device for the target lock device is identified among the lock devices in the area surrounding the transfer lock device.

[0016] The abnormal operation data is uploaded through the second assist lock device.

[0017] Furthermore, determining a communication failure in the target lock device according to one aspect of this disclosure includes:

[0018] Once it is determined that the target lock device has successfully connected to the target communication network, the target lock device is controlled to upload each set of working data to be sent in the data chain list;

[0019] If the target lock device fails to upload each set of working data, the number of consecutive failures of the target lock device to upload each set of working data is counted.

[0020] If the number of consecutive failures of the working data is greater than a first threshold, it is determined that the target lock device has a communication fault.

[0021] Furthermore, according to one aspect of this disclosure, the method further includes:

[0022] If the target lock device successfully uploads each set of working data, the successfully sent working data is deleted from the data chain list.

[0023] Furthermore, according to one aspect of this disclosure, uploading abnormal operating data of the target lock device through the first assisting lock device includes:

[0024] After establishing the connection between the target lock device and the first assisting lock device, the abnormal operation data is uploaded through the first assisting lock device;

[0025] If the abnormal working data is successfully acquired, a message indicating that the abnormal working data was successfully sent is sent to the target lock device.

[0026] Furthermore, according to one aspect of this disclosure, the method further includes:

[0027] If the abnormal working data is not successfully obtained, a retry request sent by the first assisting lock device is obtained; wherein the retry request carries the number of consecutive failures of the first assisting lock device to send the abnormal working data;

[0028] If the retry request determines that the first assisting lock device meets the retry sending conditions, the number of retry sending attempts is fed back to the first assisting lock device.

[0029] According to another aspect of this disclosure, a fault handling apparatus for a lock device is provided, comprising:

[0030] The acquisition unit is used to acquire communication status parameters of lock devices in the surrounding area of ​​the target lock device when it is determined that the target lock device has a communication failure;

[0031] The processing unit is configured to calculate an assistance priority based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices; wherein the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform;

[0032] The device determination unit is configured to determine a first assisting lock device for the target lock device among the candidate lock devices based on the assistance priority, and to upload abnormal working data of the target lock device through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under communication failure conditions.

[0033] According to another aspect of this disclosure, an electronic device is provided, comprising: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps in the fault handling method of the lock device described above are performed.

[0034] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, performs the steps in the fault handling method for the lock device described above.

[0035] According to another aspect of this disclosure, a computer program product is provided, which is stored in a storage medium and executed by at least one processor to implement the steps in the fault handling method for the lock device described above.

[0036] As will be described in detail below, the fault handling method, apparatus, device, medium, and product of the lock device according to embodiments of this disclosure firstly, when it is determined that the target lock device has a communication failure, the communication status parameters of lock devices in the surrounding area of ​​the target lock device are obtained; then, based on the communication status parameters of candidate lock devices that are in an available state, an assistance priority is calculated; wherein, the assistance priority is used to indicate the success probability of the candidate lock devices uploading the working data of the target lock device to the data platform; finally, based on the assistance priority, a first assisting lock device of the target lock device is determined from the candidate lock devices, and the abnormal working data of the target lock device is uploaded through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under the communication failure state. By calculating the assistance priority based on the communication status parameters of the candidate lock devices and determining the first assisting lock device based on the assistance priority, the compatibility between the first assisting lock device and the target lock device is improved, and the abnormal working data of the target lock device is uploaded through the first assisting lock device, thereby improving the fault handling efficiency of the target lock device.

[0037] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0038] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0039] Figure 1 This is a flowchart illustrating a fault handling method for a lock device according to an embodiment of the present disclosure.

[0040] Figure 2 This is a further illustration of a flowchart for determining a second assist lock device according to an embodiment of the present disclosure.

[0041] Figure 3 This is a flowchart illustrating the failure to successfully obtain abnormal working data according to an embodiment of the present disclosure.

[0042] Figure 4 This is a system architecture diagram of a lock device system according to an embodiment of the present disclosure.

[0043] Figure 5 This is a flowchart further illustrating the process of determining that the target lock device has a communication failure, according to an embodiment of the present disclosure.

[0044] Figure 6 This is a flowchart further illustrating the fault handling process of the lock device according to an embodiment of the present disclosure.

[0045] Figure 7 This is a flowchart further illustrating the process of uploading abnormal working data of the target lock device through the first assisting lock device according to an embodiment of the present disclosure.

[0046] Figure 8 This is a block diagram illustrating a fault handling apparatus for a lock device according to an embodiment of the present disclosure.

[0047] Figure 9 This is a hardware block diagram illustrating an electronic device according to an embodiment of the present disclosure.

[0048] Figure 10 This is a schematic diagram illustrating a computer program product according to an embodiment of the present disclosure. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0050] To facilitate understanding of this embodiment, a fault handling method for a lock device disclosed in this disclosure will first be described in detail. The execution subject of the fault handling method for a lock device provided in this disclosure is generally an electronic device with a certain computing capability, such as a terminal device, a server, or other processing device. In some possible implementations, the fault handling method for the lock device can be implemented by a processor calling computer-readable instructions stored in memory.

[0051] See Figure 1 The diagram shows a flowchart of a fault handling method for a lock device provided in an embodiment of this disclosure. The method includes steps S101 to S103, wherein:

[0052] Step S101: If it is determined that the target lock device has a communication failure, obtain the communication status parameters of the lock devices in the surrounding area of ​​the target lock device.

[0053] Here, the communication status parameters include the lock device's model, device identifier, device power, device communication quality, and the number of surrounding lock devices. The lock device can be a door lock device, but this application does not require it to be one.

[0054] Among them, the device model is used to indicate whether the lock device has the function of assisting in uploading data; the device identifier is used to distinguish specific lock devices (e.g., device IMEI number); the device battery level is used to indicate whether the lock device can upload data to the data platform; the device communication quality is used to indicate the communication status and communication signal quality of the lock device (e.g., Carrier to Signal Quality (CSQ) and Received Signal Strength Indicator (RSSI)); and the number of surrounding lock devices is used to indicate the number of lock devices in the surrounding area.

[0055] The device model and device identifier are updated when the lock device is in working condition. The device power and device communication quality are updated after each time the lock device uploads working data. The number of surrounding lock devices can be updated according to a preset time period, for example, a week.

[0056] In this embodiment of the application, when the data platform determines that the target lock device has a communication failure, the data platform sends a communication failure message to the target lock device. After receiving the message, the target lock device scans the lock devices in the surrounding area of ​​the target lock device through the Bluetooth module of the target lock device and uploads the communication status parameters of the lock device to the data platform.

[0057] Step S102: Calculate the assistance priority based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices; wherein, the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform.

[0058] In this embodiment of the application, after obtaining the communication status parameters, the data platform filters candidate lock devices that are in an available state among the lock devices according to the communication status parameters, and calculates the assistance priority, that is, the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform according to the communication status parameters of the candidate lock devices in an available state.

[0059] Step S103: Based on the assistance priority, determine the first assisting lock device of the target lock device among the candidate lock devices, and upload the abnormal working data of the target lock device through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under the condition of communication failure.

[0060] In this embodiment, the data platform selects the candidate lock device with the highest assistance priority as the first assisting lock device for the target lock device based on the assistance priority of the candidate lock devices, and uploads the abnormal working data of the target lock device through the first assisting lock device.

[0061] In addition, the first assisting lock device of the target lock device can be selected from the candidate lock devices according to the communication status parameters.

[0062] For example, the first assisting lock device can be determined based on the communication signal quality (e.g., CSQ and RSSI) and device power in the communication status parameters: First, the lock device with the highest CSQ is selected from the candidate lock devices in the available state; then, the lock device with the highest RSSI is selected from the lock devices with the highest CSQ; finally, the lock device with sufficient device power (i.e., the first assisting lock device) is selected from the lock devices with the highest RSSI.

[0063] In the above embodiments, the assistance priority is calculated by the communication status parameters of the candidate lock devices, and the method of the first assisting lock device is determined according to the assistance priority, thereby improving the compatibility between the first assisting lock device and the target lock device, and the abnormal working data of the target lock device is uploaded through the first assisting lock device, thereby improving the efficiency of fault handling of the target lock device.

[0064] In an optional implementation, the above step, based on the communication status parameters of candidate lock devices that are in an available state among the lock devices, calculates the assistance priority, including:

[0065] Candidate lock devices that meet the target lock characteristics are selected from the lock devices; wherein, the target lock characteristics are used to indicate that the lock device is in an available state;

[0066] The communication status parameters of the candidate lock devices are weighted and summed to obtain the assistance priority of the candidate lock devices.

[0067] Here, the target lock features are used to indicate that the lock device is in an available state, such as the lock device's battery level being higher than a preset battery threshold, normal communication status, and good communication signal quality (CSQ or RSSI being higher than the preset battery threshold).

[0068] In this embodiment of the application, the data platform filters candidate lock devices that meet the target lock characteristics based on the characteristics of the target lock and the communication status parameters of the lock devices, and performs weighted summation on the communication status parameters of the candidate lock devices to obtain the assistance priority of the candidate lock devices.

[0069] See Figure 2 The flowchart shown is a method for determining a second assist lock device according to an embodiment of this disclosure, including the following steps:

[0070] Step S201: If it is determined that there are no candidate lock devices in an available state among the lock devices, a transfer lock device is determined among the lock devices; wherein, the number of lock devices contained in the area surrounding the transfer lock device meets a preset number requirement;

[0071] Step S202: Upload the abnormal operation data of the target lock device to the transfer lock device through the target lock device;

[0072] Step S203: If the transfer lock device fails to upload the abnormal working data a certain number of times consecutively, determine the second assisting lock device of the target lock device among the lock devices in the area surrounding the transfer lock device;

[0073] Step S204: Upload the abnormal operation data through the second assist lock device.

[0074] Here, the lock device with the largest number of surrounding lock devices can be determined as the transfer lock device based on the number of surrounding lock devices. Alternatively, the lock device whose number of surrounding lock devices meets the preset quantity requirement (i.e., the number of lock devices contained in the surrounding area meets the preset quantity requirement) can be determined as the transfer lock device. This application does not make such a requirement.

[0075] Here, the second assisting lock device is a lock device that meets the characteristics of the target door lock in the area surrounding the transfer lock device.

[0076] In this embodiment, when no candidate lock device is available among the lock devices, the data platform determines a relay lock device based on the number of lock devices surrounding the target lock device. After establishing a network connection between the relay lock device and the target lock device, the target lock device uploads abnormal working data of the target lock device to the relay lock device. After the target lock device uploads the abnormal working data, the network connection between the relay lock device and the target lock device is disconnected, and the relay lock device uploads the abnormal working data to the data platform. If the relay lock device fails to upload abnormal working data to the data platform a certain number of times consecutively, a second assisting lock device for the target lock device is determined from the lock devices in the area surrounding the relay lock device. After receiving the abnormal working data uploaded by the relay lock device, the second assisting lock device uploads the abnormal working data to the data platform.

[0077] In addition, a preset upload failure threshold can be set for the transfer lock device. If the number of upload failures of the transfer lock device to upload abnormal working data to the data platform (i.e., the number of consecutive target number of times the transfer lock device fails to upload abnormal working data to the data platform) is less than or equal to the upload failure threshold, then the second assisting lock device of the target lock device is determined among the lock devices in the area surrounding the transfer lock device.

[0078] In this embodiment of the application, when there is no lock device (i.e., second assisting lock device) that meets the characteristics of the target door lock in the surrounding area of ​​the transfer lock device, the data platform controls the transfer lock device to upload abnormal working data to the dense area of ​​lock devices in the surrounding area of ​​the transfer lock device, and determines the second assisting lock device of the target lock device in the dense area of ​​lock devices.

[0079] In an optional implementation, the above steps to determine that the target lock device has a communication failure specifically include the following steps:

[0080] Once it is determined that the target lock device has successfully connected to the target communication network, the target lock device is controlled to upload each set of working data to be sent in the data chain list;

[0081] If the target lock device fails to upload each set of working data, the number of consecutive failures of the target lock device to upload each set of working data is counted.

[0082] If the number of consecutive failures of the working data is greater than a first threshold, it is determined that the target lock device has a communication fault.

[0083] Here, the first threshold is the maximum number of failures for the target lock device to upload working data, which can be configured according to the power consumption strategy of the target lock device. This application does not require this.

[0084] In this embodiment of the application, when the data platform determines that the target lock device has successfully connected to the target communication network, after receiving the successful connection result sent by the data platform, the target lock device randomly generates a data identifier (e.g., a work data id) for the work data to be sent, and backs up the data identifier and the corresponding work data to the data list of the target lock device. The target lock device then uploads each set of work data to be sent to the data platform according to the data list.

[0085] In this embodiment of the application, after the target lock device uploads each set of working data to be sent to the data platform, if the data platform determines that the target lock device has failed to upload each set of working data, it counts the number of consecutive failures of the target lock device to upload each set of working data. If the number of consecutive failures is greater than a first threshold, it determines that the target lock device has a communication failure.

[0086] In addition, in this embodiment, the target lock device initiates a network connection request to the data platform. If the data platform determines that the target lock device's network connection has failed (i.e., it has not successfully connected to the target communication network) based on the network connection request, it detects the number of retries the target lock device can re-initiate the network connection request. If the number of retries meets the retry conditions (e.g., the number of retries meets the retry threshold), the target lock device re-initiates the network connection request to the data platform. If the number of retries does not meet the retry conditions, it is determined that the target lock device has a communication failure.

[0087] In an optional implementation, if the target lock device successfully uploads working data, the following steps are included:

[0088] If the target lock device successfully uploads each set of working data, the successfully sent working data is deleted from the data chain list.

[0089] In this embodiment of the application, when the data platform determines that the target lock device has successfully uploaded each set of working data, it deletes the successfully sent working data according to the data identifier in the data chain list.

[0090] In addition, it can detect whether there is any unsent working data in the data chain (e.g., newly backed-up working data in the data chain). If it is determined that there is unsent working data in the data chain, the working data is resent to the data platform.

[0091] In this embodiment of the application, after receiving each set of working data uploaded by the target lock device, the data platform can also send new working data (e.g., password, NFC, fingerprint key) to the target lock device, and the target lock device updates the working data according to the new working data.

[0092] In an optional implementation, the above steps, which involve uploading abnormal operating data of the target lock device through the first assisting lock device, specifically include the following steps:

[0093] After establishing the connection between the target lock device and the first assisting lock device, the abnormal operation data is uploaded through the first assisting lock device;

[0094] If the abnormal working data is successfully acquired, a message indicating that the abnormal working data was successfully sent is sent to the target lock device.

[0095] In this embodiment, the target lock device sends a connection request to the first assisting lock device. The first assisting lock device establishes a connection between the target lock device and the first assisting lock device according to the connection request. The target lock device uploads abnormal working data and the data identifier corresponding to the abnormal working data to the first assisting lock device. After receiving the abnormal working data, the first assisting lock device uploads the abnormal working data and the data identifier to the data platform.

[0096] In addition, after the first assisting lock device uploads the abnormal working data to the data platform, the connection between the first assisting lock device and the target lock device is maintained, so that the working data newly backed up by the target lock device to the data chain list can be uploaded to the data platform through the first assisting lock device.

[0097] In this embodiment of the application, when the data platform successfully obtains abnormal working data, it sends a message to the target lock device that the abnormal working data has been successfully sent. Alternatively, the first assisting lock device can send a message to the target lock device that the abnormal working data has been successfully sent. After receiving the message that the abnormal working data has been successfully sent, the target lock device deletes the successfully sent abnormal working data from the data chain list according to the data identifier of the abnormal working data.

[0098] See Figure 3 The flowchart shown is a process for unsuccessfully obtaining abnormal working data according to an embodiment of this disclosure, including the following steps:

[0099] Step S301: If the abnormal working data is not successfully obtained, obtain the retry request sent by the first assisting lock device; wherein, the retry request carries the number of consecutive failures of the first assisting lock device to send the abnormal working data;

[0100] Step S302: If it is determined that the first assisting lock device meets the retry sending conditions based on the retry request, the number of retry sending times is fed back to the first assisting lock device.

[0101] In this embodiment, if the data platform fails to obtain abnormal working data, the first assisting lock device sends a retry request to the data platform. Based on the retry request, if the data platform determines that the first assisting lock device meets the retry sending conditions (e.g., the number of consecutive failed attempts to send abnormal working data by the first assisting lock device meets the retry sending threshold), the data platform sends the number of retry sending requests back to the first assisting lock device. After receiving the number of retry requests from the data platform, the first assisting lock device re-uploads the abnormal working data to the data platform.

[0102] In addition, if the data platform determines that the first assisting lock device does not meet the retry transmission conditions, it will send a message to the target lock device that the abnormal working data transmission failed. After receiving the message, the target lock device will store the abnormal working data in the data linked list and wait for the target lock device to have no communication failure or to re-upload the abnormal working data to the data platform after a preset period.

[0103] See Figure 4 The diagram shown is a system architecture diagram of a lock device system provided in this application. The lock device system includes a control module and peripheral modules. The peripheral modules include a motor module, a cellular communication module, a Bluetooth module, a fingerprint module, an NFC module, an interaction module, and a power module.

[0104] The motor module is used to receive command signals from the control module and control the lock device to execute unlocking or locking commands according to the command signals.

[0105] The cellular communication module is mainly used for cellular communication between the lock device and the data platform, that is, to upload the lock device's working data to the data platform or to receive new working data sent by the data platform.

[0106] The Bluetooth module is used to periodically broadcast within the area surrounding the lock device, making it easier to discover surrounding Bluetooth broadcasts and thus discover the lock devices contained within the area surrounding the lock device.

[0107] The fingerprint module is used to identify the fingerprint of the user to whom the lock device belongs.

[0108] The NFC module is used to detect whether the user of the lock device has an unlocking card and to read the unlocking card.

[0109] The interaction module includes a display screen and a numeric keypad, which support interactive operations between the user of the lock device and the lock device, such as the user entering the device password or the user accessing the device menu.

[0110] The power supply module is used to supply power to the control module and peripheral modules in the lock equipment system.

[0111] The control module is used to control the power supply switch of the power module to the peripheral modules.

[0112] When the lock system is functioning normally, the lock device or the user terminal of the user to which the lock device belongs will upload working data to the data platform under the following circumstances:

[0113] 1. When the user of the lock device unlocks the device using one of the three unlocking modes: keypad, NFC, or fingerprint, a corresponding unlocking record is generated. The control module packages the unlocking record and transmits the processed unlocking record to the cellular communication module. Then, the cellular communication module uploads the processed unlocking record to the data platform.

[0114] 2: During a specified time period, the control module automatically initiates a synchronization request to the data platform. The synchronization request is used to upload the historical unlocking records of the lock device and the working data in the data chain to the data platform, and to query the data platform whether a new version of the lock device exists.

[0115] 3: The user of the lock device connects via Bluetooth through a mini-program, and after successful Bluetooth connection, user authentication and verification are performed to unlock the device. The unlocking record generated after unlocking is transmitted to the user terminal of the user of the lock device via the Bluetooth module, and the user terminal uploads the unlocking record to the data platform.

[0116] When the target lock device is in a weak network environment or has low battery, it may experience problems such as failure to upload working data, inability to support the operation of the cellular communication module (i.e., communication failure), and inability to interact with the data platform. Therefore, it is necessary to send an assistance request to lock devices in the surrounding area of ​​the target lock device through the Bluetooth module in the lock device system. After establishing a connection between the target lock device and the assisting lock device in the lock device according to the assistance request, the abnormal working data is transmitted to the assisting lock device, and the abnormal working data is uploaded to the data platform through the cellular communication module of the assisting lock device.

[0117] The following is combined Figure 5 The process of determining that the target lock device has a communication failure is described below:

[0118] S501: The target lock device initiates a network connection request to the data platform.

[0119] S502: Based on the network connection request, determine whether the target lock device has successfully connected to the target communication network.

[0120] If it is determined that the target lock device has successfully connected to the target communication network, execute S505; if it is determined that the target lock device has not successfully connected to the target communication network, execute S503.

[0121] S503: Check whether the number of retries for the target lock device meets the retry conditions.

[0122] Here, the number of retries refers to the number of times the target lock device re-initiates a network connection request to the data platform.

[0123] If the number of retries meets the retry condition, execute S501; if the number of retries does not meet the retry condition, execute S504.

[0124] S504: A communication failure has been detected in the target lock device.

[0125] S505: Control the target lock device to upload work data to be sent in the data chain list.

[0126] S506: Determine whether the target lock device has successfully uploaded working data.

[0127] If it is determined that the target lock device has successfully uploaded the working data, execute S507; if it is determined that the target lock device has not successfully uploaded the working data, execute S508.

[0128] S507: Delete successfully sent work data from the data chain.

[0129] S508: Count the number of consecutive failures to upload working data to the target lock device.

[0130] S509: If the number of consecutive failures exceeds the first threshold, it is determined that the target lock device has a communication failure.

[0131] The following is combined Figure 6 The troubleshooting process for the aforementioned lock device is described below:

[0132] S601: Obtain the communication status parameters of lock devices within the surrounding area of ​​the target lock device.

[0133] S602: Determine whether there are candidate lock devices among the lock devices that meet the characteristics of the target door lock.

[0134] If it is determined that there is a candidate lock device among the lock devices that meets the characteristics of the target door lock, execute S603; if it is determined that there is no candidate lock device among the lock devices that meets the characteristics of the target door lock, execute S606.

[0135] S603: Perform a weighted summation of the communication status parameters of the candidate lock devices to obtain the assistance priority of the candidate lock devices.

[0136] S604: The first assisting lock device is determined from the candidate lock devices based on the assisting priority.

[0137] S605: Upload abnormal working data of the target lock device through the first assisting lock device.

[0138] S606: Identify the transfer lock device in the lock device.

[0139] S607: Upload abnormal working data of the target lock device to the transfer lock device through the target lock device.

[0140] S608: If the transfer lock device fails to upload abnormal working data a certain number of times consecutively, identify the second assisting lock device of the target lock device among the lock devices in the area surrounding the transfer lock device.

[0141] S609: Upload abnormal operation data through the second auxiliary lock device.

[0142] The following is combined Figure 7 The process of uploading abnormal working data of the target lock device through the first assisting lock device is described below:

[0143] S701: The target lock device sends a connection request to the first assisting lock device.

[0144] S702: Establish a connection between the target lock device and the first assisting lock device according to the connection request.

[0145] S703: The target lock device uploads abnormal working data and the corresponding data identifier to the first assisting lock device.

[0146] S704: The first assist lock device uploads the abnormal working data and the data identifier to the data platform.

[0147] S705: Determine whether the data platform has obtained abnormal working data.

[0148] If the data platform obtains abnormal working data, execute S706; if the data platform does not obtain abnormal working data, execute S708.

[0149] S706: A message indicating that abnormal working data was successfully sent to the target lock device.

[0150] S707: Delete successfully sent abnormal work data from the data chain based on the data identifier of the abnormal work data.

[0151] S708: Receive a retry request sent by the first assist lock device.

[0152] S709: If it is determined that the first assisting lock device meets the retry transmission conditions based on the retry request, the number of retry transmissions is fed back to the first assisting lock device.

[0153] If the first assisting lock device meets the retry transmission count, execute S704; if the first assisting lock device does not meet the retry transmission count, end the process.

[0154] Based on the same inventive concept, this disclosure also provides a fault handling device for a lock device corresponding to the fault handling method for the lock device. Since the principle of the device in this disclosure for solving the problem is similar to the fault handling method for the lock device described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0155] Reference Figure 8 The diagram shown is a schematic of a fault handling device for a lock device according to an embodiment of this disclosure. The device includes: an acquisition unit 80, a processing unit 81, and a device determination unit 82; wherein:

[0156] The acquisition unit is used to acquire communication status parameters of lock devices in the surrounding area of ​​the target lock device when it is determined that the target lock device has a communication failure;

[0157] The processing unit is configured to calculate an assistance priority based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices; wherein the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform;

[0158] The device determination unit is configured to determine a first assisting lock device for the target lock device among the candidate lock devices based on the assistance priority, and to upload abnormal working data of the target lock device through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under communication failure conditions.

[0159] In one possible implementation, the device is also used for:

[0160] Candidate lock devices that meet the target lock characteristics are selected from the lock devices; wherein, the target lock characteristics are used to indicate that the lock device is in an available state;

[0161] The communication status parameters of the candidate lock devices are weighted and summed to obtain the assistance priority of the candidate lock devices.

[0162] In one possible implementation, the device is also used for:

[0163] If it is determined that there are no candidate lock devices in a usable state among the lock devices, a transfer lock device is determined among the lock devices; wherein, the number of lock devices contained in the area surrounding the transfer lock device meets a preset number requirement;

[0164] The target lock device uploads abnormal operating data of the target lock device to the transfer lock device.

[0165] If the transfer lock device fails to upload the abnormal working data a certain number of times consecutively, a second assisting lock device for the target lock device is identified among the lock devices in the area surrounding the transfer lock device.

[0166] The abnormal operation data is uploaded through the second assist lock device.

[0167] In one possible implementation, the device is also used for:

[0168] Once it is determined that the target lock device has successfully connected to the target communication network, the target lock device is controlled to upload each set of working data to be sent in the data chain list;

[0169] If the target lock device fails to upload each set of working data, the number of consecutive failures of the target lock device to upload each set of working data is counted.

[0170] If the number of consecutive failures of the working data is greater than a first threshold, it is determined that the target lock device has a communication fault.

[0171] In one possible implementation, the device is also used for:

[0172] If the target lock device successfully uploads each set of working data, the successfully sent working data is deleted from the data chain list.

[0173] In one possible implementation, the device is also used for:

[0174] After establishing the connection between the target lock device and the first assisting lock device, the abnormal operation data is uploaded through the first assisting lock device;

[0175] If the abnormal working data is successfully acquired, a message indicating that the abnormal working data was successfully sent is sent to the target lock device.

[0176] In one possible implementation, the device is also used for:

[0177] If the abnormal working data is not successfully obtained, a retry request sent by the first assisting lock device is obtained; wherein the retry request carries the number of consecutive failures of the first assisting lock device to send the abnormal working data;

[0178] If the retry request determines that the first assisting lock device meets the retry sending conditions, the number of retry sending attempts is fed back to the first assisting lock device.

[0179] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0180] Corresponding to Figure 1 In addition to the fault handling method for the lock device in the present disclosure, this embodiment also provides an electronic device 90, such as... Figure 9 The diagram shown is a schematic representation of the structure of an electronic device 90 provided in an embodiment of this disclosure, including:

[0181] The system includes a processor 91, a memory 92, and a bus 93. The memory 92 stores execution instructions and includes main memory 921 and external memory 922. Main memory 921, also called internal memory, temporarily stores computational data in the processor 91, as well as data exchanged with external memory such as a hard disk. The processor 91 exchanges data with external memory 922 through main memory 921. When the electronic device 90 is running, the processor 91 communicates with the memory 92 via the bus 93, causing the processor 91 to execute the following instructions:

[0182] If a communication failure is determined in the target lock device, obtain the communication status parameters of the lock devices in the surrounding area of ​​the target lock device;

[0183] Based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices, the assistance priority is calculated; wherein, the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform;

[0184] Based on the assistance priority, a first assisting lock device is determined from the candidate lock devices for the target lock device, and abnormal working data of the target lock device is uploaded through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under communication failure conditions.

[0185] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the fault handling method for the lock device described in the above method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0186] This disclosure also provides a computer program product 1000, such as... Figure 10 The diagram shown is a structural schematic of a computer program product 1000 provided in an embodiment of this disclosure. The computer program product 1000 carries a computer program 1001. The program included in the computer program 1001 can be used to execute the steps of the fault handling method for the lock device described in the above method embodiment. For details, please refer to the above method embodiment, which will not be repeated here.

[0187] The above description, with reference to the accompanying drawings, outlines a method, apparatus, medium, and product for handling lock devices according to embodiments of the present disclosure. First, upon determining that a target lock device has a communication failure, communication status parameters of lock devices within the surrounding area of ​​the target lock device are obtained. Then, based on the communication status parameters of candidate lock devices that are in an available state, an assistance priority is calculated. This assistance priority indicates the probability of a candidate lock device successfully uploading the target lock device's working data to a data platform. Finally, based on this assistance priority, a first assisting lock device is determined from the candidate lock devices, and abnormal working data of the target lock device is uploaded through the first assisting lock device. Abnormal working data indicates working data that was not successfully sent to the data platform during a communication failure. By calculating the assistance priority based on the communication status parameters of the candidate lock devices and determining the first assisting lock device based on the assistance priority, the compatibility between the first assisting lock device and the target lock device is improved. Furthermore, by uploading the abnormal working data of the target lock device through the first assisting lock device, the efficiency of handling the target lock device's failure is improved.

[0188] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0189] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0190] Additionally, as used herein, the “or” used in a list of items beginning with “at least one” indicates a separate list, such that a list of, for example, “at least one of A, B, or C” means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word “exemplary” does not imply that the described example is preferred or better than other examples.

[0191] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0192] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0193] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0194] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A fault handling method for a lock device, characterized in that, include: If a communication failure is determined in the target lock device, obtain the communication status parameters of the lock devices in the surrounding area of ​​the target lock device; Based on the communication status parameters of the candidate lock devices that are in an available state among the lock devices, the assistance priority is calculated; wherein, the assistance priority is used to indicate the probability of the candidate lock device successfully uploading the working data of the target lock device to the data platform; Based on the assistance priority, a first assisting lock device is determined from the candidate lock devices for the target lock device, and abnormal working data of the target lock device is uploaded through the first assisting lock device; wherein, the abnormal working data is used to indicate working data that was not successfully sent to the data platform under communication failure conditions; If it is determined that there are no candidate lock devices in a usable state among the lock devices, a transfer lock device is determined among the lock devices; wherein, the number of lock devices contained in the area surrounding the transfer lock device meets a preset number requirement; The target lock device uploads abnormal operating data of the target lock device to the transfer lock device. If the transfer lock device fails to upload the abnormal working data a certain number of times consecutively, a second assisting lock device for the target lock device is identified among the lock devices in the area surrounding the transfer lock device. The abnormal operation data is uploaded through the second assist lock device.

2. The method according to claim 1, characterized in that, The step of calculating the assistance priority based on the communication status parameters of the candidate lock devices that are in an available state in the lock device includes: Candidate lock devices that meet the target lock characteristics are selected from the lock devices; wherein, the target lock characteristics are used to indicate that the lock device is in an available state; The communication status parameters of the candidate lock devices are weighted and summed to obtain the assistance priority of the candidate lock devices.

3. The method according to claim 1, characterized in that, The determination that the target lock device has a communication failure includes: Once it is determined that the target lock device has successfully connected to the target communication network, the target lock device is controlled to upload each set of working data to be sent in the data chain list; If the target lock device fails to upload each set of working data, the number of consecutive failures of the target lock device to upload each set of working data is counted. If the number of consecutive failures of the working data is greater than a first threshold, it is determined that the target lock device has a communication fault.

4. The method according to claim 3, characterized in that, The method further includes: If the target lock device successfully uploads each set of working data, the successfully sent working data is deleted from the data chain list.

5. The method according to claim 1, characterized in that, The step of uploading abnormal operating data of the target lock device through the first assisting lock device includes: After establishing the connection between the target lock device and the first assisting lock device, the abnormal operation data is uploaded through the first assisting lock device; If the abnormal working data is successfully acquired, a message indicating that the abnormal working data was successfully sent is sent to the target lock device.

6. The method according to claim 5, characterized in that, The method further includes: If the abnormal working data is not successfully obtained, a retry request sent by the first assisting lock device is obtained; wherein the retry request carries the number of consecutive failures of the first assisting lock device to send the abnormal working data; If the retry request determines that the first assisting lock device meets the retry sending conditions, the number of retry sending attempts is fed back to the first assisting lock device.

7. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the fault handling method for the lock device as described in any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the fault handling method for the lock device as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, The computer program product is stored in a storage medium, and the program product is executed by at least one processor to implement the fault handling method of the lock device as described in any one of claims 1 to 6.

Images