Multi-device linkage method and device based on home scenario

Abstract

The application relates to the field of Internet of Things, and provides a multi-device linkage method and device based on a home scene. The method comprises the following steps: receiving and executing a trigger instruction; based on the trigger instruction, a control instruction is sent to a second binding device by using a point-to-point (P2P) mapping relationship established in advance. The multi-device linkage method based on the home scene provided by the application directly receives the control instruction sent by the first binding device through the P2P mapping relationship established in advance, thereby realizing the connection and control between devices through local P2P hole punching, avoiding the situation that the communication distance is far in cloud control, improving the communication efficiency, reducing the dependence on the cloud platform, thereby reducing the load of the cloud platform, ensuring that the linkage can be normally performed when the cloud platform is abnormal, widening the use scene, and simultaneously reducing various problems and complaints caused by network problems without depending on the Internet.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, specifically to a method and apparatus for multi-device linkage in a home setting. Background Technology

[0002] With the development of IoT technology, more and more smart devices are appearing in homes. These devices typically only meet a single need in a specific scenario. For example, a smart door lock can unlock after recognizing the homeowner, and a smart light bulb can turn on and off after receiving a control command. Consumers therefore hope to have these devices interconnected to meet more usage scenarios, such as turning on the lights simultaneously when they unlock the door upon returning home at night.

[0003] Currently, to achieve intelligent linkage, cloud control is mainly adopted. The corresponding linkage rules are configured through mobile phones. When linkage needs to be triggered, the corresponding control command is uploaded to the cloud platform by operating the mobile phone. The cloud platform then sends the command to the devices in the home. For example, a voice command can be used to turn off the lights, turn off the TV, close the curtains, etc., thereby realizing device control and device linkage.

[0004] However, the above-mentioned cloud control methods mainly rely on cloud platform control. Once the cloud server malfunctions, the corresponding linkage functions will all fail. Furthermore, due to the heavy reliance on the cloud platform, it will also increase the burden on the cloud platform. Summary of the Invention

[0005] This application provides a method and apparatus for multi-device linkage in a home setting, which solves the technical problem that the linkage of devices is affected by the limitations of the usage environment.

[0006] In a first aspect, embodiments of this application provide a multi-device linkage method based on a home scenario, comprising: receiving a control command sent by a first bound device, wherein the control command is sent by the first bound device after receiving a trigger command and utilizing a previously established point-to-point P2P mapping relationship; and executing the control command.

[0007] In one embodiment, before receiving the control command sent by the first bound device, the process includes: receiving a P2P hole punching request, wherein the P2P hole punching request is sent by the first bound device based on a previously received first binding result, the first binding result being obtained and sent by the cloud platform based on device binding information sent by the user terminal, the first binding result including device information of the device that has been bound to the first bound device, the device information including the device identifier, control type, local IP address and upstream routing address of the corresponding device; based on the P2P hole punching request, combined with the previously received second binding result, establishing a P2P mapping relationship with the first bound device, and generating hole punching status feedback information, the second binding result being obtained and sent by the cloud platform based on device binding information sent by the user terminal, the second binding result including the device information of the first bound device; and sending the hole punching status feedback information to the first bound device.

[0008] In one embodiment, the first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal and binding the corresponding devices based on the device function determination; the device binding information includes the device information of at least two devices to be bound; the device function determination is the cloud platform determining whether the devices to be bound all have P2P function and whether they all support device linkage based on the bound device information;

[0009] Before receiving the P2P hole punching request, the process also includes: receiving a broadcast command sent by the cloud platform, which is sent by the cloud platform after determining that the device is located on the same upper-level route as the first bound device based on the bound device information; executing the broadcast command and broadcasting the device information; receiving response information returned by other devices based on the received broadcast device information, including the first bound device or other unbound devices; comparing the device identifier in the response information with the device identifier in the previously received second binding result, and determining that the corresponding other device is the first bound device based on the matching device identifiers, and stopping the broadcast.

[0010] Before receiving the P2P hole punching request, the process also includes: sending device information to the first bound device using the cloud platform; receiving the device information of the first bound device returned by the first bound device using the cloud platform; and comparing the device information of the first bound device returned by the first bound device using the cloud platform with the previously received second binding result to determine whether the device identifiers are consistent.

[0011] In one embodiment, the response information is the device information of another device that responds after comparing the device identifier of the received broadcast device information with the device identifier of the previously received third binding result; the third binding result is the device information of the device bound to the other device; the device identifier comparison is used to determine whether the device identifier in the broadcast device information is consistent with the device identifier in the third binding result.

[0012] Before receiving the broadcast command sent by the cloud platform, the process includes: receiving a port request command sent by the cloud platform, which is sent by the cloud platform after determining that the first bound device is not located on the same upper-level route based on the bound device information; sending a port request request to the router based on the port request command, which is used to request an externally mapped port on the same upper-level route as the first bound device; receiving the port request result returned by the router based on the port request request; determining that the port request was successful based on the port request result, and sending the port mapping relationship in the port request result to the first bound device through the cloud platform.

[0013] In one embodiment, receiving the port request result returned by the router based on the port request request further includes: determining, based on the port request result, that the external mapped port has been occupied, then reselecting the external mapped port based on a preset selection rule, and generating a corresponding port request request.

[0014] In one embodiment, the device information of the first bound device returned by the first bound device using the cloud platform is sent by the first bound device after determining that the device identifier is consistent with the device information sent to the first bound device using the cloud platform and the previously received first binding result.

[0015] Secondly, embodiments of this application provide a multi-device linkage device based on a home scenario, comprising: an instruction receiving module, configured to: receive control instructions sent by a first bound device, wherein the control instructions are sent by the first bound device after receiving a trigger instruction, using a pre-established point-to-point P2P mapping relationship; and an instruction execution module, configured to: execute the control instructions.

[0016] Thirdly, embodiments of this application provide a terminal, including a memory, a transceiver, and a processor; the memory is used to store a computer program; the transceiver is used to send and receive data under the control of the processor; the processor is used to read the computer program in the memory and perform the following operations: receiving a control instruction sent by a first bound device, the control instruction being sent by the first bound device after receiving a trigger instruction using a previously established point-to-point P2P mapping relationship; and executing the control instruction.

[0017] Fourthly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the multi-device linkage method based on a home scenario described in the first or second aspect.

[0018] Fifthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the multi-device linkage method based on a home scenario described in the first aspect.

[0019] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-device linkage method based on a home scenario described in the first or second aspect.

[0020] The multi-device linkage method and apparatus based on home scenarios provided in this application embodiment directly receive control commands sent by the first bound device through a pre-established P2P mapping relationship. This enables connection and control between devices through local P2P hole punching, avoiding situations where cloud control communication distances are too long, improving communication efficiency, reducing dependence on the cloud platform, thereby reducing the load on the cloud platform, ensuring normal linkage even when the cloud platform is abnormal, expanding the application scenarios, and reducing various problems and complaints caused by network issues by not relying on the Internet. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is one of the flowcharts illustrating the multi-device linkage method based on a home scenario provided in the embodiments of this application;

[0023] Figure 2 This is the second flowchart illustrating the multi-device linkage method based on a home scenario provided in this application embodiment;

[0024] Figure 3 This is the third flowchart illustrating the multi-device linkage method based on a home scenario provided in this application embodiment;

[0025] Figure 4 This is one of the structural schematic diagrams of a multi-device linkage device based on a home scenario provided in the embodiments of this application;

[0026] Figure 5 This is the second schematic diagram of the structure of the multi-device linkage device based on a home scenario provided in the embodiments of this application;

[0027] Figure 6 This is the third structural schematic diagram of the multi-device linkage device based on a home scenario provided in the embodiments of this application;

[0028] Figure 7 This is a schematic diagram of the terminal structure provided in the embodiments of this application;

[0029] Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0031] Reference Figure 1 This illustration shows a flowchart of a multi-device linkage method based on a home scenario provided by an embodiment of this application. The method may include:

[0032] S11, Receive control instructions sent by the first bound device. The control instructions are sent by the first bound device after receiving the trigger instruction, using the previously established point-to-point P2P mapping relationship.

[0033] S12 executes control commands.

[0034] It should be noted that the execution subject of this method is the second bound device controlled by the first bound device. S1N in this specification does not represent the order of the multi-device linkage method based on the home scenario. The multi-device linkage method based on the home scenario of the present invention is described in detail below.

[0035] Step S11: Receive control instructions sent by the first bound device. The control instructions are sent by the first bound device after receiving the trigger instruction, using the previously established point-to-point P2P mapping relationship.

[0036] It should be noted that the trigger command is used to control the first bound device to execute corresponding instructions. For example, when the first bound device is a door lock, it controls the door to open; or when the first bound device is a light, it controls the light to turn on. In addition, the trigger command can be generated directly based on triggering the first bound device, or it can be sent from the cloud platform to the first bound device based on the user's trigger. No further limitations are made here.

[0037] It should be noted that the first and second bound devices can select corresponding smart home devices based on linkage requirements, and the second bound device is controlled by the first bound device. The number of second bound devices can be at least one. In addition, the first and second bound devices can be the same or different smart home devices, including at least one of the following smart home appliances: home cameras, large-screen TVs, smart doorbells and locks, smart speakers, smart lights, etc.

[0038] In one optional embodiment, before receiving the control command sent by the first bound device, the process includes: receiving a P2P hole punching request, wherein the P2P hole punching request is sent by the first bound device based on a previously received first binding result, the first binding result being obtained and sent by the cloud platform based on device binding information sent by the user terminal, the first binding result including device information of the device that has been bound to the first bound device; based on the P2P hole punching request and combined with the previously received second binding result, establishing a P2P mapping relationship with the first bound device and generating hole punching status feedback information, the second binding result being obtained and sent by the cloud platform based on device binding information sent by the user terminal, the second binding result including device information of the first bound device; and sending the hole punching status feedback information to the first bound device.

[0039] It should be noted that by using local P2P hole punching to achieve connection and control between the first and second bound devices, the long communication distance of cloud control is avoided, communication efficiency is improved, dependence on the cloud platform is reduced, and the load on the cloud platform is reduced. This ensures normal linkage even when the cloud platform is abnormal, expands the application scenarios, and reduces various problems and complaints caused by network issues by not relying on the Internet.

[0040] In addition, the device information includes the device identifier, control type, local IP address and the IP address of the upstream router. The control type is used to indicate whether the corresponding device is a master device or a controlled device.

[0041] Furthermore, the first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal and binding the corresponding device based on the device function determination. The device binding information includes the device information of at least two devices to be bound. The device function determination is the cloud platform's determination based on the bound device information to determine whether the devices to be bound all have P2P function and whether they all support device linkage.

[0042] Specifically, before the second bound device establishes a P2P mapping relationship with the first bound device, the user terminal sets device binding information based on linkage requirements and sends the device binding information to the cloud platform. The device binding information includes device information of at least two devices to be bound. The cloud platform determines, based on the device binding information, that the corresponding devices to be bound all have P2P functionality and support device linkage, and binds the corresponding devices to be bound, obtaining a first binding result and a second binding result. The first binding result includes the device information of the second bound device, which is the current executing entity, and the second binding result includes the device information of the first bound device. The cloud platform sends the first binding result to the first bound device and the second binding result to the second bound device.

[0043] It should be noted that the binding between devices only needs to be done once. After binding, the connection and control between the first and second bound devices can be achieved directly using the local P2P method, reducing the dependence on the cloud platform and network, ensuring normal linkage even when the cloud platform or network is abnormal, and broadening the application scenarios.

[0044] In one possible implementation, before receiving the P2P hole punching request, the process further includes: receiving a broadcast instruction sent by the cloud platform, which is sent by the cloud platform after determining that the device is located on the same upper-level route as the first bound device based on the bound device information; executing the broadcast instruction to broadcast the device information; receiving response information returned by other devices based on the received broadcast device information, the other devices including the first bound device or other unbound devices; comparing the device identifier in the response information with the device identifier in the previously received second binding result, and determining that the corresponding other device is the first bound device based on the consistency of the device identifier, and stopping the broadcast.

[0045] It should be added that the response information is the device information of other devices based on the comparison of the device identifiers of the received broadcast device information and the previously received third binding result, and the response is the device information of the device after determining that the device identifiers are consistent; the third binding result is the device information of the device bound to other devices; the device identifier comparison is used to determine whether the device identifier in the broadcast device information is consistent with the device identifier in the third binding result.

[0046] In addition, comparing the device identifier in the response information with the device identifier in the previously received second binding result also includes: based on the inconsistency of the device identifiers, continuing to broadcast device information and repeating the above steps until the first binding device is determined.

[0047] In one alternative embodiment, prior to broadcasting device information, the method includes: listening to a port to promptly ascertain whether the first bound device is connected to other devices.

[0048] In one optional embodiment, before receiving the broadcast instruction sent by the cloud platform, the process includes: receiving a port request instruction sent by the cloud platform, wherein the port request instruction is sent by the cloud platform after determining, based on the bound device information, that the first bound device is not located on the same upper-level route; based on the port request instruction, sending a port request request to the router, wherein the port request request is used to request an externally mapped port located on the same upper-level route as the first bound device; receiving a port request result returned by the router based on the port request request; and based on the port request result, determining that the port request was successful, and sending the port mapping relationship in the port request result to the first bound device through the cloud platform.

[0049] It should be noted that after receiving the port request result returned by the router based on the port request request, the process includes: listening to the port in order to know in real time whether the port is connected to other devices.

[0050] It's important to note that when sending a port request to the router using a port request command, the UPnP protocol can be used to proactively add port mappings to the router. Upon successful request, the port mapping relationship is obtained, including the local IP address, local port, protocol type (TCP or UDP), and the obtained external mapped port. By using UPnP to map external network ports, the issue of unsuccessful hole punching when devices are distributed across secondary routers is resolved, improving the success rate of hole punching and expanding the application scenarios to secondary routers, thus broadening the usage scenarios.

[0051] In addition, receiving the port request result returned by the router based on the port request also includes: determining, based on the port request result, that the externally mapped port is already occupied, then reselecting the externally mapped port based on a preset selection rule, and generating a corresponding port request. The preset selection rule can be set based on actual design requirements. For example, if the currently selected externally mapped port 5000 is already occupied, and the preset selection rule is to add 100, then the externally mapped port 5100 will be reselected. No further limitations are imposed here.

[0052] To facilitate intelligent selection of local broadcast or cloud forwarding based on the network distribution of the devices, and to improve the connection success rate of devices under various network conditions, another possible implementation includes, before receiving the P2P hole punching request, the following steps: sending device information to the first bound device via the cloud platform; receiving the device information of the first bound device returned by the first bound device via the cloud platform; and comparing the device information of the first bound device returned by the first bound device via the cloud platform with the previously received second binding result to determine whether the device identifiers are consistent.

[0053] Furthermore, the device information of the first bound device returned by the cloud platform is sent by the first bound device after confirming that the device identifier is consistent with the device information sent to the first bound device by the cloud platform and the previously received first binding result.

[0054] Step S12: Execute control commands.

[0055] In this embodiment, after executing the control command, the process includes sending an execution status to the first bound device so that the first bound status can determine the execution status of the second device command.

[0056] In summary, this embodiment of the invention directly receives control commands sent by the first bound device through a pre-established P2P mapping relationship, thereby achieving connection and control between devices through local P2P hole punching. This avoids situations where cloud control communication distances are too long, improves communication efficiency, reduces dependence on the cloud platform, and thus reduces the load on the cloud platform. It also ensures normal linkage even when the cloud platform is abnormal, broadens the application scenarios, and reduces various problems and complaints caused by network issues by not relying on the Internet.

[0057] Reference Figure 2 This illustration shows a flowchart of a multi-device linkage method based on a home scenario provided by an embodiment of this application. The method may include:

[0058] S21, Receive and execute the trigger command;

[0059] S22, based on the trigger command, uses the previously established point-to-point (P2P) mapping relationship to send control commands to the second bound device.

[0060] It should be noted that the execution subject of this method is the first bound device, which controls at least one second bound device. S2N in this specification does not represent the order of the multi-device linkage method based on the home scenario. The multi-device linkage method based on the home scenario of the present invention is described in detail below.

[0061] Step S21: Receive and execute the trigger command.

[0062] It should be noted that the trigger command is used to control the first bound device to execute corresponding instructions. For example, when the first bound device is a door lock, it controls the door to open; or when the first bound device is a light, it controls the light to turn on. In addition, the trigger command can be generated directly based on triggering the first bound device, or it can be sent from the cloud platform to the first bound device based on the user's trigger. No further limitations are made here.

[0063] In one optional embodiment, before sending the control command to the second binding device, the process includes: sending a P2P hole punching request to the second binding device, the P2P hole punching request being sent based on a first binding result previously received from the cloud platform; and receiving hole punching status feedback information returned by the second binding device, the hole punching status feedback information being generated by the second binding device after establishing a P2P mapping relationship based on the second binding result previously sent by the cloud platform. It should be noted that the first binding result and the second binding result can be referred to in the embodiments described above, and will not be repeated here.

[0064] In one possible implementation, before sending the P2P hole punching request to the second bound device, the method further includes: receiving broadcast device information broadcast by the second bound device, wherein the broadcast device information is broadcast by the second bound device based on a broadcast command issued by the cloud platform, and the broadcast command is sent by the cloud platform after determining that the current execution entity, the first bound device, and the second bound device are located on the same upper-level route based on the bound device information; comparing the device identifier in the broadcast device information with the device identifier in the previously received first binding result, and generating response information based on its own device information based on the consistency of the device identifiers, and sending the response information to the second bound device for device identifier comparison.

[0065] It should be added that the device identifier comparison is to check whether the device identifier in the response information of the second bound device is consistent with the device identifier in the second binding result sent by the cloud platform earlier.

[0066] Specifically, after sending the response information to the second binding device, the second binding device compares the response information with the previously received second binding result. If the device identifier matches the comparison result, it determines that the corresponding other device is the first binding device and stops broadcasting. If the device identifier does not match the comparison result, it continues to broadcast device information and repeats the above steps until the first binding device is determined.

[0067] In an optional embodiment, before receiving the broadcast device information broadcast by the second bound device, the method further includes: receiving a port mapping relationship sent by the cloud platform. This port mapping relationship is sent by the second bound device using the cloud platform and is obtained based on a port request result sent by the router to the second bound device. The port request result is returned by the router based on a port application request sent by the second bound device, which is generated by the second bound device based on a port application instruction sent by the cloud platform. It should be noted that when the second bound device sends a port mapping relationship to the first bound device (the current executing entity) using the cloud platform, the port request result should indicate that the port application was successful. If the port request result indicates that the port is already occupied, the second bound device needs to reselect an external mapping port based on preset selection rules and reapply until the application is successful, then send the successfully obtained port mapping relationship to the first bound device.

[0068] In another possible implementation, before sending the P2P hole-punching request to the second bound device, the process further includes: receiving device information of the first bound device sent by the second bound device via a cloud platform; comparing the device information of the first bound device with the previously received first binding result for device identification, and based on the consistency of the device identification, sending its own device information, i.e., the device information of the first bound device, to the second bound device for device identification comparison; and the second bound device comparing the device information of the first bound device with the second binding result for device identification comparison. It should be noted that the device identification comparison can be referred to the above description and will not be repeated here.

[0069] Step S22: Based on the trigger command, a control command is sent to the second bound device using the previously established point-to-point P2P mapping relationship, so that the second bound device can receive and execute the control command, thereby realizing the connection and linkage between the second bound device and the first bound device.

[0070] In summary, this embodiment of the invention sends control commands directly to the second bound device through a pre-established P2P mapping relationship, thereby achieving connection and control between devices through local P2P hole punching. This avoids situations where cloud control communication distances are too long, improves communication efficiency, reduces dependence on the cloud platform, and thus reduces the load on the cloud platform. It also ensures normal linkage even when the cloud platform is abnormal, broadens the application scenarios, and reduces various problems and complaints caused by network issues by not relying on the Internet.

[0071] Reference Figure 3 This illustration shows a flowchart of a multi-device linkage method based on a home scenario provided by an embodiment of this application. The method may include:

[0072] S31, the first bound device receives and executes the trigger command;

[0073] S32, the first bound device sends a control command to the second bound device based on the trigger command and the previously established point-to-point P2P mapping relationship;

[0074] S33, the second bound device receives and executes the control command.

[0075] It should be noted that S3N in this specification does not represent the order of the multi-device linkage method based on a home scenario. The multi-device linkage method based on a home scenario of the present invention is described in detail below.

[0076] It should be noted that the first and second bound devices can select corresponding smart home devices based on linkage requirements, and the second bound device is controlled by the first bound device. The number of second bound devices can be at least one. In addition, the first and second bound devices can be the same or different smart home devices, including at least one of the following smart home appliances: home cameras, large-screen TVs, smart doorbells and locks, smart speakers, smart lights, etc.

[0077] In an optional embodiment, before step S32, the process includes: a first binding device sending a P2P hole punching request to a second binding device, the P2P hole punching request being sent by the first binding device based on a first binding result previously received from the cloud platform; the second binding device receiving the P2P hole punching request, establishing a P2P mapping relationship with the first binding device based on the P2P hole punching request and the previously received second binding result, generating hole punching status feedback information, and sending the hole punching status feedback information to the first binding device; and the first binding device receiving the hole punching status feedback information.

[0078] It should be noted that the P2P hole punching request is sent by the first bound device based on the first bound result received earlier. The first bound result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The first bound result includes the device information of the device that has been bound to the first bound device. The second bound result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The second bound result includes the device information of the first bound device.

[0079] In an optional embodiment, before the first bound device sends a P2P hole punching request to the second bound device, the method further includes: the user terminal setting device binding information based on linkage requirements and sending the device binding information to the cloud platform, the device binding information including device information of at least two devices to be bound; the cloud platform determining, based on the device binding information, that the corresponding devices to be bound all have P2P functionality and support device linkage, binding the corresponding devices to be bound to obtain a first binding result and a second binding result, the first binding result including device information of the second bound device of the current executing entity, and the second binding result including device information of the first bound device; the cloud platform sending the first binding result to the first bound device and the second binding result to the second bound device.

[0080] In one possible implementation, after the cloud platform sends the first binding result to the first bound device and the second binding result to the second bound device, and before the second bound device receives the P2P hole punching request, the process includes: the cloud platform, based on the bound device information, determining that the second bound device and the first bound device are located on the same upstream route, and sending a broadcast command to the second bound device; the second bound device executes the broadcast command and broadcasts device information; other devices receive the broadcast device information, compare the device identifier in the broadcast device information with the device identifier in the previously received third binding result, and based on consistency, send their own first bound device's device information as response information to the second bound device; the second bound device receives the response information, compares the device identifier in the response information with the device identifier in the previously received second binding result, and based on consistency of device identifiers, stops broadcasting; based on inconsistency of device identifiers, continues broadcasting device information, and repeats the above steps until the first bound device is determined.

[0081] In one optional embodiment, after the cloud platform sends the first binding result to the first binding device and the second binding result to the second binding device, and before the second binding device receives the P2P hole punching request, the process includes: the cloud platform determining, based on the binding device information, that the second binding device and the first binding device are not located on the same upstream route, and sending a port request instruction to the second binding device; the second binding device sending a port request to the router based on the port request instruction; the router returning a port request result to the second binding device based on the port request request; the second binding device determining, based on the port request result, that the port request was successful, and sending the port mapping relationship in the port request result to the first binding device through the cloud platform; and the second binding device determining, based on the port request result, that the external mapped port has been occupied, then reselecting an external mapped port based on a preset selection rule, and generating a corresponding port request.

[0082] In another possible implementation, after the cloud platform sends the first binding result to the first bound device and the second binding result to the second bound device, and before the second bound device receives the P2P hole punching request, the method further includes: the second bound device sending device information to the first bound device using the cloud platform; the first bound device receiving the device information of the second bound device and comparing it with the previously received first binding result for device identification; if the device identifications match, the first bound device sending its own device information to the first bound device using the cloud platform; the first bound device receiving the binding information of the second bound device and comparing it with the previously received first binding result for device identification; and based on the matching device identifications, stopping the sending of its own device information using the cloud platform.

[0083] In summary, the first bound device in this embodiment of the invention sends control commands directly to the second bound device through a pre-established P2P mapping relationship. This enables connection and control between devices via local P2P hole punching, avoiding long communication distances in cloud control, improving communication efficiency, reducing dependence on the cloud platform, and thus alleviating the load on the cloud platform. It also ensures normal operation even when the cloud platform is abnormal, broadening the application scenarios. Furthermore, by not relying on the internet, it reduces various problems and complaints caused by network issues.

[0084] The following describes the multi-device linkage device based on a home scenario provided in the embodiments of this application. The multi-device linkage device based on a home scenario described below and the multi-device linkage method based on a home scenario described above can be referred to in correspondence with each other.

[0085] Figure 4 A schematic diagram of a multi-device linkage device based on a home scenario is shown. Corresponding to the second bound device, the device includes:

[0086] The instruction receiving module 41 is used to: receive control instructions sent by the first bound device, wherein the control instructions are sent by the first bound device after receiving the trigger instruction, using the previously established point-to-point P2P mapping relationship;

[0087] Instruction execution module 42 is used to execute control instructions.

[0088] In this embodiment, the device further includes: a P2P request receiving module, which receives a P2P hole punching request before receiving a control command sent by the first bound device. The P2P hole punching request is sent by the first bound device based on a previously received first binding result. The first binding result is obtained and sent by the cloud platform based on device binding information sent by the user terminal. The first binding result includes device information of the device that has been bound to the first bound device; a P2P relationship establishment module, which establishes a P2P mapping relationship with the first bound device based on the P2P hole punching request and combined with a previously received second binding result, and generates hole punching status feedback information. The second binding result is obtained and sent by the cloud platform based on device binding information sent by the user terminal. The second binding result includes device information of the first bound device; and an information feedback module, which sends the hole punching status feedback information to the first bound device.

[0089] In one possible implementation, the device further includes: a broadcast instruction receiving module, which receives a broadcast instruction sent by a cloud platform before receiving a P2P hole punching request. The broadcast instruction is sent by the cloud platform after determining that the device is located on the same upper-level route as the first bound device based on the bound device information; a broadcast instruction execution module, which executes the broadcast instruction and broadcasts the device information; a response information receiving module, which receives response information returned by other devices based on the received broadcast device information. The other devices include the first bound device or other unbound devices; and a first identifier comparison module, which compares the device identifier in the response information with the device identifier in the previously received second binding result. If the device identifiers match, the module determines that the corresponding other device is the first bound device and stops broadcasting. If the device identifiers do not match, the module continues to broadcast the device information and repeats the above steps until the first bound device is determined.

[0090] In one alternative embodiment, the device includes a listening module that listens to a port before broadcasting device information in order to know in a timely manner whether the first bound device is connected to other devices.

[0091] In an optional embodiment, the device further includes: a port request receiving module, which receives a port request instruction sent by the cloud platform before receiving a broadcast instruction sent by the cloud platform. The port request instruction is sent by the cloud platform after determining, based on the bound device information, that the first bound device is not located on the same upper-level route; a port request module, which sends a port request request to the router based on the port request instruction. The port request request is used to request an externally mapped port located on the same upper-level route as the first bound device; a result receiving module, which receives a port request result returned by the router based on the port request request; a relationship sending module, which determines that the port request is successful based on the port request result and sends the port mapping relationship in the port request result to the first bound device through the cloud platform; and a port request module, which determines that the externally mapped port is occupied based on the port request result and then reselects an externally mapped port based on a preset selection rule and generates a corresponding port request request.

[0092] In an optional embodiment, the listening module is further configured to listen to the port after receiving the port request result returned by the router based on the port request request, so as to know in real time whether the port is connected to other devices.

[0093] In another possible implementation, the device further includes: a first information sending module, which sends device information to the first bound device via a cloud platform before receiving a P2P hole punching request; a first information receiving module, which receives the device information of the first bound device returned by the first bound device via the cloud platform; and a first identifier comparison module, which compares the device information of the first bound device returned by the first bound device via the cloud platform with the previously received second binding result to determine whether the device identifiers are consistent. It should be noted that the received device information of the first bound device returned by the first bound device via the cloud platform is sent by the first bound device after determining that the device identifiers are consistent with the device information sent to the first bound device via the cloud platform and the previously received first binding result.

[0094] In this embodiment, the device further includes a status return module, which sends an execution status to the first bound device after executing the control command, so that the first bound status can determine the command execution status of the second device command.

[0095] In summary, the instruction receiving module of this embodiment of the invention directly receives control instructions sent by the first bound device through a pre-established P2P mapping relationship. This enables connection and control between devices through local P2P hole punching, avoiding situations where cloud control communication distances are too long, improving communication efficiency, reducing dependence on the cloud platform, thereby reducing the load on the cloud platform, ensuring normal linkage even when the cloud platform is abnormal, expanding the application scenarios, and reducing various problems and complaints caused by network issues by not relying on the Internet.

[0096] Figure 5 A schematic diagram of a multi-device linkage device based on a home scenario is shown. Corresponding to the first bound device, the device includes:

[0097] The first control module 51 is used to: receive and execute trigger commands;

[0098] The second control module 52 is used to: send control commands to the second bound device based on the trigger command and using the previously established point-to-point P2P mapping relationship.

[0099] In this embodiment, the device further includes: a P2P request sending module, which sends a P2P hole punching request to the second binding device before sending a control command to the second binding device. The P2P hole punching request is sent based on the first binding result sent by the cloud platform in advance; and a feedback information receiving module, which receives hole punching status feedback information returned by the second binding device. The hole punching status feedback information is generated by the second binding device after establishing a P2P mapping relationship based on the second binding result sent by the cloud platform in advance.

[0100] In one possible implementation, the device further includes: a broadcast information receiving module, which receives broadcast device information broadcast by the second bound device before sending a P2P hole punching request to the second bound device. The broadcast device information is broadcast by the second bound device based on a broadcast command issued by the cloud platform. The broadcast command is sent by the cloud platform after determining that the current execution entity, the first bound device, and the second bound device are located on the same upper-level route based on the bound device information; and a second identifier comparison module, which compares the device identifier in the broadcast device information with the device identifier in the previously received first binding result, and generates response information based on its own device information based on the consistency of the device identifiers, and sends the response information to the second bound device for device identifier comparison.

[0101] Specifically, the second identifier comparison module is used to, after sending the response information to the second binding device, compare the response information with the previously received second binding result, and determine that the corresponding other device is the first binding device based on the comparison result that the device identifiers are consistent, and stop broadcasting; based on the comparison result that the device identifiers are inconsistent, continue broadcasting device information, and repeat the above steps until the first binding device is determined.

[0102] In an optional embodiment, the device further includes: a port mapping relationship receiving module, which receives a port mapping relationship sent by a cloud platform before receiving broadcast device information broadcast by the second bound device. The port mapping relationship is sent by the second bound device using the cloud platform, and the port mapping relationship is obtained based on the port request result sent by the router to the second bound device. The port request result is returned by the router based on the port application request sent by the second bound device, and the port application request is generated by the second bound device based on the port application instruction sent by the cloud platform.

[0103] In another possible implementation, the device further includes: a second information receiving module, which receives device information of the first bound device sent by the second bound device using a cloud platform before sending a P2P hole punching request to the second bound device; a second identifier comparison module compares the device information of the first bound device with the previously received first binding result for device identifier comparison, and based on the consistency of the device identifiers, sends its own device information, i.e., the device information of the first bound device, to the second bound device for device identifier comparison; and the second bound device compares the device information of the first bound device with the second binding result for device identifier comparison.

[0104] In summary, this embodiment of the invention utilizes a pre-established P2P mapping relationship through a second control module to directly send control commands to the second bound device. This enables connection and control between devices through local P2P hole punching, avoiding the long communication distances required for cloud-based control, improving communication efficiency, reducing dependence on the cloud platform, and thus alleviating the load on the cloud platform. It also ensures normal operation even when the cloud platform is malfunctioning, broadening the application scenarios. Furthermore, by not relying on the internet, it reduces various problems and complaints caused by network issues.

[0105] Figure 6 A schematic diagram of a multi-device linkage device based on a home scenario is shown. The device includes a first binding device and a second binding device, wherein:

[0106] The first bound device receives and executes the trigger command;

[0107] The first bound device sends control commands to the second bound device based on the trigger command and the pre-established peer-to-peer (P2P) mapping relationship.

[0108] The second bound device receives and executes control commands.

[0109] In an optional embodiment, before the first binding device sends a control command to the second binding device based on a trigger command and utilizing a previously established peer-to-peer (P2P) mapping relationship, the process includes: the first binding device sending a P2P hole-punching request to the second binding device, the P2P hole-punching request being sent by the first binding device based on a first binding result previously received from the cloud platform; the second binding device receiving the P2P hole-punching request, establishing a P2P mapping relationship with the first binding device based on the P2P hole-punching request and the previously received second binding result, generating hole-punching status feedback information, and sending the hole-punching status feedback information to the first binding device; and the first binding device receiving the hole-punching status feedback information.

[0110] In an optional embodiment, before the first bound device sends a P2P hole punching request to the second bound device, the method further includes: the user terminal setting device binding information based on linkage requirements and sending the device binding information to the cloud platform, the device binding information including device information of at least two devices to be bound; the cloud platform determining, based on the device binding information, that the corresponding devices to be bound all have P2P functionality and support device linkage, binding the corresponding devices to be bound to obtain a first binding result and a second binding result, the first binding result including device information of the second bound device of the current executing entity, and the second binding result including device information of the first bound device; the cloud platform sending the first binding result to the first bound device and the second binding result to the second bound device.

[0111] In one possible implementation, after the cloud platform sends the first binding result to the first bound device and the second binding result to the second bound device, and before the second bound device receives the P2P hole punching request, the process includes: the cloud platform, based on the bound device information, determining that the second bound device and the first bound device are located on the same upstream route, and sending a broadcast command to the second bound device; the second bound device executes the broadcast command and broadcasts device information; other devices receive the broadcast device information, compare the device identifier in the broadcast device information with the device identifier in the previously received third binding result, and based on consistency, send their own first bound device's device information as response information to the second bound device; the second bound device receives the response information, compares the device identifier in the response information with the device identifier in the previously received second binding result, and based on consistency of device identifiers, stops broadcasting; based on inconsistency of device identifiers, continues broadcasting device information, and repeats the above steps until the first bound device is determined.

[0112] In one optional embodiment, after the cloud platform sends the first binding result to the first binding device and the second binding result to the second binding device, and before the second binding device receives the P2P hole punching request, the process includes: the cloud platform determining, based on the binding device information, that the second binding device and the first binding device are not located on the same upstream route, and sending a port request instruction to the second binding device; the second binding device sending a port request to the router based on the port request instruction; the router returning a port request result to the second binding device based on the port request request; the second binding device determining, based on the port request result, that the port request was successful, and sending the port mapping relationship in the port request result to the first binding device through the cloud platform; and the second binding device determining, based on the port request result, that the external mapped port has been occupied, then reselecting an external mapped port based on a preset selection rule, and generating a corresponding port request.

[0113] In another possible implementation, after the cloud platform sends the first binding result to the first bound device and the second binding result to the second bound device, and before the second bound device receives the P2P hole punching request, the method further includes: the second bound device sending device information to the first bound device using the cloud platform; the first bound device receiving the device information of the second bound device and comparing it with the previously received first binding result for device identification; if the device identifications match, the first bound device sending its own device information to the first bound device using the cloud platform; the first bound device receiving the binding information of the second bound device and comparing it with the previously received first binding result for device identification; and based on the matching device identifications, stopping the sending of its own device information using the cloud platform.

[0114] In summary, the first bound device in this embodiment of the invention sends control commands directly to the second bound device through a pre-established P2P mapping relationship. This enables connection and control between devices via local P2P hole punching, avoiding long communication distances in cloud control, improving communication efficiency, reducing dependence on the cloud platform, and thus alleviating the load on the cloud platform. It also ensures normal operation even when the cloud platform is abnormal, broadening the application scenarios. Furthermore, by not relying on the internet, it reduces various problems and complaints caused by network issues.

[0115] The terminal involved in the embodiments of this application may be a device that provides voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. The name of the terminal device may differ in different systems; for example, in a 5G system, the terminal device may be called a User Equipment (UE).

[0116] Figure 7This is a schematic diagram of the terminal structure according to an embodiment of this application, with reference to... Figure 7 This application embodiment also provides a terminal, which may include: a memory 710, a transceiver 720, and a processor 730;

[0117] The memory 710 is used to store computer programs; the transceiver 720 is used to send and receive data under the control of the processor 730; the processor 730 is used to read the computer program in the memory 710 and perform the following operations:

[0118] Receive control commands sent by the first bound device. The control commands are sent by the first bound device after receiving the trigger command, using the previously established point-to-point P2P mapping relationship.

[0119] Execute control commands.

[0120] Among them, Figure 7 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, such as one or more processors represented by processor 730 and memory represented by memory 710. The bus architecture can also link together various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 720 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. For different user equipment, the user interface 740 can also be an interface capable of connecting external or internal devices as needed.

[0121] The processor 730 is responsible for managing the bus architecture and general processing, while the memory 710 can store the data used by the processor 730 during operation.

[0122] The processor 730 executes any of the methods described in the embodiments of this application according to the obtained executable instructions by calling a computer program stored in the memory 710. The processor and the memory may also be physically separated.

[0123] Optionally, the processor 730 is also used to perform the following operations:

[0124] Before receiving the control command sent by the first bound device, the process includes: receiving a P2P hole punching request, wherein the P2P hole punching request is sent by the first bound device based on a previously received first binding result, wherein the first binding result is obtained and sent by the cloud platform based on device binding information sent by the user terminal, and the first binding result includes device information of the device that has been bound to the first bound device, wherein the device information includes the device identifier, control type, local IP address, and upstream routing address of the corresponding device; based on the P2P hole punching request, and in conjunction with the previously received second binding result, establishing a P2P mapping relationship with the first bound device, and generating hole punching status feedback information, wherein the second binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal, and the second binding result includes the device information of the first bound device; and sending the hole punching status feedback information to the first bound device.

[0125] The first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal and binding the corresponding device based on the device function determination; the device binding information includes device information of at least two devices to be bound; the device function determination is the cloud platform determining whether the devices to be bound all have P2P function and whether they all support device linkage based on the bound device information.

[0126] Before receiving the P2P hole punching request, the method further includes: receiving a broadcast instruction sent by the cloud platform, wherein the broadcast instruction is sent by the cloud platform after determining that the first bound device is located on the same upper-level route based on the bound device information; executing the broadcast instruction to broadcast device information; receiving response information returned by other devices based on the received broadcast device information, wherein the other devices include the first bound device or other unbound devices; comparing the device identifier in the response information with the device identifier in the previously received second binding result, and determining that the corresponding other device is the first bound device based on the consistency of the device identifier, and stopping the broadcast.

[0127] The response information is the device information of the other device, which is based on the received broadcast device information and the previously received third binding result, and is responded to after determining that the device identifiers are consistent. The third binding result is the device information of the device bound to the other device. The device identifier comparison is used to determine whether the device identifier in the broadcast device information is consistent with the device identifier in the third binding result.

[0128] Before receiving the broadcast instruction sent by the cloud platform, the process includes: receiving a port request instruction sent by the cloud platform, wherein the port request instruction is sent by the cloud platform after determining, based on the bound device information, that the first bound device is not located on the same upper-level route; based on the port request instruction, sending a port request request to the router, wherein the port request request is used to request an externally mapped port located on the same upper-level route as the first bound device; receiving a port request result returned by the router based on the port request request; based on the port request result, determining that the port request was successful, and sending the port mapping relationship in the port request result to the first bound device through the cloud platform.

[0129] Receiving the port request result returned by the router based on the port request request further includes: determining, based on the port request result, that the external mapped port has been occupied, then reselecting the external mapped port based on a preset selection rule, and generating a corresponding port request request.

[0130] Before receiving the P2P hole punching request, the method further includes: sending device information to the first bound device using the cloud platform; receiving device information of the first bound device returned by the first bound device using the cloud platform; comparing the device information of the first bound device returned by the first bound device using the cloud platform with the previously received second binding result to determine whether the device identifiers are consistent.

[0131] The device information of the first bound device returned by the cloud platform is sent by the first bound device after determining that the device identifier is consistent with the device information sent to the first bound device by the cloud platform and the previously received first binding result.

[0132] It should be noted that the terminal and network device provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.

[0133] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call a computer program in the memory 830 to execute steps of a multi-device linkage method based on a home scenario, such as:

[0134] Receive control commands sent by the first bound device, which are sent by the first bound device after receiving the trigger command, using the previously established peer-to-peer (P2P) mapping relationship; execute the control commands; or,

[0135] Receive and execute trigger commands; based on the trigger commands, use the pre-established peer-to-peer (P2P) mapping relationship to send control commands to the second bound device; or,

[0136] The first bound device receives and executes the trigger command; based on the trigger command, the first bound device sends a control command to the second bound device using the previously established point-to-point P2P mapping relationship; the second bound device receives and executes the control command.

[0137] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0138] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the multi-device linkage method based on a home scenario provided in the above embodiments, such as including:

[0139] Receive control commands sent by the first bound device, which are sent by the first bound device after receiving the trigger command, using the previously established peer-to-peer (P2P) mapping relationship; execute the control commands; or,

[0140] Receive and execute trigger commands; based on the trigger commands, use the pre-established peer-to-peer (P2P) mapping relationship to send control commands to the second bound device; or,

[0141] The first bound device receives and executes the trigger command; based on the trigger command, the first bound device sends a control command to the second bound device using the previously established point-to-point P2P mapping relationship; the second bound device receives and executes the control command.

[0142] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program, the computer program being used to cause a processor to execute the steps of the multi-device linkage method based on a home scenario provided in the above embodiments, for example including:

[0143] Receive control commands sent by the first bound device, which are sent by the first bound device after receiving the trigger command, using the previously established peer-to-peer (P2P) mapping relationship; execute the control commands; or,

[0144] Receive and execute trigger commands; based on the trigger commands, use the pre-established peer-to-peer (P2P) mapping relationship to send control commands to the second bound device; or,

[0145] The first bound device receives and executes the trigger command; based on the trigger command, the first bound device sends a control command to the second bound device using the previously established point-to-point P2P mapping relationship; the second bound device receives and executes the control command.

[0146] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0147] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0149] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for multi-device linkage in a home setting, characterized in that, include: Receive control commands sent by the first bound device, wherein the control commands are sent by the first bound device after receiving the trigger command, using the previously established point-to-point P2P mapping relationship; Execute the control command; Before receiving the control command sent by the first bound device, the procedure includes: Receive a P2P hole punching request. The P2P hole punching request is sent by the first binding device based on the first binding result received earlier. The first binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The first binding result includes device information of the device that has been bound to the first binding device. The device information includes the device identifier, control type, local IP address and upstream routing address of the corresponding device. Based on the P2P hole punching request, combined with the previously received second binding result, a P2P mapping relationship is established with the first bound device, and hole punching status feedback information is generated. The second binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The second binding result includes the device information of the first bound device. The drilling status feedback information is sent to the first bound device; The first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal, and binding the corresponding device based on the device function determination; The device binding information includes device information for at least two devices to be bound. The device function determination is based on the cloud platform's assessment of whether all devices to be bound have P2P functionality and whether they all support device linkage, according to the device binding information. Before receiving the P2P hole punching request, the following is also included: Receive a broadcast instruction sent by the cloud platform, the broadcast instruction being sent by the cloud platform after determining, based on the device binding information, that the device is located on the same upstream route as the first bound device; Execute the broadcast command to broadcast device information; Receive response information returned by other devices based on the received broadcast device information, wherein the other devices include the first bound device or other unbound devices; The device identifier in the response information is compared with the device identifier in the previously received second binding result. Based on the consistency of the device identifier, the corresponding other device is determined to be the first binding device, and the broadcast is stopped.

2. The multi-device linkage method based on a home scenario according to claim 1, characterized in that, Before receiving the P2P hole punching request, the following is also included: The cloud platform is used to send device information to the first bound device; Receive device information of the first bound device returned by the first bound device through the cloud platform; The device information of the first bound device returned by the cloud platform is compared with the device identifier of the second bound result received earlier to determine whether the device identifiers are consistent.

3. The multi-device linkage method based on a home scenario according to claim 2, characterized in that, The response information is the device information of the other device, which is based on the comparison of the device identifier of the received broadcast device information with the previously received third binding result, and the response is made after determining that the device identifiers are consistent. The third binding result is the device information of the device bound to the other device; The device identifier comparison is used to determine whether the device identifier in the broadcast device information is consistent with the device identifier in the third binding result; Before receiving the broadcast instruction sent by the cloud platform, the process includes: Receive a port request instruction sent by the cloud platform, wherein the port request instruction is sent by the cloud platform after determining, based on the device binding information, that the device is not located on the same upper-level route as the first bound device; Based on the port request instruction, a port request is sent to the router. The port request is used to request an externally mapped port from the router that is located on the same upper-level route as the first bound device. Receive the port request result returned by the router based on the port request request; Based on the port request result, it is determined that the port application was successful, and the port mapping relationship in the port request result is sent to the first bound device through the cloud platform.

4. The multi-device linkage method based on a home scenario according to claim 3, characterized in that, The step of receiving the port request result returned by the router based on the port request also includes: Based on the port request result, if it is determined that the external mapped port has been occupied, then based on the preset selection rules, a new external mapped port is selected, and a corresponding port application request is generated.

5. The multi-device linkage method based on a home scenario according to claim 2, characterized in that, The device information of the first bound device returned by the cloud platform is sent by the first bound device after determining that the device identifier is consistent with the device information sent to the first bound device by the cloud platform and the previously received first binding result.

6. A multi-device linkage device based on a home scenario, characterized in that, include: The instruction receiving module is used to: receive control instructions sent by the first bound device, wherein the control instructions are sent by the first bound device after receiving the trigger instruction, using the previously established point-to-point P2P mapping relationship; The instruction execution module is used to: execute the control instructions; The device further includes: Before receiving the control command sent by the first bound device, the P2P request receiving module receives a P2P hole punching request. The P2P hole punching request is sent by the first bound device based on the first bound result received earlier. The first bound result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The first bound result includes device information of the device that has been bound to the first bound device. The device information includes the device identifier, control type, local IP address and upstream routing address of the corresponding device. The P2P relationship establishment module establishes a P2P mapping relationship with the first bound device based on the P2P hole punching request and the previously received second binding result, and generates hole punching status feedback information. The second binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The second binding result includes the device information of the first bound device. The information feedback module sends the drilling status feedback information to the first bound device; The first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal, and binding the corresponding device based on the device function determination; The device binding information includes device information for at least two devices to be bound. The device function determination is based on the cloud platform's assessment of whether all devices to be bound have P2P functionality and whether they all support device linkage, according to the device binding information. The device further includes: The broadcast instruction receiving module receives a broadcast instruction sent by the cloud platform before receiving the P2P hole punching request. The broadcast instruction is sent by the cloud platform after determining that the device is located on the same upper-level route as the first bound device based on the device binding information. The broadcast instruction execution module executes the broadcast instruction and broadcasts device information; The response information receiving module receives response information returned by other devices based on the received broadcast device information, wherein the other devices include the first bound device or other unbound devices; The first identifier comparison module compares the device identifier in the response information with the device identifier in the previously received second binding result, and determines the corresponding other device as the first binding device based on the consistency of the device identifier, and stops broadcasting.

7. A terminal, characterized in that, Includes memory, transceiver, and processor; A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer programs from the memory and performing the following operations: Receive control commands sent by the first bound device, wherein the control commands are sent by the first bound device after receiving the trigger command, using the previously established point-to-point P2P mapping relationship; Execute the control command; Before receiving the control command sent by the first bound device, the procedure includes: Receive a P2P hole punching request. The P2P hole punching request is sent by the first binding device based on the first binding result received earlier. The first binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The first binding result includes device information of the device that has been bound to the first binding device. The device information includes the device identifier, control type, local IP address and upstream routing address of the corresponding device. Based on the P2P hole punching request, combined with the previously received second binding result, a P2P mapping relationship is established with the first bound device, and hole punching status feedback information is generated. The second binding result is obtained and sent by the cloud platform based on the device binding information sent by the user terminal. The second binding result includes the device information of the first bound device. The drilling status feedback information is sent to the first bound device; The first binding result and the second binding result are obtained by the cloud platform after determining the device function based on the device binding information sent by the user terminal, and binding the corresponding device based on the device function determination; The device binding information includes device information for at least two devices to be bound. The device function determination is based on the cloud platform's assessment of whether all devices to be bound have P2P functionality and whether they all support device linkage, according to the device binding information. Before receiving the P2P hole punching request, the following is also included: Receive a broadcast instruction sent by the cloud platform, the broadcast instruction being sent by the cloud platform after determining, based on the device binding information, that the device is located on the same upstream route as the first bound device; Execute the broadcast command to broadcast device information; Receive response information returned by other devices based on the received broadcast device information, wherein the other devices include the first bound device or other unbound devices; The device identifier in the response information is compared with the device identifier in the previously received second binding result. Based on the consistency of the device identifier, the corresponding other device is determined to be the first binding device, and the broadcast is stopped.

8. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the multi-device linkage method based on a home scenario as described in any one of claims 1 to 5.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it represents the steps of the multi-device linkage method based on a home scenario as described in any one of claims 1 to 5.

Images