Control method of home control terminal, home control terminal and system

Abstract

This disclosure provides a control method, a home control terminal, and a system for a home control terminal, relating to the field of smart home technology. The home control terminal of this disclosure includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway. The control method includes: the processor extracting a device identifier of a target device from control commands; determining a device object corresponding to the device identifier in a unified device model based on the device identifier of the target device, and extracting the corresponding protocol identifier from the device object; the protocol fusion gateway converting the control commands into a first command conforming to the KNX communication protocol when the protocol identifier is the KNX communication protocol, and converting the control commands into a second command conforming to the Zigbee communication protocol when the protocol identifier is the Zigbee communication protocol; and sending the first command to the target device via the KNX bus communication interface, or sending the second command to the target device via the Zigbee gateway module.

Description

Technical Field

[0001] This disclosure relates to the field of smart home technology, and in particular to a control method, home control terminal and system for a home control terminal. Background Technology

[0002] Smart home control systems typically employ either wired or wireless communication protocols to interconnect devices. The KNX communication protocol, using twisted-pair transmission, offers high reliability and stability, making it the mainstream choice for wired smart home systems in residential and commercial buildings. The Zigbee communication protocol, with its low power consumption and self-organizing network advantages, is the mainstream protocol for wireless smart home devices. Therefore, in practical applications, to balance the reliability of wired control with the flexibility of wireless deployment, a hybrid networking scheme combining KNX wired control with Zigbee wireless extension is often adopted.

[0003] In existing hybrid networking solutions, KNX and Zigbee devices typically rely on independent control applications for operation. Users need to frequently switch between different user interfaces when controlling the devices, making it impossible to achieve a unified device view and centralized control. Although some solutions achieve limited cross-protocol command forwarding through external protocol conversion gateways, this not only introduces additional hardware failure nodes but also often requires restarting the gateway when adding or changing devices, leading to service interruptions. Summary of the Invention

[0004] This disclosure provides a control method, a home control terminal, and a system for a home control terminal.

[0005] According to one aspect of this disclosure, a control method for a home control terminal is provided, which is applied to the home control terminal, the home control terminal including a processor, a Zigbee gateway module, a KNX bus communication interface and a protocol fusion gateway; The control method of the home control terminal includes: The processor extracts the device identifier of the target device from the received control command for the target device; based on the device identifier of the target device, it queries the unified device model to determine the device object in the unified device model corresponding to the device identifier, and extracts the corresponding protocol identifier from the device object, wherein the protocol identifier includes KNX communication protocol or Zigbee communication protocol; When the protocol identifier is KNX communication protocol, the protocol fusion gateway converts the control command into a first command conforming to the KNX communication protocol; when the protocol identifier is Zigbee communication protocol, it converts the control command into a second command conforming to the Zigbee communication protocol; and sends the first command to the target device through the KNX bus communication interface, or sends the second command to the target device through the Zigbee gateway module.

[0006] According to the control method of the home control terminal according to at least one embodiment of the present disclosure, a unified device model is constructed, including: The protocol fusion gateway broadcasts device query messages through the KNX bus communication interface to obtain the first device information of the KNX device, and initiates a network scan through the Zigbee gateway module to obtain the second device information of the Zigbee device; and maps the first device information and the second device information to standard field values ​​of the unified device model; The processor instantiates each KNX device and Zigbee device into a device object based on the standard field values ​​obtained from the mapping, thus obtaining a unified device model.

[0007] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the home control terminal further includes a touch screen display, the touch screen display being electrically connected to the processor; The processor further includes performing the following steps: Based on the received KNX bus status change event or Zigbee attribute reporting event, update the status field of the device object associated with the KNX bus status change event or Zigbee attribute reporting event; The status fields of each device object are rendered in the interactive interface of the touch screen to obtain a unified device status view.

[0008] According to a control method for a home control terminal according to at least one embodiment of the present disclosure, the protocol fusion gateway maintains a dynamic protocol mapping table, and each entry in the dynamic protocol mapping table includes an associated KNX group address, a Zigbee network address, a Zigbee endpoint identifier, and a Zigbee cluster identifier. When converting the control command into a first command conforming to the KNX communication protocol or a second command conforming to the Zigbee communication protocol, the following steps are included: When the protocol identifier is KNX communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the KNX group address corresponding to the device identifier, and the control command is converted into a first command that conforms to the KNX communication protocol and contains the KNX group address; When the protocol identifier is Zigbee communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the Zigbee network address, Zigbee endpoint identifier and Zigbee cluster identifier corresponding to the device identifier, and the control command is converted into a second command that conforms to the Zigbee communication protocol and includes the Zigbee network address, the Zigbee endpoint identifier and the Zigbee cluster identifier.

[0009] According to at least one embodiment of the control method for a home control terminal of the present disclosure, the protocol fusion gateway further includes performing the following steps: In response to received device change information, obtain a first copy of the currently used dynamic protocol mapping table; Based on the first copy, add, modify or delete entries in the first copy that correspond to the device change information to generate a second copy of the dynamic protocol mapping table; Perform a feasibility check on the second copy; If the feasibility check passes, the global mapping table pointer is switched from the first copy to the second copy; if the feasibility check fails, the second copy is discarded and the first copy continues to be used.

[0010] According to the control method of a home control terminal according to at least one embodiment of the present disclosure, after receiving a control command for a target device, the protocol fusion gateway further includes performing the following steps: Based on the received control command for the target device, extract the event trigger source identifier from the control command; The priority level of the control command is determined by querying the event trigger source identifier. When the priority level of the control instruction is the target level, the control instruction is assigned to the target instruction queue for execution, and the processing threads of other instruction queues other than the target instruction queue are interrupted and suspended. After the control instructions in the target instruction queue are executed, the target instruction queue is cleared, and the processing threads of other suspended instruction queues continue to be executed.

[0011] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: Send a heartbeat detection message to the KNX or Zigbee device to confirm the heartbeat detection result; When the heartbeat detection result of a KNX device or Zigbee device indicates a communication anomaly, shorten the heartbeat detection cycle for that KNX device or Zigbee device and implement a heartbeat detection retry strategy. During the execution of the heartbeat detection retry strategy, if the corresponding KNX device or Zigbee device remains unresponsive, an audible and visual alarm signal will be issued, an alarm notification will be pushed to the mobile application, and a fault log will be recorded. If the continuous offline time of the corresponding KNX device or Zigbee device exceeds the target time threshold, an alarm data packet is pushed to the cloud server, and the cloud server generates a maintenance work order based on the alarm data packet.

[0012] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: In response to scene linkage trigger events, the first and second commands that exist simultaneously are sent synchronously to the corresponding KNX and Zigbee devices; For each first instruction and second instruction, listen for the corresponding device report signal. If no device report signal is received within the response time threshold, it is determined that the device response has timed out, and the corresponding first instruction or second instruction is resent. If no response signal is received from the device after the number of resends reaches the threshold, a communication anomaly alarm policy will be triggered and executed.

[0013] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: When a connection interruption with the cloud server is detected, the control mode is switched to local autonomous mode; Store incremental operation records generated during the local autonomy mode to the local cache; When reconnecting to the cloud server, the control mode is switched to cloud linkage mode, and the locally cached operation records are incrementally uploaded to the cloud server in chronological order.

[0014] According to at least one embodiment of the control method for a home control terminal of the present disclosure, the protocol fusion gateway further includes performing the following steps: Collect KNX bus load rate, Zigbee signal strength value, link quality indicators and command transmission success rate; Based on the collected KNX bus load rate, Zigbee signal strength value, link quality index and command transmission success rate, the routing score of the current communication link is calculated. The routing score is used to characterize the signal transmission quality of the communication link. When the routing score of the current communication link is less than a preset routing quality threshold, the system switches to a backup communication link for communication.

[0015] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: Construct a baseline model of user behavior based on historical user operation data; Based on the user behavior baseline model, predict user operation intentions, and generate and cache the corresponding pre-issued instruction set based on the user operation intention prediction results; In response to a trigger event for the pre-delivered instruction set, the instructions contained in the pre-delivered instruction set are sent to the corresponding KNX device or Zigbee device.

[0016] According to the control method of a home control terminal according to at least one embodiment of the present disclosure, after constructing a user behavior baseline model, the processor further includes performing the following steps: Based on the received control commands for the target device and the user behavior baseline model, a user behavior deviation score is determined between the control commands and the user behavior baseline model. When the user behavior deviation score is greater than or equal to a preset abnormal score threshold, the control command is suspended and a secondary confirmation message is displayed on the interactive interface of the home control terminal. In response to the operation on the secondary confirmation information, the suspended control command is executed or discarded.

[0017] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: Construct virtual digital twins corresponding to each KNX and Zigbee device; Based on the scene instruction set configured for the target scene, virtual state changes are performed on the virtual digital twins corresponding to the KNX devices or Zigbee devices associated with the instructions in the scene instruction set, and simulation preview results are generated and displayed on the interactive interface of the home control terminal. In response to the confirmation operation of the simulation preview result, the instructions contained in the scene instruction set are sent to the corresponding KNX device or Zigbee device.

[0018] According to a control method for a home control terminal based on at least one embodiment of the present disclosure, the processor further includes performing the following steps: Collect health status data for each KNX and Zigbee device; Based on the health status data of each KNX device and Zigbee device, a fault risk analysis is performed to obtain the fault risk analysis results corresponding to each KNX device and Zigbee device. Based on the failure risk analysis results, predictive maintenance alarm information corresponding to the KNX device or Zigbee device is generated.

[0019] According to another aspect of this disclosure, a home control terminal is provided, including a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway; the home control terminal is used to execute the control method of the home control terminal as described in any embodiment of this disclosure.

[0020] According to another aspect of this disclosure, a home control system is provided, including a cloud server and a home control terminal that communicate with each other. The home control terminal includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway. The home control terminal is used to execute the control method of the home control terminal as described in any embodiment of this disclosure.

[0021] According to another aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement a control method of a home control terminal according to any embodiment of this disclosure.

[0022] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements a control method for a home control terminal according to any embodiment of this disclosure.

[0023] The beneficial effects of this disclosure are that the home control terminal includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway. The processor, based on the received control command for the target device, extracts the device identifier of the target device from the control command. Then, it queries a unified device model to determine the device object and protocol identifier corresponding to this device identifier. This protocol identifier includes either the KNX communication protocol or the Zigbee communication protocol. Next, the protocol fusion gateway, based on the queried protocol identifier, converts the control command into a first command or a second command conforming to the corresponding communication protocol, achieving unified generation of cross-protocol control commands. The converted first command or second command is then sent by the protocol fusion gateway to the target device via the KNX bus communication interface or the Zigbee gateway module, respectively. Thus, without switching between two independent control applications or relying on an external independent protocol conversion gateway, unified management and control of KNX and Zigbee devices can be achieved on the same home control terminal, improving the integration and ease of operation of home control. Attached Figure Description

[0024] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0025] Figure 1 This is a schematic structural block diagram of a home control terminal according to one embodiment of the present disclosure.

[0026] Figure 2 This is a flowchart illustrating a control method for a home control terminal according to one embodiment of the present disclosure.

[0027] Figure 3 This is a schematic diagram of the process of constructing a unified device model in the control method of a home control terminal according to one embodiment of the present disclosure.

[0028] Figure 4 This is a flowchart illustrating the rendering of a unified state view of a device in a control method for a home control terminal according to one embodiment of the present disclosure.

[0029] Figure 5 This is a schematic flowchart illustrating the translation of control commands in a control method for a home control terminal according to one embodiment of the present disclosure.

[0030] Figure 6 This is a schematic diagram of the process of updating a dynamic protocol mapping table in a control method for a home control terminal according to one embodiment of the present disclosure.

[0031] Figure 7 This is a flowchart illustrating the allocation of priority levels in a control method for a home control terminal according to one embodiment of the present disclosure.

[0032] Figure 8 This is a schematic diagram of the fault self-diagnosis process in the control method of a home control terminal according to one embodiment of the present disclosure.

[0033] Figure 9 This is a schematic diagram of the control method for monitoring instruction response timeout of a home control terminal according to one embodiment of the present disclosure.

[0034] Figure 10 This is a schematic diagram of the control mode switching process in a control method for a home control terminal according to one embodiment of the present disclosure.

[0035] Figure 11 This is a schematic diagram of the routing switching process in a control method for a home control terminal according to one embodiment of the present disclosure.

[0036] Figure 12This is a schematic flowchart of the instruction prediction process in a control method for a home control terminal according to one embodiment of the present disclosure.

[0037] Figure 13 This is a schematic flowchart of the behavior deviation detection process in the control method of a home control terminal according to one embodiment of the present disclosure.

[0038] Figure 14 This is a flowchart illustrating the scene configuration preview in a control method for a home control terminal according to one embodiment of the present disclosure.

[0039] Figure 15 This is a schematic diagram of the predictive maintenance alarm process in a control method for a home control terminal according to one embodiment of the present disclosure.

[0040] Figure 16 This is a schematic structural block diagram of a home control system according to one embodiment of the present disclosure.

[0041] Figure 17 This is a flowchart illustrating a control method for a home control terminal according to another embodiment of the present disclosure. Detailed Implementation

[0042] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0043] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0044] Existing technologies make it difficult to achieve unified management and control of KNX and Zigbee devices, resulting in fragmented cross-protocol control logic and cumbersome operation.

[0045] To address this, this disclosure proposes the following technical solution, in which the home control terminal includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway. The processor, upon receiving a control command for a target device, extracts the device identifier of the target device from the control command. It then queries a unified device model to determine the device object and protocol identifier corresponding to this device identifier. This protocol identifier includes either the KNX communication protocol or the Zigbee communication protocol. Next, the protocol fusion gateway, based on the queried protocol identifier, converts the control command into a first command or a second command conforming to the corresponding communication protocol, achieving unified generation of cross-protocol control commands. The converted first command or second command is then sent by the protocol fusion gateway to the target device via the KNX bus communication interface or the Zigbee gateway module, respectively. Thus, without switching between two independent control applications or relying on an external independent protocol conversion gateway, unified management and control of KNX and Zigbee devices can be achieved on the same home control terminal, improving the integration and ease of operation of home control.

[0046] Figure 1 This is a schematic structural block diagram of a home control terminal according to one embodiment of the present disclosure.

[0047] like Figure 1 As shown, the home control terminal 100 preferably includes a processor 110, a Zigbee gateway module 120, a KNX bus communication interface 130, and a protocol fusion gateway 140 integrated therein.

[0048] For example, the processor 110 runs a unified control management platform, which is responsible for core functions such as processing control commands, maintaining a unified device model, and diagnosing routing faults.

[0049] The Zigbee gateway module 120 is used to manage the Zigbee wireless network and is responsible for managing Zigbee devices, including Zigbee device access, changes, address allocation, and command transmission.

[0050] The KNX bus communication interface 130 is used to connect to the KNX bus and is responsible for sending and receiving KNX messages (such as the first instruction) and transmitting KNX device-related information (such as device status change event information of the KNX device).

[0051] Protocol fusion gateway 140, which serves as a cross-protocol instruction scheduling and routing hub, is connected to processor 110, Zigbee gateway module 120, and KNX bus communication interface 130. Protocol fusion gateway 140 includes a KNX interface unit, a Zigbee coordinator unit, and a protocol mapping engine.

[0052] The KNX interface unit is responsible for physical and protocol-level interaction with the KNX bus. For example, it broadcasts device query messages to the KNX bus to discover KNX devices, collects the physical address, group address and data point type of each KNX device, and reports the received device status change events to the processor 110. The KNX interface unit receives the KNX message (i.e. the first instruction) converted by the protocol mapping engine, sends it to the corresponding KNX device through the KNX bus communication interface 130, and receives the confirmation information returned by the KNX device.

[0053] The Zigbee coordinator unit, acting as the coordinator of the Zigbee network, is responsible for initiating network scans to discover Zigbee devices, collecting device information from each Zigbee device, and performing Zigbee device network access authentication. Simultaneously, the Zigbee coordinator unit receives command frames (i.e., second instructions) from the Zigbee cluster library after conversion by the protocol mapping engine, wirelessly distributes them to the corresponding Zigbee devices via the Zigbee gateway module, and receives confirmation information reported by the Zigbee devices.

[0054] The protocol mapping engine maintains a dynamic protocol mapping table. Each entry in this table contains four fields: the associated KNX group address, the Zigbee network address, the Zigbee endpoint identifier, and the Zigbee cluster identifier. Preferably, this dynamic protocol mapping table uses a hash-indexed doubly linked list structure to achieve constant-time lookup. This allows the system to query the dynamic protocol mapping table based on the target device's device identifier and protocol identifier to obtain cross-protocol address mappings, translating unified control commands into first or second commands conforming to the target communication protocol format (such as the KNX or Zigbee communication protocol).

[0055] In one embodiment, the home control terminal 100 further includes a touch display screen 150 electrically connected to the processor 110, which is used to present a unified status view of KNX devices and Zigbee devices, receive touch operations input by the user, and transmit control commands triggered by the user to the processor 110.

[0056] In some examples, the home control terminal disclosed herein may be a smart home central control screen device with an integrated touch display, serving as the core interactive entry point for whole-house intelligence. In other examples, the home control terminal may also be an embedded control host without a touch display, operated via a mobile application or voice assistant.

[0057] Figure 2 This is a schematic flowchart of a control method for a home control terminal according to one embodiment of the present disclosure. The control method of this home control terminal can be applied to, for example... Figure 1The home control terminal shown.

[0058] like Figure 2 As shown, the control method of the home control terminal preferably includes steps S210 to S220.

[0059] In step S210, the processor extracts the device identifier of the target device from the received control instruction for the target device; based on the device identifier of the target device, it queries the unified device model to determine the device object in the unified device model corresponding to the device identifier, and extracts the corresponding protocol identifier from the device object. The protocol identifier includes the KNX communication protocol or the Zigbee communication protocol.

[0060] The unified device model is a pre-built cross-protocol device abstract data structure that can be maintained on the processor's unified control and management platform. The unified device model instantiates an abstract device object in memory for each KNX or Zigbee device to store the corresponding device's static attributes and dynamic states. Preferably, this device object includes at least a device identifier, a current state field, and a protocol identifier (indicating the communication protocol type to which the device belongs).

[0061] In this embodiment, after receiving a control command for a target device, the processor parses the control command and extracts the device identifier of the target device. Preferably, the device identifier of a KNX device is its physical address, and the device identifier of a Zigbee device is its IEEE 64-bit address.

[0062] The processor queries the unified device model based on the extracted device identifier to determine the device object corresponding to that identifier. Next, it extracts a protocol identifier from the determined device object, thereby determining the communication protocol type of the target device based on the protocol identifier. Preferably, the protocol identifier includes the KNX communication protocol or the Zigbee communication protocol.

[0063] In step S220, if the protocol identifier is KNX communication protocol, the protocol fusion gateway converts the control command into a first command conforming to the KNX communication protocol; if the protocol identifier is Zigbee communication protocol, the control command converts the control command into a second command conforming to the Zigbee communication protocol; and sends the first command to the target device through the KNX bus communication interface, or sends the second command to the target device through the Zigbee gateway module.

[0064] In this embodiment, after determining the protocol identifier, the processor sends the control command along with the protocol identifier to the protocol fusion gateway. When the protocol identifier is the KNX communication protocol, the protocol fusion gateway converts the control command into a first command conforming to the KNX communication protocol (such as a KNX message). The converted first command is then transmitted to the KNX bus communication interface via the KNX interface unit, and the KNX bus communication interface sends the first command to the target device.

[0065] When the protocol is identified as the Zigbee communication protocol, the protocol fusion gateway converts the control command into a second command conforming to the Zigbee communication protocol (such as a Zigbee control command frame). Then, the converted second command is sent to the Zigbee gateway module via the Zigbee coordinator unit, and the Zigbee gateway module transmits it to the target device in the Zigbee network via the 2.4GHz radio frequency channel.

[0066] In some embodiments of this disclosure, constructing a unified device model preferably includes steps S310 to S320, please refer to... Figure 3 .

[0067] In step S310, the protocol fusion gateway broadcasts a device query message through the KNX bus communication interface to obtain the first device information of the KNX device, and initiates a network scan through the Zigbee gateway module to obtain the second device information of the Zigbee device; the first device information and the second device information are mapped to standard field values ​​of the unified device model.

[0068] In step S320, the processor instantiates each KNX device and Zigbee device into device objects based on the standard field values ​​obtained from the mapping, thus obtaining a unified device model.

[0069] In this embodiment, after the home control terminal is powered on or restarted, the KNX interface unit of the protocol fusion gateway broadcasts a device query message to the KNX bus via the KNX bus communication interface. Upon receiving the device query message, all connected KNX devices on the KNX bus respond with their own first device information. Preferably, this first device information includes the physical address of the KNX device, the KNX group address, and the data point type.

[0070] Simultaneously, the Zigbee coordinator unit of the protocol convergence gateway initiates a network scan through the Zigbee gateway module to collect second device information of each Zigbee device entering the network. Preferably, this second device information includes the Zigbee device's IEEE 64-bit address, network short address (2 bytes), endpoint identifier, and the supported Zigbee cluster library cluster identifier (i.e., the aforementioned Zigbee cluster identifier).

[0071] After device discovery is complete, the protocol fusion gateway maps the acquired first and second device information to standard field values ​​of a unified device model. Specifically, for each discovered KNX device, the protocol fusion gateway maps its physical address to the "device unique identifier" field value, its data point type corresponding to the function category to the "device type" field value (e.g., lighting, shading), its KNX group address to the "current status value" field value, its KNX message format specification to the "control command set" field value, sets the "protocol identifier" field value to the "KNX communication protocol," and sets the "location information" field value (e.g., living room, master bedroom) according to user presets or system configuration.

[0072] For each discovered Zigbee device, the protocol fusion gateway maps its IEEE 64-bit address to the "Device Unique Identifier" field value, maps the Zigbee cluster library function type to the "Device Type" field value, maps the current read value of the Zigbee cluster library attribute to the "Current Status Value" field value, maps the Zigbee cluster library command format to the "Control Command Set" field value, sets the "Protocol Identifier" field value to the "Zigbee Communication Protocol," and sets the "Location Information" field value according to user presets or system configuration.

[0073] After mapping is complete, the protocol fusion gateway sends the standard fields and their values ​​to the processor. Based on the received standard fields and their values, the processor instantiates a device object in memory for each KNX and Zigbee device. Each device object stores the standard field information (including the standard fields and their values) for the corresponding KNX or Zigbee device. Then, all device objects are organized into a device object tree to obtain a unified device model.

[0074] Preferably, after obtaining the unified device model, the processor associates each device object in the unified device model with the relevant entries in the dynamic protocol mapping table, thereby supporting bidirectional lookup and control instruction translation.

[0075] Therefore, the protocol fusion gateway proactively performs device discovery and completes field mapping, unifying the first and second device information of different communication protocols into a standard format, which is then instantiated by the processor to obtain a unified device model. Through this unified device model, upper-layer applications (such as scene linkage, fault diagnosis, etc.) can achieve unified management and control of KNX devices and Zigbee devices without distinguishing between device types.

[0076] In some embodiments of this disclosure, the processor preferably further includes execution steps S410 to S420, please refer to Figure 4 .

[0077] In step S410, the status field of the device object associated with the KNX bus status change event or Zigbee attribute reporting event is updated according to the received KNX bus status change event or Zigbee attribute reporting event.

[0078] In step S420, the status fields of each device object are rendered in the interactive interface of the touch screen to obtain a unified status view of the device.

[0079] In this implementation, the processor's unified control management platform subscribes to KNX bus state change events and Zigbee attribute reporting events. KNX bus state change events are notifications proactively reported by KNX devices via the KNX bus when the state of a KNX device changes (e.g., lights are manually switched on / off, curtain motors are in operation, or thermostat temperatures change). Zigbee attribute reporting events are notifications of attribute updates reported by Zigbee devices when they proactively report or respond to queries.

[0080] When the processor receives any of the above events (i.e., KNX bus status change event or Zigbee attribute reporting event), it extracts the device identifier and latest status value of the KNX device or Zigbee device from the event. Based on the extracted device identifier, it quickly locates the device object corresponding to the KNX device or Zigbee device and updates the value of the status field (i.e., the aforementioned "current status value" field) of the device object to the latest status value.

[0081] After the status update is completed, the processor traverses the device objects in the unified device model, reads the device identifier, device type, current status value and location information of each device object, organizes this data into a unified device status view, and renders it on the interactive interface of the touch screen, visually displaying the current status of each KNX device or Zigbee device in the form of text, color, charts or progress bars.

[0082] Therefore, by using an event subscription-driven device current status update mechanism, the status data of KNX and Zigbee devices are rendered and presented in a unified manner, allowing users to view the status of all devices in the house without frequently switching between operating interfaces.

[0083] In some embodiments of this disclosure, when converting control commands into first commands conforming to the KNX communication protocol or second commands conforming to the Zigbee communication protocol, steps S510 to S520 are preferably included. Please refer to [link / reference]. Figure 5 .

[0084] In step S510, if the protocol identifier is KNX communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the KNX group address corresponding to the device identifier, and the control command is converted into a first command that conforms to the KNX communication protocol and contains the KNX group address.

[0085] In step S520, if the protocol identifier is Zigbee communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the Zigbee network address, Zigbee endpoint identifier and Zigbee cluster identifier corresponding to the device identifier, and the control command is converted into a second command that conforms to the Zigbee communication protocol and contains the Zigbee network address, Zigbee endpoint identifier and Zigbee cluster identifier.

[0086] In this implementation, when the protocol identifier is the KNX communication protocol, the protocol mapping engine in the protocol fusion gateway queries the dynamic protocol mapping table based on the target device's device identifier (i.e., the unique device identifier in the unified device model, such as the KNX physical address). Since this dynamic protocol mapping table uses a hash-indexed doubly linked list structure, the lookup process can be completed in constant time complexity. After a successful query, the protocol mapping engine obtains the KNX group address field corresponding to the KNX device. Subsequently, the protocol mapping engine encodes the control commands issued by the processor according to the KNX message format specification and encapsulates them together with the queried KNX group address into a complete KNX message. After encapsulation, the KNX message is transmitted as the first instruction to the KNX interface unit within the protocol fusion gateway, and then sent through the KNX bus communication interface.

[0087] When the protocol identifier is Zigbee communication protocol, the protocol mapping engine also uses the target device's device identifier as the search keyword to query the dynamic protocol mapping table. Upon successful query, the protocol mapping engine obtains three field values ​​corresponding to the target device: Zigbee network address, Zigbee endpoint identifier, and Zigbee cluster identifier. These three fields together constitute the complete addressing information for locating the specific functional module of the device in the Zigbee network. The Zigbee network address indicates a specific Zigbee device, the Zigbee endpoint identifier indicates a specific functional module on that Zigbee device, and the Zigbee cluster identifier indicates which set of commands in the Zigbee Cluster Library (ZCL) is supported by that functional module. Subsequently, the protocol mapping engine converts the control instructions issued by the processor into Zigbee Cluster Library (ZCL) standard command frames, and encapsulates the converted ZCL standard command frames together with the retrieved Zigbee network address, Zigbee endpoint identifier, and Zigbee cluster identifier into a complete second instruction. The second instruction is transmitted to the Zigbee coordinator unit of the protocol convergence gateway, and then sent to the target device via the Zigbee gateway module.

[0088] Therefore, based on the dynamic protocol mapping table, the protocol fusion gateway can automatically and quickly complete the address translation according to the device identifier, without the need for manual maintenance of address correspondence, which greatly reduces the complexity of system configuration.

[0089] In some embodiments of this disclosure, the protocol fusion gateway preferably further includes steps S610 to S640, please refer to... Figure 6 .

[0090] In step S610, in response to the received device change information, a first copy of the currently used dynamic protocol mapping table is obtained.

[0091] In step S620, based on the first copy, add, modify or delete entries in the first copy that correspond to the device change information, and generate a second copy of the dynamic protocol mapping table.

[0092] In step S630, a feasibility check is performed on the second copy.

[0093] In step S640, if the feasibility check passes, the global mapping table pointer is switched from the first copy to the second copy; if the feasibility check fails, the second copy is discarded and the first copy continues to be used.

[0094] In this implementation, when a device change occurs (e.g., adding a Zigbee device or removing a KNX device), the unified control management platform generates device change information and sends it to the protocol fusion gateway. Upon receiving this device change information, the protocol mapping engine in the protocol fusion gateway obtains the first copy of the currently used dynamic protocol mapping table (i.e., the version of the dynamic protocol mapping table pointed to by the current global mapping table pointer).

[0095] Then, based on this first copy, the protocol mapping engine performs add, modify, or delete operations only on entries involved in the device change information. For example, if a new device is added, a new entry is added to the first copy; if a device is deleted, the corresponding entry is removed from the first copy; if a device is modified, the fields of the corresponding entry are updated based on the first copy. For entries that have not changed, they are reused unchanged. Through the above incremental reconstruction method, a second copy of the dynamic protocol mapping table is generated. During this period, the first copy continues to respond to all query requests, and the user is unaware of it.

[0096] After the second copy is generated, the protocol mapping engine performs a feasibility check. Preferably, the feasibility check includes integrity check, index bidirectional reachability check, changeset integrity check, and quantity reasonableness check. Specifically, the integrity check involves traversing all entries in the second copy and checking whether the four fields of each entry are in a valid format, without null pointers, and without missing fields; the index bidirectional reachability check verifies whether the forward hash index (e.g., finding the corresponding Zigbee network address through the KNX group address) and the reverse linked list index (e.g., finding the corresponding KNX group address through the Zigbee network address) are mutually reachable, ensuring consistency in bidirectional lookups; the changeset integrity check verifies that the number of entries actually added, modified, or deleted in the second copy matches the number of entries involved in the device change information; the quantity reasonableness check verifies whether the total number of entries in the second copy is equal to the total number of entries in the first copy plus the number of newly added entries minus the number of deleted entries.

[0097] If any of the four checks fails, the second copy is deemed to have failed the feasibility check. In this case, the protocol mapping engine discards the second copy and continues to use the first copy to respond to queries. If the second copy passes the feasibility check, the protocol mapping engine uses a CAS (Compare-And-Swap) atomic instruction to atomically switch the global mapping table pointer from the first copy to the second copy. Since the CAS atomic instruction is a single CPU instruction set operation, the switching time is less than 1 microsecond, and it does not produce an intermediate state where the pointer points to invalid memory.

[0098] At the moment the switchover is complete, all newly arriving query requests immediately access the second copy through the new pointer, while old threads that are currently querying the first copy continue reading data from it. After the switchover, the protocol mapping engine maintains an atomic reference count for the first copy. The count is incremented by 1 each time a query thread reads the first copy and decremented by 1 when the read is complete. When the atomic reference count reaches zero (i.e., all queries to the first copy have ended), the memory of the first copy is safely released, completing the hot update of the dynamic protocol mapping table.

[0099] This enables zero-downtime hot updates of the dynamic protocol mapping table. Throughout the entire hot update process, the query service remains uninterrupted, and device changes do not require restarting the gateway or home control terminal.

[0100] In some embodiments of this disclosure, after receiving a control command for the target device, the protocol fusion gateway preferably further includes executing steps S710 to S740, please refer to... Figure 7 .

[0101] In step S710, the event trigger source identifier is extracted from the received control command for the target device.

[0102] In step S720, the priority level of the control command is determined by querying the event trigger source identifier.

[0103] In step S730, when the priority level of the control instruction is the target level, the control instruction is assigned to the target instruction queue for execution, and the processing threads of other instruction queues other than the target instruction queue are interrupted and suspended.

[0104] In step S740, after the control instructions in the target instruction queue are executed, the target instruction queue is cleared, and the processing threads of other suspended instruction queues continue to be executed.

[0105] The event trigger source identifier is used to distinguish the triggering entity and business attribute of the control command. Preferably, the event trigger source identifier includes, but is not limited to, security sensor alarm identifiers, user manual touch identifiers, and timed task identifiers. Security sensors include smoke sensors, thermal sensors, gas concentration sensors, and door / window magnetic induction sensors.

[0106] Priority levels are the order in which control commands are processed, based on their urgency. Preferably, the priority levels in this embodiment include a first level (P0, urgent, processing time < 50ms, with full preemption rights, used for fire alarms / security), a second level (P1, normal, used for user scenario linkage, without strict time limits), and a third level (P2, low priority, used for status polling, etc., allowing for larger delays).

[0107] In this implementation, when the protocol fusion gateway receives the control command issued by the processor, the three-level priority queue scheduler in the protocol fusion gateway parses the control command and extracts the event trigger source identifier contained therein.

[0108] By querying the pre-defined priority mapping rules, the three-level priority queue scheduler determines the priority level corresponding to the event trigger source identifier. When the priority level of the control instruction is determined to be the target level (i.e., the highest priority level, such as the first level above), the three-level priority queue scheduler triggers a full preemptive scheduling mechanism, assigning the control instruction to the target instruction queue (a dedicated message queue for storing the highest priority control instructions, which has full preemptive rights and strict processing time constraints).

[0109] Simultaneously, the Level 3 Priority Queue Scheduler checks if there are processing threads for other instruction queues besides the target instruction queue (such as processing threads for instruction queues corresponding to the aforementioned Level 2 or Level 3). If so, the Level 3 Priority Queue Scheduler interrupts and suspends the processing threads for other instruction queues. This ensures that emergency security instructions such as fire alarm linkage, gas leak shut-off, or illegal intrusion alarms are issued with exclusive priority.

[0110] The Level 3 Priority Queue Scheduler retrieves control instructions from the target instruction queue and allocates CPU resources for execution. During execution, it will not be interrupted by control instructions from other instruction queues. After each instruction is executed, the Level 3 Priority Queue Scheduler removes it from the target instruction queue until the target instruction queue is completely empty.

[0111] Once the target instruction queue is empty, the three-level priority queue scheduler continues to execute the processing threads of other previously suspended instruction queues. Preferably, the three-level priority queue scheduler executes the suspended processing threads in the order of last suspended to first resumed, or in descending order of priority (e.g., executing second-level control instructions before third-level control instructions).

[0112] Therefore, priority levels are automatically determined based on the event trigger source identifier, ensuring that emergency security control commands such as fire alarms and gas leaks can be automatically identified and prioritized. Furthermore, target-priority control commands employ a full preemption mechanism, which can immediately interrupt other low-priority processing threads that are currently executing, guaranteeing real-time response to emergency security control commands.

[0113] In some embodiments of this disclosure, the processor preferably further includes execution steps S810 to S840, please refer to Figure 8 .

[0114] In step S810, a heartbeat detection message is sent to the KNX device or Zigbee device to determine the heartbeat detection result; In step S820, when the heartbeat detection result of the KNX device or Zigbee device is a communication anomaly, the heartbeat detection cycle of the KNX device or Zigbee device is shortened and a heartbeat detection retry strategy is executed.

[0115] In step S830, during the execution of the heartbeat detection retry strategy, if the corresponding KNX device or Zigbee device continues to be unresponsive, an audible and visual alarm signal is issued, an alarm notification is pushed to the mobile application, and a fault log is recorded.

[0116] In step S840, if the continuous offline time of the corresponding KNX device or Zigbee device exceeds the target time threshold, an alarm data packet is pushed to the cloud server, and the cloud server generates a maintenance work order based on the alarm data packet.

[0117] Among them, the heartbeat detection message is information sent periodically to the controlled devices (i.e., KNX devices and Zigbee devices) to detect the online status of the devices.

[0118] In this embodiment, the fault self-diagnosis module in the processor's unified control and management platform sends heartbeat detection messages to all KNX and Zigbee devices simultaneously at fixed intervals via a unified heartbeat engine during device operation. Preferably, for KNX devices, the heartbeat detection messages are sent through the KNX bus communication interface; for Zigbee devices, the heartbeat detection messages are sent through the Zigbee gateway module.

[0119] Each controlled device should respond within a specified time after receiving the heartbeat probe message. If a controlled device fails to respond within the time limit, the heartbeat probe result of that controlled device will be marked as "communication abnormal". At this time, the fault self-diagnosis module triggers the first-level fault alarm mechanism.

[0120] In the first-level fault alarm mechanism, the fault self-diagnosis module shortens the heartbeat detection cycle of the controlled device with communication abnormalities (e.g., shortening the heartbeat detection cycle from the original 30s to 15s) to monitor its status more intensively. Next, the fault self-diagnosis module executes a heartbeat detection retry strategy on the controlled device, retrying the heartbeat detection a maximum of a preset number of times (e.g., 3 times) according to the shortened heartbeat detection cycle. If any response is received from the controlled device during the execution of the heartbeat detection retry strategy, the fault self-diagnosis module determines that the controlled device has recovered, clears its "communication abnormality" flag, and restores its heartbeat detection cycle.

[0121] Preferably, when a first-level fault alarm is triggered, the fault self-diagnosis module changes the icon of the controlled device with communication abnormality to yellow in the unified device status view of all controlled devices and displays a "communication abnormality" label. The fault self-diagnosis module also pushes a yellow alarm notification through a mobile application (such as a smartphone APP), which includes the device name, device location, and the text "communication abnormality, retrying".

[0122] If no response is received from the controlled device with the communication error after the heartbeat detection retry strategy has been executed, the fault self-diagnosis module determines that the controlled device is offline and triggers the second-level fault alarm mechanism.

[0123] In the second-level fault alarm mechanism, the fault self-diagnosis module drives the home control terminal's audible and visual alarm to issue audible and visual alarm signals (including sound prompts and flashing lights). Simultaneously, the fault self-diagnosis module pushes a red alarm notification via the mobile application, which includes the device name, device location, and the message "Device Offline." Next, the fault self-diagnosis module records a fault log, preferably containing five elements: device identifier, protocol type, current timestamp, device location, and error code. This fault log is stored in the home control terminal's local storage space for later retrieval.

[0124] During the execution of the second-level fault alarm mechanism, the fault self-diagnosis module continues to perform heartbeat detection on the controlled devices determined to be offline at a shortened heartbeat detection cycle. If the continuous offline time of the controlled device exceeds the preset target duration threshold (e.g., 5 minutes), the third-level fault alarm mechanism is triggered.

[0125] In this third-level fault alarm mechanism, the fault self-diagnosis module changes the icon of the controlled device to purple in the unified device status view and displays a "Severe Offline" indicator. Simultaneously, the fault self-diagnosis module pushes alarm data packets to the cloud server via an encrypted long-lived connection (such as TLS 1.3). These alarm data packets contain fault logs, a complete timeline record from the triggering of the first-level fault alarm mechanism to the triggering of the third-level fault alarm mechanism, records of all heartbeat probe retry attempts, and recent communication link quality data (such as RSSI / LQI data).

[0126] Upon receiving the alarm data packet, the cloud server automatically generates a maintenance work order based on the information contained within it. Preferably, this work order includes a work order title (e.g., device location + device type + critical offline alarm), faulty device (device identifier + device type + device location), fault time (trigger timestamp of the third-level fault alarm mechanism), protocol type (i.e., KNX or Zigbee communication protocol, used to determine the skill requirements of the maintenance personnel), error code (which may be derived from the fault log), and handling suggestions (matched according to the error code; for example, if a Zigbee network layer timeout occurs, it is recommended to check the power supply and RF environment). The work order is set to high priority and then pushed to the maintenance personnel's corresponding mobile application.

[0127] Therefore, by simultaneously covering both KNX and Zigbee devices with heartbeat detection, the fault monitoring coverage of the hybrid networking solution is improved. Furthermore, through a three-tiered fault alarm mechanism, accurate fault classification and progressive alarms are achieved, avoiding information overload or insufficient response caused by a single fault level.

[0128] Preferably, when the third-order fault alarm mechanism is triggered, the edge AI inference engine (a lightweight artificial intelligence computing module) on the unified control management platform starts the root cause analysis process. Specifically, the edge AI inference engine first obtains all fault records of the controlled device that triggered the third-order fault alarm mechanism within the most recent preset time range (e.g., the most recent 90 days), including the timestamp of each fault, error code, and link quality data such as Received Signal Strength Indication (RSSI) and Link Quality Indication (LQI) within 30 seconds before and after the fault.

[0129] Next, the edge AI inference engine performs multi-dimensional feature extraction on the acquired fault records. Specifically, in the time dimension, the edge AI inference engine analyzes the time distribution pattern of fault occurrences to determine whether there is a periodic pattern; in the error code dimension, the edge AI inference engine counts the repetitive features of error code sequences to determine whether the same type of error occurs repeatedly; in the link quality dimension, the edge AI inference engine extracts the RSSI and LQI change trends before and after each fault occurrence, and calculates the change slope and fluctuation amplitude.

[0130] Then, the edge AI inference engine performs similarity matching between the extracted multidimensional features and a pre-built historical failure pattern library. This library stores feature templates for various typical failures and their corresponding root cause inferences. Upon successful matching, the edge AI inference engine outputs the specific root cause inference.

[0131] The edge AI inference engine uploads the root cause inference conclusions to the cloud server, which then appends these conclusions as text to the automatically generated maintenance work order, such as to the "AI diagnostic opinion" field of the maintenance work order.

[0132] Therefore, maintenance personnel can quickly locate the root cause of the fault based on this root cause diagnosis, shortening the on-site troubleshooting time.

[0133] Preferably, after triggering the first-level fault alarm mechanism, the second-level fault alarm mechanism, or the third-level fault alarm mechanism, if the heartbeat detection response of the corresponding controlled device is received multiple times (e.g., 3 times) consecutively, it is confirmed that the controlled device has returned to online status. At this time, the fault mark of the controlled device is cleared in stages.

[0134] Specifically, after receiving multiple consecutive heartbeat detection responses from the controlled device, if the first-level fault alarm mechanism is triggered, the yellow marker on the interactive interface is cleared, and the yellow alarm notification on the mobile application is canceled; if the second-level fault alarm mechanism is triggered, the red marker on the interactive interface is cleared, the audible and visual alarms are turned off (if they are still active), and the red alarm notification on the mobile application is canceled; if the third-level fault alarm mechanism is triggered, the device's online recovery event and recovery timestamp are synchronized to the cloud server, a device online recovery notification is pushed through the mobile application, and a "device has been restored to online" record is added to the maintenance work order and the maintenance work order is closed.

[0135] In some embodiments of this disclosure, the processor preferably further includes execution steps S910 to S930, please refer to Figure 9 .

[0136] In step S910, in response to the scene linkage trigger event, the first and second instructions that exist simultaneously are sent synchronously to the corresponding KNX device and Zigbee device.

[0137] In step S920, for each first instruction and second instruction, the corresponding device reporting signal is monitored. If no device reporting signal is received within the response time threshold, the device response is determined to have timed out, and the corresponding first instruction or second instruction is resent.

[0138] In step S930, if no device feedback signal is received after the number of retransmissions reaches the threshold, a communication anomaly alarm policy is triggered and executed.

[0139] In this implementation, when the scene triggering engine on the unified control management platform triggers a scene linkage involving both KNX and Zigbee devices (e.g., timed triggering or user manual triggering), the scene triggering engine will simultaneously generate corresponding first and second instructions (there may be multiple first and second instructions).

[0140] The scene triggering engine sends both the first instruction and the second instruction to the protocol convergence gateway at the same time. The KNX interface unit of the protocol convergence gateway sends the first instruction to the corresponding KNX device through the KNX bus communication interface, and the Zigbee coordinator unit of the protocol convergence gateway sends the second instruction to the corresponding Zigbee device through the Zigbee gateway module.

[0141] While sending all instructions, the scene triggering engine starts a unified timeout confirmation timer. The unified timeout confirmation timer separately records the corresponding response duration threshold for each of the KNX devices and Zigbee devices corresponding to the sent first instruction and second instruction. It should be noted that the response duration thresholds corresponding to different controlled devices may be the same or different.

[0142] The scene triggering engine continuously monitors the device report signals (confirmation frames returned after the controlled devices execute the corresponding instructions) of each KNX device and Zigbee device. Specifically, the unified timeout confirmation timer covers the monitoring of device report signals for both the KNX device and Zigbee device instruction paths at the same time. If any instruction on either path times out, the unified timeout confirmation timer triggers the timeout processing logic, which facilitates unified management of the overall completion status of parallel tasks.

[0143] If a KNX device or a Zigbee device returns a device report signal within its corresponding response duration threshold, the corresponding instruction is marked as executed successfully.

[0144] If a KNX device or a Zigbee device does not return a device report signal within its corresponding response duration threshold, the scene triggering engine determines that the response of the KNX device or the Zigbee device times out. At this time, the scene triggering engine resends (that is, retries) the first instruction or the second instruction corresponding to the KNX device or the Zigbee device.

[0145] When the number of resends reaches a preset number threshold and no device report information returned by the KNX device or Zigbee device is received, a communication abnormality alarm strategy is triggered, and this communication abnormality alarm strategy may be the first-level fault alarm as mentioned above. If the device report signal returned by the KNX device or the Zigbee device is received before the number of resends reaches the number threshold, the retries are stopped, and the scene triggering engine marks the corresponding instruction as executed successfully.

[0146] Therefore, during scene linkage, by implementing a parallel delivery mechanism for the coexisting first instruction and second instruction, the total delay of cross-protocol linkage can be effectively reduced. In addition, the path-based independent timeout retry mechanism can avoid the waste of communication resources caused by blind retries of all instructions.

[0147] In some embodiments of this disclosure, the processor preferably further includes execution steps S1010 to S1030, please refer to Figure 10 .

[0148] In step S1010, when an interruption in the connection with the cloud server is detected, the control mode is switched to local autonomous mode.

[0149] In step S1020, the incremental operation records generated during the local autonomous mode are stored in the local cache.

[0150] In step S1030, when the connection with the cloud server is restored, the control mode is switched to cloud linkage mode, and the locally cached operation records are incrementally uploaded to the cloud server in chronological order.

[0151] In this implementation, the unified control and management platform sends long-connection heartbeat messages to the cloud server at fixed intervals. When the connection with the cloud server is normal, the cloud server will respond with a heartbeat response within a specified time. If no heartbeat response is received from the cloud server within a certain period, the unified control and management platform determines that the connection with the cloud server has been interrupted.

[0152] At this point, the unified control management platform switches the internal control mode flag from "cloud-based linkage mode" to "local autonomous mode" and displays a local control status prompt on the touch screen to inform the user of the current control mode.

[0153] Upon entering local autonomy mode, the unified control and management platform ceases reporting any control commands or status data to the cloud server. However, background threads continuously and silently attempt to rebuild the encrypted long connection with the cloud server. Simultaneously, the unified control and management platform confirms that all functions (including KNX device control, Zigbee device control, scene linkage, status monitoring, etc.) have switched to the local execution path. Specifically, regarding KNX device control, the first command is sent directly to the KNX bus communication interface through the KNX interface unit of the protocol fusion gateway, without going through the cloud server. Regarding Zigbee device control, the second command is directly issued to the Zigbee gateway module through the Zigbee coordinator unit of the protocol fusion gateway. Regarding scene linkage, the scene triggering engine reads scene templates from the scene configuration library stored locally in the eMMC (this scene configuration library has been synchronized with the scene template configuration on the cloud server in cloud linkage mode) and completes the generation and issuance of scene linkage commands locally. Status monitoring and fault self-diagnosis, heartbeat detection, and the three-level fault alarm mechanism all run completely locally. The edge AI inference engine also runs locally. This ensures the availability of whole-house control functions in local autonomy mode.

[0154] In addition, in local autonomous mode, all newly generated operation records (such as user manual operations, device status changes, etc.) are written incrementally to the local cache (such as a local eMMC dedicated cache partition). Preferably, whenever an operation record is generated, the unified control management platform assigns it an incrementing timestamp, then encapsulates the operation record into a preset format and appends it to a pre-defined cache partition. Preferably, a round-robin overwrite strategy is used within this cache partition, prioritizing the deletion of the oldest operation records that are not marked as high priority. For high-priority operation records such as fault logs and security event alarms that trigger the third-level fault alarm mechanism, it is ensured that they are not deleted during the round-robin overwrite process, guaranteeing that critical data is not lost.

[0155] Upon receiving a heartbeat response from the cloud server again, it can be determined that the connection with the cloud server has been restored. At this time, the unified control and management platform switches the control mode from local autonomous mode back to cloud-linked mode. Furthermore, the unified control and management platform initiates the breakpoint resume synchronization process, uploading the operation records that have not yet been uploaded from the local cache to the cloud server one by one in chronological order of their timestamps. Preferably, the cloud server returns an acknowledgment response after receiving the operation record. If the transmission of an operation record fails (e.g., due to network jitter), the unified control and management platform records the location of the failure and continues to attempt to upload subsequent operation records. After all operation records have been sent, the failed operation records are retried. After synchronization is complete, the unified control and management platform clears the successfully uploaded operation records from the local cache, freeing up storage space.

[0156] Therefore, when the connection to the cloud server is lost, the system automatically and seamlessly switches to local autonomous mode, eliminating the risk of cloud dependency. Furthermore, operation logs during local autonomy are fully retained through incremental caching, ensuring that critical fault data and security events are not lost during local autonomy.

[0157] In some embodiments of this disclosure, the protocol fusion gateway preferably further includes steps S1110 to S1130, please refer to... Figure 11 .

[0158] In step S1110, the KNX bus load rate, Zigbee signal strength value, link quality indicators, and command transmission success rate are collected.

[0159] In step S1120, the routing score of the current communication link is calculated based on the collected KNX bus load rate, Zigbee signal strength value, link quality index and command transmission success rate. The routing score is used to characterize the signal transmission quality of the communication link.

[0160] In step S1130, when the routing score of the current communication link is less than the preset routing quality threshold, the system switches to the backup communication link for communication.

[0161] In this implementation, the protocol convergence gateway also includes an adaptive Quality of Service (QoS) routing engine (hereinafter referred to as the "routing engine"). During the operation of the home control terminal, the routing engine collects data in real time at a fixed sampling period (e.g., 500ms) on the following metrics: KNX bus load rate (i.e., the percentage of actual data transmitted on the KNX bus per unit time relative to the maximum theoretical capacity of the KNX bus), Zigbee device signal strength value (in dBm, the larger the value, the stronger the signal), link quality index (a comprehensive link quality evaluation value provided by the Zigbee protocol stack, ranging from 0 to 255, the larger the value, the better the link quality), and command transmission success rate (the percentage of successful device confirmation responses received within a preset historical time window (e.g., in 100 historical command transmissions, including the first and second commands)).

[0162] Next, the routing engine normalizes the collected parameters and determines the routing score of the current communication link according to the pre-set routing score calculation formula.

[0163] Preferably, the formula for calculating the routing score is as follows: Score=α×(1-BusLoad)+β×RSSI_norm+γ×LQI_norm+δ×SuccessRate Where BusLoad is the KNX bus load rate; RSSI_norm is the Zigbee signal strength value; LQI_norm is the link quality index; SuccessRate is the command transmission success rate; α, β, γ, and δ are weighting coefficients, and α+β+γ+δ=1. Preferably, the weighting coefficients can be dynamically updated by the edge AI inference engine.

[0164] Once the routing score of the current communication link is determined, it is compared with a pre-set routing quality threshold. When the routing score is lower than the threshold, the routing engine switches to a backup communication link (e.g., switching within 50ms), achieving seamless link self-healing. The backup communication link can be a pre-defined or dynamically discovered alternative communication path. For example, for KNX devices, the backup communication link could be different address mappings of the same device; for Zigbee devices, it could be an alternative communication path via different relay devices (e.g., relay routers).

[0165] When the routing score is greater than or equal to the routing quality threshold, it indicates that the current communication link has good communication quality, and the current communication link should continue to be used for communication.

[0166] This enables real-time, multi-dimensional perception of KNX bus load and Zigbee wireless link quality, effectively avoiding command loss and response delays caused by radio frequency interference, bus congestion, or abnormal device power supply.

[0167] In some embodiments of this disclosure, the processor preferably further includes execution steps S1210 to S1230, please refer to Figure 12 .

[0168] In step S1210, a user behavior baseline model is constructed based on the user's historical operation data.

[0169] In step S1220, user operation intent is predicted based on the user behavior baseline model, and the corresponding pre-issued instruction set is generated and cached based on the user operation intent prediction result.

[0170] In step S1230, in response to a trigger event for a pre-delivered instruction set, the instructions contained in the pre-delivered instruction set are sent to the corresponding KNX device or Zigbee device.

[0171] The user behavior baseline model is a standardized set of behavioral features constructed based on users' historical operation data. Preferably, the user behavior baseline model includes the operation frequency patterns of each controlled device in different time periods and scenarios, device linkage combination habits, energy consumption range characteristics, and time distribution patterns.

[0172] In this implementation, the edge AI inference engine deployed on the processor is always in a learning state during actual operation. Whenever a user performs a device control or scene-triggered operation, the edge AI inference engine writes the relevant features of that operation (such as timestamp, device identifier, operation type, scene context, etc.) as training samples into a local training sample buffer. When the training sample buffer accumulates a certain number of training samples or reaches a certain time interval, the edge AI inference engine starts incremental training locally, fine-tuning the previously established user behavior baseline model and updating parameters such as model weights, thereby continuously optimizing the user behavior baseline model. Furthermore, user operation data never leaves the local device throughout the entire process.

[0173] The edge AI inference engine predicts user action intentions based on a user behavior baseline model. Specifically, at regular intervals or when a specific event (such as changes in light sensor readings or human movement detection) occurs, the edge AI inference engine uses the current time and environmental context as input to the user behavior baseline model. The user behavior baseline model then outputs the most likely behavioral scenario within a certain future timeframe (e.g., the next 30 seconds) and its corresponding confidence level. For example, at 6:55 AM, based on the current time and environmental context (such as human body sensor detection data), the user behavior baseline model predicts that the "getting up scenario" is about to occur.

[0174] The edge AI inference engine generates corresponding KNX messages and Zigbee command frames (i.e., the first and second instructions) based on the pre-configured instruction set of the scenario predicted by the user behavior baseline model, forming a pre-delivered instruction set, which is cached in local memory. This pre-delivered instruction set is not executed immediately, but is only in a standby state.

[0175] When a user actually performs a trigger event (such as pressing the physical button for the "wake-up scene" or detecting that the user has sat up in bed), the processor checks whether there is a pre-delivered instruction set that matches the trigger event. If there is, the instruction generation and protocol conversion steps can be skipped directly, and the first and second instructions in the pre-delivered instruction set can be sent in parallel to the corresponding KNX and Zigbee devices.

[0176] Thus, by generating pre-issued instruction sets, proactive predictive control is achieved, significantly reducing the response latency when the user actually triggers the control.

[0177] Preferably, if the home control terminal is connected to the federated learning aggregation server (provided by the manufacturer and requiring user authorization to enable), the processor only extracts the model gradients generated during the current incremental training (excluding the original user operation data) and uploads them to the federated learning aggregation server via TLS 1.3 encryption. The federated learning aggregation server performs federated aggregation after aggregating the model gradients from multiple devices (such as multiple home control terminals), generating updated global model weights. Then, the federated learning aggregation server distributes the updated global model weights (excluding any user operation data) to each home control terminal. Upon receiving the global model weights, each home control terminal replaces the weight parameters in its user baseline behavior model, thereby continuously optimizing the predictive capabilities of the user behavior baseline model without exposing user privacy data.

[0178] In some embodiments of this disclosure, after constructing the user behavior baseline model, the processor preferably further includes executing steps S1310 to S1330, please refer to... Figure 13 .

[0179] In step S1310, based on the received control commands for the target device and the user behavior baseline model, a user behavior deviation score between the control commands and the user behavior baseline model is determined.

[0180] In step S1320, when the user behavior deviation score is greater than or equal to the preset abnormal score threshold, the control command is suspended and a secondary confirmation message is displayed on the interactive interface of the home control terminal.

[0181] In step S1330, in response to the operation on the secondary confirmation information, the suspended control command is executed or discarded.

[0182] The user behavior deviation score is a quantitative score representing the degree of deviation between the current control command and the user's historical behavioral habits. Preferably, the edge AI inference engine extracts the feature vector of the currently received control command (including timestamp, device identifier, operation type, and scene context, etc.) and performs multi-dimensional feature matching (e.g., time deviation, frequency deviation, device combination deviation, and energy consumption deviation, etc.) with the expected feature vector of the corresponding time period in the user behavior baseline model, and calculates the corresponding user behavior deviation score.

[0183] In this implementation, upon receiving a control command for the target device (regardless of whether it originates from a touchscreen click, scene linkage, voice control, or a mobile application), the edge AI inference engine extracts the feature vector of the control command. Using the trigger timestamp of the control command as a query condition, it searches the user behavior baseline model for historical behavior statistics of the target device during the corresponding time period. The edge AI inference engine then performs multi-dimensional matching between the feature vector of the control command and the acquired historical behavior statistics to obtain the corresponding user behavior deviation score.

[0184] For example, user historical operation data shows that between 0:00 and 6:00 AM, the average number of times the living room lights are turned on is less than 0.1 times per week, and all lights are never turned on at 2:00 AM. The edge AI inference engine compares the currently received control command "turn on all living room lights at 2:00 AM" with the user behavior baseline model and calculates the deviation in each dimension: time deviation (the current time is significantly inconsistent with the user's active period) score 0.9, frequency deviation (this operation far exceeds the historical frequency limit) score 0.85, and combination deviation (the current operation conflicts with the already activated "sleep mode") score 0.8. After weighted calculation based on the deviations in each dimension, the user behavior deviation score is 0.88.

[0185] Next, the edge AI inference engine compares the calculated user behavior deviation score with a pre-set anomaly score threshold. If the user behavior deviation score is less than the anomaly score threshold, the control command is considered a normal operation and is executed normally.

[0186] If a user's behavior deviation score is greater than or equal to the abnormal score threshold, it can be determined as "suspected abnormal behavior," and the control command will be immediately suspended and not executed. Simultaneously, a pop-up window displaying secondary confirmation information, such as "All lights detected, please confirm whether to execute," is displayed on the touchscreen interface of the home control terminal. This pop-up provides two buttons: "Confirm Execution" and "Do Not Execute," for the user to choose from. Preferably, the edge AI inference engine can simultaneously push notifications with the same content to the mobile application.

[0187] After the user sees the pop-up window for secondary confirmation, if the user chooses to confirm execution, the processor will resume the execution flow of the suspended control instruction, convert the control instruction into a first instruction or a second instruction, and send it to the target device; if the user chooses not to execute (or fails to confirm within the timeout period), the processor will directly delete the suspended control instruction and will not execute any device control.

[0188] Therefore, user behavior deviation identification based on the user behavior baseline model can accurately identify various unconventional operation modes. Furthermore, through a secondary confirmation mechanism, it can intervene when suspected abnormal behavior occurs, and also retain the execution path under temporary user needs, thus achieving a balance between security and flexibility.

[0189] In some embodiments of this disclosure, the processor preferably further includes steps S1410 to S1430, please refer to Figure 14 .

[0190] In step S1410, virtual digital twins corresponding to each KNX device and Zigbee device are constructed.

[0191] In step S1420, according to the scene instruction set configured for the target scene, the virtual state change is performed on the virtual digital twin corresponding to the KNX device or Zigbee device associated with the instruction in the scene instruction set, and the simulation preview result is generated and displayed on the interactive interface of the home control terminal.

[0192] In step S1430, in response to the confirmation operation for the simulation preview result, the instructions contained in the scene instruction set are sent to the corresponding KNX device or Zigbee device.

[0193] The virtual digital twin is a virtual mapping object created in local memory for each controlled device, storing a snapshot of the device's current state (such as on / off status, brightness percentage, temperature value, curtain opening degree, etc.) as well as a sequence of its entire lifecycle state. The virtual digital twin typically synchronizes with the corresponding controlled device every 30 seconds.

[0194] A scene instruction set is a pre-configured set of device control instructions for a specific scene. For example, a scene instruction set for the "homecoming mode" might include: adjust the living room lights to 80%, set the air conditioner to 26°C, open the curtains to 50%, and turn on background music. Each instruction includes a device identifier, operation type, and target parameters.

[0195] In this implementation, the processor's unified control and management platform also includes a digital twin management module. When the home control terminal starts up, this module instantiates a virtual digital twin in memory for each discovered KNX and Zigbee device. The initial state of this virtual digital twin is filled in by reading the current actual state of the corresponding device. During the operation of the home control terminal, the digital twin management module continuously updates the status fields of the virtual digital twin through a unified heartbeat engine (30-second cycle) and device-initiated reporting events, ensuring state synchronization between the virtual digital twin and the corresponding controlled device.

[0196] After the user completes the configuration of the scene instruction set for the target scene in the scene configuration module of the unified control management platform, the user can click the "Preview Effect" button. At this time, the digital twin management module starts the simulation verification process. Specifically, the digital twin management module parses each instruction in the scene instruction set and loads the virtual digital twin of the KNX device or Zigbee device associated with that instruction. Then, the digital twin management module sequentially changes the virtual state of the corresponding virtual digital twin according to the target parameters of each instruction in the scene instruction set. For example, for the "living room light" instruction, the brightness status field of the virtual digital twin is modified from the current value (e.g., 80%) to the target value, i.e., the target parameter (0%); for "bedroom curtains", its opening status field is modified from the current value (100% fully open) to the target value (0% fully closed).

[0197] Preferably, while performing virtual state changes, the digital twin management module simultaneously performs conflict detection, including checking whether any instructions require the same controlled device to simultaneously reach two contradictory states (such as both turning the lights on and off), whether the instructions in the scene instruction set conflict with the currently activated scene configuration (for example, "away mode" requires the air conditioner to be turned off, but the currently activated "pet mode" requires the air conditioner to remain on), and whether the target parameters exceed the rated range. If a conflict is detected in any instruction in the scene instruction set, the conflicting item is highlighted on the interactive interface of the home control terminal.

[0198] After the virtual state change and conflict detection are completed, the digital twin management module generates a simulation preview result and displays it on the interactive interface of the home control terminal. Preferably, the simulation preview result is a visualization of the expected state of all controlled devices in the house after the execution of the scene command set of the target scenario, as well as conflict alarm prompts.

[0199] Based on the displayed simulation preview results, users can intuitively confirm whether the scenario instruction set configuration for the target scenario matches their actual intent. If the user confirms that the simulation preview results meet expectations and there are no conflict alarms, they can trigger a confirmation operation through the interactive interface. At this time, the KNX or Zigbee devices corresponding to each instruction contained in the scenario instruction set can be sent for execution (this can be done through the scenario triggering engine). If the user finds that the simulation preview results do not match expectations, they can directly adjust the corresponding instructions in the interactive interface and re-trigger the simulation verification.

[0200] In this way, when configuring scene instruction sets, users do not need to wait for the controlled device to execute before making corrections, effectively avoiding actual misoperations caused by configuration errors and improving the configuration efficiency of complex scenarios.

[0201] In some embodiments of this disclosure, the processor preferably further includes steps S1510 to S1530, please refer to Figure 15 .

[0202] In step S1510, health status data of each KNX device and Zigbee device are collected.

[0203] In step S1520, a fault risk analysis is performed based on the health status data of each KNX device and Zigbee device to obtain the fault risk analysis results corresponding to each KNX device and Zigbee device.

[0204] In step S1530, based on the fault risk analysis results, predictive maintenance alarm information corresponding to the KNX device or Zigbee device is generated.

[0205] In this implementation, the digital twin management module continuously collects health status data from each KNX and Zigbee device at fixed intervals using a unified heartbeat engine during operation. Preferably, this health status data includes device response latency, communication success rate (the proportion of commands successfully sent within a recent period, including the number of retries), Zigbee signal strength value, link quality indicators, operating temperature / voltage reported by the controlled device itself (if the device supports it), historical fault records (including timestamps and error codes for triggering the first-level fault alarm mechanism, the second-level fault alarm mechanism, and the third-level fault alarm mechanism), cumulative operating time, and installation date.

[0206] The digital twin management module writes the collected health status data into a local LevelDB time-series database. The edge AI inference engine periodically (e.g., at a fixed time each day) reads the health data (e.g., from the last 90 days) of each controlled device from this local LevelDB time-series database. Then, for each controlled device, a fault risk analysis is performed based on its health status data. This fault risk analysis involves trend analysis and pattern recognition of the health status data of the controlled devices.

[0207] Preferably, the fault risk analysis for each controlled device includes: communication success rate attenuation trend analysis (e.g., the communication success rate drops from 99% to 92% in the past 14 days, which can be identified as a "slow degradation" trend), response delay trend analysis (a continuous increase in device response delay may indicate a decrease in the internal processing capacity of the controlled device or unstable power supply), link quality trend analysis (a continuous decrease in Zigbee signal strength value / link quality index may indicate antenna aging or a gradual increase in physical obstruction), and historical fault cycle pattern analysis (based on the timestamps of historical fault records, the fault occurrence cycle pattern is extracted, such as a device triggering a second-order fault alarm mechanism once every 90 days).

[0208] After completing the multidimensional trend analysis, the edge AI inference engine integrates the slope characteristics and periodic patterns of the above trend indicators to calculate the current fault risk score (i.e., fault risk analysis result) for each controlled device.

[0209] When the failure risk score of a controlled device is greater than or equal to a pre-set warning threshold (corresponding to the confidence level of a failure risk expected after N days, where N is an integer greater than 0), the edge AI inference engine triggers and generates predictive maintenance alarm information. It should be noted that the alarm lead time is determined by the trend slope, and is typically 1-7 days. For example, based on the downward trend of communication success rate, if it is expected that the communication success rate will drop below 80% in another 4 days, then the alarm lead time is 4 days.

[0210] Preferably, predictive maintenance alarm information includes the device name, device location, expected failure time window, and description of key degradation indicators. For example, the predictive maintenance alarm information is:

Predictive Maintenance

[0211] After generating predictive maintenance alerts, the edge AI inference engine pushes these alerts to the mobile application, thus transforming unexpected downtime into planned preventative maintenance and significantly reducing the probability of unexpected downtime.

[0212] Preferably, after a predictive maintenance alarm is pushed, the digital twin management module continuously monitors the changes in the health status data of the controlled device. If the controlled device completes maintenance and the health status data returns to normal, the predictive maintenance alarm is revoked. If the health status data continues to deteriorate, the corresponding warning level is raised and the review cycle is shortened (e.g., the data acquisition cycle of the health window is shortened).

[0213] In some embodiments of this disclosure, the home control terminal sequentially activates a five-layer security protection mechanism during startup and operation, including: Layer 1 (Zigbee Network Layer): When a Zigbee device first requests to join the network, the Zigbee coordinator unit, acting as the Trust Center, initiates the authentication process. The Zigbee device must provide a pre-shared installation code or prove its legitimacy through methods such as key confirmation. After successful verification by the Trust Center, a network key is assigned to the Zigbee device, and AES-128 CCM is used. The algorithm encrypts all subsequent communication frames. Each frame contains an encrypted payload and an integrity checksum; any tampered or forged frame will be discarded by the receiver. This effectively prevents unauthorized devices from accessing the network and prevents over-the-air packet sniffing and parsing of commands.

[0214] Layer 2 (Cloud Communication Layer): A TLS 1.3 encrypted connection is established between the home control terminal and the cloud server, with both parties authenticating each other through certificate exchange. All uplink status data and downlink control commands are transmitted within this encrypted tunnel. When a third-party application needs to access the cloud API, it must obtain an access token following the OAuth 2.0 process. The token carries the scope and validity period. After the cloud server verifies the token's validity, it allows the application to call the corresponding API interface. This ensures that even if network transmission is monitored, the data content cannot be parsed; it also prevents unauthorized third-party applications from maliciously calling cloud interfaces.

[0215] The third layer (local API permission layer): The local control interface exposed by the home control terminal (for calls from mobile apps or third-party control panels within the same network) requires the caller to include a Bearer Token in the HTTP header. The home control terminal has a built-in token authentication service that supports periodic refresh. Simultaneously, the home control terminal assigns permission levels to each logged-in user: administrators can add or delete devices, configure scenes, and modify system settings; ordinary users can manually control devices through scene linkages; visitors can only view device status and cannot perform any control actions. All API calls are written to audit logs and stored in a local eMMC partition. In the event of abnormal operations, the specific account and time can be traced back.

[0216] Layer 4 (Firmware Security Layer): When the cloud server pushes a new firmware version, the home control terminal first downloads the firmware package and its digital signature. It then verifies the signature using a pre-installed vendor public key to confirm the firmware's integrity and legitimate origin. After successful verification, the home control terminal backs up the currently running firmware to the recovery partition and then performs the upgrade. If any abnormalities occur after the upgrade (such as repeated reboots or functional failure), the user can select "Rollback" in the maintenance interface to restore the previous firmware version from the backup partition.

[0217] Layer 5 (Data Privacy Layer): When the edge AI inference engine trains the user behavior baseline model, all original user operation records (including time, device, and operation type) are stored only in the local LevelDB database and are never actively uploaded to the cloud. Similarly, the health status data of each controlled device collected by the digital twin management module is also stored locally. When the home control terminal enables the federated learning function and the user authorizes it, only the model gradient (not the original data) is encrypted and uploaded locally to the federated learning aggregation server. The federated learning aggregation server aggregates the model gradients from multiple home control terminals to generate global model weights before distributing them, without accessing any user privacy data throughout the entire process.

[0218] In some embodiments of this disclosure, when a user touches the touchscreen display with their finger, the capacitive sensing array of the touchscreen display detects a change in capacitance and generates a raw electrical signal. This electrical signal first enters a hardware low-pass filter inside the touchscreen display controller. The hardware low-pass filter allows low-frequency effective touch signals to pass through by setting a cutoff frequency (e.g., 500kHz), while attenuating high-frequency noise components caused by environmental electromagnetic interference, power supply noise, etc. After passing through the hardware low-pass filter, the touchscreen display controller outputs a set of relatively smooth touch coordinate data and reports it to the processor via the internal bus.

[0219] After receiving the touch point coordinate data, the processor enters the software debounce processing stage. The processor maintains a timestamp record for the touch point, marking the timestamp of the last valid trigger. When new touch point coordinate data arrives, the processor calculates the difference between the current time and the timestamp of the last valid trigger. If the difference is less than the preset debounce duration (e.g., 50ms), and the distance between the coordinates of the newly received touch point and the coordinates of the previously received touch point is less than the preset distance threshold (e.g., 5 pixels), it is determined to be a "repeated trigger event," and the processor discards the touch point trigger event without further processing. If the difference is greater than or equal to the debounce duration, or the coordinate distance between the two touch points exceeds the distance threshold, it is determined to be a valid first trigger event, the processor updates the timestamp of the touch point trigger event, and enters the touch point validity verification stage.

[0220] During the touch point validity verification phase, the processor obtains the boundary rectangle information (including position and size) of all interactive controls (buttons, sliders, icons, etc.) on the current interactive interface. The processor performs a point-to-rectangle containment test between the coordinates of the touch point to be verified and the boundary rectangle of each control. Specifically, if the touch point coordinates fall within the boundary rectangle of any control, the touch point triggering event is determined to be a valid operation, and the processor generates the corresponding control command according to the function bound to the control. If the touch point coordinates do not fall within the boundary rectangle of any control (e.g., clicking on the gap between two buttons, or the non-interactive area at the very edge of the screen), the touch point triggering event is determined to be an invalid operation, the processor discards the touch point triggering event and ends the processing.

[0221] This effectively eliminates repeated triggering caused by finger tremors or touchscreen hardware jitter, ensuring that each user touch operation generates only one command response, thus improving the stability and accuracy of touch interaction.

[0222] In some embodiments of this disclosure, when a controlled device recovers from an offline state (i.e., triggering the second-order fault alarm mechanism) to online status, the routing engine writes the duration of the fault, the recovery time, and the link quality data during the fault period into the routing quality history database, and updates the success rate weight of the path, so that subsequent routing decisions prioritize stable paths. Furthermore, the edge AI inference engine writes the fault event into the device health status history for the generation of subsequent predictive maintenance alarms. Additionally, if a controlled device is detected to have triggered the second-order fault alarm mechanism a preset number of times (e.g., 3 times) within a certain period (e.g., 30 days), the device's heartbeat polling cycle is automatically shortened from 30 seconds to 20 seconds for long-term encrypted monitoring, and the owner is notified via a mobile application to arrange maintenance.

[0223] like Figure 16 As shown, this disclosure also provides a home control system, including a cloud server 200 and at least one home control terminal 100. The cloud server 200 communicates bidirectionally with each home control terminal 100 via a long-lived encrypted connection using Transport Layer Security Protocol 1.3.

[0224] Specifically, the cloud server 200 provides remote control, data backup, OTA upgrades, and open API interfaces for third-party platforms, and supports the OAuth 2.0 authorization framework. The home control terminal 100 is installed in the user's residence. This home control terminal can execute the control methods provided in this embodiment, including local device control, status monitoring, fault self-diagnosis, edge AI inference, and digital twin management. The cloud server 200 and the home control terminal 100 cooperate to achieve remote control and data synchronization when the cloud server 200 is online. When the network is interrupted, the home control terminal 100 automatically switches to local autonomous mode to ensure full availability of local control functions.

[0225] The specific implementation of the above-mentioned home control system can refer to the implementation process of the corresponding steps in the above-described method implementation method of this disclosure, and will not be repeated here.

[0226] Figure 17 This is a flowchart illustrating a control method for a home control terminal according to another embodiment of the present disclosure.

[0227] like Figure 17 As shown, in step S1701 (trigger event recognition), the processor of the home control terminal detects touch operations from the touch screen, timed tasks, or trigger signals from sensors (such as door magnets or infrared sensors), and acquires event information of the trigger event, including location coordinates, pressure, or area information. It further identifies the event type corresponding to the trigger event, such as user-initiated triggering, automatic timed triggering, or sensor-linked triggering.

[0228] In step S1702 (edge ​​AI prediction intervention), the edge AI inference engine evaluates whether the current triggering event meets the prediction conditions. If it identifies that a user's habitual behavior scenario (such as getting up, going out, going to bed, etc.) is about to occur, it generates a pre-issued instruction set before the expected triggering time and caches it locally so as to reduce response latency when the user actually triggers it.

[0229] In step S1703 (data processing and mode determination), the triggering event is filtered and debounced (including hardware low-pass filtering and software debounce), the corresponding scene template is determined, and the current network status between the cloud server is determined to select local autonomous mode or cloud linkage mode.

[0230] In step S1704 (instruction generation and priority allocation), the scene triggering engine generates a first instruction set and a second instruction set simultaneously based on the scene template. The protocol fusion gateway assigns a priority level to each instruction (P0 emergency security level, P1 normal scene level, P2 status polling level). Among them, the P0 level instruction has full preemption rights and can immediately interrupt and suspend low-priority tasks.

[0231] In step S1705 (Quality of Service Routing Query), the Quality of Service routing engine collects KNX bus load rate, Zigbee signal strength value, link quality index and command transmission success rate at fixed intervals, calculates the routing score of the current communication link, and queries the dynamic protocol mapping table to determine the optimal routing path for each controlled device.

[0232] In step S1706 (parallel instruction issuance), the scene triggering engine synchronously and in parallel issues the first instruction and the second instruction, and simultaneously starts a unified timeout confirmation timer.

[0233] In step S1707 (Device Execution and Status Feedback), after receiving the corresponding first or second instruction, each controlled device returns its own device report signal (including the current status of the controlled device). The current status returned by each controlled device is synchronized to the corresponding virtual digital twin.

[0234] In step S1708 (fault diagnosis and link self-healing), if a certain command is not acknowledged within the corresponding response time threshold, it will be retried up to 3 times (with an interval of 200 milliseconds); if two consecutive failures trigger the service quality routing engine to switch to the backup communication link within 50 milliseconds; if all 3 retries time out, a first-level fault alarm will be triggered and the heartbeat detection cycle of the controlled device will be shortened.

[0235] In step S1709 (Status Update and Cloud Synchronization), the processor updates the current state value of the corresponding device object in the unified device model according to the current state feedback from the controlled device, and renders it to the touch screen in real time; when the network is connected, the state change is reported to the cloud server; if it is offline, the operation record is incrementally cached in a local dedicated cache partition, and automatically synchronized to the cloud server through breakpoint resume after the network is restored.

[0236] In step S1710 (quality assessment and adaptive optimization), the quality score of this joint execution (including response latency, success rate, etc.) is recorded. The edge AI inference engine updates the user behavior baseline model accordingly, the service quality routing engine updates the dynamic weight coefficients (α,β,γ,δ) of each communication link score, and the digital twin management module writes the execution data into the time series database for subsequent predictive maintenance analysis.

[0237] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means that can contain a program for storage, communication, propagation, or transmission for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0238] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0239] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0240] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0241] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0242] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0243] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0244] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0245] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

[0246] It is understood that before using the technical solutions disclosed in the embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained. For example, in response to receiving a user's active request, a prompt message can be sent to the user to clearly inform the user that the requested operation will require the acquisition and use of the user's personal information. This allows the user to choose whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media that perform the operations of the technical solutions of this disclosure, based on the prompt message. As an optional but non-limiting implementation, the way to send a prompt message to the user in response to receiving a user's active request can be, for example, a pop-up window, in which the prompt message can be presented in text form. Furthermore, the pop-up window can also include a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0247] It is understood that the above notification and user authorization acquisition process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure. The data involved in the technical solution of this disclosure (including but not limited to the data itself, the acquisition or use of data) shall comply with the requirements of relevant laws, regulations and related provisions.

Claims

1. A control method of a home control terminal, characterized by, The device is used in a home control terminal, which includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway. The control method of the home control terminal includes: The processor extracts the device identifier of the target device from the received control command for the target device; based on the device identifier of the target device, it queries the unified device model to determine the device object in the unified device model corresponding to the device identifier, and extracts the corresponding protocol identifier from the device object, wherein the protocol identifier includes KNX communication protocol or Zigbee communication protocol; When the protocol identifier is KNX communication protocol, the protocol fusion gateway converts the control command into a first command conforming to the KNX communication protocol; when the protocol identifier is Zigbee communication protocol, it converts the control command into a second command conforming to the Zigbee communication protocol; and sends the first command to the target device through the KNX bus communication interface, or sends the second command to the target device through the Zigbee gateway module.

2. The control method of a home control terminal according to claim 1, characterized by, Building a unified device model includes: The protocol fusion gateway broadcasts device query messages through the KNX bus communication interface to obtain first device information of the KNX device, and initiates a network scan through the Zigbee gateway module to obtain second device information of the Zigbee device; it then maps the first and second device information to standard field values ​​of a unified device model; and The processor instantiates each KNX device and Zigbee device into a device object based on the standard field values ​​obtained from the mapping, thus obtaining a unified device model.

3. The control method of a home control terminal according to claim 1, wherein The protocol fusion gateway maintains a dynamic protocol mapping table. Each entry in the dynamic protocol mapping table contains an associated KNX group address, Zigbee network address, Zigbee endpoint identifier, and Zigbee cluster identifier. When converting the control command into a first command conforming to the KNX communication protocol or a second command conforming to the Zigbee communication protocol, the following steps are included: When the protocol identifier is KNX communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the KNX group address corresponding to the device identifier, and the control command is converted into a first command that conforms to the KNX communication protocol and contains the KNX group address; as well as When the protocol identifier is Zigbee communication protocol, the dynamic protocol mapping table is queried according to the device identifier to obtain the Zigbee network address, Zigbee endpoint identifier and Zigbee cluster identifier corresponding to the device identifier, and the control command is converted into a second command that conforms to the Zigbee communication protocol and includes the Zigbee network address, the Zigbee endpoint identifier and the Zigbee cluster identifier.

4. The control method of a home control terminal according to claim 3, characterized by, The protocol fusion gateway further includes performing the following steps: In response to received device change information, obtain a first copy of the currently used dynamic protocol mapping table; Based on the first copy, add, modify or delete entries in the first copy that correspond to the device change information to generate a second copy of the dynamic protocol mapping table; Perform a feasibility check on the second copy; as well as If the feasibility check passes, the global mapping table pointer is switched from the first copy to the second copy; if the feasibility check fails, the second copy is discarded and the first copy continues to be used.

5. The control method of a home control terminal according to claim 1, wherein Upon receiving a control command for the target device, the protocol fusion gateway further includes performing the following steps: Based on the received control command for the target device, extract the event trigger source identifier from the control command; The priority level of the control command is determined by querying the event trigger source identifier. When the priority level of the control instruction is the target level, the control instruction is assigned to the target instruction queue for execution, and the processing threads of other instruction queues besides the target instruction queue are interrupted and suspended; and After the control instructions in the target instruction queue are executed, the target instruction queue is cleared, and the processing threads of other suspended instruction queues continue to be executed.

6. The control method of a home control terminal according to claim 1, wherein The processor further includes performing the following steps: Send a heartbeat detection message to the KNX or Zigbee device to confirm the heartbeat detection result; When the heartbeat detection result of a KNX device or Zigbee device indicates a communication anomaly, shorten the heartbeat detection cycle for that KNX device or Zigbee device and implement a heartbeat detection retry strategy. During the execution of the heartbeat detection retry strategy, if the corresponding KNX or Zigbee device remains unresponsive, an audible and visual alarm signal will be issued, an alarm notification will be pushed to the mobile application, and a fault log will be recorded; and If the continuous offline time of the corresponding KNX device or Zigbee device exceeds the target time threshold, an alarm data packet is pushed to the cloud server, and the cloud server generates a maintenance work order based on the alarm data packet.

7. The control method of a home control terminal according to claim 1, wherein The processor further includes performing the following steps: Construct a baseline model of user behavior based on historical user operation data; Based on the user behavior baseline model, predict user operation intentions, and generate and cache the corresponding pre-issued instruction set based on the user operation intention prediction results; as well as In response to a trigger event for the pre-delivered instruction set, the instructions contained in the pre-delivered instruction set are sent to the corresponding KNX device or Zigbee device.

8. The control method of a home control terminal according to claim 1, wherein The processor further includes performing the following steps: Collect health status data for each KNX and Zigbee device; Based on the health status data of each KNX device and Zigbee device, a fault risk analysis is performed to obtain the fault risk analysis results corresponding to each KNX device and Zigbee device. as well as Based on the failure risk analysis results, predictive maintenance alarm information corresponding to the KNX device or Zigbee device is generated.

9. A home control terminal, characterized by comprising: It includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway; the home control terminal is used to execute the control method of the home control terminal as described in any one of claims 1-8.

10. A home control system comprising a cloud server and a home control terminal in communication with each other, characterized by, The home control terminal includes a processor, a Zigbee gateway module, a KNX bus communication interface, and a protocol fusion gateway; the home control terminal is used to execute the control method of the home control terminal as described in any one of claims 1-8.

Images