Household appliance accessory compatibility verification system based on multi-source data

Abstract

The invention discloses a household appliance accessory compatibility verification system based on multi-source data, and relates to the technical field of smart home Internet of Things. Through convergence and alignment of operation data, network state data and a user fault text, compatibility risk judgment based on behavior evidence is formed in an equipment access and operation stage; the risk identification can be triggered without depending on a known list; a transition probability matrix is constructed for an application layer interaction instruction sequence, and difference degree measurement is performed on the transition probability matrix and a historical normal baseline, so that conflict identification pays attention to continuous deviation of an interaction structure, and concurrency control, long sequence triggering and chronic evolution anomaly are covered; besides, network topology change, link quality and gateway transaction processing time delay are brought into threshold condition adjustment, and a double-counting criterion of continuous overrun and accumulative overrun is adopted, so that early warning triggering is kept stable for short-time fluctuation and interaction frequency change, and meanwhile, response is kept for persistent abnormity.

Description

Technical Field

[0001] This invention relates to the field of smart home Internet of Things (IoT) technology, and in particular to a compatibility verification system for home appliance accessories based on multi-source data. Background Technology

[0002] The current smart home / appliance accessory ecosystem is largely composed of devices from multiple brands, various communication protocols, and hardware from different generations. To reduce access and interconnection risks, existing compatibility verification methods include some solutions that rely on alliance certification and compliance test results to verify whether accessories meet the corresponding protocol standards and have the prior conditions for network access / interoperability; other solutions combine compatibility information maintained on the platform side or in the cloud, matching the accessory's device identification information (such as model, version, firmware / regional SKU, etc.) with the compatibility list to determine its connectivity and controllability at the rule level.

[0003] However, in real-world deployment environments, even if devices belong to the same certified protocol and are shown as compatible at the manifest level, cross-vendor interoperability anomalies may still occur. These anomalies are often not due to protocol incompatibility, but rather to implementation differences and the use of extension points: for example, different choices regarding the trade-offs of optional protocol features (MAY / SHOULD), manufacturer-specific extensions (such as private profiles or manufacturer-defined clusters / commands / attributes), and differences in the timing of handling anomalies / border network events. These issues may be triggered after multi-device concurrent control, long-term operation, network topology changes, or firmware version iterations, manifesting as occasional command timeouts, state asynchrony, intermittent device offlineness, or functional degradation. These problems are highly scenario-dependent and sporadic; traditional laboratory conformance testing and static manifest matching are insufficient to cover all combinations and runtime sequences, making it difficult to promptly identify potential dynamic compatibility risks introduced by new device combinations / new firmware versions.

[0004] Therefore, there is a need for a component compatibility verification mechanism that can integrate multi-source information and perform more granular assessment and early warning of compatibility risks based on runtime behavior. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides a home appliance parts compatibility verification system based on multi-source data to solve the problems of difficulty in covering differences between certification and static lists, and difficulty in predicting implicit interoperability conflicts.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] This invention provides a home appliance component compatibility verification system based on multi-source data, comprising:

[0009] The data acquisition and aggregation module is used to collect device identification information and operating data from accessory devices to be connected, existing smart home appliances and their gateways, collect network status data of the smart home network, and obtain user fault text from external platforms.

[0010] The feature construction module is used to generate communication behavior features from the running data and network status data, and extract the main device identifier, associated device identifier and abnormal phenomenon description from the user fault text.

[0011] Anomaly identification module is used to output a conflict score and determine the conflict mode based on the communication behavior characteristics and the description of the abnormal phenomenon;

[0012] The risk knowledge base module is used to associate the conflict patterns with the corresponding device identification information to generate risk entries;

[0013] The early warning output module is used to output early warning information containing a risk scenario description and mitigation suggestions when a new device is connected or the conflict score exceeds a threshold.

[0014] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the device identification information includes at least two of the following: device brand, model, hardware version, and firmware version.

[0015] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the running data includes an application layer interaction instruction sequence, a response delay sequence corresponding to the instruction, and a device event log.

[0016] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the feature construction module includes: constructing an instruction transition probability matrix based on the interaction instruction sequence, and calculating the distribution statistical characteristics of the response delay sequence within a sliding time window;

[0017] When constructing the instruction transition probability matrix based on the interaction instruction sequence, the feature construction module discretizes the interaction instruction events into a set of states and counts the first-order transitions or chain-dependent second-order transitions of adjacent states within a sliding time window; it performs smoothing processing on sparse transitions when generating the transition probability matrix from the transition count; and it forms a normal baseline transition matrix based on historical normal interaction samples, calculates the difference between the transition probability matrix and the normal baseline transition matrix, and uses the difference as part of the communication behavior feature and inputs it into the anomaly identification module.

[0018] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the network status data includes at least one of network topology change events, wireless link quality indicators, and gateway transaction processing latency.

[0019] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the feature construction module performs named entity recognition and referential resolution on the user fault text, and outputs the main device identifier, associated device identifier and abnormal phenomenon description, wherein the abnormal phenomenon description includes at least the abnormal phenomenon category.

[0020] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the anomaly identification module uses a sequence coding model to encode the communication behavior features and calculates the conflict score in combination with the description of the anomaly phenomenon, and the conflict mode includes at least triggering conditions, affecting functions and confidence level.

[0021] As a preferred embodiment of the home appliance component compatibility verification system based on multi-source data described in this invention, the threshold is a dynamic threshold that is adaptively updated based on the normal scoring statistical baseline formed by historical normal interaction samples. During online operation, the dynamic threshold is modified by combining the actual results recorded by the risk knowledge base module to correct the normal scoring statistical baseline. Furthermore, network status data is introduced to conditionally adjust the threshold when constructing the dynamic threshold. When the early warning output module triggers an early warning, it simultaneously uses the number of consecutive exceedances of conflict scores and the cumulative exceedances within a preset time window as counting criteria. The threshold for the cumulative exceedances is determined by the number of interaction events within the time window and a preset proportional coefficient.

[0022] As a preferred embodiment of the home appliance accessory compatibility verification system based on multi-source data described in this invention, the mitigation suggestions include at least one of the following: adjusting device logical grouping, adjusting the gateway's polling and retry parameters for the target device, switching the wireless channel, or suggesting a temporary suspension of firmware upgrades for specific devices.

[0023] As a preferred embodiment of the home appliance parts compatibility verification system based on multi-source data described in this invention, the risk knowledge base module records the actual result feedback after the warning and uses the result feedback to update the model parameters of the anomaly identification module.

[0024] Through the above technical solution, the present invention can achieve at least the following beneficial effects:

[0025] To address the difficulty of identifying interoperability risks in real-world operation through static authentication and inventory verification, this invention aggregates and aligns operational data, network status data, and user fault texts to form a compatibility risk assessment based on behavioral evidence during device access and operation, enabling risk identification to be triggered without relying on a known inventory list.

[0026] To address the problems of sporadic, strong temporal dependence, and difficulty in reproducing latent conflicts, this invention constructs a transition probability matrix from the application layer interaction instruction sequence and measures the difference between it and the historical normal baseline. This allows conflict identification to focus on the continuous deviation of the interaction structure, thereby covering concurrency control, long sequence triggering, and chronic evolutionary anomalies.

[0027] To address the problem of difficulty in distinguishing between network jitter and protocol interaction conflicts, which can easily lead to false alarms, this invention incorporates network topology changes, link quality, and gateway transaction processing latency into threshold condition adjustment. It also employs dual counting criteria of continuous and cumulative over-limits to ensure that alarm triggering remains stable in response to short-term fluctuations and changes in interaction frequency, while maintaining a response to persistent anomalies.

[0028] To address the problem of the difficulty in timely accumulating unknown risks brought about by new firmware / combinations, this invention maps conflict patterns into risk entries with brand, model, and firmware version attributes, and feeds back the actual results after the warning to update the statistical baseline and model parameters, so that risk knowledge can be gradually accumulated with real operation and feedback, forming a searchable, reusable, and iterative risk management closed loop.

[0029] To address the lack of actionable mitigation paths on the user side, the warning information simultaneously provides a risk scenario description and mitigation suggestions. These mitigation suggestions are then linked with a summary of triggering conditions, symptom fields, and a network status summary to generate an output that is actionable for configuration / networking / upgrade strategies, reducing the randomness of investigation and handling. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0031] Figure 1 This is a framework diagram of the home appliance accessory compatibility verification system based on multi-source data in the embodiment. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0033] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way. Example 1:

[0034] like Figure 1 As shown, this embodiment proposes a home appliance parts compatibility verification system based on multi-source data, including:

[0035] The data acquisition and aggregation module is used to collect device identification information and operating data from accessory devices to be connected, existing smart home appliances and their gateways, as well as network status data of the smart home network and user fault text from external platforms.

[0036] The data acquisition and aggregation module is deployed on the gateway side and connects to the device-side diagnostic interface. The gateway side proxies and forwards application-layer interactions between devices and records interaction events along the forwarding path. Interaction events are stored in a unified recording format, including: event timestamp, source device identifier, destination device identifier, protocol type identifier, interaction command type identifier, interaction command parameter summary, response result identifier, and response latency. Device event logs are reported to the gateway side through the device-side log interface. The logs include at least: power-on / reset events, network entry / exit events, reconnection events, firmware version change events, abnormal restart events, and resource alarm events. Network status data is collected by the gateway-side network management function and forms a status event stream, which includes network topology change events, link quality indicator events, and gateway transaction processing latency events.

[0037] Furthermore, network topology change events are generated in an event-triggered manner and include the triggering device identifier; wireless link quality indicators and gateway transaction processing latency are generated in a periodic sampling manner, with the sampling period being an implementation parameter, defaulting to 5 seconds and adjustable from 1 to 30 seconds; when a test is missing within the sampling period, the system writes a missing test flag to the missing test item and retains the previous sampled value for alignment, without generating a new topology change event.

[0038] In this embodiment, the event timestamp is generated using the gateway-side system time as a unified time base. The timestamp resolution is an implementation parameter, defaulting to 1 millisecond and adjustable from 1 to 100 milliseconds. The source device identifier and destination device identifier are derived from the device identifier information written during the gateway-side network entry and binding process, and are stored as fixed-length strings in the interaction event record. The fixed length is an implementation parameter, defaulting to 32 characters and adjustable from 16 to 64 characters. The protocol type identifier is given by the gateway-side protocol stack parsing result and together with the interaction command type identifier, forms a traceable parsing link. The enumeration value corresponding to the interaction command type identifier is within the same protocol type identifier range. The parameters are kept unique; the interaction command parameter summary is the implementation parameter, which is represented by a truncated parameter key-value pair sequence by default and limited to a length of 32 bytes, adjustable from 16 to 128 bytes. Parts exceeding the length are truncated but the truncation mark is retained; the response result identifier is used to record three types of results: success, failure, and timeout. The timeout determination uses a timeout time threshold as an implementation parameter, which is 2000 milliseconds by default and adjustable from 500 to 10000 milliseconds; the response latency is calculated as the difference between the timestamp of the interaction command event sent by the source device and the timestamp of the response result event returned by the destination device, in milliseconds, and is synchronously written to the same interaction event record with the response result identifier.

[0039] Specifically, the device-side log interface pushes device event logs asynchronously. The reporting period is an implementation parameter, with a default of 10 seconds and an adjustable range of 1 to 60 seconds. When the reporting link is interrupted, the device side retains the latest logs in a circular cache. The cache retention time is an implementation parameter, with a default of 60 seconds and an adjustable range of 10 to 600 seconds. After the link is restored, the logs are resent in the order of event timestamps. Firmware version change events are generated and written to the device event log by the device side after the upgrade is completed. When the consistency check between the firmware version information and the device identification information fails, the gateway side marks the log as invalid and uses it only for anomaly counting, without writing it into a risk entry.

[0040] The feature construction module is used to generate communication behavior features from operational data and network status data, and to extract the main device identifier, associated device identifier, and abnormal phenomenon description from user fault text.

[0041] User fault text from external platforms, along with user account identifiers and home network identifiers, are input into the system. The system locates the corresponding set of devices based on the user account identifier and home network identifier, and maps the devices mentioned in the text to their identifiers within that set. During the text mapping process, the system matches device nicknames, room names, brand terms, model terms, and firmware version terms, and outputs a candidate device list. When the candidate device list is unique, it outputs the main device identifier and associated device identifiers. When the candidate device list is not unique, it outputs the main device identifier as "not uniquely determined," and this text sample is only used for anomaly category statistics and does not generate risk entries.

[0042] Optionally, when the candidate device list is empty, the main device identifier is also output as not uniquely determined and the associated device identifier is set to an empty set; when the length of the candidate device list is greater than 1 and the number of matching fields in the first and second sorted orders is the same, the not uniquely determined status is maintained and the matching field hit status of the text sample is recorded. The record is stored in association with the timestamp of the text generation for subsequent result feedback and backtracking.

[0043] For example, the user account identifier is mapped from the login account on the external platform and stored locally in an irreversible hash form. The home network identifier is generated by the gateway side when the external platform account is bound for the first time and is bound to the gateway's unique identifier. The user fault text must contain at least the text content and the generation timestamp. The text generation timestamp is uniformly converted to the gateway side's system time base when entering the system. When the user account identifier or the home network identifier is missing, the user fault text only participates in the anomaly category statistics and does not participate in the mapping between the main device identifier and the associated device identifier.

[0044] Similarly, the matching process is constrained by the set of devices under the same home network identifier. First, a complete match is performed, then an inclusion match is performed and sorted by the number of matched fields. The sorting rule is an implementation parameter, with the default priority being device nickname, room name, brand name, model name, and firmware version name, which can be adjusted to prioritize any field. The maximum length of the candidate device list is an implementation parameter, with a default of 20 entries and an adjustable range of 5 to 50 entries. If the maximum length is exceeded, only the top-ranked candidate devices are retained.

[0045] The anomaly identification module is used to output conflict scores and determine conflict patterns based on communication behavior characteristics and descriptions of abnormal phenomena.

[0046] The risk knowledge base module is used to associate conflict patterns with corresponding equipment identification information to generate risk entries.

[0047] Risk entries are stored using device combinations as keys. Each device combination includes the main device identifier, associated device identifiers, and their respective firmware version information. Each risk entry includes a conflict mode identifier, a summary of the triggering conditions, a summary of the affected functions, a confidence level, the time of the most recent observation, and the number of observations. For repeated observations of the same device combination and the same conflict mode identifier, the system accumulates the observation count and updates the time of the most recent observation. For firmware version change events, the system records the version before and after the change in the risk entry and stores the change information in association with the number of observations.

[0048] In this embodiment, the device combination key is represented by an ordered pair of the main device identifier and the associated device identifier. The main device identifier is determined by text mapping or anomaly identification and maintains a stable order. The firmware version information of each device is based on the firmware version string reported by the device side. The upper limit of the string length is an implementation parameter, with a default of 32 characters and an adjustable length of 16 to 64 characters. The retention period for risk entries is an implementation parameter, with a default of 180 days and an adjustable length of 30 to 365 days. Risk entries that exceed the retention period and have not been updated in the most recent observation time are transferred to the archived state and do not participate in the retrieval of new device access.

[0049] The early warning output module is used to output early warning information containing a description of the risk scenario and mitigation suggestions when a new device is connected or the conflict score exceeds the threshold.

[0050] New device access events are triggered by gateway-side network access / binding events. When an access event occurs, the system reads the new device's identification information and retrieves risk entries related to the new device from the risk knowledge base. When a match is found, the warning output module outputs an access risk warning and writes the matched conflict mode identifier, trigger condition summary, and affected function summary into the warning. When the conflict score exceeds the threshold, the warning output module outputs an operational risk warning and writes the time range of the abnormal segment, the main device identifier, the associated device identifier, the abnormal phenomenon category, and the conflict mode identifier into the warning.

[0051] For example, the network access event is used to mark the device joining the smart home network for the first time, and the binding event is used to mark the establishment of a controllable relationship between the device and the control object on the gateway side. After the binding event is completed, the system reads the device brand, model, hardware version and firmware version as device identification information. When a new device is connected, the firmware version information cannot be read. Therefore, the system searches for risk items by brand and model and marks the firmware version not provided in the warning information. At the same time, the access event is added to the list to be completed. The risk item is accurately matched after the firmware version change event occurs.

[0052] In this embodiment, the device identification information includes at least two of the following: device brand, model, hardware version, and firmware version.

[0053] In this embodiment, the runtime data includes the application layer interaction instruction sequence, the response latency sequence corresponding to the instruction, and the device event log.

[0054] The application layer interaction command sequence is formed by arranging the interaction command type identifiers in a unified record format in chronological order; the response delay sequence is formed by arranging the response delays in a unified record format in chronological order; and the device event log is sorted by event timestamps to form an event sequence. The interaction command type identifiers are enumerated and correspond one-to-one with the protocol stack parsing results. The enumerated encoding is loaded during system initialization and maintains consistency during operation.

[0055] In this embodiment, the interactive events are arranged in chronological order using the event timestamps in the interactive event logs as the sorting key. Out-of-order arrival of interactive events is allowed. The out-of-order tolerance threshold is an implementation parameter, with a default of 200 milliseconds and an adjustable range of 50 to 2000 milliseconds. When the out-of-order exceeds the tolerance threshold, the interactive events are still written in the order of arrival and marked with an out-of-order flag in the sequence. The out-of-order flag is input into the anomaly identification module as part of the communication behavior characteristics. The response delay sequence and the device event log sequence are aligned with the same timestamp reference during construction, and the time recorded on the gateway side is used as the final alignment time.

[0056] Furthermore, the enumeration encoding table is stored with the protocol type identifier as the index and has a version number. The version number is an implementation parameter and is updated by default with firmware version change events, but can be adjusted to a fixed version without updating. When the protocol stack parsing result shows an unregistered interaction instruction type identifier, the system maps the interaction instruction type identifier to a reserved enumeration value and writes an unknown type flag in the interaction event record. The unknown type flag is included in the transition count but does not participate in the normal baseline transition matrix update.

[0057] In this embodiment, the feature construction module includes: constructing an instruction transition probability matrix based on the interaction instruction sequence, and calculating the distribution statistical features of the response delay sequence within a sliding time window.

[0058] The instruction transition probability matrix uses the interaction instruction type identifier as the state set and ordered pairs of adjacent instruction types as the statistical objects of transition events, with a preset sliding time window as the statistical period. For transition events that do not appear within the window, matrix elements are assigned values ​​according to a uniform smoothing rule to avoid zero probability. The distribution statistical characteristics of the response delay sequence are calculated within the sliding time window and output as a feature vector. The feature vector includes central tendency, dispersion, quantile characteristics, and tail characteristics. For interaction events with missing response delays, the system includes the interaction event in the timeout event count and outputs the timeout ratio feature in the feature vector. Specifically, missing response delay refers to interaction events for which the corresponding response result identifier is not recorded before the timeout threshold is reached. The timeout threshold and the aforementioned response result identifier share the same implementation parameter. The timeout ratio feature is calculated as the ratio of the timeout event count within the sliding time window to the total number of interaction events within the window, and is used together with the gateway transaction processing delay in the network status data to distinguish between device-side interaction anomalies and link-side congestion.

[0059] For example, central tendency includes the mean and median, dispersion includes the standard deviation and interquartile range, quantile characteristics include the 10th percentile and the 90th percentile, and tail characteristics include the proportion of tails exceeding the 90th percentile. To reduce the impact of extreme values, outlier truncation is performed on the response delay before it is entered into the statistics. The truncation quantile is an implementation parameter, with a default of 1% and 99%, and adjustable from 0.5% to 5% and from 95% to 99.5%. When the response delay has a negative value or an unresolvable value, the system marks the interaction event as invalid and only counts it as invalid, without participating in the calculation of distribution statistics.

[0060] In this embodiment, the smoothing process uses the Laplace smoothing coefficient as the implementation parameter, with a default value of 1.0 and an adjustable value of 0.1 to 5.0. A Laplace smoothing coefficient of 0 will result in a zero probability of no transition, making the difference unstable in extremely sparse scenarios. A value greater than 5.0 will result in excessive compression of the difference between high-frequency and low-frequency transitions and reduce the sensitivity to structural changes.

[0061] Specifically, the granularity of the state set definition is an implementation parameter. By default, the interaction instruction type identifier is used as the state. When multiple device concurrent control identifiers are detected in the same time window, the definition is switched to a joint state. The joint state is obtained by concatenating the source device identifier, the destination device identifier, and the interaction instruction type identifier. The upper limit of the state set size is an implementation parameter, with a default of 2000 and an adjustable range of 200 to 10000. When the upper limit is exceeded, low-frequency states are merged into retained low-frequency states, and the merged mapping relationship is retained for traceability.

[0062] When constructing the instruction transition probability matrix based on the interaction instruction sequence, the feature construction module discretizes the interaction instruction events into a set of states and counts the first-order transitions of adjacent states or the second-order transitions of chain dependencies within the sliding time window to form a transition count; when generating the transition probability matrix from the transition count, it performs smoothing processing on sparse transitions; and it forms a normal baseline transition matrix based on historical normal interaction samples, calculates the difference between the transition probability matrix and the normal baseline transition matrix, and uses the difference as part of the communication behavior features and inputs it into the anomaly identification module;

[0063] Furthermore, historical normal interaction samples are formed by extracting continuous time intervals. The minimum length of the continuous time interval is an implementation parameter, with a default of 30 minutes and an adjustable range of 5 to 240 minutes. If network entry / exit events, route reconstruction events, or firmware version change events occur within the continuous time interval, that time interval will not be included in the historical normal interaction samples. The update cycle of the normal baseline transition matrix is ​​consistent with the rolling update cycle. During the update, only unmarked out-of-order and unmarked unknown type interaction events are used to avoid parsing anomalies from interfering with baseline stability.

[0064] Furthermore, the sliding time window length and window step size are implementation parameters. The default window length is 60 seconds and the window step size is 5 seconds. The adjustable window length is 10 to 600 seconds and the window step size is 1 to 60 seconds. When the window step size is less than the window length, the windows overlap. The interaction events of the overlapping part repeatedly participate in the transfer count and maintain comparability in the difference calculation through row weight normalization.

[0065] When constructing the instruction transition probability matrix based on the interactive instruction sequence, the interactive instruction sequence is regarded as a discrete event stream ordered by time, so that the transition probability matrix has closed logic of state definition, window statistics-probability normalization, sparse smoothing, and baseline comparison.

[0066] In one implementation, the steps for constructing the instruction transition probability matrix are as follows:

[0067] When the first one was collected When there is a single instruction event, it is represented as:

[0068] (1)

[0069] In equation (1), Indicates the first One instruction event; This indicates the identifier of the source device for the event; Indicates the target device identifier for this event; Indicates the instruction type of the event.

[0070] Define the state mapping function based on the discretization strategy. Map events to a sequence of states:

[0071] (2)

[0072] In equation (2), Indicates the first One state; A discretized mapping function representing events to states; Represents a set of states.

[0073] The discretization strategy is set at the instruction semantic granularity as either instruction type only or a joint state of source device × destination device × instruction type, in order to cover the mutual influence in concurrent or multi-device collaborative scenarios.

[0074] In the sliding time window The number of adjacent state transitions is counted within the window, and the set of window positions is represented as follows:

[0075] (3)

[0076] In equation (3), Display window The set of covered sequence positions; Display window The starting position index; Display window The span length.

[0077] based on Calculate the first-order transition count:

[0078]

[0079] In equation (4), Display window Internal state Transition to state The count; Indicates the state index; Indicates the state index; Indicates an indicator function; Indicates the first There are several states.

[0080] To avoid the zero probability caused by sparse transitions, Laplace smoothing is used to obtain the first-order transition probability matrix:

[0081]

[0082] In equation (5), Display window Internal state to state The conditional transition probability; Represents the Laplace smoothing coefficient; Indicates the state index; This represents the cardinality of the state set. This ensures that each row satisfies the conditional distribution meaning, facilitating subsequent difference calculations with the baseline matrix.

[0083] When it is necessary to characterize the chain dependency of instruction-response-reinstruction, expand the second-order transition count and second-order transition probability within the same window:

[0084] ,

[0085] (6)

[0086] In equation (6), Display window Inner state triples The count; Indicates the state index; Indicates the first One state; Indicates that given the previous state pair Transferred under conditions The conditional probability; Indicates the state index.

[0087] To enable the anomaly detection module to obtain comparable anomaly features, historical normal interaction samples are introduced to form a normal baseline matrix. The difference between the window matrix and the baseline matrix is ​​calculated and included as part of the communication behavior characteristics. The difference is calculated using row-weighted JS divergence, with the mixture distribution for each row first defined:

[0088]

[0089] In equation (7), Represents the window matrix and baseline matrix in state Rows and columns The mixing probability; Indicates the baseline matrix from state to state The transition probability.

[0090] Redefining row-level JS divergence:

[0091]

[0092] In equation (8), Representing state JS divergence of the row; This represents the natural logarithm function.

[0093] Considering that different states occur at different frequencies within the window, the proportion of states within the window is used as the weight and summarized as the window dissimilarity:

[0094]

[0095] In equation (9), Display window Internal state Row weights; Indicates the state index; Display window Weighted JS dissimilarity relative to the baseline. This dissimilarity can be correlated with the transition matrix. Together, they serve as input anomaly identification modules for communication behavior characteristics, making conflict scoring more sensitive to changes in transfer structure rather than single, occasional commands.

[0096] The above process of constructing the instruction transition probability matrix starts with the interactive instruction sequence. Each interactive record is regarded as an instruction event containing the source device, destination device, and instruction type, and organized into an event stream in chronological order. The expression of the instruction event corresponds to equation (1). Subsequently, the instruction event is mapped to a state sequence based on the discretization strategy, so that the subsequent statistical objects are transformed from the original instruction into states in a finite set of states. The mapping relationship corresponds to equation (2). The transitions of adjacent states are counted within the sliding time window. The definition of the window position set corresponds to equation (3), and the statistics of the transition count correspond to equation (4). When constructing the transition probability from the count, the sparse transitions are smoothed and row normalized to obtain the transition probability matrix. The formation of the transition probability matrix corresponds to equation (5). When it is necessary to characterize the instruction chain dependency, the transition count and conditional transition probability are extended to a second-order form, corresponding to equation (6). To ensure that changes in this matrix can be directly used as anomaly features, a baseline transition matrix is ​​formed using historical normal interactions. The current window matrix and the baseline matrix are first mixed and distributed to construct the matrix, corresponding to equation (7). Then, the row-level difference is calculated, corresponding to equation (8). Finally, the window difference is obtained by weighting and summing the states within the window according to their frequency of occurrence, corresponding to equation (9). The output results include the window transition probability matrix and its difference relative to the baseline. These results are used as communication behavior features in the anomaly identification module to improve the sensitivity to changes in the transition structure and to serve the determination of conflict modes.

[0097] Specifically, the above implementation discretizes application-layer interaction command events into finite states, uses a sliding time window to count adjacent transitions in the state sequence, and obtains a transition matrix with conditional probability through smoothed row normalization. Smoothing reduces the zero-probability impact of sparse transitions, making subsequent difference calculations more stable. To ensure the matrix changes reflect the evolution of compatibility conflicts, a baseline matrix is ​​formed by introducing historical normal interactions, and the structural differences from the baseline are calculated at the window level. The differences are summarized using a weighted approach based on the frequency of state occurrence, making the contribution of high-frequency interaction states to the differences more consistent with the actual impact range. In concurrent or multi-device collaboration, the discretization of joint states incorporates the command coupling between devices into the state definition, thereby covering single-device and multi-device scenarios within the same statistical framework. This facilitates the input of communication behavior features into the anomaly identification module to support conflict mode determination.

[0098] In this embodiment, network status data includes at least one of network topology change events, wireless link quality indicators, and gateway transaction processing latency.

[0099] Network topology change events include device joining, device leaving, parent node change, and route reconstruction events; wireless link quality metrics include received signal strength, link quality indication, retransmission count, and channel occupancy; gateway transaction processing latency includes queuing latency and processing latency for device downlink transactions. Network status events and interaction events are timestamped to form a joint timing input for anomaly identification.

[0100] In this embodiment, the alignment uses nearest neighbor timestamp matching and sets the maximum alignment deviation as the implementation parameter, which is 1 second by default and can be adjusted from 0.1 to 5 seconds. When the deviation of the nearest neighbor timestamp matching exceeds the maximum alignment deviation, the system marks the network status sample as missing and writes the missing test mark on the corresponding interaction event. The missing test mark is input into the anomaly identification module as part of the communication behavior characteristics.

[0101] In this embodiment, the feature construction module performs named entity recognition and referential resolution on the user's fault text, and outputs the main device identifier, associated device identifier and abnormal phenomenon description. The abnormal phenomenon description includes at least the abnormal phenomenon category.

[0102] Named entity recognition (NER) annotates device names, brand names, model names, version number strings, room / area names, and functional terms in user fault text. Dereference resolution uses the same user account and the same set of devices within the same home network as constraints, merging pronouns, aliases, and device names appearing in historical conversations into the same device identifier. Anomaly categories are represented using a preset category set, including offline, command timeout, state asynchrony, linkage failure, repeated reconnection, performance degradation, and abnormal restart. Anomaly categories are output from text classification and form a structured record with the main device identifier and associated device identifiers.

[0103] Specifically, named entity recognition uses device nicknames and room names under the same home network identifier as constraint terms, and performs format normalization on the version number string in the text before participating in the matching; when multiple device names appear in the same text at the same time, the system takes the device name closest to the fault verb as the main device identifier candidate, and takes the remaining device names as associated device identifier candidates. If the candidates conflict, it remains ununique and only outputs the abnormal phenomenon category.

[0104] Furthermore, in this embodiment, the description of an anomaly is composed of an anomaly category and its corresponding trigger word fragment. The trigger word fragment is taken from the user's fault text and its length is limited to the implementation parameters, with a default of 40 characters and an adjustable length of 20 to 120 characters. The set of anomaly categories is fixed during system initialization and includes a version number. The version number is recorded synchronously with the model version number to ensure that the feedback of results between different versions is traceable.

[0105] In this embodiment, the anomaly identification module uses a sequence coding model to encode the communication behavior characteristics and calculates the conflict score in combination with the description of the anomaly. The conflict mode includes at least the triggering condition, the affected function, and the confidence level.

[0106] The sequence coding model's input consists of time-aligned communication behavior feature sequences, network state feature sequences, and anomaly category coding sequences. The model outputs a conflict score and a conflict pattern identifier. Conflict patterns are represented using structured data records, which include: trigger condition fields, symptom fields, affected function fields, associated device combination fields, and confidence fields. The trigger condition field includes the interaction instruction subsequence pattern and network state constraints; the symptom field includes the timeout ratio, offline event count, and state deviation event count; the affected function field includes the identifier of the affected service function; the associated device combination field includes the main device identifier, associated device identifiers, and their firmware version information; the confidence field is output by the model and updated with the result feedback. The conflict pattern identifier is obtained by similarity aggregation of the feature representations of anomaly fragments. During the aggregation process, anomaly fragments that meet the merging conditions are grouped into the same conflict pattern according to preset similarity judgment rules.

[0107] Optionally, similarity aggregation first performs normalization processing on the feature representation of the abnormal segments, then calculates the similarity in the range of 0 to 1 and compares it with the preset similarity judgment rule. The similarity threshold is an implementation parameter, with a default of 0.85 and an adjustable value of 0.70 to 0.95. A similarity threshold below 0.70 will lead to excessive merging of different abnormal segments and reduce the distinguishability, while a threshold above 0.95 will make it difficult to merge similar abnormal segments and increase the number of conflict pattern identifiers. When similarity aggregation generates multiple candidate conflict pattern identifiers, the conflict pattern identifier with higher confidence is used as the output and the remaining candidates are recorded as candidate mappings for result feedback correction.

[0108] The boundaries of anomalous segments are determined by the continuous time intervals where the conflict score exceeds a threshold. For each anomalous segment, the system generates an interaction instruction subsequence summary and a network state summary and writes them into the conflict pattern record. Similarity aggregation uses the same subject device identifier and the same associated device identifier as the first merging condition, and performs consistency judgment on the interaction instruction subsequence summary and symptom field when the first merging condition is met; if the consistency judgment is met, the same conflict pattern identifier is output; otherwise, a new conflict pattern identifier is output.

[0109] In this embodiment, the input sequence uses interactive events as the basic time granularity, and the upper limit of the sequence length is an implementation parameter, with a default of 256 interactive events and an adjustable range of 64 to 1024 interactive events. When the sequence length is less than the upper limit, it is padded with 0 and a padded marker is written. When the sequence length exceeds the upper limit, it is truncated according to the most recent interactive event and the truncation marker is retained. The conflict score is normalized to the range of 0 to 1 and output together with the description of the abnormal phenomenon. The normalization method is an implementation parameter, which defaults to monotonic mapping and determines the mapping parameters on the offline validation set. It can be adjusted to determine the mapping parameters only using the quantiles of historical normal interactive samples. The conflict score trigger threshold is set to the implementation parameter of 0.95 in the cold start phase and can be adjusted from 0.90 to 0.99. The cold start termination condition is to accumulate no less than 30 minutes of historical normal interactive samples.

[0110] Furthermore, short-interval breakpoints are allowed within continuous time intervals. The breakpoint merging threshold is an implementation parameter, with a default of 2 seconds and an adjustable range of 0.2 to 10 seconds. The minimum duration of abnormal segments is an implementation parameter, with a default of 5 seconds and an adjustable range of 1 to 60 seconds. Abnormal segments with durations shorter than the minimum duration do not generate new conflict mode identifiers but are only counted in the over-limit event count. The length of the interactive instruction subsequence summary is an implementation parameter, with a default of 10 interactive events and an adjustable range of 3 to 50 interactive events. When the summary is truncated, the type identifiers of the first and last interactive instructions are retained to ensure traceability.

[0111] In this embodiment, the threshold is a dynamic threshold that is adaptively updated based on the normal scoring statistical baseline formed by historical normal interaction samples. During online operation, the dynamic threshold is modified by combining the actual results recorded by the risk knowledge base module to correct the normal scoring statistical baseline. When constructing the dynamic threshold, network status data is introduced to conditionally adjust the threshold. When the warning output module triggers a warning, it uses the number of consecutive exceedances of conflict scores and the cumulative exceedances within a preset time window as counting criteria. The threshold for the cumulative exceedances is determined by the number of interaction events within the time window and a preset proportional coefficient.

[0112] Historical normal interaction samples are formed by extracting time intervals from continuously running events without offline, timeout, or abnormal restart events. The system uses the conflict score sequence within this time interval as the normal score sequence and calculates a normal score distribution summary. The dynamic threshold is obtained by updating the normal score distribution summary within a rolling update cycle, which is kept fixed by the system configuration. The determination of continuously exceeding the dynamic threshold adopts a joint rule of continuous over-limit determination and cumulative over-limit determination: continuous over-limit determination is established when the conflict score is continuously in an over-limit state; cumulative over-limit determination is established when the cumulative over-limit events reach a preset count condition within a preset statistical window; an early warning is triggered immediately upon either determination.

[0113] In this embodiment, the determination of continuous operation is based on the power-on reset event and abnormal restart event in the device event log. The interval between the boundary and without offline, timeout and abnormal restart events is included in the candidate interval. If the candidate interval contains a route reconstruction event, it is not included in the historical normal interaction sample. The update trigger of the normal score distribution summary is based on the rolling update cycle. The rolling update cycle is an implementation parameter, which is 24 hours by default and can be adjusted from 1 to 168 hours.

[0114] In one implementation, the adaptive update process of the dynamic threshold constructs a coherent link between the dynamic threshold and the offline normal baseline, online adaptive correction, network state condition adjustment, and over-limit counting criteria, making the conflict score less likely to be misjudged as a compatibility conflict in network jitter scenarios; the specific update steps are as follows:

[0115] When the set of conflict scores corresponding to historical normal interaction samples is denoted as When, use it to initialize the statistic required for the threshold:

[0116] (10)

[0117] In equation (10), This represents the average score of historical normal conflicts; This represents the variance of historical normal conflict scores; A set of conflict scores representing historical normal interaction samples; Represents a set Sample size; Represents a set A single conflict score sample.

[0118] When running online, the anomaly detection module outputs the time index as follows: Conflict rating And obtain the result feedback tags of this interaction from the risk knowledge base module. This is used to limit normal samples from entering the threshold update process.

[0119] (11)

[0120] In equation (11), Indicates the time index as The online mean; Indicates the time index as The online variance; This represents the average online index value at the previous time step. This represents the online variance of the index at the previous time step; This represents the mean update factor, ranging from 0.01 to 0.05; This represents the variance update coefficient, ranging from 0.01 to 0.05. Indicates the result feedback label, This indicates that the interaction was received as normal. This indicates that the interaction was flagged as abnormal. Indicates the time index as Conflict score; Indicates the time index.

[0121] In obtaining and Then, a basic threshold based on moving statistics is constructed, which is updated as the threshold drifts with the normal distribution:

[0122] (12)

[0123] In equation (12), Indicates the time index as Standard deviation; This represents the baseline threshold based on the mean and standard deviation; This represents the scaling factor, ranging from 2.0 to 3.5.

[0124] When the conflict score distribution is skewed or has heavy tails, parallel maintenance of quantile thresholds is used to reduce the sensitivity of the mean-variance threshold to extreme values, making Indicates the time index as Online quantile estimation:

[0125] (13)

[0126] In equation (13), This indicates online quantile estimation; This represents the online quantile estimate of the index at the previous time step; This represents the quantile update coefficient, ranging from 0.001 to 0.02; This represents the target quantile level, ranging from 0.95 to 0.995. Indicates an indicator function; This represents the quantile baseline threshold. Based on the dual-channel threshold, a more conservative combination is used to form the baseline threshold:

[0127] (14)

[0128] In equation (14), This represents the base threshold after fusion; This indicates the operation of finding the maximum value.

[0129] To distinguish network jitter from real-world compatibility conflicts, network state data is compressed into a network degradation factor, and the threshold is conditionally increased. Let... This indicates the gateway transaction processing latency metric. This represents a wireless link quality indicator, using historical normal period reference values. , Normalization yields the unbounded degradation quantity:

[0130] (15)

[0131] In equation (15), This represents the degradation of an unbounded network. This represents the degradation factor of a bounded network. This represents the weight of the gateway latency item, ranging from 0.3 to 0.7. This represents the weight of the link quality item, ranging from 0.3 to 0.7. Indicates the time index as Gateway transaction processing latency metrics; This indicates the normal reference gateway transaction processing latency metric; Indicates the time index as Wireless link quality metrics; This indicates a normal reference wireless link quality indicator. This represents an exponential function.

[0132] Furthermore, the gateway latency weight and link quality weight are implementation parameters, both defaulting to 0.5 and adjustable from 0.3 to 0.7; the network condition adjustment coefficient is an implementation parameter, defaulting to 0.3 and adjustable from 0.1 to 0.6; a gateway latency weight or link quality weight of 0 will cause the corresponding network state to fail to adjust the threshold condition, while a weight of 1 will cause another type of network state to not participate in the condition adjustment at all, thus reducing adaptability; the cumulative over-limit ratio threshold is an implementation parameter, defaulting to 0.5 and adjustable from 0.3 to 0.7. A value close to 0 will cause the cumulative over-limit criterion to be too sensitive, while a value close to 1 will cause the cumulative over-limit criterion to be too sluggish and reduce the response speed to continuous anomalies.

[0133] based on The dynamic threshold is obtained by conditionally adjusting the base threshold:

[0134] (16)

[0135] In equation (16), Indicates the time index as The dynamic threshold; This represents the network condition adjustment coefficient, ranging from 0.1 to 0.6. When... When it rises, The subsequent increase makes it more difficult for a rise in scores due to poor network conditions to directly trigger an alert.

[0136] In the condition that the number of times the conflict score continuously exceeds the dynamic threshold reaches the preset count condition, two types of criteria, namely continuous overrun and cumulative overrun, are given side by side. Let the overrun indication quantity be:

[0137] , (17)

[0138] In Equation (17), represents the overrun indication quantity at the moment index .

[0139] The continuous overrun count is updated recursively:

[0140] , (18)

[0141] In Equation (18), represents the number of continuous overruns up to the moment index ; represents the number of continuous overruns up to the previous moment index. The cumulative overrun count is statistically counted within the time window. Let the event timestamp at the moment index be , the time window be , and the window index set be:

[0142] , (19)

[0143] In Equation (19), represents the set of event indices within the window with as the end point and a span of <00​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

[0149] In equation (21), This represents the cumulative over-limit percentage threshold, ranging from 0.3 to 0.7. Indicates the number of events within the window; This represents the floor function. Therefore, in... When fixed, a higher frequency of events within the window will correspondingly increase the threshold for triggering, preventing short-term high-frequency interactions from amplifying occasional fluctuations into warnings.

[0150] The adaptive update process of the dynamic threshold starts with historical normal interaction samples and their corresponding conflict scores. An initial statistical baseline is first formed from the historical normal scores, corresponding to Equation (10). During the online operation phase, the anomaly identification module continuously outputs conflict scores, while the risk knowledge base module provides feedback on the actual results after the warning. This feedback is used to limit the range of data to be updated, and the statistical baseline is corrected online accordingly, corresponding to Equation (11). Based on the updated statistical baseline, a basic threshold is constructed. The mean and volatility-driven thresholds form Equation (12). When the score distribution is skewed or has heavy tails, the quantile threshold is maintained in parallel to reduce extreme value disturbances, corresponding to Equation (13). The two types of basic thresholds are then merged to form a more conservative basic threshold, corresponding to Equation (14). To separate network jitter from real compatibility conflicts, gateway transaction processing latency and wireless link quality in the network status data are introduced and compressed into a network degradation factor, corresponding to Equation (15). This factor is used to adjust the conditions of the basic threshold to obtain the dynamic threshold, corresponding to Equation (16). In the early warning triggering phase, an over-limit indication quantity is first generated, corresponding to equation (17). Then, the number of consecutive over-limits and the cumulative number of over-limits within the time window are maintained respectively. The continuous over-limit recursion corresponds to equation (18), the window set and count of cumulative over-limits correspond to equation (19), and the triggering criterion corresponds to equation (20). At the same time, the cumulative triggering threshold is linked by the relationship between the number of events within the window and the proportion, corresponding to equation (21). The output results include dynamic thresholds and over-limit triggering results. Based on this, the early warning output module outputs a risk scenario description and mitigation suggestions when a new device is connected or the score meets the counting conditions.

[0151] Specifically, in the above implementation, the dynamic threshold uses historical normal interaction samples as a starting point and is updated online over time, allowing the threshold to follow the slow drift changes of normal behavior. During the online update phase, result feedback is introduced, and only interaction samples that are considered normal are included in the statistical correction, preventing abnormal samples from pushing the threshold up or down. The threshold construction employs both a statistical threshold based on mean fluctuation and a threshold based on quantiles, ensuring sensitivity to abnormal increases even when the conflict score distribution is skewed or has heavy tails. Network status is used as a conditional variable in threshold adjustment; when the gateway experiences congestion or the wireless link quality deteriorates, the threshold is adjusted upwards according to the degree of network degradation, thus separating score fluctuations caused by network jitter from genuine compatibility conflicts. Early warning triggering uses both continuous and cumulative over-limit counting rules, linking the time window with the number of triggers, so that the trigger threshold changes synchronously with changes in interaction frequency, reducing false triggers caused by short-term high-frequency interactions while retaining the ability to respond to persistent conflicts.

[0152] In this embodiment, mitigation suggestions include at least one of the following: adjusting device logical groups, adjusting the gateway's polling and retry parameters for the target device, switching the wireless channel, or suggesting that firmware upgrades for specific devices be postponed.

[0153] Mitigation recommendations are generated driven by the trigger condition summary and symptom fields in the risk entries. When the trigger condition summary includes a multi-device concurrency control identifier, the system outputs a recommendation to adjust the logical grouping of devices, including a list of target devices and grouping rule identifiers. When the symptom field includes an increase in timeout rate and gateway transaction processing latency, the system outputs a recommendation to adjust the gateway polling and retry configuration, including target device identifiers and configuration item identifiers. When the network status summary includes an increase in channel occupancy or a decrease in link quality, the system outputs a recommendation to switch wireless channels, including the current channel identifier and the target channel selection rule identifier. When a risk entry includes a firmware version change and an increase in the number of observations after the change, the system outputs a recommendation to postpone firmware upgrades for specific devices, including the device identifiers and firmware version information involved.

[0154] Specifically, device logical groups are represented by group identifiers maintained on the gateway side. Devices within the same group share the same control queue and can be referenced by linkage rules. Polling and retry parameters include polling period, number of retries, and retry interval. The polling period is an implementation parameter, with a default of 5 seconds and an adjustable range of 1 to 60 seconds. The number of retries is an implementation parameter, with a default of 2 times and an adjustable range of 1 to 5 times. The retry interval is an implementation parameter, with a default of 200 milliseconds and an adjustable range of 50 to 2000 milliseconds. The execution of switching wireless channels is based on the target channel selection rule identifier, which in this embodiment corresponds to the channel with the lowest channel occupancy in the past minute. The postponement period for firmware upgrades on specific devices is an implementation parameter, with a default of 7 days and an adjustable range of 1 to 30 days. During the postponement period, firmware version change events are still recorded but do not trigger automatic upgrade actions. Example 2:

[0155] Based on Example 1, in this example, the risk knowledge base module records the actual result feedback after the warning, and uses the result feedback to update the model parameters or dynamic threshold of the anomaly identification module.

[0156] Actual result feedback is generated by the following events: user confirmation that the fault has disappeared, the absence of the same conflict mode identifier within the preset observation window, work order closure, equipment returning to online status and synchronizing status, and recurrence of the fault. For the same risk item, the system writes the actual result feedback into the result field of the risk item and updates the confidence level. Model parameter updates are triggered after accumulating result feedback consistent with the conflict mode identifier. The update process records the model version number and stores both the pre-update and post-update models. Dynamic threshold updates are triggered when the normal scoring sequence rolling update cycle arrives. The update process records the threshold version number and stores both the pre-update and post-update thresholds. When the count of false alarm events within the preset observation window reaches the rollback condition after an update, the system rolls back the model version number or threshold version number to the previous version.

[0157] Furthermore, the user confirmation that the fault has disappeared is generated by the external platform's confirmation operation of the warning information and associated with the user's account identifier; the event that the same conflict mode identifier does not reappear within the preset observation window is obtained by the gateway side by retrieving the most recent observation time according to the conflict mode identifier. The preset observation window is an implementation parameter, with a default of 7 days and an adjustable range of 1 to 30 days; a false alarm event is defined as an event where the actual result feedback corresponding to the warning output is marked as normal. The false alarm event count threshold in the rollback condition is an implementation parameter, with a default of 5 times and an adjustable range of 1 to 50 times; the cumulative number of results collected to trigger the model parameter update is an implementation parameter, with a default of 20 result feedbacks and an adjustable range of 5 to 200 result feedbacks. After triggering, the model version number is incremented and a traceable index of the model before and after the update is retained; the threshold version number is recorded independently from the model version number. The threshold version number is incremented and a traceable index of the threshold before and after the update is retained to support rolling back the model version number or threshold version number to the previous version when the rollback condition is met.

[0158] Finally, it should be noted that 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. Such 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.

[0159] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A compatibility verification system for home appliance components based on multi-source data, characterized in that, include: The data acquisition and aggregation module is used to collect device identification information and operating data from accessory devices to be connected, existing smart home appliances and their gateways, collect network status data of the smart home network, and obtain user fault text from external platforms. The feature construction module is used to generate communication behavior features from the running data and network status data, and extract the main device identifier, associated device identifier and abnormal phenomenon description from the user fault text. Anomaly identification module is used to output a conflict score and determine the conflict mode based on the communication behavior characteristics and the description of the abnormal phenomenon; The risk knowledge base module is used to associate the conflict patterns with the corresponding device identification information to generate risk entries; The early warning output module is used to output early warning information containing a risk scenario description and mitigation suggestions when a new device is connected or the conflict score exceeds a threshold.

2. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The device identification information includes at least two of the following: device brand, model, hardware version, and firmware version.

3. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The operational data includes an application layer interaction command sequence, a response latency sequence corresponding to the command, and a device event log.

4. The appliance component compatibility verification system based on multi-source data according to claim 3, characterized in that, The feature construction module includes: constructing an instruction transition probability matrix based on the interaction instruction sequence, and calculating the distribution statistical features of the response delay sequence within a sliding time window; When constructing the instruction transition probability matrix based on the interaction instruction sequence, the feature construction module discretizes the interaction instruction events into a set of states and counts the first-order transitions or chain-dependent second-order transitions of adjacent states within a sliding time window; it performs smoothing processing on sparse transitions when generating the transition probability matrix from the transition count; and it forms a normal baseline transition matrix based on historical normal interaction samples, calculates the difference between the transition probability matrix and the normal baseline transition matrix, and uses the difference as part of the communication behavior feature and inputs it into the anomaly identification module.

5. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The network status data includes at least one of network topology change events, wireless link quality indicators, and gateway transaction processing latency.

6. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The feature construction module performs named entity recognition and referential resolution on the user fault text, and outputs the main device identifier, associated device identifier and abnormal phenomenon description, wherein the abnormal phenomenon description includes at least the abnormal phenomenon category.

7. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The anomaly identification module uses a sequence coding model to encode the communication behavior features and calculates the conflict score in combination with the description of the anomaly phenomenon. The conflict mode includes at least the triggering condition, the influencing function, and the confidence level.

8. The appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The threshold is a dynamic threshold that is adaptively updated based on the normal scoring statistical baseline formed by historical normal interaction samples. During online operation, the dynamic threshold is modified by combining the actual results recorded by the risk knowledge base module to correct the normal scoring statistical baseline. When constructing the dynamic threshold, the network state data is introduced to conditionally adjust the threshold. When the warning output module triggers a warning, it uses both the number of consecutive exceedances of the conflict score and the cumulative exceedances within a preset time window as counting criteria. The threshold for the cumulative exceedances is determined by the number of interactive events within the time window and a preset ratio coefficient.

9. A home appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The mitigation recommendations include at least one of the following: adjusting device logical grouping, adjusting gateway polling and retry parameters for the target device, switching the wireless channel, or suggesting a temporary halt to firmware upgrades for the specific device.

10. A home appliance component compatibility verification system based on multi-source data according to claim 1, characterized in that, The risk knowledge base module records the actual feedback results after the warning, and uses the feedback results to update the model parameters of the anomaly identification module.

Images