Ota dynamic upgrading method, system and device for home appliance

Abstract

This application relates to an OTA dynamic upgrade method, system, and device for home appliances. The method includes: collecting operational data from the home appliances; analyzing the operational data, grouping devices with similar operational characteristics into the same device group based on the analysis results, and determining the algorithm upgrade requirements for each device group; breaking down the AI ​​algorithm into multiple levels, determining the target level to be upgraded based on the algorithm upgrade requirements, and generating a customized upgrade strategy for the target level; generating a differentiated upgrade package and sending it to the corresponding device to complete the update of the target level, and performing a rollback operation on the target level in the event of abnormal operation of the updated algorithm. This enables differentiated layered upgrades of AI algorithms, improves the device's personalized adaptation capability and upgrade efficiency, and reduces upgrade risks and ensures system operational stability through layered hot updates and partial rollback mechanisms.

Description

Technical Field

[0001] This application relates to the field of remote upgrade technology for smart home appliances in the next-generation information technology industry, and in particular to an OTA dynamic upgrade method, system and device for home appliances. Background Technology

[0002] Currently, smart home appliances, as a core component of the modern home environment, have seen their continuous AI algorithm evolution and remote maintenance capabilities become key indicators of product competitiveness. With the deep integration of the Internet of Things (IoT) and edge computing technologies, home appliances have evolved from single-function execution units into intelligent agents with sensing, decision-making, and execution capabilities. Among related technologies, Over-The-Air (OTA) technology enables remote updates of algorithm models, constructing a full-chain operation and maintenance system covering data collection, model iteration, policy distribution, and effect feedback.

[0003] However, the OTA upgrade solutions in related technologies directly adopt the strategy of replacing the entire model or updating the entire application layer without fine-grained splitting and hierarchical processing of the model structure for the differences in device operation. This may result in devices under different usage environments and user habits not receiving personalized algorithm optimization, or due to the lack of layered loading and partial rollback mechanisms in the upgrade process, the entire rollback or restart may be forced when the algorithm is abnormal, thereby affecting the reliability of home appliances in continuous operation scenarios and significantly increasing upgrade risks and recovery costs. Summary of the Invention

[0004] To address the aforementioned technical issues of lacking a refined AI algorithm upgrade mechanism based on device operational differences and lacking layered update and fine-grained rollback capabilities, this application provides an OTA dynamic upgrade method, system, device, and medium for home appliances. The specific technical solution is as follows: In a first aspect, this application provides an OTA dynamic upgrade method for home appliances, the method comprising: Collect operating data of home appliances and upload the operating data to a cloud server. The operating data includes equipment operating parameters, user operation behavior and equipment abnormal status information. The operational data is analyzed, and devices with similar operational characteristics are grouped into the same device group based on the analysis results. The algorithm upgrade requirements of each device group are then determined. The AI ​​algorithms of the device group to be upgraded are divided into multiple levels. Based on the algorithm upgrade requirements, the target level to be upgraded is determined, and a customized upgrade strategy for the target level is generated. Based on the customized upgrade strategy, a differentiated upgrade package is generated and sent to the corresponding device for loading to complete the update of the target level. In the event of an abnormal operation of the updated algorithm, a rollback operation is performed on the target level.

[0005] In an optional implementation, the step of analyzing the operational data, dividing devices with similar operational characteristics into the same device group based on the analysis results, and determining the algorithm upgrade requirements for each device group includes: judging user usage habits, environmental characteristics, and whether the devices have various abnormal situations based on the operational data; dividing the devices into groups based on the judged device operational characteristics using preset device grouping rules, machine learning-based clustering algorithms, deep learning models, or reinforcement learning upgrade strategies; and determining whether each divided device group needs AI algorithm upgrades and the corresponding upgrade targets.

[0006] In one optional implementation, the step of splitting the AI ​​algorithm of the group of devices to be upgraded into multiple levels, determining the target level to be upgraded based on the algorithm upgrade requirements, and generating a customized upgrade strategy for the target level includes: splitting the AI ​​algorithm into a control logic layer, a parameter configuration layer, and a model structure layer; determining the target level to be upgraded among the multiple split levels by performing fault tracing and attribution analysis, wherein the fault tracing and attribution analysis includes: analyzing the importance of features by comparing the decision paths of similar high-quality devices and the devices to be upgraded, and determining the level where the root cause of the problem lies; and performing strategy deconstruction and reconstruction for the target level to generate the customized upgrade strategy.

[0007] In an optional implementation, the fault tracing and attribution analysis further includes: for air conditioning equipment, if the indoor temperature feature weight is lower than the threshold and the running time feature weight is higher than the threshold, the root cause of the problem is identified as a logical deviation, and the control logic layer is determined to be updated; if the parameter value deviation exceeds the preset range, the parameter configuration layer is determined to be updated; if the AI ​​model is insufficiently fitted to a specific working condition, the model structure layer is determined to be updated.

[0008] In an optional implementation, the deconstruction and reconstruction of the execution strategy for the target level includes: decomposing the rigid logic in the original strategy into a Bayesian network of environment perception, user intent, and device response, and embedding a debouncing mechanism and a predictive control module into the Bayesian network; controlling the Bayesian network to learn user habits and generate an adjusted update strategy; verifying the effectiveness of the update strategy through a simulation sandbox, and generating a configuration file containing the update strategy and rollback trigger conditions.

[0009] In an optional implementation, the step of generating differentiated upgrade packages according to the customized upgrade strategy and distributing them to the corresponding devices for loading includes: matching the device group tags with the target level through a strategy template library, removing irrelevant modules from the general strategy template, and extracting specific strategy plugins; comparing the binary differences between the current device-side strategy file and the cloud-updated strategy file to generate a lightweight differential file, wherein the differential file embeds logical change strategies and parameter offsets; compiling and adapting the differential file in conjunction with the hardware fingerprint in the device profile, and installing constraints and verification fingerprints at the packet header encapsulation point to generate the differentiated upgrade package; and, based on the network quality and power consumption status reported by the home appliances, arranging the differentiated upgrade package into a distribution queue through a scheduling engine and distributing it to the corresponding devices.

[0010] In an optional implementation, completing the update of the target level and performing a rollback operation on the target level in the event of an abnormal operation of the updated algorithm includes: loading the differentiated upgrade package on the control device side without interrupting operation and retaining the old version as a backup; when an abnormal operation of the updated AI algorithm is detected, determining the type of abnormality and rolling back the target level with abnormality after the update according to the type of abnormality.

[0011] In an optional implementation, after the rollback update of the target level where an anomaly exists, the method further includes: packaging and uploading the operation logs before and after the anomaly to the cloud, wherein the operation logs include sensor sequences, decision paths, and resource usage information; entering the incident review pipeline, comparing the inference logs of the update strategy with the decision trajectory of the original strategy, locating the abnormal strategy branch, re-determining the target level to be upgraded, and generating a secondary upgrade strategy; overlaying a pitfall avoidance patch into the secondary upgrade strategy, adding the conditions that trigger rollback to the device's strategy blacklist scenario, and after verifying through a simulation sandbox that the rollback conditions are no longer triggered, generating a secondary differential package and sending it to the corresponding device.

[0012] In an optional implementation, after the target level update is completed, the method further includes: synchronously updating the data display rules on the APP, adjusting the display metrics on the APP to be consistent with the current algorithm; and feeding back the upgraded running data to the cloud server for subsequent algorithm optimization to generate a continuously iterating closed-loop logic.

[0013] In an optional implementation, the subsequent algorithm optimization to generate a continuously iterative closed-loop logic includes: adding an algorithm version tag to the data returned by the upgraded device, comparing it longitudinally with the baseline before the upgrade, and merging the comparison indicators into the effect evaluation pool of the device group; when the sample size in the effect evaluation pool reaches a statistical threshold, triggering a strategy solidification process to upgrade the upgrade strategy from the experimental version to the baseline strategy template of the device group; performing attribution analysis on cases where the upgraded effect does not meet expectations or rollback occurs, and when the proportion of abnormal cases exceeds a threshold, triggering a secondary cluster split of the device group to divide extreme conditions into independent subgroups, and training new parameter sub-strategies for the independent subgroups.

[0014] In an optional implementation, the method further includes: using online incremental learning to return the triplet data of environmental status, user temperature adjustment, and energy consumption of each upgraded device to the original model for training, or using contrastive learning to increase the latent space distance between different decisions to generate an iterative version of the model; and updating the real-time display content of the APP to be consistent with the current upgrade logic of the backend.

[0015] In one optional implementation, the collection of operating data of home appliances includes: continuously collecting the operating parameters of the appliances through data acquisition devices built into the appliances, or uniformly collecting the operating parameters of each appliance through a grid device; indirectly collecting user operation behavior through user terminal devices; and obtaining environmental data or device linkage data through a third-party smart home platform.

[0016] Secondly, this application provides an OTA dynamic upgrade system for home appliances, comprising: The data acquisition module is used to collect the operating data of home appliances and upload the operating data to the cloud server. The operating data includes equipment operating parameters, user operation behavior and equipment abnormal status information. The analysis module is used to analyze the operating data, divide devices with similar operating characteristics into the same device group based on the analysis results, and determine the algorithm upgrade requirements of each device group. The generation module is used to break down the AI ​​algorithms of the device group to be upgraded into multiple levels, determine the target level to be upgraded based on the algorithm upgrade requirements, and generate a customized upgrade strategy for the target level. The update module is used to generate differentiated upgrade packages according to the customized upgrade strategy and send them to the corresponding devices for loading to complete the update of the target level. In the event of an abnormal operation of the updated algorithm, the module performs a rollback operation on the target level.

[0017] Thirdly, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the OTA dynamic upgrade method for any of the home appliances described in the first aspect above.

[0018] Fourthly, a storage medium is also provided, wherein the storage medium stores instructions that, when run on a computer, cause the computer to execute the OTA dynamic upgrade method for any of the home appliances described in the first aspect above.

[0019] Fifthly, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the OTA dynamic upgrade method for any of the home appliances described in the first aspect above.

[0020] The technical solutions provided in this application have the following advantages compared with the prior art: The method provided in this application deeply integrates device operation data analysis with the hierarchical structure of AI models. This allows upgrade decisions to not only determine whether to upgrade, but also which layer of the model to upgrade and the content of the upgrade, thus shifting from traditional overall upgrades to fine-grained, differentiated upgrades. This significantly improves the adaptability of AI algorithms in different usage environments, enhances the operating efficiency and energy efficiency of home appliances such as air conditioners, and reduces resource consumption caused by ineffective upgrades. Furthermore, this application integrates the AI ​​algorithm upgrade process with an anomaly detection mechanism, introducing a control method combining layered updates and layered rollbacks. This enables the system to achieve partial recovery without interrupting operation, rather than a traditional overall rollback. This effectively reduces the risk of AI algorithm upgrades, improves system stability, ensures continuous operation of home appliances during the upgrade process, and enhances the user experience. Therefore, this application can generate fine-grained, layered AI algorithm upgrade strategies based on device operation differences, achieving precise upgrades on demand and improving algorithm adaptability and device operating efficiency. Simultaneously, through layered hot updates and graded rollback mechanisms, upgrade risks are reduced, ensuring continuous and stable system operation. Attached Figure Description

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

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

[0023] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0024] Figure 1 A flowchart illustrating an OTA (Over-The-Air) dynamic upgrade method for home appliances provided in this application embodiment; Figure 2 A flowchart illustrating a specific OTA dynamic upgrade method for home appliances provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an OTA dynamic upgrade system for home appliances provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0027] For ease of description, spatial relative terms may be used in the text to describe the relative position or movement of one element or feature relative to another element or feature, as shown in the figure. These relative terms include, for example, "inside," "outside," "middle," "outer," "below," "below," "above," "front," "back," etc. Such spatial relative terms are intended to include different orientations of the device in use or operation, other than those depicted in the figure. For example, if the device in the figure undergoes a positional flip, orientation change, or change of motion, these directional indications will change accordingly. For instance, an element described as "below other elements or features" or "below other elements or features" will subsequently be oriented "above other elements or features" or "above other elements or features." Therefore, the example term "below" can include both upper and lower orientations. The device may be otherwise oriented, and the spatial relative descriptors used in the text will be interpreted accordingly.

[0028] This application proposes an OTA dynamic upgrade method, system, device, and medium for home appliances.

[0029] Figure 1 A flowchart illustrating an OTA dynamic upgrade method for home appliances provided in this application embodiment is shown below. Figure 1 As shown, the method includes the following steps: Step S101: Collect the operating data of the home appliances and upload the operating data to the cloud server. The operating data includes the operating parameters of the equipment, user operation behavior and abnormal status information of the equipment.

[0030] Specifically, collecting operational data from home appliances and uploading it to a cloud server is a fundamental prerequisite for implementing differentiated algorithm upgrades. This operational data includes equipment operating parameters reflecting the device's working status and performance, user operating behaviors reflecting user preferences and patterns, and abnormal device status information used to identify potential faults or malfunctions.

[0031] The device can collect and aggregate the aforementioned multi-dimensional data periodically or through event-triggered methods, and then upload the data to a cloud server via a network transmission channel for subsequent analysis and processing. The scope and granularity of the collected operational data can be adaptively configured according to the device type, application scenario, and upgrade decision requirements. This includes physical quantity information sensed by internal sensors, status records generated during the operation of the device's control logic, and behavioral traces formed during user interaction with the device. To ensure that the data accurately reflects the overall operation of the device, the collection process can perform necessary preprocessing on the raw data, such as removing redundant information, standardizing data formats, or adding time stamps, thereby improving data integrity. The upload process can employ different methods such as batch transmission or streaming transmission, and the transmission strategy can be dynamically adjusted according to network conditions to ensure the timeliness and reliability of data arrival.

[0032] As an example, air conditioning equipment continuously collects information such as indoor temperature, set temperature, fan speed, compressor start-stop frequency, user adjustment habits, and abnormal status information such as frequent start-stop or slow cooling during operation. After simple processing, this data is periodically uploaded to a cloud server via the network, thereby providing data support for the cloud to accurately perceive the actual usage habits and operating status of the equipment.

[0033] Therefore, by collecting and uploading multi-dimensional device operation data in the above manner, a comprehensive and accurate analytical foundation can be provided for the cloud server, making it possible to formulate differentiated algorithm upgrade strategies based on the different operating characteristics of different devices. At the same time, it provides reliable data basis for upgrade decisions, thereby effectively improving the pertinence and effectiveness of algorithm upgrades.

[0034] Step S102: Analyze the operating data, divide devices with similar operating characteristics into the same device group based on the analysis results, and determine the algorithm upgrade requirements of each device group.

[0035] Specifically, analyzing operational data to uncover underlying equipment operating patterns and status characteristics forms the basis for developing differentiated upgrade strategies. This analysis process aims to extract key information reflecting the actual usage, operational efficiency, and potential problems of equipment from massive, multi-dimensional operational data. Its analytical dimensions cover trends in equipment operating parameters, patterns in user operational behavior, and the occurrence patterns of abnormal equipment states.

[0036] Furthermore, based on the feature information obtained from the analysis, and according to the preset similarity judgment criteria, devices with significant commonalities in their operating characteristics are grouped into the same device group, thereby mapping the differentiated status of individual devices to the common needs at the group level.

[0037] Based on the completion of device grouping, further assessments are conducted on the common operational characteristics and existing problems of each device group. The degree of matching between the currently installed AI algorithm and the actual operational requirements is comprehensively evaluated. Based on this, it is determined whether the group needs an algorithm upgrade and the specific goals to be achieved by the upgrade are clarified. These upgrade goals can be directional technical expectations such as improving specific performance indicators, optimizing resource consumption, or improving user experience.

[0038] Through the above analysis, segmentation, and demand determination process, the transformation from raw operational data to clearly defined upgrade tasks was achieved, providing a basis for decision-making in formulating targeted upgrade strategies.

[0039] As one implementation method, equipment operation data can be analyzed to identify user habits, environmental characteristics, and equipment efficiency or abnormal conditions. Equipment with similar characteristics can then be classified into the same type. Based on the common characteristics of this type of equipment, it can be determined whether an algorithm upgrade is needed and what the upgrade should achieve. For example, equipment with high-frequency cooling requirements and high energy consumption can be classified and the upgrade goal can be determined to improve cooling efficiency and reduce energy consumption.

[0040] Therefore, this step can transform scattered equipment operation data into structured group demand cognition, enabling algorithm upgrade decisions to shift from a uniform, extensive model to a refined model based on the actual differences in equipment operation. This allows for matching the most suitable upgrade direction to different equipment groups, improving the utilization efficiency of upgrade resources, and laying the foundation for personalized, on-demand algorithm optimization.

[0041] Step S103: The AI ​​algorithm of the device group to be upgraded is divided into multiple levels. Based on the algorithm upgrade requirements, the target level to be upgraded is determined, and a customized upgrade strategy for the target level is generated.

[0042] Specifically, in this step, the system divides the AI ​​algorithm into several independently identifiable and operable hierarchical structures according to its functional logic and data dependencies. Each level corresponds to different processing mechanisms and parameter configurations during the algorithm's operation.

[0043] Furthermore, based on the device groups and their upgrade requirements identified in the preceding steps, the system locates the target level causing the current performance deviation or functional defect within the hierarchical structure, considering the operational characteristics and optimization objectives of the group. A customized upgrade strategy is then generated solely around this target level. The generation process of this customized upgrade strategy includes analyzing and reconstructing the internal logic of the target level. Based on the common characteristics and individual differences of the device group, the system determines the functional modules, control logic, or parameter values ​​that need adjustment within this level, forming an update scheme that matches the target level. This update scheme performs local optimization of the algorithm within the hierarchical boundaries without involving changes to other levels, thereby maintaining the stability and compatibility of the overall algorithm structure while meeting upgrade requirements.

[0044] As one implementation method, the system can use fault tracing and attribution analysis to compare the decision path differences between similar high-quality equipment and equipment to be upgraded, locate the level to which the root cause of the problem belongs, and then perform strategy deconstruction and reconstruction on that level to generate a differential configuration file containing logical changes and parameter adjustments, along with rollback trigger conditions, so as to achieve accurate and safe layered hot updates.

[0045] Thus, this step realizes the transformation of AI algorithm upgrade from overall replacement to hierarchical and refined control, enabling the upgrade operation to be precisely applied to the algorithm level where the root cause of the problem lies, significantly reducing resource consumption and operational risks during the upgrade process, while providing a fine-grained control basis for subsequent generation of differentiated upgrade packages and partial rollback operations.

[0046] Step S104: Generate differentiated upgrade packages according to the customized upgrade strategy and send them to the corresponding devices for loading to complete the update of the target level. If the updated algorithm fails to run, perform a rollback operation on the target level.

[0047] Specifically, this step generates differentiated upgrade packages based on customized upgrade strategies and distributes them to the corresponding devices. The devices load the upgrade packages while in operation to complete the update of the target level. When an abnormality is detected in the updated algorithm, a rollback operation is performed only on the target level.

[0048] Specifically, the cloud server generates an upgrade package that matches the device based on the upgrade needs of the device group and the determined target level, combined with the individual differences of each device. The upgrade package only contains updates for the target level, rather than a complete replacement of the device's overall algorithm or program.

[0049] The upgrade package generation process is based on an analysis of the differences between the current device-side algorithm state and the target update content. It extracts the minimum change data and encapsulates it into an independently transmittable and loadable upgrade file, significantly reducing the data size and bandwidth consumption of the upgrade package. Simultaneously, during upgrade package generation, compatibility processing is performed based on the device's hardware configuration and operating environment to ensure the generated upgrade package can be correctly recognized and loaded by the target device. Furthermore, the upgrade package encapsulates corresponding installation constraints and verification information to guarantee the security and reliability of the upgrade process.

[0050] Furthermore, after the upgrade package is generated, it is distributed to the corresponding device via OTA. The distribution process can be scheduled according to the real-time operating status of the device and network conditions, such as selecting a time when the device is idle or when the network conditions are good to transmit, so as to avoid interfering with the normal operation of the device and the user experience.

[0051] Furthermore, upon receiving the upgrade package on the device side, the upgrade package is loaded while maintaining uninterrupted operation. Only the target level is updated, while other levels remain unchanged. After the update is complete, the device continuously monitors the running status of the updated algorithm. If an anomaly is detected, a rollback operation is performed only on the target level, restoring it to the state before the update, without needing to restore other levels or the entire system.

[0052] As one implementation method, the cloud uses a policy template library to accurately match devices based on their grouping tags and the level to be updated, eliminating irrelevant modules and extracting only specific policy plugins. It also compares the binary differences between the current policy file on the device and the new policy file on the cloud to generate a lightweight differential file. This file embeds specific logical change parameters and is compiled and adapted in conjunction with the device's hardware fingerprint. The packet header encapsulates installation constraints and verification fingerprints. Finally, the scheduling engine arranges the customized differential packets into the distribution queue based on the network quality and power consumption status reported by the device, achieving precise delivery of one policy per device.

[0053] Therefore, this step enables differentiated generation and precise distribution of upgrade packages, significantly reducing the amount of upgrade data and transmission resource consumption. At the same time, through the target-level loading and partial rollback mechanism under device-side operating conditions, the impact of the upgrade process on the continuous operation of the device is effectively reduced, improving the security and reliability of the upgrade operation and ensuring user experience.

[0054] The following describes the specific implementation process of each step in the OTA dynamic upgrade method for home appliances of this application using several specific embodiments.

[0055] In this embodiment, step S101 involves collecting the operating data of the home appliances and uploading the operating data to the cloud server. The specific implementation method is as follows.

[0056] First, home appliances continuously collect operational data using their built-in sensors and control units. For example, in a smart air conditioner, the temperature sensor monitors the indoor temperature in real time, the control unit records the set temperature, fan speed, and compressor start / stop frequency, and the device's main control logic captures the user's adjustment habits, such as the user frequently lowering the set temperature from 26℃ to 24℃, and detects whether the device exhibits abnormal conditions such as frequent start / stop or slow cooling. All of this data is initially processed and formatted locally on the device, forming a structured operational data record.

[0057] In one possible implementation, the collection of the aforementioned operational data is not limited to the home appliances themselves. It can also be collected uniformly through home gateways or edge gateways, or indirectly through user terminal devices to collect user operation behavior. Alternatively, it can obtain environmental data or device linkage data through third-party smart home platforms. These multiple collection methods can complement each other to enrich the data dimensions.

[0058] Subsequently, the devices periodically upload the processed operational data to the cloud server via the network module. The upload cycle can be set according to the device type or network conditions, such as batch transmission during low-usage periods at night, to ensure timely data reporting and efficient use of network resources. As a result, the cloud server obtains a complete dataset containing device operating parameters, user operation behaviors, and abnormal device status information, providing a data foundation for subsequent device grouping and upgrade requirement analysis.

[0059] Therefore, this embodiment realizes the collection and reliable uploading of multi-dimensional and fine-grained data on the operating status of home appliances, providing sufficient and accurate data support for the cloud to accurately identify differences in device operation and formulate personalized upgrade strategies, thereby ensuring the effectiveness and pertinence of subsequent differentiated upgrade decisions.

[0060] In this embodiment, step S102 analyzes the running data, divides devices with similar running characteristics into the same device group based on the analysis results, and determines the algorithm upgrade requirements of each device group. The specific implementation method is as follows.

[0061] First, the cloud server receives the operating data uploaded by the home appliance in step S101. This operating data includes the device's operating parameters, user operation behavior, and abnormal device status information.

[0062] Subsequently, the cloud analyzes and extracts features from the above data to determine the user's usage habits, environmental characteristics, and whether the device has efficiency problems or abnormalities from multiple dimensions.

[0063] For example, user habits can be characterized by the frequency, magnitude, and timing of temperature adjustments; environmental characteristics can be inferred by combining external data such as outdoor temperature and humidity in the area where the equipment is located, as well as indoor temperature trends; and whether the equipment has efficiency issues or abnormalities can be comprehensively evaluated by indicators such as compressor start-stop frequency, runtime percentage, energy consumption deviation, and abnormal alarm records.

[0064] In one possible implementation, the above analysis process can be automated using machine learning-based clustering algorithms. For example, the K-means algorithm or DBSCAN algorithm can be used to perform unsupervised clustering of device feature vectors, thereby automatically grouping devices with similar operating characteristics into the same device group. Alternatively, deep learning models can be used to predict and classify user behavior, or reinforcement learning can be used to dynamically adjust upgrade strategies based on real-time feedback. Through the above analysis, the system can identify device groups with typical characteristics, such as "high-temperature areas + frequent cooling needs + high energy consumption" or "nighttime users".

[0065] Building upon this foundation, for each device group, the system further determines whether an AI algorithm upgrade is needed and the upgrade objectives. These objectives may include specific optimization directions such as improving cooling efficiency, reducing energy consumption, or enhancing comfort. The output of this step is device grouping information with group tags and upgrade requirement identifiers. This information will serve as input for subsequent steps to determine the upgrade target level and generate customized upgrade strategies, thereby ensuring the targetedness and effectiveness of subsequent upgrade decisions.

[0066] Therefore, this embodiment can achieve refined equipment grouping and upgrade demand determination based on actual equipment operation data, transforming upgrade decisions from a unified overall strategy to a differentiated strategy for different equipment groups, thereby improving the adaptability of AI algorithm upgrades and resource utilization efficiency.

[0067] In this embodiment, in step S103, the AI ​​algorithm of the device group to be upgraded is divided into multiple levels, the target level to be upgraded is determined based on the algorithm upgrade requirements, and a customized upgrade strategy for the target level is generated. The specific implementation method is as follows.

[0068] First, the system logically divides the AI ​​algorithm into three independently updatable layers: the control logic layer, the parameter configuration layer, and the model structure layer.

[0069] The control logic layer contains the decision rules and strategy branches for device operation, the parameter configuration layer stores various adjustable coefficients and thresholds in the control algorithm, and the model structure layer corresponds to the weight parameters and network topology of models such as neural networks. Each layer is stored in a modular manner on the device side and has an independent version identifier and loading interface, thus providing a structural foundation for subsequent differentiated updates and partial rollbacks.

[0070] After hierarchical decomposition, the system performs fault tracing and attribution analysis to determine the target level to be upgraded. The inputs to this analysis process are the equipment group information defined in step S102, the operating data of the equipment to be upgraded, and the decision path data of similar high-quality equipment pre-stored in the cloud. The processing actions include: comparing the decision path of the equipment to be upgraded under the same operating conditions with the decision paths of similar high-quality equipment node by node, and calculating the contribution weight of each input feature to the decision output based on the feature importance analysis method. When the comparison results show that the weight of the indoor temperature feature is significantly lower than the benchmark value, while the weight of the operating time feature is significantly higher than the benchmark value, the system determines that the root cause of the problem lies in the deviation of the strategy logic of the control logic layer, rather than inaccurate parameter values ​​or model structure failure, and therefore determines that only the control logic layer needs to be updated. When the analysis results show that the deviation between the actual value and the optimal reference value of a certain parameter exceeds a preset range, it is determined that the parameter configuration layer needs to be updated. When the analysis results show that the fitting error of the model under a specific operating condition continuously exceeds a threshold and cannot be eliminated by adjusting parameters or modifying logic, it is determined that the model structure layer needs to be updated. The output of this step is a clear target level identifier and the corresponding fault attribution results.

[0071] After determining the target level as the control logic layer, the system performs policy deconstruction and reconstruction operations for this level. The inputs to this operation are the policy rule set in the original control logic layer, the upgrade targets of the device group, and the fault attribution results.

[0072] For example, the processing actions include: deconstructing the rigid logic of "full-speed cooling whenever the user lowers the temperature" in the original strategy, and reconstructing it into a Bayesian network with environmental perception, user intent, and device response as nodes, and embedding an anti-jitter mechanism and a predictive control module into this network. The anti-jitter mechanism is used to merge repeated user temperature adjustment commands within a short period to avoid frequent device start-ups and shutdowns; the predictive control module is used to predict user needs based on historical behavior patterns. Simultaneously, the system adjusts the original fixed PID parameters to load-based dynamic parameters; specifically, the integral coefficient Ki in the low-frequency oscillation range is reduced from 0.05 to 0.02 to reduce overshoot. Furthermore, the system activates a user habit learning sub-strategy in the strategy library, allowing pre-cooling 15 minutes in advance if the user lowers the temperature at 10 PM for three consecutive days.

[0073] After completing the above reconstruction, the system verifies the new strategy through a simulation sandbox. Continuing with the example above, when the simulation shows an 18% reduction in energy consumption and no temperature overshoot, a differential configuration file containing only strategy logic changes is generated. This file does not involve changes to model weights or structure and includes a rollback trigger condition: a partial rollback is triggered if a temperature fluctuation exceeding ±1.5℃ is detected within 5 minutes. The output of this step is a customized upgrade strategy file for the control logic layer, which is used in subsequent steps to generate differentiated upgrade packages.

[0074] Therefore, this embodiment breaks down the AI ​​algorithm into a control logic layer, a parameter configuration layer, and a model structure layer. By combining fault tracing and attribution analysis to accurately locate the problem level, and then performing strategy deconstruction and reconstruction for that level, it achieves a shift from overall upgrade to fine-grained layered upgrade. This significantly reduces resource consumption and operational risks during the upgrade process, while improving the matching accuracy between the upgrade strategy and the actual operating requirements of the equipment.

[0075] In this embodiment, the specific implementation method of generating differentiated upgrade packages according to the customized upgrade strategy and sending them to the corresponding devices for loading to complete the target level update is as follows.

[0076] First, after receiving the device group tags (e.g., "high temperature and high load" or "high energy consumption") output in step S102 and the update level (e.g., policy layer) determined in step S103, the cloud server enters the upgrade package generation stage. This stage uses the device group tags and the update level as input and performs precise matching through a preset policy template library.

[0077] For example, for the "high energy consumption" group to which the air conditioner belongs, the system will remove modules in the general strategy template that are not related to the group, such as "humidification linkage" or "extreme cold mode", and only extract specific strategy plugins that are directly related to the current upgrade target, such as the "dynamic temperature control optimization" plugin, thereby completing the tailoring and matching of the strategy template and outputting a set of strategies to be updated that only contain relevant strategy logic.

[0078] Subsequently, the system performs a differential build operation. This operation takes the policy file currently deployed on the device and the newly generated policy file in the cloud as input, and generates a lightweight patch differential file through a binary difference comparison algorithm. For example, this differential file only accounts for 3% to 5% of the original policy package size. It embeds specific logical changes in a structured data format, adjusting the "user manual temperature adjustment response priority" from the highest priority to the second highest priority, and writing new parameter offsets, such as setting the "pre-cooling time offset" to 15 minutes. This differential file is the smallest upgrade unit subsequently issued, and its output is directly used as the input for the next compilation and adaptation step.

[0079] Next, the system compiles and adapts the differential file using the hardware fingerprint information from the device profile. For example, the hardware fingerprint includes key hardware attributes such as the device's MCU model and remaining Flash memory. The compilation and adaptation process aims to ensure that the instruction set in the differential file is fully compatible with the target device's hardware platform, avoiding upgrade failures due to instruction set incompatibility. After compilation, the system encapsulates installation constraints and verification fingerprints in the differential file header. The installation constraints specifically limit upgrade installation to be triggered only between 2 AM and 5 AM when the indoor temperature is above 25°C. The verification fingerprint is used by the device to verify the integrity and legitimacy of the upgrade package's origin. This step outputs a fully packaged, device-specific customized differential package.

[0080] Finally, the scheduling engine places the customized differential packet into the distribution queue based on the network quality parameters and current power consumption reported by the device. For example, the network quality parameter is determined by a Wi-Fi signal strength greater than -65dBm, and the power consumption status requires the device to be in a low-power standby window. Taking into account these conditions, the scheduling engine selects a time when the network conditions are good and the device is in a low-power standby state to send the differential packet to the corresponding device, thereby achieving precise delivery with a "one device, one policy" approach while ensuring extremely low bandwidth usage.

[0081] Therefore, through the above-described implementation methods, this application can significantly reduce the amount of data transmitted during the OTA upgrade process, reduce interference with the normal operation of the device and the user's network, and effectively improve the compatibility of the upgrade package on different hardware platforms and the security of the installation process through hardware fingerprint adaptation and installation constraint encapsulation, thereby achieving refined and low-risk upgrade delivery for individual devices.

[0082] In this embodiment, the specific process of performing layered hot updates and abnormal rollbacks on the device side is as follows.

[0083] After receiving the differential packet from the cloud, the device first performs an integrity check on the upgrade package. Once the verification fingerprint is confirmed to be correct, the new algorithm is loaded into a pre-defined independent storage partition without interrupting the current operation. Simultaneously, the currently running old version algorithm is completely preserved in a backup partition, creating a coexisting operating architecture. This loading process employs a hot-switching mechanism; that is, after the new algorithm completes its initialization in the background, an atomic pointer switch redirects the runtime traffic to the new version. The switching process is imperceptible to the user, and the device continues to maintain its original control functions.

[0084] After the hot update is completed, the equipment enters the anomaly monitoring phase. The system collects real-time equipment operating status data, including key indicators such as compressor start-stop frequency and temperature fluctuation amplitude, and compares these indicators with preset anomaly judgment thresholds. When anomalies such as frequent start-stops or increased temperature fluctuations are detected after the upgrade, the system automatically classifies the anomaly as a policy anomaly and triggers a partial rollback operation targeting only the policy layer. This rollback operation restores the policy layer to its pre-upgrade state by calling the old version policy file in the backup partition, while the model structure layer and parameter layer remain unchanged. The overall equipment operation is uninterrupted, avoiding the large-scale impact of traditional overall rollback methods.

[0085] After completing the partial rollback, the device immediately packages and uploads the operational logs before and after the anomaly to the cloud. These logs specifically include sensor sequence data, decision path records, and resource usage information. Upon receiving these logs, the cloud enters the incident review pipeline, comparing the inference logs of the new strategy with the decision trajectory of the original strategy branch by branch to locate the strategy branch that triggered the anomaly.

[0086] For example, when anomalies are concentrated in the oscillation period triggered after 15 minutes of pre-cooling, the system determines that the strategy logic is correct but the parameter settings are too aggressive, attributing the anomaly to parameter layer mismatch. In subsequent upgrades, the pre-cooling time is adjusted to 8 minutes, and the integral coefficient Ki is kept at 0.05 without being lowered. When oscillations occur in all temperature control scenarios and are irregular, the system determines that the anti-shake mechanism threshold setting in the strategy layer is incorrect, attributing the anomaly to a logic error in the strategy layer. In subsequent upgrades, the system rolls back to the previous version of the strategy and only fine-tunes the anti-shake threshold. When the old strategy also exhibits slight anomalies under the same operating conditions after the rollback, the system determines that the root cause is insufficient fitting of the structural layer model to the high-temperature and high-humidity coupled scenario, requiring retraining of the small-sample adaptation model of the structural layer.

[0087] After identifying the new upgrade level, the system adds a pitfall avoidance patch to the original policy template, adds the current rollback trigger condition to the device's policy blacklist scenario, and performs multiple verifications through a simulation sandbox. Once it is confirmed that the rollback conditions will no longer be triggered, a secondary differential packet is generated and sent to the device. In addition, the entire retry chain has a circuit breaker mechanism. If the same device fails to roll back three times consecutively, the system automatically exits the automated process and switches to the manual annotation and structural layer retraining branch to avoid infinite loops.

[0088] Therefore, through the aforementioned layered hot update and local rollback mechanism, this embodiment achieves accurate anomaly location and minimized impact recovery during the AI ​​algorithm upgrade process, significantly reducing upgrade risks and ensuring high reliability of home appliances in continuous operation scenarios.

[0089] In this embodiment, after the AI ​​algorithm is upgraded, the data display rules on the APP are updated synchronously to make the displayed indicators consistent with the current algorithm, and the upgraded running data is fed back to the cloud for subsequent algorithm optimization. The specific implementation method of forming a continuous iteration closed loop logic is as follows.

[0090] After the cloud server completes the AI ​​algorithm upgrade, it first tags the running data returned by the upgraded device with the algorithm version, such as marking it as version V2, and then compares it with the baseline data of version V1 before the upgrade with the same device.

[0091] As an example, taking air conditioning equipment as an illustration, the comparison indicators include the average daily power consumption after the upgrade and the frequency of manual temperature adjustment by users. For example, the average daily power consumption decreased from 8 kWh to 6.5 kWh, and the frequency of manual temperature adjustment decreased from 12 times per day to 4 times per day. These comparison results are incorporated into the effect evaluation pool of the group to which the equipment belongs (such as the "high temperature area + high frequency cooling + high energy consumption" group). When the sample size in the effect evaluation pool reaches a statistically significant level, for example, when the average energy saving of 500 devices in the same group reaches more than 15% after the upgrade and there is no rollback record, the cloud triggers the policy solidification process, promoting the upgrade policy from the experimental version to the benchmark policy template for the group. Subsequent new devices joining the network in the same group can directly receive this template without having to perform a full analysis again.

[0092] Furthermore, for cases where the upgrade results are not as expected or a rollback occurs, the cloud performs attribution analysis based on its unique characteristics. For example, if an outdoor unit faces west and is exposed to direct sunlight, causing the ambient temperature to remain above 42°C, the power consumption may increase to 8.5 degrees Celsius after the upgrade. When such abnormal cases account for more than 5%, a secondary cluster split is triggered, separating extreme operating conditions (such as "extreme high temperature + west-facing sun") into independent subgroups, and new parameter sub-strategies are trained accordingly, such as extending the pre-cooling time to 25 minutes and limiting the power of the compressor at high frequencies.

[0093] Based on this, the cloud also adopts an online incremental learning method to feed the environmental status, user temperature adjustment and energy consumption triplet data of each device after the upgrade back into the original model for training, or adopts comparative learning to widen the implicit space distance between energy-saving comfort decisions and high-consumption and low-efficiency decisions, thereby generating model iteration versions such as V2.1 and V2.2.

[0094] Furthermore, the intelligent energy-saving index calculation formula displayed on the APP is synchronously distributed with the algorithm version. The initial calculation formula is (baseline power consumption - actual power consumption) / baseline power consumption. After the introduction of a comfort penalty term, the calculation formula becomes energy saving rate multiplied by comfort weight, where the comfort penalty term is the frequency of manual temperature adjustment by the user. The formula version is updated synchronously with the algorithm version to ensure that the front-end display and back-end logic are always consistent. The above feedback loop mechanism enables the system to move from one-time optimization to continuous self-evolution, forming a spiral upward path of "single unit upgrade verification → group effect convergence → strategy template accumulation → subgroup re-splitting → model incremental training".

[0095] Therefore, this embodiment realizes the closed loop of data display synchronization and effect feedback after AI algorithm upgrade, enabling the upgrade strategy to be continuously iterated and optimized based on actual operating data, significantly improving the algorithm's adaptability and long-term operating efficiency in different device groups, while reducing the probability of invalid upgrades and abnormal rollbacks through strategy solidification and subgroup splitting mechanisms.

[0096] This embodiment describes in detail the complete implementation process of an OTA dynamic upgrade method for AI algorithms in home appliances according to this application. This method is applicable to smart home appliances such as air conditioners, refrigerators, and washing machines, and is particularly suitable for application scenarios requiring remote upgrades and dynamic effect feedback of AI algorithms without interrupting operation. This embodiment mainly uses an air conditioner as an example for illustration, and the implementation process of the method is as follows: Figure 2 As shown.

[0097] In this embodiment, the system architecture comprises three main components: the device itself, the cloud server, and the user terminal device. The device itself is the home appliance, which integrates sensors, a control unit, a communication module, and a storage module. Sensors collect various physical data during device operation, the control unit executes AI algorithms and controls the device's operating status, the communication module interacts with the cloud server, and the storage module saves the currently running algorithm version and historical backup versions. The cloud server is a remote service platform with computing and storage capabilities, deployed with modules for data analysis, device grouping, algorithm hierarchical management, upgrade strategy generation, differential upgrade package construction, scheduling and distribution, incident review, and strategy solidification. The user terminal device is a smartphone or tablet with a companion application (APP) installed, used to display the device's operating status, energy efficiency indicators, and algorithm upgrade effects to the user, and to collect user behavior data. The device and cloud server interact via a network connection, and the cloud server and user terminal device also interact via a network connection.

[0098] During the data acquisition phase, home appliances continuously collect their own operational data during daily operation. Taking air conditioners as an example, the built-in temperature sensor collects indoor temperature in real time, and the control unit records equipment operating parameters such as set temperature, fan speed, and compressor start / stop frequency. It also records user operation behaviors such as adjustment habits, as well as information on whether the equipment exhibits abnormal conditions, including frequent start / stop and slow cooling. After simple local processing on the device, this data is periodically uploaded to a cloud server via the network. For example, in a user's home, the air conditioner is usually set at 26℃, but the user frequently manually lowers it to 24℃. Simultaneously, the system detects that the compressor is running at high load for an extended period; all this information will be recorded and uploaded.

[0099] In one possible implementation, device operation data can be collected uniformly through a home gateway or edge gateway. The gateway device aggregates the operation data of multiple home appliances and uploads it to the cloud. Alternatively, user operation behavior can be collected indirectly through an app installed on the user's terminal device. Or, environmental data or device linkage data can be obtained through a third-party smart home platform. For example, in a smart home scenario, the air conditioner's operating status can be uniformly aggregated by the home gateway and combined with outdoor weather platform data (such as temperature and humidity) for analysis, thereby further improving the accuracy of upgrade strategies. The data uploaded by the device is encapsulated according to a preset data format. Each data record includes a device identifier, timestamp, data type identifier, and data value field. The communication module sends the data to the cloud server according to a set reporting cycle (e.g., once every 5 minutes) or an event-triggered method.

[0100] After receiving a large amount of operational data uploaded by devices, the cloud server enters the device analysis and segmentation phase. The cloud-based data analysis module analyzes the operational data to determine user habits, environmental characteristics, and whether any devices have efficiency issues or abnormalities.

[0101] Specifically, the analysis module performs statistical analysis and feature extraction on equipment operating parameters, such as calculating average set temperature, temperature adjustment frequency, compressor high-load operation duration percentage, and energy consumption per unit time. The extracted feature indicators are then compared with preset threshold ranges to determine if the equipment has efficiency issues or abnormalities. Subsequently, the equipment grouping module categorizes equipment with similar operating characteristics into the same equipment group and determines whether each group requires an AI algorithm upgrade and the upgrade target. For example, based on the above example, this air conditioner would be classified as a device type with "high temperature region + high frequency cooling demand + high energy consumption." The system determines that its current AI control strategy is not optimized and requires an algorithm upgrade aimed at "improving cooling efficiency and reducing energy consumption." In one possible implementation, equipment grouping can use machine learning-based clustering algorithms for automatic grouping, including K-means or DBSCAN algorithms; it can also use deep learning models for user behavior prediction and classification; or it can use reinforcement learning-based dynamic adjustment of the upgrade strategy. For example, in the air conditioning scenario, clustering algorithms can be used to automatically identify "nighttime users" and "24 / 7 users" and distribute different energy-saving strategy models to different groups.

[0102] After device grouping, the cloud server enters the hierarchical AI model upgrade strategy generation phase. The core of this phase is to break down the AI ​​algorithm into multiple layers and determine the target layer to be upgraded based on the upgrade needs of the device group, thereby generating a customized upgrade strategy for the target layer. In this embodiment, the AI ​​algorithm is divided into three layers: a control logic layer, a parameter configuration layer, and a model structure layer. The control logic layer contains the algorithm's decision logic and strategy rules; the parameter configuration layer contains the various parameter values ​​required for the algorithm's operation; and the model structure layer contains the algorithm's network structure and weight parameters. The system does not simply issue a complete new program, but rather determines which part needs to be updated based on the upgrade needs of the device group, thereby reducing upgrade risks and resource consumption. In this air conditioner case, system analysis revealed that the problem mainly stemmed from an "unreasonable temperature control strategy," rather than a complete model failure. Therefore, only the control strategy and some parameters needed optimization, without replacing the entire AI model.

[0103] This embodiment provides a complete implementation logic for determining which level to update and how to formulate a specific upgrade strategy for that level. Specifically, after device grouping is completed in the cloud, the system first initiates fault tracing and attribution analysis: by comparing the decision paths of similar high-quality devices with that of the air conditioner, the importance of features is analyzed. It is found that the weight of the "indoor temperature" feature is too low while the weight of "running time" is too high, thus pinpointing the root cause as a logical deviation in the strategy layer, rather than inaccurate values ​​in the parameter layer or a model failure in the structure layer. Based on this, it is determined that only the strategy layer needs to be updated. After determining the update strategy layer, the system performs strategy deconstruction and reconstruction: The rigid logic of the original strategy, "full-speed cooling whenever the user lowers the temperature," is broken down into a Bayesian network of "environmental perception - user intent - device response," and "anti-jitter mechanism" and "predictive control" modules are implanted. Specifically, the original fixed PID parameters are adjusted to load-based dynamic parameters. For example, the integral coefficient Ki in the low-frequency oscillation range is reduced from 0.05 to 0.02 to reduce overshoot. Simultaneously, the "user habit learning" sub-strategy is activated in the strategy library, allowing pre-cooling 15 minutes in advance if the user lowers the temperature at 10 PM for three consecutive days. Finally, the system verifies the effectiveness of the new strategy through a simulation sandbox. Simulations show an 18% reduction in energy consumption without temperature overshoot. A differential configuration file containing only strategy logic changes (rather than altering model weights or structure) is generated, along with a rollback trigger condition. This rollback trigger condition is triggered when a temperature fluctuation exceeding ±1.5℃ within 5 minutes is detected, thus achieving accurate, safe, and low-risk layered thermal updates.

[0104] After generating a customized upgrade strategy, the system enters the stage of building and distributing differentiated OTA upgrade packages. First, the cloud platform uses a strategy template library for precise matching based on device group tags (such as "high temperature and high load") and the level to be updated (strategy layer). For the "high energy consumption" group to which the air conditioner belongs, the system removes irrelevant "humidification linkage" or "extreme cold mode" modules from the general strategy template, extracting only the specific strategy plugin "dynamic temperature control optimization." Then, differential construction is performed, comparing the binary differences between the current device-side strategy file and the new cloud-based strategy file to generate a lightweight .patch differential file that occupies only 3%-5% of the original package size. This file embeds specific logic changes, such as lowering the "user manual temperature adjustment response priority" from the highest to the second highest, and writing a new "pre-cooling time offset = 15min" parameter. Next, the system compiles and adapts the patch using the hardware fingerprint from the device profile. The hardware fingerprint includes the MCU model and remaining Flash space to ensure instruction set compatibility. Installation constraints and verification fingerprints are encapsulated in the package header. Installation constraints, for example, are triggered only between 2-5 AM and when the room temperature is above 25°C. Finally, the scheduling engine, based on the network quality and power consumption status reported by the device, queues customized differential packets for distribution. Network quality parameters include, for example, Wi-Fi signal strength greater than -65dBm, and power consumption parameters include, for example, the device being in a low-power standby window. This ensures precise delivery with a "one device, one policy" approach while maintaining extremely low bandwidth usage. For instance, the user's air conditioner will receive a "lightweight upgrade package" during low-usage periods at night, containing only new temperature control strategies and optimized parameters, rather than a complete software update. Compared to traditional full-package upgrades, this method is faster, safer, and less prone to errors.

[0105] After receiving the upgrade package on the device side, the system enters the tiered hot update and anomaly rollback phase. The device loads the new algorithm without interrupting operation, performing a hot update while retaining the old version as a backup. When an anomaly is detected in the new algorithm's operation, the system determines the type of anomaly and rolls back only the recently updated target layer, rather than restoring the entire system to factory settings. Specifically, if the upgraded device experiences frequent start-stops or increased temperature fluctuations, it is automatically identified as a policy anomaly, and only the policy layer is rolled back. For example, in a real-world scenario, if an air conditioner experiences "frequent start-stops" or "increased temperature fluctuations" after an upgrade, the system will automatically identify it as a policy anomaly and only roll back the recently updated policy layer, rather than restoring the entire system to factory settings. This "partial rollback" significantly reduces risk.

[0106] After completing the partial rollback, the system needs to return to the strategy generation stage with the "failure scene" to redetermine the level and upgrade strategy. Moreover, the judgment logic is more refined this time because it has the key evidence of the abnormal snapshot triggered by the rollback, such as "the temperature fluctuates by ±1.8℃ and the compressor starts and stops 7 times within 5 minutes under the new strategy".

[0107] The specific process is as follows: Upon rollback, the device packages and uploads the operational logs before and after the anomaly to the cloud. The operational logs include sensor sequences, decision paths, and resource usage information. The cloud first enters the incident review pipeline, comparing the decision trajectory of the new strategy's inference logs with that of the original strategy to pinpoint which strategy branch is causing the problem. If the anomaly is concentrated in the oscillation segment after the "15-minute pre-cooling" trigger, it indicates that the strategy logic is correct but the parameters are aggressive, attributed to parameter layer mismatch. The next upgrade will change it to "8-minute pre-cooling + Ki maintained at 0.05 without reduction". If the oscillation occurs in all temperature adjustment scenarios without any pattern, it may be due to an incorrect threshold setting in the strategy layer's "anti-shake mechanism". For example, "multiple temperature adjustments within 5 minutes are merged" may be mistakenly written as "3 times". This is attributed to a logic error in the strategy layer. The next rollback will only fine-tune the anti-shake threshold to the previous version of the strategy. In a more extreme case, if the old strategy also shows a slight anomaly under the same operating conditions after rollback, it indicates that the root cause is in the structural layer, meaning that the original model is not well-fitted for the high-temperature and high-humidity coupled scenario in this region. It is necessary to retrain the small-sample adaptation model of the structural layer rather than simply changing the strategy. After determining the new level, the system will overlay a "pitfall avoidance patch" on the original policy template, adding the conditions that triggered the rollback (e.g., 2 AM, outdoor temperature 38℃, user making 3 consecutive adjustments) to the device's "policy blacklist scenario." This is explicitly written into the new upgrade package, and the system will run the blacklist scenario 1000 times in a simulation sandbox to verify that the rollback conditions are no longer triggered before generating a second differential packet for distribution. The entire retry chain also includes a circuit breaker mechanism: if the same device fails to rollback 3 times consecutively, it will automatically exit the automated process and switch to the manual annotation and structural layer retraining branch to avoid infinite loops.

[0108] After the AI ​​algorithm upgrade is completed, the system enters a closed-loop phase of dynamic adaptation of app data display and effect feedback. Following the AI ​​algorithm upgrade, the data display method on the app will also be adjusted accordingly. For example, indicators such as energy efficiency scores and comfort evaluations may adopt new calculation methods, and the system will synchronously update these display rules to ensure that the data seen by users is consistent with the current algorithm. For instance, the upgraded app adds a "Smart Energy Saving Index" to reflect the optimization effect, allowing users to intuitively see that daily power consumption decreased from 8 kWh before the upgrade to 6.5 kWh after. Simultaneously, this data will continue to be fed back to the cloud for subsequent algorithm optimization, forming a continuously iterative closed loop.

[0109] It's important to clarify that the essence of the feedback loop in this application is to use the upgraded operational data as training fuel for a new round of algorithm iterations, allowing the system to move from "one-time optimization" to "self-evolution." In practical implementation, the cloud will first tag the data returned by the upgraded devices with the algorithm version V2, and compare it longitudinally with the V1 baseline before the upgrade. For example, after the upgrade, the air conditioner's average daily power consumption will decrease from 8 kWh to 6.5 kWh, and the frequency of manual temperature adjustments by users will decrease from 12 times per day to 4 times per day. These indicators will be incorporated into the effect evaluation pool for this group ("high-temperature region + high-frequency cooling + high energy consumption"). When the sample size in the pool accumulates to a statistically significant level, for example, if the average energy saving of 500 devices in the same group is ≥15% after the upgrade and there is no rollback, the cloud will trigger the "strategy solidification" process, promoting this dynamic temperature control optimization + 15-minute pre-cooling strategy from the "experimental version" to the "baseline strategy template" for the group. New devices joining the same group can then be directly deployed without needing to undergo full-scale analysis. At the same time, cases where the upgrade results are not as expected or even rolled back will be handled separately. For example, if a device in the same group consumes 8.5 kWh after the upgrade, the cause will be attributed based on its unique characteristics, such as its outdoor unit facing west and exposed to the sun, and the ambient temperature being above 42°C. If such cases account for more than 5%, a second group split will be triggered, and "extreme high temperature + west exposure" will be split into an independent subgroup. A new parameter sub-strategy will be trained accordingly, such as extending the precooling time to 25 minutes and limiting the power of the compressor at high frequencies.

[0110] A deeper level of optimization utilizes online incremental learning: the upgraded triplet data of "(environmental state → user temperature adjustment → energy consumption)" for each device is fed back into the original model's training, or contrastive learning is used to widen the latent space distance between "energy-saving comfort decisions" and "high-consumption, low-efficiency decisions," generating model iteration versions V2.1 and V2.2. The app is also actively working on this; the "intelligent energy-saving index" calculation formula seen by users is itself iterative. Initially, it might be (baseline power consumption - actual power consumption) / baseline power consumption. Later, a "comfort penalty" (frequency of user manual temperature adjustment) is introduced, transforming it into energy-saving rate multiplied by comfort weights. This formula version is synchronously distributed with the algorithm version, ensuring that the front-end display and back-end logic are always synchronized. This entire mechanism forms a spiral progression of "single-device upgrade verification → group effect convergence → strategy template accumulation → subgroup re-splitting → model incremental training," continuously improving the accuracy of upgrade optimization.

[0111] In summary, this embodiment, through a differentiated AI algorithm OTA upgrade mechanism driven by device operation data, combined with the hierarchical structure of the AI ​​model and the control methods of hierarchical update and rollback, realizes the transformation from traditional overall upgrades to fine-grained differentiated upgrades. This significantly improves the adaptability of AI algorithms in different usage environments, enhances the operating efficiency and energy efficiency of home appliances such as air conditioners, effectively reduces the risk of AI algorithm upgrades, ensures the continuous operation of home appliances during the upgrade process, and improves the user experience.

[0112] Corresponding to the above method embodiments, this application also provides an OTA dynamic upgrade system for home appliances, such as... Figure 3 As shown, the system includes: The data acquisition module 100 is used to collect the operating data of home appliances and upload the operating data to a cloud server. The operating data includes equipment operating parameters, user operation behavior and equipment abnormal status information. The analysis module 200 is used to analyze the operating data, divide devices with similar operating characteristics into the same device group based on the analysis results, and determine the algorithm upgrade requirements of each device group. The generation module 300 is used to split the AI ​​algorithm of the device group to be upgraded into multiple levels, determine the target level to be upgraded based on the algorithm upgrade requirements, and generate a customized upgrade strategy for the target level. The update module 400 is used to generate differentiated upgrade packages according to the customized upgrade strategy and send them to the corresponding devices for loading to complete the update of the target level, and to perform a rollback operation on the target level if the updated algorithm runs abnormally.

[0113] It should be noted that the above explanations of the OTA dynamic upgrade method for home appliances in this application also apply to the system in this embodiment, and will not be repeated here.

[0114] Corresponding to the above method embodiments, this application also provides an electronic device, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus.

[0115] Memory, used to store computer programs; When the processor executes a program stored in the memory, it implements the OTA dynamic upgrade method for home appliances as described in any of the first aspect embodiments above.

[0116] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0117] The communication interface is used for communication between the aforementioned photovoltaic air conditioner and other devices.

[0118] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0119] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0120] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute the OTA dynamic upgrade method for home appliances described in any of the above embodiments.

[0121] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the OTA dynamic upgrade method for home appliances described in any of the above embodiments.

[0122] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0123] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0124] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0125] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for OTA dynamic upgrade of home appliances, characterized in that, The method includes: Collect operating data of home appliances and upload the operating data to a cloud server. The operating data includes equipment operating parameters, user operation behavior and equipment abnormal status information. The operational data is analyzed, and devices with similar operational characteristics are grouped into the same device group based on the analysis results. The algorithm upgrade requirements of each device group are then determined. The AI ​​algorithms of the device group to be upgraded are divided into multiple levels. Based on the algorithm upgrade requirements, the target level to be upgraded is determined, and a customized upgrade strategy for the target level is generated. Based on the customized upgrade strategy, a differentiated upgrade package is generated and sent to the corresponding device for loading to complete the update of the target level. In the event of an abnormal operation of the updated algorithm, a rollback operation is performed on the target level.

2. The method according to claim 1, characterized in that, The process of analyzing the operational data, classifying devices with similar operational characteristics into the same device group based on the analysis results, and determining the algorithm upgrade requirements for each device group includes: Based on the operational data, determine the user's usage habits, environmental characteristics, and whether the equipment has any abnormalities; Based on the identified equipment operating characteristics, the equipment is divided into groups using preset equipment grouping rules, machine learning-based clustering algorithms, deep learning models, or reinforcement learning upgrade strategies. Determine whether each group of devices needs an AI algorithm upgrade and what the corresponding upgrade goals are.

3. The method according to claim 1, characterized in that, The process of splitting the AI ​​algorithms of the device group to be upgraded into multiple levels, determining the target level to be upgraded based on the algorithm upgrade requirements, and generating a customized upgrade strategy for the target level includes: The AI ​​algorithm is divided into a control logic layer, a parameter configuration layer, and a model structure layer. By conducting fault tracing and attribution analysis, the target level to be upgraded among the multiple levels after splitting is determined. The fault tracing and attribution analysis includes: analyzing the importance of features by comparing the decision paths of similar high-quality equipment and the equipment to be upgraded, and determining the level where the root cause of the problem is located. The execution strategy for the target level is deconstructed and reconstructed to generate the customized upgrade strategy.

4. The method according to claim 3, characterized in that, The fault tracing and attribution analysis also includes: For air conditioning equipment, if the indoor temperature feature weight is lower than the threshold and the running time feature weight is higher than the threshold, the root cause of the problem is identified as a logic deviation, and the control logic layer is updated. If the parameter value deviation exceeds the preset range, the parameter configuration layer is updated. If the AI ​​model is not well fitted to a specific working condition, the model structure layer is updated.

5. The method according to claim 3, characterized in that, The deconstruction and reconstruction of the execution strategy for the target level includes: The rigid logic in the original strategy is decomposed into a Bayesian network of environmental perception, user intent and device response, and a de-jitter mechanism and predictive control module are embedded in the Bayesian network. The Bayesian network is controlled to learn user habits and generate an adjusted update strategy. The effectiveness of the update strategy is verified through a simulation sandbox, and a configuration file containing the update strategy and rollback trigger conditions is generated.

6. The method according to claim 1, characterized in that, The step of generating differentiated upgrade packages according to the customized upgrade strategy and sending them to the corresponding devices for loading includes: Based on the device group tags and the target level, the system matches the policy template library, removes irrelevant modules from the general policy templates, and extracts specific policy plugins. Compare the binary differences between the current device-side policy file and the cloud-updated policy file to generate a lightweight difference file, wherein the difference file embeds the logical change policy and parameter offset; The differential file is compiled and adapted by combining the hardware fingerprint in the device profile, and constraints and verification fingerprints are installed at the packet header encapsulation to generate the differentiated upgrade package; Based on the network quality and power consumption status reported by home appliances, the differentiated upgrade packages are queued by the scheduling engine and sent to the corresponding devices.

7. The method according to claim 1, characterized in that, The step of completing the update of the target level and performing a rollback operation on the target level in the event of an abnormal operation after the update, includes: The control device loads the differentiated upgrade package without interrupting operation and retains the old version as a backup; When an anomaly is detected in the updated AI algorithm, the anomaly type is determined, and the target level where the anomaly occurred is rolled back based on the anomaly type.

8. The method according to claim 7, characterized in that, Following the target level where an anomaly exists after the rollback update, the following is also included: The operation logs before and after the anomaly are packaged and uploaded to the cloud. The operation logs include sensor sequences, decision paths, and resource usage information. Enter the incident review pipeline, compare the decision trajectory of the updated strategy with the original strategy, locate the abnormal strategy branch, redetermine the target level to be upgraded and generate a secondary upgrade strategy. In the secondary upgrade strategy, a pitfall avoidance patch is superimposed, and the operating conditions that trigger rollback are added to the device's policy blacklist scenario. After verifying through a simulation sandbox that the rollback conditions are no longer triggered, a secondary differential package is generated and sent to the corresponding device.

9. The method according to claim 1, characterized in that, After the update of the target level is completed, the following is also included: Synchronously update the data display rules on the APP and adjust the display metrics on the APP to be consistent with the current algorithm; The upgraded operational data is fed back to the cloud server for subsequent algorithm optimization to generate a continuously iterating closed-loop logic.

10. The method according to claim 9, characterized in that, The subsequent algorithm optimization to generate continuously iterative closed-loop logic includes: Add algorithm version tags to the data returned by the upgraded devices, compare it with the baseline before the upgrade for the same device, and import the comparison indicators into the effect evaluation pool of the device group. When the number of samples in the effect evaluation pool accumulates to the statistical threshold, the strategy solidification process is triggered, and the upgrade strategy is upgraded from the experimental version to the baseline strategy template of the device group. For cases where the upgrade effect does not meet expectations or a rollback occurs, attribution analysis is performed. When the proportion of abnormal cases exceeds the threshold, a secondary cluster split is triggered for the device group, which splits the extreme working conditions into independent subgroups, and a new parameter sub-policy is trained for the independent subgroups.

11. The method according to claim 10, characterized in that, Also includes: The online incremental learning approach is adopted, and the environmental status, user temperature adjustment and energy consumption triplet data of each upgraded device are returned to the original model for training, or the contrastive learning approach is adopted to increase the latent space distance between different decisions in order to generate model iteration versions. The updated real-time display content on the app is consistent with the current backend upgrade logic.

12. The method according to claim 1, characterized in that, The collected operating data of home appliances includes: The operating parameters of the home appliances are continuously collected by the data acquisition devices built into the appliances, or the operating parameters of each home appliance are collected uniformly by the grid device. The user's operational behavior is collected indirectly through the user terminal device; Obtain environmental data or device linkage data through third-party smart home platforms.

13. An OTA dynamic upgrade system for home appliances, characterized in that, include: The data acquisition module is used to collect the operating data of home appliances and upload the operating data to the cloud server. The operating data includes equipment operating parameters, user operation behavior and equipment abnormal status information. The analysis module is used to analyze the operating data, divide devices with similar operating characteristics into the same device group based on the analysis results, and determine the algorithm upgrade requirements of each device group. The generation module is used to break down the AI ​​algorithms of the device group to be upgraded into multiple levels, determine the target level to be upgraded based on the algorithm upgrade requirements, and generate a customized upgrade strategy for the target level. The update module is used to generate differentiated upgrade packages according to the customized upgrade strategy and send them to the corresponding devices for loading to complete the update of the target level. In the event of an abnormal operation of the updated algorithm, the module performs a rollback operation on the target level.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in a memory, it implements the OTA dynamic upgrade method for any of the home appliances described in claims 1-12.

Images