An integrated method and system of an intelligent touch screen of an electric door and window

Abstract

This application provides an integrated method and system for an intelligent touchscreen control for electric windows and doors, applied in the field of intelligent window and door control technology. By acquiring window type information from the electric window actuator and dynamically loading matching software control logic modules and user interface elements based on this information, the method converts user operation information into control commands recognizable by the electric window actuator and receives status feedback. Furthermore, the control capabilities of the electric window actuator are encapsulated into a virtual device interface recognizable by third-party intelligent control systems, greatly enhancing the system's openness and compatibility. Therefore, this method, through a unified intelligent touchscreen, allows users to intuitively and conveniently control all electric windows and doors, significantly improving the user experience. Simultaneously, it reduces the types of accessories, simplifies production, debugging, and inventory management processes, and lowers costs. The unified appearance design also enhances the overall aesthetics of the product.

Description

Technical Field

[0001] This application relates to the field of intelligent door and window control technology, and in particular to an integration method and system for an intelligent touch screen for electric doors and windows. Background Technology

[0002] In modern product design, to enhance user experience and functional integration, multiple subsystems with similar functions but different implementations are often integrated into a single product framework. However, this integration often leads to increased control complexity, especially when independent control and management of each subsystem is required. The traditional approach is to equip each subsystem with a separate control unit and sensor, but this not only results in a wide variety of accessories and inconsistent appearances but also presents numerous challenges to product manufacturing, debugging, inventory management, and on-site installation.

[0003] For example, consider a product that integrates various types of motorized windows, such as motorized lift windows, motorized casement windows, and motorized top-hung windows. Current solutions require installing diverse control panels for these window types; some are controlled via wall panels, others by remote controls, and still others may require built-in applications. These control panels vary in appearance and style, and their corresponding sensors also differ. Based on this, this product faces several challenges in practical application: First, the wide variety of control components undoubtedly increases the learning burden and time cost for workshop debugging personnel; second, warehouse inventory management becomes more difficult due to the need to manage and differentiate between various component models; third, the inconsistent appearance of the control panels and sensors affects the overall aesthetics of the window; and fourth, complex wiring issues frequently arise during on-site installation, further complicating installation management.

[0004] In response to the above situation, the industry is exploring a new solution: designing a smart touchscreen based on a universal signal platform that can control all electric doors and windows. This screen aims to integrate the control protocols of all electric products, achieving unified control of all electric doors and windows through interface switching, while also easily connecting to third-party smart control systems. In terms of appearance, it strives for a unified style, thereby solving the problems of numerous control panels and sensors, as well as installation and wiring difficulties.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] In view of the shortcomings of the prior art, this application provides an integrated method and system for intelligent touch screens of electric doors and windows, aiming to solve the problems of passive, inflexible, easily damaged and inadequate emergency handling capabilities of infrared sensing devices in existing intelligent doors and windows.

[0007] In a first aspect, a method for integrating an intelligent touchscreen for electric doors and windows is provided, the method comprising the steps of:

[0008] S1: Obtain window type information from the motorized window actuator connected to the smart touchscreen;

[0009] S2: Based on the window type information, identify the window type corresponding to the electric window actuator, and dynamically load the software control logic module that matches the window type and generate the corresponding user interface elements;

[0010] S3: Obtain user operation information on the user interface element;

[0011] S4: Convert the operation information into a control command that the electric window actuator can recognize, and receive the status information fed back by the electric window actuator in response to the control command;

[0012] S5: Update the user interface elements to display the status information, and encapsulate the control capabilities of the electric window actuator into a virtual device interface recognizable by a third-party intelligent control system.

[0013] This technical solution enables unified intelligent control of electric doors and windows of different window types, simplifies the control system, enhances the user experience, and facilitates integration with third-party smart home systems.

[0014] Furthermore, step S2 includes:

[0015] S21: Identify the window type corresponding to the electric window actuator based on the window type information;

[0016] S22: Decompose the software control logic modules and user interface elements that match the window type according to the functional level, and repackage them into basic display modules and functional operation modules;

[0017] S23: Prioritize loading the basic display modules of all identified window types to generate the initial user interface. The basic display modules contain window type identification information and basic status display elements.

[0018] S24: Based on the user's operation on the initial user interface, dynamically load the functional operation module and detailed user interface elements corresponding to the specific window type; the specific window type is the window type selected by the user in the operation on the initial user interface;

[0019] S25: Monitor system resource usage. When the system resources are below a preset threshold, unload functional operation modules that have not been used for a long time to release the system resources.

[0020] This technical solution enables optimized management of system resources, and effectively improves system operating efficiency and response speed by dynamically loading and unloading modules.

[0021] Furthermore, step S25 includes:

[0022] S251: Configure the functional priority of each functional operation module;

[0023] S252: Record the last usage time of each functional operation module;

[0024] S253: Monitor system resource usage. When the system resources are lower than the preset threshold, determine the unused functional operation modules to be uninstalled based on the functional priority of the functional operation modules and the last usage time of the functional operation modules. When determining the unused functional operation modules to be uninstalled, exclude modules with high functional priority.

[0025] S254: Execute the uninstallation operation of the unused function operation module to be uninstalled for a long time, so as to release the system resources.

[0026] This technical solution enables more refined system resource management, ensuring the stable operation of high-priority functional modules while effectively releasing unnecessary resource consumption.

[0027] Furthermore, step S3 includes:

[0028] S31: Collect the touch point position, touch time, touch pressure, and number of touch points on the touch screen to obtain the raw touch information;

[0029] S32: Based on the original touch information, analyze the movement trajectory and duration of a single touch point, as well as the number, relative position changes, and duration of multiple touch points, to obtain multi-touch gestures;

[0030] S33: Calculate the moving speed and moving distance of a single touch point based on its movement trajectory and continuous touch time. When the moving speed of the single touch point exceeds a preset speed threshold and the moving distance of the single touch point exceeds a preset distance threshold, identify the single touch point as a rapid sliding action.

[0031] S34: When the continuous touch time of the single touch point exceeds a preset time threshold, the single touch point is identified as a long press action;

[0032] S35: Based on the identified fast swipe action, long press action, or multi-touch gesture, the corresponding advanced operation intent of the window is parsed to obtain the user's operation information on the user interface element.

[0033] This technical solution enables accurate recognition and analysis of complex user touch gestures, thereby supporting richer advanced window operations and improving the convenience and intelligence of user interaction.

[0034] Furthermore, step S35 includes:

[0035] S351: When the rapid swipe action, the long press action, or the multi-touch gesture is identified, obtain the window type of the electric window actuator that performs the gesture and the current operation context parameters;

[0036] S352: Based on the quick swipe action, the long press action, or the multi-touch gesture, the window type, and the current operation context parameters, parse the corresponding advanced operation intent of the window;

[0037] S353: The advanced operation intent of the window is used as the operation information of the user on the user interface element.

[0038] Furthermore, step S352 includes:

[0039] S3521: Preset judgment logic structure, the judgment logic structure includes judgment node and result node, the judgment node is used to evaluate gesture, window type and current operation context parameters, the result node stores the window's advanced operation intent;

[0040] S3522: Based on the identified fast swipe action, the long press action, or the multi-touch gesture, the window type, and the current operation context parameters, the judgment is performed starting from the initial judgment node of the judgment logic structure;

[0041] S3523: Based on the conditions set by the judgment node, evaluate the identified fast swipe action, long press action, or multi-touch gesture, the window type, and the current operation context parameters, and select the corresponding branch path;

[0042] S3524: Perform the evaluation and branch path selection operations sequentially until the result node is reached, and obtain the corresponding window advanced operation intent from the result node.

[0043] Furthermore, step S4 includes:

[0044] S41: Based on the window type information, search for the communication protocol and instruction set corresponding to the electric window actuator from the preset protocol mapping table;

[0045] S42: Based on the communication protocol and instruction set, convert the operation information into control instructions recognizable by the electric window actuator;

[0046] S43: Send the control command to the electric window actuator and receive the status information in the original format from the electric window actuator in response to the control command;

[0047] S44: Convert the original format status information fed back by the electric window actuator into status information in a general status data format.

[0048] Furthermore, step S5 includes:

[0049] S51: Update the user interface elements to display the status information;

[0050] S52: Obtain the control capability of the electric window actuator and map the control capability to a standard virtual device type defined in a preset universal smart home protocol;

[0051] S53: Generate a virtual device interface that conforms to the standard virtual device type protocol specification based on the standard virtual device type.

[0052] Furthermore, step S52 includes:

[0053] S521: First functional characteristic for acquiring the control capability of the electric window actuator;

[0054] S522: Obtain the second functional characteristics of the standard virtual device type defined in the preset universal smart home protocol;

[0055] S523: Match the first functional characteristic with the second functional characteristic, and determine the optimal mapping relationship between the control capability of the electric window actuator and the standard virtual device type based on the matching result, thereby mapping the control capability to the standard virtual device type defined in the preset universal smart home protocol.

[0056] Secondly, an integrated system for an intelligent touch screen for electric doors and windows, used to implement any of the methods described above:

[0057] First acquisition module: Acquires window type information of the electric window actuator connected to the smart touch screen;

[0058] Identification module: Based on the window type information, identify the window type corresponding to the electric window actuator, and dynamically load the software control logic module that matches the window type and generate the corresponding user interface elements;

[0059] Second acquisition module: Acquires user operation information on the user interface elements;

[0060] Conversion module: converts the operation information into control commands that the electric window actuator can recognize, and receives status information from the electric window actuator in response to the control commands;

[0061] Encapsulation module: Updates the user interface elements to display the status information, and encapsulates the control capabilities of the electric window actuator into a virtual device interface that can be recognized by a third-party intelligent control system.

[0062] Beneficial Effects: This application proposes an integrated method and system for intelligent touch screens of electric windows and doors. By acquiring window type information of the electric window actuator and dynamically loading matching software control logic modules and user interface elements based on the window type information, it achieves unified management and control of electric windows and doors of different window types. Furthermore, this method ensures the accuracy and real-time performance of control by converting user operation information into control commands recognizable by the electric window actuator and receiving status feedback. In addition, encapsulating the control capabilities of the electric window actuator into a virtual device interface recognizable by a third-party intelligent control system greatly enhances the system's openness and compatibility. Therefore, the method of this application effectively solves problems such as a wide variety of control accessories, inconsistent appearance, complex production and debugging, difficult inventory management, and complex on-site installation and wiring. Through a unified intelligent touch screen, users can intuitively and conveniently control all electric windows and doors, significantly improving the user experience. At the same time, it reduces the types of accessories, simplifies production, debugging, and inventory management processes, and reduces costs. The unified appearance design also enhances the overall aesthetics of the product. Attached Figure Description

[0063] Figure 1 This is a flowchart illustrating the integration method of an intelligent touch screen for electric doors and windows proposed in this application.

[0064] Figure 2 This is a structural diagram of an integrated system for an intelligent touch screen for electric doors and windows proposed in this application.

[0065] Figure 3 This is a simplified schematic diagram of an integrated system for an intelligent touch screen for electric doors and windows proposed in this application.

[0066] Labeling explanation: 201, First acquisition module; 202, Identification module; 203, Second acquisition module; 204, Conversion module; 205, Encapsulation module. Detailed Implementation

[0067] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and marked in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0068] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0069] Please refer to Figure 1 A method for integrating an intelligent touch screen for electric doors and windows, the method comprising the following steps:

[0070] S1: Obtain window type information from the motorized window actuator connected to the smart touchscreen;

[0071] S2: Based on the window type information, identify the window type corresponding to the electric window actuator, and dynamically load the software control logic module that matches the window type and generate the corresponding user interface elements;

[0072] S3: Obtain user interaction information on user interface elements;

[0073] S4: Convert the operation information into control commands that the electric window actuator can recognize, and receive the status information fed back by the electric window actuator in response to the control commands;

[0074] S5: Update user interface elements to display status information and encapsulate the control capabilities of the electric window actuator into a virtual device interface that can be recognized by third-party intelligent control systems.

[0075] In modern product design, to enhance user experience and functional integration, multiple subsystems with similar functions but different implementations are often integrated into a single product framework. However, this integration often leads to increased control complexity, especially when each subsystem needs independent control and management. The traditional approach is to equip each subsystem with a separate control unit and sensor, but this not only results in a wide variety of accessories and inconsistent appearances but also presents numerous challenges to product manufacturing, debugging, inventory management, and on-site installation. For example, consider a current product that integrates various types of electric windows, such as electric lift windows, electric casement windows, and electric top-hung windows. According to existing solutions, various control panels need to be installed for these window types; some are controlled via wall-mounted panels, some via remote controls, and others may require control via built-in applications. These control panels vary in appearance and style, and their corresponding sensors also differ. Based on the above, this product will face a series of problems in practical applications: First, the variety of control accessories undoubtedly increases the learning burden and time cost for workshop debugging personnel; second, the difficulty of warehouse inventory management also increases, as it is necessary to manage and distinguish various different models of accessories; at the same time, the inconsistent appearance of the control panel and sensors will affect the overall aesthetics of the window; in addition, complex wiring problems often occur during on-site installation, increasing the difficulty of installation management.

[0076] In response, this application proposes an integration method for an intelligent touch screen for electric doors and windows, aiming to achieve centralized management and control of various electric window actuators through a unified intelligent touch screen.

[0077] Among them, intelligent touch screens refer to devices that integrate touch input and display output functions, and can serve as the center for users to interact with electric door and window systems.

[0078] Electric window actuators are mechanical devices that drive electric doors and windows to open, close, or adjust their position. They come in many types, including but not limited to electric lift windows, electric casement windows, and electric top-hung windows. Window type information refers to data describing the specific type, size, and functional characteristics of the electric window actuator, such as "electric casement window, 1200 mm wide, 1500 mm high, maximum opening angle 90 degrees, using a push rod motor, supports automatic closing based on wind and rain sensors, and has an anti-pinch function," etc.

[0079] The software control logic module is program code written for a specific window type, used to process the control commands, status feedback and implement its unique functions.

[0080] User interface elements are graphical components displayed on a smart touchscreen, such as buttons, sliders, and text boxes, for users to interact with and view status.

[0081] Third-party intelligent control systems refer to smart home or building automation systems that are independent of this integration method, such as smart speakers and smart central control screens. They can interact with this integration method through virtual device interfaces to achieve remote or automated control of electric doors and windows.

[0082] In step S1, window type information can be obtained in various ways. For example, the smart touch screen can establish communication with the motorized window actuator via a wired connection (such as RS485, CAN bus) or a wireless connection (such as Wi-Fi, Bluetooth, Zigbee), and actively query information such as the actuator's model and serial number. Then, it parses the corresponding window type according to a preset database or configuration file. As a preferred embodiment, the motorized window actuator can automatically broadcast its window type information to the smart touch screen upon initial connection or startup. Alternatively, a manual configuration interface can be provided on the smart touch screen, allowing installers or users to manually input or select the window type of the motorized window actuator.

[0083] In step S2, in practical applications, when the smart touchscreen obtains the window type information as "electric lift window," the system identifies the window type and retrieves and loads the software control logic module specifically for controlling electric lift windows from local storage or the cloud server. Simultaneously, the system generates a set of user interface elements including "Up," "Down," and "Stop" buttons, as well as a slider or text box displaying the current window position. If the window type information is "electric casement window," the corresponding casement window control logic module is loaded, and user interface elements including "Open," "Close," and "Stop" are generated. This dynamic loading mechanism ensures that the smart touchscreen can flexibly adapt to different window types, avoiding the resource waste caused by preloading all modules.

[0084] In step S3, users can operate the smart touchscreen in various ways. For example, users can directly tap the "Up" button on the screen to control the electric window to rise, or drag the slider to adjust the window's opening degree. Additionally, users can operate using multi-touch gestures, such as pinching with two fingers to close the window, or quickly swiping with a single finger to open or close the window. This operation information is captured and parsed by the smart touchscreen's touch event processing system.

[0085] In step S4, protocol conversion is required because different motorized window actuators may use different communication protocols and instruction sets. For example, if the user clicks the "Up" button on the interface, the smart touchscreen will convert the operation information into a specific binary instruction or string command that the actuator can understand, based on the type of the currently connected motorized window actuator. This instruction is sent to the motorized window actuator through the communication interface. After executing the instruction, the motorized window actuator will feed back its current status (e.g., window position, operating status, fault information, etc.) to the smart touchscreen through the communication interface.

[0086] In step S5, in practical applications, for example, when the electric window actuator reports its current position as "50% open," the slider on the smart touchscreen will move accordingly to the 50% position and may display a "half-open" text prompt. Simultaneously, to achieve interoperability with third-party smart control systems, this method abstracts the control capabilities of the electric window actuator (e.g., opening, closing, adjusting position, etc.) and encapsulates them into virtual device interfaces conforming to common smart home protocols (such as MQTT, HomeKit, Matter, etc.). Therefore, third-party smart control systems can remotely control and query the status of the electric window by calling these virtual device interfaces without needing to understand the specific communication protocols and instruction sets of the underlying electric window actuator. Specifically, the heterogeneous features of the electric window actuator at the physical layer, link layer, and instruction layer are semantically stripped and normalized and encapsulated, so that its original control capability set {specific communication protocol frames, vendor-specific instruction sets, and hardware interface parameters} is mapped into a set of general semantic models that are independent of protocols, vendors, and window types. This model only retains standard operation primitives such as "open, close, pause, set opening degree, and query status" and their corresponding finite state sets, and exposes them to the outside world in the form of virtual device interfaces that conform to general smart home protocol specifications such as MQTT, HomeKit, and Matter.

[0087] Through this abstraction process, third-party intelligent control systems can directly call the virtual device interface with unified semantics to complete remote control and status query of electric windows without parsing or adapting to the private protocols and instruction formats of any underlying actuators.

[0088] In addition, this method can also be applied to various electric doors. It only requires writing program code specifically designed for the door type into the software control logic module to handle the control commands, status feedback and implement the unique functions of various electric doors (such as electric swing doors, electric sliding doors, etc.).

[0089] The integrated method for intelligent touch screens for electric doors and windows proposed in this application demonstrates a significant technological contribution in solving many problems existing in the prior art. In traditional solutions, different window types require their own independent control panels and sensors, resulting in a wide variety of accessories, complex inventory management, inconsistent appearance, and difficulties in installation and wiring. The core innovation of this application lies in introducing a unified intelligent touch screen as the control center and employing dynamic loading and virtual device encapsulation technologies to completely change this fragmented control mode.

[0090] Compared with existing technologies, the advantages of this application are:

[0091] Firstly, regarding window type adaptation, existing technologies typically require pre-setting or hard-coding control logic and interfaces for each window type. This application, however, obtains window type information in step S1 and dynamically loads matching software control logic modules and user interface elements based on the window type information in step S2. This dynamic adaptation mechanism gives the system extremely high flexibility and scalability, eliminating the need to redevelop or update the entire system for each new window type; only the corresponding modules need to be added, significantly reducing development and maintenance costs.

[0092] Secondly, regarding user experience, existing technologies may require users to interact with various control panels with vastly different styles. This application, however, provides a consistent user interface through a unified smart touchscreen, allowing users to operate on a familiar interface regardless of the window type being controlled. Step S3 acquires user operation information and, combined with the instruction conversion and status update in steps S4 and S5, provides users with intuitive and real-time feedback, significantly improving the user experience.

[0093] Furthermore, in terms of system integration, existing technologies often struggle to seamlessly interface with third-party intelligent control systems. This application, through step S5, encapsulates the control capabilities of the electric window actuator into a virtual device interface recognizable by the third-party intelligent control system, enabling the electric door and window system to easily integrate into the smart home ecosystem. This encapsulation not only simplifies the integration difficulty of third-party systems but also provides users with richer intelligent control options, such as controlling windows via voice assistants or linking with other smart devices.

[0094] In summary, the integration method of this application effectively solves the problems of numerous accessories, complex management, inconsistent appearance, and integration difficulties in traditional electric door and window control solutions through innovative technologies such as dynamic adaptation, unified interface, and virtual device encapsulation. It provides an efficient, flexible, and user-friendly solution for the intelligent control of electric doors and windows.

[0095] Furthermore, step S2 includes:

[0096] S21: Identify the window type corresponding to the electric window actuator based on the window type information;

[0097] S22: Decompose the software control logic modules and user interface elements that match the window type according to the functional level, and repackage them into basic display modules and functional operation modules;

[0098] S23: Prioritize loading the basic display modules of all identified window types to generate the initial user interface. The basic display modules contain window type identification information and basic status display elements.

[0099] S24: Based on the user's actions on the initial user interface, dynamically load the functional operation modules and detailed user interface elements corresponding to the specific window type; the specific window type is the window type selected by the user in the initial user interface.

[0100] S25: Monitor system resource usage. When system resources are below a preset threshold, uninstall functional operation modules that have not been used for a long time to release system resources.

[0101] Specifically, in step S22, the functionality can be broken down into three dimensions. The first is the functional dimension: modules that only provide read-only status feedback and do not require user intervention for adjustable parameters are classified as basic display modules; modules that require adjustable parameters, configurable strategies, or additional user interaction processes are classified as functional operation modules. The second is the resource dimension: modules that consume less system storage, memory, and rendering resources than a preset threshold are classified as basic display modules; modules that consume more than the threshold are classified as functional operation modules. The third is the timing dimension: modules that need to be loaded and presented within the t0-t1 time period of interface initialization are classified as basic display modules; modules that can be loaded only after a user triggers an event are classified as functional operation modules.

[0102] The basic display module refers to the core component that provides window type identification information and basic status display elements, such as the window's open / closed status and position information. Its purpose is to ensure that users can quickly obtain a basic overview of the window.

[0103] The functional operation module can be understood as a component that provides more advanced and refined control functions, such as setting the ventilation mode of the window, adjusting the anti-pinch function, and linkage control options. Its purpose is to provide a richer operating experience when the user needs it.

[0104] Step S23 ensures that the touchscreen can quickly present a usable interface containing basic information when starting up or switching interfaces, avoiding long waiting times for the user. The basic display module is typically small in size, loads quickly, and can rapidly provide window type identification information and basic status display elements, such as displaying icons for different window types and their current open / closed status.

[0105] In step S24, the system only loads the specific functional modules corresponding to a window type on demand when the user explicitly selects a window type and attempts to perform advanced operations, thereby avoiding unnecessary resource consumption. For example, when the user clicks the icon of a window, the detailed control interface and functional modules related to that window will be loaded.

[0106] In step S25, as a preferred implementation, the system continuously monitors system resource usage. When system resources fall below a preset threshold, the system will unload functional operation modules that have not been used for a long time to release system resources. This mechanism aims to achieve dynamic optimization management of system resources, ensuring that the system always maintains a high-efficiency operating state and avoiding resource waste caused by loading too many infrequently used functional modules.

[0107] Suppose an integrated system with a smart touchscreen connects to various types of motorized window actuators, including casement windows, sliding windows, and skylights. When the smart touchscreen is activated, it first identifies the window type corresponding to all connected motorized window actuators. Next, the system categorizes the software control logic modules and user interface elements matching these window types into basic display modules and functional operation modules. For example, the basic display module for a casement window might contain a simple window icon and an "open / closed" status indicator, while its functional operation module might include advanced functions such as "ventilation mode" and "micro-opening angle adjustment."

[0108] Subsequently, the system prioritizes loading the basic display modules for all identified window types. This means that on the touchscreen, the user will quickly see simple icons for all casement windows, sliding windows, and skylights, along with their current basic status (e.g., all closed), forming an initial user interface. At this point, advanced functional modules have not yet been loaded, and system resource usage is low.

[0109] When a user clicks on the icon of a casement window on the initial user interface, the system dynamically loads the corresponding functional operation modules and detailed user interface elements based on the user's action. At this time, the screen displays the detailed control interface for that casement window, including advanced operation options such as "ventilation mode" and "micro-opening angle adjustment." If the user does not perform any operation on the sunroof for an extended period, the system monitors system resource usage and intelligently unloads the functional operation modules corresponding to the sunroof when resources fall below a preset threshold, thus freeing up system resources and ensuring the smooth operation of the overall system. In this way, the system can dynamically adjust resource allocation according to actual needs, providing an efficient and responsive user experience.

[0110] Furthermore, step S25 includes:

[0111] S251: Configure the functional priority of each functional operation module;

[0112] S252: Record the last usage time of each functional operation module;

[0113] S253: Monitor system resource usage. When system resources are below a preset threshold, determine the unused functional operation modules to be uninstalled based on their functional priority and last usage time. When determining the unused functional operation modules to be uninstalled, exclude modules with high functional priority.

[0114] S254: Execute the uninstallation operation of the unused function operation module to free up system resources.

[0115] Specifically, in step S251, configuring the functional priority of each functional operation module refers to setting an importance level for each functional operation module. For example, it can be divided into three levels: "high," "medium," and "low," or it can be quantified numerically. The purpose is to distinguish the criticality of different modules in system operation. This priority can be preset during module development or configured by the administrator according to actual needs after system deployment.

[0116] In step S252, the last usage time of each functional operation module is recorded. This can be understood as the system continuously tracking the timestamp of the last time each loaded functional operation module was activated or called by the user. The purpose is to provide a quantitative basis for judging whether a module has been "unused for a long time".

[0117] In practical applications, in step S253, the system can set a "long-term inactivity" time threshold and prioritize uninstalling modules whose last inactivity time exceeds this threshold and which have lower functional priority. When determining the modules to be uninstalled, the system strictly excludes modules marked as high functional priority; even if these high-priority modules have not been used for a long time, they will not be uninstalled to ensure the continued availability of core functions. Therefore, in step S254, performing the uninstallation operation of the long-term inactive functional operation modules means that the system will safely remove the selected functional operation modules from memory based on the judgment result of S253, thereby reclaiming the system resources they occupy.

[0118] In some preferred embodiments, it is assumed that the smart touchscreen connects to multiple window types and loads corresponding functional operation modules, such as a "ventilation mode control module," a "privacy mode control module," an "emergency shutdown module," and a "custom scene setting module." The system configures these modules with different functional priorities: for example, the "emergency shutdown module" is configured with high priority (to handle emergencies and must always be available); the "ventilation mode control module" and "privacy mode control module" are configured with medium priority; and the "custom scene setting module" is configured with low priority. The system continuously records the last usage time of each module. When the system detects that memory resources are below a preset threshold, it initiates a module uninstallation process. At this time, if the "custom scene setting module" and the "ventilation mode control module" have been inactive for a long time (e.g., more than 30 minutes), and the "emergency shutdown module" has also been inactive for a long time, the system will make a judgment based on functional priority and last usage time. Specifically, the system will prioritize uninstalling the "custom scene setting module" because it has the lowest functional priority and has not been used for a long time. Even if the "emergency shutdown module" has not been used for an extended period, because it is configured with high priority, the system will exclude it from the uninstallation list, ensuring it is always loaded to handle emergencies. In this way, the system can intelligently preserve critical functions while freeing up resources, avoiding the impact of resource constraints on the availability of core system functions.

[0119] Furthermore, step S3 includes:

[0120] S31: Collect the touch point position, touch time, touch pressure, and number of touch points on the touch screen to obtain the raw touch information;

[0121] S32: Based on the original touch information, analyze the movement trajectory and duration of a single touch point, as well as the number, relative position changes, and duration of multiple touch points, in order to obtain multi-touch gestures;

[0122] S33: Calculate the moving speed and moving distance of a single touch point based on its movement trajectory and continuous touch time. When the moving speed of a single touch point exceeds a preset speed threshold and the moving distance of a single touch point exceeds a preset distance threshold, identify the single touch point as a fast swipe action.

[0123] S34: When the continuous touch time of a single touch point exceeds a preset time threshold, the single touch point is identified as a long press action;

[0124] S35: Based on the identified fast swipe, long press, or multi-touch gestures, the corresponding advanced operation intent of the window is parsed to obtain the user's operation information on the user interface elements.

[0125] Specifically, in step S31, the raw touch information refers to the underlying data that the touchscreen can directly obtain when it receives a user touch. This data includes, but is not limited to, the coordinates of the touch point on the screen, the timestamp from the start to the end of the touch, the force applied by the touch point to the screen (touch pressure), and the number of touch points present simultaneously. This raw data is the basis for subsequent recognition of complex gestures.

[0126] Furthermore, in step S32, multi-touch gestures refer to collaborative operations performed by the user on the screen using two or more touch points. For example, gestures such as zooming and rotating can be identified by analyzing changes in distance (pinch or open), relative position movement (rotation), and duration between two touch points. For a single touch point, its movement trajectory and duration of touch are key to recognizing basic actions such as swiping and clicking.

[0127] In step S33, a rapid swipe action refers to a user making a single-point swipe on the screen at a relatively fast speed and over a certain distance. The preset speed threshold and preset distance threshold are parameters pre-set by the system to distinguish between rapid swipes and normal dragging or slight movements. For example, when a user quickly swipes a distance across the screen, the system will recognize it as a rapid swipe, which typically corresponds to the rapid opening or closing of a window.

[0128] In practical applications, in step S34, a long press action refers to a user holding a single touch point on a certain position on the screen for an extended period of time. The preset time threshold is a parameter used to distinguish between a long press and a regular click. For example, when a user long presses a window icon, the system can recognize it as a long press action, which might correspond to a pop-up window's detailed control menu or entering the window's fine-tuning mode.

[0129] Therefore, in step S35, advanced window operation intent refers to complex control commands that go beyond simple switches, expressed by the user through the aforementioned quick swipe, long press, or multi-touch gestures. For example, a quick swipe might indicate "fully open" or "fully close," a long press might indicate "enter ventilation mode" or "lock window," and a multi-touch gesture (such as pinching) might indicate "adjust window opening angle to 50%." These advanced operation intents enable users to control motorized doors and windows in a more intuitive and efficient manner.

[0130] Furthermore, step S35 includes:

[0131] S351: When a fast swipe action, long press action or multi-touch gesture is recognized, obtain the window type of the motorized window actuator that the gesture is applied to and the current operation context parameters;

[0132] S352: Based on the quick swipe action, long press action or multi-touch gesture, window type and current operation context parameters, the corresponding advanced operation intent of the window is parsed;

[0133] S353: Treat window advanced operation intents as user operation information on user interface elements.

[0134] Specifically, in step S351, after the system successfully recognizes the user's rapid swipe, long press, or multi-touch gesture on the touchscreen, it needs to further acquire contextual information related to the object of the gesture. Here, "the window type of the motorized window actuator acting on the gesture" refers to the specific type of motorized window the user is currently operating, such as casement window, sliding window, top-hung window, bottom-hung window, blinds, skylight, etc. This window type information can be acquired and stored during system initialization through steps S1 and S2, and can be queried based on the motorized window actuator associated with the user interface element during user operation. "Current operating context parameters" can be understood as external or internal environmental factors affecting window operation, such as the current window opening status (fully open, half open, closed), external weather information (rain, wind, sunny), indoor temperature, humidity, light intensity, etc. These context parameters can be acquired through sensor data, system preset values, or external smart home system interfaces.

[0135] In step S352, the system comprehensively considers the recognized gesture, the acquired window type, and the current operation context parameters to parse a more accurate and user-expected "advanced window operation intent." For example, a "rapid swipe action" might be interpreted as "fully open" on a casement window, but as "leaf fully open" or "leaf fully closed" on a venetian blind. Similarly, if the current operation context parameters indicate that it is raining, even if a "fully open" gesture is recognized, the system might interpret it as "slightly open for ventilation" or "keep closed" to prevent rainwater from entering. This comprehensive analysis of multi-dimensional information enables the system to more intelligently understand the user's true intent.

[0136] In step S353, the "advanced window operation intent" obtained through the above comprehensive analysis will be passed to the subsequent control command conversion module as the final user operation information. This operation information is no longer a simple gesture recognition result, but includes the specific window state or action that the user expects to achieve for a specific window type in a specific context.

[0137] Through the above technical solution, the present application can significantly improve the understanding accuracy and intelligence level of the electric window intelligent touch screen for the user's operation intention. Compared with the solution that only relies on gesture recognition, by comprehensively considering the window type and the current operation context parameters, the system can perform differential and context-based parsing of the same user gesture according to different window characteristics and environmental changes. Thus, the user can achieve precise window control through intuitive touch operations without having to memorize complex gesture combinations or make multiple attempts, greatly improving the operation convenience and the satisfaction of the user experience. In addition, this intelligent intention parsing ability also lays the foundation for realizing higher-level automation and linkage control, such as automatically adjusting the window opening angle in rainy weather or automatically adjusting the louver blade angle according to the indoor temperature, thereby further enhancing the overall efficiency and comfort of the smart home system.

[0138] Further, step S352 includes:

[0139] S3521: Preset a judgment logic structure. The judgment logic structure includes judgment nodes and result nodes. The judgment nodes are used to evaluate gestures, window types, and current operation context parameters, and the result nodes store the high-level operation intentions of the window.

[0140] S3522: Start judgment from the starting judgment node of the judgment logic structure according to the recognized quick sliding action, long press action, or multi-touch gesture, window type, and current operation context parameters.

[0141] S3523: Evaluate the recognized quick sliding action, long press action, or multi-touch gesture, window type, and current operation context parameters according to the conditions set by the judgment nodes, and select the corresponding branch path.

[0142] S3524: Sequentially execute the operations of evaluation and selection of branch paths until reaching the result node, and obtain the corresponding high-level operation intention of the window from the result node.

[0143] Specifically, the judgment logic structure can be understood as a decision tree, designed to systematically process complex input combinations to achieve accurate parsing of user operation intentions. The judgment nodes are key links in the decision-making process; each node is configured with specific evaluation conditions to logically judge input actions such as quick swipes, long presses, multi-touch gestures, window types, and current operation context parameters. For example, one judgment node might evaluate whether the gesture is a "quick upward swipe," another might evaluate whether the window type is a "skylight," and yet another might evaluate whether the current operation context parameter indicates "rain mode." The result nodes are located at the end of the judgment logic structure. Each result node stores a specific, predefined advanced window operation intention, such as "fully open," "half-open for ventilation," "close and lock," or "anti-pinch back."

[0144] In practical applications, the judgment logic structure can be pre-designed and stored in the system's configuration module to adapt to different application scenarios and user needs. The initial judgment node is the entry point for the decision-making process, where the system begins to parse the user's operation intent. Based on the conditions set at the judgment node, the system evaluates the currently identified rapid swipe actions, long press actions or multi-touch gestures, window type, and current operation context parameters, and selects one or more corresponding branch paths based on the evaluation results. For example, if the evaluation result is true, it proceeds along the "yes" branch path; if it is false, it proceeds along the "no" branch path. The sequential execution of evaluation and branch path selection means that the system traverses subsequent judgment nodes level by level along the selected branch path until it finally reaches a result node. Once the result node is reached, the high-level operation intent of the window stored therein is extracted and used as the final parsing result.

[0145] In some preferred embodiments, it is assumed that a user performs a "quick swipe up" gesture on a "sliding window" on a smart touch screen, and the current operation context parameter is displayed as "ventilation mode".

[0146] First, the system will identify the gesture as a quick swipe action according to the above steps S31 to S34, and obtain that the window type of the electric window actuator is a sliding window, and the current operation scenario parameter is ventilation mode.

[0147] Next, the system will begin its judgment from the starting judgment node of the preset judgment logic structure.

[0148] For example, the first decision node might evaluate whether the gesture is a rapid swipe. If the recognition result is yes, the system proceeds along the "yes" branch path.

[0149] The second decision node might evaluate whether the window type is a sliding window. Since the recognition result is yes, the system continues along the "yes" branch path.

[0150] The third decision node might assess whether the current situation is in ventilation mode. Since the identification result is yes, the system proceeds along the "yes" branch path again.

[0151] Finally, the system reaches a result node that stores the advanced operation intent of the window as "sliding window half open for ventilation".

[0152] Thus, the advanced window operation intent "sliding window half-open for ventilation" was successfully parsed and interpreted as user operation information on the user interface element, and then converted into a control command recognizable by the motorized window actuator to achieve the half-open ventilation operation of the window. This example demonstrates how a judgment logic structure maps complex combinations of inputs to precise advanced window operation intents through a series of organized evaluations, thereby achieving intelligent and refined window control.

[0153] Furthermore, step S4 includes:

[0154] S41: Based on the window type information, search the preset protocol mapping table for the communication protocol and instruction set corresponding to the electric window actuator;

[0155] S42: Based on the communication protocol and instruction set, convert the operation information into control instructions that the electric window actuator can recognize;

[0156] S43: Send control commands to the electric window actuator and receive status information in raw format from the electric window actuator in response to the control commands;

[0157] S44: Convert the raw status information fed back by the electric window actuator into status information in a general status data format.

[0158] In step S41, the window type information refers to the specific type information of the electric window actuator obtained in step S1, such as casement window, sliding window, skylight, etc. The preset protocol mapping table can be a database or configuration file stored inside the smart touchscreen, containing communication protocols (such as RS485, CAN, Zigbee, Wi-Fi, etc.) and instruction sets (such as specific commands like open, close, stop, and percentage opening / closing) corresponding to different window types. Through the window type information, the system can accurately find the specific protocol and instruction format required to communicate with the currently connected electric window actuator.

[0159] In step S42, the operation information is the user's operation on the user interface element obtained in step S3, such as "fully open," "half-close," or "stop." The system will translate these abstract user operation intentions into control instructions in binary or text format that the motorized window actuator can directly understand and execute, based on the communication protocol and instruction set found in step S41. For example, if the user operation is "fully open," and the found instruction set specifies that "0x01" represents "open," then the operation information will be converted into the "0x01" instruction.

[0160] Specifically, step S43 involves sending the converted control command to the electric window actuator through a corresponding communication interface (such as a serial port, network interface, etc.). After receiving and executing the command, the electric window actuator will feed back its current status information (such as percentage of open, running status, fault information, etc.) to the smart touch screen in the raw data format.

[0161] In step S44, since the original status information feedback from different electric window actuators may have different formats, these original status information formats will be uniformly converted into a common status data format for easier subsequent processing and display. This common format can be a predefined data structure, such as JSON, XML, or a specific binary protocol, ensuring that the status information of all window types can be parsed and processed in a consistent manner.

[0162] Furthermore, step S5 includes:

[0163] S51: Update user interface elements to display status information;

[0164] S52: Obtain the control capabilities of the electric window actuator and map the control capabilities to the standard virtual device type defined in the preset universal smart home protocol;

[0165] S53: Generate virtual device interfaces that conform to the standard virtual device type protocol specification based on the standard virtual device type.

[0166] Specifically, the control capability of an electric window actuator can be understood as all the operation commands and status feedback supported by the actuator, such as opening and closing the window, pausing, adjusting the opening degree, anti-pinch function, and wind and rain sensor linkage. The preset universal smart home protocol refers to the communication protocols widely adopted in the industry for interconnecting smart home devices, such as Matter, Zigbee, HomeKit, and Tuya. The standard virtual device type is an abstract model predefined in these protocols for specific functional devices (such as curtains, door locks, and lighting fixtures), which includes the standard functional characteristics and data structures that such devices should possess. Mapping the control capability to the standard virtual device type means converting the control logic and status information unique to the electric window actuator into a standardized set of functions that can be understood and processed by the universal smart home protocol.

[0167] The virtual device interface is a software interface generated based on the standard virtual device type. It provides a unified API (Application Programming Interface) that conforms to the protocol specification of the standard virtual device type. This allows third-party intelligent control systems to control and query the status of the underlying electric window actuator without needing to understand its specific communication protocol and instruction set. The protocol specification defines in detail the interface calling method, parameter format, return value, etc., ensuring the accuracy and consistency of communication between different systems.

[0168] In some preferred embodiments, it is assumed that an electric window actuator has the control capabilities of "opening," "closing," "pausing," and "adjusting the opening degree (0-100%)." In step S52, the system can acquire these control capabilities and map them to the "Window Covering" standard virtual device type defined in the Matter protocol. This standard virtual device type typically includes standard attributes such as "open / closed state" and "current position," and standard commands such as "goToLiftPercentage." Subsequently, in step S53, the system generates a virtual device interface conforming to the "Window Covering" standard virtual device type according to the Matter protocol specifications. For example, when a third-party smart control system (such as Google Home or Apple HomeKit) sends a command to "open the curtains 50%" through this interface, the virtual device interface will convert it into a specific command that the underlying motorized window actuator can recognize (for example, sending "set opening degree to 50%" via RS485 protocol), and receive the actual opening degree status fed back by the actuator, and then convert it into standard status information defined by the Matter protocol, and feed it back to the third-party system through the interface.

[0169] Furthermore, step S52 includes:

[0170] S521: The first functional characteristic for acquiring the control capability of the electric window actuator;

[0171] S522: Obtain the second functional characteristics of the standard virtual device type defined in the preset universal smart home protocol;

[0172] S523: Match the first functional characteristic with the second functional characteristic, and determine the optimal mapping relationship between the control capability of the electric window actuator and the standard virtual device type based on the matching result, thereby mapping the control capability to the standard virtual device type defined in the preset general smart home protocol.

[0173] Specifically, the first functional characteristic for acquiring the control capabilities of a power window actuator refers to the system obtaining all supported operations, status reports, parameter settings, and other functions by querying the actuator's firmware information, device description file, or communicating with the actuator. For example, these characteristics may include open / close, up / down, stop, position adjustment (such as percentage opening), anti-pinch function, and weather sensor linkage. The purpose is to comprehensively understand the actual control capabilities and reportable statuses of the power window actuator.

[0174] The acquisition of the second functional characteristics of standard virtual device types defined in preset universal smart home protocols can be understood as the system parsing the standard function sets defined for device types such as curtains, blinds, and roller blinds in universal smart home protocols (such as Zigbee, Z-Wave, Matter, HomeKit, etc.). These function sets typically include standardized control commands (such as on, off, stop, and setting percentage), status reports (such as current location and operating status), and attributes (such as device type and manufacturer information). Its purpose is to clarify the standardized interfaces and functions expected by third-party smart control systems.

[0175] In practical applications, the first functional characteristic is matched with the second functional characteristic. Based on the matching result, the optimal mapping relationship between the control capability of the electric window actuator and the standard virtual device type is determined. Specifically, the system compares and associates the actual functional characteristics of the electric window actuator with the functional characteristics of the standard virtual device type through algorithms or preset mapping rules. For example, the "up / down" operation of the electric window actuator can be mapped to the "open / close" or "raise / lower" command of the standard virtual device; the "position adjustment" of the electric window actuator can be mapped to the "set percentage" command of the standard virtual device. The optimal mapping relationship aims to ensure maximum compliance with the specifications of the general smart home protocol without losing the original function of the electric window actuator, enabling third-party smart control systems to control the electric window actuator in the most intuitive and complete way. For example, semantic analysis, feature vector matching, or rule-based expert systems can be used to complete this matching process to ensure the accuracy and efficiency of the mapping.

[0176] In some preferred embodiments, this can be achieved by establishing a multi-level mapping mechanism based on semantic analysis and feature vector comparison.

[0177] First, a standardized functional feature library is constructed. For the acquired first functional characteristics (i.e., the actual physical capabilities of the electric window actuator, such as motor speed adjustment, infrared anti-pinch signal, current stroke pulse count, etc. in the proprietary protocol), the system first converts them into a standardized intermediate description language through a semantic parser. For example, the two discrete physical parameters, pulse count and motor direction, reported by the physical device, are aggregated in the intermediate layer into a current position percentage feature with actual physical meaning.

[0178] This process involves the initial cleaning and standardization of the original physical capabilities, establishing the source feature vector to be matched, which includes the function identifier, data type (such as Boolean, integer, enumeration), value range (such as 0-100 or 0-255), and read / write permissions (read-only, read-write).

[0179] Secondly, for the second functional characteristic (i.e., the standard model in general smart home protocols such as Matter or HomeKit), the system loads the metadata definitions from the protocol specification. For example, the "WindowCovering" cluster defined in the Matter protocol includes standard attributes such as "LiftPercentage," "TiltPercentage," and "ObstructionDetected." The system also abstracts these standard attributes into target feature vectors. At this point, the matching process is essentially a comparison of the source feature vector and the target feature vector in terms of functional semantics and data structure. The system traverses the functional list of the standard protocol, searching for the item that is semantically closest to the physical device's capability. For example, the system will identify that the physical device's "anti-pinch alarm" is highly semantically related to the protocol's "obstacle detection."

[0180] Finally, determining the optimal mapping relationship is not a simple name correspondence, but a decision-making process based on weighted scoring. The system calculates a matching score based on three dimensions: semantic similarity, data precision matching, and operational completeness. If the opening degree of the physical device is an integer from 0 to 100, while the protocol requires an integer from 0 to 255, although the data ranges are different, the semantics are completely consistent and can be losslessly converted through linear transformation. This situation is judged as a high-score match, and the system automatically generates a linear scaling formula: Value_Protocol = Value_Device * 2.55, as the mapping logic. This is the optimal mapping. Here, Value_Device refers to the original value reported or used by the electric window actuator itself, which is the actual physical quantity in the first functional characteristic. Value_Device refers to the standard numerical range required by the general smart home protocol.

[0181] Conversely, if a physical device has a "gentle breeze mode" but there is no directly corresponding standard function in the general protocol, the system will downgrade it to the general "30% on" scenario or map it to a custom extended attribute in the protocol, based on a preset strategy, to ensure that the core function is not lost. This mapping scheme, which compensates for numerical differences through data conversion algorithms and functional granularity differences through combinational logic while ensuring the smooth operation of the core control link, is the optimal mapping relationship defined in this step.

[0182] This application's solution, by acquiring the first functional characteristics of the electric window actuator and the second functional characteristics of a standard virtual device type, and precisely matching the two, enables a deep understanding of the actual control capabilities of the electric window actuator and the standardized interface expected by the third-party intelligent control system. It is precisely this meticulous comparison and matching of functional characteristics that allows the system to establish a highly accurate and flexible mapping relationship. In this way, the unique functions of the electric window actuator can be effectively converted into standard commands and states recognizable by universal smart home protocols, avoiding compatibility issues or functional deficiencies that may result from simple mapping. This ensures that the third-party intelligent control system can comprehensively and accurately control the electric window actuator and obtain its detailed status information.

[0183] Please refer to Figure 2 An integrated system for an intelligent touch screen for electric doors and windows, used to implement any of the above methods:

[0184] First acquisition module 201: Acquires window type information of the electric window actuator connected to the smart touch screen;

[0185] Identification module 202: Based on the window type information, identify the window type corresponding to the electric window actuator, and dynamically load the software control logic module that matches the window type and generate the corresponding user interface elements;

[0186] Second acquisition module 203: Acquires user operation information on user interface elements;

[0187] Conversion module 204: converts operation information into control commands that the electric window actuator can recognize, and receives status information from the electric window actuator in response to the control commands;

[0188] Encapsulation module 205: Updates user interface elements to display status information and encapsulates the control capabilities of the electric window actuator into a virtual device interface that can be recognized by a third-party intelligent control system.

[0189] Specifically, the integrated system consists of multiple functional modules, each undertaking a specific task, working together to achieve intelligent control and integration of electric doors and windows.

[0190] The first acquisition module 201 is configured to acquire window type information from the motorized window actuators connected to the smart touchscreen. This module can actively query the connected motorized window actuators or receive broadcast information from the actuators to identify their specific window type, such as casement windows, sliding windows, skylights, or lift windows. Its purpose is to provide basic data for subsequent window type recognition and software loading.

[0191] The identification module 202 is configured to identify the window type corresponding to the motorized window actuator based on the window type information provided by the first acquisition module 201. Once the window type is identified, the module dynamically loads the software control logic module matching the window type and generates the corresponding user interface elements. For example, for a casement window, the identification module 202 will load the casement window control logic and corresponding open / close and stop buttons; for a skylight, it may load tilt angle adjustment logic and corresponding sliders or buttons. The purpose is to achieve adaptive interface and customized functions, ensuring that the user interface matches the actual window type functions.

[0192] The second acquisition module 203 is configured to acquire user operation information on user interface elements. This module continuously monitors user interactions on the touchscreen, including but not limited to multi-touch gestures such as clicks, swipes, and long presses. Its purpose is to capture the user's operational intent so that the system can respond to the user's control needs.

[0193] The conversion module 204 is configured to convert the operation information acquired by the second acquisition module 203 into control commands recognizable by the electric window actuator, and to receive status information fed back by the electric window actuator in response to the control commands. This module internally includes a protocol mapping mechanism that can convert general operation information into the communication protocol and command format required by a specific electric window actuator based on window type information and operation intent. Simultaneously, it is also responsible for parsing the raw status information fed back by the actuator. Its purpose is to achieve communication compatibility between the touchscreen and different types of electric window actuators.

[0194] The encapsulation module 205 is configured to update user interface elements to display the status information received by the conversion module 204, and to encapsulate the control capabilities of the electric window actuator into a virtual device interface recognizable by third-party intelligent control systems. This module is responsible for two aspects: firstly, intuitively presenting the actuator's feedback status (such as opening / closing degree, operating status, etc.) on the user interface; secondly, it abstracts the control functions of the electric window, enabling it to be controlled by a smart home hub or other third-party systems through a standardized virtual device interface, thereby achieving broader interconnectivity. Its purpose is to provide intuitive user feedback and achieve open interoperability of the system.

[0195] The system solution of this application effectively overcomes the limitation of lacking a concrete implementation carrier in the method description by decomposing the integration method of the intelligent touch screen for electric doors and windows into a series of cooperative modules. When the system starts, the first acquisition module 201 actively or passively acquires the window type information of the connected electric window actuator, laying the foundation for subsequent personalized configuration. Subsequently, the identification module 202 dynamically loads the corresponding software control logic and user interface elements based on this window type information, ensuring that the user interface can accurately reflect the currently connected electric window type and its operable functions. This dynamic loading mechanism not only improves the system's flexibility but also optimizes resource utilization.

[0196] When a user interacts with the touchscreen, the second acquisition module 203 accurately captures the user's operation information, including various complex touch gestures, thereby deciphering the user's control intent. This operation information is then transmitted to the conversion module, which, according to preset protocol mapping rules, translates the abstract operation intent into control commands that the specific electric window actuator can understand and execute. After sending the commands, the conversion module 204 also receives and processes the status information fed back by the actuator, ensuring that the system can monitor the operation status of the electric window in real time.

[0197] Finally, the encapsulation module 205 receives the processed status information and updates it to the user interface, providing the user with intuitive visual feedback. Simultaneously, the encapsulation module 205 abstracts and encapsulates the control capabilities of the electric window actuator into a standardized virtual device interface. This allows the smart touchscreen not only to independently control electric doors and windows but also to seamlessly integrate into a broader smart home ecosystem, accepting instructions from third-party smart control systems, thereby greatly expanding the system's application scenarios and interoperability.

[0198] Through the aforementioned system solution, this application provides a clearly structured and functionally defined integrated system for intelligent touchscreen control of electric doors and windows. The system's modular design separates the responsibilities of each function, greatly improving its maintainability and scalability. For example, when support for new electric window actuators is needed, only the corresponding software control logic modules and user interface elements need to be updated or added, without modifying the entire system architecture. Furthermore, by encapsulating the control capabilities of electric windows into a standardized virtual device interface, the system can easily integrate with various third-party smart home platforms, breaking down barriers between different devices and achieving true intelligent interconnectivity. This system-level implementation, compared to purely methodological descriptions, provides a solid physical and logical foundation for practical deployment, ensuring the stability and reliability of the solution, and significantly improving the user experience and the overall intelligence level of the system.

[0199] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An integrated method of an intelligent touch screen of an electric door and window, characterized in that, The method comprises steps of: S1: acquiring window type information of a motorized window actuator connected with the intelligent touch screen; S2: identifying a window type corresponding to the motorized window actuator according to the window type information, and dynamically loading a software control logic module matched with the window type and generating corresponding user interface elements; Step S2 comprises: S21: identifying a window type corresponding to the motorized window actuator according to the window type information; S22: disassembling the software control logic module and the user interface elements matched with the window type according to a functional level, and re-encapsulating the same into a basic display module and a functional operation module; S23: preferentially loading the basic display module of all identified window types to generate an initial user interface, the basic display module containing window type identification information and basic state display elements; S24: dynamically loading a functional operation module corresponding to a specific window type and detailed user interface elements according to user operation on the initial user interface, the specific window type being selected by the user in the operation on the initial user interface; S25: monitoring system resource occupation, and unloading a functional operation module not used for a long time to release the system resource when the system resource is lower than a preset threshold; S3: acquiring operation information of a user on the user interface elements; S4: converting the operation information into a control instruction recognizable by the motorized window actuator, and receiving state information fed back by the motorized window actuator in response to the control instruction; S5: updating the user interface elements to display the state information, and encapsulating the control capability of the motorized window actuator into a virtual device interface recognizable by a third-party intelligent control system.

2. The method as claimed in claim 1, wherein, Step S25 comprises: S251: configuring a functional priority of each functional operation module; S252: recording last use time of each functional operation module; S253: monitoring system resource occupation, and determining a functional operation module not used for a long time to be unloaded according to the functional priority of the functional operation module and the last use time of the functional operation module when the system resource is lower than the preset threshold, and excluding a module with a high functional priority when determining the functional operation module not used for a long time to be unloaded; S254: performing an unloading operation of the functional operation module not used for a long time to be unloaded to release the system resource.

3. The method as claimed in claim 1, wherein the method further comprises: providing a touch screen on the door or window; and providing a power source for the touch screen. Step S3 comprises: S31: collecting a touch point position, a touch time, a touch pressure and a touch point quantity on the touch screen to obtain original touch information; S32: analyzing a moving track of a single touch point, a continuous touch time, and analyzing a quantity, a relative position change and a continuous time of multiple touch points according to the original touch information to obtain a multi-point touch gesture; S33: calculating a moving speed and a moving distance of the single touch point according to the moving track of the single touch point and the continuous touch time, and identifying the single touch point as a fast sliding action when the moving speed of the single touch point exceeds a preset speed threshold and the moving distance of the single touch point exceeds a preset distance threshold. S34: identifying the single touch point as a long-press action when a duration of the single touch point exceeds a preset time threshold; S35: according to the identified quick slide action, long-press action or multi-point touch gesture, analyzing a corresponding window advanced operation intention to obtain operation information of the user on the user interface element. Step S35 includes:

4. The method of claim 3, wherein the method further comprises: S351: when the quick slide action, long-press action or multi-point touch gesture is identified, obtaining a window type of an electric window actuator on which the gesture acts and a current operation context parameter; S352: according to the quick slide action, long-press action or multi-point touch gesture, the window type and the current operation context parameter, analyzing a corresponding window advanced operation intention; S353: taking the window advanced operation intention as the operation information of the user on the user interface element. Step S352 includes:

5. The method of claim 4, wherein the method further comprises: S3521: a preset judgment logic structure, the judgment logic structure includes a judgment node and a result node, the judgment node is used to evaluate gestures, window types and current operation context parameters, and the result node stores window advanced operation intentions; S3522: according to the identified quick slide action, long-press action or multi-point touch gesture, the window type and the current operation context parameter, starting from the starting judgment node of the judgment logic structure to make a judgment; S3523: according to the conditions set by the judgment node, evaluating the identified quick slide action, long-press action or multi-point touch gesture, the window type and the current operation context parameter, and selecting a corresponding branch path; S3524: sequentially performing the evaluation and branch path selection operation until the result node is reached, and obtaining the corresponding window advanced operation intention from the result node. Step S4 includes:

6. The method of claim 1, wherein the method further comprises: S41: according to the window type information, searching a communication protocol and an instruction set corresponding to the electric window actuator from a preset protocol mapping table; S42: according to the communication protocol and the instruction set, converting the operation information into a control instruction recognizable by the electric window actuator; S43: sending the control instruction to the electric window actuator, and receiving state information in a raw format fed back by the electric window actuator in response to the control instruction; S44: converting the state information in the raw format fed back by the electric window actuator into state information in a general state data format. Step S5 includes:

7. The method of claim 1, wherein the method further comprises: S51: updating the user interface element to display the state information; S52: obtaining a control capability of the electric window actuator, and mapping the control capability into a standard virtual device type defined in a preset general smart home protocol; S53: according to the standard virtual device type, generating a virtual device interface conforming to a standard virtual device type protocol specification. Step S52 includes:

8. The method of claim 7, wherein the method further comprises: S521: obtaining a first functional characteristic of the control capability of the electric window actuator; S522: obtaining a second functional characteristic of the standard virtual device type defined in the preset general smart home protocol; ​ S523: match the first function characteristic with the second function characteristic, and determine the optimal mapping relationship between the control ability of the electric window actuator and the standard virtual device type according to the matching result, so as to map the control ability to the standard virtual device type defined in the preset general smart home protocol.

9. An integrated system of an intelligent touch screen of an electric door and window, characterized in that, The method according to any one of claims 1-8 is implemented by using the following device: A first obtaining module is configured to obtain window type information of an electric window actuator connected to a smart touch screen. An identifying module is configured to identify a window type corresponding to the electric window actuator according to the window type information, and dynamically load a software control logic module matched with the window type and generate corresponding user interface elements. The identifying module is further configured to identify a window type corresponding to the electric window actuator according to the window type information, and to disassemble and re-encapsulate the software control logic module and the user interface elements matched with the window type according to a function level into a basic display module and a function operation module. All the basic display modules of the identified window types are preferentially loaded to generate an initial user interface, and the basic display modules contain window type identification information and basic state display elements. The function operation module and detailed user interface elements corresponding to a specific window type are dynamically loaded according to user operations on the initial user interface, and the specific window type is selected by the user in the operations on the initial user interface. System resource occupation is monitored, and when the system resources are lower than a preset threshold, a function operation module that has not been used for a long time is unloaded to release the system resources. A second obtaining module is configured to obtain operation information of a user on the user interface elements. A converting module is configured to convert the operation information into control instructions recognizable by the electric window actuator, and receive state information fed back by the electric window actuator in response to the control instructions. An encapsulating module is configured to update the user interface elements to display the state information, and encapsulate the control ability of the electric window actuator into a virtual device interface recognizable by a third-party intelligent control system.

Images