A smart home scene linkage control method and system across communication protocols

Abstract

The application discloses a smart home scene linkage control method and system across communication protocols. The method comprises the following steps: a scene master control device deployed in a home local area network receives a scene instruction triggered by a user, acquires scene configuration information containing a control task of a first protocol device and a second protocol device from a local storage medium in response to the scene instruction, sends a first control instruction to the first protocol device through a first communication protocol, and sends a second control instruction to the second protocol device through a second communication protocol. The control instruction formats of the first communication protocol and the second communication protocol do not undergo protocol conversion inside the scene master control device, and the sending of the first control instruction and the second control instruction is independently scheduled and executed according to a preset timing strategy by the scene master control device after receiving the same scene instruction, independently of the execution result of the first control instruction. The application replaces the commonly used "protocol conversion" architecture in the prior art with a "unified scheduling" architecture, encapsulates the control tasks of heterogeneous systems under one scene instruction, solves the technical problem that heterogeneous communication protocol devices cannot work cooperatively under the same scene, simplifies the operation steps of cross-ecological scene linkage, and improves the consistency experience of whole-house intelligent control.

Description

Technical Field

[0001] This invention relates to the field of smart home control, and more specifically, to a method and system for cross-communication protocol-based smart home scene linkage control. Background Technology

[0002] With the development of smart home technology, a home often contains multiple smart devices using different communication protocols. For example, a user might simultaneously use a smart switch based on a 433MHz proprietary protocol and smart lighting based on a cloud-based ecosystem protocol. The advantages of the 433MHz proprietary protocol are local offline operation, fast response speed, and no network dependence; the advantages of the cloud-based ecosystem protocol are a wide variety of devices, support for remote control, and advanced functions (such as dimming and color adjustment).

[0003] However, in existing technologies, these two types of devices belong to two separate control systems. Users need to operate them separately: controlling the 433 switch via voice or physical buttons, and then controlling the smart lights in the cloud ecosystem via a mobile app or voice speaker. This fragmented operation method seriously affects the consistency of the user experience for whole-house smart home systems.

[0004] Current scene linkage functions are typically limited to a single ecosystem. For example, scene linkage of one ecosystem app can only control devices connected to that ecosystem, while scene linkage of another ecosystem app can only control devices on its cloud platform. When a user wants to "return home with one click," they cannot simultaneously trigger both the local 433 switch and the cloud-based smart light; they must set two separate scenes and trigger them sequentially, resulting in redundant steps and a poor user experience.

[0005] Furthermore, while multi-protocol gateway devices (such as smart gateways that simultaneously support Zigbee, Wi-Fi, and Bluetooth) exist in existing technologies, their functionality is mainly limited to independent control of different protocol devices within their respective protocol domains, or simply achieving basic state synchronization between different protocol devices. For cross-protocol linkage between local proprietary protocol devices and cloud-based ecosystem protocol devices, existing technologies generally adopt a "protocol conversion" approach—that is, setting up a protocol conversion module within the gateway or controller to uniformly convert the proprietary protocols of different devices into an intermediate or standard protocol, and then using this intermediate protocol for linkage control. For example, Zigbee protocol commands and Wi-Fi protocol commands are uniformly converted into a certain internal standard format, and then this internal standard format is converted into native commands that the corresponding devices can recognize.

[0006] In the field of smart homes, there is a prevalent, fixed understanding that to achieve device interaction across communication protocols, some form of "protocol conversion" or "message translation" is necessary to unify heterogeneous protocols into an intermediate language. This understanding leads those skilled in the art to consistently seek improvements along the "protocol conversion" technical route, creating path dependence, without considering whether there are alternative solutions that do not require protocol conversion. This invention overcomes the aforementioned technical bias and proposes for the first time a path to achieve cross-protocol scenario interaction without any protocol conversion.

[0007] The core concept of this invention lies in using a scene master control device as the scheduling center for cross-protocol collaboration. Upon receiving a single scene command triggered by a user, it decomposes it into multiple control tasks targeting devices with different communication protocols. The control commands for each task maintain the original format of their respective protocols and are directly issued and executed by the scene master control device through its built-in corresponding communication module. This "unified scheduling" architecture completely eliminates the protocol conversion step and achieves seamless collaboration of heterogeneous systems in the same scene through a unified task decomposition and timing scheduling mechanism. Summary of the Invention

[0008] The purpose of this invention is to provide a method and system for cross-communication protocol smart home scene linkage control, so as to solve the problem in the prior art that smart devices with different communication protocols cannot work together under a scene command.

[0009] To achieve the above objectives, the present invention provides a cross-communication protocol smart home scene linkage control method, applied to a scene master control device, wherein the scene master control device is a fixed smart control device deployed within a home local area network, and the method includes the following steps: Receive scene commands triggered by the user; In response to the scene command, scene configuration information corresponding to the scene command is obtained from the local storage medium of the scene master control device. The scene configuration information includes a first control task of at least one first protocol device and a second control task of at least one second protocol device. The first protocol device and the second protocol device adopt different wireless communication standards and belong to different device control ecosystems. According to the first control task, a first control command is sent to the first protocol device via a first communication protocol; According to the second control task, a second control command is sent to the second protocol device via the second communication protocol; The control command formats of the first communication protocol and the second communication protocol do not undergo protocol conversion within the scene master control device. After receiving the same scene command, the scene master control device, independent of the execution result of the first control command, uniformly schedules the sending of the first control command and the second control command according to a preset timing strategy.

[0010] Furthermore, the first communication protocol is a private wireless radio frequency protocol, and the second communication protocol is a cloud ecosystem protocol; the sending of the first control command to the first protocol device via the first communication protocol is accomplished by the scene master control device through its local wireless communication module; the sending of the second control command to the second protocol device via the second communication protocol is accomplished by the scene master control device through its built-in cloud ecosystem communication module, via a cloud server, to the second protocol device.

[0011] Furthermore, the first control task includes controlling the on / off state of local switching equipment; the second control task includes adjusting the brightness, color temperature, or color mode of cloud-based smart lighting fixtures.

[0012] Furthermore, the generation method of the scene configuration information includes: in scene setting mode, the scene master control device receives the user's pairing operation on the first protocol device to determine the first control task; receives the user's status setting operation on the second protocol device through the interactive interface of the scene master control device or an external terminal to determine the second control task; associates the first control task and the second control task with the same scene identifier and stores them in the local storage medium.

[0013] Furthermore, the scene master control device is the only cross-protocol scheduling node within the home LAN; the control logic of the first protocol device and the second protocol device are both uniformly managed within the scene master control device, and the scene master control device distributes instructions to the two heterogeneous systems respectively.

[0014] The present invention also provides a smart home scene linkage control system across communication protocols, including a scene master control device, at least one first protocol device using a first communication protocol, and at least one second protocol device using a second communication protocol; the scene master control device is configured to execute the method described in any of the above embodiments.

[0015] Compared with the prior art, the present invention has the following beneficial effects: This invention uses a scene master control device deployed in a home LAN as a scheduling center for cross-protocol collaboration. After receiving a single scene command triggered by the user, it decomposes it into multiple control tasks for devices with different communication protocols and schedules them to be executed in a unified manner according to a preset timing strategy. The control commands of each protocol device are independent of each other and there is no causal dependency, thereby realizing seamless collaboration between local private protocol devices and cloud ecosystem protocol devices in the same scene.

[0016] Compared to the commonly used "protocol conversion" architecture in existing technologies, the core innovation of this invention lies in the fact that the scene master control device does not have a protocol conversion module internally, and does not perform mutual conversion between the control command formats of the first and second communication protocols. The role of the scene master control device is "unified scheduling"—after decomposing the scene command into two independent control tasks, it directly issues control commands in native format through their respective corresponding communication modules. This "unified scheduling" architecture avoids the processing delays and compatibility risks caused by protocol conversion, simplifies the system architecture, reduces hardware costs, and simultaneously enables real-time collaborative response between two heterogeneous systems under the same user command.

[0017] This invention eliminates the need for users to perform repetitive operations in multiple control systems, simplifies the operation steps for cross-ecological scenario linkage, reduces the collaborative complexity of synchronizing the status of multiple protocol devices, and improves the consistent experience of whole-house smart control.

[0018] From a technical implementation perspective, this invention, through a "unified scheduling" architecture, enables manufacturers to integrate voice group control functionality without requiring protocol adaptation development based on existing switch control chips and firmware. Since the control command formats of the first and second communication protocols do not undergo mutual conversion within the scene master control device, manufacturers only need to integrate the corresponding protocol communication module into existing products to achieve scene-linked control across protocol devices. This architecture reduces the complexity of system integration, eliminating the need for the development and maintenance of protocol conversion modules for collaborative control between devices using different communication protocols. Attached Figure Description

[0019] Figure 1 This is a structural block diagram of a smart home scene linkage control system across communication protocols provided in an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of the functional modules of the scene master control device in an embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram illustrating the process of setting up and executing scenarios in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Example 1: Dual-system scenario linkage of local proprietary protocol and cloud ecosystem protocol

[0024] like Figure 1 As shown, this embodiment provides a smart home scene linkage control system that spans multiple communication protocols. The system includes a scene master control device 100, at least one first protocol device 200, and at least one second protocol device 300.

[0025] The scene master control device 100 is a fixed intelligent control device deployed within a home local area network. Distinguished from portable terminals such as user mobile phones, it has a fixed physical location and a continuously online operating status. The scene master control device 100 integrates dual communication modules, including a first communication module and a second communication module. The first communication module uses a local proprietary wireless radio frequency protocol (e.g., 433MHz) for direct local communication with the first protocol device 200. The second communication module uses a communication protocol supporting the cloud ecosystem (e.g., Bluetooth Mesh or Wi-Fi) for communication with the second protocol device 300 via a cloud server 400. It should be noted that the specific types of the first and second communication protocols mentioned above are merely examples; the core of this invention lies in a unified scheduling architecture across protocols, rather than protocol conversion.

[0026] The scene master control device 100 also includes a local storage medium (not shown in the figure) for pre-storing scene configuration information. The scene configuration information is generated and saved in this local storage medium during the scene setting phase, and is directly read by the scene master control device 100 from this local storage medium during the scene execution phase, eliminating the need to download it from the cloud each time it is executed. As the only cross-protocol scheduling node within the home LAN, the scene master control device 100 undertakes the scheduling responsibility for all cross-protocol scene linkages.

[0027] The first protocol device 200 is a smart switch or lighting controller that uses a first proprietary protocol. It forms a local offline control system with the scene master control device 100 through this proprietary protocol. The second protocol device 300 is a smart downlight, spotlight, light strip, or curtain motor that supports a second cloud ecosystem. It connects to the scene master control device 100 through this cloud ecosystem protocol.

[0028] like Figure 2 As shown, the scene control device 100 internally includes: The scene configuration module 101 is used to receive the user's configuration operation in the scene setting mode, generate scene configuration information, and store the scene configuration information in the local storage medium. The instruction decomposition module 102 is used to read scene configuration information from the local storage medium after receiving a scene trigger instruction, and decompose it into a first control task and a second control task. The first communication module 103 is used to perform the first control task and send the first control command to the first protocol device 200; The second communication module 104 is used to perform the second control task and send the second control command to the second protocol device 300. The unified scheduling module 105 is used to coordinate the instruction sending timing of the first communication module 103 and the second communication module 104, ensuring that the control instructions of the two heterogeneous systems are triggered by the same scenario instruction, and that the instruction sending trigger of the second communication module 104 does not depend on the instruction execution feedback of the first communication module 103, and is uniformly scheduled and executed according to a preset timing strategy (e.g., simultaneous issuance, or issuance according to a preset order).

[0029] It is important to emphasize that the scene master control device 100 does not have a protocol conversion module. The control commands issued by the first communication module 103 are always in the native format of the first communication protocol, and the control commands issued by the second communication module 104 are always in the native format of the second communication protocol. No protocol conversion or message translation is performed between the two. The responsibility of the scene master control device 100 is "unified scheduling"—after breaking down the scene commands into two independent control tasks, it directly issues control commands in native format through their respective communication modules.

[0030] like Figure 3 As shown, the scenario setup and execution process is as follows:

[0031] Scene setup phase: Users can trigger the scene control device 100 to enter the scene setting mode via voice or button. The user first operates the first protocol device 200 (for example, pressing the local smart switch that needs to be controlled), and the scene master control device 100 records the device's identifier and its target state as the first control task. The user then sets the target state of the second protocol device 300 (e.g., setting the cloud-based smart light to a warm color and 80% brightness) through the interactive interface of the scene master control device 100 or through an external terminal (such as a mobile APP). The scene master control device 100 records this state information as the second control task. The scene master control device 100 associates the first control task and the second control task with the same scene identifier (such as "home mode"), and stores the scene configuration information in the local storage medium to complete the scene configuration.

[0032] Scenario execution phase: Users can issue a voice command for "Home Mode" to the scene control device 100 or press the corresponding scene button. The instruction decomposition module 102 reads the pre-stored scene configuration information from the local storage medium and extracts the first control task and the second control task. The unified scheduling module 105 performs scheduling according to a preset timing strategy: In this embodiment, to ensure a fast response from local devices and a smooth startup experience for cloud devices, the unified scheduling module 105 controls the first communication module 103 and the second communication module 104 to simultaneously issue commands; in another preferred timing strategy, the first communication module 103 can also be controlled to issue commands first, followed by the commands from the second communication module 104. Regardless of the timing strategy used, the sending of commands by the second communication module 104 does not depend on whether the first communication module 103 receives execution feedback. The first communication module 103 sends control commands, such as "turn on the living room light" or "turn on the dining room light," directly to the first protocol device 200 via a local proprietary protocol. These commands are always in the native format of the first communication protocol and do not undergo any protocol conversion. The second communication module 104 sends control commands to the second protocol device 300 via the cloud server 400, such as "adjust the living room spotlights to a warm color and 80% brightness". This command is always in the native format of the second communication protocol and does not undergo any protocol conversion.

[0033] Ultimately, the user experiences the following scene: the basic lighting in the living room and dining room instantly illuminates (completed by the local system with a millisecond response time), while the ambient spotlights in the living room smoothly transition to a preset warm brightness (completed by the cloud system). The entire process is triggered by a user's scene command. The two heterogeneous systems seamlessly collaborate under the unified scheduling of the scene master control device 100, and the control actions of the two systems are independent. Execution delays or feedback anomalies in either system do not affect the transmission of control commands to the other system. It is important to emphasize that the command transmission of the second communication module 104 is independent of whether the first communication module 103 successfully receives execution confirmation feedback from the first protocol device 200. Even if the first protocol device 200 fails to return a confirmation signal for any reason, the transmission process of the second control command remains unaffected.

[0034] Example 2: Extended Applications of Other Communication Protocol Combinations

[0035] The core concept of this invention is not limited to the specific protocol combinations in the above embodiments. For example, the first communication protocol can be replaced with other local or regional protocols such as Zigbee or Z-Wave, and the second communication protocol can be replaced with cloud ecosystem protocols from other brands. As long as the scene control device integrates a communication module with the corresponding protocol and has the ability to decompose scene commands into heterogeneous system control tasks without protocol conversion, the cross-protocol collaborative effect described in this invention can be achieved.

[0036] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention.

Claims

1. A method for cross-communication protocol smart home scene linkage control, characterized in that, The method, applied to a scene control device, which is a fixed intelligent control device deployed within a home local area network, includes: receiving a scene command triggered by a user; responding to the scene command by retrieving scene configuration information corresponding to the scene command from the local storage medium of the scene control device, wherein the scene configuration information includes a first control task of at least one first protocol device and a second control task of at least one second protocol device, the first protocol device and the second protocol device employing different wireless communication standards and belonging to different device control ecosystems; sending a first control command to the first protocol device via a first communication protocol according to the first control task; and sending a second control command to the second protocol device via a second communication protocol according to the second control task; wherein the control command formats of the first communication protocol and the second communication protocol do not undergo protocol conversion within the scene control device, and after receiving the same scene command, the scene control device, independently of the execution result of the first control command, uniformly schedules the sending of the first control command and the second control command according to a preset timing strategy.

2. The method according to claim 1, characterized in that, The first communication protocol is a private wireless radio frequency protocol, and the second communication protocol is a cloud ecosystem protocol; the sending of the first control command to the first protocol device via the first communication protocol is accomplished by the scene master control device through its local wireless communication module; the sending of the second control command to the second protocol device via the second communication protocol is accomplished by the scene master control device through its built-in cloud ecosystem communication module, via a cloud server, to the second protocol device.

3. The method according to claim 2, characterized in that, The first control task includes controlling the on / off state of local switching equipment; the second control task includes adjusting the brightness, color temperature, or color mode of cloud-based smart lighting fixtures.

4. The method according to claim 1, characterized in that, The generation method of the scene configuration information includes: In scene setting mode, the scene master control device receives the user's pairing operation on the first protocol device to determine the first control task; receives the user's status setting operation on the second protocol device through the interactive interface of the scene master control device or an external terminal to determine the second control task; associates the first control task and the second control task with the same scene identifier and stores them in the local storage medium.

5. The method according to claim 1, characterized in that, The scene master control device is the only cross-protocol scheduling node within the home LAN; the control logic of the first protocol device and the second protocol device are both uniformly managed within the scene master control device, and the scene master control device distributes instructions to the two heterogeneous systems respectively.

6. A smart home scene linkage control system that crosses communication protocols, characterized in that, The system includes a scene master control device, at least one first protocol device employing a first communication protocol, and at least one second protocol device employing a second communication protocol; the scene master control device is configured to perform the method according to any one of claims 1 to 5.

7. The system according to claim 6, characterized in that, The main control device of the scenario integrates a first communication module and a second communication module, as well as a unified scheduling module. The unified scheduling module is used to coordinate the instruction sending timing of the first communication module and the second communication module according to the preset timing strategy, and the instruction sending trigger of the second communication module does not depend on the instruction execution feedback of the first communication module.

8. A scene master control device, characterized in that, The scene master control device is a fixed intelligent control device deployed within a home local area network. The scene master control device includes: a first communication module for communicating with a first protocol device via a first communication protocol; a second communication module for communicating with a second protocol device via a second communication protocol; a local storage medium for storing scene configuration information, which includes a first control task from at least one first protocol device and a second control task from at least one second protocol device. The first and second protocol devices use different wireless communication standards and belong to different device control ecosystems; and a unified scheduling module for, upon receiving a scene instruction, retrieving the scene configuration information from the local storage medium, decomposing it into a first control task and a second control task, and coordinating the first and second communication modules to send control instructions according to a preset timing strategy. The control instruction formats of the first and second communication protocols do not undergo protocol conversion within the scene master control device. Upon receiving the same scene instruction, the unified scheduling module, independent of the execution result of the first control instruction, uniformly schedules the sending of the first and second control instructions according to the preset timing strategy.

Images