Multi-protocol compatibility control method for smart home energy routers

Abstract

This invention discloses a multi-protocol compatible control method for smart home energy routers, relating to the field of Internet of Things (IoT) technology. The method includes: S1, acquiring the status information of multi-protocol devices, decomposing data packets of protocols such as Wi-Fi and Zigbee using a preset protocol parsing module, extracting device status fields, and obtaining a standardized status dataset; S2, using a semantic mapping algorithm on the standardized status dataset to map fields from different protocols to a unified data model, obtaining a cross-protocol integrated information set; and S3, obtaining the device's functional description fields from the cross-protocol integrated information set, performing semantic analysis through a pre-trained functional parsing model, and obtaining a device functional tag set. This multi-protocol compatible control method for smart home energy routers significantly improves the compatibility and management efficiency of multi-protocol devices, realizing intelligent and dynamic device control and status updates.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to a multi-protocol compatible control method for smart home energy routers. Background Technology

[0002] The field of intelligent device management occupies a core position in the rapid development of the Internet of Things. Its importance lies in achieving efficient collaboration of devices and optimizing user experience through unified management, providing key support for scenarios such as smart homes and industrial automation.

[0003] However, existing solutions have significant limitations when handling multi-protocol device information. They generally rely on customized adaptations for specific protocols, making it difficult to achieve universal querying and control across protocols, resulting in complex and inefficient device management. Furthermore, device function identification and classification often depend on manually preset rules, lacking dynamic adaptability and failing to cope with the diversity of device functions and changing scenarios. The core challenge stems from the unified retrieval of device information across protocols and the intelligent identification of device functions. First, the heterogeneity of device status information under different protocols makes unified querying difficult. For example, in smart homes, Wi-Fi bulbs and Zigbee sensors have significantly different data formats and communication mechanisms, requiring intermediate layer conversion and mapping, increasing system complexity and latency. Second, the intelligent identification and classification of device functions is limited by the lack of a universal function parsing framework, preventing automatic categorization of device functions. For example, a smart light supporting dimming and color temperature adjustment may be incorrectly identified as a single-function device due to protocol differences, affecting users' ability to achieve precise control through a unified interface. These two factors are interconnected: the ineffective integration of heterogeneous information limits the accuracy of function identification; and the inadequacy of function identification further hinders the realization of a unified management interface. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-protocol compatible control method for smart home energy routers, design a cross-protocol device information retrieval engine to achieve unified query of status information, and provide users with a unified device management interface and control experience through intelligent identification and classification technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a multi-protocol compatible control method for a smart home energy router, the method comprising:

[0006] S1. Obtain the status information of multi-protocol devices, decompose data packets of protocols such as Wi-Fi and Zigbee through the preset protocol parsing module, extract device status fields, and obtain a standardized status dataset;

[0007] S2. For the standardized state dataset, a semantic mapping algorithm is used to map fields from different protocols to a unified data model, resulting in a cross-protocol integrated information set.

[0008] S3. Obtain the device's functional description field from the cross-protocol integrated information set, perform semantic analysis through a pre-trained functional parsing model, and obtain the device functional tag set;

[0009] S4. For the set of device function tags, use a clustering algorithm to automatically classify the functions, generate a device function classification table, and determine the function affiliation of the device.

[0010] S5. Obtain the device function classification table, and construct the display components of the unified management interface through the dynamic template generation algorithm to obtain the interface presentation dataset;

[0011] S6. Extract user control commands from the dataset presented on the interface, combine them with the device function classification table, and generate control commands for the corresponding protocols through the protocol conversion module to obtain the device control command set.

[0012] Preferably, S1 includes:

[0013] The system acquires data packets transmitted by multi-protocol devices via Wi-Fi and Zigbee protocols, performs initial decomposition using a preset protocol parsing module, and obtains protocol-specific data units.

[0014] For a specific data unit of the protocol, if the Wi-Fi protocol data packet contains a complete status field, the status information is extracted through the field mapping table;

[0015] If the Zigbee protocol data packet contains compressed status fields, then a decompression algorithm is used to restore the status information and obtain the original set of status fields;

[0016] By using preset field mapping rules, the original set of state fields is formatted and converted to generate state data records in a unified format.

[0017] A data verification algorithm is used to verify the integrity of status data records in a uniform format. If a record is missing a key field, it is marked as invalid data.

[0018] If the record is complete, the valid status data is output. Based on the valid status data, combined with the device identifier and timestamp, a standardized status dataset is generated and stored in the distributed database.

[0019] A standardized state dataset is obtained through a distributed database query interface. The device states are then grouped using the K-means clustering algorithm to obtain the device state classification results.

[0020] Based on the equipment status classification results, a status update log is generated, stored in the log management system, and status change trend data is output.

[0021] Preferably, S2 includes:

[0022] Obtain the protocol identifier and data structure information from the standardized state dataset. Parse the JSON format data of the Wi-Fi protocol and the binary data of the Zigbee protocol through the protocol identifier. If the device type identifier is included, extract the attribute descriptor to obtain the protocol-specific field description set.

[0023] Based on the set of field descriptions, a semantic parser is used to perform lexical analysis. The meaning of the fields is matched with a preset semantic dictionary. If the Wi-Fi protocol field is temperature, it is mapped to the temperature attribute of the unified data model to obtain a semantically standardized field mapping table.

[0024] The data values ​​of different protocols are converted by a field mapping table, and the data type differences are handled by a numerical conversion algorithm. If the Zigbee protocol data is in hexadecimal, it is converted to decimal to obtain attribute data records with a uniform format.

[0025] Based on attribute data records, information from the same device is merged by a data fusion processor. If there are conflicts between multi-protocol data, they are integrated according to timestamp priority to generate a cross-protocol integrated information set.

[0026] Preferably, S3 includes:

[0027] Obtain the device function description field from the cross-protocol integrated information set, parse the field content through a preset field extractor, and if the field contains a device type identifier, classify it according to the protocol identifier field to obtain a classified set of device function descriptions.

[0028] Based on the categorized set of device function descriptions, the field content is processed using a semantic dictionary matching method. If the field content matches the preset semantic dictionary, the matching semantic tags are extracted to obtain a preliminary set of semantic tags.

[0029] Tag data is obtained from the initial semantic tag set, and semantic classification is performed using the support vector machine algorithm. If the confidence of a tag is higher than a preset threshold, it is assigned to the corresponding functional category, resulting in a classified functional tag set.

[0030] Based on the categorized set of functional tags, a data fusion processor is used to associate data fusion records. If there is multi-protocol data of the same device in the records, the tags are integrated according to the timestamp priority to obtain the final set of device functional tags.

[0031] Preferably, S4 includes:

[0032] The function description field is obtained from the device function tag set. The field content is extracted through the preset field parser. If the field content contains a protocol identifier, it is grouped according to the protocol identifier to obtain a grouped set of function descriptions.

[0033] For the grouped set of function descriptions, the K-means clustering algorithm is used to cluster the function description fields. If the intra-cluster similarity of the clustering results is higher than the preset classification threshold, a preliminary function classification table is generated.

[0034] Based on the preliminary functional classification table, semantic tag data is extracted, and multi-protocol data is associated through the data fusion processor. If there are records of the same device in the multi-protocol data, the tags are integrated according to the timestamp priority to obtain the fused functional classification table.

[0035] For the merged function classification table, the tag association data is obtained and processed according to the preset attribution determination rules. If the tag association meets the preset threshold, the function attribution of the device is determined and the device function classification table is generated.

[0036] Preferably, S5 includes:

[0037] Obtain functional classification data from the device functional classification table, extract the classification label field through the preset template parser, and if the classification label field contains the device identifier, group the devices according to the device identifier to obtain the grouped classification label set.

[0038] For the grouped set of category labels, a dynamic template generation algorithm is used to generate template configuration data. The category labels and interface layout are associated through preset template mapping rules to obtain the template configuration dataset.

[0039] Based on the template configuration dataset, display components are generated through the component rendering processor. If the component rendering result meets the preset interface layout threshold, the set of display components for the unified interface is determined.

[0040] For the set of display components, obtain the interface presentation data, and integrate the component rendering data and function classification data through a data fusion processor to obtain the interface presentation dataset.

[0041] Preferably, S6 includes:

[0042] The user control commands are obtained from the interface presentation dataset. The operation type and device identifier in the user control commands are extracted by the command parser to obtain the parsed command dataset.

[0043] Based on the parsed instruction dataset, the corresponding function tags and device identifiers are obtained from the device function classification table. The operation type and function tags are then integrated by the data fusion processor to obtain the fused instruction function dataset.

[0044] For the fused instruction function dataset, the protocol conversion module generates corresponding control commands according to the preset protocol format to obtain a set of device control commands;

[0045] If the commands in the device control command set meet the preset protocol format threshold, the command verification processor confirms the validity of the commands and obtains the final device control instruction set.

[0046] Preferably, it also includes S7, which distributes the device control command set to the target device through the communication scheduling module, obtains the device response status, updates the standardized status dataset, and obtains real-time status feedback, specifically as follows:

[0047] The instruction distribution task is obtained from the device control instruction set, and the distribution channel is matched according to the device identifier through the communication scheduling module to generate the channel allocation instruction set;

[0048] Based on the channel allocation instruction set, the device control instruction set is distributed to the target device through the communication scheduling module, and the response status of the target device is collected to obtain the device status dataset.

[0049] If the device status dataset conforms to the preset data format, the device status dataset is encoded by the status normalization processor to generate a standardized status dataset.

[0050] For the standardized status dataset, the status update module generates real-time status feedback according to the feedback timeliness requirements, thus obtaining the device status feedback set.

[0051] Preferably, it also includes S8: extracting abnormal state information from real-time status feedback; if a function recognition error is detected, updating the function analysis model through an incremental learning algorithm to obtain optimized model parameters, specifically:

[0052] The feedback data stream is obtained from the real-time status feedback. The feedback data stream is parsed by the status analysis module to extract the data subset containing the status anomaly identifier, and the abnormal status dataset is obtained.

[0053] If the abnormal state dataset contains error classification labels, the abnormal state dataset is classified according to the preset error correction rules to generate a functional identification error set.

[0054] Preferably, S8 further includes:

[0055] Based on the functional identification error set, the incremental learning algorithm is used to iteratively train the error classification labels, calculate and update the weights and biases, and obtain the optimized model parameter set;

[0056] By optimizing the parameter set update function of the parsing model, the parameter configuration of the parsing model is parsed, and an updated parsing model is generated, thus completing the model parameter update.

[0057] As can be seen from the above technical solution, the present invention has the following beneficial effects:

[0058] This invention presents a multi-protocol compatible control method for smart home energy routers. Addressing the complexity of acquiring and controlling status information for multi-protocol devices, it employs a series of technical means to achieve cross-protocol data integration and dynamic interface management. First, a protocol parsing module decomposes data packets from protocols such as Wi-Fi and Zigbee, extracting device status fields to form a standardized status dataset. Then, a semantic mapping algorithm maps different protocol fields to a unified data model, generating a cross-protocol information set. Subsequently, a pre-trained functional parsing model performs semantic analysis on device function descriptions, and a clustering algorithm generates a device function classification table to clarify function attribution. This invention uses a dynamic template generation algorithm to construct a unified management interface and generates control commands through a protocol conversion module, distributing them to target devices for real-time status feedback. For abnormal states, an incremental learning algorithm optimizes the functional parsing model to ensure system adaptability. This invention significantly improves the compatibility and management efficiency of multi-protocol devices, achieving intelligent and dynamic device control and status updates. Attached Figure Description

[0059] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] like Figure 1 As shown, the present invention provides a technical solution: a multi-protocol compatible control method for a smart home energy router, the method comprising:

[0062] S1. Obtain the status information of multi-protocol devices, decompose data packets of protocols such as Wi-Fi and Zigbee through the preset protocol parsing module, extract device status fields, and obtain a standardized status dataset;

[0063] S2. For the standardized state dataset, a semantic mapping algorithm is used to map fields from different protocols to a unified data model, resulting in a cross-protocol integrated information set.

[0064] S3. Obtain the device's functional description field from the cross-protocol integrated information set, perform semantic analysis through a pre-trained functional parsing model, and obtain the device functional tag set;

[0065] S4. For the set of device function tags, use a clustering algorithm to automatically classify the functions, generate a device function classification table, and determine the function affiliation of the device.

[0066] S5. Obtain the device function classification table, and construct the display components of the unified management interface through the dynamic template generation algorithm to obtain the interface presentation dataset;

[0067] S6. Extract user control commands from the dataset presented on the interface, combine them with the device function classification table, and generate control commands for the corresponding protocols through the protocol conversion module to obtain the device control command set.

[0068] This method uses a smart home energy router as its core, leveraging its embedded multi-protocol access and parsing module to achieve seamless management of various types of smart terminals in the home environment. First, upon receiving communication data from the devices, the system selects the corresponding parser based on the protocol type (e.g., Wi-Fi, Zigbee) and extracts universally meaningful status data. Then, a semantic mapping algorithm eliminates field differences, establishing a cross-protocol consistent data model. At the functional level, the system further analyzes device function descriptions using natural language processing technology, extracts function tags, and categorizes them into function categories using clustering algorithms, thus constructing a unified functional view. At the management interface layer, a dynamic component generation mechanism dynamically binds function categories to UI controls, adapting the interface to various device control needs. Finally, control intentions generated through user interaction are processed by the protocol conversion module into commands in the target protocol format, achieving a unified control entry point and protocol output matching for precise control of multi-protocol devices.

[0069] S1 includes acquiring data packets transmitted by multi-protocol devices via Wi-Fi and Zigbee protocols, performing initial decomposition using a preset protocol parsing module to obtain protocol-specific data units; for each protocol-specific data unit, if the Wi-Fi protocol data packet contains complete status fields, extracting status information through a field mapping table; if the Zigbee protocol data packet contains compressed status fields, using a decompression algorithm to restore the status information to obtain the original status field set; converting the format of the original status field set using preset field mapping rules to generate a unified format status data record; using a data verification algorithm to verify the integrity of the unified format status data record, marking it as invalid data if a record is missing key fields; if the record is complete, outputting valid status data; based on the valid status data, combined with device identifiers and timestamps, generating a standardized status dataset and storing it in a distributed database; obtaining the standardized status dataset through a distributed database query interface, grouping device states using a K-means clustering algorithm to obtain device status classification results; generating a status update log based on the device status classification results, storing it in a log management system, and outputting status change trend data.

[0070] In this embodiment, the smart home energy router first receives data packets from multiple devices, which are transmitted via Wi-Fi and Zigbee protocols respectively. The system's built-in protocol parsing module selects the appropriate parsing process based on the protocol type of the received data packets. For Wi-Fi protocol data packets, the system parses the data structure using a preset protocol format specification document, extracting complete status fields such as device on / off status, power level, and running time. During parsing, field names and content are compared and extracted using a field mapping table. This mapping table is established item by item by technical personnel during the product development phase based on the communication protocol field specifications of various manufacturers' devices. Field matching uses key-value pairs, and each Wi-Fi field has a clearly corresponding standard field name, without ambiguity or omissions. For Zigbee protocol data packets, if the data packet is determined to have field compression after preliminary parsing, i.e., the field content appears in compressed encoding form (e.g., abbreviations, bit field combinations, etc.), the system uses a preset decompression algorithm for processing. This decompression algorithm is based on the Zigbee protocol specification, restoring the compressed fields to the original set of status fields. The specific decompression process includes bitwise rearrangement of fields and replacement of field values. For example, the binary value combination "0110" is restored to two fields: "Device status is on, operating mode is automatic". The restored fields are stored in a temporary structure as the original status field set.

[0071] After extracting the Wi-Fi and Zigbee fields, the system converts these raw fields into status data records in a unified format according to field standardization rules. This process includes field renaming (e.g., unifying "on / off status" to "running status"), unit conversion (e.g., converting temperature from Fahrenheit to Celsius), and structure adjustment (e.g., converting from a list to a key-value pair format). All conversion rules are pre-defined by the engineering team and fixed in the mapping configuration table, and cannot be modified at runtime.

[0072] After the status data records are generated, the system uses a built-in data verification algorithm to verify the integrity of each record. Specifically, this involves checking each key field in the record for null or outlier values. Key fields are defined as fields that, if missing, would affect control decisions. If any field is missing, the entire record is marked as invalid data and written to the error log; if the field is complete, the record is marked as valid status data.

[0073] The system further generates a standardized status dataset based on the device identifier and collection timestamp fields in each valid status data entry. This dataset is structured data with the device identifier as the primary key and sorted by timestamp. This dataset is written to a distributed database deployed within the system via the local network. Before each data entry is written, a duplicate check is performed; if a duplicate primary key is found, the data is overwritten to ensure the status data remains up-to-date.

[0074] Next, the system retrieves the complete status dataset for a recent period (e.g., within 24 hours) through a distributed database query interface and aggregates it by device. For the status history of each device, the system calls the K-means clustering algorithm to group the statuses. The calculation process of this clustering algorithm includes: first, extracting target fields as input vectors from the status data of the device over the past 24 hours, such as operating status, power level, temperature and humidity values, forming a sequence of status vectors of consistent length. The system sets the number of clusters to 3, indicating that the statuses are divided into three categories: low frequency, medium frequency, and high frequency. The initial cluster centers are set using the first 3 data points as references. Then, the distance between all data points and the cluster centers is calculated using Euclidean distance, and each data point is assigned to the category represented by the nearest center. The center points are updated, and the above process is repeated until the iteration stops.

[0075] After clustering, the system generates a status classification result for the device based on features such as the number of state samples, frequency of change, and time period of occurrence for each category. This result is then attached as a status label to the device information for use by upper-level modules. Next, the system organizes the device status change behavior according to the clustering classification results and time series, forming a status update log. Each log entry contains information such as device identifier, status category, change time, and duration. The logs are stored in a structured format in the log management system for subsequent querying and analysis.

[0076] Finally, the system generates status change trend data based on the status change records in the log management system. This trend data is generated by analyzing the frequency and periodicity of status changes in the logs, such as the number of times a device switches on and off within 24 hours and its longest continuous running time. The trend data is updated daily and written to the data interface used by the visualization module, allowing users to view device behavior trends. Parameters throughout the process, such as the number of clusters, time period length, and types of validation fields, are explicitly set during the system development phase and are not changed during runtime. The number of clusters is selected as 3 based on engineering experience and actual test results. The time period is 24 hours. Validation fields include device ID, timestamp, and running status; data that does not meet any of these criteria is considered invalid.

[0077] S2 includes acquiring protocol identifiers and data structure information from a standardized state dataset; parsing JSON-formatted data of the Wi-Fi protocol and binary data of the Zigbee protocol using a protocol recognizer; extracting attribute descriptors if device type identifiers are included to obtain a protocol-specific field description set; performing lexical analysis using a semantic parser based on the field description set, matching field meanings using a pre-defined semantic dictionary; mapping a Wi-Fi protocol field to temperature to a temperature attribute in a unified data model to obtain a semantically standardized field mapping table; converting data values ​​from different protocols using the field mapping table, employing numerical conversion algorithms to handle data type differences; converting Zigbee protocol data from hexadecimal to decimal to obtain uniformly formatted attribute data records; and merging information from the same device using a data fusion processor based on the attribute data records. If conflicts exist between multi-protocol data, they are integrated according to timestamp priority to generate a cross-protocol integrated information set.

[0078] In this embodiment, regarding step S2, the smart home energy router, having already constructed a standardized status dataset, first sequentially reads the protocol identifier field and data structure information field from each data record in the dataset. The protocol identifier field is an identifier value automatically appended by the system when writing status data; its value is fixed as "wifi" or "zigbee," and the system determines the data source protocol type based on this field. The data structure information field is a standardized field format record, including the number of fields, a list of field names, a list of field types, etc., used to assist in parsing the structure content. The protocol identifier first reads the protocol identifier. If the value is "wifi," it calls the Wi-Fi protocol parsing module to read the JSON format structure, parsing it field by field using key-value pairs. If the protocol identifier is "zigbee," it calls the Zigbee protocol parsing module to read the binary bitstream format data packet, disassembling it into field segments according to bit offset and length definition. During the extraction process, if the data packet contains a "device type identifier", the system searches for the field according to the field matching rules. For example, the "device_type" field in the Wi-Fi protocol and the first 8 bits of the field segment in the Zigbee protocol are device type codes. After extracting the field value, the system calls the attribute definition table to find the corresponding attribute descriptor. The descriptor includes the field name, field unit, value range, etc., forming a "protocol-specific field description set".

[0079] After obtaining the set of field descriptions, the system passes the set to the semantic parser for semantic standardization. The semantic parser reads each field name in the set and calls the built-in semantic dictionary to match the field meaning. The dictionary predefines the correspondence between common protocol fields and standard attributes. For example, the Wi-Fi field "temp_current" is defined as "current temperature," and the Zigbee field "0x1A" is "power." The parser performs word splitting on the field names, for example, splitting "temp_current" into "temp" and "current." The stemming module identifies "temp" as a temperature-related morpheme, and after searching in the semantic dictionary, it determines that the field should be mapped to the "temperature" attribute of the unified data model. The dictionary matching uses a hash matching method, and the dictionary entries are automatically expanded through system test data and manually reviewed and confirmed. If the field is a Zigbee binary field, the parser identifies its semantics based on the field bitmap description table. For example, "0x1A" is mapped to "power." After all matching is completed, a "semantic standardization field mapping table" is formed. Each mapping record contains the original field name, standard field name, unit, and field type.

[0080] Next, the field mapping table is input into the data conversion module, which performs data type and unit conversion operations for each field. First, the system determines the original value type of the field, for example, whether it is hexadecimal. If the field value is "0x1A", the system calls the hexadecimal conversion module to convert the value to decimal "26". If the field unit is "Fahrenheit", such as the value "77", the system performs unit conversion according to preset rules: first, "77" is subtracted from "32", resulting in "45", then multiplied by "5" to get "225", and finally divided by "9" to get "25", meaning the standard temperature value is "25 degrees Celsius". All field values ​​are converted to decimal floating-point numbers, retaining two decimal places. The converted fields are written to the "attribute data record", including the field name, value, unit, protocol source, and timestamp.

[0081] Next, the system calls the data fusion processor to perform cross-protocol information merging on the attribute data records. First, the system groups all data records by device identifier field, with each group representing a specific device. For each device, the system searches for multiple values ​​of the same attribute in each group. If the values ​​come from different protocol sources, the system compares the timestamps of each value. The timestamp value is in the standard format "year-month-day hour:minute:second," and the data with the newer time is considered the currently valid data and is retained first. For example, in the power field of a device "Socket A," there are two values: "zigbee source 26" with the time "2025-07-30 14:00:00" and "wifi source 28" with the time "2025-07-30 14:05:00." The system selects the wifi source with the value "28" as the final value. After all fields are merged, they are written into the cross-protocol integration information set, the structure of which includes device ID, each standard attribute, attribute value, unit, timestamp, and protocol source. There is no fuzzy merging logic in the entire fusion process; all conflict handling priorities are determined by the order of timestamps, with newer timestamps having higher priority. The processor does not set any automatic threshold judgment, but directly executes a clear time sorting selection strategy to ensure data accuracy and standardization, and finally completes the generation of cross-protocol information sets and submits them to the unified control logic processing module.

[0082] S3 includes obtaining the device function description field from the cross-protocol integrated information set, parsing the field content through a preset field extractor, and classifying the field according to the protocol identifier field if the field contains a device type identifier, thereby obtaining a classified set of device function descriptions.

[0083] Based on the categorized set of device function descriptions, the field content is processed using a semantic dictionary matching method. If the field content matches the preset semantic dictionary, the matching semantic tags are extracted to obtain a preliminary set of semantic tags.

[0084] Tag data is obtained from the initial semantic tag set, and semantic classification is performed using the support vector machine algorithm. If the confidence of a tag is higher than a preset threshold, it is assigned to the corresponding functional category, resulting in a classified functional tag set.

[0085] Based on the categorized set of functional tags, a data fusion processor is used to associate data fusion records. If there is multi-protocol data of the same device in the records, the tags are integrated according to the timestamp priority to obtain the final set of device functional tags.

[0086] In this embodiment, the system first obtains the cross-protocol integration information set generated in step S2 in step S3. Each record in this set contains device identifier, protocol source, function description field, attribute value, timestamp, etc. The system reads the device function description field sequentially according to the record order. The content of this field is generally a string structure representing the device's functional attributes, such as "mode_auto" or "function_switch". The system calls the field extractor to analyze whether the field content contains a device type identifier, such as whether it contains keywords such as "device_type" or "dev_class". The field extractor searches according to keyword rules. If a keyword is found, the device type is recorded, and it is classified in combination with the protocol identifier field in the current record. The protocol identifier field is an identifier field added in the previous step, and its value is "wifi" or "zigbee". The system classifies the corresponding record into the Wi-Fi or Zigbee device set according to this field, forming a "classified device function description set". This set is stored according to device type and protocol source for easy semantic processing.

[0087] After classification, the system reads each function description field after classification and calls the semantic dictionary matching module for semantic parsing. The dictionary is a built-in function tag database containing commonly used function fields and their corresponding standard tags, such as "switch_on" corresponding to "enabled function" and "mode_auto" corresponding to "automatic mode". The semantic matching process is as follows: the original field is split into basic words using underscore or camelCase format, for example, "function_switch" is split into "function" and "switch", and then these two words are matched one by one in the dictionary. If a match is successful, the corresponding tag is extracted. The matching uses a hash table retrieval method, and the matching rule is complete match. The system collects the successfully matched tags into a "preliminary semantic tag set", where each tag record includes tag text, source field, device type, protocol type, and timestamp.

[0088] Based on the initial semantic label set, the system calls the Support Vector Machine (SVM) algorithm for semantic classification. The SVM model is a multi-class classification model; its input is label word vectors, and its output is the corresponding function category and classification confidence. The word vector construction method is as follows: the label string is mapped to an integer sequence according to the dictionary index, and then represented using a fixed-length vector structure, such as converting each label into a 10-dimensional vector, with vector elements being dictionary numbers. The input vector is fed into the trained SVM classification model, which returns a category number and a floating-point value representing the classification confidence. The confidence is the support probability value output by the classification model, ranging from 0 to 1. The system sets the confidence threshold to 0.85, which is the critical value determined during model training through cross-validation under the condition that the accuracy exceeds 90%. If the confidence of a label is higher than 0.85, it is classified into that category, and the classification result is recorded; if it is lower than this value, the label is judged as unclassifiable and excluded from the final classification result. The classification result forms a "classified function label set," containing each label, function category, classification confidence, and source field information.

[0089] Finally, the system performs a fusion process on the functional tag set. Using the "device unique identifier" field as an index, the system groups tag data for the same device from different protocol sources, with each group representing all protocol tags for that device. The system sorts by the timestamp field, selecting records with larger timestamp values ​​as the priority data source. For example, if a device has two tag records, one from the Wi-Fi protocol and the other from the Zigbee protocol, with timestamps of 1685000000 and 1684000000 respectively, the system selects the Wi-Fi tag with timestamp 1685000000 as the main tag and merges the unique Zigbee tags. The merging method is: check if the tag string exists in the main tag list; if not, append it. After fusion, the final "device functional tag set" is obtained, which provides input for subsequent function classification and control command generation. This processing method ensures the consistency of functional semantics and the optimal selection of data between protocols, ensuring that the system's identification of device functions is accurate, clear, and reproducible.

[0090] S4 includes obtaining the function description field from the device function tag set, extracting the field content through a preset field parser, and if the field content contains a protocol identifier, grouping it according to the protocol identifier to obtain a grouped set of function descriptions.

[0091] For the grouped set of function descriptions, the K-means clustering algorithm is used to cluster the function description fields. If the intra-cluster similarity of the clustering results is higher than the preset classification threshold, a preliminary function classification table is generated.

[0092] Based on the preliminary functional classification table, semantic tag data is extracted, and multi-protocol data is associated through the data fusion processor. If there are records of the same device in the multi-protocol data, the tags are integrated according to the timestamp priority to obtain the fused functional classification table.

[0093] For the merged function classification table, the tag association data is obtained and processed according to the preset attribution determination rules. If the tag association meets the preset threshold, the function attribution of the device is determined and the device function classification table is generated.

[0094] During step S4, the system first reads each tag record from the device function tag set generated in the previous stage and parses the function description field. The function description field is generally stored as a structured string, representing the specific function of the device, such as "timed control" or "automatic heating." The system calls the field parser module to parse this field, specifically by using a rule matching function to analyze whether the field content contains protocol identification information. Protocol identification information comes from the protocol type field extracted in the previous step; common values ​​include "wifi" and "zigbee." If the field parser determines that the field explicitly contains this identifier field, it groups the record containing that field according to the protocol type, generating multiple "grouped function description sets," each set corresponding to one protocol, ensuring semantic consistency in subsequent clustering processes.

[0095] After protocol grouping is completed, the system executes the K-means clustering algorithm for each group set. The initial step of the clustering algorithm is to set the number of clusters parameter K, which is set according to the estimated number of device function types, usually between 8 and 10; in this embodiment, K is set to 8. The initial selection method for cluster centers is to randomly select 8 function description fields from the current set as initial center points. Then, the system converts each function description field into vector form. The conversion method is to map the field text into word frequency vectors based on a preset semantic dictionary. Each vector has a length of 100 dimensions, representing the frequency of occurrence of the top 100 common function keywords. Cosine similarity is used as a metric to calculate the similarity value between each vector and the K center vectors. The similarity value ranges from 0 to 1, with a larger value indicating greater similarity. The system assigns each field to the cluster with the highest similarity and recalculates the average center vector of each cluster. This process is executed iteratively until all cluster centers converge or the maximum number of iterations of 50 is reached.

[0096] After clustering is completed, the system calculates the intra-cluster similarity for each cluster, which is the average similarity value between all vectors in the cluster and the cluster's center vector. This value reflects the consistency within the cluster. If the average intra-cluster similarity is higher than the set classification threshold of 0.85 (this value is derived based on the experimental data where the clustering quality and manual annotation consistency rate reach 90%), the clustering result is considered valid, and the system includes it in the "Preliminary Functional Classification Table". Each record in the classification table includes: cluster center label, protocol, number of labels within the cluster, and average similarity value.

[0097] Subsequently, the system performs a fusion operation on the records in the preliminary functional classification table. The fusion process uses the device's unique identifier as an index to identify whether there are classification records generated by the same device under multiple protocols. If so, the records are sorted by the timestamp field, and the record with the largest timestamp is selected as the primary label record. The functional category corresponding to the primary record is retained. Other records that are semantically similar to the primary category are merged into that primary category. The merging criterion is that the distance between semantic labels in the semantic dictionary is less than 3. After fusion is complete, a "fused functional classification table" is generated.

[0098] The system continues processing the fusion table, extracting the co-occurrence of functional tags, i.e., counting the number of times multiple tags appear simultaneously in the same device record. This data is used to construct a tag correlation matrix, where the correlation value of each tag pair is equal to its co-occurrence count divided by the total number of device records. If a tag pair has a correlation value higher than 0.7 (this value is determined by statistically analyzing the frequency of actual function combinations to ensure the accuracy of function attribution), then the tag pair is considered highly semantically relevant. Based on the attribution rules, the system merges these highly relevant tag pairs into the same functional category. For example, if the tags "temperature regulation" and "constant temperature mode" frequently co-occur and their correlation value is 0.83, then they are classified into the "temperature control function" category. Finally, the system establishes a mapping relationship between all devices and their determined functional categories, generating a "Device Function Classification Table." This table contains device identifiers, functional categories, tag lists, and attribution confidence values, for use by the subsequent interface construction and control command generation modules.

[0099] S5 includes obtaining functional classification data from the device functional classification table, extracting the classification label field through a preset template parser, and if the classification label field contains a device identifier, grouping according to the device identifier to obtain a set of grouped classification labels.

[0100] For the grouped set of category labels, a dynamic template generation algorithm is used to generate template configuration data. The category labels and interface layout are associated through preset template mapping rules to obtain the template configuration dataset.

[0101] Based on the template configuration dataset, display components are generated through the component rendering processor. If the component rendering result meets the preset interface layout threshold, the set of display components for the unified interface is determined.

[0102] For the set of display components, obtain the interface presentation data, and integrate the component rendering data and function classification data through a data fusion processor to obtain the interface presentation dataset.

[0103] During step S5, the system first reads each functional category data record from the device functional category table generated in the previous stage, extracting the functional category field and the corresponding device identifier field. The system parses the table using a template parser, judging the field content of each record. If the device identifier field has a fixed 8-character string format, with the first 4 characters being the device type code and the last 4 characters being the serial number (e.g., "TEMP0012"), and the field content is not empty, then the system assigns this data to a grouping set with the device identifier as the key, forming multiple category label sets, each containing the functional label of a device.

[0104] The system then invokes a dynamic template generation algorithm for each device's category tag set. This algorithm first performs category mapping based on the number of tags in the set. The system sets the initial control unit template to accommodate a maximum of 6 tags. If the number of tags is no more than 6, a basic template is assigned; if the number of tags is 7 to 12, an extended template is invoked; if the number of tags exceeds 12, a paginated template is used. Each tag is matched to a pre-defined template mapping rule, with the rule format being "tag keyword—control type—display area." For example, the tag "lighting control" corresponds to a button control type and the display area is the upper left corner of the interface. The system generates configuration records based on the rules. These records include the control type name, control width and height in pixels, the control's initial display state, and the control's bound tag value. All configuration records constitute the template configuration dataset for the current device.

[0105] Next, the system processes the template configuration dataset line by line using the component rendering processor, performing control component generation operations. After each control configuration record is loaded, the system calls the control constructor to generate the corresponding type of component, setting its width, height, margins, and color style. The component's display position is determined based on preset area coordinates. The system uses a grid layout to ensure all controls are aligned and do not overlap. The system then checks whether the rendering effect meets the interface layout threshold, set at 0.95, meaning that the total display area of ​​controls in the current interface should be no less than 95% of the ideal control area. The actual display area of ​​a control is the sum of its width and height, and the ideal control area is the maximum control arrangement space set in the current template. The system judges this by calculating the display area ratio. If the ratio is lower than 0.95, the system automatically reduces the control margins by 10 pixels and re-renders until the requirement is met.

[0106] After rendering is complete and layout checks are passed, the system incorporates all valid controls into the display component set, completing the component generation process. Next, the system integrates control components and functional category data using a data fusion processor. Based on the device identifier field as the primary key, the system matches each rendered component with its functional category label, integrating them into a display record. The system then checks label consistency again. If a functional label lacks a corresponding component, the system defaults to configuring that label as the most basic text control and adds it to the display component set. Ultimately, the device's interface presentation dataset consists of the structural configuration of all display components and their bound functional labels, serving as the foundation for subsequent interface display and user interaction.

[0107] S6 includes obtaining user control commands from the interface presentation dataset, extracting the operation type and device identifier from the user control commands through a command parser, and obtaining the parsed command dataset.

[0108] Based on the parsed instruction dataset, the corresponding function tags and device identifiers are obtained from the device function classification table. The operation type and function tags are then integrated by the data fusion processor to obtain the fused instruction function dataset.

[0109] For the fused instruction function dataset, the protocol conversion module generates corresponding control commands according to the preset protocol format to obtain a set of device control commands;

[0110] If the commands in the device control command set meet the preset protocol format threshold, the command verification processor confirms the validity of the commands and obtains the final device control instruction set.

[0111] During step S6, the system first reads user operation records one by one from the interface-presented dataset. Each operation record is generated by the user clicking on an interface-displayed component, which is bound to a specific device function label and device identifier. The system calls the instruction parser module to extract data from the user operations, specifically: extracting the operation type field, such as "on", "off", "heat up", or "cool down", and the corresponding device identifier field, such as "LIGHT001" or "AIRCON002", from the data bound to the component. When extracting the operation type, the system matches it according to the preset action dictionary of the controls in the interface to ensure the accuracy of the parsing results. All extracted operation types and device identifier data form a parsed instruction dataset, which is sorted by timestamp for subsequent processing priority determination.

[0112] After obtaining the parsed instruction dataset, the system reads each instruction one by one, using the device identifier field as the search key to look up the corresponding function tag information in the device function classification table. The device function classification table is organized using a hash table structure, supporting rapid location of function tags; for example, "LIGHT001" corresponds to "lighting control," and "AIRCON002" corresponds to "temperature regulation." The system then merges the found function tags with the operation type field to form a merged instruction function dataset. The merging process uses a structure concatenation method to ensure that each merged record contains three items: device identifier, function tag, and operation type. If the device identifier does not match in the classification table, the system records an exception and outputs it to the pending review queue.

[0113] After generating the fused command function dataset, the system sequentially reads each fused record and calls the protocol conversion module. The protocol conversion module stores command templates for different protocol formats, such as Wi-Fi and Zigbee protocol templates. The system first determines the protocol type based on the function label field. If the function label is "lighting control," the Zigbee protocol template is selected; if the function label is "temperature adjustment," the Wi-Fi protocol template is selected. Subsequently, the system maps the operation type field to specific command parameter values. For example, "on" is converted to the value 1, "off" to the value 0, and "heat up" adds 1 degree to the current temperature value to obtain a new target value. The current temperature value is read from the standardized state dataset.

[0114] The command format consists of three parts: the target device address, the control command type, and the command parameter values. The system fills in the data one by one according to the field structure in the protocol template to generate a complete control command. Examples of command formats include hexadecimal format in the Zigbee protocol and JSON structure in the Wi-Fi protocol. All generated commands are then compiled into a set of device control commands.

[0115] Subsequently, the system inputs each command from the device control command set into the command verification processor for validity validation. During the validation process, the system checks whether the command field order, field length, and data type conform to the protocol template definition. The validation standard is set as a format threshold of 100%, meaning that each command must fully conform to the preset protocol format. If any field in a command does not meet the format requirements, it is considered an invalid command. This threshold is set by the system during the deployment phase, based on the explicit field definitions in the protocol specification document, and does not require user configuration.

[0116] Validated commands are marked as valid and output to the final device control instruction set. This instruction set is categorized and sorted by device identifier and arranged in timestamp order to ensure that commands are executed sequentially when received by the device, avoiding concurrency conflicts or duplicate execution issues. The entire process uses structured data organization, protocol matching, and field validation to ensure that user operations are accurately mapped to device instructions, achieving precise execution of control objectives.

[0117] It also includes S7, which, for the device control command set, distributes it to the target device through the communication scheduling module, obtains the device response status, updates the standardized status dataset, and obtains real-time status feedback, specifically as follows:

[0118] The instruction distribution task is obtained from the device control instruction set, and the distribution channel is matched according to the device identifier through the communication scheduling module to generate the channel allocation instruction set;

[0119] Based on the channel allocation instruction set, the device control instruction set is distributed to the target device through the communication scheduling module, and the response status of the target device is collected to obtain the device status dataset.

[0120] If the device status dataset conforms to the preset data format, the device status dataset is encoded by the status normalization processor to generate a standardized status dataset.

[0121] For the standardized status dataset, the status update module generates real-time status feedback according to the feedback timeliness requirements, thus obtaining the device status feedback set.

[0122] In this implementation, the system first extracts the command tasks to be executed from the device control command set. Each command task includes the type of control operation issued by the user, the unique device identifier of the target device, and the timestamp information of the command generation. After extraction, the corresponding target device is identified through the communication scheduling module. In this module, a device mapping table is first set up. This mapping table is established based on the binding relationship between the device identifier and its communication protocol type. For example, the device identifier "Device A" is matched with its supported Zigbee protocol identifier. Then, the system reads the communication channel type information supported by the device, such as the Wi-Fi channel number or the Zigbee channel number. According to the communication channel type, the corresponding channel allocation command set is generated in the communication scheduling module. The channel allocation command set contains the transmission path parameters of the commands required by each device, including the communication protocol type, transmission channel address, encryption key index, etc.

[0123] Subsequently, based on the generated channel allocation instruction set, the system sends the device control instruction set to the target device through the actual network protocol channel via the communication scheduling module. Immediately after transmission, a listening mechanism is activated to collect the device response status through a polling mechanism. The device response status includes, but is not limited to, operation execution success flags, current device status values, and exception response codes. Each collected result is timestamped and aggregated into a device status dataset. This dataset has a standard structure and includes fields such as: device identifier, operation status value, execution time, and response code.

[0124] Next, it is determined whether the collected device status dataset conforms to the preset data format. Data format verification rules include field integrity checks and field type consistency checks. Field integrity checks mainly include checking for missing fields, such as the device identifier field; field type consistency checks include checking whether the status value is a numeric or string type and whether it exceeds the data range. If the checks pass, the dataset is handed over to the status normalization processor for normalization processing. During normalization, the status values ​​returned by different devices are uniformly converted to the standard format defined internally by the system. For example, the percentage value "seventy-five percent" returned by the device is converted to the numeric value "75", the string "on status" is normalized to the Boolean value "1", and the hexadecimal response code is uniformly converted to decimal encoding.

[0125] After normalization, the data generates a standardized status dataset, which is then indexed and stored in a distributed status database based on device identifiers and timestamps. The status update module periodically checks the latest status data and generates real-time status feedback based on preset feedback timeliness requirements. The feedback timeliness requirement parameter is the maximum response waiting time, for example, set to 5 seconds. This means the device response status must be returned within 5 seconds of the command being issued to be considered valid. If the device status is successfully updated within this time, the execution is considered successful, the system records the feedback set as "successful," and displays the latest device status on the interface. If no status update occurs after 5 seconds, it is recorded as "failure," and a communication error is indicated.

[0126] Ultimately, the entire process outputs a device status feedback set including fields such as the execution result of each control command, the current device status, feedback time, and whether a timeout occurred, for users and the system to use for subsequent judgment and operation. This implementation method realizes a closed-loop control process from the issuance of control commands to device response and then to status update, ensuring the traceability of command execution and the real-time and accurate feedback of system status.

[0127] This also includes S8, which extracts abnormal status information from real-time status feedback. If a function recognition error is detected, the function parsing model is updated through an incremental learning algorithm to obtain optimized model parameters. Specifically:

[0128] The feedback data stream is obtained from the real-time status feedback. The feedback data stream is parsed by the status analysis module to extract the data subset containing the status anomaly identifier, and the abnormal status dataset is obtained.

[0129] If the abnormal state dataset contains error classification labels, the abnormal state dataset is classified according to the preset error correction rules to generate a functional identification error set.

[0130] Based on the functional identification error set, the incremental learning algorithm is used to iteratively train the error classification labels, calculate and update the weights and biases, and obtain the optimized model parameter set;

[0131] By optimizing the parameter set update function of the parsing model, the parameter configuration of the parsing model is parsed, and an updated parsing model is generated, thus completing the model parameter update.

[0132] During step S8, the system first reads the feedback data stream from the real-time status feedback set obtained in step S7. The feedback data stream refers to the sequence of status data generated after the device responds to control commands, and its structure includes device identifier, status code, timestamp, and function label. The system calls the status analysis module to parse each feedback record item by item according to a predefined status code matching table. This matching table contains a list of code values ​​for the device's normal operating status and a list of common error codes, such as device not responding, function execution failure, and status value out of range. When a status code in a record is detected to belong to the error code list, or when the feedback status value is logically inconsistent with the function label, the system marks the record as an abnormal state and aggregates all abnormal records to form an abnormal status dataset.

[0133] Next, the system determines whether each record in the abnormal state dataset contains a function identification error label. This determination process relies on error classification rules, which are set by expert experience and adjusted in actual deployment. Specifically, these rules include the following: if a record's function label is switch control, but the feedback status displays dimming or temperature readings, it is determined to be a function label identification error; if the label is temperature control, but the device is a socket without temperature control, it is also determined to be an identification error. Once these rules are matched, the system categorizes the record into the function identification error set. Each record retains the device identifier, original function label, feedback status information, determination time, and error reason.

[0134] Subsequently, the system invokes the incremental learning module to iteratively train the model on the set of function recognition errors. The training process employs an incremental learning algorithm, the core of which is to fine-tune only the parameters with recognition errors based on the original function parsing model, avoiding resource waste caused by retraining the entire model. Training samples are derived from the set of function recognition errors, with input features including device function fields, contextual state data, and time information. Labels are the correct function categories determined by manual correction or system inference. Training uses a mini-batch gradient descent approach with a batch size of 16 data points and an initial learning rate of 0.001. The training error is the cross-validation error between the predicted and actual labels. If this error decreases by less than 0.1% in three consecutive iterations, the learning rate is halved until convergence. The bias term is determined by the average training error. After each iteration, the weight vector and bias scalar are updated to form an optimized set of model parameters.

[0135] Finally, the system loads the optimized model parameter set into the functional parsing model, replacing the original model parameters with the new ones, forming an updated functional parsing model. This model will be used in subsequent step S3 to parse the device functional description fields. After the update, the system records the model version number, update time, total number of training samples, error descent curve, and final accuracy. The entire process ensures that the system can automatically learn and adjust when errors occur, effectively improving the accuracy of functional parsing, and ensures that the model update process is traceable and runs stably through log tracking and version control.

[0136] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-protocol compatible control method for a smart home energy router, characterized in that, The method includes: S1. Obtain the status information of multi-protocol devices, decompose data packets of protocols such as Wi-Fi and Zigbee through the preset protocol parsing module, extract device status fields, and obtain a standardized status dataset; S2. For the standardized state dataset, a semantic mapping algorithm is used to map fields from different protocols to a unified data model, resulting in a cross-protocol integrated information set. S3. Obtain the device's functional description field from the cross-protocol integrated information set, perform semantic analysis through a pre-trained functional parsing model, and obtain the device functional tag set; S4. For the set of device function tags, use a clustering algorithm to automatically classify the functions, generate a device function classification table, and determine the function affiliation of the device. S5. Obtain the device function classification table, and construct the display components of the unified management interface through the dynamic template generation algorithm to obtain the interface presentation dataset; S6. Extract user control commands from the dataset presented on the interface, combine them with the device function classification table, and generate control commands for the corresponding protocols through the protocol conversion module to obtain the device control command set; S3 includes: Obtain the device function description field from the cross-protocol integrated information set, parse the field content through a preset field extractor, and if the field contains a device type identifier, classify it according to the protocol identifier field to obtain a classified set of device function descriptions. Based on the categorized set of device function descriptions, the field content is processed using a semantic dictionary matching method. If the field content matches the preset semantic dictionary, the matching semantic tags are extracted to obtain a preliminary set of semantic tags. Tag data is obtained from the initial semantic tag set, and semantic classification is performed using the support vector machine algorithm. If the confidence of a tag is higher than a preset threshold, it is assigned to the corresponding functional category, resulting in a classified functional tag set. Based on the categorized set of functional tags, a data fusion processor is used to associate data fusion records. If there is multi-protocol data of the same device in the records, the tags are integrated according to the timestamp priority to obtain the final set of device functional tags. S4 includes: The function description field is obtained from the device function tag set. The field content is extracted through the preset field parser. If the field content contains a protocol identifier, it is grouped according to the protocol identifier to obtain a grouped set of function descriptions. For the grouped set of function descriptions, the K-means clustering algorithm is used to cluster the function description fields. If the intra-cluster similarity of the clustering results is higher than the preset classification threshold, a preliminary function classification table is generated. Based on the preliminary functional classification table, semantic tag data is extracted, and multi-protocol data is associated through the data fusion processor. If there are records of the same device in the multi-protocol data, the tags are integrated according to the timestamp priority to obtain the fused functional classification table. For the merged function classification table, the tag association data is obtained and processed according to the preset attribution determination rules. If the tag association meets the preset threshold, the function attribution of the device is determined and the device function classification table is generated.

2. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that: S1 includes: The system acquires data packets transmitted by multi-protocol devices via Wi-Fi and Zigbee protocols, performs initial decomposition using a preset protocol parsing module, and obtains protocol-specific data units. For a specific data unit of the protocol, if the Wi-Fi protocol data packet contains a complete status field, the status information is extracted through the field mapping table; If the Zigbee protocol data packet contains compressed status fields, then a decompression algorithm is used to restore the status information and obtain the original set of status fields; By using preset field mapping rules, the original set of state fields is formatted and converted to generate state data records in a unified format. A data verification algorithm is used to verify the integrity of status data records in a uniform format. If a record is missing a key field, it is marked as invalid data. If the record is complete, the valid status data is output. Based on the valid status data, combined with the device identifier and timestamp, a standardized status dataset is generated and stored in the distributed database. A standardized state dataset is obtained through a distributed database query interface. The device states are then grouped using the K-means clustering algorithm to obtain the device state classification results. Based on the equipment status classification results, a status update log is generated, stored in the log management system, and status change trend data is output.

3. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that: S2 includes: Obtain the protocol identifier and data structure information from the standardized state dataset. Parse the JSON format data of the Wi-Fi protocol and the binary data of the Zigbee protocol through the protocol identifier. If the device type identifier is included, extract the attribute descriptor to obtain the protocol-specific field description set. Based on the set of field descriptions, a semantic parser is used to perform lexical analysis. The meaning of the fields is matched with a preset semantic dictionary. If the Wi-Fi protocol field is temperature, it is mapped to the temperature attribute of the unified data model to obtain a semantically standardized field mapping table. The data values ​​of different protocols are converted by a field mapping table, and the data type differences are handled by a numerical conversion algorithm. If the Zigbee protocol data is in hexadecimal, it is converted to decimal to obtain attribute data records with a uniform format. Based on attribute data records, information from the same device is merged by a data fusion processor. If there are conflicts between multi-protocol data, they are integrated according to timestamp priority to generate a cross-protocol integrated information set.

4. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that: S5 includes: Obtain functional classification data from the device functional classification table, extract the classification label field through the preset template parser, and if the classification label field contains the device identifier, group the devices according to the device identifier to obtain the grouped classification label set. For the grouped set of category labels, a dynamic template generation algorithm is used to generate template configuration data. The category labels and interface layout are associated through preset template mapping rules to obtain the template configuration dataset. Based on the template configuration dataset, display components are generated through the component rendering processor. If the component rendering result meets the preset interface layout threshold, the set of display components for the unified interface is determined. For the set of display components, obtain the interface presentation data, and integrate the component rendering data and function classification data through a data fusion processor to obtain the interface presentation dataset.

5. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that: S6 includes: The user control commands are obtained from the interface presentation dataset. The operation type and device identifier in the user control commands are extracted by the command parser to obtain the parsed command dataset. Based on the parsed instruction dataset, the corresponding function tags and device identifiers are obtained from the device function classification table. The operation type and function tags are then integrated by the data fusion processor to obtain the fused instruction function dataset. For the fused instruction function dataset, the protocol conversion module generates corresponding control commands according to the preset protocol format to obtain a set of device control commands; If the commands in the device control command set meet the preset protocol format threshold, the command verification processor confirms the validity of the commands and obtains the final device control instruction set.

6. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that, It also includes S7, which, for the device control command set, distributes it to the target device through the communication scheduling module, obtains the device response status, updates the standardized status dataset, and obtains real-time status feedback, specifically as follows: The instruction distribution task is obtained from the device control instruction set, and the distribution channel is matched according to the device identifier through the communication scheduling module to generate the channel allocation instruction set; Based on the channel allocation instruction set, the device control instruction set is distributed to the target device through the communication scheduling module, and the response status of the target device is collected to obtain the device status dataset. If the device status dataset conforms to the preset data format, the device status dataset is encoded by the status normalization processor to generate a standardized status dataset. For the standardized status dataset, the status update module generates real-time status feedback according to the feedback timeliness requirements, thus obtaining the device status feedback set.

7. The multi-protocol compatible control method for a smart home energy router according to claim 1, characterized in that, This also includes S8, which extracts abnormal status information from real-time status feedback. If a function recognition error is detected, the function parsing model is updated through an incremental learning algorithm to obtain optimized model parameters. Specifically: The feedback data stream is obtained from the real-time status feedback. The feedback data stream is parsed by the status analysis module to extract the data subset containing the status anomaly identifier, and the abnormal status dataset is obtained. If the abnormal state dataset contains error classification labels, the abnormal state dataset is classified according to the preset error correction rules to generate a functional identification error set.

8. The multi-protocol compatible control method for a smart home energy router according to claim 7, characterized in that: S8 further includes: Based on the functional identification error set, the incremental learning algorithm is used to iteratively train the error classification labels, calculate and update the weights and biases, and obtain the optimized model parameter set; By optimizing the parameter set update function of the parsing model, the parameter configuration of the parsing model is parsed, and an updated parsing model is generated, thus completing the model parameter update.

Images