Infrared device control interface dynamic generation and key mixed matching method and device

Abstract

This invention provides a method for dynamically generating and matching key presses for an infrared device control interface based on protocol self-description, a terminal device, and an infrared repeater. The method involves obtaining the protocol description file of the target infrared device, comparing the function instance identifier with a preset standard function filter table, and dynamically generating interface controls based on the description information corresponding to the function instance identifier. It also involves obtaining infrared code data and using a multi-level matching mechanism to bind the infrared code data to interface controls on the user interface, including matching based on the function instance identifier and text matching based on the name field. The bound control command is sent to the infrared repeater, or a modified control command is sent to the infrared repeater to control the target infrared device. This method is capable of dynamically generating interface controls to adapt to new device functions and improves the accuracy and robustness of key press matching through a multi-level matching mechanism.

Description

Technical Field

[0001] This invention relates to the field of smart home control technology, and more specifically, to a method for dynamically generating and matching buttons for an infrared device control interface, a terminal device, and an infrared transponder device. Background Technology

[0002] With the rapid development of smart home technology, the types and numbers of infrared remote control devices in the home environment continue to grow, covering traditional home appliances such as televisions, air conditioners, and set-top boxes. To improve user convenience, universal infrared repeaters and mobile terminal applications are widely used for centralized control of devices, enabling users to remotely control infrared devices by simulating the function of a physical remote control through their mobile terminals. However, existing technical solutions have revealed significant shortcomings in practical applications, severely restricting user experience and system adaptability.

[0003] In terms of interface design, mainstream solutions adopt a hard-coded development model, where the application interface uses pre-defined standard button layouts, such as power switches, volume control, and channel switching. When new devices are introduced, developers must define separate interface templates for each device type. While this method has certain advantages in interface stability and ease of development, its core problem lies in the highly rigid interface design and lack of dynamic expansion capabilities. For example, when an air conditioner adds a "powerful cooling" mode or a television supports "3D vision" functionality, these functions cannot be presented and operated on the interface because the application's pre-defined template does not include the corresponding controls. Users are forced to wait for application version updates to obtain support, resulting in extended response times for new features and fragmented user experience. At the same time, frequent expansion of device types requires continuous iteration of application versions, significantly increasing development and maintenance costs. Furthermore, this solution struggles to adapt to the diversified evolution of infrared device functions and cannot meet users' customization needs for personalized functions. For example, non-standard functions such as "independent audio output" for audio equipment or "intelligent humidity control" for air conditioners cannot be effectively integrated.

[0004] In the infrared code matching process, existing technologies primarily rely on a simple matching mechanism based on name strings. After a user learns the infrared code of a physical remote control through an infrared transponder, the application attempts to bind the learned code value to the interface buttons, performing only a direct text comparison based on the button name. However, due to the diverse and complex sources of infrared code data, including cloud-based pre-built libraries, third-party vendors, and user-defined learning, the naming of the same function is highly inconsistent. For example, expressions such as "power on," "power," "Power," and "Switch" may refer to the same function, causing simple text matching to frequently fail, and the buttons learned by the user cannot be correctly associated with the target controls. In scenarios with multiple devices coexisting, this problem is further exacerbated, easily leading to mismatches, such as incorrectly binding the "power" command of a set-top box to the TV's power button, causing device malfunctions. Furthermore, this solution lacks compatibility with legacy data and cannot adapt to naming differences in multilingual environments, such as the mixed use of Chinese "Volume+" and English "Volume+", resulting in a lack of robustness in the matching process. These shortcomings collectively force users to repeatedly try to learn operations, significantly reducing control efficiency and system reliability.

[0005] In summary, existing technologies have systemic shortcomings in terms of the dynamic expansion capability of infrared device control interfaces and the high-precision matching of infrared codes. They cannot simultaneously solve the problems of functional deficiencies caused by interface rigidity and matching failures caused by naming confusion. Summary of the Invention

[0006] This invention aims to provide a method for dynamically generating and matching key buttons for infrared device control interfaces based on protocol self-description, as well as a terminal device and an infrared repeater. It has the advantages of being able to dynamically generate interface controls to adapt to new device functions, and improving the accuracy and robustness of key matching through a multi-level matching mechanism, thereby enhancing the user experience and system reliability.

[0007] To achieve the above objectives, this invention provides a method for dynamically generating and matching buttons for an infrared device control interface based on protocol self-description, comprising the following steps:

[0008] Obtain the protocol description file of the target infrared device, wherein the protocol description file contains at least one functional instance identifier and its corresponding descriptive information; The function instance identifier is compared with a preset standard function filter table, which contains at least one common function identifier supported by the local user interface. If the function instance identifier is not in the standard function filter table, then the interface control is dynamically generated according to the description information corresponding to the function instance identifier and rendered to the user interface. Acquire infrared code data, the infrared code data including a function instance identifier, a name field, and / or a field identifier; bind the infrared code data to interface controls on the user interface, including: First matching step: Matching is performed based on the functional instance identifier. When the functional instance identifier in the infrared code data is equal to the expected functional identifier of the control, the name field in the infrared code data is further checked to see if it is empty, if the field identifier is empty, or if the name field is consistent with the display name of the control. If any of the above verification conditions are met, the matching is determined to be successful. Second matching step: If the first matching step fails to determine a successful match, then text matching is performed based on the name field; The bound control command is sent to the infrared relay device to control the target infrared device; or, when a control command containing numerical parameters is received, the allowable range of the numerical parameters is read. If the numerical parameters exceed the allowable range, they are corrected to a preset value, and the corrected control command is sent to the infrared relay device to control the target infrared device.

[0009] Furthermore, the standard function filter table is pre-installed in local memory, and the general function identifier includes at least one of power function identifier, volume function identifier, and channel function identifier.

[0010] Furthermore, the step of dynamically generating interface controls based on the description information corresponding to the function instance identifier includes: constructing a function action object based on the description information, encapsulating the description information into a button name, and rendering the corresponding click event control in the extended area of ​​the user interface.

[0011] Furthermore, the text matching based on the name field includes: comparing the name field in the infrared code data with the display name of the control; if the two match, the match is considered successful.

[0012] Alternatively, the text matching based on the name field may include: using a fuzzy string matching algorithm to calculate the similarity between the name field in the infrared code data and the display name of the control; if the similarity exceeds a preset threshold, the match is considered successful.

[0013] Furthermore, the numerical parameters include the air conditioning temperature setting value, the allowable range is obtained from the protocol description file according to the current working mode, and the preset value is a preset default temperature value.

[0014] Furthermore, it also includes a multilingual support step: selecting the text of the corresponding language from the description information based on the current language environment as the display name of the dynamically generated interface control; if the text of the current language environment is missing, it will fall back to the default language text.

[0015] Furthermore, it also includes an icon mapping step: allocating locally preset icon resources to dynamically generated interface controls based on the category field or icon keyword corresponding to the function instance identifier.

[0016] In addition, the present invention also proposes a terminal device, including a processor and a memory, wherein the memory stores a computer program, and the computer program implements the above method when executed by the processor.

[0017] In addition, the present invention also proposes an infrared transponder device, comprising: A communication interface is provided for receiving infrared control commands from a terminal device, wherein the infrared control commands are generated by the terminal device executing the above method. An infrared transmitter is used to convert the infrared control commands into infrared signals and send them to the target infrared device.

[0018] As can be seen from the above, the present invention provides a method for dynamically generating and matching the control interface of an infrared device based on protocol self-description, as well as a terminal device and an infrared forwarding device. By dynamically generating interface controls and adopting a multi-level matching mechanism, the present invention solves the problems of interface rigidity and button matching failure. It has the advantages of being able to dynamically generate interface controls to adapt to new device functions and improving the accuracy and robustness of button matching through a multi-level matching mechanism, thereby improving the user experience and system reliability.

[0019] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention obtains and parses the protocol description file of the target infrared device, compares the function instance identifier with a pre-set standard function filter table, and dynamically generates interface controls for functions not in the filter table. This enables the APP interface to support the extended functions of new devices without needing to release a new version. Compared with the existing technology that requires pre-fixing interface templates for each new device, this invention significantly reduces the dependence on APP version iteration, greatly reduces the workload of interface adaptation development, and improves the compatibility speed and user experience of new devices.

[0020] (2) This invention adopts a two-layer hybrid matching strategy of "prioritizing precise matching of functional instance identifiers and using name text matching as a fallback". After successful identifier matching, fault-tolerant verification logic (name field null value verification, field identifier null value verification, and name consistency verification) is introduced. This not only leverages the advantages of precise matching of structured data (functional identifiers) but also ensures compatibility with historical data and user-defined naming scenarios through text matching as a fallback. Compared with existing technologies that rely solely on name string matching, this invention effectively solves the matching failure problem caused by non-standard naming (such as the mixed use of "Power", "supply", and "switch"), and significantly improves the success rate of binding infrared codes and interface controls.

[0021] (3) This invention employs a boundary self-correction mechanism. When receiving control commands containing numerical parameters, it reads the allowable range of the parameters and automatically corrects out-of-bounds values, avoiding invalid command issuance due to abnormal infrared code data, incorrect protocol descriptions, or user misoperation. Taking air conditioner temperature control as an example, when the user sets a temperature that exceeds the device's supported range, the system automatically corrects it to a preset safety value, preventing the sending of erroneous commands to the device and ensuring the stability and safety of the device's operation.

[0022] (4) By pre-setting a filter table containing general function identifiers such as power, volume, and channel in local memory, the present invention enables the rapid differentiation between standard functions and non-standard extended functions, avoids repeatedly loading filter table data every time the protocol description file is parsed, and improves the interface rendering efficiency.

[0023] (5) By encapsulating the description information of the extended functions into button names and rendering them in the extended area of ​​the interface, this invention not only ensures the visibility and usability of non-standard functions in the APP, but also avoids the interface crowding caused by too many controls, maintains the layout stability of the standard function area, and optimizes the user operation experience.

[0024] (6) The present invention provides two optional implementation methods for the text matching step: precise string comparison is suitable for scenarios where the names are completely identical and has high processing efficiency; fuzzy string matching (such as edit distance and similarity calculation) can handle situations where “power switch” and “power” are similar but not completely identical, providing a flexible choice between matching accuracy and mismatch risk, and can be configured and used according to specific application scenarios.

[0025] (7) This invention targets devices such as air conditioners that have numerical range attributes. It obtains the allowable temperature range under the current mode from the protocol description file and automatically corrects it to the preset default value (such as 26°C) when the command exceeds the limit. This effectively avoids control failure or device abnormality caused by the temperature setting exceeding the device's capacity, and improves the reliability of air conditioner control and user experience.

[0026] (8) The present invention selects the text of the corresponding language from the description information according to the current language environment as the display name of the dynamically generated control, and falls back to the default language when it is missing, thereby realizing the internationalization support of the extended function interface, so that the same technical solution can be adapted to the user needs of different language regions without the need to develop the interface separately for different language environments.

[0027] (9) The present invention allocates local preset icon resources to dynamic controls according to the category field or icon keyword corresponding to the functional instance identifier, so that the dynamically generated extended functional controls are visually consistent with the standard functional controls, improving the overall interface and user experience, and avoiding the identification difficulties caused by plain text buttons.

[0028] (10) By integrating the above methods into terminal devices (such as mobile APP), the present invention enables terminal devices to have the capabilities of protocol self-description parsing, dynamic interface generation, intelligent matching and boundary correction. Users can achieve compatible control of new infrared devices without replacing terminal devices, thereby reducing the user's usage cost and the threshold for device upgrades. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the infrared protocol dynamic parsing and interface construction process of the present invention; Figure 2 This is a schematic diagram of the dual-layer hybrid matching logic flow of infrared code data and UI controls in this invention. Detailed Implementation

[0030] The following will be combined with the appendix of this invention. Figure 1 and 2 The technical solutions of this invention will be clearly and completely described below. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. The following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0031] Traditional infrared device control solutions often rely on hard-coding for interface development, resulting in a rigid interface that struggles to support non-standard functions of new devices and incurs high update and maintenance costs. Furthermore, infrared code button binding depends solely on name string matching, leading to low accuracy, susceptibility to mismatches, and poor compatibility, severely impacting user experience and device compatibility.

[0032] To address this issue, the present invention proposes a method for dynamically generating an infrared device control interface and matching buttons, comprising the following steps: Obtain the protocol description file of the target infrared device, which contains at least one functional instance identifier and its corresponding descriptive information; The function instance identifier is compared with a preset standard function filter table, which contains at least one common function identifier supported by the local user interface. If the function instance identifier is not in the standard function filter table, then the interface control is dynamically generated based on the description information corresponding to the function instance identifier and rendered to the user interface. Obtain infrared code data, which includes a function instance identifier, a name field, and / or a field identifier; bind the infrared code data to a UI control on the user interface, including: The first matching step is to match based on the function instance identifier. When the function instance identifier in the infrared code data is equal to the expected function identifier of the control, further verification is performed to check whether the name field in the infrared code data is empty, whether the field identifier is empty, or whether the name field is consistent with the display name of the control. If any of the above verification conditions are met, the match is determined to be successful. Second matching step: If the first matching step fails to determine a successful match, then text matching is performed based on the name field; When a control command containing numerical parameters is received, the allowable range of the numerical parameters is read. If the numerical parameters exceed the allowable range, they are corrected to the preset value. The modified control command is sent to the infrared relay device to control the target infrared device.

[0033] For ease of understanding, the following explains some key terms in this embodiment: Protocol Description File: This file, typically provided by the equipment manufacturer, details the various functions supported by the target infrared device and their corresponding control protocols. Its internal structure can use XML, JSON, or other structured data formats, containing key data such as function instance identifiers, descriptive information, and parameter ranges. It forms the basis for device function parsing and dynamic interface generation.

[0034] Function instance identifier: This identifier is a code or string used in the protocol description file to uniquely identify a specific function of the device. For example, for an air conditioning device, each specific function such as "cooling mode", "air supply mode", and "temperature adjustment" corresponds to a unique function instance identifier.

[0035] Standard Function Filter Table: This table is a predefined list containing identifiers of common functions generally supported by the local user interface. For example, functions such as power switch, volume control, and channel switching are usually considered common functions. The purpose of this table is to distinguish which functions are standard functions and which are non-standard or extended functions, so as to enable dynamic interface generation for non-standard functions.

[0036] General Function Identifier: This identifier is a code or string used in the standard function filter table to represent common, ubiquitous device functions. These functions are typically present in most infrared devices and have a fixed display method and interaction logic on the user interface.

[0037] Interface controls: These are graphical elements on the user interface used for user interaction, such as buttons, sliders, and text boxes. In this embodiment, interface controls can be dynamically generated based on the description information of function instance identifiers to support non-standard functions of the device.

[0038] Infrared code data: This data is binary or hexadecimal encoding emitted by the infrared remote controller to control infrared devices. When learning or acquiring infrared code data, some metadata is usually included, such as function instance identifiers, name fields, and / or field identifiers, to facilitate identification and binding.

[0039] Name field: This field contains text information from the infrared code data that describes the function corresponding to the infrared code, such as "Power On," "Volume Up," or "Mode Switch." This field plays a role in matching the infrared code with the text of the interface controls.

[0040] Field Identifier: This identifier is an auxiliary identifier in infrared code data used to further distinguish or limit functions. For example, in some complex devices, there may be multiple "setting" functions, which can be more accurately distinguished by the field identifier.

[0041] Numerical parameters: These are variable values ​​included in the control commands, such as the temperature setpoint, fan speed level, and timer duration for an air conditioner. These parameters typically have specific allowable ranges; values ​​outside these ranges may cause the equipment to malfunction or exhibit abnormal behavior.

[0042] Permissible range: This range refers to the predefined acceptable minimum and maximum values ​​for a numerical parameter. For example, the permissible range for an air conditioner temperature might be 16°C to 30°C. Verifying the range of numerical parameters ensures the validity and safety of control commands.

[0043] Preset value: When a numerical parameter exceeds its allowable range, the system corrects it to a default, safe, or commonly used value. For example, if the temperature setting is out of range, it can be corrected to 26℃.

[0044] Infrared repeater: This device is a hardware unit capable of receiving control commands from terminal devices and converting them into infrared signals for transmission to the target infrared device. It acts as a bridge between the terminal device and the infrared device.

[0045] In addition, the English abbreviations and key terms are explained as follows: FIID: Function Instance ID, used to uniquely identify a specific function of an infrared device; Profile: Device protocol description file, which contains a list of functions supported by the device and their attribute descriptions; protocolLibId: Protocol library ID, used to index the protocol description file corresponding to the device; Filter Set: A standard function filter table containing a set of common function IDs with pre-built UI layouts in the app. FIId Action: A function action object that encapsulates the ID and display name of the extended function and is used to dynamically generate controls; keyIv Name: The display name of the control; the text label of the button control on the UI interface. eFiid: Expected Function ID, the default function ID that the UI control is expected to match; Key Name: The name field for the infrared code data; field Name: Field identifier for infrared code data.

[0046] This embodiment provides a method for dynamically generating and matching button mapping for infrared device control interfaces based on protocol self-description.

[0047] First, the protocol description file of the target infrared device needs to be obtained. This file can be downloaded from a cloud server or read from local storage media. This file contains information about the various functions supported by the device; for example, it may simply list the function names and corresponding control codes, or it may contain more detailed function instance identifiers and their textual descriptions.

[0048] Next, the function instance identifiers parsed from the protocol description file are compared with a pre-defined standard function filter table. This standard function filter table can be a simple list that enumerates common, general functions such as "power on / off" and "volume adjustment." The comparison process can involve searching each function instance identifier one by one to determine whether it belongs to a general function.

[0049] If the comparison results show that a certain function instance identifier is not in the standard function filter table, it indicates that the function is a non-standard or extended function. In this case, the system will dynamically generate the corresponding interface control based on the description information corresponding to the function instance identifier. For example, if the description information is "Powerful Mode", a button displaying the words "Powerful Mode" can be generated. This interface control is then rendered to the extended area of ​​the user interface for user operation.

[0050] After the interface controls are generated, infrared code data needs to be obtained. This infrared code data can be obtained by the user learning the physical remote control buttons, or it can be loaded from a preset infrared code library. This infrared code data typically contains a function identifier, a text name describing the function, or an auxiliary field identifier.

[0051] Next, the acquired infrared code data is bound to existing UI controls on the user interface. This binding process includes two matching steps. In the first matching step, the system first matches the functional instance identifier in the infrared code data with the expected functional identifier of the UI control. For example, if the functional identifier of the infrared code is exactly the same as the expected functional identifier of the UI control, further verification is performed. This verification can check whether the name field in the infrared code data is empty, or whether the field identifier is empty, or whether the name field is exactly the same as the display name of the control. As long as any of the above conditions are met, the match is considered successful.

[0052] If the first matching step fails, the system proceeds to the second matching step. In this step, the system performs text matching based on the name field in the infrared code data and the display name of the interface control. For example, a simple string inclusion check can be used, that is, checking whether the name field of the infrared code contains the display name of the interface control, or vice versa. If the inclusion relationship is satisfied, the match is considered successful.

[0053] Finally, the bound control command is sent to the infrared relay device to control the target infrared device.

[0054] When a user sends control commands via the interface controls, if the command includes numerical parameters, such as wind speed level or timeout duration, the system reads the allowable range of these parameters. This allowable range can be a fixed preset interval, for example, wind speed levels can only be between 1 and 5. If the received numerical parameter exceeds this preset allowable range, the system will automatically correct it to a preset value, for example, correcting the out-of-range wind speed level to the default level 3. Then, the corrected (if necessary) control command is sent to the infrared repeater. After receiving the command, the infrared repeater converts it into a corresponding infrared signal and transmits it to the target infrared device, thereby achieving precise control of the target infrared device.

[0055] This embodiment effectively solves the problems of fixed and unscalable control interfaces in traditional infrared devices by dynamically generating interface controls, enabling new devices or non-standard functions to be presented on the user interface in a timely manner. Simultaneously, the adoption of a multi-level matching strategy based on functional instance identifiers and name fields significantly improves the binding accuracy between infrared codes and interface controls, reducing the risk of mismatches. Furthermore, range verification and correction of numerical parameters ensure the validity of control commands and the stable operation of the device. Therefore, this method overcomes the shortcomings of existing technologies in dynamic interface expansion and high-precision infrared code matching, improving user experience and system compatibility.

[0056] Preferably, the standard function filter table is pre-installed in local memory, and the general function identifier includes at least one of a power function identifier, a volume function identifier, and a channel function identifier. Specifically, the local memory can refer to random access memory (RAM), read-only memory (ROM), or flash memory within the terminal device. Pre-installing the standard function filter table in local memory means that the table is already fixed or loaded into the device at the time of device manufacturing or software installation, eliminating the need to download it from an external server or read it from an external storage device during runtime. This pre-installation method ensures fast access speed and high reliability of the filter table, enabling normal function comparison even in offline environments. Meanwhile, the general function identifier refers to a unique identification code that is commonly found in various infrared devices and has similar control logic. The power function identifier is used to control the device's power on / off state; the volume function identifier is used to adjust the device's volume; and the channel function identifier is used to switch the device's playback channel. These functions are the most commonly used and basic control functions of infrared devices (such as televisions, air conditioners, set-top boxes, etc.). By clearly defining these common function identifiers, the system can prioritize the identification and processing of these core functions, ensuring that users can respond quickly and accurately to basic operations on common devices.

[0057] By pre-loading the standard function filter table into local memory using the above technical solution, the system can access the filter table at extremely high speed when comparing function instance identifiers, significantly improving comparison efficiency and user interface responsiveness. Simultaneously, since the filter table is stored locally, the system no longer relies on external networks or storage, enhancing system stability and offline availability. Furthermore, explicitly defining common function identifiers, such as power function identifiers, volume function identifiers, and channel function identifiers, allows the system to optimize processing for these most frequently used functions, ensuring accurate identification and matching of core control functions. This improves the convenience and accuracy of user operation and avoids the problem of a degraded user experience due to unrecognized common functions.

[0058] The present invention further proposes a specific method for dynamically generating interface controls based on the description information corresponding to the function instance identifier, which includes: constructing a function action object based on the description information, encapsulating the description information as a button name, and rendering the corresponding click event control in the extended area of ​​the user interface.

[0059] Specifically, constructing functional action objects based on the described information aims to transform the descriptive information obtained from the protocol description file, corresponding to specific function instance identifiers, into structured objects that can be recognized and executed within the system. This descriptive information may include the function's name, parameter types, parameter ranges, and execution command sequences. By constructing functional action objects, the system can parse, abstract, and encapsulate this raw, potentially unstructured descriptive information, forming a software entity with clearly defined behaviors and attributes. For example, for a "wind speed adjustment" function, the functional action object could include a list of allowed values ​​for the "wind speed" parameter (e.g., low, medium, high) and a command template for sending the corresponding infrared code. This allows subsequent interface rendering and event handling to operate based on unified, standardized objects, improving the system's modularity and scalability.

[0060] Simultaneously, the description information is encapsulated into button names. This step presents the function represented by the functional action object on the user interface in a user-friendly text format. The description information may contain text in multiple languages ​​or technical terms. When encapsulating into button names, the system extracts or generates a concise and intuitive label from the description information as the display text for the corresponding control on the user interface. For example, if the description information contains "Set Fan Speed ​​to High," it can be encapsulated as "High Wind Speed" as the button name. This ensures that users can clearly understand the function represented by each dynamically generated control, thereby improving the readability and usability of the user interface.

[0061] Building upon this, the corresponding click event control is rendered in the extended area of ​​the user interface. This step involves creating and displaying a user-interactive interface element in a specific area of ​​the user interface, typically a "reserved extended area" for non-standard or custom functions. The click event control is usually in the form of a button, icon button, or clickable text label, and its appearance and behavior allow users to trigger the corresponding function through clicks. Rendering these controls in the extended area avoids confusion with standard function controls (such as power and volume) and provides users with a way to access all the unique functions of the device. When the user clicks the control, the system triggers the function action object bound to that control, thereby executing the corresponding infrared control command.

[0062] Through the above technical solution, this invention can effectively transform the description information corresponding to non-standard functional instance identifiers in the target infrared device protocol description file into user-understandable and operable interface elements. Specifically, by constructing functional action objects based on the description information, the system can transform abstract functional definitions into executable logical entities, providing a solid foundation for subsequent interface interactions. Simultaneously, encapsulating the description information into intuitive button names greatly improves the user's cognitive efficiency of dynamically generated control functions, avoiding obstacles to understanding complex technical descriptions. Furthermore, rendering the corresponding click event controls in the extended area of ​​the user interface not only provides dedicated display space for non-standard functions, avoiding clutter on the main interface, but also ensures that these functions can be activated by the user through simple click operations. Overall, this solution significantly enhances the dynamic adaptability and user-friendliness of the infrared device control interface, enabling even infrared devices with unique or complex functions to have their non-standard functions automatically identified, clearly presented, and easily operated by the system, thereby improving user experience and device compatibility.

[0063] In this embodiment, the text matching based on the name field includes: comparing the name field in the infrared code data with the display name of the control; if they match, the match is considered successful. Specifically, string comparison is a basic text matching method used to determine whether two strings are completely identical. In scenarios where the infrared device control interface is dynamically generated and buttons are matched, this means that the system directly compares the name field extracted from the infrared code data with the display name of the interface control rendered on the user interface. This comparison is usually performed character by character, requiring the two strings to be completely identical in content, order, and case (if case-sensitive). This can be implemented using string equality comparison functions provided by programming languages, such as the `equals()` method in Java and the `==` operator in Python. This direct comparison method is simple, efficient, and suitable for scenarios where the name field and display name are expected to be completely identical, enabling rapid confirmation of the matching relationship.

[0064] Through the above technical solution, when the first matching step fails, the system can perform a second matching by directly comparing the name field in the infrared code data with the display name of the control, using a precise string comparison method. This precise matching method ensures the accuracy of button binding, avoids misoperation or matching failure due to name inconsistencies, and improves the reliability of user operations. It is particularly suitable for scenarios where there is a strict correspondence between infrared code data and the display name of interface controls, thus effectively solving the problem of how to accurately and efficiently perform text matching after the functional instance identifier matching fails.

[0065] In another embodiment, a different implementation method for text matching based on the name field is proposed, which includes using a fuzzy string matching algorithm to calculate the similarity between the name field in the infrared code data and the display name of the control. If the similarity exceeds a preset threshold, the match is determined to be successful.

[0066] Fuzzy string matching algorithms are a technique for measuring the similarity between two strings. Unlike traditional precise string comparison, fuzzy matching algorithms can tolerate subtle differences in strings, such as the addition, deletion, modification, and reordering of characters, and quantify their closeness. Common fuzzy string matching algorithms include, but are not limited to, Levenshtein distance (edit distance), Jaro-Winkler distance, N-gram similarity, or cosine similarity. For example, Levenshtein distance measures similarity by calculating the minimum number of single-character editing operations (insertion, deletion, or replacement) required to transform one string into another; N-gram similarity assesses similarity by comparing the number of sequences (N-grams) of shared N characters in two strings. These algorithms yield a numerical value, the similarity score, typically between 0 and 1, where 1 indicates identical strings and 0 indicates completely different strings. The preset threshold is a critical value pre-set by the system to determine whether a match is successful. After calculating the similarity between the name field in the infrared code data and the display name of the control, the system compares this similarity score with the preset threshold. If the calculated similarity is greater than or equal to the preset threshold, the two names are considered sufficiently similar, and a successful match is determined. This preset threshold can be flexibly configured according to the needs of the actual application scenario; for example, it can be set to 0.7, 0.8, or higher to balance matching accuracy and recall.

[0067] Through the above technical solution, this invention effectively solves the matching failure problem caused by subtle differences between the name field and the displayed name (such as spelling errors, abbreviations, synonyms, or word order changes). Employing a fuzzy string matching algorithm, the system is no longer limited to strict character consistency but can identify semantically related but not literally identical keys. This method significantly improves the success rate and robustness of key matching, enabling the system to accurately bind infrared code data to corresponding interface controls even when there is an imprecise correspondence between infrared code data and user interface control names. This not only enhances the user experience and reduces the need for manual configuration but also strengthens the adaptability of the entire infrared device control system to diverse infrared code data, allowing users to control target infrared devices more conveniently and accurately.

[0068] In practical applications, the allowable range for certain key numerical parameters, such as the temperature setpoint of an air conditioner, is not fixed but dynamically changes depending on the current operating mode of the device (such as cooling or heating). If the system fails to accurately verify and correct these dynamic changes, it may send control commands that are not compatible with the current mode, leading to abnormal device operation or a poor user experience.

[0069] To address the aforementioned issues, this invention further proposes a refined processing scheme for numerical parameters. Specifically, the numerical parameters include the air conditioning temperature setpoint, the allowable range is obtained from the protocol description file based on the current operating mode, and the preset value is a preset default temperature value.

[0070] Numerical parameters refer to quantified data carried in control commands to adjust a specific attribute of equipment. For example, for air conditioning equipment, the temperature setpoint is a typical numerical parameter, which directly determines the target temperature for cooling or heating. In addition to temperature setpoints, numerical parameters can also include fan speed levels, timer durations, humidity setpoints, etc. These parameters are usually expressed in integer or floating-point form and have specific physical meanings and value ranges.

[0071] The permissible range refers to the acceptable range of values ​​for a numerical parameter under specific operating conditions. For air conditioning temperature setpoints, the permissible range is not fixed but dynamically changes according to the air conditioner's current operating mode (e.g., cooling mode, heating mode, automatic mode, fan mode, etc.). The protocol description file is a document describing the communication protocol and functional characteristics of the target infrared device, typically defining in detail the valid parameter ranges for different functional instances (such as temperature setting) under different operating modes. When the system receives a control command containing numerical parameters, it first identifies the target device's current operating mode, then parses the protocol description file to extract the permissible range of the temperature setpoint corresponding to that operating mode. For example, in cooling mode, the permissible range might be 16℃ to 30℃; while in heating mode, it might be 18℃ to 32℃. This dynamic acquisition of the permissible range ensures the accuracy of parameter verification and the safety of the equipment.

[0072] A preset value refers to the default value that the system uses to replace an invalid parameter when the received numerical parameter exceeds its allowable range. For air conditioning temperature settings, this preset value is usually a relatively neutral default temperature value that is acceptable in most situations, such as 26℃. This default temperature value can be preset according to user habits, device type, or environmental standards. When a user attempts to set a temperature that exceeds the allowable range of the current mode, the system will not directly reject the command but will correct it to this preset default temperature value. This avoids the command becoming completely invalid and provides a relatively reasonable alternative, ensuring the effectiveness of the control command and the normal operation of the device.

[0073] By using the above technical solution, the numerical parameters are specifically limited to the air conditioner temperature setpoint, and its allowable range is further clarified to be dynamically obtained from the protocol description file based on the current operating mode. Simultaneously, parameters exceeding the range are corrected to a preset default temperature value. This invention significantly improves the intelligence and security of infrared device control. In practical applications, different operating modes of air conditioning equipment (such as cooling and heating) have drastically different temperature setpoint ranges. If a static or single allowable range is used for verification, a valid temperature command sent in one mode may be misjudged as invalid, or an invalid temperature command sent in another mode may not be corrected in time, leading to abnormal equipment operation or a poor user experience. This solution ensures the accuracy of temperature verification by dynamically obtaining the allowable range, enabling the system to make intelligent judgments based on the actual operating status of the air conditioner. When the user inputs a temperature value exceeding the allowable range of the current mode, the system can correct it to a preset default temperature value, rather than simply rejecting the command or sending an invalid command that may cause equipment malfunction. This not only avoids control failures caused by user misoperation or system compatibility issues but also provides a flexible error handling mechanism, ensuring the validity of control commands and stable equipment operation, thereby improving user satisfaction and security with infrared device control.

[0074] The present invention further proposes a multilingual support step, which selects the text of the corresponding language from the description information according to the current language environment as the display name of the dynamically generated interface control. If the text of the current language environment is missing, it will fall back to the default language text.

[0075] This multilingual support step aims to enhance the internationalization and localization capabilities of the user interface, ensuring that users from different language backgrounds can clearly understand and operate dynamically generated interface controls. Its core lies in extracting or generating text in the corresponding language from pre-stored description information based on the user's current language preference, and using this as the display name for the interface controls. Specifically, the "current language environment" refers to the language preference currently set on the user's terminal device or system, such as Simplified Chinese, English, Japanese, etc. After obtaining the protocol description file of the target infrared device, this description information typically contains multilingual text resources, or at least text in a default language along with identifiers for translation. The system detects the current language environment setting, for example, by reading the operating system's language settings or the language selected by the user in the application. Then, based on this language environment, it parses the text content matching that language environment from the protocol description file. For example, if the current language environment is English, the system searches for the corresponding English text in the description information; if it is Chinese, it searches for Chinese text. These selected texts will be directly used to set the display names of dynamically generated interface controls (such as buttons, labels, etc.), ensuring that the user interface is presented in a familiar language. Furthermore, the "default language text" typically refers to a common language text preset in the protocol description file, such as English or the official language of the device manufacturer's location. When the system attempts to select the corresponding language text from the description information based on the current language environment, it may encounter situations where the language text is not available. For example, the protocol description file may only provide English and Japanese text, while the current language environment is French. In this case, to avoid the interface controls displaying as blank or garbled characters, the system will execute a fallback mechanism, automatically selecting and using the preset default language text as the display name of the interface controls. This mechanism ensures that even when certain specific language texts are missing, the user interface remains usable and understandable, providing a basic, operable interface.

[0076] Through the above technical solution, this invention, when dynamically generating the infrared device control interface, can intelligently select or revert to the appropriate display text based on the user's current language environment, thereby solving the problem of user comprehension barriers caused by language mismatch. This greatly enhances the internationalization and localization capabilities of the user interface, enabling users with different language backgrounds to operate the infrared device smoothly and accurately, significantly improving the user experience and broadening the applicability of the device. Even in cases where certain language texts are missing, the mechanism of reverting to the default language text ensures that the interface controls always have understandable display content, avoiding blank interfaces or garbled characters, and guaranteeing the stability and usability of the system.

[0077] In some of the above embodiments, the system can dynamically generate interface controls based on the protocol description file of the infrared device and render them to the user interface, thereby achieving universal control of various infrared devices. However, when interface controls are generated solely based on description information, the user interface may only present text or general graphics, lacking intuitive visual identifiers. This may make it difficult for users to quickly understand the specific function of each control when faced with a large number of or unfamiliar functions, thus affecting operational efficiency and user experience. Especially for infrared devices with complex functions or a wide variety of types, a plain text or general graphic interface may not effectively guide users in operation.

[0078] In response, the present invention further proposes an icon mapping step, which involves allocating locally preset icon resources to dynamically generated interface controls based on the category field or icon keyword corresponding to the function instance identifier.

[0079] Specifically, the icon mapping step aims to provide intuitive visual identifiers for dynamically generated interface controls, enhancing the usability and aesthetics of the user interface. By associating specific icons with functions, users can more quickly identify and understand the functionality of controls without relying entirely on text descriptions. The category field or icon keyword corresponding to the function instance identifier is information contained in the protocol description file or related metadata, indicating the type of a specific function instance or its associated icon. The category field can be an identifier that macroscopically categorizes functions, such as "air conditioning function" or "television function"; icon keywords can be more specific descriptive terms, such as "power," "silent," "mode," or "fan speed," which can be directly or indirectly mapped to preset icon resources. Dynamically generated interface controls refer to interactive elements, such as buttons, sliders, and switches, created and presented in real-time on the user interface based on the protocol description file of the target infrared device. These controls provide control over specific functions of the infrared device. Locally preset icon resources refer to a collection of graphic files pre-stored in the local memory of the terminal device. These graphic files are typically designed and optimized icons used to represent various common or specific functions. These icon resources can be matched with category fields or icon keywords based on their filename, metadata, or internal identifiers. Assignment refers to associating the matched local preset icon resources with the corresponding dynamically generated UI controls, so that the icon can be displayed on the user interface along with the control, serving as a visual cue for the control's function.

[0080] Through the above technical solution, this invention can allocate locally pre-set icon resources to dynamically generated interface controls based on the category field or icon keyword corresponding to the functional instance identifier. This allows the user interface to no longer be limited to plain text or general graphics, but to present controls with rich visual information. Users can quickly identify and understand the purpose of each functional control with intuitive icons; for example, a power icon clearly indicates that it is a power switch, and a fan icon represents fan speed adjustment. This visual presentation significantly reduces the user's cognitive burden and learning cost, especially when faced with a large number of or unfamiliar functions, enabling users to operate more efficiently, thereby greatly improving the user experience and system usability. At the same time, a unified icon style also enhances the overall aesthetics and professionalism of the user interface.

[0081] Furthermore, the present invention proposes a terminal device comprising a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the above-described method.

[0082] The terminal device can be any electronic device capable of performing computing tasks and interacting with the user, such as a smartphone, tablet, smart speaker, smart home control screen, personal computer, or dedicated remote control device. As the core carrier of the infrared device control system, this terminal device provides the necessary hardware environment and user interface for the operation of the aforementioned method.

[0083] The processor is the computing and control core of the terminal device, responsible for executing computer programs stored in memory. This processor can be a central processing unit (CPU), microcontroller (MCU), system-on-a-chip (SoC), or any other computing unit with instruction execution capabilities. Its main functions include parsing computer program instructions, performing data operations, managing system resources, and coordinating the work of various hardware modules, thereby driving the smooth implementation of the steps in the aforementioned infrared device control method.

[0084] The memory is used to store computer programs and various data generated during program execution. This memory may include random access memory (RAM) for temporary data storage and program execution space, and non-volatile memory such as read-only memory (ROM), flash memory, or hard disk for long-term storage of the operating system, application programs (i.e., the computer programs), and user data. Through the memory, computer programs are persistently preserved and loaded and executed when needed by the processor.

[0085] The computer program is a collection of instructions that, when executed by a processor, can perform the following functions according to the steps of the aforementioned method for dynamically generating and matching the infrared device control interface: acquiring the infrared device protocol description file, comparing the function instance identifier with the standard function filter table, dynamically generating and rendering interface controls, binding infrared code data to interface controls (including the first and second matching steps), correcting numerical parameters, and sending control commands. This computer program is the software carrier that implements the logic of the above method.

[0086] Through the above technical solution, this invention provides a specific hardware platform that enables the method for dynamically generating infrared device control interfaces and matching buttons to be practically deployed and run. This terminal device acts as a bridge between the user and the infrared device, executing stored computer programs through its processor to transform abstract control logic into a user-perceptible, interactive operating experience. This not only solves the problem of the physical carrier required for the method's implementation but also allows users to conveniently manage and control multiple infrared devices through a unified terminal device, greatly improving device compatibility and user operation convenience in smart home or office environments. This terminal device can intelligently generate customized control interfaces based on the protocol description files of different infrared devices and accurately match button functions. Simultaneously, it intelligently corrects the numerical parameters in the control commands, thereby ensuring the accuracy and reliability of control and providing users with a more intelligent and efficient infrared device control experience.

[0087] In addition, the present invention also proposes an infrared relay device, which includes a communication interface for receiving infrared control commands from a terminal device, the infrared control commands being generated by the terminal device executing the above-described method; and an infrared transmitter for converting the infrared control commands into infrared signals and sending them to a target infrared device.

[0088] This embodiment combines a communication interface with an infrared transmitter in a collaborative manner to specifically receive infrared control commands generated by the terminal device using the aforementioned method, thereby ensuring the accuracy and compatibility of the commands. Because the above method achieves dynamic generation of the infrared device control interface and high-precision button matching, the generated infrared control commands have been verified through function instance identifiers and corrected for numerical parameter ranges, avoiding command errors caused by name string mismatches or missing non-standard functions in traditional solutions. Specifically, when receiving commands, the communication interface only processes valid control commands output by the above method, eliminating the risk of inconsistent name fields or excessive parameters; the infrared transmitter then accurately converts the command into an infrared signal, ensuring that the signal fully matches the protocol of the target infrared device. Through this technical solution, the problem of control failure caused by inaccurate command sources during infrared forwarding is effectively solved, significantly improving the reliability of device control and overall system compatibility, while reducing user operation complexity.

[0089] The following combination Figure 1 and Figure 2 To further illustrate the above technical solution, a more specific example will be used: User A purchased a new smart air conditioner with special features not commonly found on traditional remote controls, such as a "powerful mode" and a "sleep mode." User A wants to centrally control the air conditioner via a mobile app, rather than using multiple physical remote controls.

[0090] First, when user A adds this new smart air conditioner to the mobile app for the first time, the app retrieves the air conditioner's protocol description file from the cloud and queries the corresponding profile text based on the air conditioner's protocolLib ID. This file details all the functions supported by the air conditioner, such as the function instance identifiers and corresponding descriptions for "Power," "Temperature Adjustment," "Fan Speed," and "Power Mode." For example, "Power Mode" might correspond to the function instance identifier "FAN_BOOST" and the description "Power Mode, rapid cooling / heating."

[0091] Subsequently, the mobile terminal APP has a pre-built standard function filter set stored in local memory. This table contains common function identifiers (FIIDs) supported by the APP's local user interface, such as power (0x8110), volume (0x8117), and channel (0x8134). The APP will iterate through the function list (FIIDs) in the protocol description file, compare each function instance identifier obtained from the air conditioning protocol description file with this filter set, and determine whether each FIID is in the standard function filter set.

[0092] For functions like "POWER" and "TEMP_UP" that are in the standard function filter table, the app directly uses their preset standard interface controls. However, for function instance identifiers such as "FAN BOOST" (powerful mode) and "SLEEP MODE" (sleep mode), since they are not in the standard function filter table, the app determines that the function is a non-standard extended function and dynamically generates interface controls based on its corresponding description information. Specifically, the app extracts the function description text fIIdDescription corresponding to the FIID, dynamically constructs a function action object FIIdAction, and encapsulates the description text as a Num Map as the button name. The UI rendering engine automatically generates corresponding click event controls in the extended areas of the interface (such as the "More" panel or bottom list) based on the generated FIIdAction list, achieving seamless function extension.

[0093] If the app supports multiple languages, it will select the corresponding Chinese text "Powerful Mode" from the description information as the display name for the dynamically generated interface control based on the current language environment (e.g., Chinese). Simultaneously, the app will allocate locally pre-defined icon resources to the dynamically generated interface control based on the category field (e.g., "fan function") or icon keyword (e.g., "boost") corresponding to the "FANBOOST" function instance identifier. For example, an icon representing strong winds. Through this process, buttons for non-standard functions such as "Powerful Mode" and "Sleep Mode" will automatically appear on User A's app interface without waiting for an app update, solving the problems of interface rigidity and lack of extensibility in existing technologies.

[0094] Next, User A wants to learn the "Strong Mode" button from the physical remote control into the app. User A operates an infrared repeater to learn the "Strong Mode" infrared signal emitted by the physical remote control. The infrared repeater sends the learned infrared code data (which may contain the function instance identifier "CUSTOM FAN MODE", the name field "Strong", and / or the field identifier "FANMODE 1") to the mobile app. After receiving the infrared code data, the app needs to bind it to the existing "Strong Mode" interface control on the user interface.

[0095] The app first obtains a collection of all controls on the current UI interface. Each control contains two attributes: keyIvName (display name) and eFiid (expected function ID; standard buttons have this value, while custom buttons may be empty); and then obtains a collection of infrared code data stored on the device.

[0096] Perform the first matching step: Match based on the function instance identifier.

[0097] The system iterates through the data, prioritizing checks if the fiid of the infrared code data matches the eFiid of the UI control. If the IDs match, to prevent dirty data (e.g., the ID is correct but the name has been incorrectly modified), the system performs the following checks: if the keyName of the infrared code data is empty; or the fieldName (field identifier) ​​is empty; or the keyName is exactly the same as the UI control name. If any of these conditions are met, it is considered a successful exact match, and binding is initiated immediately. This step resolves the issue of inconsistent names (e.g., "Power" versus "Power Supply") but essentially identical function IDs.

[0098] Suppose the function instance identifier contained in the infrared code data is "CUSTOM FAN MODE", while the expected function identifier of the dynamically generated "Strong Mode" control is "FAN BOOST". Since "CUSTOM FAN MODE" and "FAN BOOST" are not equal, the first matching step fails to determine that the match is successful.

[0099] The second matching step is then performed: text matching based on the name field.

[0100] If the first-level matching fails (e.g., the old data lacks a FIID, or the custom button lacks a standard FIID), the system downgrades to text matching mode: directly comparing the keyName of the infrared code data with the keyIvName (or extKeyIvName) of the UI control. For example, the name field "Strong" in the infrared code data is compared with the display name "Strong Mode" of the control. If the strings match, it is considered a successful fuzzy match, and binding is performed. This step is compatible with legacy data and user-defined naming scenarios.

[0101] If a direct string comparison doesn't match, the app uses a fuzzy string matching algorithm (e.g., calculating edit distance) to calculate the similarity between the name field "Strong" in the infrared code data and the control's display name "Strong Mode". If the similarity exceeds a preset threshold (e.g., 80%), a successful match is determined. For example, "Strong" and "Strong Mode" have a high similarity, so a successful match is possible. This two-step matching mechanism significantly improves the accuracy of binding infrared codes to UI controls, solving the problems of low accuracy and mismatches caused by relying solely on name string matching in existing technologies. It first attempts a more precise functional instance identifier match, and then falls back to a more flexible text match if that fails, balancing accuracy and compatibility.

[0102] Finally, when a control instruction containing a temperature setting is received, the system reads the allowable temperature range (min to max) in the current mode. If the temperature value (set Temp) in the instruction exceeds this range (set Temp < min or set Temp > max), the system automatically resets it to the default safety value to prevent sending invalid or incorrect infrared code instructions to the device.

[0103] For example, User A clicks the "Powerful Mode" button on the APP interface and attempts to set the air conditioner temperature to 10°C. Before sending this control instruction, the APP reads the allowable range of the air conditioner temperature setting value (numerical parameter) in the protocol description file. Suppose that in the current "Powerful Mode" operating mode, the allowable temperature range of the air conditioner is 16°C to 30°C. Since the 10°C set by User A exceeds this allowable range, the APP will correct it to the preset value, for example, correct it to the lowest allowable temperature of 16°C in this mode. The APP sends the corrected control instruction (for example, "Powerful Mode", temperature set to 16°C) to the infrared forwarding device. The infrared forwarding device receives the infrared control instruction from the mobile terminal APP through its communication interface. Subsequently, the infrared forwarding device uses its infrared emitter to convert this control instruction into an infrared signal and sends it to the target infrared device - namely, User A's smart air conditioner. After receiving the infrared signal, the air conditioner will operate according to the settings of "Powerful Mode" and 16°C. This parameter correction mechanism ensures that the instructions sent to the infrared device are always within the effective operating range of the device, avoiding invalid instructions or abnormal device behaviors caused by user misoperations or device protocol limitations, and improving the stability of the system and the user experience.

[0104] The above are only embodiments of the present invention and are not used to limit the protection scope of the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for dynamically generating and matching key presses of an infrared device control interface based on protocol self-describing, characterized in that, Includes the following steps: Obtain the protocol description file of the target infrared device, wherein the protocol description file contains at least one functional instance identifier and its corresponding descriptive information; The function instance identifier is compared with a preset standard function filter table, which contains at least one common function identifier supported by the local user interface. If the function instance identifier is not in the standard function filter table, then the interface control is dynamically generated according to the description information corresponding to the function instance identifier and rendered to the user interface. Acquire infrared code data, wherein the infrared code data includes a function instance identifier, a name field, and / or a field identifier; Binding the infrared code data to interface controls on the user interface includes: First matching step: Matching is performed based on the functional instance identifier. When the functional instance identifier in the infrared code data is equal to the expected functional identifier of the control, the name field in the infrared code data is further checked to see if it is empty, if the field identifier is empty, or if the name field is consistent with the display name of the control. If any of the above verification conditions are met, the matching is determined to be successful. Second matching step: If the first matching step fails to determine a successful match, then text matching is performed based on the name field; The bound control command is sent to the infrared relay device to control the target infrared device; or, when a control command containing numerical parameters is received, the allowable range of the numerical parameters is read. If the numerical parameters exceed the allowable range, they are corrected to a preset value, and the corrected control command is sent to the infrared relay device to control the target infrared device.

2. The method according to claim 1, characterized in that, The standard function filter table is pre-installed in local memory, and the general function identifier includes at least one of the power function identifier, volume function identifier, and channel function identifier.

3. The method according to claim 1, characterized in that, The step of dynamically generating interface controls based on the description information corresponding to the function instance identifier includes: constructing a function action object based on the description information, encapsulating the description information into a button name, and rendering the corresponding click event control in the extended area of ​​the user interface.

4. The method according to claim 1, characterized in that, The text matching based on the name field includes: comparing the name field in the infrared code data with the display name of the control; if the two match, the match is considered successful.

5. The method according to claim 1, characterized in that, The text matching based on the name field includes: using a fuzzy string matching algorithm to calculate the similarity between the name field in the infrared code data and the display name of the control; if the similarity exceeds a preset threshold, the match is considered successful.

6. The method according to claim 1, characterized in that, The numerical parameters include the air conditioning temperature setting value, the allowable range is obtained from the protocol description file according to the current working mode, and the preset value is a preset default temperature value.

7. The method according to claim 1, characterized in that, It also includes a multilingual support step: selecting the text of the corresponding language from the description information based on the current language environment as the display name of the dynamically generated interface control; if the text of the current language environment is missing, it will fall back to the default language text.

8. The method according to claim 1, characterized in that, It also includes an icon mapping step: allocating locally preset icon resources to dynamically generated interface controls based on the category field or icon keyword corresponding to the function instance identifier.

9. A terminal device, characterized in that, It includes a processor and a memory, the memory storing a computer program that, when executed by the processor, implements the method as described in any one of claims 1 to 8.

10. An infrared transponder device, characterized in that, include: A communication interface for receiving infrared control commands from a terminal device, wherein the infrared control commands are generated by the terminal device executing the method of any one of claims 1 to 8; An infrared transmitter is used to convert the infrared control commands into infrared signals and send them to the target infrared device.

Images