Inter-device communication method, control device, target device, and communication system

Abstract

The application discloses an inter-device communication method applied to the technical field of short-distance wireless communication, and comprises the following steps: a first control device establishes and maintains a connection with at least one second control device through a first short-distance wireless communication module; control devices in the same logical control group are configured with the same group identifier; a control instruction carrying the group identifier is received and sent by the second control device; the control instruction is converted into a control packet carrying the group identifier which is transmitted through a second communication network; and the control packet is sent to a target device, so that the target device judges whether to execute the control instruction based on the group identifier. The application establishes a logical control group with the target device as the center, and transmits the group identifier across protocols, checks and executes the control instruction based on the group identifier on the target device side, realizes group-level control between multiple control devices and multiple target devices in the same physical space, and avoids control crosstalk.

Description

Technical Field

[0001] This application relates to the field of short-range wireless communication technology, and in particular to a device-to-device communication method, control device, target device, and communication system. Background Technology

[0002] Short-range wireless communication technology has been widely used in control equipment in scenarios such as conference rooms, multimedia classrooms, and family living rooms. With the increasing prevalence of smart devices, multiple controlled devices and multiple control devices often exist in the same physical space, leading to a continuously growing demand for multi-user collaborative control. How to achieve precise, low-power group-level control in environments with multiple devices coexisting has become an important development direction in this technological field.

[0003] Currently, common short-range wireless control solutions mainly include the following categories: Infrared remote control technology transmits control commands via infrared light signals, offering the advantage of low cost and being widely used in traditional home appliances. However, its signal transmission is highly directional and only supports one-way communication, meaning the remote control cannot determine whether the controlled device has received the control commands correctly. Point-to-point control technology based on the standard Bluetooth protocol, such as Bluetooth voice remote controls using HID profiles, enables two-way communication. However, its connection architecture typically only supports one-to-one device connections, making it difficult to meet the needs of scenarios where multiple control devices work simultaneously or coordinate control. Wireless control technology based on the 2.4GHz proprietary radio frequency protocol is commonly used in devices such as wireless mice, keyboards, and presentation turners. However, it usually requires a dedicated USB receiver, limiting its versatility and increasing deployment costs. While WiFi-based wireless control solutions support high data transmission rates and networked control, their high power consumption makes it difficult to balance battery life and ease of use for battery-powered portable control devices.

[0004] However, in scenarios where multiple control devices and multiple controlled devices coexist, existing short-range wireless control solutions struggle to achieve group-level permission division between devices. There is a significant conflict between the power consumption of WiFi solutions and the battery life requirements of battery-powered control devices; the point-to-point connection architecture of standard Bluetooth solutions is ill-suited to supporting scenarios where multiple control devices operate concurrently. These shortcomings severely limit the application of existing short-range wireless control solutions in multi-device collaborative control scenarios. Summary of the Invention

[0005] In order to at least solve the problems of group-level control being impossible and crosstalk between different control commands in scenarios where multiple control devices and multiple controlled devices coexist in the prior art, embodiments of the present invention provide a device communication method to solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems.

[0006] The device communication method provided in this embodiment of the invention is executed by a first control device. The method includes: establishing and maintaining a connection with at least one second control device through a first short-range wireless communication module, wherein control devices within the same logical control group are authorized to control the same target device, and control devices belonging to the same logical control group are configured with the same group identifier; receiving a control command from the second control device through the first short-range wireless communication module, the control command carrying the group identifier; converting the received control command into a control packet transmitted through a second communication network, the control packet carrying the group identifier; and sending the control packet to the target device through the second communication network, so that the target device determines whether to execute the control command based at least on the group identifier. By establishing a logical control group centered on the target device and configuring the same group identifier for control devices within the same logical control group, group-level division of control permissions is achieved; by transmitting the group identifier across protocols between the first short-range wireless communication and the second communication network, the second control device, which communicates only with the first control device through the first short-range wireless communication, can transfer its control permissions to the target device via the first control device.

[0007] Correspondingly, embodiments of the present invention also provide a device-to-device communication method executed by a second control device. The second control device sends a control command to a first control device via a first short-range wireless communication module. The control command carries a group identifier, wherein the group identifier identifies the logical control group to which the second control device belongs. Control devices within the same logical control group share the same group identifier and are authorized to control the same target device. The second control device receives an execution result returned by the first control device via the first short-range wireless communication module. The execution result is generated by the target device after verification based at least on the group identifier.

[0008] On the other hand, embodiments of the present invention also provide a device-to-device communication method executed by a target device. The target device receives a control packet from a first control device via a second communication network. The control packet is generated by the first control device based on control instructions received from a second control device via a first short-range wireless communication. The control packet carries a group identifier, which identifies the logical control group to which the second control device belongs. Control devices within the same logical control group are authorized to control the same target device. The target device obtains the group identifier carried in the control packet; compares the group identifier carried in the control packet with a group identifier configured in the target device; if the comparison result matches, the target device executes the control instruction; if the comparison result does not match, the target device refuses to execute the control instruction.

[0009] In a specific implementation, the group identifier can be sent from the configuration device to the first control device via the second communication network. The first control device persistently saves the received group identifier to a local non-volatile storage medium, and loads and uses the group identifier from the local non-volatile storage medium when restarting after a power outage or re-entering the network after going offline. Furthermore, when the control command received from the second control device does not carry the group identifier, the first control device can use its own currently configured group identifier as the group identifier of the control command to generate the control packet, thereby ensuring that the control command is correctly assigned even if the second control device fails to carry the group identifier due to abnormal reasons.

[0010] The connection between the first control device and the second control device is established by: detecting the signal strength of the broadcast signal from the second control device; and triggering a pairing connection process with the second control device when the signal strength meets a preset near-field condition, thereby achieving near-field pairing of the first control device without physical operation. Further, if the second control device fails to complete the pairing connection process within a preset pairing time window after entering the pairing mode, it automatically exits the pairing mode and stops sending pairing broadcasts; when the first control device simultaneously detects multiple second control devices that meet the preset near-field condition, it selects the second control device with the strongest signal strength as the pairing connection target to reduce the probability of mispairing.

[0011] Regarding connection maintenance, the first control device can establish a connection context for each connected second control device. The connection context includes at least one of the following: the address information of the second control device, connection handle, connection order, group identifier, recent activity time, and pending data queue. When multiple second control devices send control commands within a preset time window, the first control device sorts the control commands sent by the multiple second control devices according to the connection order recorded in the connection context. Furthermore, when the second control device is in standby mode, the first control device configures a first connection interval and a first slave delay parameter for it. When the second control device has control commands to send or is in an active reporting state, the slave delay parameter is set to zero, and a second connection interval smaller than the first connection interval is switched to. After the control command processing is completed or the second control device re-enters standby mode, the first connection interval and the first slave delay parameter are restored, thereby balancing the low power consumption characteristics and control response speed of the second control device.

[0012] In terms of security and isolation, different first control devices and their respective connected second control devices form mutually isolated independent control networks. The first control device only receives and processes control commands from the second control device it is bound to, and only sends the control packets to the target device located on the same second communication network. Based on this, after a network outage or power-on, the bound second control device sends a broadcast carrying the target device's address information, which is the address information of the first control device. If the first control device determines that the second control device exists in its locally stored list of bound devices, it proactively initiates a connection request to achieve targeted reconnection. Furthermore, after establishing a connection with a non-bound device, the second control device verifies at the link layer whether the non-bound device holds a valid pairing key. If the verification fails, it proactively disconnects from the non-bound device to prevent accidental connection to unauthorized control devices.

[0013] Regarding the feedback of execution results, the first control device receives the execution result of the control command returned by the target device through the second communication network, and feeds back the execution result to the second control device that sent the control command through the first short-range wireless communication module. The execution result may include at least one of the following: execution successful, execution failed, target device offline, permission mismatch, or timeout. Thus, after the user operates the second control device, they can know whether each operation was successful, overcoming the defect of traditional one-way remote control that cannot confirm the operation result.

[0014] Based on the above method, the first control device provided in this embodiment of the invention includes at least one processor; a first short-range wireless communication module for establishing and maintaining a connection with at least one second control device; a second communication network module for communicating with a target device; and a memory storing instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform the method on the first control device side. The second control device includes at least one processor, the first short-range wireless communication module, and the memory, the instructions stored in the memory enabling the processor to perform the method on the second control device side. The target device includes at least one processor, the second communication network module, and the memory, the instructions stored in the memory enabling the processor to perform the method on the target device side. Furthermore, the system composed of the first control device, the second control device, and the target device, as well as a computer-readable storage medium storing a computer program implementing the above method steps, are also components of the technical solution provided in this embodiment of the invention.

[0015] The above technical solution has the following advantages over existing technologies. By establishing a logical control group centered on the target device and uniformly assigning group identifiers to control devices within the same logical control group, the group identifier is transmitted along with the control command in the control link. Finally, the target device compares and verifies the received group identifier with its configured group identifier; if they match, the command is executed; otherwise, it is rejected. By having the target device verify the group identifier upon receiving the control packet, executing if they match and rejecting if they do not, control commands from different logical control groups do not interfere with each other, thus achieving group-level control of the controlled device.

[0016] By transmitting the group identifier across protocols between the first short-range wireless communication network and the second communication network, the second control device, which only possesses the first short-range wireless communication capability, can deliver control commands carrying the group identifier to the target device via protocol conversion by the first control device. This cross-protocol transmission mechanism allows the second control device to participate in the group-level access control system without directly accessing the second communication network or communicating directly with the controlled device, thereby allowing the second control device to maintain a low-power, lightweight hardware design.

[0017] By passively detecting signal strength and automatically triggering pairing when preset near-field conditions are met, the first control device can complete pairing and network access with only one operation, eliminating the need for any physical operation from the first control device. Compared to existing technologies that require simultaneous operation from both parties, this mechanism significantly simplifies the process of adding or replacing control devices in batches, making it particularly suitable for scenarios where control devices need to be frequently added or replaced.

[0018] By establishing a connection context for each connected second control device and sorting concurrent control commands according to the connection order within the connection context, the first control device can simultaneously maintain stable connections with multiple second control devices and process multiple inputs in an orderly manner, overcoming the limitations of traditional Bluetooth point-to-point connection architectures. Combining a long connection interval configuration in standby mode with a short connection interval switching during active reporting, the power consumption of the second control devices is effectively reduced while ensuring timely control response. Attached Figure Description

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

[0020] Figure 1A flowchart illustrating an embodiment of the device-to-device communication method of the present invention (applied to a first control device);

[0021] Figure 2 This is a flowchart of an embodiment of the device-to-device communication method of the present invention (applied to a second control device);

[0022] Figure 3 This is a flowchart of an embodiment of the inter-device communication method of the present invention (applied to a target device);

[0023] Figure 4 A schematic diagram of the structure of a first control device provided in an embodiment of the present invention;

[0024] Figure 5 A schematic diagram of the structure of a second control device provided in an embodiment of the present invention;

[0025] Figure 6 A schematic diagram of the structure of the target device provided in an embodiment of the present invention;

[0026] Figure 7 This is a schematic diagram of a communication system provided in an embodiment of the present invention. Detailed Implementation

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

[0028] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0029] This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, elements, data structures, etc., that perform a specific task or implement a specific abstract data type. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0030] In this invention, "module," "system," etc., refer to relevant entities applied to a computer, such as hardware, combinations of hardware and software, software, or software in execution. More specifically, for example, an element may be, but is not limited to, a process running on a processor, a processor, an object, an executable element, an execution thread, a program, and / or a computer. One or more elements may be in an executing process and / or thread, and elements may be localized on a single computer and / or distributed across two or more computers, and may be executable by various computer-readable media.

[0031] Finally, it should be noted that in this document, the terms "comprising" and "including" include not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0032] In this embodiment of the invention, unless otherwise explicitly stated, the term "first control device" refers to a control device that acts as a central node in a short-range wireless communication network, such as a master remote control, i.e., a BLE (Bluetooth Low Energy) central device, or a BLE gateway, or an intelligent central control device integrating short-range wireless communication and local area network communication capabilities. The term "second control device" refers to a control device that acts as a peripheral terminal in a short-range wireless communication network, such as a slave remote control, i.e., a BLE peripheral device, or a portable remote control or mobile control terminal. The term "group identifier" (i.e., Group ID) refers to the identifier of a logical control group established around the target device, used to define which control devices can control the corresponding target device, such as a 1-byte group number field (value range 0x00-0xFF), a string-formatted logical group name, or a group identifier code generated based on a hash algorithm. The term "target device" refers to the terminal device being controlled, such as a smart screen, television, central control system, microphone device, projector, or conference terminal device.

[0033] Please see Figure 1 ,like Figure 1 As shown, an embodiment of the present invention provides a device-to-device communication method, which is applied to a first control device and includes the following steps.

[0034] Step S110: Establish and maintain a connection with at least one second control device through the first short-range wireless communication module, wherein control devices within the same logical control group are authorized to control the same target device, and control devices belonging to the same logical control group are configured with the same group identifier.

[0035] Here, the first short-range wireless communication module refers to a communication module that supports low-power short-range wireless communication protocols, such as a Bluetooth Low Energy (BLE) communication module, a Zigbee communication module, or a Thread communication module. The first control device operates in a central node mode through the first short-range wireless communication module, scanning for broadcast messages from the second control device, and initiating a connection request when it discovers a second control device in a connectable state, thus completing the BLE connection establishment.

[0036] Specifically, control devices within the same logical control group are authorized to control the same target device, and control devices belonging to the same logical control group are configured with the same group identifier. The group identifier is sent from the configuration device to the first control device via a second communication network. The configuration device is, for example, a computer, mobile terminal, or cloud management platform running configuration tool software. The second communication network refers to a network different from the first short-range wireless communication network, such as a wired Ethernet LAN, a WiFi wireless LAN, or a LAN based on the TCP / IP protocol. The configuration device communicates with both the target device and the first control device via the second communication network, writing the same group identifier to both the target device and the first control device within the same logical control group.

[0037] More specifically, after receiving the group identifier, the first control device persistently saves the group identifier to a local non-volatile storage medium. The non-volatile storage medium is, for example, Flash memory, EEPROM memory (e.g., an AT24C02 series 2Kbit EEPROM), or ferroelectric memory (FRAM, e.g., an MB85RC256V series 32KB FRAM). After the first control device is powered off and restarted, goes offline for a short period, or re-enters the network, the first control device loads and uses the group identifier from the local non-volatile storage medium. The original group identifier is only overwritten or cleared when the configuration device reissues a new group identifier, or when the first control device performs a factory reset operation. In some embodiments, the group identifier can be a 1-byte field with a value range of 0x00-0xFF, thereby supporting up to 256 independent logical control groups coexisting in the same physical space.

[0038] Furthermore, the first control device establishes a connection context for each connected second control device. The connection context is a data structure stored in the RAM of the first control device. The connection context includes at least one of the following: the address information of the second control device (e.g., a 48-bit BLE MAC address or a device unique identifier (UUID)), the connection handle (e.g., a 16-bit connection identifier assigned by the link layer when the BLE connection is established), the connection order (e.g., an incrementing sequence number sorted by the first connection timestamp), the group identifier, the most recent activity time (e.g., a Unix timestamp or a FreeRTOS tick count), and a queue of pending data (e.g., a ring buffer or a singly linked list structure). When multiple second control devices send control commands within a preset time window, the first control device does not set priorities based on the type of control command, but instead sorts the control commands sent by the multiple second control devices according to the connection order recorded in the connection context. For multiple control commands consecutively sent by the same second control device, the first control device processes them sequentially according to the order in which the commands arrive within that second control device.

[0039] In this embodiment, the first control device maintains stable BLE connections with multiple second control devices simultaneously. Unlike the point-to-point one-to-one connection mode in the standard Bluetooth protocol, the first control device uses a time division multiplexing (TDM) mechanism at the BLE link layer to sequentially interact with each second control device in different connection event time slots. Specifically, each connection event begins at the current connection interval anchor time. The first control device, acting as the master, sends data packets on the agreed access address channel, and the second control device, acting as the slave, replies with data packets after a preset delay. The anchor times of different connection events do not overlap, so the first control device can schedule multiple connection events in turn to achieve data transmission and reception with multiple second control devices. After completing a BLE connection with the first second control device, the first control device continues to scan and accept connection requests from other second control devices in broadcast state, initiating BLE connections sequentially according to the order in which broadcast information is detected, until the maximum number of connections supported by the first control device is reached or the list of devices to be connected is empty. The maximum number of connections depends on the capabilities of the BLE SoC chip used by the first control device and the configuration of the physical layer and link layer parameters. For example, it can support 8 concurrent connections (such as nRF52840, which can stably support about 10-20 concurrent connections with a connection interval of 30ms, but we actually use 8 to ensure connection stability).

[0040] Regarding power consumption control, when the second control device is in standby mode, the first control device configures a first connection interval and a first slave latency parameter for it. The first connection interval is, for example, a preset value between 100 milliseconds and 500 milliseconds, and the first slave latency parameter is, for example, a latency of 0 to 9 connection intervals, allowing the second control device to not respond to master polling for multiple consecutive connection intervals, thereby extending the sleep time of the second control device. When the second control device actively reports, is triggered by a button, or has a control command to be sent, the first control device sets the slave latency parameter to zero and switches to the second connection interval, where the second connection interval is shorter than the first connection interval, for example, a preset value between 20 milliseconds and 50 milliseconds. The BLE connection interval is updated through a link layer connection parameter update request (LL_CONNECTION_PARAM_REQ) or a connection parameter update procedure. After the control command is processed or the second control device re-enters standby mode, the first control device restores the first connection interval and the first slave latency parameter.

[0041] Different first control devices and their respective connected second control devices form isolated independent control networks. The controlled device and the first control device must be within the same second communication network, exchanging data via the second communication network's protocol. The second control device does not directly access the second communication network, nor can it directly communicate with the controlled device. It can only send control commands to the bound first control device via a first short-range wireless communication, which then converts them into control packets for the second communication network and sends them to the controlled device. Therefore, controlled devices and first control devices in different second communication networks cannot communicate directly, and second control devices under different first control devices cannot bypass the first control device to directly control the controlled device. Within the same local area network, the controlled device further verifies whether the control packet belongs to its authorized control domain using a group identifier. Only when the group identifier matches will the controlled device execute the control command. Thus, even if other first control devices and their subordinate second control devices exist in adjacent physical spaces (e.g., two adjacent conference rooms), no signal crosstalk will occur.

[0042] Through the embodiments of this application, the first control device establishes and maintains concurrent BLE connections with multiple second control devices, overcoming the limitations of the traditional Bluetooth point-to-point connection architecture and realizing collaborative networking of multiple control devices. By combining long connection intervals and slave latency configurations in standby mode with short connection intervals during active reporting, the power consumption of the second control devices is effectively reduced while ensuring timely control response, enabling battery-powered portable second control devices to meet the battery life requirements of daily use scenarios.

[0043] Step S120: Receive a control command from the second control device via the first short-range wireless communication module, the control command carrying the group identifier.

[0044] Specifically, the second control device sends BLE data packets to the first control device via the first short-range wireless communication module. The BLE data packets encapsulate control commands. The data structure of the control commands includes a command type field and a group identifier field. The command type field identifies the type of control operation, such as volume adjustment (operation code 0x01), channel switching (operation code 0x02), power on / off (operation code 0x03), or device selection (operation code 0x04). The group identifier field identifies the logical control group to which the second control device sending the control command belongs.

[0045] More specifically, at the BLE protocol level, the second control device sends control commands to the first control device through the Notify operation of BLE GATT (Generic Attribute Profile). BLE GATT is based on a client-server architecture; in this embodiment, the second control device acts as the GATT server, and the first control device acts as the GATT client. The second control device defines a control instruction characteristic in the GATT server. This characteristic has a Notify attribute (PropertiID is a custom 128-bit UUID). The first control device needs to obtain the attribute handle of this characteristic in advance through the GATT discovery process and enable the CCCD (Client Characteristic Configuration Descriptor) of this characteristic to the GATT server to enable Notify notification. After enabling, the second control device reports the control instruction to the first control device through the GATT Notify operation (ATT_HANDLE_VALUE_NTF PDU). The attribute value of this characteristic is the payload of the control instruction, including a group identifier field (1 byte), an instruction type field (1 byte), and an optional instruction parameter field (variable length, 0 to N bytes).

[0046] In some embodiments, the group identifier may not be encapsulated within the attribute value of the GATT feature, but rather carried in the Manufacturer Specific Data (MSD) field of the BLE broadcast packet. In the AdvData field of the BLE broadcast message, the AD Structure with AD Type 0xFF is the Manufacturer Specific Data, where the first two bytes of the AD Data field are the Company ID, and the subsequent bytes are custom data. The second control device fills the group identifier value into this custom data segment. When the first control device scans the broadcast, it directly parses the group identifier from the broadcast data AD Structure, determining the group to which the second control device belongs without establishing a complete GATT connection. This is suitable for connectionless, rapid data reporting scenarios based on broadcast.

[0047] Furthermore, when the control command received from the second control device does not carry a group identifier, the first control device uses its own currently configured group identifier as the group identifier for the control command to generate subsequent control packets. This completion mechanism ensures that even if the second control device fails to carry the group identifier due to abnormal reasons such as firmware version differences, abnormal resets, or Flash storage corruption, the control command can still be correctly assigned to the corresponding logical control group, guaranteeing the robustness of the control link. That is, in this embodiment, the group identifier can be carried by the second control device, or if the second control device does not carry the group identifier, it can be obtained by the first control device through the configuration device or locally. Based on the established and maintained connection between the first and second control devices and the existing group identifier, the received control command is converted into a control command transmitted through the second communication network and sent to the target device.

[0048] Step S130: The received control command is converted into a control packet transmitted through the second communication network, the control packet carrying the group identifier.

[0049] This step is the core inventive step of this embodiment. The first control device acts as a protocol conversion gateway between the first short-range wireless communication network and the second communication network, converting control commands from the BLE domain into control packets from the second communication network domain.

[0050] Specifically, upon receiving a BLE GATT Notify request (ATT_HANDLE_VALUE_NTFPDU, with PDU opcode 0x1B), the first control device triggers an application callback function via the BLE protocol stack. Within this callback function, the application layer firmware of the first control device retrieves the control instruction payload byte array from the Attribute Value field of ATT_HANDLE_VALUE_NTF. The firmware parses this byte array according to a preset data format: byte 0 (offset 0) is the group identifier field, byte 1 (offset 1) is the instruction type field, and bytes 2 through N (offsets 2 through N) are the instruction parameter fields. The first control device maintains a currently valid group identifier mapping table. This table is a key-value pair structure, using the group identifier (e.g., a 1-byte integer from 0x00 to 0xFF) as the key and the corresponding target device's second communication network address as the value. The second communication network address is, for example, a tuple of the target device's IPv4 address and TCP port number. The group identifier mapping table is created or updated synchronously by the first control device when the configuration device issues group identifiers.

[0051] More specifically, the protocol conversion process from BLE to the second communication network includes the following sub-steps. First, the first control device performs field parsing and integrity verification on the BLE control command payload. The verification includes: whether the payload length meets the minimum length requirement (at least 2 bytes: group identifier + command type), whether the opcode in the command type field is within the preset valid opcode range, and whether the value of the group identifier field has a corresponding entry in the local group identifier mapping table. After successful verification, the first control device constructs the second communication network control packet. The second communication network control packet is an application layer data packet based on the TCP / IP protocol. Taking TCP as an example, the first control device constructs an application layer packet, which includes a header and a body. The message header contains the following fields: a 2-byte message header identifier (Magic Number, e.g., 0xBEEF, used for frame synchronization and protocol identification), a 1-byte protocol version number (e.g., 0x01), a 2-byte total message length (in bytes, network byte order), a 2-byte message sequence number (monotonically increasing, used for deduplication and request-response matching), and a 1-byte group identifier field. The message body contains the following fields: a 1-byte instruction type opcode, and a variable-length instruction parameter field (the content of which is consistent with the parameter fields in BLE control instructions or has undergone format normalization conversion).

[0052] After the message is constructed, the first control device obtains the socket file descriptor for the TCP connection with the target device. If the TCP connection has not yet been established or has been broken, the first control device first re-establishes the TCP connection with the target device through a TCP three-way handshake (SYN→SYN-ACK→ACK). Then, it sends the complete application layer message data to the TCP socket buffer through the send() function of the Socket API. The underlying TCP / IP protocol stack is responsible for data segmentation, sequence number management, acknowledgment retransmission, and congestion control.

[0053] Taking a specific scenario as an example, suppose the BLE control command issued by the second control device is "adjust the volume of microphone device-1 to 50%". This command is encapsulated in the Attribute Value field of the ATT_WRITE_REQ PDU, with the content: [0x01 (group identifier), 0x10 (volume adjustment opcode), 0x32 (hexadecimal representation of 50%)]. After the first control device's BLE protocol stack receives this PDU, it triggers an application layer callback. The callback function parses out the group identifier 0x01, opcode 0x10, and parameter 0x32. The first control device queries the group identifier mapping table for the target device information corresponding to group identifier 0x01. Suppose the target device IP is found to be 192.168.1.100 and the TCP port is 8080. The first control device constructs a TCP application layer message: the message header is [0xBE, 0xEF, 0x01, 0x00, 0x0B, 0x00, 0x01, 0x01], and the message body is [0x10, 0x32]. The first control device sends this message to 192.168.1.100:8080 through the established TCP connection.

[0054] In some embodiments, the second communication network control packet may not be based on the TCP / IP protocol, but may instead use UDP / IP-based datagrams, CAN bus (Controller Area Network)-based control frames, RS-485 serial bus-based Modbus RTU protocol frames, or communication frames based on a proprietary 2.4GHz radio frequency protocol. The second communication network module of the first control device is accordingly adapted to the communication interface hardware and protocol stack of the corresponding protocol.

[0055] Through the embodiments of this application, the group identifier, via the protocol conversion process of the first control device, crosses from the first short-range wireless communication domain (BLE GATT attribute value field) to the second communication network domain (TCP application layer header field), realizing the transmission of group-level permission information from the first short-range wireless communication domain to the second communication network domain. This cross-protocol transmission mechanism enables the second control device, which only has BLE communication capabilities, to transmit its logical control group information to the target device on the local area network side via the first control device without hardware upgrades (no need to add WiFi or Ethernet communication modules), thus decoupling control capabilities from hardware costs.

[0056] Step S140: The control packet is sent to the target device through the second communication network, so that the target device can determine whether to execute the control command based at least on the group identifier.

[0057] Specifically, the first control device calls the sending interface of the second communication network module to send the constructed control packet to the target device. Upon receiving the control packet, the target device first verifies the validity of the message header identifier (Magic Number) and protocol version number. Then, it extracts the group identifier field from the message header (e.g., the 7th byte of the message header) and compares the group identifier byte-by-byte with the group identifier stored in the target device's local non-volatile storage medium. If they match completely, the target device executes the device control operation corresponding to the instruction type opcode in the message body (e.g., calling the volume control interface of the audio digital signal processor (DSP) to set the output volume to a specified value), and constructs an execution result response message after the operation is completed, returning it to the first control device via the second communication network. If they do not match, the target device discards the control packet, does not execute any control operation, and optionally returns a response message with a permission mismatch status code.

[0058] Furthermore, after sending the control packet, the first control device blocks or asynchronously waits for the target device's execution result response within a preset timeout period. The preset timeout period is, for example, a value between 3 and 10 seconds (e.g., 5 seconds). If a response is received within the timeout period, the first control device feeds back the execution result to the second control device that sent the control command via a first short-range wireless communication module. The execution result includes at least one of the following: execution successful (status code 0x00), execution failed (status code 0x01), target device offline (status code 0x02, determined after TCP connection disconnection or multiple retransmission failures), permission mismatch (status code 0x03), or timeout (status code 0x04). The feedback mechanism involves the first control device invoking either the BLE GATT Write operation (ATT_WRITE_REQ PDU) or the Write Without Response operation (ATT_WRITE_CMD PDU) to write the execution result status code into the value attribute of the feedback characteristic defined in the GATT server of the second control device. Upon receiving this write request, the BLE protocol stack of the second control device triggers an application layer callback. This mechanism establishes a complete feedback chain, from the second control device sending BLE control commands, to the first control device's protocol conversion and forwarding to the target device, to the target device's execution and return of a response, and finally to the second control device receiving the execution result. This feedback mechanism allows the user to clearly know whether each operation was successful after operating the second control device, overcoming the shortcomings of traditional one-way control schemes such as infrared remote control that cannot perceive the operation result.

[0059] In this embodiment, a logical control group is established centered on the target device. Group identifiers are uniformly assigned to the first and second control devices within the same logical control group. These group identifiers are then transmitted across protocols between the BLE GATT domain and the TCP / IP LAN domain along with control commands. Finally, the target device performs permission verification and operation execution at the end of the control link based on the group identifier. This mechanism ensures that control commands from different logical control groups do not interfere with each other, achieving group-level control of the controlled devices.

[0060] In some embodiments of this application, when the first control device establishes a binding / pairing relationship with the second control device for the first time, a pairing triggering method based on near-field signal strength detection is adopted. The first control device only needs to passively detect during the entire process, without requiring any physical operation by the user.

[0061] A binding / pairing relationship can also be established by triggering the pairing button on either the first or second control device. Specifically, the second control device enters pairing mode after responding to a user's physical operation. This physical operation could be, for example, pressing and holding the pairing button on the second control device for a preset duration (e.g., 3 seconds). The microprocessor of the second control device detects the button press event via a GPIO external interrupt and starts a button press timer. When the timer reaches the 3-second threshold, the microprocessor switches the second control device's BLE protocol stack operating mode to pairing mode. In pairing mode, the second control device periodically sends non-directional connectable broadcast messages (ADV_IND, with PDU type code 0x00) through its first short-range wireless communication module. The AdvA field of the broadcast message PDU is the second control device's BLE MAC address (48 bits), and the AdvData field contains the following AD Structure: device name (AD Type 0x09, e.g., "Remote-01"), a list of UUIDs (AD Type 0x03, containing custom service UUIDs), and optional manufacturer-specific data.

[0062] When the first control device is not bound / paired, it continuously monitors three BLE broadcast channels (37, 38, and 39) via the BLE link layer scanning function of its first short-range wireless communication module, receiving broadcast messages from surrounding second control devices. The first control device obtains the following information for each broadcast message in the scan event callback of the BLE protocol stack: broadcast device address (AdvA), broadcast data (AdvData), and Received Signal Strength Indication (RSSI) value. The RSSI value, measured in dBm by the BLE RF transceiver during demodulation of the broadcast message, is stored in the scan report structure of the BLE protocol stack. The RSSI value satisfies the Free Space Path Loss (FSPL) relationship with the distance between the transmitting and receiving devices. Considering factors such as antenna mismatch, near-field effects, and obstruction in the actual environment, the measured RSSI value is typically about 10-20 dB lower than the theoretical FSPL calculation value. The first control device compares the read RSSI value with a preset near-field threshold. The preset near-field threshold is, for example, a preset value between -40 dBm and -30 dBm (e.g., -35 dBm), corresponding to a distance of approximately 5 to 10 centimeters between the antennas of the second control device and the first control device. When the RSSI value is greater than the preset near-field threshold (e.g., -28 dBm > -35 dBm), the first control device determines that the second control device is close enough to meet the preset near-field condition. Subsequently, the application layer firmware calls the connection initiation API of the BLE protocol stack (e.g., the sd_ble_gap_connect() function of nRF52840) to trigger the BLE connection establishment process with the second control device.

[0063] BLE connection establishment follows the standard link-layer connection establishment procedure. After detecting that the RSSI meets the near-field condition, the first control device sends a CONNECT_IND PDU within the nearest broadcast interval, containing connection parameters such as connection interval, slave delay, and connection timeout. After successful connection establishment, both parties enter the pairing process. The first control device sends a pairing request to the second control device, indicating that the Bonding Flags in its AuthReq field are set to Bonding, the IO Capability field is set to No Input No Output (neither party needs input / output capabilities), and the Man-in-the-Middle (MITM) protection field is set according to security requirements. Pairing uses LE Secure Connections, and both parties negotiate and generate an LTK (Long Term Key) through a key exchange algorithm. After pairing, the first control device stores the generated LTK, the other device's address, and the Identity Resolving Key (IRK) in a binding table on local non-volatile storage. The second control device also stores the LTK and the first control device's address information locally. When the two parties re-establish a BLE connection thereafter, they directly use the stored LTK to perform encrypted communication through the link layer encryption startup process, without the need for re-pairing.

[0064] Furthermore, the pairing mode of the second control device has a timeout mechanism. When the second control device enters pairing mode, it starts a pairing timeout count via a hardware timer in the microprocessor. The preset pairing time window is a value between 30 and 120 seconds (e.g., 60 seconds). If the BLE connection establishment or pairing process is not completed within the preset pairing time window, the pairing timeout timer triggers an interrupt. The microprocessor's interrupt service routine restores the BLE protocol stack of the second control device to non-pairing mode, stops sending pairing broadcasts (ADV_IND), and switches the second control device to a low-power sleep state. This timeout mechanism prevents the second control device from continuously sending broadcasts and consuming battery power due to prolonged periods without pairing.

[0065] When the first control device detects multiple second control devices that meet preset near-field conditions (RSSI values ​​all greater than a threshold) during the scanning phase, the first control device sorts and compares the RSSI values ​​of all candidate devices, selecting the second control device with the largest RSSI value (strongest signal) as the pairing and connection target. This RSSI optimization strategy is based on the physical principle that distance in free space decreases logarithmically with RSSI value; the device with the largest RSSI value is the closest to the first control device and is therefore most likely the device the user intends to pair with.

[0066] Taking a specific scenario as an example, in a multi-remote control deployment in a conference room, the administrator needs to bind 5 slave remote controls to the master remote control. The administrator takes out one slave remote control, presses and holds its pairing button for 3 seconds to enter pairing mode (the slave remote control's LED indicator flashes blue), and then brings the slave remote control within about 5 centimeters of the master remote control on the table. The master remote control's BLE scanning module continuously scans in the background and detects that the slave remote control's RSSI value is -28 dBm, exceeding the preset -35 dBm threshold, and then automatically triggers the pairing process. After successful pairing, the slave remote control's LED indicator flashes green once, and the slave remote control is added to the master remote control's list of bound devices. The administrator repeats the above operation for the remaining slave remote controls in turn. All 5 slave remote controls are batch-bound in about 2 minutes, and the administrator does not need to touch or operate the master remote control during the entire process.

[0067] Through the embodiments of this application, the unilateral physical operation on the second control device side, combined with the passive RSSI threshold detection and automatic pairing triggering mechanism of the first control device, enables a near-field pairing and network access method where the first control device requires no physical operation. Compared to the prior art, which requires both parties to perform physical operations simultaneously, the pairing process of this embodiment significantly simplifies the operational complexity of batch device network access.

[0068] Furthermore, the bound second control device can reconnect to the network after a disconnection via directional broadcast.

[0069] Specifically, the second control device, which has completed BLE security binding with the first control device, needs to re-establish the BLE encrypted connection with the first control device after a network outage (e.g., connection timeout due to moving out of the signal coverage area, power failure and restart of the first control device, or link loss due to 2.4GHz ISM band wireless interference) or power-on.

[0070] When the second control device is powered on and initialized, the application layer firmware first calls the read interface of the non-volatile storage medium to check whether a valid binding record exists in the Flash memory. The binding record is a structure that includes the address type of the first control device (Address Type, 0x00 for Public Device Address, 0x01 for Random StaticAddress), the address of the first control device (48 bits), LTK (128 bits), encryption key distribution information (EDIV, 2 bytes; Rand, 8 bytes), and the identity resolution key. If a binding record exists, the BLE protocol stack of the second control device is configured with directed broadcast parameters: the broadcast type is set to ADV_DIRECT_IND (PDU type code 0x01, directed connectable broadcast), and the InitA / AdvTargetA field (6 bytes) is filled with the device address of the first control device. ADV_DIRECT_IND is a high duty cycle broadcast mode; in the BLE specification, its broadcast interval is fixed at 3.75 milliseconds, and the maximum duration is 1.28 seconds, suitable for fast reconnection scenarios. ADV_DIRECT_IND is sent only on broadcast channels 37 and 38, unlike ADV_IND which is sent on all three channels. At the BLE link layer, only devices whose device addresses completely match the InitA / AdvTargetA fields (i.e., the corresponding first control device) can respond to this broadcast message and send a CONNECT_IND connection request. Other BLE devices with mismatched addresses discard the broadcast message at the link layer and cannot respond.

[0071] After the first control device powers on and the BLE protocol stack is initialized, the application layer firmware loads the list of bound devices from non-volatile storage media into the bound device list in RAM. The background BLE scanning parameters of the first control device are set as follows: scan interval, for example, 30 milliseconds; scan window, for example, 30 milliseconds (i.e., continuous scan with 100% duty cycle); and scan type, active scan. When the first control device scans an ADV_DIRECT_IND broadcast message, it obtains the broadcast device address (AdvA) and InitA / AdvTargetA (target address) from the scan report. The first control device first verifies whether the address in the InitA / AdvTargetA field matches its own address; if it matches, it further checks whether the device address in AdvA exists in the local list of bound devices; if it exists in the list, the application layer of the first control device calls the connection initiation API of the BLE protocol stack and sends a CONNECT_IND PDU. Both parties then use the stored LTK to directly establish an encrypted connection through the link layer encryption startup process, without user intervention.

[0072] If the second control device does not receive a CONNECT_IND from the first control device within 1.28 seconds after sending an ADV_DIRECT_IND broadcast, it switches to a low-duty-cycle directional broadcast mode and continues to send ADV_DIRECT_IND broadcasts to reduce power consumption and maintain a directional connection with the first control device. If no CONNECT_IND is received from the first control device after a preset waiting time (e.g., 1 minute), the second control device stops broadcasting, enters standby mode, and waits for device operation (e.g., button triggering or sensor event) before restarting the directional broadcast process to reduce power consumption and accommodate abnormal scenarios such as possible address changes in the first control device (e.g., using a Resolvable Private Address) or loss of binding records. If the second control device is captured and a connection is established by any scanning device during the ADV_IND transmission, the second control device will determine the identity and legitimacy of the connection object through LTK verification during the link layer encryption startup phase. If the other device (an unbound first control device) does not hold the correct LTK, the encryption startup process will return an error (such as error code 0x06 in LL_ENC_RSP - Pin or Key Missing). After detecting the encryption failure, the second control device will actively disconnect the erroneous connection through LL_TERMINATE_IND PDU (error code 0x05 - Authentication Failure), and then return to the directed broadcast mode to continue waiting for the correct response from the first control device.

[0073] Through the embodiments of this application, the directional broadcast reconnection mechanism enables the bound second control device to accurately locate and quickly reconnect to the unique corresponding first control device through the destination address matching mechanism of the BLE link layer. Combined with the link layer LTK verification anti-misconnection mechanism, even in a complex radio frequency environment with multiple unbound first control devices, it can ensure that the second control device only establishes an encrypted connection with the bound object, realizing secure automatic connection maintenance without manual intervention after pairing.

[0074] Please see Figure 2 ,like Figure 2 As shown, an embodiment of the present invention provides a device-to-device communication method, which is applied to a second control device and includes the following steps.

[0075] Step S210: Send a control command to the first control device through the first short-range wireless communication module. The control command carries a group identifier, wherein the group identifier is used to identify the logical control group to which the second control device belongs. Control devices within the same logical control group share the same group identifier and are authorized to control the same target device.

[0076] Specifically, when a user triggers a control operation, the second control device reads its currently configured group identifier from a non-volatile storage medium. This group identifier is sent to the second control device via a BLE GATT Write operation after the first control device completes pairing and binding with the second control device. The data format is as follows: the high byte of the GATT feature value represents the configuration command type (0xFE indicates group identifier configuration), and the low byte represents the group identifier value (0x00-0xFF). Upon receiving the GATT Write, the second control device persistently saves the group identifier value to the configuration data area in the embedded Flash memory. When sending control commands, the second control device constructs a control command payload data packet: the 0th byte is the group identifier field, the 1st byte is the command type field (opcode), and subsequent optional bytes are command parameter fields. After construction, the BLE GATT Write operation is called to write the payload into the corresponding control command feature value attribute and send it to the first control device.

[0077] In some embodiments, the second control device can cache the same type of control operations triggered by the user in a short period of time (e.g., pressing the volume + button 5 times in a row), and merge them into a single BLE GATT Write operation within a preset cache period (e.g., 50 milliseconds) for transmission (e.g., directly sending the target volume value instead of sending 5 "volume + 1" commands), so as to reduce the number of BLE wireless transmissions and receptions and the overhead of air packets, and further reduce power consumption.

[0078] Step S220: Receive the execution result returned by the first control device through the first short-range wireless communication module. The execution result is generated by the target device after verification based at least on the group identifier.

[0079] After sending the control command, the second control device maintains an active BLE connection and waits for the execution result from the first control device via the BLE GATT Notify mechanism. After forwarding the control command and receiving the response from the target device, the first control device calls the BLE GATT Handle Value Notification PDU to push the execution result status code to the second control device. Upon receiving this notification, the second control device's BLE protocol stack triggers an application layer callback, parses the execution result status code, and provides feedback to the user through the user interaction module based on the status code type. For example, if the status code is 0x00 (execution successful), the control GPIO output makes the green LED blink once; if the status code is 0x03 (permission mismatch), the control GPIO output makes the red LED blink three times; and if it is 0x04 (timeout), the control GPIO output makes the yellow LED stay on for 2 seconds.

[0080] Through the embodiments of this application, the second control device can not only send control commands, but also receive execution result feedback generated by the target device via relay from the first control device, forming a complete feedback process from command initiation to result confirmation.

[0081] Please see Figure 3 ,like Figure 3 As shown, an embodiment of the present invention provides a device-to-device communication method, which is applied to a target device and includes the following steps.

[0082] Step S310: Receive a control packet from the first control device via the second communication network. The control packet is generated by the first control device based on control commands received from the second control device via a first short-range wireless communication. The control packet carries a group identifier, which identifies the logical control group to which the second control device belongs. Control devices within the same logical control group are authorized to control the same target device.

[0083] Specifically, the target device listens for TCP connections and control packets from the first control device on a designated TCP port via the Socket API of its second communication network module. The target device maintains a list of registered first control devices and only accepts TCP connections or UDP datagrams initiated by first control devices with IP addresses on the list to prevent unauthorized control sources.

[0084] Step S320: Obtain the group identifier carried in the control packet.

[0085] After receiving the complete application layer message, the target device parses it according to the message format agreed upon with the first control device. First, it verifies the message header identifier (the first 2 bytes, Magic Number 0xBEEF). If the verification passes, it compares the protocol version number (the 3rd byte). If the protocol versions are compatible, it extracts the group identifier field value from the 7th byte (offset 6) of the message header. If the message header verification fails or the protocol versions are incompatible, the target device discards the control packet and records an exception in the log.

[0086] Step S330: Compare the group identifier carried in the control package with the group identifier configured in the target device.

[0087] The target device reads the currently configured group identifier from the configuration parameter area of ​​its local non-volatile storage medium. This group identifier value is issued and persistently stored by the configuration device during system deployment. The target device performs a byte-by-byte comparison (memcmp) between the group identifier value extracted in step S420 and the locally configured group identifier value.

[0088] Step S340: If the comparison results are consistent, execute the control command; if the comparison results are inconsistent, refuse to execute the control command.

[0089] If the group identifiers match, the target device parses the instruction type opcode and instruction parameters from the message body and calls the corresponding local device control hardware abstraction layer interface to execute the control operation. For example, if the opcode is 0x10 (volume adjustment) and the parameter is 0x32 (50%), the target device calls the I2C control interface of the audio codec (such as ES8388) to set the DAC's volume register to the corresponding value. After execution, the target device constructs an acknowledgment message and sends it to the first control device. If the group identifiers do not match, the target device discards the control packet, does not execute the control instruction, returns a permission mismatch status code (0x03) to the first control device, and optionally records the abnormal event (including source IP, timestamp, and group identifier value) in the local log for administrator security auditing.

[0090] In this embodiment, the target device performs group identifier verification at the end of the control link, whereby the controlled object verifies the group identifier in the control packet. Control commands are only executed if the group identifiers match, ensuring that control commands from different logical control groups do not cause cross-group control crosstalk when multiple target devices exist within the same local area network.

[0091] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a first control device provided according to an embodiment of the present invention. Figure 4 As shown, the first control device 400 may include the following modules:

[0092] A first short-range wireless communication module 410 is used to establish and maintain a connection with at least one second control device, and to receive control commands from the second control device, the control commands carrying a group identifier. The first short-range wireless communication module 410 is, for example, a BLE communication module implemented based on a BLE SoC chip such as Nordic nRF52840 (ARM Cortex-M4F core, built-in 2.4GHz RF transceiver, supporting BLE 5.0 protocol stack (which can be upgraded to be compatible with some BLE 5.x features)), TI CC2542R (ARM Cortex-M4F core, built-in Sensor Controller engine), or Telink TLSR8258 (RISC-V core, built-in Flash and 2.4GHz RF).

[0093] Protocol conversion module 420 is used to convert received control commands into control packets transmitted through a second communication network, wherein the control packets carry group identifiers. Protocol conversion module 420 performs BLE GATT feature value parsing, group identifier mapping table lookup, and second communication network application layer message construction. Protocol conversion module 420 is implemented by an embedded firmware program running on the microprocessor of the first control device.

[0094] The second communication network module 430 is used to send control packets to the target device and receive execution results returned by the target device through the second communication network. The second communication network module 430 may be, for example, a WiFi communication module based on the Espressif ESP32-S3 module (with built-in WiFi 4 protocol stack and TCP / IP protocol stack), a wired Ethernet module based on the WIZnet W5500 Ethernet control chip (with built-in hardware TCP / IP protocol stack, supporting 8 independent sockets), or a WiFi / Bluetooth dual-mode communication module based on the Realtek RTL8620DN.

[0095] The connection management module 440 is used to establish a connection context for each connected second control device and sort concurrent control commands according to the connection order in the connection context.

[0096] The group identifier management module 450 is used to receive and persistently save the group identifier issued by the configuration device, and to issue the group identifier to the bound second control device via BLE GATT.

[0097] The pairing control module 460 is used to trigger a pairing connection when the broadcast RSSI value is detected to meet the preset near-field conditions, and to select the device with the largest RSSI value from multiple candidate devices as the pairing object.

[0098] The first control device 400 described above can be used to execute the corresponding method steps applied to the first device in the above embodiments, and achieve the technical effects achieved by the above method embodiments accordingly, which will not be elaborated here.

[0099] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a second control device provided according to an embodiment of the present invention. Figure 5 As shown, the second control device 500 may include the following modules:

[0100] The first short-range wireless communication module 510 is used to send control commands to the first control device and receive execution results. The first short-range wireless communication module 510 is, for example, a BLE communication module implemented based on an ultra-low power BLE SoC chip such as Nordic nRF52810 (ARM Cortex-M4 core, 192KB Flash, 24KB RAM), Dialog DA14531 (ARM Cortex-M0+ core, 48KB RAM), or INPLAYIN100 (RISC-V core).

[0101] The group identifier storage module 520 is used to persistently save the group identifier received from the first control device to a non-volatile storage medium and to be read by the control instruction construction process.

[0102] The user interaction module 530 is used to receive physical operation input from the user and to provide feedback on the execution results through LEDs, vibrations, and other means.

[0103] The power management module 540 is used to manage battery power and standby / sleep modes.

[0104] The second control device 500 described above can be used to execute the corresponding method steps applied to the second device in the above embodiments.

[0105] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a target device provided according to an embodiment of the present invention. For example... Figure 6 As shown, the target device 600 may include the following modules:

[0106] The second communication network module 610 is used to receive control packets from the first control device.

[0107] The group identifier verification module 620 is used to extract the group identifier from the control package and compare it with the group identifier configured in this device.

[0108] The instruction execution module 630 is used to execute control instructions when the group identifiers match, and refuse to execute and return a response when they do not match.

[0109] The target device 600 described above can be used to execute the corresponding method steps applied to the target device in the above embodiments.

[0110] Please see Figure 7 , Figure 7 This is a schematic diagram of a communication system provided in an embodiment of the present invention.

[0111] like Figure 7As shown, the system includes at least one second control device 500, at least one first control device 400, and at least one target device 600. The first control device 400 establishes and maintains a connection with the second control device 500 via a first short-range wireless communication, receives control commands carrying a group identifier sent by the second control device 500, converts the control commands into control packets carrying the group identifier transmitted via a second communication network, and sends them to the target device 600. The target device 600 receives the control packets and determines whether to execute the control commands based on group identifier verification. Furthermore, the figure shows multiple target devices, each bound to a different first control device (master remote control), and each can only be controlled by its own first control device. In this scenario, there are two connection methods:

[0112] 1. Target device 1 and target device 2 are connected to the same first control device 1 (master remote controller). By setting configuration parameters (such as setting bindsn to 1 and 2 respectively) for different second control devices (slave remote controllers), different control permissions are achieved, realizing the networking of different target devices with the second device based on the same first control device.

[0113] 2. Target device 1 and target device 2 are respectively connected to different first control devices 1 and first control devices 2. Then, the same parameters are configured for different second control devices. The same configuration parameters are sent to the different first control devices connected to them through the different second control devices, so as to realize the networking of the same target device with different first control devices and second devices.

[0114] The system of this application establishes a logical control group centered on the target device and uniformly assigns a group identifier to the control devices within the same logical control group. This group identifier is transmitted along the control link with the control commands. Finally, the target device compares and verifies the received group identifier with its configured group identifier; if they match, the command is executed; otherwise, it is rejected. By verifying the group identifier when receiving control packets, the target device executes the command if they match and rejects it if they do not, ensuring that control commands from different logical control groups do not interfere with each other, thus achieving group-level control of the controlled device. This cross-protocol transmission mechanism allows the second control device to participate in the group-level access control system without directly accessing a second communication network or communicating directly with the controlled device, thereby allowing the second control device to maintain a low-power, lightweight hardware design.

[0115] This invention also provides an electronic device comprising: at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the method described in any of the above method embodiments.

[0116] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the above method embodiments. The computer-readable storage medium is, for example, ROM, RAM, magnetic disk storage medium, optical disk storage medium, Flash memory card, or solid-state drive.

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

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, 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.

[0119] 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 device-to-device communication method, executed by a first control device, characterized in that, include: A connection is established and maintained with at least one second control device via a first short-range wireless communication module, wherein control devices within the same logical control group are authorized to control the same target device, and control devices belonging to the same logical control group are configured with the same group identifier. The first short-range wireless communication module receives control commands from the second control device, the control commands carrying the group identifier; The received control command is converted into a control packet transmitted through a second communication network, the control packet carrying the group identifier; The control packet is sent to the target device via the second communication network, so that the target device can determine whether to execute the control command based at least on the group identifier.

2. The method according to claim 1, characterized in that, The group identifier is sent from the configuration device to the first control device via the second communication network.

3. The method according to claim 2, characterized in that, The first control device persistently saves the received group identifier to a local non-volatile storage medium, and loads and uses the group identifier from the local non-volatile storage medium when the first control device is powered off and restarted or reconnected to the network after being offline.

4. The method according to claim 1, characterized in that, When the control command received from the second control device does not carry the group identifier, the first control device uses its own currently configured group identifier as the group identifier of the control command to generate the control package.

5. The method according to claim 1, characterized in that, The establishment of a connection with at least one second control device includes: Detect the signal strength of the broadcast signal from the second control device; When the signal strength meets the preset near-field conditions, the pairing connection process with the second control device is triggered.

6. The method according to claim 1, characterized in that, Different first control devices and their respective connected second control devices form mutually isolated independent control networks, wherein the first control device only receives and processes control commands from the second control device bound to it, and the first control device only sends the control packets to the target device that is in the same second communication network as it.

7. The method according to claim 1, characterized in that, The establishment and maintenance of a connection with at least one second control device further includes: Receive a broadcast message carrying target address information sent by a bound second control device; wherein the target address information is the address information of the first control device; if it is determined that the second control device exists in the locally stored list of bound devices, actively initiate a connection request.

8. The method according to claim 1, characterized in that, Also includes: The second communication network is used to receive the execution result of the control command returned by the target device. The execution result is fed back to the second control device that sent the control command via the first short-range wireless communication module; The execution result includes at least one of the following: execution successful, execution failed, target device offline, permission mismatch, or timeout.

9. A method for inter-device communication, executed by a second control device, characterized in that, include: The first short-range wireless communication module sends a control command to the first control device. The control command carries a group identifier, wherein the group identifier is used to identify the logical control group to which the second control device belongs. Control devices within the same logical control group share the same group identifier and are authorized to control the same target device. The first short-range wireless communication module receives the execution result returned by the first control device, and the execution result is generated by the target device after verification based at least on the group identifier.

10. A device-to-device communication method, executed by a target device, characterized in that, include: The control packet is received from the first control device via the second communication network. The control packet is generated by the first control device based on the control command received from the second control device via the first short-range wireless communication. The control packet carries a group identifier, which is used to identify the logical control group to which the second control device belongs. Control devices within the same logical control group are authorized to control the same target device. Obtain the group identifier carried in the control packet; The group identifier carried in the control package is compared with the group identifier configured in this target device; If the comparison results are consistent, execute the control command; if the comparison results are inconsistent, refuse to execute the control command.

11. The method according to any one of claims 1, 9, or 10, characterized in that, The group identifier is the identifier of a logical control group established with the target device as the center. The control devices in the logical control group include at least one of the following: one or more of the first control devices and one or more of the second control devices. All control devices in the same logical control group are configured with the same group identifier, and control devices in different logical control groups are configured with different group identifiers.

12. A first control device, characterized in that, include: At least one processor; A first short-range wireless communication module is used to establish and maintain a connection with at least one second control device; The second communication network module is used to communicate with the target device; A memory, communicatively connected to the at least one processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1-8.

13. A second control device, characterized in that, include: At least one processor; A first short-range wireless communication module is used to establish and maintain a connection with a first control device; A memory, communicatively connected to the at least one processor, stores instructions executable by the at least one processor to enable the at least one processor to perform the steps of the method of claim 9.

14. A target device, characterized in that, include: At least one processor; The second communication network module is used to communicate with the first control device; A memory, communicatively connected to the at least one processor, stores instructions executable by the at least one processor to enable the at least one processor to perform the steps of the method of claim 10.

15. A communication system, characterized in that, include: At least one second control device as described in claim 13; At least one first control device as described in claim 12 is configured to establish and maintain a connection with the second control device via a first short-range wireless communication module, receive a control command carrying a group identifier sent by the second control device, convert the control command into a control packet carrying the group identifier transmitted via a second communication network, and send the control packet to a target device; At least one target device as described in claim 14 is configured to receive the control packet via the second communication network, obtain the group identifier carried in the control packet, compare the group identifier with a group identifier configured in the device, execute the control command if they match, and refuse to execute if they do not match.

Images