Processing method for upgrading exception of intelligent equipment, storage medium and server

Abstract

The invention discloses a processing method for an upgrade exception of an intelligent device, a storage medium and a server, relates to the technical field of smart homes, and aims to solve the problem of how to reduce the cost required for processing the upgrade exception of the intelligent device, and the method comprises the following steps: in response to the upgrade exception of the intelligent device, obtaining an upgrade exception code reported by the intelligent device, and judging whether the upgrading exception code meets a first preset condition or not, if yes, adding the intelligent equipment into an equipment upgrading blacklist, and setting a removal condition to judge whether the intelligent equipment can be removed from the equipment upgrading blacklist or not under the preset condition. Therefore, the specific reason of the upgrade exception can be known according to the upgrade exception code, the intelligent equipment with the upgrade exception is subjected to differential processing, and meanwhile, the removal condition is set to form a mechanism that the intelligent equipment is automatically removed from the equipment upgrade blacklist, so that the intelligent degree of upgrade exception processing is improved, and the user experience is improved. The labor cost of equipment upgrading exception handling is reduced, and the coverage range of the equipment upgrading service is expanded.

Description

Technical Field

[0001] The present application relates to the field of smart home, and more specifically, to a method, storage medium and server for handling abnormalities in smart device upgrades. Background Art

[0002] OTA upgrade of smart devices is a process of updating the software or firmware on the device to the latest version through a wireless network, without the need for users to connect the device to a computer or other device, which greatly simplifies the upgrade process and improves the user experience. This upgrade method is called Over-the-Air (OTA) upgrade, also known as air download technology. During the OTA upgrade process, smart devices may fail to upgrade due to various reasons such as network anomalies, incomplete upgrade package files, and the current status of the device not meeting the upgrade conditions.

[0003] For devices that have failed to upgrade multiple times in a row, the current existing technology uses the OTA platform to determine that when the number of consecutive upgrade failures of the device reaches a certain number, the device is automatically added to the blacklist, so that the OTA platform will not send upgrades to the devices in the blacklist again; when the device returns to normal, the OTA administrator manually removes the device from the blacklist. However, this method completely relies on the OTA administrator to manually remove the device from the blacklist, which increases labor costs and reduces the timeliness of the operation. In addition, this method has a large error, which may cause devices that can continue to upgrade to lose subsequent upgrade opportunities because they are added to the blacklist, thereby affecting the coverage scale and number of upgrades of the OTA service.

[0004] Accordingly, a new solution is needed in the art to solve the above problems. Summary of the invention

[0005] The present application aims to solve the above-mentioned technical problem, namely, to solve the problem that the existing technology for handling failed upgrades of smart devices has high labor costs and affects the coverage scale of OTA services.

[0006] In a first aspect, the present application provides a method for handling an abnormality in upgrading a smart device, the method comprising:

[0007] Acquire an upgrade exception code reported by the smart device, where the upgrade exception code is an identifier for indicating a specific reason for an upgrade exception of the smart device;

[0008] Determine whether the upgrade exception code meets a first preset condition, where the first preset condition is a condition in a preset exception handling strategy for adding the smart device to a device upgrade blacklist;

[0009] If it meets the requirements, the smart device is added to the device upgrade blacklist, and a removal condition is set for the smart device added to the device upgrade blacklist, wherein the removal condition is 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 abnormalities in smart device upgrade,

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

[0012] Obtain multiple device upgrade exception reasons, and set a corresponding upgrade exception code for each of the device upgrade exception reasons;

[0013] According to user needs, an automatic adding parameter is set for each of the device upgrade abnormality reasons, and the automatic adding parameter is a parameter used to indicate whether the smart device that has an upgrade abnormality caused by the device upgrade abnormality reason needs to be added to the device upgrade blacklist;

[0014] Determine the exception handling strategy according to the upgrade exception code and automatic adding parameters corresponding to each of the device upgrade exception reasons;

[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 abnormalities in smart device upgrade,

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

[0018] Acquire all upgrade exception codes of the target automatic addition parameter from the exception handling strategy to obtain a preset upgrade exception code range, wherein the target automatic addition parameter is an automatic addition parameter corresponding to adding to the device upgrade blacklist;

[0019] Determine the number of exceptions corresponding to each upgrade exception code in the preset upgrade exception code range, where the number of exceptions is used to indicate the minimum number of times that the smart device added to the device upgrade blacklist needs to continuously report the upgrade exception code;

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

[0021] In one technical solution of the above-mentioned method for handling abnormalities in smart device upgrade,

[0022] The determining whether the upgrade exception code meets the first preset condition includes:

[0023] Determining whether the upgrade exception code meets a first preset condition according to the preset upgrade exception code range and the number of exceptions;

[0024] If the upgrade exception code is within the preset upgrade exception code range and the number of times the smart device continuously reports the upgrade exception code is greater than or equal to the number of exceptions, it is determined that the upgrade exception code meets the first preset condition;

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

[0026] In one technical solution of the above-mentioned method for handling abnormalities in smart device upgrade,

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

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

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

[0030] If not, determining whether the smart device meets a second preset condition, where the second preset condition is a condition determined according to the number of times the smart device continuously reports the upgrade exception code;

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

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

[0033] In one technical solution of the above-mentioned method for handling abnormalities in smart device upgrade,

[0034] The 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 exception code is greater than or equal to a preset number;

[0036] If so, it is determined that the smart device meets the second preset condition; if not, it is determined that the smart device does not meet the second preset condition.

[0037] In one technical solution of the above-mentioned method for handling abnormalities in smart device upgrade,

[0038] The method further comprises:

[0039] In response to a smart device in the device upgrade blacklist being reconnected to the network, it is determined whether to remove the smart device from the device upgrade blacklist according to the removal condition.

[0040] In one technical solution of the above-mentioned method for handling abnormalities in smart device upgrade,

[0041] The removal condition includes automatic joining, and the automatically joined smart device is a smart device that meets the first preset condition and is added to the device upgrade blacklist;

[0042] The determining, according to the removal condition, whether to remove the smart device from the device upgrade blacklist includes:

[0043] Determining whether the removal condition of the smart device is automatic joining;

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

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

[0046] In a second aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is run, any of the methods described in the technical solution for handling upgrade exceptions of smart devices is executed.

[0047] In a third aspect, a server is provided, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute any one of the methods in the technical solution for handling abnormalities in smart device upgrades through the computer program.

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

[0049] In the case of adopting the above technical solution, the present application provides a method for handling abnormalities in smart device upgrades, including: in response to abnormalities in smart device upgrades, obtaining an upgrade exception code reported by the smart device to indicate the specific cause of the abnormality in the smart device upgrade, judging whether the upgrade exception code meets the first preset condition, and if so, adding the smart device to the device upgrade blacklist, and setting removal conditions for the smart device added to the device upgrade blacklist, the removal conditions are used to judge whether the smart device can be removed from the device upgrade blacklist under the preset conditions. Through the above configuration method, the specific cause of the abnormality in the upgrade of the smart device can be understood according to the upgrade exception code reported by the smart device, and then different causes of the abnormality in the upgrade can be handled differently, and whether to add the smart device to the device upgrade blacklist can be selected according to the pre-configured exception handling strategy, thereby realizing the automated processing of smart devices with abnormal upgrades, improving the intelligence of the abnormality handling of device upgrades, reducing the labor cost of the abnormality handling of device upgrades, avoiding the situation where smart devices are mistakenly included in the blacklist due to reasons such as device refusal to upgrade or delayed upgrades, and expanding the coverage of device upgrade services. At the same time, it is also possible to set removal conditions for smart devices added to the device upgrade blacklist, so that the smart device can be automatically removed from the device upgrade blacklist after the smart device is reconnected to the network, thereby forming a mechanism for automatically removing devices from the blacklist. This greatly reduces the work and manpower costs of OTA managers in removing devices from the blacklist, improves the operational efficiency of device upgrade exception handling, and effectively ensures the coverage of the device upgrade service and the number of upgraded devices.

[0050] In addition, you can also select multiple upgrade exception codes to form a preset upgrade exception code range, determine the number of exceptions corresponding to each upgrade exception code, specify whether the device upgrade exception caused by each device upgrade exception reason will cause the corresponding smart device to enter the blacklist and the corresponding conditions for entering the blacklist. It is highly flexible and can meet actual application needs in a variety of scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

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

[0054] Figure 2 A flowchart of the main steps of a method for handling an abnormal smart device upgrade according to an implementation of an embodiment of the present application;

[0055] Figure 3 A schematic diagram of an actual operation page for configuring a strategy for automatically adding a device to a blacklist according to an embodiment of the present application;

[0056] Figure 4 A schematic diagram of the hardware environment for interaction between a server and a smart device according to an embodiment of the present application. DETAILED DESCRIPTION

[0057] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work 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 and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0059] See attached Figure 1 , Figure 1 FIG. 1 is a flowchart of the main steps of a method for handling an abnormal smart device upgrade according to an embodiment of the present application. Figure 1 As shown, the method for handling the abnormality of smart device upgrade may include the following steps S101 to S103:

[0060] Step S101: Obtain the upgrade exception 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 exception of the smart device.

[0062] In this embodiment, the smart device upgrade exception refers to the upgrade failure caused by various reasons during the OTA upgrade process, such as network abnormality, incomplete upgrade package file, and the current state of the device not meeting the upgrade conditions. Among them, the Over-the-Air (OTA) upgrade of smart devices is a smart device upgrade technology that updates the software or firmware on the device to the latest version through a wireless network without the user connecting the device to a computer or other device.

[0063] In this embodiment, the upgrade exception code corresponding to the upgrade failure reason 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 according to the upgrade failure reason detected by the smart device itself, and upload the upgrade exception code to the OTA platform.

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

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

[0066] In this embodiment, the first preset condition is a condition in a preset exception handling strategy for adding the smart device to a device upgrade blacklist.

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

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

[0069] Step S201: Acquire multiple reasons for device upgrade exceptions, and set a corresponding upgrade exception code for each reason for device upgrade exceptions.

[0070] In this implementation, the OTA system can automatically configure the reason for each device upgrade exception, or it can be manually configured by an administrator, both of which will not affect the normal implementation of the embodiments of the present application.

[0071] Step S202: setting automatic joining parameters for each device upgrade exception reason according to user needs.

[0072] In this embodiment, the automatic joining parameter is a parameter used to indicate whether the smart device that has an upgrade abnormality due to the device upgrade abnormality needs to be added to the device upgrade blacklist. As an example, the automatic joining parameter may include "yes" or "no", or "Y" or "N", or other parameters corresponding to whether to add to the device upgrade blacklist, which do not affect the normal implementation of the embodiment of the present application.

[0073] Step S203: determining an exception handling strategy according to the upgrade exception code and the automatic adding parameter corresponding to each device upgrade exception reason.

[0074] In this implementation, the user may pre-configure and store the exception handling strategy in the OTA platform, and the user may be a manufacturer or developer of the smart device.

[0075] In this embodiment, the exception handling strategy may include the upgrade exception code stored by OTA, the specific description of the upgrade exception reason corresponding to the upgrade exception code, automatic addition parameters, conditions for automatically adding the device upgrade blacklist, and other parameters that the user needs to configure.

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

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

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

[0079] Step S2041: Acquire all upgrade exception codes of the target automatic addition parameters from the exception handling strategy to obtain a 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 a first preset condition according to a preset upgrade exception code range and an exception number.

[0082] In this embodiment, the target automatic joining parameter is an automatic joining parameter corresponding to joining the upgrade blacklist. The number of exceptions is used to indicate the minimum number of times that the smart device added to the device upgrade blacklist needs to continuously report the upgrade exception code.

[0083] In one implementation, the value of the target automatic joining parameter may be any one of “yes”, “Y” or “1”, or may be other actual representative values ​​corresponding to joining the upgrade blacklist.

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

[0085] Step S1021: judging whether the upgrade exception code meets the first preset condition according to the preset upgrade exception code range and the number of exceptions.

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

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

[0088] In this embodiment, only when the upgrade exception code is within the preset upgrade exception code range and the number of times the smart device continuously reports the upgrade exception code is greater than or equal to the number of abnormal times, will the upgrade exception code be determined to meet the first preset condition. In other cases, the upgrade exception code is determined not to meet the first preset condition. As an example, other situations may include the situation that the upgrade exception code is within the preset upgrade exception code range but the number of times the smart device continuously reports the upgrade exception code is less than the number of abnormal times, the number of times the smart device continuously reports the upgrade exception code is greater than or equal to the number of abnormal times but the upgrade exception code is not within the preset upgrade exception code range, the upgrade exception code is not within the preset upgrade exception code range and the number of times the smart device continuously reports the upgrade exception code is less than the number of abnormal times, etc.

[0089] In one implementation, after step S101, the method for handling smart device upgrade exceptions of the present application may further include steps S301 to S304:

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

[0091] Step S302: Determine whether the smart device meets the second preset condition, if so, proceed to step S303, if not, proceed to step S304.

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

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

[0094] In this embodiment, the second preset condition is a condition determined according to the number of times the smart device continuously reports the upgrade exception code.

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

[0096] It is determined whether the number of times the smart device continuously reports the upgrade exception code is greater than or equal to a preset number of times. If so, it is determined that the smart device meets the second preset condition; if not, it is determined that the smart device does not meet the second preset condition.

[0097] In one implementation, if the device upgrade exception cause corresponding to the upgrade exception code does not exist in the device upgrade exception causes in the exception handling policy, the device upgrade exception cause can be classified as other causes, and the upgrade exception code, automatic joining parameters and number of exceptions corresponding to the other causes can be configured in the exception handling policy.

[0098] Step S103: adding the smart device to the device upgrade blacklist, and setting removal conditions for the smart device added to the device upgrade blacklist.

[0099] In this embodiment, the removal condition is used to determine whether the 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 to protect the security and normal operation of the OTA platform.

[0101] In some implementations, the smart device can be added to the device upgrade blacklist by adding the network identification ID of the smart device or the original ID used when the OTA platform adds the smart device to the device upgrade blacklist.

[0102] In one implementation, step S103 may further include step S401:

[0103] Step S401: In response to a smart device in the device upgrade blacklist being reconnected to the network, it is determined whether to remove the smart device from the device upgrade blacklist according to a removal condition.

[0104] In this implementation, the removal condition may include automatic joining, and the automatically joined smart device is a smart device that meets the first preset condition and is added to the device upgrade blacklist.

[0105] In other implementations, the removal condition may also include manual addition, where the manually added smart device is a smart device that is manually added to the device upgrade blacklist by the manufacturer or developer in advance because the device cannot be upgraded due to special circumstances. In the subsequent process of determining whether to remove the smart device from the device upgrade blacklist, the manually added smart device cannot be removed from the device upgrade blacklist.

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

[0107] It is determined whether the removal condition of the smart device is automatic addition. If so, the smart device is removed from the device upgrade blacklist. If not, the smart device is not removed from the device upgrade blacklist.

[0108] In one embodiment, see the attached Figure 2 , Figure 2 FIG. 1 is a flow chart of the main steps of a method for handling an abnormal smart device upgrade according to an implementation of an embodiment of the present application. Figure 2 As shown, this embodiment may include steps S501 to S508:

[0109] Step S501: When it is detected that the smart device upgrade fails, the OTA platform obtains the upgrade exception code corresponding to the failure reason reported by the smart device.

[0110] In one embodiment, please refer to the attached Figure 3 , Figure 3 This is a schematic diagram of the actual operation page of configuring a strategy of automatically adding a device to a blacklist in an embodiment of the present application. Figure 3 As shown, the "strategy of automatically adding devices to the blacklist", that is, the exception handling strategy, can be configured in advance on the OTA platform according to various possible reasons for upgrade failure of smart devices.

[0111] In this embodiment, if Figure 2 As shown, the manufacturer or developer may fill in the upgrade exception code, upgrade exception code description and "whether to add to blacklist" parameter corresponding to the reason for the upgrade failure. Among them, the upgrade exception code description refers to the specific reason for the upgrade failure. For example, the upgrade exception code description may include "the device is working, the upgrade is rejected", "the device is working, the upgrade is postponed", "the device is performing other upgrades", "the device battery is low", "the device upgrade timeout", "the upgrade package size exceeds the range" and "the upgrade package file verification failed" One or more. The "whether to add to blacklist" parameter refers to whether the smart device needs to be added to the blacklist when the smart device reports the upgrade exception code. For example, the "whether to add to blacklist" parameter may include "yes" and "no".

[0112] In one implementation, when "yes" is selected for "whether to add to blacklist", it is necessary to obtain the manufacturer's or developer's input content to determine the minimum number of consecutive appearances of the corresponding upgrade exception code as a condition for automatically adding the device to the blacklist.

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

[0114] Step S502: The OTA platform processes the upgrade exception code according to the "strategy of automatically adding the device to the blacklist".

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

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

[0117] In this implementation, it can be determined whether the automatic adding parameter corresponding to the upgrade exception code is "yes" to determine whether the failure reason corresponding to the upgrade exception code is within the range of adding to the blacklist.

[0118] Step S505: The OTA platform determines whether the smart device meets the blacklisting conditions corresponding to the failure reason. If so, the process goes to step S507; if not, the process goes to step S508.

[0119] In this embodiment, it can be determined whether the number of upgrade exception codes reported by the smart device is greater than or equal to the preset number. If so, it is determined that the cause of this failure is within the scope of blacklisting. If not, it is determined that the cause of this failure is not within the scope of blacklisting.

[0120] Step S506: The OTA platform determines whether the smart device meets the conditions for joining the blacklist based on "upgrade failure caused by other reasons". If so, proceed to step S507; if not, proceed to step S508.

[0121] In one embodiment, if Figure 3 As shown in the figure, the condition for adding the device to the blacklist corresponding to "upgrade failure caused by other reasons" is to automatically add the device to the blacklist if it occurs 5 times in a row. Therefore, the OTA platform can count the number of times the smart device continuously reports the upgrade exception code corresponding to the failure reason. If the number is equal to or greater than 5 times, it is determined that the smart device meets the condition for adding to the blacklist. If the number is less than 5 times, it is determined that the smart device does not meet the condition for adding 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 may send an upgrade instruction to the smart device again.

[0126] In one implementation, since the reconnection of a smart device generally means that the status of the device has been restored, the problem of the previous upgrade failure is likely to have been solved. For example, a battery-powered device is automatically added to the blacklist by the OTA platform after the upgrade fails due to insufficient power. The user finds that the power is insufficient and replaces the battery for the device. The device will reconnect to the network. At this time, the platform needs to be able to automatically remove the device from the blacklist so that the device can continue to be covered by the upgrade service. Therefore, OTA can automatically remove the smart device from the blacklist every time it detects that a smart device is connected to the network, which can include steps S509 to S510:

[0127] Step S509: The OTA platform determines whether the smart device is in the blacklist. If not, no processing is performed; if in the blacklist, the process proceeds 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 processing is performed; if so, the OTA platform automatically removes the smart device from the blacklist.

[0129] In this embodiment, the OTA platform can determine whether the smart device is automatically added to the blacklist by the OTA platform through the removal condition marked by the smart device. Specifically, if the removal condition is automatic addition, it is determined that the smart device is automatically added to the blacklist by the OTA platform; if the removal condition is not automatic addition, it is determined that the smart device is not automatically added to the blacklist by the OTA platform.

[0130] Through the above configuration method, the present application can collect the specific reasons for the upgrade exception of the smart device by obtaining the upgrade exception code reported by the smart device, and then perform differentiated processing on different upgrade exception reasons, and choose whether to add the smart device to the device upgrade blacklist according to the pre-configured exception handling strategy, thereby realizing the automated processing of smart devices with upgrade exceptions, improving the intelligence of device upgrade exception handling, reducing the labor cost of device upgrade exception handling, avoiding the situation where the smart device is mistakenly added to the blacklist due to reasons such as device refusal to upgrade or delayed upgrade, and expanding the coverage of device upgrade services.

[0131] At the same time, the present 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 they are reconnected to the network, thereby forming a mechanism for automatically removing devices from the blacklist, which greatly reduces the work and manpower costs of OTA managers in removing devices from the blacklist, improves the operational efficiency of device upgrade exception handling, and effectively ensures the coverage of the device upgrade service and the number of upgraded devices.

[0132] In addition, you can also select multiple upgrade exception codes to form a preset upgrade exception code range, determine the number of exceptions corresponding to each upgrade exception code, specify whether the device upgrade exception caused by each device upgrade exception reason will cause the corresponding smart device to enter the blacklist and the corresponding conditions for entering the blacklist. It is highly flexible and can meet actual application needs in a variety of scenarios.

[0133] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided. In a computer-readable storage medium embodiment according to the present application, the computer-readable storage medium can be configured to store a program for executing the method for handling the abnormality of smart device upgrades in the above-mentioned method embodiment, and the program can be loaded and run by a processor to implement the method for handling the abnormality of smart device upgrades. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The computer-readable storage medium can be a memory device formed by various electronic devices. Optionally, the computer-readable storage medium in the embodiment of the present application is a non-temporary computer-readable storage medium.

[0134] According to one aspect of an embodiment of the present application, a server is provided. In a server embodiment according to the present application, the server includes a processor and a memory. The memory can be configured to store a program for executing the method for handling abnormalities of smart device upgrades in the above method embodiment. The processor can be configured to execute the program in the memory, which includes but is not limited to the program for executing the method for handling abnormalities of smart device upgrades in the above method embodiment. For ease of explanation, only the parts related to the embodiment of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application.

[0135] In an embodiment of the present application, the server may be a server equipped with an over-the-air download platform. In some possible implementations, the server may include multiple memories and multiple processors. The program for executing the method for handling the exception of the smart device upgrade of the above method embodiment can be divided into multiple subprograms, each of which can be loaded and run by a processor to execute different steps of the method for handling the exception of the smart device upgrade of the above method embodiment. Specifically, each subprogram can be stored in different memories, and each processor can be configured to execute programs in one or more memories to jointly implement the method for handling the exception of the smart device upgrade of the above method embodiment, that is, each processor executes different steps of the method for handling the exception of the smart device upgrade of the above method embodiment, to jointly implement the method for handling the exception of the smart device upgrade of the above method embodiment.

[0136] The above-mentioned multiple processors may be processors deployed on the same device. For example, the above-mentioned server may be a high-performance server composed of multiple processors, and the above-mentioned multiple processors may be processors configured on the high-performance server. In addition, the above-mentioned multiple processors may also be processors deployed on different servers. For example, the above-mentioned server may also be a server cluster, and the above-mentioned multiple processors may be processors on different servers in the server cluster.

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

[0138] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The smart device 102 may be but is not limited to a PC, a mobile phone, a tablet computer, a smart air conditioner, a smart range hood, a smart refrigerator, a smart oven, a smart stove, a smart washing machine, a smart water heater, a smart washing equipment, a smart dishwasher, a smart projection equipment, a smart TV, a smart clothes drying rack, a smart curtain, a smart audio and video, a smart socket, a smart speaker, a smart speaker, a smart fresh air equipment, a smart kitchen and bathroom equipment, a smart bathroom equipment, a smart sweeping robot, a smart window cleaning robot, a smart mopping robot, a smart air purification equipment, a smart steamer, a smart microwave oven, a smart kitchen treasure, a smart purifier, a smart water dispenser, a smart door lock, etc.

[0139] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for handling abnormalities in smart device upgrades, characterized in that: The method comprises: Acquire an upgrade exception code reported by the smart device, where the upgrade exception code is an identifier for indicating a specific reason for an upgrade exception of the smart device; Determine whether the upgrade exception code meets a first preset condition, where the first preset condition is a condition in a preset exception handling strategy for adding the smart device to a device upgrade blacklist; If it meets the requirements, the smart device is added to the device upgrade blacklist, and a removal condition is set for the smart device added to the device upgrade blacklist, wherein the removal condition is used to determine whether the smart device can be removed from the device upgrade blacklist under preset conditions.

2. The method for handling abnormal smart device upgrade according to claim 1, characterized in that: The method further comprises determining the first preset condition according to the following steps, comprising: Obtain multiple device upgrade exception reasons, and set a corresponding upgrade exception code for each of the device upgrade exception reasons; According to user needs, an automatic adding parameter is set for each of the device upgrade abnormality reasons, and the automatic adding parameter is a parameter used to indicate whether the smart device that has an upgrade abnormality caused by the device upgrade abnormality reason needs to be added to the device upgrade blacklist; Determine the exception handling strategy according to the upgrade exception code and automatic adding parameters corresponding to each of the device upgrade exception reasons; The first preset condition is determined according to the exception handling strategy.

3. The method for handling abnormal smart device upgrade according to claim 2, characterized in that: The determining the first preset condition according to the exception handling strategy includes: Acquire all upgrade exception codes of the target automatic addition parameter from the exception handling strategy to obtain a preset upgrade exception code range, wherein the target automatic addition parameter is an automatic addition parameter corresponding to adding to the device upgrade blacklist; Determine the number of exceptions corresponding to each upgrade exception code in the preset upgrade exception code range, where the number of exceptions is used to indicate the minimum number of times that the smart device added to the device upgrade blacklist needs to continuously report the upgrade exception code; The first preset condition is determined according to the preset upgrade exception code range and the number of exceptions.

4. The method for handling abnormal smart device upgrade according to claim 3, characterized in that: The determining whether the upgrade exception code meets the first preset condition includes: Determining whether the upgrade exception code meets a first preset condition according to the preset upgrade exception code range and the number of exceptions; If the upgrade exception code is within the preset upgrade exception code range and the number of times the smart device continuously reports the upgrade exception code is greater than or equal to the number of exceptions, it is determined that the upgrade exception code meets the first preset condition; If the upgrade exception code is not within the preset upgrade exception code range or the number of times the smart device continuously reports the upgrade exception code is less than the number of exceptions, it is determined that the upgrade exception code does not meet the first preset condition.

5. The method for handling abnormal smart device upgrade according to claim 2, characterized in that: After obtaining the upgrade exception code reported by the smart device, the method further includes: Determine whether the upgrade exception code exists in the exception handling strategy; If yes, proceed to the step of "determining whether the upgrade exception code meets the first preset condition"; If not, determining whether the smart device meets a second preset condition, where the second preset condition is a condition determined according to the number of times the smart device continuously reports the upgrade exception code; If yes, add the smart device to the device upgrade blacklist; If not, the smart device is not added to the device upgrade blacklist.

6. The method for handling abnormal smart device upgrade according to claim 5, characterized in that: The determining whether the smart device meets the second preset condition includes: Determine whether the number of times the smart device continuously reports the upgrade exception code is greater than or equal to a preset number; If so, it is determined that the smart device meets the second preset condition; if not, it is determined that the smart device does not meet the second preset condition.

7. The method for handling abnormal smart device upgrade according to any one of claims 1 to 6, characterized in that: The method further comprises: In response to a smart device in the device upgrade blacklist being reconnected to the network, it is determined whether to remove the smart device from the device upgrade blacklist according to the removal condition.

8. The method for handling abnormal smart device upgrade according to claim 7, characterized in that: The removal condition includes automatic joining, and the automatically joined smart device is a smart device that meets the first preset condition and is added to the device upgrade blacklist; The determining, according to the removal condition, whether to remove the smart device from the device upgrade blacklist includes: Determining whether the removal condition of the smart device is automatic joining; If yes, remove the smart device from the device upgrade blacklist; If not, the smart device is not removed from the device upgrade blacklist.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method for handling smart device upgrade anomalies according to any one of claims 1 to 8 when running.

10. 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 smart device upgrade anomalies according to any one of claims 1 to 8 through the computer program.

Images