Household appliance fault diagnosis method, device, equipment and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for diagnosing home appliance faults, relating to the fields of smart home appliance fault diagnosis and IoT after-sales service. It aims to address the problems in existing after-sales services for connected home appliances, such as reliance on explicit faults or vague user reports, difficulty in timely identification of early anomalies, low diagnostic efficiency, and unclear handling suggestions. To this end, it collects operational data from home appliances and analyzes its trend changes. After identifying abnormal trends, it maps corresponding fault information and then combines this with a pre-trained large language model to output handling suggestions that match the fault information. This solution enables predictive and assisted diagnosis before or in the early stages of fault formation, improving the timeliness and accuracy of diagnosis, enhancing the comprehensibility of the suggestions, and optimizing the allocation of after-sales service resources.

Description

Technical Field

[0001] This application relates to the field of smart home appliance fault diagnosis and Internet of Things after-sales service, and in particular to a method, apparatus, device and storage medium for home appliance fault diagnosis. Background Technology

[0002] In after-sales service for connected home appliances, fault code prompts, remote parameter queries, knowledge base retrieval, and work order dispatch are commonly used to handle equipment malfunctions.

[0003] However, the above methods mostly rely on users actively reporting problems or handling issues only after they are triggered by anomalies, making it difficult to detect early anomalies in operating parameters in a timely manner. At the same time, user descriptions, equipment logs, and after-sales knowledge are scattered, often requiring manual comprehensive judgment, resulting in low diagnostic efficiency, insufficient understandability and specificity of handling suggestions, and even simple problems can easily consume human service resources.

[0004] Therefore, how to improve the efficiency of fault prediction and diagnosis in the after-sales service of connected home appliances, while taking into account user understandability and the rationality of service resource allocation, has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for diagnosing home appliance faults to address the aforementioned technical problems. This solution targets after-sales scenarios for connected home appliances, constructing a fault diagnosis technology path from operational status detection to diagnostic result generation, focusing on anomaly perception, fault information determination, and fault handling suggestions during the operation of smart home appliances. This improves the ability to identify device anomalies in advance and enhances the overall efficiency of fault diagnosis and handling.

[0006] In a first aspect, this application provides a method for diagnosing household appliance malfunctions, the method comprising:

[0007] Collect operational data from smart home appliances and identify whether there are any abnormal trends in the operational data;

[0008] If it exists, the corresponding first equipment fault information is determined based on the abnormal trend data;

[0009] By using a pre-trained large language model, fault handling suggestions adapted to the equipment fault information are generated.

[0010] In one possible implementation, generating fault handling suggestions adapted to the device fault information using a pre-trained large language model includes:

[0011] Determine whether a fault description, used to indicate a malfunction of the smart home appliance, is detected within a preset time period;

[0012] If it exists, the knowledge base is retrieved based on the fault description to determine the corresponding second equipment fault information, wherein the knowledge base is a database that stores at least equipment fault code explanations, maintenance manuals, historical work orders, and product manuals;

[0013] The abnormal trend data, the first device fault information, and the second device fault information are input into the large language model to generate the fault handling suggestions.

[0014] If not, the abnormal trend data and the first device fault information are input into the large language model to generate the fault handling suggestion.

[0015] In one possible implementation, determining the corresponding second device fault information based on the fault description retrieval knowledge base includes:

[0016] Extract target keywords from the fault description;

[0017] And match the target keywords, the device model of the smart home appliance, and the operating data;

[0018] Based on the matching results, the knowledge base is retrieved to obtain the fault information of the second device.

[0019] In one possible implementation, after generating the fault handling suggestion, the method further includes:

[0020] Based on the fault handling suggestions, the fault type, user operation complexity, and corresponding historical maintenance records for the fault type are determined.

[0021] A risk score is determined based on the historical maintenance records, the user operation complexity, and the historical maintenance records, and a maintenance work order is generated based on the risk score.

[0022] When the risk score indicates a high risk, a maintenance work order is generated based on the fault handling suggestions and an emergency alert is triggered.

[0023] When the risk score indicates low risk, the fault handling suggestion is output.

[0024] In one possible implementation, the fault handling suggestion includes a fault description, a fault code, and maintenance operation information. The step of determining the fault type, user operation complexity, and historical maintenance records corresponding to the fault type based on the fault handling suggestion includes:

[0025] Based on the fault description or the fault code, determine the corresponding fault type, wherein the fault type includes safety hazard fault, performance degradation fault, and consumable replacement fault;

[0026] Based on the maintenance operation information, the number of steps in the maintenance process, whether preset maintenance tools are used, and whether it includes gas pipeline disassembly or circuit connection operations are analyzed, and the complexity of the user operation is determined based on the analysis results.

[0027] Based on the fault type, query the maintenance database for a preset time period to determine the historical maintenance records.

[0028] In one possible implementation, identifying whether the operational data contains abnormal trend data includes:

[0029] The operational data is monitored using a time-series analysis algorithm to generate a corresponding allowable fluctuation range;

[0030] By comparing the operational data with the allowable fluctuation range, it is determined whether there are any abnormal trend data in the operational data.

[0031] In one possible implementation, after generating the fault handling suggestions adapted to the device fault information, the method further includes:

[0032] Based on the interaction habits of home users with the smart home appliances, the target interaction method is determined;

[0033] The fault handling suggestions are output through the target interaction method.

[0034] Secondly, this application provides a home appliance fault diagnosis device, comprising:

[0035] The acquisition module is used to collect operating data of smart home appliances and identify whether there are abnormal trend data in the operating data;

[0036] The determination module is used to determine the corresponding first equipment fault information based on the abnormal trend data if the fault exists.

[0037] The control module is used to generate fault handling suggestions adapted to the fault information of the device through a pre-trained large language model.

[0038] Thirdly, this application provides a smart home appliance device, including: a processor, and a memory communicatively connected to the processor;

[0039] The memory stores computer-executed instructions;

[0040] The processor executes computer execution instructions stored in the memory to implement the home appliance fault diagnosis method as described in the first aspect.

[0041] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the home appliance fault diagnosis method as described in the first aspect.

[0042] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps of the scheme recommendation method as described in any of the first aspects.

[0043] This application provides a method, apparatus, device, and storage medium for diagnosing home appliance faults. By collecting operating data of smart home appliances and identifying whether there is abnormal trend data, potential fault signs can be detected before the equipment malfunction worsens or the user actively reports a fault. By determining the corresponding first equipment fault information based on the abnormal trend data, the efficiency of fault location and diagnosis can be improved. Furthermore, by generating fault handling suggestions that are adapted to the equipment fault information through a pre-trained large language model, the relevance and understandability of the handling suggestions can be improved, the reliance on human comprehensive judgment can be reduced, and the rational allocation of after-sales service resources can be promoted. Attached Figure Description

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

[0045] Figure 1 A flowchart illustrating a home appliance fault diagnosis method provided in this application embodiment. Figure 1 ;

[0046] Figure 2 A flowchart illustrating a home appliance fault diagnosis method provided in this application embodiment. Figure 2 ;

[0047] Figure 3 This is a schematic diagram of the structure of a home appliance fault diagnosis device provided in an embodiment of this application;

[0048] Figure 4 This is a schematic diagram of the structure of a smart home appliance provided in an embodiment of this application.

[0049] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0050] Smart home appliance fault diagnosis and IoT after-sales service belong to the interdisciplinary technical field of IoT, equipment fault diagnosis, and intelligent service collaborative processing. They are widely used in network-enabled home appliances such as water heaters, boilers, water purifiers, water dispensers, air conditioners, and washing machines. In these application scenarios, home appliances are typically deployed in real-world environments such as homes, rental apartments, hotel rooms, offices, or commercial stores. During operation, these devices continuously generate operational data such as temperature, water pressure, flow rate, power, runtime, start / stop status, and fault codes, which are then uploaded to a remote platform via communication modules. The supporting business system typically includes the device side, network transmission links, cloud management platform, user-side interaction interface, and after-sales processing system. The device side is responsible for collecting operational status data, the network side handles data transmission, and the cloud is used to store device logs, historical operational information, and after-sales data. Users typically report abnormalities through mobile applications, mini-programs, or customer service channels, and after-sales personnel conduct remote diagnosis or arrange repairs based on the backend records. The core characteristics of this scenario are the wide distribution of equipment, the variety of models, the complexity of operating conditions, the limited professional capabilities of users, and the fact that failures often do not occur instantaneously but are caused by slow parameter drift and gradual performance degradation. For example, water heaters may initially show longer heating times, boilers may initially show increased water pressure fluctuations, and water purifiers may initially show a slow decrease in water flow. These changes usually do not constitute a clear malfunction or shutdown in the early stages, but they have already affected equipment performance and user experience. Therefore, technical solutions in this field that can promptly identify abnormal trends in real-world usage scenarios and assist in formulating handling recommendations have high application value.

[0051] In existing after-sales service systems for connected home appliances, common technical solutions mainly revolve around fault code prompts, remote parameter queries, knowledge base searches, online customer service responses, and work order dispatch. The typical workflow involves the device outputting a fault code after detecting an anomaly exceeding a threshold. The user then sees the message on a display screen or through an application, prompting them to report the problem. Alternatively, customer service or repair personnel log into the backend system to view device operating parameters, historical logs, and fault records, and use the instruction manual, repair manual, or past work order experience to determine the cause of the problem. For more standardized issues, common answers may be provided through knowledge base searches or chatbot Q&A. While these solutions can cover some clearly defined faults in engineering practice, they still have significant limitations.

[0052] First, existing solutions typically rely on faults becoming explicit before triggering intervention. The system tends to respond to outright anomalies rather than identifying pre-existing trends, making it difficult to address early anomalies such as decreased heating efficiency, persistent water pressure deviations, and gradual flow reductions in a timely manner. Second, users often only describe vague phenomena like "the equipment isn't heating," "the water pressure is low," or "the noise is high" when reporting problems. These descriptions lack professionalism, and the actual equipment status is scattered across logs, parameters, fault codes, and model information. Customer service needs to repeatedly ask follow-up questions and manually compare data across multiple systems to form a preliminary diagnosis, resulting in low diagnostic efficiency. Third, even when the backend has access to operating parameters, the output often remains at the level of technical jargon, parameter values, or fault codes. Ordinary users struggle to understand the cause and perform corresponding actions, making simple checks, maintenance, or consumable disposals that could be done independently still require human customer service and on-site service resources. Furthermore, while existing knowledge bases have accumulated a wealth of repair manuals, case records, and Q&A content, in practical applications they often rely primarily on passive queries and lack a linkage mechanism with equipment operating status. This makes it impossible to generate scenario-specific handling suggestions for current equipment anomalies. Due to these limitations, enterprise after-sales systems are prone to problems such as untimely warnings, excessively long diagnostic processes, difficult-to-understand suggestions, and unreasonable resource allocation. These issues negatively impact user experience, increase maintenance costs, and fail to meet the demands of connected home appliance scenarios for proactive, intelligent, and refined services.

[0053] In view of this, how to improve the efficiency of fault prediction and diagnosis in the after-sales service of connected home appliances, while taking into account user understandability and the rationality of service resource allocation, has become an urgent technical problem to be solved.

[0054] To address the aforementioned issues, this application proposes a method for diagnosing home appliance faults. After collecting operational data from smart home appliances, the method first analyzes the data to identify any abnormal trends. If abnormal trends are identified, the method further determines the corresponding first device fault information based on these trends. Subsequently, a pre-trained large language model is used to generate fault handling suggestions adapted to the device fault information. This allows fault diagnosis to move beyond relying solely on vague user reports or single fault code triggers, enabling more targeted processing outputs based on changes in the device's operating status. This technical approach is based on the existing application architecture of connected home appliances and is suitable for platform-based scenarios where operational data is collected from the device and uploaded to the cloud, as well as service processes where users receive diagnostic results and processing prompts through applications. By first identifying abnormal trends from the operational data, then associating these trends with fault information, and finally using a pre-trained large language model to output appropriate suggestions, this method can provide diagnostic conclusions and processing content more consistent with the device's state when the appliance fault is still in its early stages. This improves the timeliness of fault identification, enhances the comprehensibility of suggestions, and provides more efficient technical support for subsequent after-sales handling.

[0055] Figure 1 A flowchart illustrating a home appliance fault diagnosis method provided in this application embodiment. Figure 1 .like Figure 1 As shown, the method includes:

[0056] S101: Collects operating data from smart home appliances and identifies any abnormal trends in the operating data.

[0057] In this step, smart home appliances are the objects for collecting operational data and performing fault diagnosis. These can be network-connected appliances such as water heaters, boilers, water purifiers, water dispensers, air conditioners, and washing machines. During operation, these devices continuously generate information such as temperature, water pressure, flow rate, power, runtime, start / stop status, and fault codes, which are uploaded to the system via a communication module. Operational data serves as the foundation for characterizing the current working state of the smart home appliances and is the basis for subsequent identification of abnormal trend data and inference of fault information. Abnormal trend data indicates abnormal changes in the operational data, not limited to sudden anomalies exceeding a threshold at a specific moment, but also including directional changes over time such as continuous decline, continuous increase, increased fluctuation, prolonged recovery time, and reduced efficiency.

[0058] The entity executing this step can be a diagnostic server in a cloud management platform, a smart home appliance (hereinafter referred to as the device side), or a distributed processing system composed of the device side and the cloud.

[0059] Specifically, the device collects operating parameters through sensors. For example, temperature parameters can be obtained by a temperature probe, water pressure parameters by a pressure sensor, flow parameters by a flow meter, and power parameters by a power detection circuit. Operating duration and start / stop status can be recorded by the control motherboard. After receiving the operating data, smart home appliances can first perform timestamp alignment, missing value completion, abnormal noise removal, unit unification, and device identity binding processing. For example, a unique index can be created based on the device serial number, user account, installation location, and device model before writing the raw data into a time-series database or operating log database.

[0060] When identifying abnormal trends in operational data, a baseline operational profile for the corresponding device model can be established first. This baseline operational profile can be derived from historical normal operation data, factory test data, statistical characteristics of a group of devices of the same model, or a normal sample set after after-sales labeling. The device compares and analyzes the operational data in the current acquisition window with historical operational data to determine whether there are any continuously deviating changes. For example, for water heaters, it can be determined whether the heating time required to reach the target temperature under the same inlet water temperature conditions has been prolonged for multiple consecutive cycles; for water purifiers, it can be determined whether the outlet water flow rate shows a slow downward trend under the same water supply conditions. In one possible embodiment, a sliding window method is used to statistically analyze the operational data, using the most recent N sampling periods as the analysis window, and calculating trend indicators such as mean, slope, variance, range, rate of change, and recovery time. When at least one of these indicators continuously exceeds the normal fluctuation range, the trend feature is extracted as abnormal trend data. Here, N can be set to a minute-level, hour-level, or day-level window according to the device type to adapt to the operating rhythm of different home appliances.

[0061] In another possible implementation, abnormal trend data can be identified by combining preset thresholds with trend rules. Specifically, the device not only determines whether the current parameter exceeds a single-point threshold, but also whether the parameter continuously changes in an abnormal direction within a predetermined time interval. For example, if the flow rate gradually decreases for seven consecutive days and the cumulative decrease reaches a preset ratio, or if the heating duration is higher than the historical average for five consecutive start cycles by a certain percentage, abnormal trend data can be identified. For fluctuating anomalies, judgments can also be made based on changes in standard deviation, coefficient of variation, or peak-to-valley difference to identify problems such as unstable water pressure and increased power fluctuations. If the collected operating data does not show a continuous deviation, the device can record the result as normal and continue subsequent sampling and polling; if abnormal trend data is identified, a corresponding trend label, trend intensity value, duration, associated parameter items, and occurrence time period are generated, and the next step of fault information determination is triggered.

[0062] Based on the above analysis, this step, through continuous data collection, cleaning, modeling, and time-series trend identification, enables the diagnostic process to move beyond single-point alarms after faults become apparent. It allows for the detection of problem signs as early as the formation stage of equipment performance degradation or state drift. This approach addresses the technical challenges of widely distributed devices, complex operating conditions, and the difficulty for users to accurately perceive early-stage faults in connected home appliance scenarios. It improves the timeliness of anomaly identification, provides structured input for subsequent fault localization, and shortens the link between parameter changes and fault diagnosis.

[0063] In another possible implementation, existing home appliance fault diagnosis technologies typically use a fixed threshold comparison method to determine whether the device's operating status is abnormal. This involves pre-setting a fixed numerical range, and any data exceeding this range is considered abnormal. However, the operating data of smart home appliances exhibits significant temporal characteristics. For example, the compressor operating frequency of an air conditioner varies with different seasons and times of day; the temperature fluctuation of a refrigerator before and after opening and closing the door; and the motor speed of a washing machine during different washing stages. The normal fluctuation range of these fluctuations dynamically changes over time, with variations in the usage environment and the degree of device aging. Using a fixed threshold presents the following problems: when the device's operating status is normal but the fluctuation range is large, the fixed threshold can easily misjudge normal fluctuations as abnormal, leading to a higher false alarm rate; when the device's operating status shows a slow degradation trend but has not yet exceeded the fixed threshold, potential risks cannot be identified in time, resulting in missed alarms. Therefore, to adaptively determine reasonable fluctuation boundaries under different temporal scenarios, thereby improving the accuracy and timeliness of anomaly identification, this embodiment introduces a technical means of monitoring operating data using a time-series analysis algorithm to generate an allowable fluctuation range and identify abnormal trend data accordingly. The specific implementation steps for identifying abnormal trend data are as follows:

[0064] The time series analysis algorithm is used to monitor the running data and generate the corresponding allowable fluctuation range; the running data and the allowable fluctuation range are compared to determine whether there are abnormal trend data in the running data.

[0065] Time-series analysis algorithms are used to continuously monitor equipment operating data in chronological order and calculate acceptable change boundaries by combining historical data characteristics. In this embodiment, the time-series analysis algorithm can specifically employ analysis methods capable of capturing the temporal dependencies of data, such as autoregressive integral moving average models, exponential smoothing methods, or long short-term memory networks. The allowable fluctuation range is used to characterize the parameter fluctuation range of the equipment under normal operating conditions. This range can be obtained based on historical stable operating data, equipment model parameters, and preset statistical confidence intervals, and is used as a reference standard to determine whether the current data deviates from the normal state. Operating data may include numerical sequences corresponding to temperature, water pressure, flow rate, power, start / stop status, or fault codes. Abnormal trend data refers to data segments that show continuous deviation, increased fluctuation amplitude, or abnormal slope changes in the time dimension.

[0066] The device inputs the collected operational data into a time-series analysis algorithm for processing. Specifically, the device extracts historical time window data corresponding to the operational data. This historical time window can be set to the data volume of the most recent week, month, or quarter, depending on actual needs. Based on this historical time window data, the time-series analysis algorithm first preprocesses the data, including removing obvious noise interference points, filling in missing values ​​caused by communication interruptions, and normalizing the data to eliminate differences between different units of measurement. Next, the time-series analysis algorithm identifies long-term trend components, i.e., the direction of continuous rise, fall, or stagnant change in data over a long time span; identifies seasonal periodic components, i.e., regular fluctuations that recur within fixed time intervals; and identifies random fluctuation components, i.e., irregular small fluctuations caused by unpredictable factors. After decomposing the above components, the time-series analysis algorithm combines the trend and periodic components to predict the normal operation data for a future period, obtaining a prediction baseline value. It then calculates the prediction error range based on the statistical distribution characteristics of the historical random fluctuation components, and superimposes the prediction baseline value and the prediction error range to generate the corresponding allowable fluctuation range. The allowable fluctuation range is a dynamic interval, and the upper and lower limits of the interval are constantly updated over time based on the latest operating data, thereby reflecting the normal fluctuation boundaries of the equipment in the current operating stage.

[0067] After generating the allowable fluctuation range, the device compares the real-time collected operational data point by point with this range to determine whether each value in the operational data falls within the allowable fluctuation range corresponding to the current moment. If the value exceeds the upper or lower limit of the allowable fluctuation range, that moment is recorded as an anomaly. The device further performs trend analysis on consecutively occurring anomalies to determine whether their occurrence is persistent or regular, such as multiple consecutive sampling moments showing excessively high values, a sudden increase in the amplitude of value fluctuations, or a significant acceleration in the rate of data change. If the distribution pattern of the anomalies conforms to the preset anomaly trend judgment rules, the device determines that there is an abnormal trend in the operational data. Conversely, if the operational data value only occasionally and briefly exceeds the allowable fluctuation range and then quickly returns to the normal range without forming a persistent deviation, the device determines that the fluctuation is a normal random disturbance and does not constitute abnormal trend data.

[0068] By employing the above methods, smart home appliances can identify progressive anomalies in operational data based on time-series characteristics, rather than relying solely on instantaneous threshold alarms, thereby improving the ability to detect early signs of malfunctions. Because the permissible fluctuation range combines historical operational patterns with current temporal changes, it reduces misjudgments caused by environmental fluctuations and short-term disturbances, and enhances the stability and accuracy of anomaly trend identification.

[0069] S102: If it exists, determine the corresponding first equipment fault information based on the abnormal trend data.

[0070] In this step, the first device fault information is used to correlate and characterize abnormal trend data to reflect potential faults in smart home appliances. This information can represent one or more combinations of fault type, fault cause, fault code, maintenance operation information, or items to be verified. The abnormal trend data is used as direct input in this step and includes one or more combinations of information such as parameter category, direction of change, magnitude of change, duration, frequency of occurrence, and degree of deviation from historical baselines. By associating these trend characteristics with device knowledge, historical cases, and fault mapping relationships, data results that originally only reflected state changes can be transformed into first device fault information that can be used for diagnosis and service decisions.

[0071] Specifically, smart home appliances can pre-establish a knowledge base, which is organized and stored according to device type, device model, component structure, typical abnormal trends, corresponding fault descriptions, and handling records. For example, for water heaters, a trend of continuously increasing heating time without a significant decrease in power can be mapped to a decrease in heating efficiency or scaling of the heating element. After receiving abnormal trend data, the smart home appliance can first filter based on device model, operating mode, installation environment, historical maintenance records, and the time of the most recent maintenance, and then search for matching fault candidates in the knowledge base.

[0072] In one possible embodiment, the process of determining the first device fault information based on abnormal trend data is implemented using rule-based reasoning. Specifically, smart home appliances pre-configure corresponding rules between trend conditions and fault conclusions for various types of devices. When abnormal trend data satisfies a certain set of rules, the corresponding first device fault information is directly output. For example, if the rule is defined as "the heating rate decreases and the total power consumption increases in multiple consecutive heating cycles," the first device fault information can be determined as "reduced heat exchange efficiency"; if the rule is defined as "the outflow rate decreases and the inflow pressure is normal," the first device fault information can be determined as "increased risk of filter blockage."

[0073] In another possible implementation, smart home appliances can also use classification models, similar case matching models, or knowledge graph reasoning models to determine fault information. In this case, abnormal trend data is input into a trained diagnostic model after feature encoding. The model outputs multiple candidate faults and their confidence levels. The smart home appliance then selects the first fault information based on the confidence level ranking and business strategy. If the highest confidence level does not reach a set threshold, the result can be marked as awaiting manual review to ensure the robustness of the diagnostic output.

[0074] Furthermore, the fault information of the first device can be structurally encapsulated: the smart home appliance generates fields corresponding to the fault information of the first device, such as fault identifier, fault description text, associated components, possible causes, risk level, and suggested handling direction. For example, the fault description text summarizes the possible problems of the current device, associated components indicate objects involved such as heating elements, heat exchangers, water pumps, filters, valve bodies, and sensors, and the risk level distinguishes whether it affects continued operation and whether priority dispatch is required. The structured fault information formed in this way can be called by subsequent large language models, and can also be directly used by after-sales platforms, customer service agents, and work order systems.

[0075] Based on the above analysis, this step achieves a mapping transformation from abnormal trends to fault semantics, enabling smart home appliances to provide preliminary fault judgments consistent with changes in device status even before a clear shutdown fault code is generated. Compared to methods relying solely on subjective user descriptions or single alarm codes, this processing method can transform scattered time-series data into interpretable fault information, reducing the burden of manually comparing logs and maintenance manuals, improving diagnostic efficiency, and laying the foundation for generating targeted handling suggestions.

[0076] S103: Generate fault handling suggestions adapted to equipment fault information through a pre-trained large language model.

[0077] In this step, the large language model is the core generative model used to generate fault handling suggestions based on input information. It is responsible for converting the initial device fault information into executable natural language suggestions. This model can be a pre-trained language generation model fine-tuned for home appliance maintenance scenarios. Its training corpus can include historical fault information, repair work orders, customer service Q&A, device manuals, repair manuals, knowledge base text, and processing result feedback, enabling the model to comprehensively understand the semantics of home appliance faults, processing procedures, and user expressions. The fault handling suggestions are executable recommendations generated for the device fault. Their output can include explanations of the fault cause, self-check steps, risk warnings, whether to suspend use, whether to schedule an on-site visit, required consumables or tools, and further handling tips for customer service and repair personnel.

[0078] Specifically, after receiving initial device fault information, smart home appliances assemble it along with some contextual information into model input. This contextual information may include anomaly trend data summaries, device model, device installation scenario, historical repair records, user repair reports, current fault level, and user identity type. Subsequently, a prompt word template is constructed to convert the structured fault information into an input format suitable for language model understanding. For example, the input might explicitly state that the current device is a specific model of water heater, the anomaly is a continuous increase in heating time, the corresponding initial fault is decreased heating efficiency, and the model is required to output suggested text understandable to ordinary users, a summary text for customer service, and a risk level description. After receiving the input, the large language model performs semantic reasoning and text generation, outputting fault handling suggestions adapted to the device fault information.

[0079] In one possible implementation, the fault information of the first device is input into a large language model, which then generates processing suggestions by combining the fault knowledge obtained during the pre-training phase. This simplifies the call chain and is suitable for scenarios where the fault information is already relatively clear.

[0080] In another possible implementation, smart home appliances use both abnormal trend data and initial device malfunction information as contextual input, allowing the model to consider both trend characteristics and malfunction conclusions during generation. For example, for the trend of "slowly decreasing flow," the model can not only generate suggestions such as "check the filter or water inlet channel," but also supplement it with a risk warning based on the duration and magnitude of the decrease, such as "if the flow rate has decreased by more than a set percentage in the past week, it is recommended to suspend high-frequency use and replace the filter as soon as possible," thus making the output more consistent with the actual state of the device. The generated malfunction handling suggestions can also undergo terminology simplification, sensitive risk verification, and formatting adjustments. For example, professional expressions can be converted into user-friendly explanations, content involving safety risks can be elevated to mandatory reminders, and suggestions can be divided into user self-check content and after-sales handling content.

[0081] Furthermore, the generated troubleshooting suggestions can be pushed to mobile applications, mini-programs, device screens, customer service workstations, or ticket systems. When the troubleshooting suggestion is determined to be a simple check or consumable maintenance that the user can complete themselves, the smart home appliance can directly display step-by-step instructions to the user, such as checking whether the water inlet valve is fully open, observing whether the filter cartridge has expired, and confirming whether the power supply and network status are normal. When the suggestion involves risks such as water leakage, overheating, abnormal combustion, or abnormal pressurized components, the smart home appliance can automatically add warning messages such as stop use and contact after-sales service, and trigger the pre-creation of repair tickets or human customer service intervention. For cases that have been handled, the smart home appliance can also collect feedback results such as whether the user adopted the suggestion, whether the problem was solved, and the final repair conclusion, and feed these back into training data or rule bases to continuously improve the matching degree of subsequent suggestion generation.

[0082] Based on the above analysis, it is evident that by using a pre-trained large language model to convert the fault information of the first device into fault handling suggestions that can be directly used by both users and the after-sales system, the problem of traditional solutions where the backend output remains at the level of parameter values, logs, or fault codes, making it difficult for ordinary users to understand and execute. This processing method not only improves the comprehensibility of the suggestions but also automatically distinguishes between self-service and on-site service scenarios based on the fault information, thereby improving the rationality of service resource allocation and reducing unnecessary manual interaction and on-site service costs.

[0083] In one possible implementation, existing technologies typically output fault handling suggestions through a fixed, single channel, such as pushing text messages via a mobile application or issuing alarms via a device buzzer. However, different household users have significantly different usage habits and interaction preferences for smart home appliances. Some users prefer to interact with devices via voice, some prefer to view graphical interfaces, and others may only focus on concise SMS notifications. Using a fixed, single output method results in fault handling suggestions failing to reach users in a timely manner, reducing the practicality of fault diagnosis and user satisfaction. Therefore, to improve the efficiency of fault handling suggestions and user experience, and to match the output method with the personalized interaction preferences of household users, this embodiment introduces a technical means to determine the target interaction method based on the interaction habits of household users with smart home appliances, and output fault handling suggestions through this target interaction method. The specific implementation steps for outputting fault handling suggestions are as follows:

[0084] Based on the interaction habits of home users with smart home appliances, determine the target interaction method; and output troubleshooting suggestions based on the target interaction method.

[0085] Interaction habits refer to the common interaction methods between home users and smart home appliances, while the target interaction method refers to the specific interaction channel or form used to deliver troubleshooting suggestions. Smart home appliances can pre-build user profiles and, combined with mobile application operation records, voice wake-up records, message viewing records, and device panel operation records, statistically analyze the historical interaction behavior of home users to identify their commonly used receiving methods and use these methods as the target interaction method. For example, if a user frequently checks device status through a mobile application, the target interaction method is determined to be application push notifications; if a user often obtains information through a voice speaker or device voice broadcast, the target interaction method can be voice broadcast; if a user habitually views prompts through the home control panel or mini-program messages, the corresponding interface can be used as the target interaction method. This target interaction method is used to present troubleshooting suggestions in a familiar form to the user, thereby lowering the understanding threshold.

[0086] Specifically, after generating troubleshooting suggestions, smart home appliances match these suggestions against pre-stored interaction preference information. If the preference information matches the current online status of the device and the reachability of the user terminal, the troubleshooting suggestions are converted into the corresponding display format. For push notifications, the fault description, troubleshooting suggestions, and necessary precautions can be packaged into a card message and sent to the user terminal. For voice broadcasts, the text content can be synthesized into speech and output through the device's speaker. For panel displays, the suggestions can be compressed into short text and displayed on the device screen. This approach ensures that the troubleshooting suggestions align with existing user habits, improving accessibility, readability, and response efficiency. It also reduces missed messages, misunderstandings, or duplicate inquiries caused by mismatched output channels, thereby enhancing the overall interactive experience of after-sales service for connected home appliances.

[0087] This application provides a method for diagnosing home appliance faults, including collecting operating data from smart home appliances and identifying whether there are abnormal trend data in the operating data; if abnormal trend data exists, determining the corresponding first device fault information based on the abnormal trend data; and then generating fault handling suggestions adapted to the device fault information through a pre-trained large language model. In this embodiment, by constructing a sequential processing link from operating data collection, abnormal trend identification, fault information determination to suggestion generation, the connected home appliance can output scenario-specific diagnostic results and handling content before the fault is fully manifested, thereby solving the problems of over-reliance on fault code triggering, vague user descriptions, high cost of manual comparison by customer service, and difficulty in understanding suggestions in the prior art. Furthermore, this method links device status changes with a knowledge output mechanism, so that the diagnostic results are not only based on data but can also be accurately conveyed to users and after-sales personnel in natural language. Therefore, it can improve the timeliness of fault prediction, improve diagnostic efficiency, improve user comprehensibility, and provide more efficient technical support for subsequent self-service processing, customer service support, and repair resource scheduling. In one possible embodiment, the above steps can be performed by a single server; in another exemplary embodiment, they can also be performed collaboratively by the device, edge nodes, and cloud platform. It should be understood that the above examples are merely illustrative and not limiting.

[0088] Figure 2 A flowchart illustrating a home appliance fault diagnosis method provided in this application embodiment. Figure 2 .like Figure 2 As shown, the method includes:

[0089] S201. Determine whether a fault description, which is used to indicate a fault in a smart home appliance, is detected within a preset time period.

[0090] In this step, in existing technologies, when large language models generate fault handling suggestions, they typically rely solely on the operating data and fault code information automatically collected by the device. However, in real-world home use scenarios, users may observe some abnormal phenomena in the device, such as unusual noises, odors, or screen flickering. These phenomena are sometimes difficult for sensors to fully capture and convert into structured data. Relying solely on the first device fault information automatically identified by the device presents the following problems: the large language model cannot acquire the fault phenomena subjectively perceived by the user, leading to suggestions that may overlook issues of actual concern to the user; there is an information gap between device operating data and the user's actual usage experience, resulting in insufficient targeting and completeness of the fault handling suggestions. Therefore, in order to integrate the fault phenomena subjectively described by the user with the fault information objectively identified by the device, and to improve the comprehensiveness and accuracy of fault handling suggestions generated by the large language model, this embodiment introduces a technical means to determine whether a fault description input by the user is detected within a preset time period, and if so, to determine the second device fault information by combining it with a knowledge base, thereby inputting multi-source information into the large language model to generate fault handling suggestions.

[0091] The fault description is a text or structured statement entered by the user in a mobile application, customer service interface, or voice interaction portal to indicate abnormal phenomena of the device. The smart home appliance performs semantic recognition on the user input within a preset time period, and when it recognizes content related to the device fault, it determines it as a fault description.

[0092] Specifically, after determining the first device fault information, the device starts timing and enters a waiting state for a preset time period. During this preset time period, the device monitors in real time whether it receives fault descriptions input by the user through various interactive channels. For example, the device can collect the user's voice input through a microphone, receive the user's text input through a touchscreen or associated mobile terminal, or receive images of the device's abnormal state taken by the user through a camera.

[0093] S202. If it exists, then the corresponding second device fault information is determined by searching the knowledge base based on the fault description.

[0094] The knowledge base is a database that stores at least the explanations of equipment fault codes, maintenance manuals, historical work orders, and product manuals.

[0095] In this step, fault code interpretation is used to establish the correspondence between fault codes and fault causes; the maintenance manual is used to provide repair actions and component inspection information; historical work orders are used to reflect the handling records of similar faults; and the product manual is used to provide model parameters and structural descriptions. The second equipment fault information is fault information obtained by matching the fault description in the knowledge base, used to supplement or correct the first equipment fault information to make it more consistent with the user's description and the current equipment model.

[0096] Specifically, if a user-inputted fault description is detected within a preset time period, semantic parsing is performed on the fault description to extract keywords and key features, such as the user describing abnormal hot water temperature from a water heater. Subsequently, the device matches the extracted semantic features with data stored in a knowledge base, including device fault code explanations, repair manuals, historical work orders, and product manuals. The device fault code explanations record the fault phenomena and causes corresponding to various fault codes; the repair manuals record the troubleshooting steps and repair methods for various faults; historical work orders record past cases of similar fault phenomena; and the product manuals record the normal operating parameters and common usage problems of the equipment. The device then uses semantic similarity calculations or keyword matching algorithms to search the knowledge base for the fault record most relevant to the user's fault description and determines the corresponding second device fault information. This second device fault information includes structured content such as fault type, possible causes, and involved components.

[0097] In one possible implementation, in existing technologies, user-input fault descriptions are typically unstructured natural language text, such as a user describing a water heater making abnormal noises or producing insufficiently hot water. If a knowledge base is directly searched based on such fault descriptions, the same fault phenomenon may be described in multiple different ways due to significant differences in users' expression habits, vocabulary preferences, and regional language usage. This makes it difficult to accurately locate the corresponding fault record during knowledge base retrieval. Furthermore, different water heater models exhibit significant differences in hardware structure, control logic, operating parameter ranges, and common fault modes. The same fault description may correspond to drastically different causes on different models. If the constraints of device model and actual operating data are not considered during the search process, there will be issues with generalized search results and mismatch with the current device, reducing the accuracy of the identified second device fault information and consequently affecting the reliability of subsequent fault handling suggestions. Therefore, to improve the accuracy of knowledge base retrieval and its compatibility with users' actual devices, and to ensure that the fault information of the second device simultaneously reflects the user's subjective observation, device model characteristics, and objective operating status, this embodiment introduces a technical means of extracting target keywords from the fault description, matching the target keywords, the device model of the smart home appliance, and operating data, and retrieving the knowledge base based on the matching results to obtain the fault information of the second device. The corresponding specific implementation method is as follows:

[0098] Extract target keywords from the fault description; match the target keywords, the device model of the smart home appliance, and the operating data; and retrieve the knowledge base based on the matching results to obtain the fault information of the second device.

[0099] The target keywords are key semantic terms extracted from fault descriptions for retrieval and matching. They typically include words reflecting abnormal phenomena, component names, or status descriptions, used to narrow the search scope of the knowledge base and improve fault association accuracy. The device model identifies the specific specifications and type of the smart home appliance. Different models have different structural configurations, control logic, and common fault characteristics, thus helping to avoid confusion regarding fault knowledge between different models. Operational data refers to the status information uploaded by the smart home appliance during network operation, typically including temperature, water pressure, flow rate, power, start / stop status, runtime, and fault codes, reflecting the device's current actual operating status.

[0100] Specifically, after receiving the fault description input by the user, the device first performs natural language processing on the fault description to extract target keywords. For example, for a water heater, if the user inputs a fault description that the water heater makes a buzzing sound and the bath water is not hot enough, the device will extract raw words such as buzzing sound, bath water, and not hot enough through word segmentation and semantic reduction. It will then further classify the "not hot enough bath water" as the target keyword "low water temperature" and the "buzzing sound" as the target keyword "abnormal fan noise".

[0101] Subsequently, the device reads the device model information stored in its local memory and simultaneously retrieves the currently collected operational data. Then, the device performs multi-dimensional matching between the extracted target keywords, device model, and operational data, including semantic matching and numerical matching.

[0102] At the semantic matching level, the device side performs semantic comparison between the target keywords and the corresponding fault feature entries in the knowledge base for that device model. For example, for water heater model A, the knowledge base stores a fault mode index specific to that model: abnormal fan noise faults correspond to abnormal fan speed and bearing wear characteristics, while insufficient heating faults correspond to decreased combustion efficiency and heat exchanger scaling characteristics. The device side semantically associates abnormal fan noise with abnormal noise fault features for that model in the knowledge base, and semantically associates low outlet water temperature with heating performance fault features.

[0103] At the numerical matching level, the device verifies the consistency between operating data and the physical state implied by the target keywords. For example, for the target keyword "low outlet water temperature," the device compares the actual outlet water temperature of 36 degrees Celsius with the set target temperature of 45 degrees Celsius, confirming a negative temperature deviation of 9 degrees Celsius. This numerical difference aligns with the semantic description of "low outlet water temperature," verifying the physical authenticity of the keyword. For the target keyword "abnormal fan noise," the device compares the current fan speed of 3200 revolutions per minute with the normal operating speed range of the device model. According to the product manual for device model A, the normal fan speed for this model at a water flow rate of 10 liters per minute should be 2400 to 2800 revolutions per minute. The current speed exceeds the normal upper limit by approximately 500 revolutions per minute, and this abnormal operating data numerically confirms the target keyword "abnormal fan noise."

[0104] Based on the combined results of semantic and numerical matching, the device retrieves the second equipment fault information from the knowledge base. For example, the knowledge base stores historical work order records for equipment model A, which record related fault cases such as abnormally high fan speed and low-frequency humming sound caused by fan bearing wear, and incomplete combustion, decreased heat exchange efficiency, and water outlet temperature lower than the set value due to insufficient air supply. The device then performs a correlation search with the multi-dimensional matching results and historical work orders, maintenance manuals, and fault code explanations in the knowledge base to determine that the second equipment fault information corresponding to this fault description is a decrease in heating performance caused by fan bearing wear and abnormal burner air distribution.

[0105] By employing the above methods, a correlation constraint is established between fault descriptions and equipment status. This allows knowledge base retrieval to move beyond relying solely on single keywords, comprehensively considering model differences and real-time operational data. This improves the accuracy and relevance of fault information for the second device. When this result is subsequently input into a large language model, it provides more reliable fault information for generating fault handling suggestions, reducing misjudgments and irrelevant searches, and enhancing the efficiency and user understandability of after-sales diagnostics for home appliances.

[0106] S203. Input the abnormal trend data, the fault information of the first device and the fault information of the second device into the large language model to generate fault handling suggestions.

[0107] In this step, after determining the fault information of the second device, the device integrates and organizes the abnormal trend data, the fault information of the first device, and the fault information of the second device to form a comprehensive fault context. The device then inputs this comprehensive fault context into a pre-trained large language model. Based on its language understanding and reasoning capabilities acquired during training, the large language model comprehensively analyzes the correlation and complementarity of multi-source information to generate fault handling suggestions adapted to the device fault information.

[0108] In one possible implementation, in existing technologies, after a large language model generates fault handling suggestions, these suggestions are typically directly output to the user without differentiated assessment and triage based on the hazard level and user feasibility of the faults involved. For faults with high safety risks, such as gas leaks, short circuits, and burns, simply providing users with self-troubleshooting and handling suggestions may lead to safety accidents due to users' lack of professional knowledge and operational experience. Conversely, for low-risk problems that can be resolved with simple operations, uniformly generating repair work orders and dispatching professionals would result in the ineffective use of repair resources and increased service costs for enterprises. Therefore, to intelligently classify fault handling suggestions based on risk, enabling high-risk faults to automatically trigger professional repair intervention and low-risk faults to guide users to handle them themselves, this embodiment introduces a technical means to determine the fault type, user operation complexity, and corresponding historical repair records based on the fault handling suggestions, and to determine a risk score to decide whether to generate a repair work order. The specific implementation steps are as follows:

[0109] Based on the fault handling suggestions, the fault type, user operation complexity, and corresponding historical maintenance records are determined. A risk score is determined based on the historical maintenance records, user operation complexity, and historical maintenance records. The risk score determines whether to generate a maintenance work order. When the risk score indicates high risk, a maintenance work order is generated based on the fault handling suggestions and an emergency prompt is triggered. When the risk score indicates low risk, fault handling suggestions are output.

[0110] The fault type is used to categorize the problems corresponding to the fault handling suggestions. The categorization results are linked to subsequent risk scoring and work order flow. User operation complexity characterizes the ease with which a user can perform the operation according to the fault handling suggestions. It is typically determined by a combination of factors, including the number of operations, whether special tools are required, and whether disassembly, wiring, or sealing is involved. Historical maintenance records reflect the handling methods, results, and rework status of the same or similar faults in previous maintenance. Historical maintenance records can be retrieved from the maintenance database by fault type. The risk score indicates the overall risk level of the current fault handling and serves as the basis for determining whether to generate a maintenance work order and trigger an emergency alert.

[0111] Specifically, after generating fault handling suggestions using a large language model, the device first parses the suggestions to determine the fault type. Then, based on the specific operational steps in the suggestions, the device determines the user's operational complexity. The device analyzes each instruction in the suggestions, assessing the feasibility of each operation for an average user. For example, if the suggestions only involve operations that require no tools and are safe and harmless, such as rotating the temperature control knob, pressing the reset button, or cleaning the external filter, the device determines the user's operational complexity to be low. However, if the suggestions involve operations requiring specialized tools, a certain level of manual dexterity, or involving gas and electrical safety, such as disassembling the water heater casing, using a multimeter to test the circuit board voltage, adjusting the gas proportional valve opening, or performing deep cleaning of the combustion chamber, the device determines the user's operational complexity to be high.

[0112] Afterwards, the device retrieves maintenance statistics for this type of fault from the local database or the after-sales service platform database via the network. This data includes information on the same or similar models of water heaters and their repair statistics during past service cycles.

[0113] After obtaining the above information, the device determines a risk score based on historical maintenance records, user operation complexity, and other relevant factors. Specifically, the device establishes a risk assessment model that weights and integrates parameters such as the inherent hazard weight of the fault type, the quantified score of user operation complexity, and the incidence rate of safety incidents and the rate of professional maintenance intervention in historical maintenance records. Taking a water heater as an example, if the fault type is a sensor detection fault, historical maintenance records show a high success rate of user self-handling with no safety incidents, and the user operation complexity involves only plugging and unplugging connectors and replacing batteries, then the weighted risk score is low risk. If the fault type is a gas leak fault, historical maintenance records show an extremely low success rate of user self-handling with potential safety risks, and the user operation complexity involves gas pipeline inspection and seal replacement, then the weighted risk score is high risk.

[0114] After determining the risk score, if the risk score indicates high risk, the device automatically generates a repair work order based on fault handling suggestions. This work order includes at least the water heater model, fault type, fault symptom summary, user contact information, installation address, risk level indicator, and recommended priority on-site visit time. The work order is also synchronized to the after-sales service platform to arrange for professional repair personnel to arrive as soon as possible. Simultaneously, the device triggers emergency alerts, such as issuing a continuous alarm sound via the water heater's built-in buzzer, providing a voice prompt through a linked smart speaker to immediately stop using the water heater, close the main gas valve and water inlet valve, and ensure indoor ventilation. A warning message stating "Do not disassemble" is also displayed in bright red on the device's screen. When the risk score indicates low risk, the device directly provides fault handling suggestions to the user through targeted interaction. For example, it may guide the user step-by-step through simple operations such as cleaning the filter, adjusting water pressure, and restarting the device via voice, or display graphic instructions via a mobile application, allowing the user to troubleshoot and restore the device independently.

[0115] Furthermore, fault handling suggestions generated by large language models are typically presented in natural language text, lacking structured breakdown. It is difficult for the device to automatically determine the inherent hazard attributes, operational difficulty level, and historical maintenance patterns of the fault based solely on the suggested text. This can easily lead to a lack of objective and quantifiable input for subsequent risk scoring and work order decisions, resulting in high-risk faults being misjudged as low-risk or low-risk faults being over-assigned work orders. Therefore, to transform unstructured fault handling suggestions into structured, quantifiable, multi-dimensional evaluation elements, providing clear analytical sources for fault type determination, operational complexity analysis, and historical record queries, this embodiment introduces a technique that includes fault descriptions, fault codes, and maintenance operation information in fault handling suggestions, and uses these to determine fault types, user operational complexity, and historical maintenance records, respectively.

[0116] The troubleshooting recommendations include a fault description, fault code, and maintenance operation information. The specific implementation steps for determining the fault type, user operation complexity, and historical maintenance records are as follows:

[0117] Based on the fault description or fault code, determine the corresponding fault type, which includes safety hazard faults, performance degradation faults, and consumable replacement faults; based on maintenance operation information, analyze the number of steps in the maintenance process, whether preset maintenance tools are used, and whether it includes gas pipeline disassembly or circuit connection operations, and determine the user operation complexity based on the analysis results; query the maintenance database for a preset time period based on the fault type to determine historical maintenance records.

[0118] The system includes a fault description to represent the user's textual expression of abnormal equipment phenomena, a fault code to identify the fault status output by the equipment during operation or self-test, and maintenance operation information to represent the operation content, sequence, and required tools involved in the maintenance suggestions. Safety hazard faults indicate faults that may pose a danger to the user or equipment safety, performance degradation faults indicate faults where equipment performance declines but may not immediately endanger safety, and consumable replacement faults indicate faults that can be resolved by replacing consumables. Preset maintenance tools can include wrenches, insulation detectors, seal removal and installation tools, or multimeters, etc. The preset time period can be set to the past three months, six months, or one year, depending on the equipment model, after-sales policy, or fault statistics cycle.

[0119] Specifically, smart home appliances first map and match keywords in the fault description with fault codes. For example, when the fault description contains "gas leak," "abnormal combustion," or the fault code points to a gas leak risk, the fault type is determined to be a safety hazard fault; when the fault description reflects "slower heating," "reduced output," or the code corresponds to a performance degradation anomaly, the fault type is determined to be a performance degradation fault; when the fault description involves "filter expired," "consumable replacement reminder," or the code corresponds to the end of consumable lifespan, the fault type is determined to be a consumable replacement fault.

[0120] Smart home appliances perform structured analysis of maintenance operation information, counting the number of operation units included and identifying whether preset maintenance tools are required. Further analysis determines if gas pipeline disassembly or electrical connection operations are involved. When the number of operation units is small, requires no special tools, and does not involve gas pipeline disassembly or electrical connection, the user's operation complexity is determined to be low; otherwise, it is determined to be high. Based on the determined fault type, the smart home appliance then searches the maintenance database within a preset time period to retrieve historical maintenance records corresponding to the same type of fault. These historical maintenance records may include fault symptoms, handling methods, maintenance results, and recurrence rates.

[0121] By combining fault descriptions, fault codes, and repair operation information for fault determination, fault types, user operation complexity, and historical repair records can be synchronously linked, providing a unified basis for subsequent risk assessments and repair work order generation. Since different fault types correspond to different risk levels and handling methods, combining historical repair records allows for a more accurate determination of whether a fault is suitable for user self-handling or requires intervention from after-sales personnel. Simultaneously, it improves the accuracy of fault classification, reducing misjudgments caused by relying solely on a single fault code or vague description. Furthermore, by linking repair complexity and historical records, it enhances the feasibility and safety of fault recommendations, helps reduce unnecessary on-site repair frequency, and improves the efficiency of after-sales processing for connected home appliances.

[0122] S204. If not, input the abnormal trend data and the first equipment fault information into the large language model to generate fault handling suggestions.

[0123] In this step, if no user-inputted fault description is detected within a preset time period, the device directly inputs the abnormal trend data and the first device fault information into the large language model. In this case, the large language model generates fault handling suggestions based solely on the objectively collected data from the device, avoiding delays in fault handling due to waiting for user input.

[0124] This application provides a method for diagnosing home appliance faults. By linking user fault descriptions with a knowledge base and introducing fault information from a second device into the generation process, the large language model can simultaneously reference objective device anomalies, backend diagnostic results, and user subjective descriptions, thereby generating handling suggestions that are more consistent with the actual fault state. Even when no user input is detected, the system can still output suggestions based on anomaly trend data and first device fault information, ensuring the continuity of the diagnostic process. Adopting this approach improves the relevance and understandability of fault suggestions, reduces manual follow-up questions and repetitive searches, enhances the efficiency of networked home appliance maintenance, and lowers after-sales service costs.

[0125] Figure 3 This is a schematic diagram of the structure of a home appliance fault diagnosis device provided in an embodiment of this application. Figure 3 As shown, the appliance fault diagnosis device 30 includes:

[0126] The acquisition module 301 is used to collect the operating data of smart home appliances and identify whether there are abnormal trend data in the operating data;

[0127] The determination module 302 is used to determine the corresponding first equipment fault information based on the abnormal trend data if the fault exists.

[0128] The control module 303 is used to generate fault handling suggestions adapted to equipment fault information through a pre-trained large language model.

[0129] In one possible implementation, the control module 303 is further configured to:

[0130] Determine whether a fault description, used to indicate a malfunction of a smart home appliance, is detected within a preset time period;

[0131] If it exists, the knowledge base is searched based on the fault description to determine the corresponding second equipment fault information. The knowledge base is a database that stores at least the equipment fault code explanation, maintenance manual, historical work orders, and product manual.

[0132] Input abnormal trend data, first equipment fault information, and second equipment fault information into the large language model to generate fault handling suggestions;

[0133] If not, the abnormal trend data and the first equipment fault information are input into the large language model to generate fault handling suggestions.

[0134] In one possible implementation, the control module 303 is further configured to:

[0135] Extract target keywords from the fault description;

[0136] And match the target keywords, smart home appliance models, and operating data;

[0137] Based on the matching results, the knowledge base was searched to obtain the fault information of the second device.

[0138] In one possible implementation, after generating fault handling suggestions, the control module 303 is further configured to:

[0139] Based on the fault handling suggestions, the fault type, the complexity of user operations, and the corresponding historical maintenance records for the fault type are determined.

[0140] A risk score is determined based on historical maintenance records, user operation complexity, and whether a maintenance work order should be generated based on the risk score.

[0141] When the risk score indicates a high risk, a maintenance work order is generated based on the fault handling suggestions and an emergency alert is triggered.

[0142] When the risk score indicates low risk, output fault handling suggestions.

[0143] In one possible implementation, the fault handling suggestion includes a fault description, a fault code, and maintenance operation information. The control module 303 is further configured to:

[0144] Based on the fault description or fault code, determine the corresponding fault type, which includes safety hazard faults, performance degradation faults, and consumable replacement faults.

[0145] Based on maintenance operation information, analyze the number of steps in the maintenance process, whether preset maintenance tools are used, and whether it includes gas pipeline disassembly or circuit connection operations, and determine the complexity of user operation based on the analysis results.

[0146] Based on the fault type, query the maintenance database for a preset time period to determine historical maintenance records.

[0147] In one possible implementation, the acquisition module 301 is further configured to:

[0148] The running data is monitored by time series analysis algorithms to generate the corresponding allowable fluctuation range;

[0149] By comparing the operational data with the allowable fluctuation range, it can be determined whether there are any abnormal trends in the operational data.

[0150] In one possible implementation, after generating fault handling suggestions adapted to the device fault information, the control module 303 is further configured to:

[0151] Based on the interaction habits of home users with smart home appliances, determine the target interaction method;

[0152] Fault handling suggestions are output through target interaction.

[0153] This embodiment provides a home appliance fault diagnosis device that can execute the home appliance fault diagnosis method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0154] Figure 4 This is a schematic diagram of the structure of a smart home appliance provided in an embodiment of this application. Figure 4 As shown, the smart home appliance 40 includes a processor 401 and a memory 402 communicatively connected to the processor 401. Optionally, the smart home appliance 40 also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0155] Memory 402 stores instructions executed by the computer;

[0156] The processor 401 executes computer execution instructions stored in the memory 402 to implement the aforementioned home appliance fault diagnosis method.

[0157] At least one processor 401 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0158] Optionally, in specific implementations, the processor 401 and memory 402 are implemented independently. In this case, the processor 401 and memory 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0159] Optionally, in a specific implementation, if the processor 401 and the memory 402 are integrated on a single chip, the processor 401 and the memory 402 can communicate through an internal interface.

[0160] This application also provides a computer storage medium storing computer execution instructions, which, when executed by a processor, implement the aforementioned home appliance fault diagnosis method.

[0161] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0162] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. Both the processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the control device of a garment handling apparatus.

[0163] This unit division is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0166] If this function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods indicated in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0168] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for diagnosing household appliance faults, characterized in that, The method includes: Collect operational data from smart home appliances and identify whether there are any abnormal trends in the operational data; If it exists, the corresponding first equipment fault information is determined based on the abnormal trend data; By using a pre-trained large language model, fault handling suggestions adapted to the equipment fault information are generated.

2. The method according to claim 1, characterized in that, The process of generating fault handling suggestions adapted to the device fault information using a pre-trained large language model includes: Determine whether a fault description, used to indicate a malfunction of the smart home appliance, is detected within a preset time period; If it exists, the knowledge base is retrieved based on the fault description to determine the corresponding second equipment fault information, wherein the knowledge base is a database that stores at least equipment fault code explanations, maintenance manuals, historical work orders, and product manuals; The abnormal trend data, the first device fault information, and the second device fault information are input into the large language model to generate the fault handling suggestions. If not, the abnormal trend data and the first device fault information are input into the large language model to generate the fault handling suggestion.

3. The method according to claim 2, characterized in that, The step of retrieving the corresponding second device fault information based on the fault description knowledge base includes: Extract target keywords from the fault description; And match the target keywords, the device model of the smart home appliance, and the operating data; Based on the matching results, the knowledge base is retrieved to obtain the fault information of the second device.

4. The method according to claim 2, characterized in that, After generating the fault handling suggestion, the method further includes: Based on the fault handling suggestions, the fault type, user operation complexity, and corresponding historical maintenance records for the fault type are determined. A risk score is determined based on the historical maintenance records, the user operation complexity, and the historical maintenance records, and a maintenance work order is generated based on the risk score. When the risk score indicates a high risk, a maintenance work order is generated based on the fault handling suggestions and an emergency alert is triggered. When the risk score indicates low risk, the fault handling suggestion is output.

5. The method according to claim 4, characterized in that, The fault handling suggestion includes a fault description, fault code, and maintenance operation information. The step of determining the fault type, user operation complexity, and historical maintenance records corresponding to the fault type based on the fault handling suggestion includes: Based on the fault description or the fault code, determine the corresponding fault type, wherein the fault type includes safety hazard fault, performance degradation fault, and consumable replacement fault; Based on the maintenance operation information, the number of steps in the maintenance process, whether preset maintenance tools are used, and whether it includes gas pipeline disassembly or circuit connection operations are analyzed, and the complexity of the user operation is determined based on the analysis results. Based on the fault type, query the maintenance database for a preset time period to determine the historical maintenance records.

6. The method according to claim 1, characterized in that, The process of identifying whether the operational data contains abnormal trend data includes: The operational data is monitored using a time-series analysis algorithm to generate a corresponding allowable fluctuation range; By comparing the operational data with the allowable fluctuation range, it is determined whether there are any abnormal trend data in the operational data.

7. The method according to claim 1, characterized in that, After generating the fault handling suggestions adapted to the device fault information, the method further includes: Based on the interaction habits of home users with the smart home appliances, the target interaction method is determined; The fault handling suggestions are output through the target interaction method.

8. A home appliance fault diagnosis device, characterized in that, include: The acquisition module is used to collect operating data of smart home appliances and identify whether there are abnormal trend data in the operating data; The determination module is used to determine the corresponding first equipment fault information based on the abnormal trend data if the fault exists. The control module is used to generate fault handling suggestions adapted to the fault information of the device through a pre-trained large language model.

9. A smart home appliance, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the home appliance fault diagnosis method as described in any one of claims 1 to 7.

Images