Handling methods, storage media, and servers for intelligent device upgrade anomalies.

Abstract

This application discloses a method, storage medium, and server for handling upgrade anomalies of smart devices, relating to the field of smart home technology. It aims to solve the problem of reducing the cost of handling upgrade anomalies of smart devices. The method includes: in response to a smart device upgrade anomaly, obtaining the upgrade anomaly code reported by the smart device; determining whether the upgrade anomaly code meets a first preset condition; if it does, adding the smart device to a device upgrade blacklist; and setting removal conditions to determine whether the smart device can be removed from the device upgrade blacklist under the preset conditions. In this way, the specific reason for the upgrade anomaly can be understood based on the upgrade anomaly code, allowing for differentiated processing of the anomaly-affected smart devices. Simultaneously, setting removal conditions establishes a mechanism for automatically removing smart devices from the device upgrade blacklist, improving the intelligence level of upgrade anomaly handling, reducing the manual cost of device upgrade anomaly handling, and expanding the coverage of device upgrade services.

Description

Technical Field

[0001] This application relates to the field of smart homes, and more specifically, to a method for handling abnormal upgrades of smart devices, a storage medium, and a server. Background Technology

[0002] OTA (Over-The-Air) upgrade for smart devices is a process of updating the software or firmware of a device to the latest version via a wireless network. This eliminates the need for the user to connect the device to a computer or other device, greatly simplifying the upgrade process and improving the user experience. This upgrade method is called Over-the-Air (OTA) upgrade, also known as over-the-air download technology. However, during the OTA upgrade process, smart devices may fail to upgrade due to various reasons such as network anomalies, incomplete upgrade package files, or the device's current state not meeting the upgrade requirements.

[0003] For devices that have failed to upgrade multiple times consecutively, current technology involves the OTA platform automatically adding the device to a blacklist when the number of consecutive upgrade failures reaches a certain threshold. This prevents the OTA platform from issuing upgrades to devices on the blacklist again. Once the device recovers, OTA administrators manually remove it from the blacklist. However, this method relies entirely on manual intervention by OTA administrators, increasing labor costs and reducing timeliness. Furthermore, this method is prone to errors, potentially causing devices eligible for upgrades to lose subsequent upgrade opportunities due to being blacklisted, thus impacting the coverage and number of upgrades available for the OTA service.

[0004] Accordingly, a new solution is needed in this field to address the aforementioned problems. Summary of the Invention

[0005] This application aims to solve the aforementioned technical problems, namely, the high labor costs and impact on the coverage of OTA services caused by the high cost of handling upgrade failures of smart devices in the existing technology.

[0006] In a first aspect, this application provides a method for handling upgrade anomalies in smart devices, the method comprising:

[0007] Obtain the upgrade exception code reported by the smart device, wherein the upgrade exception code is an identifier used to indicate the specific reason for the upgrade exception of the smart device;

[0008] Determine whether the upgrade error code meets the first preset condition, the first preset condition being the condition in the pre-set exception handling strategy for adding the smart device to the device upgrade blacklist;

[0009] If the conditions are met, the smart device is added to the device upgrade blacklist, and removal conditions are set for the smart device added to the device upgrade blacklist. The removal conditions are used to determine whether the smart device can be removed from the device upgrade blacklist under preset conditions.

[0010] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0011] The method further includes determining the first preset condition according to the following steps:

[0012] Obtain multiple reasons for device upgrade anomalies and set a corresponding upgrade anomaly code for each of the aforementioned reasons;

[0013] According to user needs, an automatic addition parameter is set for each of the above-mentioned reasons for device upgrade anomalies. The automatic addition parameter is a parameter used to indicate whether the smart device that caused the upgrade anomaly due to the above-mentioned reasons needs to be added to the device upgrade blacklist.

[0014] The exception handling strategy is determined based on the upgrade exception code corresponding to each of the aforementioned device upgrade exception reasons and the automatically added parameters.

[0015] The first preset condition is determined according to the exception handling strategy.

[0016] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0017] Determining the first preset condition according to the exception handling strategy includes:

[0018] All upgrade exception codes of the target automatic addition parameters are obtained from the exception handling strategy to obtain the preset upgrade exception code range. The target automatic addition parameters are the automatic addition parameters corresponding to the addition of the device upgrade blacklist.

[0019] Determine the number of exceptions corresponding to each upgrade exception code in the preset upgrade exception code range. The number of exceptions is used to represent the minimum number of times that a smart device added to the device upgrade blacklist needs to continuously report the upgrade exception code.

[0020] The first preset condition is determined based on the preset upgrade exception code range and the number of exceptions.

[0021] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0022] The step of determining whether the upgrade error code meets the first preset condition includes:

[0023] Based on the preset upgrade exception code range and the number of exceptions, determine whether the upgrade exception code meets the first preset condition;

[0024] If the upgrade error code is within the preset upgrade error code range and the number of times the smart device continuously reports the upgrade error code is greater than or equal to the number of errors, the upgrade error code is determined to meet the first preset condition.

[0025] If the upgrade error code is not within the preset upgrade error code range or the number of times the smart device continuously reports the upgrade error code is less than the number of errors, it is determined that the upgrade error code does not meet the first preset condition.

[0026] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0027] After obtaining the upgrade error code reported by the smart device, the process further includes:

[0028] Determine whether the upgrade exception code exists in the exception handling strategy;

[0029] If it exists, proceed to the step of "determining whether the upgrade exception code meets the first preset condition";

[0030] If not, determine whether the smart device meets the second preset condition, which is determined based on the number of times the smart device continuously reports the upgrade error code;

[0031] If so, add the smart device to the device upgrade blacklist;

[0032] If not, the smart device will not be added to the device upgrade blacklist.

[0033] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0034] The step of determining whether the smart device meets the second preset condition includes:

[0035] Determine whether the number of times the smart device continuously reports the upgrade error code is greater than or equal to a preset number;

[0036] If yes, the smart device is determined to meet the second preset condition; if no, the smart device is determined to not meet the second preset condition.

[0037] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0038] The method further includes:

[0039] In response to a smart device in the device upgrade blacklist reconnecting to the network, the system determines whether to remove the smart device from the device upgrade blacklist based on the removal conditions.

[0040] In one technical solution of the above-mentioned method for handling abnormal upgrades of smart devices,

[0041] The removal conditions include automatic addition, whereby the automatically added smart devices are smart devices that meet the first preset conditions and are added to the device upgrade blacklist.

[0042] The step of determining whether to remove the smart device from the device upgrade blacklist based on the removal conditions includes:

[0043] Determine whether the removal condition for the smart device is automatic addition;

[0044] If so, remove the smart device from the device upgrade blacklist;

[0045] If not, the smart device will not be removed from the device upgrade blacklist.

[0046] In a second aspect, a computer-readable storage medium is provided, the computer-readable storage medium comprising a stored program, wherein the program, when executed, performs the method described in any one of the above-described methods for handling intelligent device upgrade anomalies.

[0047] In a third aspect, a server is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute, through the computer program, any one of the above-described methods for handling intelligent device upgrade anomalies.

[0048] The above-described technical solutions of this application have at least one or more of the following beneficial effects:

[0049] By adopting the above technical solution, this application provides a method for handling intelligent device upgrade anomalies, including: responding to an intelligent device upgrade anomaly, obtaining an upgrade anomaly code reported by the intelligent device indicating the specific reason for the upgrade anomaly, determining whether the upgrade anomaly code meets a first preset condition, and if it does, adding the intelligent device to a device upgrade blacklist, and setting removal conditions for the intelligent devices added to the device upgrade blacklist, the removal conditions being used to determine whether the intelligent device can be removed from the device upgrade blacklist under preset conditions. Through the above configuration method, the specific reason for the upgrade anomaly of the intelligent device can be understood based on the upgrade anomaly code reported by the intelligent device, and then different processing can be carried out for different upgrade anomaly reasons. Based on the pre-configured anomaly handling strategy, it is selected whether to add the intelligent device to the device upgrade blacklist, realizing automated processing of intelligent devices with upgrade anomalies, improving the intelligence of device upgrade anomaly handling, reducing the manual cost of device upgrade anomaly handling, avoiding the situation where intelligent devices are mistakenly included in the blacklist due to reasons such as device refusal to upgrade or delayed upgrade, and expanding the coverage of device upgrade services. Meanwhile, the removal conditions for adding smart devices to the device upgrade blacklist can be set so that smart devices can be automatically removed from the device upgrade blacklist after they reconnect to the network. This forms a mechanism for automatically removing devices from the blacklist, which greatly reduces the work and manpower costs for OTA administrators to remove devices from the blacklist, improves the operational efficiency of handling device upgrade anomalies, and effectively ensures the coverage of device upgrade services and the number of upgraded devices.

[0050] Furthermore, multiple upgrade exception codes can be selected to form a preset upgrade exception code range, the number of exceptions corresponding to each upgrade exception code can be determined, and the reasons for each type of device upgrade exception can be specified to determine whether the corresponding smart device can be blacklisted and the corresponding conditions for blacklisting. This provides a high degree of flexibility and can meet the practical application needs of various scenarios. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0052] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic flowchart of the main steps of a method for handling upgrade anomalies of a smart device according to an embodiment of this application;

[0054] Figure 2 This is a schematic flowchart of the main steps of a method for handling upgrade anomalies of a smart device according to one embodiment of this application.

[0055] Figure 3 This is a schematic diagram of the actual operation page for configuring a strategy to automatically add devices to a blacklist according to an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of the hardware environment for the interaction between a server and a smart device, according to an embodiment of this application. Detailed Implementation

[0057] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0058] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0059] See appendix Figure 1 , Figure 1 This is a schematic flowchart illustrating the main steps of a method for handling upgrade anomalies in smart devices according to an embodiment of this application. Figure 1 As shown, the method for handling upgrade anomalies in smart devices may include the following steps S101 to S103:

[0060] Step S101: Obtain the upgrade error code reported by the smart device.

[0061] In this embodiment, the upgrade exception code is an identifier used to indicate the specific reason for the upgrade failure of the smart device.

[0062] In this embodiment, "smart device upgrade anomaly" refers to upgrade failure during the OTA upgrade process due to various reasons such as network anomalies, incomplete upgrade package files, and the device's current state not meeting the upgrade conditions. Over-the-Air (OTA) upgrade is a smart device upgrade technology that updates the software or firmware on a device to the latest version via a wireless network, without requiring the user to connect the device to a computer or other devices.

[0063] In this embodiment, upgrade exception codes corresponding to upgrade failure reasons can be pre-configured on the OTA platform so that when an upgrade exception occurs, the smart device can determine the corresponding upgrade exception code based on the upgrade failure reason detected by the smart device itself, and upload the upgrade exception code to the OTA platform.

[0064] In one embodiment, the method for handling smart device upgrade anomalies of this application can be applied to an over-the-air download platform or to a cloud server for handling device upgrade anomalies, without affecting the normal implementation of the embodiments of this application.

[0065] Step S102: Determine whether the upgrade error code meets the first preset condition. If it does, proceed to step S103.

[0066] In this embodiment, the first preset condition is a condition in a pre-set exception handling strategy used to add the smart device to the device upgrade blacklist.

[0067] In one implementation, if the upgrade error code does not meet the first preset condition, the smart device will not be added to the device upgrade blacklist.

[0068] In one implementation, the first preset condition can be determined according to the following steps S201 to S204:

[0069] Step S201: Obtain multiple reasons for device upgrade anomalies and set a corresponding upgrade anomaly code for each reason for device upgrade anomalies.

[0070] In this embodiment, the cause of each device upgrade anomaly can be automatically configured by the OTA system or manually configured by the administrator, neither of which will affect the normal implementation of this application embodiment.

[0071] Step S202: Set up automatic parameter addition for each device upgrade anomaly cause according to user needs.

[0072] In this embodiment, the automatically added parameter is a parameter used to indicate whether a smart device that experienced an upgrade anomaly due to an upgrade failure needs to be added to the device upgrade blacklist. For example, the automatically added parameter may include "Yes" or "No," "Y" or "N," or other parameters corresponding to whether to add the device to the upgrade blacklist; none of these affect the normal implementation of this embodiment.

[0073] Step S203: Determine the exception handling strategy based on the upgrade exception code and automatically added parameters corresponding to each device upgrade exception reason.

[0074] In this embodiment, users can pre-configure and store exception handling strategies in the OTA platform. Users can be manufacturers or developers of smart devices.

[0075] In this embodiment, the exception handling strategy may include the upgrade exception code stored in OTA, a detailed description of the upgrade exception reason corresponding to the upgrade exception code, automatic addition parameters, conditions for automatic addition to the device upgrade blacklist, and other parameters that users need to configure.

[0076] Step S204: Determine the first preset condition according to the exception handling strategy.

[0077] In one implementation, user input can be obtained according to user needs, and a corresponding first preset condition can be configured for each upgrade error code based on the user input. For example, the number of errors can be configured as the first preset condition for each upgrade error code. If a smart device fails to upgrade multiple times consecutively and continuously reports the same upgrade error code, and the number of consecutive reports by the smart device is greater than or equal to the number of errors corresponding to that upgrade error code, the smart device will be added to the device upgrade blacklist.

[0078] In one embodiment, step S204 may further include steps S2041 to S2043:

[0079] Step S2041: Obtain all upgrade exception codes that are automatically added to the target parameters from the exception handling strategy to obtain the preset upgrade exception code range.

[0080] Step S2042: Determine the number of exceptions corresponding to each upgrade exception code in the preset upgrade exception code range.

[0081] Step S2043: Determine the first preset condition based on the preset upgrade exception code range and the number of exceptions.

[0082] In this embodiment, the target auto-add parameter corresponds to the auto-add parameter for adding to the upgrade blacklist. The anomaly count is used to indicate the minimum number of consecutive upgrade anomaly codes that a smart device added to the device upgrade blacklist needs to report.

[0083] In one implementation, the value of the target auto-add parameter can be any one of "Yes", "Y" or "1", or other actual representative values ​​corresponding to adding to the upgrade blacklist.

[0084] In one embodiment, step S102 may further include steps S1021 to S1023:

[0085] Step S1021: Determine whether the upgrade error code meets the first preset condition based on the preset upgrade error code range and the number of errors.

[0086] Step S1022: If the upgrade error code is within the preset upgrade error code range and the number of times the smart device continuously reports the upgrade error code is greater than or equal to the number of errors, the upgrade error code is determined to meet the first preset condition.

[0087] Step S1023: If the upgrade error code is not within the preset upgrade error code range or the number of times the smart device continuously reports the upgrade error code is less than the number of errors, it is determined that the upgrade error code does not meet the first preset condition.

[0088] In this implementation, an upgrade anomaly code is determined to meet the first preset condition only if it falls within a preset upgrade anomaly code range and the number of times the smart device continuously reports the upgrade anomaly code is greater than or equal to the number of anomalies. In all other cases, the upgrade anomaly code is determined not to meet the first preset condition. For example, other cases may include situations where the upgrade anomaly code is within the preset upgrade anomaly code range but the number of times the smart device continuously reports the upgrade anomaly code is less than the number of anomalies; the number of times the smart device continuously reports the upgrade anomaly code is greater than or equal to the number of anomalies but the upgrade anomaly code is not within the preset upgrade anomaly code range; and the upgrade anomaly code is not within the preset upgrade anomaly code range and the number of times the smart device continuously reports the upgrade anomaly code is less than the number of anomalies.

[0089] In one embodiment, after step S101, the method for handling intelligent device upgrade anomalies of this application may further include steps S301 to S304:

[0090] Step S301: Determine whether the upgrade exception code exists in the exception handling strategy. If it exists, proceed to step S102; otherwise, proceed to step S302.

[0091] Step S302: Determine whether the smart device meets the second preset condition. If yes, proceed to step S303; otherwise, proceed to step S304.

[0092] Step S303: Add the smart device to the device upgrade blacklist.

[0093] Step S304: Do not add smart devices to the device upgrade blacklist.

[0094] In this embodiment, the second preset condition is determined based on the number of times the smart device continuously reports upgrade error codes.

[0095] In one embodiment, step S302 may further include:

[0096] Determine whether the number of times the smart device continuously reports upgrade error codes is greater than or equal to a preset number. If yes, the smart device is determined to meet the second preset condition; otherwise, the smart device is determined not to meet the second preset condition.

[0097] In one implementation, if the device upgrade exception reason corresponding to the upgrade exception code does not exist in the device upgrade exception reasons in the exception handling strategy, the device upgrade exception reason can be classified as other reasons, and the upgrade exception code, automatic addition parameters and exception count corresponding to the other reasons can be configured in the exception handling strategy.

[0098] Step S103: Add the smart device to the device upgrade blacklist and set removal conditions for the smart device added to the device upgrade blacklist.

[0099] In this embodiment, the removal condition is used to determine whether a smart device can be removed from the device upgrade blacklist under preset conditions.

[0100] In this embodiment, the device upgrade blacklist refers to the blacklist of the OTA (Over-The-Air) download platform, which is mainly used to prevent specific devices or users from accessing OTA platform resources in order to protect the security and normal operation of the OTA platform.

[0101] In some implementations, a smart device can be added to the device upgrade blacklist by adding the smart device's network identifier ID or the original ID used when adding the smart device to the OTA platform.

[0102] In one embodiment, step S103 may be followed by step S401:

[0103] Step S401: In response to the smart device in the device upgrade blacklist reconnecting to the network, determine whether to remove the smart device from the device upgrade blacklist based on the removal conditions.

[0104] In this embodiment, the removal conditions may include automatic addition, where the smart devices that are automatically added are those that meet the first preset conditions and are added to the device upgrade blacklist.

[0105] In other implementations, removal criteria may also include manual addition. Manually added smart devices are those that manufacturers or developers have pre-selected as ineligible for upgrades due to special circumstances and have added to the device upgrade blacklist. In subsequent decisions regarding whether to remove a smart device from the device upgrade blacklist, manually added smart devices must not be removed.

[0106] In one embodiment, step S401 may further include:

[0107] Determine if the removal condition for the smart device is automatic addition. If yes, remove the smart device from the device upgrade blacklist; otherwise, do not remove the smart device from the device upgrade blacklist.

[0108] In one implementation, see Appendix Figure 2 , Figure 2 This is a schematic flowchart illustrating the main steps of a method for handling upgrade anomalies in a smart device according to one embodiment of this application. Figure 2 As shown, this embodiment may include steps S501 to S508:

[0109] Step S501: The smart device upgrade failure is detected. The OTA platform obtains the upgrade exception code corresponding to the reason for the failure reported by the smart device.

[0110] In one implementation, see Appendix Figure 3 , Figure 3 This is a schematic diagram of the actual operation page for configuring a strategy to automatically add devices to a blacklist, according to an embodiment of this application. Figure 3 As shown, the "automatic blacklisting strategy" (i.e., the exception handling strategy) can be configured in advance on the OTA platform based on various possible reasons for upgrade failures of smart devices.

[0111] In this embodiment, such as Figure 2 As shown, manufacturers or developers can fill in the upgrade exception code, upgrade exception code description, and "Add to Blacklist" parameter corresponding to the upgrade failure reason. The upgrade exception code description refers to the specific reason for the upgrade failure. For example, the upgrade exception code description can include one or more of the following: "Device is working, upgrade refused," "Device is working, upgrade postponed," "Device is performing other upgrades," "Device battery power is insufficient," "Device upgrade execution timed out," "Upgrade package size exceeds the range," and "Upgrade package file verification failed." The "Add to Blacklist" parameter indicates whether the smart device should be added to the blacklist when it reports the upgrade exception code. For example, the "Add to Blacklist" parameter can include "Yes" and "No."

[0112] In one implementation, when "Add to blacklist" is selected as "Yes", it is necessary to obtain the information filled in by the manufacturer or developer to determine the minimum number of consecutive occurrences required for the corresponding upgrade error code, as a condition for automatically adding the device to the blacklist.

[0113] In one implementation, the upgrade exception code corresponding to "upgrade failure due to other reasons", the "whether to add to the blacklist" parameter and the conditions for adding to the blacklist can be preset in order to handle upgrade failure reasons that do not exist in the policy.

[0114] Step S502: The OTA platform processes the upgrade error code according to the "policy of automatically adding devices to the blacklist".

[0115] Step S503: The OTA platform determines whether the reason for the upgrade failure corresponding to the upgrade exception code exists in the above strategy. If it exists, proceed to step S504; if it does not exist, proceed to step S506.

[0116] Step S504: The OTA platform determines whether the reason for the failure corresponding to the upgrade exception code is within the scope of the blacklist.

[0117] In this embodiment, it can be determined whether the reason for the failure of the upgrade exception code is within the scope of the blacklist by judging whether the automatic addition parameter corresponding to the upgrade exception code is "yes".

[0118] Step S505: The OTA platform determines whether the smart device meets the conditions for adding it to the blacklist corresponding to the reason for this failure. If it does, proceed to step S507; otherwise, proceed to step S508.

[0119] In this embodiment, it can be determined whether the number of upgrade error codes reported by the smart device is greater than or equal to a preset number. If so, it is determined that the reason for this failure is within the scope of adding to the blacklist; otherwise, it is determined that the reason for this failure is not within the scope of adding to the blacklist.

[0120] Step S506: The OTA platform determines whether the smart device meets the conditions for being added to the blacklist based on "upgrade failure due to other reasons". If it does, proceed to step S507; otherwise, proceed to step S508.

[0121] In one implementation, such as Figure 3 As shown, the condition for adding a device to the blacklist for "upgrade failure due to other reasons" is that the device is automatically added to the blacklist after 5 consecutive occurrences. Therefore, the OTA platform can count the number of times a smart device reports the upgrade exception code corresponding to the reason for the failure. If the number is equal to or greater than 5, the smart device is determined to meet the condition for being added to the blacklist; if the number is less than 5, the smart device is determined not to meet the condition for being added to the blacklist.

[0122] Step S507: The OTA platform automatically adds the smart device to the blacklist and marks the removal condition of the smart device as automatic addition.

[0123] In this embodiment, the removal condition is used to subsequently determine whether to automatically remove the smart device from the blacklist.

[0124] Step S508: The OTA platform does not add the smart device to the blacklist.

[0125] In one implementation, after step S508, the OTA platform can send an upgrade command to the smart device again.

[0126] In one implementation, since the reconnection of a smart device generally indicates that the device's state has been restored, the previous upgrade failure issue has likely been resolved. For example, if a battery-powered device fails to upgrade due to insufficient power and is automatically added to the blacklist by the OTA platform, and the user replaces the battery, the device will reconnect to the network. In this case, the platform needs to be able to automatically remove the device from the blacklist so that the device can continue to be covered by upgrade services. Therefore, the OTA can automatically remove a smart device from the blacklist each time it detects a smart device connecting to the network, which may include steps S509 to S510:

[0127] Step S509: The OTA platform determines whether the smart device is in the blacklist. If it is not in the blacklist, no action is taken; if it is in the blacklist, proceed to step S510.

[0128] Step S510: The OTA platform determines whether the smart device has been automatically added to the blacklist by the platform before. If not, no action is taken; if so, the OTA platform automatically removes the smart device from the blacklist.

[0129] In this embodiment, the OTA platform can determine whether a smart device has been automatically added to the blacklist by the removal conditions marked on the smart device. Specifically, if the removal condition is automatic addition, the smart device is determined to have been automatically added to the blacklist by the OTA platform; if the removal condition is not automatic addition, the smart device is determined not to have been automatically added to the blacklist by the OTA platform.

[0130] By using the above configuration method, this application can obtain the upgrade anomaly code reported by the smart device, collect the specific reasons for the upgrade anomaly, and then perform differentiated processing on different upgrade anomaly reasons. Based on the pre-configured anomaly handling strategy, it can select whether to add the smart device to the device upgrade blacklist, realize the automated processing of smart devices with upgrade anomalies, improve the intelligence of device upgrade anomaly handling, reduce the manual cost of device upgrade anomaly handling, avoid the situation of mistakenly adding smart devices to the blacklist due to device refusal to upgrade or delayed upgrade, and expand the coverage of device upgrade services.

[0131] Meanwhile, this application can also mark the removal conditions for smart devices added to the device upgrade blacklist, so that the automatically added smart devices can be automatically removed from the device upgrade blacklist after reconnecting to the network. This forms a mechanism for automatically removing devices from the blacklist, which greatly reduces the work and manpower costs for OTA administrators to remove devices from the blacklist, improves the operational efficiency of handling device upgrade anomalies, and effectively ensures the coverage of device upgrade services and the number of upgraded devices.

[0132] Furthermore, multiple upgrade exception codes can be selected to form a preset upgrade exception code range, the number of exceptions corresponding to each upgrade exception code can be determined, and the reasons for each type of device upgrade exception can be specified to determine whether the corresponding smart device can be blacklisted and the corresponding conditions for blacklisting. This provides a high degree of flexibility and can meet the practical application needs of various scenarios.

[0133] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided. In one embodiment of the computer-readable storage medium according to this application, the computer-readable storage medium can be configured to store a program for executing the intelligent device upgrade exception handling method of the above-described method embodiments. The program can be loaded and run by a processor to implement the above-described intelligent device upgrade exception handling method. For ease of explanation, only the parts related to the embodiments of this application are shown; for specific technical details not disclosed, please refer to the method section of the embodiments of this application. The computer-readable storage medium can be a memory device formed by various electronic devices. Optionally, in the embodiments of this application, the computer-readable storage medium is a non-transitory computer-readable storage medium.

[0134] According to one aspect of the embodiments of this application, a server is provided. In one embodiment of the server according to this application, the server includes a processor and a memory. The memory can be configured to store a program for executing the intelligent device upgrade exception handling method of the above-described method embodiments. The processor can be configured to execute the program in the memory, which includes, but is not limited to, a program for executing the intelligent device upgrade exception handling method of the above-described method embodiments. For ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the method section of the embodiments of this application.

[0135] In this embodiment, the server may be a server equipped with an over-the-air (OTA) download platform. In some possible implementations, the server may include multiple memories and multiple processors. The program executing the intelligent device upgrade exception handling method of the above method embodiments can be divided into multiple subroutines. Each subroutine can be loaded and run by a processor to execute different steps of the intelligent device upgrade exception handling method of the above method embodiments. Specifically, each subroutine can be stored in different memories, and each processor can be configured to execute programs in one or more memories to jointly implement the intelligent device upgrade exception handling method of the above method embodiments. That is, each processor executes different steps of the intelligent device upgrade exception handling method of the above method embodiments to jointly implement the intelligent device upgrade exception handling method of the above method embodiments.

[0136] The aforementioned processors can be processors deployed on the same device. For example, the aforementioned server can be a high-performance server composed of multiple processors, and the aforementioned processors can be processors configured on that high-performance server. Alternatively, the aforementioned processors can also be processors deployed on different servers. For example, the aforementioned server can also be a server cluster, and the aforementioned processors can be processors on different servers within the server cluster.

[0137] Optionally, in this embodiment, the server 104 and the smart device 102 can be used in applications such as... Figure 4 In the hardware environment shown. For example... Figure 4 As shown, server 104 is connected to smart device 102 via a network and can be used to provide services (such as application services) to terminals or clients installed on terminals. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0138] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The smart device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0139] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for handling upgrade anomalies in smart devices, characterized in that, The method includes: Obtain the upgrade exception code reported by the smart device, wherein the upgrade exception code is an identifier used to indicate the specific reason for the upgrade exception of the smart device; Determine whether the upgrade error code meets the first preset condition, the first preset condition being the condition in the pre-set exception handling strategy for adding the smart device to the device upgrade blacklist; If the conditions are met, the smart device is added to the device upgrade blacklist, and removal conditions are set for the smart device added to the device upgrade blacklist. The removal conditions are used to determine whether the smart device can be removed from the device upgrade blacklist under preset conditions. The method further includes determining the first preset condition according to the following steps: Obtain multiple reasons for device upgrade anomalies and set a corresponding upgrade anomaly code for each of the aforementioned reasons; According to user needs, an automatic addition parameter is set for each of the above-mentioned reasons for device upgrade anomalies. The automatic addition parameter is a parameter used to indicate whether the smart device that caused the upgrade anomaly due to the above-mentioned reasons for device upgrade anomalies needs to be added to the device upgrade blacklist. The exception handling strategy is determined based on the upgrade exception code corresponding to each of the aforementioned device upgrade exception reasons and the automatically added parameters. The first preset condition is determined according to the exception handling strategy; The method further includes: In response to a smart device in the device upgrade blacklist reconnecting to the network, the system determines whether to remove the smart device from the device upgrade blacklist based on the removal conditions. The removal conditions include automatic addition, whereby the automatically added smart devices are smart devices that meet the first preset conditions and are added to the device upgrade blacklist. The step of determining whether to remove the smart device from the device upgrade blacklist based on the removal conditions includes: Determine whether the removal condition for the smart device is automatic addition; If so, remove the smart device from the device upgrade blacklist; If not, the smart device will not be removed from the device upgrade blacklist.

2. The method for handling intelligent device upgrade anomalies according to claim 1, characterized in that, Determining the first preset condition according to the exception handling strategy includes: All upgrade exception codes of the target automatic addition parameters are obtained from the exception handling strategy to obtain the preset upgrade exception code range. The target automatic addition parameters are the automatic addition parameters corresponding to the addition of the device upgrade blacklist. Determine the number of exceptions corresponding to each upgrade exception code in the preset upgrade exception code range. The number of exceptions is used to represent the minimum number of times that a smart device added to the device upgrade blacklist needs to continuously report the upgrade exception code. The first preset condition is determined based on the preset upgrade exception code range and the number of exceptions.

3. The method for handling intelligent device upgrade anomalies according to claim 2, characterized in that, The step of determining whether the upgrade error code meets the first preset condition includes: Based on the preset upgrade exception code range and the number of exceptions, determine whether the upgrade exception code meets the first preset condition; If the upgrade error code is within the preset upgrade error code range and the number of times the smart device continuously reports the upgrade error code is greater than or equal to the number of errors, the upgrade error code is determined to meet the first preset condition. If the upgrade error code is not within the preset upgrade error code range or the number of times the smart device continuously reports the upgrade error code is less than the number of errors, it is determined that the upgrade error code does not meet the first preset condition.

4. The method for handling intelligent device upgrade anomalies according to claim 1, characterized in that, After obtaining the upgrade error code reported by the smart device, the process further includes: Determine whether the upgrade exception code exists in the exception handling strategy; If it exists, proceed to the step of "determining whether the upgrade exception code meets the first preset condition"; If not, determine whether the smart device meets the second preset condition, which is determined based on the number of times the smart device continuously reports the upgrade error code; If so, add the smart device to the device upgrade blacklist; If not, the smart device will not be added to the device upgrade blacklist.

5. The method for handling intelligent device upgrade anomalies according to claim 4, characterized in that, The step of determining whether the smart device meets the second preset condition includes: Determine whether the number of times the smart device continuously reports the upgrade error code is greater than or equal to a preset number; If yes, the smart device is determined to meet the second preset condition; if no, the smart device is determined to not meet the second preset condition.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method for handling intelligent device upgrade anomalies as described in any one of claims 1 to 5.

7. A server, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method for handling intelligent device upgrade anomalies according to any one of claims 1 to 5 through the computer program.

Images