A cross-protocol device inter-control method and device, equipment and medium

Abstract

The application discloses a cross-protocol device interaction control method and device, equipment and a medium, which first establishes a first mapping relationship between a first protocol layer and a standard protocol layer, the first mapping relationship being associated with a first protocol address, a standard device identifier and a driving source identifier; then a second mapping relationship between the standard protocol layer and a second protocol layer is established, the second mapping relationship recording a second protocol address corresponding to each standard protocol device and being sent to an interactive control device driven by the second protocol. After receiving a cross-protocol control instruction containing a target second protocol address sent by the interactive control device, the target standard device identifier is determined according to the target second protocol address by querying the second mapping relationship, the target driving source identifier and the target first protocol address are acquired by querying the first mapping relationship based on the identifier, and the instruction is routed to the first protocol layer according to the driving source identifier, and the target first protocol device corresponding to the target first protocol address is driven to execute the instruction according to the target first protocol address.

Description

Technical Field

[0001] This application relates to the field of equipment control technology, and in particular to a method, apparatus, device and medium for cross-protocol device mutual control. Background Technology

[0002] In the fields of IoT and intelligent control, the diversification of device communication protocols has become the norm. Devices from different manufacturers and of different types often employ their own independent technical standards, resulting in barriers between protocols in terms of addressing methods, data formats, and control logic. This fragmented protocol ecosystem prevents heterogeneous devices from communicating directly, forcing system integration to rely on cumbersome customized development, which not only increases deployment costs but also limits the flexibility of system expansion.

[0003] Currently, to achieve interoperability between devices using different protocols, a cloud-based protocol conversion solution is commonly used. This solution uploads device data to a remote server for parsing and command relay, thereby enabling indirect communication. However, in this mode, data is transmitted via the public network, which is limited by network bandwidth fluctuations and link stability, making it difficult to meet the response requirements of high real-time scenarios such as industrial automation. At the same time, the system operation relies excessively on the external network; once the link is interrupted, the cloud cannot complete the protocol conversion, and the linkage control between local devices will be paralyzed, resulting in a serious lack of system robustness and local autonomy. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for cross-protocol device inter-control, which establishes a three-layer mapping of a first protocol layer, a standard protocol layer, and a second protocol layer. Cross-protocol association is achieved through the standard device identifier and the driver source identifier. Control commands are sent to the target first protocol driver based on the target second protocol address. The control commands are transmitted locally on the gateway, reducing cloud dependence and network latency, and realizing precise cross-protocol device inter-control. It can still operate in a network off-grid environment.

[0005] In a first aspect, embodiments of this application provide a cross-protocol device interoperability method, applied to a gateway device, the method comprising: A first mapping relationship is established between a first protocol layer and a standard protocol layer, wherein the first protocol layer includes at least one first protocol device driven by a first protocol, the first protocol device having a first protocol address, and the standard protocol layer includes a standard protocol device virtualized by each of the first protocol devices, the standard protocol device having a standard device identifier and a driver source identifier, the standard device identifier being used to identify the standard protocol device, and the driver source identifier being used to identify the first protocol to which the standard protocol device belongs; A second mapping relationship is established between the standard protocol layer and the second protocol layer, and the second mapping relationship is sent to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The system receives a cross-protocol control command sent by the interactive control device, the cross-protocol control command including a target second protocol address; it queries the second mapping relationship based on the target second protocol address to determine the corresponding target standard device identifier, queries the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address, and routes the cross-protocol control command to the first protocol layer according to the target driver source identifier, so that the target first protocol drives the corresponding target first protocol device to execute the command according to the target first protocol address.

[0006] Furthermore, establishing the first mapping relationship between the first protocol layer and the standard protocol layer includes: Scan the first protocol device running under the first protocol layer and driven by the first protocol to obtain the first protocol address and protocol feature information corresponding to the first protocol device; The standard device identifier corresponding to the first protocol device is generated based on the protocol feature information, and the corresponding driver source identifier is generated based on the protocol type of the first protocol; The first protocol address, the standard device identifier, and the driver source identifier are associated and bound to form the first mapping relationship, and the first mapping relationship is synchronously stored in the standard protocol layer.

[0007] Further, generating the standard device identifier corresponding to the first protocol device based on the protocol feature information includes: Extract the device type code, device serial number, and loop identifier from the protocol feature information; The standard device identifier is generated by performing calculations on the device type code, the device serial number, and the loop identifier according to a preset hash algorithm. The driver source identifier is generated based on the protocol type code of the first protocol.

[0008] Furthermore, establishing the second mapping relationship between the standard protocol layer and the second protocol layer includes: Extract the standard device identifier and device control attributes corresponding to each standard protocol device from the standard protocol layer; Assign a second protocol address to each of the standard protocol devices according to the device control attributes, and generate the second mapping relationship; The second mapping relationship is configured to the interactive control device of the second protocol layer so that the interactive control device can issue the cross-protocol control command based on the second protocol address.

[0009] Further, the step of assigning a second protocol address to each of the standard protocol devices according to the device control attributes and generating the second mapping relationship includes: Parse the device control attributes to obtain the corresponding device function type and control priority parameters; The device function type is divided into corresponding second protocol address ranges, and the control priority parameter is used to match the second protocol address value within the corresponding second protocol address range. The determined second protocol address value is associated and bound with the corresponding standard device identifier to generate the second mapping relationship.

[0010] Further, the step of determining the corresponding target standard device identifier by querying the second mapping relationship based on the target second protocol address, querying the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address, and routing the cross-protocol control command to the first protocol layer according to the target driver source identifier includes: Parse the cross-protocol control instructions to obtain the target second protocol address; Query the second mapping relationship, and obtain the corresponding target standard device identifier by matching the target second protocol address; Based on the target standard device identifier, query the first mapping relationship and synchronously match to obtain the corresponding target driver source identifier and the target first protocol address; Based on the target driver source identifier, the type of the target first protocol is determined, the cross-protocol control instruction is encapsulated into the instruction format of the target first protocol, and routed to the first protocol layer.

[0011] Further, the step of the target first protocol driving the corresponding target first protocol device to execute instructions according to the target first protocol address includes: The validity of the target first protocol address corresponding to the cross-protocol control instruction is verified based on the first mapping relationship; The target first protocol address that has been verified is used to locate the target first protocol device in the first protocol layer, and the target first protocol drives the target first protocol device to execute instructions.

[0012] In a second aspect, embodiments of this application provide a cross-protocol device interoperability device, comprising: The first mapping establishment module is used to establish a first mapping relationship between a first protocol layer and a standard protocol layer. The first protocol layer includes at least one first protocol device driven by a first protocol, and the first protocol device has a first protocol address. The standard protocol layer includes a standard protocol device virtualized by each of the first protocol devices. The standard protocol device has a standard device identifier and a driver source identifier. The standard device identifier is used to identify the standard protocol device, and the driver source identifier is used to identify the first protocol to which the standard protocol device belongs. The second mapping establishment module is used to establish a second mapping relationship between the standard protocol layer and the second protocol layer, and send the second mapping relationship to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The instruction processing module is configured to receive cross-protocol control instructions sent by the interactive control device, the cross-protocol control instructions including a target second protocol address; query the second mapping relationship based on the target second protocol address to determine the corresponding target standard device identifier; query the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address; and route the cross-protocol control instructions to the first protocol layer according to the target driver source identifier, so that the target first protocol drives the corresponding target first protocol device to execute the instructions according to the target first protocol address.

[0013] In a third aspect, embodiments of this application provide an electronic device, including: a memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-protocol device interoperability method as described in the first aspect.

[0014] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform the cross-protocol device interoperability method as described in the first aspect.

[0015] This application's embodiments construct a three-layer mapping architecture consisting of a first protocol layer, a standard protocol layer, and a second protocol layer. It establishes associations between heterogeneous devices using standard device identifiers and driver source identifiers, enabling cross-protocol control commands to be directly issued locally at the gateway via a routing path of the target second protocol address, standard device identifier, and driver source identifier, without requiring cloud uploads for protocol conversion. Since command transmission is processed entirely within the local gateway, network latency and jitter caused by public network transmission are eliminated, achieving precise inter-protocol device control. Simultaneously, the system no longer relies on external network connections; even in a network-off environment, it can maintain local autonomous operation based on a locally stored mapping table, solving the problems of poor real-time performance and high single-point-of-failure risk inherent in traditional cloud solutions. Attached Figure Description

[0016] Figure 1 This is a flowchart of a cross-protocol device interoperability method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the establishment of the first mapping relationship provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the generation of the standard device identifier provided in the embodiments of this application; Figure 4 This is a flowchart illustrating the establishment of the second mapping relationship provided in the embodiments of this application; Figure 5 This is a flowchart of the second protocol address allocation provided in the embodiments of this application; Figure 6 This is a flowchart of cross-protocol control command routing provided in an embodiment of this application; Figure 7 This is a flowchart of the target first protocol device positioning and instruction execution provided in the embodiments of this application; Figure 8 This is a structural diagram of a cross-protocol device interoperability device provided in an embodiment of this application; Figure 9 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] The cross-protocol device interoperability method, apparatus, device and medium provided in the embodiments of this application are applicable to the interconnection and interoperability scenarios of devices with heterogeneous communication protocols in the field of Internet of Things and intelligent control. They can solve the technical problems of existing cloud-based protocol conversion schemes, such as large network latency, poor real-time performance, failure due to network outage, high deployment cost and limited system scalability. This method constructs a three-layer mapping architecture—a first protocol layer, a standard protocol layer, and a second protocol layer—locally on the gateway device. The gateway device scans the first protocol devices under the first protocol layer and establishes a first mapping relationship, associating the first protocol address, standard device identifier, and driver source identifier. Simultaneously, based on the device control attributes of the standard protocol layer, a second mapping relationship is established, associating the standard device identifier and the second protocol address, and then sent to the interactive control device of the second protocol layer. When the interactive control device sends a cross-protocol control command containing the target second protocol address, the gateway device sequentially queries the second and first mapping relationships locally, reverse-parses out the target driver source identifier and the target first protocol address, encapsulates the command into the command format of the target first protocol, and routes it to the first protocol layer. The target first protocol drives the corresponding target first protocol device to execute the command, realizing local processing and routing of cross-protocol control commands. This method can be applied to heterogeneous protocol interoperability devices such as smart home gateways, building automation controllers, and industrial protocol conversion gateways. The aforementioned application scenarios are only illustrative examples, and in actual deployment, they can cover all multi-protocol converged device interconnection scenarios. This application embodiment does not limit these scenarios.

[0020] The cross-protocol device inter-control method provided in this application embodiment is executed by a gateway device. The gateway device refers to an edge computing device with first protocol adaptation capability, second protocol adaptation capability, multi-layer mapping relationship management capability, protocol frame encapsulation and conversion capability, and local routing and forwarding capability, including smart home central gateway, building automation protocol converter, industrial field protocol gateway, etc. The interactive control device refers to a control terminal driven by the second protocol, with a human-machine interface or upper-layer system interface, and capable of generating and issuing cross-protocol control commands, including smart panels, mobile terminal applications, host computer monitoring software, etc. This application embodiment does not limit this.

[0021] Figure 1 This is a flowchart of a cross-protocol device interoperability method provided in an embodiment of this application, such as... Figure 1 As shown, the cross-protocol device interoperability method includes the following steps: Step 101: Establish a first mapping relationship between the first protocol layer and the standard protocol layer. The first protocol layer includes at least one first protocol device driven by the first protocol. The first protocol device has a first protocol address. The standard protocol layer includes a standard protocol device virtualized by each first protocol device. The standard protocol device has a standard device identifier and a driver source identifier. The standard device identifier is used to identify the standard protocol device, and the driver source identifier is used to identify the first protocol to which the standard protocol device belongs.

[0022] The first protocol layer is a layer of underlying heterogeneous device protocols, including at least one first protocol device driven by the first protocol. The first protocol is a proprietary or industry-standard protocol used for communication between underlying devices; for example, the first protocol can be a bus protocol, Modbus protocol, BACnet protocol, LonWorks protocol, or Zigbee protocol. The first protocol device is a physical or logical device node connected to the first protocol network and controlled by the first protocol. Each first protocol device has a unique first protocol address within the first protocol layer. The first protocol address is an address code that uniquely identifies the device in the first protocol network. For example, if the first protocol is a bus protocol, the first protocol address can include the device bus address and loop identifier; if the first protocol is a Modbus protocol, the first protocol address can be a Modbus slave address. The standard protocol layer is a virtual abstract protocol layer set within the gateway device, used to abstract heterogeneous devices of different first protocol layers into standard protocol devices with a unified data format. The quasi-protocol device is a logical device object virtually generated based on the first protocol devices; each standard protocol device has a standard device identifier and a driver source identifier. The standard device identifier is a globally unique identifier within the standard protocol layer that uniquely identifies the virtual device. For example, the standard device identifier can be a fixed-length string generated using a hash algorithm, a universally unique UUID, or a numeric code generated based on the device serial number. The driver source identifier identifies the first protocol type to which the standard protocol device belongs. For example, the driver source identifier can be a protocol type code, a protocol name string, or a protocol driver handle. The first mapping relationship is a data structure that records the association between the first protocol address, the standard device identifier, and the driver source identifier.

[0023] In one embodiment, after the gateway device powers on and initializes, it starts the first protocol adapter. The first protocol adapter is a set of hardware interfaces and drivers in the gateway device used for communication with the first protocol network, including physical layer transceiver modules such as RS-485 transceivers, CAN bus transceivers, power line carrier modules, or wireless radio frequency modules, and a link layer protocol stack. The gateway device sends a device scan broadcast message to the first protocol network through the first protocol adapter. The device scan broadcast message is a management frame constructed according to the first protocol frame format, and its frame structure includes a frame header field, a protocol type field, a command code field (e.g., the command code field can be set to 0x01 to indicate a scan request), a reserved field, and a frame tail check field (e.g., a CRC cyclic redundancy check field). After receiving the device scan broadcast message, the first protocol device returns a device response message. The device response message contains the first protocol address and protocol characteristic information of the first protocol device. The gateway device receives the device response message, parses the message through the first protocol stack, and extracts the first protocol address and protocol characteristic information. The gateway device calls the identifier generation service to generate a standard device identifier based on the protocol characteristic information and a driver source identifier based on the protocol type of the first protocol. The gateway device associates and binds the first protocol address, the standard device identifier, and the driver source identifier to form a first mapping record. Multiple first mapping records are combined to form a first mapping relationship. The gateway device synchronously stores the first mapping relationship in the data storage area of ​​the standard protocol layer. The data storage area is a dedicated storage area designated in the gateway device's local memory; for example, the data storage area can be an SQLite database file, a memory hash table, or a structured JSON configuration file. During storage, the standard device identifier is used as the primary key index to establish the association mapping between the first protocol address and the driver source identifier, thus completing the establishment of the first mapping relationship between the first protocol layer and the standard protocol layer.

[0024] Step 102: Establish a second mapping relationship between the standard protocol layer and the second protocol layer, and send the second mapping relationship to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol.

[0025] The second protocol layer is the upper-layer control protocol layer, and the second protocol is a control protocol used for human-machine interaction or upper-layer system integration. The interactive control device is a human-machine interaction terminal, control panel, mobile terminal application, or host computer software driven by the second protocol, used to receive user input and generate cross-protocol control commands. The second protocol address is a logical address that uniquely identifies a standard protocol device in the second protocol network. For example, when the second protocol is the KNX protocol, the second protocol address can be a KNX group address, using a three-segment encoding structure of main group number / intermediate group number / subgroup number. The second mapping relationship is a data structure that records the mapping association between the standard device identifier and the second protocol address.

[0026] In one embodiment, after the establishment of the first mapping relationship is completed, the gateway device starts the second mapping relationship establishment process. The gateway device traverses all standard protocol device records in the standard protocol layer data storage area, and reads the standard device identifier and device control attributes of each standard protocol device one by one. The device control attributes are a parameter set describing the control characteristics of the device, including device function type, control priority parameter, status reporting period, supported control command set, device capability bitmap, etc. The device function type is used to identify the functional role of the device in the intelligent control system, and the device function type may include lighting control type, temperature regulation type, security monitoring type, curtain opening and closing type, access control type or environment sensing type. The control priority parameter is used to identify the response priority level of the device in a multi-device linkage scenario. For example, the control priority parameter can use a numerical range of 0-255 to represent the priority, or use enumeration values to represent three levels: high priority, medium priority, and low priority. The gateway device allocates a second protocol address to each standard protocol device according to the device control attributes, and generates the second mapping relationship. Then the gateway device sends the second mapping relationship to the interactive control device through the second protocol communication interface. The second protocol communication interface is a hardware interface and protocol stack used for communication with the second protocol network in the gateway device. Illustratively, when the second protocol is the KNX protocol, the second protocol communication interface can be a KNX bus interface, including a TP-UART transceiver or a KNX-IP gateway module. When sending, the gateway device serializes the second mapping relationship into a data format supported by the second protocol, such as a binary protocol frame, a JSON message or an XML message, and sends it to the interactive control device by means of unicast, multicast or broadcast. The interactive control device receives and parses the second mapping relationship, stores it in a local memory, and is used to map a user's operation instruction for the second protocol address to the corresponding standard device identifier when a user operates subsequently, thereby generating a cross-protocol control instruction including the target second protocol address.

[0027] Step 103: receiving a cross-protocol control instruction sent by an interactive control device, where the cross-protocol control instruction includes a target second protocol address; querying the second mapping relationship according to the target second protocol address to determine a corresponding target standard device identifier, querying the first mapping relationship based on the target standard device identifier to obtain a corresponding target driver source identifier and a target first protocol address, and routing the cross-protocol control instruction to the first protocol layer according to the target driver source identifier, so that the target first protocol drives a corresponding target first protocol device to execute the instruction according to the target first protocol address The cross-protocol control instruction is a control message encapsulated in a second protocol format, generated by the interactive control device in response to user operation. The cross-protocol control instruction includes a target second protocol address, a control opcode, and an operation value. The target second protocol address is the second protocol address obtained by the interactive control device from a second mapping relationship based on the device selected by the user. The target standard device identifier is the standard device identifier corresponding to the target second protocol address, obtained by querying the second mapping relationship. The target driver source identifier is the driver source identifier corresponding to the target standard device identifier, obtained by querying the first mapping relationship. The target first protocol address is the first protocol address corresponding to the target standard device identifier, obtained by querying the first mapping relationship. The target first protocol is the first protocol type corresponding to the target driver source identifier. The target first protocol device is a physical or logical device in the first protocol layer that is driven by the target first protocol and has a target first protocol address.

[0028] In one embodiment, the gateway device listens for cross-protocol control commands from the interactive control device in real time via a second protocol communication interface. Upon receiving a cross-protocol control command, the gateway device performs frame integrity verification on the command, such as performing CRC check, checksum check, or digital signature verification. After successful verification, the gateway device parses the cross-protocol control command according to the second protocol frame format and extracts the target second protocol address field. Using the target second protocol address as the search key, the gateway device performs a matching query in a locally stored second mapping table to obtain the target standard device identifier associated with the target second protocol address. If the query is successful, the gateway device continues to perform a matching query in a locally stored first mapping table using the target standard device identifier as the search key, simultaneously obtaining the target driver source identifier and the target first protocol address associated with the target standard device identifier. Synchronous acquisition means that the target driver source identifier field and the target first protocol address field are returned simultaneously in a single database query operation or memory retrieval operation. The gateway device queries a pre-installed protocol driver registry based on the target driver source identifier to determine the type of the corresponding target first protocol. The protocol driver registry is a mapping table maintained in the gateway device between driver source identifiers and first protocol driver module handles. The gateway device invokes the protocol conversion module corresponding to the target first protocol to re-encapsulate the control opcode and operation value in the cross-protocol control command according to the frame format of the target first protocol. Re-encapsulation includes mapping the general control opcode to a command code supported by the target first protocol, converting the operation value to the data field format of the target first protocol, and filling the target first protocol address into the frame header address field. After encapsulation, the gateway device routes the re-encapsulated command message to the first protocol layer through the first protocol adapter and sends it to the target first protocol address. The target first protocol device receives the command message, parses the command code and data field, executes the corresponding hardware operation, and completes the execution of the cross-protocol control command.

[0029] As described above, by establishing a first mapping relationship between the first protocol layer and the standard protocol layer and a second mapping relationship between the standard protocol layer and the second protocol layer locally on the gateway device, and completing reverse lookup, protocol encapsulation and routing forwarding within the gateway based on the cross-protocol control commands issued by the interactive control device, the transmission of control commands from heterogeneous protocol devices can be restricted to local processing on the gateway. Cross-protocol commands can be issued without relying on cloud relay, thereby eliminating public network transmission delay and jitter while ensuring the system's local operation capability in a network-off environment.

[0030] Figure 2 This is a flowchart illustrating the establishment of the first mapping relationship provided in the embodiments of this application, such as... Figure 2 As shown, the cross-protocol device interoperability method includes the following steps: Step 201: Scan the first protocol device driven by the first protocol under the first protocol layer, and obtain the first protocol address and protocol feature information corresponding to the first protocol device.

[0031] The scanning process is a device discovery process initiated by the gateway device through the first protocol adapter. Protocol characteristic information is a set of parameters characterizing the physical and logical attributes of the first protocol device, including device type code, device serial number, loop identifier, device capability description field, firmware version number, and vendor code. The device type code is an encoding used to identify the device category; for example, 0x01 represents lighting equipment, 0x02 represents air conditioning equipment, and 0x03 represents curtain equipment. The device serial number is a unique hardware serial number written to the device by the manufacturer during the production stage, typically a numeric string or a hexadecimal byte array. The loop identifier is an encoding used to identify the physical loop or logical group in which the device belongs.

[0032] In one embodiment, after the gateway device powers on, it initializes the first protocol adapter and configures physical layer parameters, such as baud rate, data bits, stop bits, parity bits, or wireless channel number. The gateway device constructs a device scan broadcast message. The destination address of the device scan broadcast message is set to the first protocol broadcast address, such as 0xFF or 0xFFFF, and the command code is set to the device discovery command code. The gateway device sends the device scan broadcast message on the first protocol network through the first protocol adapter and starts a scan timer. The timeout period of the scan timer is preset according to the size of the first protocol network. Before the scan timer expires, the gateway device listens for device response messages on the first protocol network. After receiving the device scan broadcast message, the first protocol device constructs and returns a device response message, which contains the first protocol address and protocol feature information of the first protocol device. The gateway device receives the device response message, parses the message data field, and extracts the first protocol address field and the protocol feature information field. For devices that do not respond before the scan timer expires, the gateway device may optionally perform a retry scan or mark them as offline. The extracted protocol feature information is stored in a temporary buffer of the gateway device according to a predefined data structure, awaiting processing in subsequent steps.

[0033] Step 202: Generate a standard device identifier corresponding to the first protocol device based on the protocol feature information, and generate a corresponding driver source identifier based on the protocol type of the first protocol.

[0034] In one embodiment, the gateway device reads the acquired protocol feature information from a temporary buffer and invokes an identifier generation service. The identifier generation service extracts the device type code, device serial number, and loopback identifier from the protocol feature information, performs calculations on these fields using a preset hash algorithm, and generates a standard device identifier. Simultaneously, the identifier generation service queries a preset protocol type code mapping table to obtain the protocol type code corresponding to the first protocol, uses this protocol type code as the driver source identifier, or performs bitwise operations between the protocol type code and the first protocol version number to generate a composite driver source identifier. The generated standard device identifier and driver source identifier are written into a temporary mapping record structure.

[0035] Step 203: Associate and bind the first protocol address, standard device identifier, and driver source identifier to form a first mapping relationship, and synchronously store the first mapping relationship to the standard protocol layer.

[0036] In one embodiment, the gateway device fills the acquired first protocol address, the generated standard device identifier, and the driver source identifier into a first mapping record structure. The first mapping record structure includes a first protocol address field, a standard device identifier field, a driver source identifier field, a record status field, and a creation timestamp field. Multiple first mapping record structures are combined to form a first mapping relationship table. The gateway device invokes the storage service to write the first mapping relationship table into the data storage area of ​​the standard protocol layer. The write operation includes creating a database table, inserting mapping records, and establishing a primary key index for the standard device identifier and a secondary index for the first protocol address. After the write is completed, the first mapping relationship between the first protocol layer and the standard protocol layer is established.

[0037] As described above, by scanning the first protocol devices under the first protocol layer to obtain the first protocol address and protocol feature information, and generating a standard device identifier and a driver source identifier based on the protocol feature information to form a first mapping relationship, the heterogeneous first protocol devices at the bottom layer can be uniformly abstracted into standard protocol devices with globally unique identifiers. A stable mapping foundation between the underlying physical devices and standard virtual devices is established locally on the gateway, providing the underlying addressing basis for the reverse routing of subsequent cross-protocol commands.

[0038] Figure 3 This is a flowchart of the standard device identifier generation method provided in the embodiments of this application, such as... Figure 3 As shown, the cross-protocol device interoperability method includes the following steps: Step 301: Extract the device type code, device serial number and loop identifier from the protocol feature information.

[0039] In one embodiment, the gateway device extracts the device type code, device serial number, and loopback identifier from the acquired protocol feature information through field offset parsing. Field offset parsing is a structured parsing performed according to the format of the first protocol device description data frame or device information message. For example, when the first protocol is the bus protocol, the protocol feature information is contained in the data field of the device registration frame, where the device type code occupies bytes 1 and 2, the device serial number occupies bytes 3 to 10, and the loopback identifier occupies bytes 11 and 12. The gateway device extracts the corresponding field values ​​from the protocol feature information byte array according to a predefined field length and offset, and stores them in temporary variables.

[0040] Step 302: Calculate the device type code, device serial number and loop identifier according to the preset hash algorithm to generate a standard device identifier.

[0041] The preset hash algorithm is a digest algorithm with low collision rate characteristics. The preset hash algorithm can be MD5 message digest algorithm, SHA-1 secure hash algorithm, SHA-256 secure hash algorithm, or a custom hybrid hash algorithm. The hybrid hash algorithm is a composite algorithm that combines multiple hash algorithms in series or parallel.

[0042] In one embodiment, the gateway device combines the extracted device type code, device serial number, and loop identifier into an original identifier string according to a concatenation rule. The concatenation rule is a predefined byte concatenation order and delimiter rule. Optionally, the concatenation can be performed directly in the order of device type code, device serial number, and loop identifier, or in the order of device type code, delimiter, device serial number, delimiter, and loop identifier, where the delimiter can be an underscore character, a hyphen, or a fixed byte 0x00. The gateway device calls a hash algorithm to perform a hash operation on the original identifier string, obtaining a fixed-length hash value. The length of the hash value is determined according to the selected hash algorithm; for example, the MD5 algorithm outputs a 128-bit hash value, and the SHA-256 algorithm outputs a 256-bit hash value. The gateway device converts the hash value into a string or a hexadecimal byte array as a standard device identifier. Before the hash operation, the gateway device adds a preset salt value to the original identifier string. The salt value is a fixed string preset at the time of the gateway device's manufacture or a dynamic string generated based on the gateway device's hardware information.

[0043] Step 303: Generate the driver source identifier based on the protocol type code of the first protocol.

[0044] In one embodiment, the gateway device queries a pre-configured protocol type code mapping table to obtain the protocol type code corresponding to the first protocol. The protocol type code mapping table is a pre-configured data table that records the correspondence between each first protocol name and its protocol type code. For example, the bus protocol corresponds to protocol type code 0x01, the Modbus protocol corresponds to protocol type code 0x02, and the BACnet protocol corresponds to protocol type code 0x03. The gateway device directly uses this protocol type code as the driver source identifier, or it shifts the protocol type code left by 8 bits and performs a bitwise OR operation with the first protocol version number to generate a composite driver source identifier containing protocol type and version information. The driver source identifier is stored as an integer or a string in the driver source identifier field of the first mapping record structure.

[0045] As described above, by extracting the device type code, device serial number, and loop identifier from the protocol feature information, generating a standard device identifier using a preset hash algorithm, and generating a driver source identifier based on the protocol type code of the first protocol, the physical attributes and protocol source information of the first protocol device can be solidified into a digital identity identifier. While ensuring the global uniqueness of the standard device identifier, the driver source identifier clearly distinguishes different first protocol types, providing an identity recognition basis for routing in scenarios where multiple protocols coexist.

[0046] Figure 4 This is a flowchart illustrating the establishment of the second mapping relationship provided in the embodiments of this application, such as... Figure 4 As shown, the cross-protocol device interoperability method includes the following steps: Step 401: Extract the standard device identifier and device control attributes corresponding to each standard protocol device from the standard protocol layer.

[0047] In one embodiment, the gateway device traverses the standard protocol device record table in the standard protocol layer data storage area, reading the standard device identifier field and device control attribute field of each record. The device control attribute field is structured data in JSON, XML, or binary serialization format. The gateway device calls the corresponding parser to deserialize it into a device control attribute object. The device control attribute object includes device function type attributes, control priority parameter attributes, status reporting cycle attributes, supported command set attributes, and device capability bitmap attributes, etc.

[0048] Step 402: Assign a second protocol address to each standard protocol device according to the device control attributes, and generate a second mapping relationship.

[0049] In one embodiment, the gateway device parses the extracted device control attributes of each standard protocol device to obtain the device function type and control priority parameters. The gateway device queries a preset address region partitioning table to determine the second protocol address region range to which the device belongs based on its function type. Within the determined address region range, it matches available second protocol address values ​​according to the control priority parameters. The determined second protocol address values ​​are associated and bound with the corresponding standard device identifiers to generate second mapping records. Multiple second mapping records are combined to form a second mapping relationship table.

[0050] Step 403: Configure the second mapping relationship to the interactive control device of the second protocol layer so that the interactive control device can issue cross-protocol control commands based on the second protocol address.

[0051] In one embodiment, the gateway device serializes the generated second mapping table into a data exchange format supported by the interactive control device. The data exchange format can be a binary protocol frame, a JSON object, or an XML document. The gateway device establishes a communication connection with the interactive control device through the second protocol communication interface and sends the serialized second mapping table to the interactive control device. Upon receiving the table, the interactive control device stores it locally and generates a device control list in the user interface based on the second mapping table, allowing the user to issue control commands by selecting the device entry corresponding to the second protocol address.

[0052] As described above, by extracting standard device identifiers and device control attributes from the standard protocol layer, assigning second protocol addresses to each standard protocol device based on the device control attributes and generating a second mapping relationship, and then configuring the second mapping relationship to the interactive control device, standardized virtual devices can be mapped to logical addresses addressable by the upper-layer control protocol. This enables the interactive control device to initiate control over the underlying heterogeneous devices based on a unified second protocol address space, thereby achieving decoupling between the upper-layer control protocol and the underlying device protocol.

[0053] Figure 5 This is a flowchart of the second protocol address allocation provided in the embodiments of this application, such as... Figure 5 As shown, the cross-protocol device interoperability method includes the following steps: Step 501: Parse the device control attributes to obtain the corresponding device function type and control priority parameters.

[0054] In one embodiment, the gateway device reads the structured data of device control attributes from a standard protocol device and calls an attribute parser to extract the device function type field value and the control priority parameter field value. The attribute parser is a pre-written parser program specific to the device control attribute data format. For example, when the device control attribute is in JSON format, the attribute parser extracts the device function type using the key "deviceFunctionType" and the control priority parameter using the key "controlPriority".

[0055] Step 502: Divide the corresponding second protocol address range according to the device function type, and match the second protocol address value in the corresponding second protocol address range according to the control priority parameter.

[0056] In one embodiment, the gateway device queries a pre-configured address region partitioning table. The address region partitioning table is a pre-configured mapping table of function types and address ranges. For example, when the second protocol is the KNX protocol, the second protocol address is a KNX group address. The address region partitioning table is configured such that the address region range for lighting control type is 1 / 1 / 1 to 1 / 1 / 100, the address region range for temperature regulation type is 1 / 2 / 1 to 1 / 2 / 100, the address region range for security monitoring type is 1 / 3 / 1 to 1 / 3 / 100, and the address region range for curtain opening / closing type is 1 / 4 / 1 to 1 / 4 / 100. Based on the obtained device function type, the gateway device retrieves the corresponding start and end addresses from the address region partitioning table to determine the available second protocol address region range for the standard protocol device. Within the determined address region range, the gateway device performs address matching according to the control priority parameters. Address matching adopts a priority segmentation allocation strategy. Optionally, the address region range is divided into three segments: high-priority devices are allocated the first segment address value, medium-priority devices are allocated the second segment address value, and low-priority devices are allocated the third segment address value. Alternatively, address matching can employ a sequential allocation strategy, searching for unoccupied free address values ​​sequentially starting from the beginning of the address range. Or, it can use a hash modulo allocation strategy, taking the control priority parameter modulo the total number of addresses within the address range to obtain an offset, adding it to the starting address to get a candidate address value. If the candidate address value is already occupied, the hash is incremented sequentially until a free address is found. The gateway device maintains an address occupancy bitmap, recording the occupancy status of each secondary protocol address value, and queries this bitmap during matching to determine if an address is free.

[0057] Step 503: Associate and bind the determined second protocol address value with the corresponding standard device identifier to generate a second mapping relationship.

[0058] In one embodiment, the gateway device establishes a one-to-one mapping record between the matched second protocol address value and the extracted standard device identifier. The mapping record includes a standard device identifier field, a second protocol address field, an allocation timestamp field, and an effective status field. The gateway device appends this mapping record to the second mapping relationship table and updates the occupancy status of the second protocol address value in the address occupancy bitmap to "occupied," thus completing the generation of the second mapping relationship.

[0059] As described above, by parsing the device control attributes to obtain the device function type and control priority parameters, dividing the second protocol address area range according to the device function type, and matching the second protocol address value according to the control priority parameters in the corresponding area, the limited second protocol address resources can be structurally allocated according to the device function role and priority. While avoiding address conflicts, it ensures that high-priority devices obtain priority addressing resources, providing address planning for efficient group control of interactive control devices and priority issuance of emergency commands.

[0060] Figure 6 This is a flowchart of cross-protocol control command routing provided in an embodiment of this application, such as... Figure 6 As shown, the cross-protocol device interoperability method includes the following steps: Step 601: Parse cross-protocol control instructions to obtain the target second protocol address.

[0061] In one embodiment, the gateway device receives cross-protocol control instruction data frames through a second protocol communication interface. The cross-protocol control instruction data frame is a binary data stream encapsulated according to the second protocol frame format. The gateway device invokes the second protocol stack parser to unpack the data frame, including extracting the frame header field, verifying the frame length, performing a CRC check, extracting the target second protocol address field, extracting the control opcode field, and extracting the operation value field. After parsing, the gateway device stores the target second protocol address in the instruction parsing context structure for subsequent steps to query.

[0062] Step 602: Query the second mapping relationship and obtain the corresponding target standard device identifier by matching the target second protocol address.

[0063] In one embodiment, the gateway device uses the resolved target second protocol address as the search key to perform a matching query in a locally stored second mapping table. The matching query performs an equality lookup on the second protocol address index in the second mapping table, returning the standard device identifier associated with the target second protocol address. If the query finds a match, the standard device identifier is output as the target standard device identifier; if the query fails, the gateway device constructs an error response message, returns it to the interactive control device via the second protocol communication interface, and terminates the current cross-protocol control process.

[0064] Step 603: Query the first mapping relationship based on the target standard device identifier, and synchronously match to obtain the corresponding target driver source identifier and target first protocol address.

[0065] In one embodiment, the gateway device uses the obtained target standard device identifier as the retrieval key to perform a primary key query in a locally stored first mapping table. The primary key query performs an equality lookup on the standard device identifier primary key index of the first mapping table, simultaneously returning the target driver source identifier field value and the target first protocol address field value associated with the target standard device identifier. Synchronous matching is achieved by using a multi-value return mechanism via a database composite index or a memory hash table in a single query operation to simultaneously obtain the target driver source identifier and the target first protocol address.

[0066] Step 604: Determine the type of the corresponding target first protocol based on the target driver source identifier, encapsulate the cross-protocol control command into the command format of the target first protocol, and route it to the first protocol layer.

[0067] In one embodiment, the gateway device queries a pre-built protocol driver registry based on the acquired target driver source identifier to determine the type of the target first protocol corresponding to the target standard device. The protocol driver registry records the mapping relationship between the driver source identifier and the first protocol driver module identifier. The gateway device loads the protocol conversion engine dynamic library corresponding to the target first protocol or calls the built-in protocol conversion function. The protocol conversion engine maps the control opcode in the cross-protocol control command to the command code supported by the target first protocol, converts the operation value according to the data field encoding rules of the target first protocol, fills the target first protocol address into the frame header address field, and constructs and generates the target first protocol command frame. For example, when the target first protocol is the bus protocol, the general enable opcode is mapped to the bus protocol command code 0x01, the brightness percentage value 0-100 is converted to the bus protocol PWM duty cycle value 0-255, and the target first protocol address is filled into the device address field of the bus protocol frame. After encapsulation, the gateway device sends the target first protocol command frame to the first protocol layer through the first protocol adapter, and it is transmitted by the first protocol network to the device corresponding to the target first protocol address, where the bus protocol is a custom protocol type.

[0068] As described above, by parsing cross-protocol control commands to obtain the target second protocol address, and sequentially querying the second mapping relationship and the first mapping relationship to reverse parse out the target standard device identifier, the target driver source identifier, and the target first protocol address, the cross-protocol control commands are encapsulated into the instruction format of the target first protocol and routed to the first protocol layer. The complete address parsing and frame format conversion from the upper layer control protocol to the lower layer device protocol can be completed locally on the gateway, and the protocol adaptive encapsulation and directed routing of control commands can be achieved without cloud intervention.

[0069] Figure 7 This is a flowchart of the target first protocol device positioning and instruction execution provided in the embodiments of this application, such as... Figure 7 As shown, the cross-protocol device interoperability method includes the following steps: Step 701: Verify the validity of the target first protocol address corresponding to the cross-protocol control instruction based on the first mapping relationship.

[0070] Among them, validity verification is the process of performing multi-dimensional verification on the target first protocol address before sending the instruction to the first protocol layer.

[0071] In one embodiment, the gateway device performs a validity check before sending the target first protocol instruction frame. Optionally, the validity check includes address format verification, checking whether the target first protocol address conforms to the first protocol address encoding specification, such as whether the address value is within a legal range and whether the address byte length is correct; device online verification, querying the list of currently online devices in the first protocol layer to check whether the device corresponding to the target first protocol address is online; and permission verification, checking whether the current cross-protocol control instruction has the operation permission for the device with the target first protocol address, such as by querying the permission configuration table to confirm whether the user level of the interactive control device meets the operation permission requirements of the device. If all the above checks pass, the target first protocol address is determined to be valid; if any check fails, the gateway device constructs an error response message and returns it to the interactive control device through the second protocol communication interface, terminating the current control process.

[0072] Step 702: Locate the corresponding target first protocol device in the first protocol layer using the verified target first protocol address, and have the target first protocol drive the target first protocol device to execute instructions.

[0073] In one embodiment, the gateway device performs a matching query in the device management table of the first protocol layer, using the verified target first protocol address as the search key, to locate the corresponding target first protocol device record. The device management table is a list of currently online first protocol devices maintained by the gateway device, recording the first protocol address, device status, communication quality parameters, and most recent heartbeat time of each device. After successful location, the gateway device obtains the communication parameters of the target first protocol device, including device response timeout, retransmission limit, and data frame length limit. In this embodiment, the gateway device sends the encapsulated target first protocol instruction frame to the target first protocol address through the first protocol adapter. The target first protocol device receives the instruction frame, parses the frame structure using its built-in first protocol stack parser, and extracts the command code and data field. The target first protocol device calls the corresponding hardware driver according to the command code to perform the corresponding physical operation. For example, when the target first protocol device is a lighting device and the command code is "on", the relay engaging circuit is turned on; when the command code is "brightness adjustment", the PWM dimming circuit is driven to output a pulse signal with the corresponding duty cycle; when the target first protocol device is a temperature regulating device, the valve actuator is driven to adjust the opening. Upon completion of execution, the target first protocol device may optionally construct an execution result response message and return it to the gateway device via the first protocol network. The gateway device receives the response message, parses the execution result status code, and if the execution is successful, may optionally convert the execution result into a second protocol format and feed it back to the interactive control device, thus completing the execution process of the cross-protocol control command.

[0074] As described above, by verifying the validity of the target first protocol address based on the first mapping relationship, the verified target first protocol address is located to the corresponding target first protocol device, and the target first protocol drives the target first protocol device to execute instructions. Multi-dimensional verification of address legality, device online status and operation permissions can be completed before the instructions are issued. Under the premise of ensuring the secure reachability of control instructions, the underlying physical device is driven to perform actions, thus ensuring the reliability and security of cross-protocol control.

[0075] Figure 8 This is a structural diagram of a cross-protocol device interoperability device provided in an embodiment of this application. The device is configured to execute the cross-protocol device interoperability method provided in the above embodiment, and possesses the corresponding functional modules and beneficial effects for executing the method. For example... Figure 8 As shown, the device specifically includes: The first mapping establishment module 801 is used to establish a first mapping relationship between the first protocol layer and the standard protocol layer. The first protocol layer includes at least one first protocol device driven by the first protocol. The first protocol device has a first protocol address. The standard protocol layer includes a standard protocol device virtualized by each first protocol device. The standard protocol device has a standard device identifier and a driver source identifier. The standard device identifier is used to identify the standard protocol device, and the driver source identifier is used to identify the first protocol to which the standard protocol device belongs. The second mapping establishment module 802 is used to establish a second mapping relationship between the standard protocol layer and the second protocol layer, and send the second mapping relationship to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The instruction processing module 803 is used to receive cross-protocol control instructions sent by the interactive control device. The cross-protocol control instructions include a target second protocol address. Based on the target second protocol address, the module queries a second mapping relationship to determine the corresponding target standard device identifier. Based on the target standard device identifier, the module queries a first mapping relationship to obtain the corresponding target driver source identifier and the target first protocol address. Based on the target driver source identifier, the module routes the cross-protocol control instructions to the first protocol layer, and the target first protocol drives the corresponding target first protocol device to execute the instructions according to the target first protocol address.

[0076] As described above, the first mapping establishment module 801 scans the first protocol devices under the first protocol layer to obtain the first protocol address and protocol feature information, generates a standard device identifier and a driver source identifier, and associates and binds the three to form a first mapping relationship, which is then synchronously stored in the standard protocol layer. This abstracts the heterogeneous first protocol devices into a unified format standard protocol device, establishing a unified addressing foundation between the underlying heterogeneous protocol and the standard virtual device locally on the gateway. The second mapping establishment module 802 extracts the standard device identifier and device control attributes from the standard protocol layer, assigns a second protocol address to each standard protocol device, and generates a second mapping relationship. The configuration is applied to the interactive control device, enabling it to initiate control commands based on a unified second protocol address, thus decoupling the upper-layer control protocol from the lower-layer heterogeneous protocols. The command processing module 803 receives the cross-protocol control command containing the target second protocol address, sequentially queries the second and first mapping relationships, reverse-parses out the target standard device identifier, the target driver source identifier, and the target first protocol address, encapsulates the command into the target first protocol's command format, and routes it to the first protocol layer. The target first protocol then drives the corresponding device to execute the command. The parsing, mapping, conversion, and routing of cross-protocol control commands are completed locally on the gateway. This solution, through a three-layer mapping architecture and a local reverse routing mechanism, ensures that the entire control command transmission is processed within the gateway, eliminating the need to upload to the cloud for protocol conversion and command distribution. This eliminates public network transmission latency and jitter, achieving precise inter-control of cross-protocol devices. Even in a network outage environment, it can maintain autonomous operation based on locally stored mapping relationships, improving the robustness and scalability of the heterogeneous protocol system.

[0077] In one possible embodiment, the first mapping establishment module 801 is specifically used for: Scan the first protocol device driven by the first protocol under the first protocol layer, and obtain the first protocol address and protocol characteristic information corresponding to the first protocol device; Generate a standard device identifier corresponding to the first protocol device based on the protocol feature information, and generate a corresponding driver source identifier based on the protocol type of the first protocol; The first protocol address, standard device identifier, and driver source identifier are associated and bound to form a first mapping relationship, and the first mapping relationship is synchronously stored in the standard protocol layer.

[0078] In one possible embodiment, the first mapping establishment module 801 is further configured to: Extract the device type code, device serial number, and loop identifier from the protocol feature information; The device type code, device serial number, and loop identifier are calculated using a preset hash algorithm to generate a standard device identifier; The driver source identifier is generated based on the protocol type code of the first protocol.

[0079] In one possible embodiment, the second mapping establishment module 802 is specifically used for: Extract the standard device identifier and device control attributes corresponding to each standard protocol device from the standard protocol layer; Assign a second protocol address to each standard protocol device based on the device control attributes, and generate a second mapping relationship; Configure the second mapping relationship to the interactive control device of the second protocol layer so that the interactive control device can issue cross-protocol control commands based on the second protocol address.

[0080] In one possible embodiment, the second mapping establishment module 802 is further configured to: Parse the device control attributes to obtain the corresponding device function type and control priority parameters; The corresponding second protocol address range is divided according to the device function type, and the second protocol address value is matched within the corresponding second protocol address range according to the control priority parameter; The determined second protocol address value is associated and bound with the corresponding standard device identifier to generate a second mapping relationship.

[0081] In one possible embodiment, the instruction processing module 803 is specifically used for: Parse cross-protocol control commands to obtain the target's second protocol address; Query the second mapping relationship and obtain the corresponding target standard device identifier by matching the target second protocol address; Based on the target standard device identifier, query the first mapping relationship and synchronously match to obtain the corresponding target driver source identifier and target first protocol address; Based on the target driver source identifier, determine the type of the corresponding target first protocol, encapsulate the cross-protocol control command into the command format of the target first protocol, and route it to the first protocol layer.

[0082] In one possible embodiment, the instruction processing module 803 is further configured to: The validity of the target first protocol address corresponding to the cross-protocol control command is verified based on the first mapping relationship; The target first protocol address that has passed the verification is used to locate the corresponding target first protocol device in the first protocol layer, and the target first protocol drives the target first protocol device to execute instructions.

[0083] Figure 9 This is a structural diagram of an electronic device provided in an embodiment of this application, such as... Figure 9 As shown, the electronic device includes a processor 901, a memory 902, an input device 903, and an output device 904.

[0084] The number of processors 901 can be one or more. Figure 9Taking a processor 901 as an example; the processor 901, memory 902, input device 903, and output device 904 can be connected via a bus or other means. Figure 9 Taking a bus connection as an example, the memory 902, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the cross-protocol device interoperability method in this embodiment. The processor 901 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 902, thereby realizing the aforementioned cross-protocol device interoperability method. The input device 903 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device, such as receiving user input of first protocol scan parameters, standard protocol layer configuration instructions, or interactive control device identification information. The output device 904 may include a display screen or other display device for displaying the establishment status of the first mapping relationship and the second mapping relationship, the online device list, the routing log of cross-protocol control instructions, or abnormal alarm information.

[0085] This application also provides a non-volatile storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform a cross-protocol device interoperability method described in the above embodiments. This method includes: establishing a first mapping relationship between a first protocol layer and a standard protocol layer, wherein the first protocol layer includes at least one first protocol device driven by a first protocol, the first protocol device having a first protocol address, and the standard protocol layer includes standard protocol devices virtualized by each first protocol device. Each standard protocol device has a standard device identifier and a driver source identifier, the standard device identifier identifying the standard protocol device, and the driver source identifier identifying the first protocol to which the standard protocol device belongs; and establishing a standard protocol layer and a second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The device receives cross-protocol control commands sent by the interactive control device. The cross-protocol control commands include the target second protocol address. The device queries the second mapping relationship based on the target second protocol address to determine the corresponding target standard device identifier. Based on the target standard device identifier, the device queries the first mapping relationship to obtain the corresponding target driver source identifier and the target first protocol address. The device routes the cross-protocol control command to the first protocol layer based on the target driver source identifier. The target first protocol drives the corresponding target first protocol device to execute the command according to the target first protocol address.

[0086] It is worth noting that in the embodiments of the above-mentioned devices, equipment and storage media, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the protection scope of the embodiments of this application.

[0087] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments provided herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A method for cross-protocol device interoperability, characterized in that, Applied to a gateway device, the method includes: A first mapping relationship is established between a first protocol layer and a standard protocol layer, wherein the first protocol layer includes at least one first protocol device driven by a first protocol, the first protocol device having a first protocol address, and the standard protocol layer includes a standard protocol device virtualized by each of the first protocol devices, the standard protocol device having a standard device identifier and a driver source identifier, the standard device identifier being used to identify the standard protocol device, and the driver source identifier being used to identify the first protocol to which the standard protocol device belongs; A second mapping relationship is established between the standard protocol layer and the second protocol layer, and the second mapping relationship is sent to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The system receives a cross-protocol control command sent by the interactive control device, the cross-protocol control command including a target second protocol address; it queries the second mapping relationship based on the target second protocol address to determine the corresponding target standard device identifier, queries the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address, and routes the cross-protocol control command to the first protocol layer according to the target driver source identifier, so that the target first protocol drives the corresponding target first protocol device to execute the command according to the target first protocol address.

2. The cross-protocol device interoperability method according to claim 1, characterized in that, The establishment of the first mapping relationship between the first protocol layer and the standard protocol layer includes: Scan the first protocol device running under the first protocol layer and driven by the first protocol to obtain the first protocol address and protocol feature information corresponding to the first protocol device; The standard device identifier corresponding to the first protocol device is generated based on the protocol feature information, and the corresponding driver source identifier is generated based on the protocol type of the first protocol; The first protocol address, the standard device identifier, and the driver source identifier are associated and bound to form the first mapping relationship, and the first mapping relationship is synchronously stored in the standard protocol layer.

3. The cross-protocol device interoperability method according to claim 2, characterized in that, The step of generating the standard device identifier corresponding to the first protocol device based on the protocol feature information includes: Extract the device type code, device serial number, and loop identifier from the protocol feature information; The standard device identifier is generated by performing calculations on the device type code, the device serial number, and the loop identifier according to a preset hash algorithm. The driver source identifier is generated based on the protocol type code of the first protocol.

4. The cross-protocol device interoperability method according to claim 1, characterized in that, The establishment of the second mapping relationship between the standard protocol layer and the second protocol layer includes: Extract the standard device identifier and device control attributes corresponding to each standard protocol device from the standard protocol layer; Assign a second protocol address to each of the standard protocol devices according to the device control attributes, and generate the second mapping relationship; The second mapping relationship is configured to the interactive control device of the second protocol layer so that the interactive control device can issue the cross-protocol control command based on the second protocol address.

5. The cross-protocol device interoperability method according to claim 4, characterized in that, The step of assigning a second protocol address to each of the standard protocol devices according to the device control attributes and generating the second mapping relationship includes: Parse the device control attributes to obtain the corresponding device function type and control priority parameters; The device function type is divided into corresponding second protocol address ranges, and the control priority parameter is used to match the second protocol address value within the corresponding second protocol address range. The determined second protocol address value is associated and bound with the corresponding standard device identifier to generate the second mapping relationship.

6. The cross-protocol device interoperability method according to claim 1, characterized in that, The step of determining the corresponding target standard device identifier by querying the second mapping relationship based on the target second protocol address, querying the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address, and routing the cross-protocol control command to the first protocol layer according to the target driver source identifier includes: Parse the cross-protocol control instructions to obtain the target second protocol address; Query the second mapping relationship, and obtain the corresponding target standard device identifier by matching the target second protocol address; Based on the target standard device identifier, query the first mapping relationship and synchronously match to obtain the corresponding target driver source identifier and the target first protocol address; Based on the target driver source identifier, the type of the target first protocol is determined, the cross-protocol control instruction is encapsulated into the instruction format of the target first protocol, and routed to the first protocol layer.

7. The cross-protocol device interoperability method according to claim 1, characterized in that, The instruction executed by the target first protocol device according to the target first protocol address includes: The validity of the target first protocol address corresponding to the cross-protocol control instruction is verified based on the first mapping relationship; The target first protocol address that has been verified is used to locate the target first protocol device in the first protocol layer, and the target first protocol drives the target first protocol device to execute instructions.

8. A cross-protocol device interoperability control device, characterized in that, include: The first mapping establishment module is used to establish a first mapping relationship between a first protocol layer and a standard protocol layer. The first protocol layer includes at least one first protocol device driven by a first protocol, and the first protocol device has a first protocol address. The standard protocol layer includes a standard protocol device virtualized by each of the first protocol devices. The standard protocol device has a standard device identifier and a driver source identifier. The standard device identifier is used to identify the standard protocol device, and the driver source identifier is used to identify the first protocol to which the standard protocol device belongs. The second mapping establishment module is used to establish a second mapping relationship between the standard protocol layer and the second protocol layer, and send the second mapping relationship to the interactive control device of the second protocol layer. The second mapping relationship is used to record the protocol address of each standard protocol device corresponding to the second protocol. The interactive control device is driven by the second protocol. The instruction processing module is configured to receive cross-protocol control instructions sent by the interactive control device, the cross-protocol control instructions including a target second protocol address; query the second mapping relationship based on the target second protocol address to determine the corresponding target standard device identifier; query the first mapping relationship based on the target standard device identifier to obtain the corresponding target driver source identifier and target first protocol address; and route the cross-protocol control instructions to the first protocol layer according to the target driver source identifier, so that the target first protocol drives the corresponding target first protocol device to execute the instructions according to the target first protocol address.

9. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the cross-protocol device interoperability method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the cross-protocol device interoperability method as described in any one of claims 1-7.

Images