Method and system for debugging electric door and window by using single computer WIFI webpage

Abstract

This application provides a method and system for debugging electric doors and windows using a standalone Wi-Fi webpage, applied in the field of intelligent door and window control technology. By connecting the debugging device to the local wireless network emitted by the electric door and window control module and obtaining product identity information, a direct and convenient connection between the debugging device and the electric door and window is achieved. Based on the obtained product identity information, the system can intelligently construct and display a webpage debugging interface containing only debugging parameters and operation options related to the current electric door and window product from preset product feature data and interface components. This effectively solves the problem of large debugging guide documents and complex operations caused by the diversity of product lines in traditional debugging solutions, and has the beneficial effects of significantly improving debugging efficiency, reducing operation difficulty and labor costs.

Description

Technical Field

[0001] This application relates to the field of intelligent door and window control technology, and in particular to a method and system for debugging electric doors and windows using a standalone WIFI webpage. Background Technology

[0002] In the production and commissioning of electric doors and windows, the industry currently faces a common and significant challenge. Due to the increasingly diverse product lines, encompassing various types from electric casement windows and electric sliding doors to electric lift windows, each product may integrate different electric hardware and control panels. This high degree of diversity necessitates addressing a wide variety of commissioning solutions during the pre-shipment commissioning phase. To ensure products meet stringent factory standards, manufacturers must prepare detailed commissioning guidelines for each product, resulting in a massive volume of documents with extremely complex content. For on-site operators, this undoubtedly greatly increases operational complexity, requiring specialized training for different commissioning items. This not only leads to numerous management inconveniences but also results in high maintenance costs, ultimately significantly increasing the company's labor costs.

[0003] Furthermore, current electric door and window products exhibit significant differences in their control methods, meaning they employ various communication protocols. For example, some products may use simple dry contact signals for control, while others may use serial communication protocols such as RS485, and still others operate via 315MHz or 433MHz wireless radio frequency signals. Faced with these protocol differences, various debugging solutions have emerged. Some debugging work relies on wall-mounted control panels, some requires the use of dedicated remote controls, and some products even come with built-in applications for debugging. Adding to the complexity, door and window products integrating glass panes and screens typically have their own independent control systems, requiring separate handling during debugging. All these factors combined make the entire debugging process exceptionally complex, resulting in disorganized training content, wasting significant human and material resources, and incurring excessive time costs.

[0004] In a complex production and debugging environment with a wide variety of electric door and window products, different control protocols (such as dry contacts, RS485, and wireless radio frequency), and scattered debugging methods (such as wall control panels, remote controls, and dedicated applications), how to effectively solve the problems of fragmented debugging solutions, complex operation, high training costs, and cumbersome debugging processes for multiple systems (such as glass sashes and screens) caused by product diversity through a unified single-machine WiFi web debugging method, thereby significantly reducing manpower, material resources, and time costs, is a technical problem that urgently needs to be solved.

[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 a method and system for debugging electric doors and windows using a standalone WIFI webpage, which has the advantages of convenient debugging operation, interface built according to product information, simplified debugging process for multiple independent control systems, and communication protocol conversion capability.

[0007] A first aspect is a method for debugging electric doors and windows using a standalone Wi-Fi webpage, the method comprising the following steps:

[0008] S1: Connect the debugging equipment to the local wireless network emitted by the electric door and window control module, and obtain the product identity information of the electric door and window control module;

[0009] S2: Based on the product identity information, construct and display a web-based debugging interface containing only debugging parameters and operation options related to electric door and window products from preset product feature data and interface components;

[0010] S3: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web page debugging interface, and the debugging order of the multiple independent control systems is arranged according to the preset linkage rules.

[0011] S4: Convert the operations on the web page debugging interface into debugging instructions according to the debugging sequence, and convert the debugging instructions into underlying communication messages that can be recognized and executed by the communication protocol based on the communication protocol type identified in the product identity information.

[0012] Furthermore, step S1 includes:

[0013] S11: After the electric door and window control module is powered on, a local wireless network containing its unique identifier is broadcast, and a connection credential associated with the unique identifier is generated.

[0014] S12: Control the debugging device to identify the connection credentials in order to establish a connection with the local wireless network;

[0015] S13: After connecting to the local wireless network, control the electric door and window control module to send a product identity information packet in a preset format to the debugging device. The product identity information packet includes at least a data integrity check code.

[0016] S14: After receiving the product identity information packet, the debugging device uses the data integrity check code to verify the data integrity. When the data integrity verification is successful, the product identity information is extracted from the product identity information packet.

[0017] Furthermore, step S2 includes:

[0018] S21: After obtaining the product identity information, control the debugging device to send a query command to the electric door and window control module to obtain the function list and parameter definition supported by the current firmware version of the electric door and window control module;

[0019] S22: In the preset product feature data, traverse the real-time function list and the real-time parameter definition, and compare the first difference between the function list and the real-time function list, and the second difference between the parameter definition and the real-time parameter definition;

[0020] S23: Based on the first difference, adjust the component selected from the preset interface components; based on the second difference, adjust the corresponding parameter range from the preset product feature data;

[0021] S24: Based on the product identity information, the adjusted components, and the adjusted parameter range, construct a web-based debugging interface that contains only debugging parameters and operation options related to the electric door and window product;

[0022] S25: Display the web page debugging interface on the interactive screen of the debugging device.

[0023] Furthermore, step S24 includes:

[0024] S241: Identify the interdependencies between debugging parameters based on the product identity information, the adjusted components, and the adjusted parameter range;

[0025] S242: Convert the aforementioned interdependencies into user interface interaction logic;

[0026] S243: Based on the product identity information, the adjusted components, the adjusted parameter range, and the interface interaction logic, construct a web-based debugging interface that contains only debugging parameters and operation options related to the electric door and window product; the interface interaction logic is used to adjust the display range, available status, or set of optional options of other debugging parameters that are interdependent with it when the debugging equipment receives input of a parameter from the debugging personnel, and to display a warning message when a conflict is detected between the parameter value input by the debugging personnel and the interdependency.

[0027] Furthermore, step S241 includes:

[0028] S2411: Based on the product identity information, determine the functional module to which each debugging parameter belongs from the preset functional module and parameter type mapping data;

[0029] S2412: Based on the functional modules, compare the parameter pairs associated with the functions to identify the basic interdependencies;

[0030] S2413: Based on the physical characteristics of the electric doors and windows indicated in the product identity information and the adjusted parameter range, deduce the interdependence of physical constraints or operating conditions.

[0031] S2414: Integrate the basic interdependencies and the interdependencies reflecting physical constraints or operating conditions to obtain the interdependencies between the debugging parameters.

[0032] Furthermore, step S242 includes:

[0033] S2421: The interdependencies are converted into a set of interface interaction logic that can be parsed and executed by the web page debugging interface. The interface interaction logic is presented in the form of a condition-action rule set. Each rule in the condition-action rule set explicitly specifies the triggering condition, affected parameters, and interface adjustment behavior.

[0034] Furthermore, step S3 includes:

[0035] S31: Obtain the operating characteristics of each of the independent control systems, including startup time, settling time, and communication delay;

[0036] S32: Analyze the preset linkage rules and identify the parallel relationships and conditional dependencies between the independent control systems;

[0037] S33: Based on the operating characteristics and the parallel and conditional dependencies, plan the debugging paths for multiple independent control systems to determine the debugging sequence that minimizes the overall debugging time;

[0038] S34: Based on the debugging sequence, generate a debugging process view that supports parallel execution and conditional jump on the web debugging interface, as the unified composite debugging view.

[0039] Furthermore, step S33 includes:

[0040] S331: Presets multiple logically feasible debugging sequences;

[0041] S332: For each of the multiple logically feasible debugging sequences, simulate execution based on the said running characteristics, the said parallel relationship, and the said conditional dependency relationship;

[0042] S333: Records the total debugging time for each simulation execution sequence;

[0043] S334: Select the order with the shortest overall debugging time from a variety of logically feasible debugging orders as the debugging order.

[0044] Furthermore, step S4 includes:

[0045] S41: Convert the operations on the web page debugging interface into debugging commands according to the debugging sequence;

[0046] S42: Obtain the communication protocol type and protocol version identified in the product identity information;

[0047] S43: Query the local protocol conversion module library to determine whether there is a conversion module in the local protocol conversion module library that matches the communication protocol type and the protocol version;

[0048] S44: If there is no conversion module in the local protocol conversion module library that matches the communication protocol type and the protocol version, then request the download of the conversion module that matches the communication protocol type and the protocol version from the preset protocol update server, and load it into the local protocol conversion module library after successful download.

[0049] S45: Using a conversion module in the local protocol conversion module library that matches the communication protocol type and the protocol version, the debugging instructions are converted into low-level communication messages that the communication protocol can recognize and execute.

[0050] Secondly, a system for debugging electric doors and windows using a standalone WIFI webpage, for implementing any of the methods described above, the system comprising:

[0051] Acquisition Module: Connects the debugging device to the local wireless network emitted by the electric door and window control module, and acquires the product identity information of the electric door and window control module;

[0052] Construction module: Based on the product identity information, construct and display a web-based debugging interface from preset product feature data and interface components, containing only debugging parameters and operation options related to electric door and window products;

[0053] Arrangement module: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web page debugging interface, and the debugging order of the multiple independent control systems is arranged according to the preset linkage rules;

[0054] Debugging module: Converts the operations on the web debugging interface into debugging commands according to the debugging sequence, and converts the debugging commands into underlying communication messages that can be recognized and executed by the communication protocol based on the communication protocol type identified in the product identity information.

[0055] Beneficial Effects: This application proposes a method and system for debugging electric doors and windows using a standalone Wi-Fi webpage. By connecting the debugging device to the local wireless network emitted by the electric door and window control module and obtaining product identity information, a direct and convenient connection between the debugging device and the electric door and window is achieved. Based on the obtained product identity information, the system can intelligently construct and display a webpage debugging interface containing only debugging parameters and operation options related to the current electric door and window product from preset product feature data and interface components. This effectively solves the problem of large and complex debugging guide documents and operations caused by the diversity of product lines in traditional debugging solutions, and has the beneficial effects of significantly improving debugging efficiency, reducing operation difficulty and labor costs. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating a method for debugging electric doors and windows using a standalone WIFI webpage, as proposed in this application.

[0057] Figure 2 This is a structural diagram of a system for debugging electric doors and windows using a standalone WIFI webpage, as proposed in this application.

[0058] Labeling explanation: 201, Acquisition module; 202, Construction module; 203, Orchestration module; 204, Debugging module. Detailed Implementation

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

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

[0061] Please refer to Figure 1 A method for debugging electric doors and windows using a standalone Wi-Fi webpage, the method includes the following steps:

[0062] S1: Connect the debugging equipment to the local wireless network emitted by the electric door and window control module, and obtain the product identity information of the electric door and window control module;

[0063] S2: Based on the product identity information, construct and display a web-based debugging interface from preset product feature data and interface components, containing only debugging parameters and operation options related to electric door and window products;

[0064] S3: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web debugging interface, and the debugging order of multiple independent control systems is arranged according to the preset linkage rules.

[0065] S4: Convert the operations on the web debugging interface into debugging commands according to the debugging order, and convert the debugging commands into underlying communication messages that can be recognized and executed by the communication protocol based on the communication protocol type identified in the product identity information.

[0066] The method provided in this application aims to solve the problems of complex, inefficient, and costly debugging processes caused by the wide variety of existing electric door and window products and their different control methods. Its core working principle lies in unifying the debugging work of all different types of electric doors and windows into a web-based interactive interface highly matched to the specific product through a standardized wireless connection and dynamic interface generation mechanism. This achieves a universal, efficient, and low-cost debugging process. The entire workflow can be understood as a process from physical connection to information recognition, then to adaptive interface construction, and finally to precise command issuance.

[0067] Specifically, when commissioning personnel need to define parameters and verify the functions of newly manufactured electric doors and windows, the entire process begins with establishing a communication connection. The commissioning personnel carry a general-purpose commissioning device, such as a smartphone, tablet, or laptop. First, the control module of the electric door and window is powered on and activated. This control module integrates a wireless network transmitter, which automatically creates a local, independent wireless network environment upon startup. This network acts as a temporary, dedicated communication bridge for commissioning, connecting the commissioning device to the electric door and window control module. The commissioning personnel operate the commissioning device to search for and connect to this local wireless network emitted by the control module. After a successful connection, a point-to-point communication link is established between the commissioning device and the electric door and window control module.

[0068] After the connection is established, the information acquisition phase begins. During this phase, the electric door and window control module proactively sends its product identification information to the debugging equipment. This product identification information is structured data containing codes that uniquely identify all the key characteristics of the electric door and window product. These characteristics include at least the product model, hardware configuration, firmware version, the type and version number of the communication protocol used, and the set of functions the product possesses. This product identification information acts like an electronic ID card for the product, providing all the necessary information for subsequent adaptive debugging.

[0069] After receiving and parsing the product identification information, the debugging equipment does not load a fixed, generic debugging program containing all possible options. Instead, it runs a web service program internally. This program, based on the product identification information just acquired, dynamically generates a customized web debugging interface by precisely selecting elements from a pre-set resource library that perfectly correspond to the current electric door and window product, much like building blocks. This resource library contains two main parts: product feature data and interface components.

[0070] The product feature data is a huge database that stores detailed parameter definitions, value ranges, function lists, and other information for all product models of the company.

[0071] Interface components are a standardized library of user interface elements, including various buttons, sliders, input boxes, drop-down menus, etc.

[0072] The specific construction process is as follows: Based on the model number in the product identification information, the program searches for corresponding parameters and functions in the product feature data. Then, for each parameter and function, it selects the most suitable visual representation from the interface component library. Finally, these components are combined into a complete webpage. For example, if the product identification information indicates that this is an electric sliding window with an anti-pinch function, the generated webpage will display a slider for adjusting the anti-pinch force, instead of a weather sensor switch related to casement windows. In this way, the interface seen by the debugging personnel is extremely simple and intuitive; all operable options are directly related to the product in front of them, greatly reducing the complexity of operation and the risk of misoperation.

[0073] In some complex application scenarios, an electric door and window product may contain multiple independently operating subsystems. A typical example is a high-end door and window that includes both a glass pane and a screen, with the opening and closing of the glass pane and the raising and lowering of the screen driven by two separate motors and control systems. For such products, separate independent debugging would be extremely cumbersome and prone to errors. Therefore, when the product identification information indicates that the product contains multiple independent control systems, this method enters a collaborative debugging mode. In this mode, the web-based debugging interface no longer simply lists the parameters of the two systems but generates a unified composite debugging view. This composite debugging view intelligently orchestrates the debugging steps of the two systems according to preset linkage rules in the debugging equipment, forming a logically clear and sequentially optimized debugging process. For example, the rules might stipulate that the travel calibration of the glass pane must be completed before the travel calibration of the screen. Debugging personnel only need to follow the process guidance presented on this composite view step by step; the system will automatically switch control of different subsystems in the background, thus simplifying the complex multi-system debugging into a single linear process.

[0074] Finally, there's the instruction conversion and execution phase. All operations performed by the debugging personnel on the web interface, such as clicking a button or dragging a slider, are captured by the script program on the web front end and converted into abstract, standardized debugging instructions. For example, clicking the "Open" button generates an instruction to "execute the open action." However, different electric door and window control modules may use completely different underlying communication protocols; for example, some use the RS485 bus protocol, some use the CAN bus protocol, and some use custom wireless radio frequency protocols. To solve this compatibility issue, the debugging equipment again utilizes the communication protocol type information obtained from the product identification information. Based on this information, the equipment calls a corresponding protocol conversion module to accurately translate the standardized debugging instruction into underlying communication messages that the specific communication protocol can recognize and execute.

[0075] The underlying communication message is a stream of binary data containing the correct frame header, address code, command code, data body, and checksum. Finally, the underlying communication message is sent to the electric door and window control module via the local wireless network. The electric door and window control module receives and executes the underlying communication message, thereby driving the motor to complete the corresponding action. This series of steps ensures that regardless of the uniformity of the front-end web interface, the instructions ultimately sent to the hardware are accurate.

[0076] Furthermore, step S1 includes:

[0077] S11: After the electric door and window control module is powered on, it broadcasts a local wireless network containing its unique identifier and generates a connection credential associated with the unique identifier.

[0078] S12: Control the debugging equipment to identify connection credentials in order to establish a connection with the local wireless network;

[0079] S13: After connecting to the local wireless network, control the electric door and window control module to send a product identity information packet in a preset format to the debugging equipment. The product identity information packet includes at least a data integrity check code.

[0080] S14: After receiving the product identity information packet, the debugging equipment uses the data integrity check code to verify the data integrity. When the data integrity verification is successful, the product identity information is extracted from the product identity information packet.

[0081] In one specific implementation, when the electric window and door control module is powered on, its internal wireless module begins operation and creates a wireless hotspot. The network name of this hotspot, i.e., the server identifier (unique identifier), is generated based on the unique serial number or MAC address of the electric window and door control module hardware. This ensures that even if multiple devices are being debugged simultaneously within the same production workshop, their network names will not be duplicated, facilitating accurate identification by debugging personnel. Simultaneously, to ensure connection security and prevent unauthorized devices from accessing the network, the control module also generates a dynamic connection credential for this network, typically a wireless network password. This credential can be provided to the debugging equipment in various ways. For example, a QR code containing the network name and password can be printed on the casing of the electric window and door control module. Debugging personnel can scan the QR code with the camera of the debugging equipment to automatically complete network identification and connection, simplifying the tedious step of manually entering the password.

[0082] Once the debugging device successfully connects to the local wireless network using connection credentials, the communication link between the two is officially established. At this point, the electric door and window control module immediately encapsulates a product identification information packet and sends it to the debugging device via the wireless link. The format of this packet is predefined to ensure that the debugging device can correctly parse it. To prevent data errors caused by signal interference during wireless transmission, when this packet is generated, a data integrity check code is calculated based on its valid data content using a verification algorithm, such as cyclic redundancy check, and this check code is appended to the end of the packet.

[0083] Upon receiving the product identity information packet, the debugging equipment does not immediately use the data. Instead, it executes a verification procedure. This procedure reads all data in the packet except for the checksum and calculates a local verification result using the same algorithm as the sender. The program then compares this locally calculated result with the data integrity checksum included in the packet. If they match perfectly, the data has been transmitted without error and is complete and reliable. At this point, the data integrity verification passes, and the debugging equipment continues to extract core product identity information such as the product model and firmware version from the packet for subsequent interface construction. If the comparison results are inconsistent, the data is corrupted, and the debugging equipment discards the packet and can request a retransmission from the control module. This ensures that the entire debugging process is based on accurate data from the outset.

[0084] Furthermore, step S2 includes:

[0085] S21: After obtaining the product identity information, control the debugging equipment to send a query command to the electric door and window control module to obtain the list of functions and parameter definitions supported by the current firmware version of the electric door and window control module;

[0086] S22: In the preset product feature data, traverse the real-time function list and real-time parameter definition, and compare the first difference between the function list and the real-time list, and the second difference between the parameter definition and the real-time parameter definition.

[0087] S23: Based on the first difference, adjust the component selected from the preset interface components; based on the second difference, adjust the corresponding parameter range from the preset product feature data.

[0088] S24: Based on the product identity information, the adjusted components, and the adjusted parameter range, construct a web-based debugging interface that contains only debugging parameters and operation options related to the electric door and window product;

[0089] S25: Display the web page debugging interface on the interactive screen of the debugging device.

[0090] This method introduces a dynamic adaptation and differentiated update mechanism, ensuring that the debugging interface not only matches the product model but also accurately reflects its current firmware status. The initial product identification information may only contain the firmware version number. To obtain the most accurate feature set, the debugging device initiates a deep query after parsing the version number. A deep query involves the debugging device sending a specific query command to the electric window / door control module, requesting it to return a complete list of all features supported by its current firmware and detailed definitions of all configurable parameters. Upon receiving the command, the electric window / door control module reads this information from its internal storage and packages it to send back to the debugging device. This response data constitutes the "real-time feature list" and "real-time parameter definitions."

[0091] After receiving this real-time data, the debugging equipment will use it as a benchmark to compare it with the preset product feature data corresponding to the product model stored locally. The comparison process is divided into two levels. First, there is a functional comparison. The program will traverse every function item in the real-time function list and check if it exists in the preset function list. In this process, the first difference may be found. For example, a "micro-ventilation" function may be added to the real-time function list, which is a new firmware addition, but not present in the function list; or an old function in the function list may no longer exist in the real-time list, indicating that it has been removed by the new firmware. Second, there is a parameter comparison. The program will traverse every parameter in the real-time parameter definition and compare it with the preset parameter of the same name. In this process, the second difference may be found. For example, for the parameter "maximum motor torque", the preset range is 1 to 10 Nm, but in the real-time parameter definition, due to the replacement of the new motor hardware, the range has become 1.5 to 12 Nm.

[0092] After identifying these differences, the debugging equipment will dynamically adjust. Based on the first difference—the addition or removal of functions—it will adjust the selection of interface components accordingly. If a "micro-ventilation" function is added, the program will select a corresponding switch button component from the interface component library and prepare to add it to the interface. If a function is removed, the component originally associated with it will not be selected. Based on the second difference—changes in parameter definitions—it will adjust the setting range of the corresponding parameters. For the "maximum motor torque" parameter, the program will update the valid value range of its corresponding slider or input box in the web interface to ensure that its upper and lower limits perfectly match the actual capabilities of the hardware.

[0093] After the above comparisons and adjustments, the debugging equipment acquired a fully customized set of functional components and parameter ranges that were precisely synchronized with the current firmware state of the product being debugged. Finally, the program used these adjusted elements, combined with basic information from the product's identity information, to construct a unique web-based debugging interface, which was then presented to the debugging personnel on the debugging equipment's screen. This process ensured that the debugging personnel saw exactly what they were getting, and all operations were performed within the actual range supported by the hardware.

[0094] The adjusted components and parameter ranges are intermediate data dynamically trimmed based on product identity information; while the debugging parameters and operation options are the specific presentation of this intermediate data in the web debugging interface. Each retained component corresponds to an interactive operation option (such as a button, switch, or drop-down menu) in the web debugging interface. The visibility, clickability, and displayed text of this operation option are entirely determined by the presence or absence of the component in the adjusted component list.

[0095] For each retained component, the numerical range or enumeration set defined within the adjusted parameter range is directly mapped to the debugging parameters of that component in the web page debugging interface. The forms of debugging parameters include, but are not limited to: numerical input boxes, whose minimum, maximum, and step sizes are defined by the upper and lower limits and granularity of the parameter range; radio / checkbox groups, whose selectable items are defined by the enumeration values ​​in the parameter range; and sliders, whose endpoints correspond to the upper and lower limits of the parameter range.

[0096] When a certain operation option is triggered, the web debugging interface will dynamically render or refresh the associated debugging parameter control in real time according to the debugging parameter range corresponding to that component, ensuring that the user can only make settings within the allowed range.

[0097] Furthermore, step S24 includes:

[0098] S241: Identify the interdependencies between debugging parameters based on product identity information, adjusted components, and adjusted parameter ranges;

[0099] S242: Transform interdependencies into UI interaction logic;

[0100] S243: Based on product identity information, adjusted components, adjusted parameter ranges, and interface interaction logic, construct a web-based debugging interface that contains only debugging parameters and operation options related to the electric door and window product; the interface interaction logic is used to adjust the display range, available status, or set of optional options of other debugging parameters that are interdependent with it when the debugging equipment receives input of a parameter from the debugging personnel, and to display a warning message when a conflict is detected between the parameter value input by the debugging personnel and the interdependencies.

[0101] This method aims to prevent the system from treating all debugging parameters as isolated, arbitrarily settable variables. Instead, it recognizes the complex, inherent relationships between them based on physical laws or functional logic. For example, the "opening speed" and "maximum motor current" parameters for electric windows are not entirely independent. If the opening speed is set very high, the motor will inevitably consume more current during startup and operation. If the debugging personnel, unaware of this relationship, set the speed to its maximum value while simultaneously setting the maximum current limit to a low value, the motor may fail to reach the set speed due to insufficient current, potentially triggering stall or overload protection, leading to debugging failure or misjudgment.

[0102] To avoid this situation, the system performs dependency identification before building the webpage interface. The system analyzes all debugging parameters to be displayed on the interface, identifying the interrelationships between them. After identifying these relationships, the system doesn't directly present them to the user in text form. Instead, it transforms these abstract dependencies into concrete, perceptible "interface interaction logic." This logic is then embedded into the webpage's code, giving the final webpage interface dynamic responsiveness and intelligent guidance capabilities.

[0103] The display range refers to the range of values ​​that a user can set or select for a specific debugging parameter in the web-based debugging interface. When the value of a parameter changes, the system dynamically adjusts the display range of other related parameters based on preset dependency logic to ensure that the user-selected value conforms to the system's logical and physical constraints. For example, when the window width parameter increases, the system may automatically reduce the display range of the maximum opening angle to prevent excessive structural stress on the window frame and hinges due to an excessively large opening angle.

[0104] Availability refers to whether a debugging parameter can be manipulated by the user (such as modified, selected, or enabled) under specific conditions. For example, some parameters may be locked in a certain mode and cannot be adjusted. When the value of a parameter changes, the system will determine whether other related parameters should be enabled or disabled based on preset dependency logic.

[0105] The set of optional options refers to the collection of values ​​that can be selected for a certain debugging parameter under specific conditions. Some parameters may have dynamic option lists that change based on the values ​​of other parameters. The system dynamically adjusts the range of optional values ​​for these parameters based on dependency logic. For example, when the window type is set to a casement window, the set of optional opening angles might be [0°, 90°]; while when the window type is set to a sliding window, the set of optional opening angles might become [0%, 100%], indicating that the opening degree of the sliding window is expressed as a percentage.

[0106] In some specific implementations, this logic comes into play when the user interacts with the interface. For example, the interface might have two parameters: "window width" and "maximum opening angle." These two parameters are physically dependent: for a very wide window, an excessively large opening angle could cause excessive structural stress on the window frame and hinges. Once the system recognizes this dependency, it generates corresponding interface interaction logic. When the user enters a large value, such as 3000 mm, into the "window width" input box, the interface will immediately react, and the input range for the "maximum opening angle" parameter might be dynamically adjusted, automatically reducing its upper limit from the default 90 degrees to 60 degrees. In this way, by changing the selectable range of the interface, the system fundamentally eliminates the possibility of the user setting physically unreasonable parameter combinations.

[0107] Furthermore, the interface interaction logic also includes conflict detection and warning functions. In some cases, the relationship between parameters may not be a simple range restriction, but a more complex logical conflict. For example, a system may have both an "energy-saving mode" and a "strong wind-resistant mode." These two modes are logically mutually exclusive; turning one on must turn the other off. If a user activates the "energy-saving mode" first and then tries to turn on the "strong wind-resistant mode," the interface interaction logic will detect this conflict. In this case, the system will not perform this contradictory operation but will instead display a clear warning message, indicating that "energy-saving mode and strong wind-resistant mode cannot be turned on simultaneously," and may guide the user to turn off the current mode first. In this way, the interface transforms from a passive parameter input tool into a proactive, intelligent assistant that understands the product's internal logic and provides real-time feedback and guidance to the user.

[0108] To systematically identify the aforementioned dependencies, the steps for identifying the interdependencies between debugging parameters may specifically include:

[0109] S2411: Based on the product identity information, determine the functional module to which each debugging parameter belongs from the preset functional module and parameter type mapping data;

[0110] S2412: Based on functional modules, compare parameter pairs related to functions to identify basic interdependencies;

[0111] S2413: Based on the physical characteristics of electric doors and windows indicated in the product identification information and the adjusted parameter range, deduce the interdependence of physical constraints or operating conditions.

[0112] S2414: Integrate basic interdependencies and interdependencies reflecting physical constraints or operating conditions to obtain the interdependencies between debugging parameters.

[0113] The above process decomposes dependency identification into two main approaches: identification based on pre-defined knowledge and derivation based on physical models. First, the system maintains a "functional module and parameter type mapping data" database. This database acts like a knowledge network, structurally associating each product function (such as anti-pinch protection, timed ventilation, and weather sensing) with the relevant parameters required to achieve that function. For example, the database explicitly records the "anti-pinch protection" functional module, which is associated with parameters such as "anti-pinch sensor sensitivity," "obstacle detection rebound distance," and "rebound force." When the system determines to build a debugging interface for a product, it first determines which functional modules the product contains based on the product's identity information. Then, by querying this mapping database, the system can quickly find all parameters belonging to the same functional module. These parameter pairs, bound together by functional logic, constitute the "basic interdependencies." For example, the system can identify a dependency between "anti-pinch sensor sensitivity" and "obstacle detection rebound distance," because a higher sensitivity setting may require a longer rebound distance to ensure safety.

[0114] However, relying solely on preset functional logic is insufficient, as many dependencies stem from the product's inherent physical attributes. Therefore, the system performs a second step: "physical constraint derivation." It extracts key physical characteristic data from the product's identity information, such as the window sash's weight and dimensions, the motor model and power curve, and the reduction ratio of the transmission mechanism. Combining this specific physical data with previously dynamically adjusted parameter ranges, the system uses built-in physical or engineering models to perform calculations, thereby deriving deeper interdependencies reflecting physical constraints or operating conditions. Typically, the built-in physical or engineering models include at least the following reproducible mechanical and electrical models used to derive the interdependencies between debugging parameters, for example:

[0115] The relationship between motor output torque and current is modeled using the steady-state equation of a DC permanent magnet motor: T = k_t·I, where T is the output torque (N·m), k_t is the motor torque constant (N·m / A), and I is the armature current (A). The value of k_t is uniquely determined by the motor model in the product identification information and is pre-stored in the motor parameter table in the local database.

[0116] The wind pressure-torque conversion model defines the wind torque M_wind acting on the window sash as being determined by the wind pressure p (Pa), the effective area A (square meters) of the window sash, and the lever arm L (m): M_wind = p·A·L. The wind pressure p is taken as the standard value corresponding to the wind resistance level according to GB / T 7106-2019 "Classification and Test Methods for Air Tightness, Water Tightness, and Wind Pressure Resistance Performance of Building Exterior Doors and Windows" (e.g., 1.5 for level 8 wind pressure). ).

[0117] The mechanical balance equation, to maintain the static balance of the window sash at a certain opening angle θ, must satisfy: T·r = M_wind(θ) + M_gravity(θ), where r is the product of the reduction ratio and the lever arm of the transmission mechanism (m), and M_gravity(θ) is the component of the window sash's weight in the opening direction, calculated from the window sash's mass m (kg) and the position of its center of gravity: M_gravity(θ) = m·g·d·sinθ, where g is taken as 9.81. d is the horizontal distance (m) from the center of gravity to the hinge axis.

[0118] The current-speed constraint model shows the relationship between the motor's steady-state speed ω (rpm) and current I, given by the motor characteristic curve: ω = (UI·R) / k_e, where U is the rated voltage (V), R is the armature resistance (Ω), and k_e is the back electromotive force constant (V·s / rad). This curve is pre-stored in a lookup table, with the table key being a triplet of (U,R,k_e).

[0119] Let's illustrate this derivation process with a specific example. Assume the product information indicates that the currently tested motorized casement window has a sash weight of 50 kg, a motor rated torque of 10 N·m, and a drive arm length of 0.5 m. The testing interface displays two parameters: "Wind Resistance Level" and "Motor Operating Current Upper Limit." The system can deduce from a simplified mechanical model that the force acting on the window sash to resist a certain wind force (e.g., Force 8, corresponding to a known wind pressure value) can be calculated, and thus the required sustaining torque of the motor can be determined. Based on the motor's performance curve, this torque corresponds to a specific operating current. Therefore, the system can derive a dependency: when the "Wind Resistance Level" is set to Force 8, the minimum value of the "Motor Operating Current Upper Limit" must be set above a calculated threshold; otherwise, the motor will not provide sufficient force to resist strong winds. This dependency cannot be obtained through simple functional module mapping; it must be derived by combining specific physical characteristics.

[0120] Finally, the system integrates all the "basic interdependencies" identified in the first step and all the "interdependencies reflecting physical constraints or operational conditions" derived in the second step. This integration process eliminates redundancy and resolves potential conflicts, ultimately forming a comprehensive and accurate set of interdependencies between debugging parameters. This set will serve as the final basis for generating subsequent interface interaction logic.

[0121] Furthermore, step S242 includes:

[0122] S2421: Convert interdependencies into a set of UI interaction logic that can be parsed and executed by the web page debugging interface. The UI interaction logic is presented in the form of a set of condition-action rules. Each rule in the set of condition-action rules explicitly specifies the triggering conditions, affected parameters, and UI adjustment behavior.

[0123] Each rule in the condition-action rule set clearly describes a causal relationship. A complete rule consists of three parts: the triggering condition, the affected parameters, and the interface adjustment behavior.

[0124] The trigger condition defines the prerequisite for a rule to be activated. This condition is usually a logical judgment based on the state of one or more debugging parameters. For example, a trigger condition could be "when the input value of parameter 'window width' is greater than 2000 mm", or "when parameter 'working mode' is set to 'silent mode'".

[0125] The affected parameters explicitly indicate which one or more other debugging parameters will be affected by this rule when the triggering condition is met. For example, in the case of window width, the affected parameter is "maximum opening angle".

[0126] Interface adjustment behaviors specify how the interface should change. This is a predefined action library containing various operations that can be applied to interface components. Common interface adjustment behaviors include: changing the maximum or minimum value of a numeric input box, disabling a button or slider, automatically filling a numeric input box, hiding or showing an interface element, or displaying an alert or prompt dialog box.

[0127] By converting all interdependencies into such "condition-action" rules, the system generates a complete rule set. This rule set is then embedded into dynamically generated webpage code, typically as a JavaScript script. When a debugger opens the webpage in a browser and performs actions, this script runs continuously in the background, monitoring the state of each interface component in real time. Once an action meets the trigger condition of a rule, the script immediately executes the interface adjustment behavior specified by that rule, thereby achieving dynamic changes to the interface.

[0128] In one specific implementation, suppose an electric door and window product has the following three interdependent parameters: operating mode (selectable values ​​are "Standard" and "Energy Saving"), operating speed (range 1-100), and motor noise level (range 1-5, read-only display). The dependency is as follows: in energy saving mode, the speed is limited to below 50, and the noise level is reduced accordingly. This dependency can be converted into the following two rules:

[0129] Rule 1:

[0130] Trigger condition: The selected value of the parameter "Running Mode" is equal to "Energy Saving".

[0131] Affected parameter: "Running speed".

[0132] Interface adjustment behavior: Set the maximum value of the "Running Speed" slider to 50. If the current value is greater than 50, it will automatically adjust to 50.

[0133] Rule Two:

[0134] Trigger condition: The selected value of the parameter "Running Mode" is equal to "Energy Saving".

[0135] Affected parameter: "Motor noise level".

[0136] Interface adjustment behavior: The corresponding noise level is calculated based on an internal function (e.g., 'calculateNoise('Energy Saving', currentSpeed)'), and the value of the read-only display box "Motor Noise Level" is updated. Here, 'calculateNoise' is the function name, indicating a dedicated function for calculating the noise level. Its function is to map the operating mode and current speed to a quantified noise value. 'Energy Saving' in the function represents the currently selected operating mode (or operating condition label). In this scheme, the system supports at least the "Energy Saving" mode; it also includes other modes such as "Standard" and "Powerful". Different modes have different noise baselines at the same speed. In Energy Saving mode, the motor torque / speed is usually lower, and the noise baseline is also lower. 'CurrentSpeed' is the real-time motor speed (in rpm). The higher the speed, the greater the aerodynamic and mechanical noise; therefore, the noise level increases monotonically with the speed.

[0137] When the technician switches the "Operating Mode" from "Standard" to "Energy Saving" in the drop-down menu on the webpage, the first rule's trigger condition is met, and the webpage script immediately adjusts the speed slider's upper limit to 50. Simultaneously, the second rule is also triggered; the script recalculates and displays a lower motor noise level based on the new mode and current speed. The entire process is instantaneous and seamless for the user, effectively guiding them to configure parameters appropriately.

[0138] Furthermore, step S3 includes:

[0139] S31: Obtain the operating characteristics of each independent control system, including startup time, settling time, and communication delay;

[0140] S32: Analyze the preset linkage rules and identify the parallel relationships and conditional dependencies between independent control systems;

[0141] S33: Based on operating characteristics, parallel relationships, and conditional dependencies, plan the commissioning paths for multiple independent control systems to determine the commissioning sequence that minimizes the overall commissioning time;

[0142] S34: Based on the debugging order, generate a debugging process view on the web debugging interface that supports parallel execution and conditional jumps, as a unified composite debugging view.

[0143] This includes the startup time of each independent control system from receiving a command to starting execution, the stabilization time required to reach a steady state after performing a certain action, and the round-trip delay of one communication with the commissioning equipment. This data can be obtained either by pre-setting it in the product feature database or by performing a quick automatic calibration at the start of commissioning.

[0144] Simultaneously, the system also reads the linkage rules for this complex product stored within the independent control system. These linkage rules define the interrelationships between different subsystems in the debugging logic. Parsing these linkage rules is primarily to identify two key relationships.

[0145] The first type is parallel processing, which refers to which debugging tasks can be performed simultaneously. For example, insulation testing of the window fan motor and reading the firmware version of the screen control board are two tasks that do not interfere with each other and can be processed in parallel.

[0146] The second type is conditional dependency, which refers to which tasks must follow a strict sequence. For example, the self-learning of the glass sash's movement must be completed and confirmed to be successful before the linkage anti-pinch test between the glass sash and the screen can be carried out. This is a typical example of conditional dependency.

[0147] The system then takes the acquired runtime characteristics (time cost) and the parsed logical relationships (parallelism and dependency constraints) as input and uses a planning algorithm to find an optimal debugging path. The algorithm's goal is very clear: to find an execution order that minimizes the total debugging time by maximizing the use of parallel operations while satisfying all dependencies. This is similar to a critical path analysis process in project management. The system arranges all debugging tasks, forming a network graph, and calculates the shortest time required to complete the entire debugging process. To explain it more easily, the planning algorithm treats each debugging task as a node and dependencies as directed edges, thus constructing a directed acyclic graph. When arranging debugging tasks, each node is labeled with two times: earliest start time and latest start time. Then, the total task duration for each node as the start and end point is calculated, and finally, the shortest time is found.

[0148] The final step is view generation. Based on the planned optimal debugging sequence, the system generates an intuitive debugging process view on the webpage. This view differs from a simple list of steps; it clearly displays the structure of the process. For example, it can use a flowchart format, placing tasks that can be executed in parallel side-by-side, while tasks with sequential dependencies are linked together with arrows. Each node in the view represents a debugging task and is interactive. When a debugger clicks on a task node, the corresponding parameter settings and operation buttons for that task will expand below. When a task is completed, the corresponding node on the flowchart will change its state, for example, turning green and being checked, while automatically activating the next or the next group of task nodes that can be started. For processes with conditional dependencies, such as a test step potentially having two results—"pass" or "fail"—the process view can also support conditional jumps, automatically guiding the debugger to different subsequent process branches based on the actual test results. This dynamic, visual debugging process view is the unified composite debugging view ultimately presented to the user, transforming the complex collaborative debugging process into a clear, map-guided process.

[0149] Furthermore, step S33 includes:

[0150] S331: Presets multiple logically feasible debugging sequences;

[0151] S332: For each of the multiple logically feasible debugging sequences, simulate execution based on runtime characteristics, parallel relationships, and conditional dependencies;

[0152] S333: Records the total debugging time for each simulation execution sequence;

[0153] S334: Select the order with the shortest overall debugging time from a variety of logically feasible debugging sequences as the debugging order.

[0154] This method employs a simulation and evaluation-based strategy to find the optimal solution. First, the system generates all logically feasible debugging sequences based on the resolved conditional dependencies. A logically feasible sequence must satisfy all hard constraints such as "A then B". However, for tasks that can be performed in parallel or whose order can be interchanged, multiple different permutations and combinations will arise. The system will pre-define or generate all these possible and valid debugging sequence schemes.

[0155] Next, the system will perform a "sandbox simulation" of each possible debugging sequence, i.e., a mock execution. During the simulation, the system will strictly adhere to known operational characteristic data (startup time, stabilization time, etc.) and parallel relationships. For each step in a sequence, the system will calculate its time consumption. If two steps are sequential, the total time is the sum of the two. If two steps are marked as parallelizable, then the simulation time of these two steps will be the longer one. The system will accumulate calculations step by step in this way until it simulates all the steps of a complete debugging sequence, ultimately obtaining the overall debugging time required to execute the scheme.

[0156] The system will perform such a simulation for each possible debugging sequence and record the calculated overall debugging time. For example, for a system containing a glass pane (A) and a screen (B), suppose there are four debugging tasks: A1 (system A self-test, 5 seconds), A2 (system A travel calibration, 15 seconds, dependent on A1), B1 (system B self-test, 8 seconds), and B2 (system B travel calibration, 10 seconds, dependent on B1). A1 and B1 can be performed in parallel, and A2 and B2 can be performed in parallel.

[0157] One possible order is: (A1, B1) parallel -> (A2, B2) parallel.

[0158] Simulation execution: The first stage (A1, B1) takes a parallel execution time of max(5, 8) = 8 seconds. The second stage (A2, B2) takes a parallel execution time of max(15, 10) = 15 seconds. The total debugging time is 8 + 15 = 23 seconds.

[0159] Another possible order is: A1 -> A2 -> B1 -> B2.

[0160] Simulated execution: This is a completely sequential process. Total debugging time = 5 + 15 + 8 + 10 = 38 seconds.

[0161] Through such simulations, the system can quantitatively evaluate the efficiency of different debugging sequences. After simulating all possible preset sequences, the system will have a list containing all sequence options and their corresponding total times. Finally, the system simply selects the sequence with the shortest overall debugging time from this list and uses this sequence as the final, optimal debugging sequence to generate the final debugging flow view. Although this method requires a certain amount of computation during the planning phase, it ensures that a theoretically most efficient debugging scheme is found under the current model.

[0162] Furthermore, step S4 includes:

[0163] S41: Convert the operations on the web debugging interface into debugging commands according to the debugging sequence;

[0164] S42: Obtain the communication protocol type and protocol version identified in the product identity information;

[0165] S43: Query the local protocol conversion module library to determine whether there is a conversion module in the local protocol conversion module library that matches the communication protocol type and protocol version;

[0166] S44: If there is no conversion module in the local protocol conversion module library that matches the communication protocol type and version, then request the preset protocol update server to download the conversion module that matches the communication protocol type and version, and load it into the local protocol conversion module library after successful download.

[0167] S45: Using conversion modules in the local protocol conversion module library that match the communication protocol type and version, debug commands are converted into low-level communication messages that the communication protocol can recognize and execute.

[0168] Specifically, when a debugger operates on the webpage and generates a standardized debugging command, the system first precisely extracts the communication protocol type name and specific version number from the product identity information, such as "Protocol Type: SuperBus, Protocol Version: 3.1". These two pieces of information are crucial for subsequently selecting the correct translation tool.

[0169] Next, the system will query a "local protocol conversion module library" in the local storage of the debugging device. This library contains all known software modules used to translate standard debugging commands into specific low-level messages. Each module corresponds to a specific protocol type and version. The system will check if a conversion module that exactly matches "SuperBus 3.1" exists in the library.

[0170] If the query result is "yes," meaning a matching conversion module already exists locally, the system will directly load and use that module. This module acts like a professional translator, receiving standard debugging commands as input and then outputting a string of binary low-level communication messages conforming to the SuperBus 3.1 protocol specification, which can be directly executed by the hardware.

[0171] However, in actual production, new communication protocols or upgraded versions of existing protocols constantly emerge. When debugging a door and window product using a completely new protocol, the local module library may not contain a matching conversion module. In this case, the system will initiate an online update mechanism. The debugging equipment will use its network connection to send a request to a pre-set protocol update server maintained by the company. This request will include the required protocol type and version number, i.e., "Request to download SuperBus 3.1 conversion module".

[0172] After receiving the request, the protocol update server searches for the corresponding module file in its more comprehensive central protocol library and returns it to the debugging device. The debugging device downloads this new conversion module file and doesn't just use it temporarily during the current debugging session; instead, it saves and loads it into its local protocol conversion module library. This way, the next time it encounters a product using the same protocol, it doesn't need to download it again and can directly use it from its local library.

[0173] After successfully acquiring a matching conversion module, whether loaded locally or newly downloaded from the server, the system utilizes this module to convert standardized debugging commands into underlying communication messages. The resulting message is then sent out via the wireless network, completing the closed loop of the entire debugging operation. This mechanism ensures the debugging system has strong survivability and backward compatibility, requiring no upgrades to the main program of the debugging device. Simply updating the protocol module online supports debugging all future new products.

[0174] Please refer to Figure 2 A system for debugging electric doors and windows using a standalone WIFI webpage, used to implement any of the above methods, the system includes:

[0175] Module 201: Connect the debugging device to the local wireless network emitted by the electric door and window control module, and obtain the product identity information of the electric door and window control module;

[0176] Module 202: Based on the product identity information, construct and display a web-based debugging interface from preset product feature data and interface components, containing only debugging parameters and operation options related to electric door and window products;

[0177] Arrangement Module 203: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web debugging interface, and the debugging order of multiple independent control systems is arranged according to the preset linkage rules.

[0178] Debugging module 204: Converts the operations on the web debugging interface into debugging commands according to the debugging sequence, and converts the debugging commands into underlying communication messages that can be recognized and executed by the communication protocol based on the communication protocol type identified in the product identity information.

[0179] The acquisition module 201 serves as the system's entry point and sensing unit. Its core responsibility is to establish a connection with the electric door / window to be debugged and accurately identify its identity. During actual operation, this module drives the wireless communication hardware of the debugging equipment to scan and connect to the target network, processes the connection credentials, and, after a successful connection, receives and verifies the product identity information packet sent from the control module. Finally, it extracts the accurate product identity information and transmits it to other parts of the system.

[0180] Module 202 is the core interactive interface generation unit of the system, responsible for transforming abstract product information into an intuitive visual operation interface. Based on the product identity information provided by the acquisition module, this module dynamically constructs and displays a web-based debugging interface from the system's preset product feature data and interface component library, containing only debugging parameters and operation options related to the current electric door and window product. It performs all the complex work mentioned in the aforementioned methods regarding dynamic interface generation, difference comparison, parameter range adjustment, dependency identification, and interface logic transformation, ensuring that the final interface presented to the user is highly customized, intelligent, and easy to operate.

[0181] The orchestration module 203 is the intelligent scheduling center for handling complex products, and it is only activated when the product to be debugged contains multiple independent control systems. This module analyzes the operating characteristics of each subsystem and the logical relationships between them, plans the optimal debugging path, and presents this path in the form of a visual flowchart, thereby guiding the debugging personnel to complete the collaborative debugging of complex products efficiently and accurately.

[0182] The debugging module 204 is the system's instruction execution unit, responsible for translating user operations on the webpage into low-level commands that the hardware can execute. Following the debugging sequence determined by the orchestration module (or the direct operation sequence in single-system mode), this module converts user operations on the webpage into standardized debugging instructions. Then, based on the communication protocol type identified in the product identification information, it calls the corresponding version of the protocol conversion module to accurately translate the standard instructions into low-level communication messages recognizable and executable by the target communication protocol, and sends them to the electric door and window control module via the wireless network. This module also includes management and online update functions for the protocol conversion module library, ensuring the system's long-term availability and scalability.

[0183] These four modules work together to form a complete and automated standalone WIFI web page debugging system, realizing the entire process from connection, identification, interface construction to process optimization and precise execution, thereby effectively solving various problems existing in the current technology.

[0184] 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. A method for debugging electric doors and windows using a standalone WIFI webpage, characterized in that, The method includes the following steps: S1: Connect the debugging equipment to the local wireless network emitted by the electric door and window control module, and obtain the product identity information of the electric door and window control module; S2: Based on the product identity information, construct and display a web-based debugging interface from preset product feature data and interface components, containing only debugging parameters and operation options related to the electric door and window product; wherein, when constructing the web-based debugging interface, identify the interdependencies between debugging parameters and convert the interdependencies into interface interaction logic, the interdependencies include dependencies reflecting physical constraints derived from the physical characteristics of the electric door and window indicated by the product identity information, and the interface interaction logic is used to display a warning message when a conflict is detected between the input parameter value and the interdependencies; S3: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web page debugging interface, and the debugging order of the multiple independent control systems is arranged according to the preset linkage rules; wherein, the debugging order is the order with the shortest overall debugging time selected from multiple logically feasible debugging orders by obtaining the operating characteristics of each independent control system and simulating execution based on the operating characteristics, parallel relationship and conditional dependency relationship. S4: Convert the operations on the web debugging interface into debugging commands according to the debugging order, and query the local protocol conversion module library according to the communication protocol type identified in the product identity information. If there is no conversion module matching the communication protocol type locally, request the preset protocol update server to download and load it into the local protocol conversion module library, and use the matching conversion module to convert the debugging commands into underlying communication messages.

2. The method for debugging electric doors and windows using a standalone WIFI webpage according to claim 1, characterized in that, Step S1 includes: S11: After the electric door and window control module is powered on, a local wireless network containing its unique identifier is broadcast, and a connection credential associated with the unique identifier is generated. S12: Control the debugging device to identify the connection credentials in order to establish a connection with the local wireless network; S13: After connecting to the local wireless network, control the electric door and window control module to send a product identity information packet in a preset format to the debugging device. The product identity information packet includes at least a data integrity check code. S14: After receiving the product identity information packet, the debugging device uses the data integrity check code to verify the data integrity. When the data integrity verification is successful, the product identity information is extracted from the product identity information packet.

3. The method for debugging electric doors and windows using a standalone WIFI webpage according to claim 1, characterized in that, Step S2 includes: S21: After obtaining the product identity information, control the debugging device to send a query command to the electric door and window control module to obtain the function list and parameter definition supported by the current firmware version of the electric door and window control module; S22: In the preset product feature data, traverse the real-time function list and the real-time parameter definition, and compare the first difference between the function list and the real-time function list, and the second difference between the parameter definition and the real-time parameter definition; S23: Based on the first difference, adjust the component selected from the preset interface components; based on the second difference, adjust the parameter range corresponding to the preset product feature data.

4. The method for debugging electric doors and windows using a standalone WIFI webpage according to claim 3, characterized in that, The interface interaction logic is also used to adjust the display range, available status, or set of optional options of other debugging parameters that are interdependent with it when the debugging device receives input from the debugging personnel for a certain parameter.

5. A method for debugging electric doors and windows using a standalone WIFI webpage according to claim 4, characterized in that, Step S2 also includes: S2411: Based on the product identity information, determine the functional module to which each debugging parameter belongs from the preset functional module and parameter type mapping data; S2412: Based on the functional modules, compare the parameter pairs associated with the functions to identify the basic interdependencies; S2413: Based on the physical characteristics of the electric doors and windows indicated in the product identity information and the adjusted parameter range, deduce the interdependence of physical constraints or operating conditions. S2414: Integrate the basic interdependencies and the interdependencies reflecting physical constraints or operating conditions to obtain the interdependencies between the debugging parameters.

6. A method for debugging electric doors and windows using a standalone WIFI webpage according to claim 4, characterized in that, The interface interaction logic is presented in the form of a set of condition-action rules; each rule in the set of condition-action rules explicitly specifies the triggering conditions, affected parameters, and interface adjustment behaviors.

7. A method for debugging electric doors and windows using a standalone WIFI webpage according to claim 1, characterized in that, Step S3 includes: S31: Obtain the operating characteristics of each of the independent control systems, including startup time, settling time, and communication delay; S32: Analyze the preset linkage rules and identify the parallel relationships and conditional dependencies between the independent control systems; S33: Based on the operating characteristics and the parallel and conditional dependencies, plan the debugging paths for multiple independent control systems to determine the debugging sequence that minimizes the overall debugging time; S34: Based on the debugging sequence, generate a debugging process view that supports parallel execution and conditional jump on the web debugging interface, as the unified composite debugging view.

8. A method for debugging electric doors and windows using a standalone WIFI webpage according to claim 7, characterized in that, Step S33 includes: S331: Presets multiple logically feasible debugging sequences; S332: For each of the multiple logically feasible debugging sequences, simulate execution based on the said running characteristics, the said parallel relationship, and the said conditional dependency relationship; S333: Records the total debugging time for each simulation execution sequence; S334: Select the order with the shortest overall debugging time from a variety of logically feasible debugging orders as the debugging order.

9. A method for debugging electric doors and windows using a standalone WIFI webpage according to claim 1, characterized in that, Step S4 includes: S41: Obtain the communication protocol type and protocol version identified in the product identity information; S42: Query the local protocol conversion module library to determine whether there is a conversion module in the local protocol conversion module library that matches the communication protocol type and the protocol version; S43: If there is no conversion module in the local protocol conversion module library that matches the communication protocol type and the protocol version, then request the download of the conversion module that matches the communication protocol type and the protocol version from the preset protocol update server, and load it into the local protocol conversion module library after successful download.

10. A system for debugging electric doors and windows using a standalone WIFI webpage, characterized in that, The system includes: Acquisition Module: Connects the debugging device to the local wireless network emitted by the electric door and window control module, and acquires the product identity information of the electric door and window control module; Construction Module: Based on the product identity information, constructs and displays a web-based debugging interface from preset product feature data and interface components, containing only debugging parameters and operation options related to the electric door and window product; wherein, when constructing the web-based debugging interface, the interdependencies between debugging parameters are identified, and the interdependencies are converted into interface interaction logic. The interdependencies include dependencies reflecting physical constraints derived from the physical characteristics of the electric door and window indicated by the product identity information. The interface interaction logic is used to display a warning message when a conflict is detected between the input parameter value and the interdependencies. Arrangement Module: If the product identity information indicates that the electric door and window product includes multiple independent control systems, a unified composite debugging view is provided on the web page debugging interface, and the debugging order of the multiple independent control systems is arranged according to preset linkage rules; wherein, the debugging order is selected from multiple logically feasible debugging orders by obtaining the operating characteristics of each independent control system, and simulating execution based on the operating characteristics, parallel relationship and conditional dependency relationship, and selecting the order with the shortest overall debugging time; Debugging Module: The module converts operations on the web debugging interface into debugging commands according to the debugging sequence. Based on the communication protocol type identified in the product identity information, it converts the debugging commands into underlying communication messages that the communication protocol can recognize and execute. It then queries the local protocol conversion module library. If no matching conversion module exists locally, it requests a download from a preset protocol update server and loads it into the local protocol conversion module library. Finally, it uses the matching conversion module to convert the debugging commands into underlying communication messages.

Images