Multi-scene Internet of Things equipment access method and system

Abstract

The invention relates to a multi-scene Internet of Things equipment access method and system, and belongs to the technical field of Internet of Things equipment access. And establishing an association relationship according to a preset corresponding relationship of the fields between the communication protocols. When data sent by equipment in a third-party platform is received, the unique product identifier and the unique equipment identifier are obtained through the incidence relation, then the obtained result is compared with the unique product identifier and the unique equipment identifier which are pre-defined in the platform and correspond to the equipment, and if the obtained result is consistent with the unique product identifier and the unique equipment identifier, the equipment is not identified. And if yes, extracting the data uploaded by the equipment according to the association relationship. According to the invention, through the preset association relationship, the Internet of Things platform can effectively receive the data sent by the Internet of Things equipment in other platforms.

Description

Technical Field

[0001] The present invention relates to a multi-scenario Internet of Things device access method and system, belonging to the technical field of Internet of Things device access. Background Art

[0002] With the rapid development of the Internet of Things (IoT), the access and data interaction of IoT devices have become an important foundation for promoting the development of smart homes, industrial automation, smart cities and other fields. At present, there are many IoT device access solutions on the market, but most solutions still have many shortcomings in dealing with multiple scenarios, multiple device types, heterogeneous data formats, etc. Mainly reflected in the following aspects:

[0003] 1. Inconsistent data models: Different IoT device manufacturers and IoT device types use different data models, which makes it difficult for the IoT platform to uniformly manage and analyze device data.

[0004] 2. Incompatible data formats: Since IoT devices from different manufacturers and models use different data formats, IoT devices cannot be properly connected to the IoT platform, forcing the IoT platform to redesign the data structure.

[0005] 3. Complex access methods: In the IoT scenario, different manufacturers and different IoT device access volumes have different requirements for IoT device access methods, such as security, prevention of illegal access, batch access, dynamic batch access, and other aspects.

[0006] Based on the above problems 1 and 2, the Chinese patent authorization announcement with announcement number CN112202758B discloses a method for accessing IoT devices. This method sets an associated mapping file for each object model, and maps the attributes customized by the IoT device manufacturer to unified standard attributes through the mapping file, thereby avoiding the differences between different IoT devices. However, when this platform wants to receive data reported by IoT devices in a third-party platform using different communication protocols, due to the differences in communication protocols, the platform cannot effectively receive the data reported by the IoT device. Summary of the invention

[0007] The purpose of the present invention is to provide a multi-scenario IoT device access method and system to solve the problem that when receiving data from a third-party data platform, the platform cannot parse the data sent from the device due to differences in communication protocols.

[0008] To achieve the above object, the solution of the present invention includes:

[0009] A multi-scenario IoT device access method of the present invention is characterized in that it includes the following steps: when the IoT platform accesses an IoT device in a third-party IoT platform that uses a different communication protocol, an association relationship between a field in the third-party IoT platform communication protocol and a field in the IoT platform communication protocol is set; when the IoT platform receives a data message sent by the IoT device, a product unique identifier and a device unique identifier corresponding to the IoT device are extracted from the corresponding fields in the data message according to the association relationship, and the extracted identifier is compared with the product unique identifier and the device unique identifier corresponding to the IoT device pre-defined in the IoT platform. If they are consistent, the data sent by the IoT device is extracted from the corresponding fields in the data message according to the association relationship; and the extracted identifier and the extracted data are forwarded in the communication protocol format used by the IoT platform.

[0010] Furthermore, before reporting data, the IoT devices in this IoT platform are authenticated and authorized through the following steps: the authentication type and parameters of the IoT device are sent to the SDK provided by this IoT platform; the SDK constructs the triplet required for establishing an MQTT connection between the IoT device and this IoT platform according to the authentication type and parameters and sends it to the IoT device; the IoT device initiates an MQTT connection to this IoT platform according to the triplet; the IoT platform calculates the expected signature based on the triplet, compares the expected signature with the signature in the triplet, and outputs the authentication result based on the comparison result.

[0011] Furthermore, when the expected signature is consistent with the signature in the triplet, it is determined whether to send authentication parameters to the IoT device based on the authentication type. The IoT device sends a new triplet to the IoT platform based on the authentication parameters. The IoT platform recalculates a new expected signature based on the new triplet, compares the new expected signature with the signature in the new triplet, and outputs the authentication result based on the comparison result.

[0012] Furthermore, the IoT platform sends authentication parameters to IoT devices by publishing MQTT reserved messages.

[0013] Furthermore, the IoT device burns the parameters of the IoT device corresponding to the IoT device defined in the IoT platform into the IoT device by calling the application programming interface provided by the IoT platform.

[0014] A multi-scenario Internet of Things device access system comprises a processor, wherein the processor executes a computer program to implement the following steps: when the Internet of Things platform accesses an Internet of Things device in a third-party Internet of Things platform using a different communication protocol, an association relationship between a field in the communication protocol of the third-party Internet of Things platform and a field in the communication protocol of the Internet of Things platform is set; when the Internet of Things platform receives a data message sent by the Internet of Things device, a product unique identifier and a device unique identifier corresponding to the Internet of Things device are extracted from the corresponding fields in the data message according to the association relationship, and the extracted identifier is compared with the product unique identifier and the device unique identifier corresponding to the Internet of Things device predefined in the Internet of Things platform. If they are consistent, the data sent by the Internet of Things device is extracted from the corresponding fields in the data message according to the association relationship; and the extracted identifier and the extracted data are forwarded in the communication protocol format used by the Internet of Things platform.

[0015] Furthermore, before reporting data, the IoT devices in this IoT platform are authenticated and authorized through the following steps: the authentication type and parameters of the IoT device are sent to the SDK provided by this IoT platform; the SDK constructs the triplet required for establishing an MQTT connection between the IoT device and this IoT platform according to the authentication type and parameters and sends it to the IoT device; the IoT device initiates an MQTT connection to this IoT platform according to the triplet; the IoT platform calculates the expected signature based on the triplet, compares the expected signature with the signature in the triplet, and outputs the authentication result based on the comparison result.

[0016] Furthermore, when the expected signature is consistent with the signature in the triplet, it is determined whether to send authentication parameters to the IoT device based on the authentication type. The IoT device sends a new triplet to the IoT platform based on the authentication parameters. The IoT platform recalculates a new expected signature based on the new triplet, compares the new expected signature with the signature in the new triplet, and outputs the authentication result based on the comparison result.

[0017] Furthermore, the IoT platform sends authentication parameters to IoT devices by publishing MQTT reserved messages.

[0018] Furthermore, the IoT device burns the parameters of the IoT device corresponding to the IoT device defined in the IoT platform into the IoT device by calling the application programming interface provided by the IoT platform.

[0019] The beneficial effects of the present invention are as follows: the present invention is a pioneering invention, which establishes an association relationship based on the correspondence between the fields of the pre-set communication protocols. When a third-party Internet of Things platform uses an Internet of Things device with a different communication protocol to send data to the present Internet of Things platform, the product unique identifier and the device unique identifier are obtained according to the association relationship, and then the obtained product unique identifier and the device unique identifier are compared with the product unique identifier and the device unique identifier corresponding to the Internet of Things device in the present Internet of Things platform. If they are consistent, the legal verification is passed, and then the corresponding data is extracted. The present invention effectively enables the present Internet of Things platform to receive data sent by Internet of Things devices in other platforms through the pre-set association relationship. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a schematic diagram of a physical model conversion example of the present invention;

[0021] Figure 2 It is a schematic diagram of the present invention after converting the power distribution IoT protocol;

[0022] Figure 3 It is a schematic diagram of the present invention after converting the industrial and commercial savings agreement;

[0023] Figure 4 It is a schematic diagram of the one-key-one-secret authentication steps of the present invention;

[0024] Figure 5 It is a schematic diagram of the one-machine-one-secret authentication process of the present invention;

[0025] Figure 6 It is a schematic diagram of the one-type-one-password pre-registration authentication steps of the present invention;

[0026] Figure 7 It is a schematic diagram of the one-type-one-password pre-registration authentication process of the present invention;

[0027] Figure 8 It is a schematic diagram of the one-type-one-password authentication step without pre-registration of the present invention;

[0028] Fig. 9 It is a schematic diagram of the one-type-one-password authentication process without pre-registration of the present invention;

[0029] Fig.10 It is a schematic diagram of the timing of device data reporting of the present invention;

[0030] Fig.11 It is a schematic diagram of the timing of sending commands of the present invention. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0032] The idea of ​​the present invention is to extract the data reported by the IoT devices required by the platform from the data messages using other communication protocols that have passed legal verification.

[0033] Method Example:

[0034] This embodiment provides a multi-scenario IoT device access method. The present invention first defines a general object model structure of the platform standard from four dimensions: basic information, attributes, events, and services of IoT devices, as shown in Table 1. The sample is shown in Table 2, which respectively describes the basic information of IoT devices, what attribute information they have, what they can do, and what they can provide. The object model supports dynamic expansion, and users can customize the details of the above dimensions according to actual needs, and supports multiple data structures, including: int, float, long, double, enum, bool, date, string, array, struct. The object model also provides data verification function.

[0035] Table 1 Physical model structure design

[0036]

[0037] Table 2 Physical model data format example and description

[0038]

[0039]

[0040]

[0041] When you need to add a device to the platform, add the corresponding parameters of the corresponding device in the platform's management page, for example, the unique identifier of the product: productKey, the unique identifier of the device: deviceKey, and the device secret key: deviceSecret.

[0042] When the data format of the object model sent and received by the IoT device fully conforms to the platform standard format, it communicates directly with the platform.

[0043] When some IoT devices cannot modify the physical model data they report due to hardware and software limitations, but also want to access the IoT platform in the platform standard format, the present invention provides a physical model conversion function, that is, maintaining a mapping table in the IoT platform, which includes the physical model data format before conversion and the physical model data format after conversion. Through mapping conversion, these IoT devices can also send and receive data in the platform standard format. For example, Figure 1As shown in the figure, a product "intelligent transformer" and a specific device "intelligent transformer ENBYQ01" are defined. In the platform standard format, the unique identifier of its attribute name "transmission voltage" is "PS_V", but the unique identifier of its original attribute name "transmission voltage" is "PS_V_OLD" and cannot be modified. Therefore, the corresponding mapping relationship is added through the IoT platform, that is, the mapping conversion from "PS_V_OLD" to "PS_V", and the value of "PS_V_OLD" can be stored in "PS_V", and the data information sent is displayed in "PS_V" on the page. When "intelligent transformer ENBYQ01" needs to receive data, the platform converts "PS_V" to "PS_V_OLD" before sending it.

[0044] When the IoT platform of the present invention needs to use data in a third-party platform, since the communication protocol selected by other IoT platforms is different from that of the IoT platform of the present invention, the data format sent by the device does not conform to the standard data format of the IoT platform of the present invention. Therefore, before the IoT platform of the present invention accesses the device in the third-party IoT platform, it is necessary to perform corresponding configuration in the platform to convert the data format, for example, add the product unique identifier productkey and the device unique identifier devicekey of the device, and extract the data in the corresponding fields in the corresponding protocol message. Among them, adding the productkey and devicekey corresponding to the device in the platform in advance is to verify whether the device is legal, that is, when the extracted productkey and devicekey are not defined in the platform, the protocol message is ignored.

[0045] When the platform receives data from a third-party platform, the platform pre-configures corresponding association relationships based on the differences in the protocol formats used by the third-party platform and the protocol used by the platform. When the platform receives data packets reported by IoT devices in a third-party platform that uses different communication protocols, the platform parses the data in the corresponding fields of the received protocol packets through the pre-configured association relationships to obtain relevant information about the device.

[0046] The following two specific examples illustrate the above:

[0047] like Figure 2As shown, when the device in the third-party platform uses the data format of the power distribution Internet of Things protocol to send a data message including specific data, since the "deviceID" field of the payload in the data message has been configured in this platform to associate with the product unique identifier and device unique identifier of this platform, "charger0001" (devicekey) and "charger" (productkey) are extracted from the "deviceID" field in the data message. Since the devicekey and productkey of the device are pre-configured in this platform, the data reported by the device passes the legal verification, and then the data sent by the device is extracted from the "data" field in the data message reported by the device, and then all the obtained data is stored in the database in the platform standard data format, and then displayed on the page.

[0048] like Figure 3 As shown, when the device in the third-party platform uses the data format of the Industrial and Commercial Storage Protocol (private protocol) to send a data message including specific data, since the topic field in the data message and the "Datatype" field of the payload have been pre-configured in this platform to associate with the product unique identifier and device unique identifier of this platform respectively, "emu" (productkey) is extracted from the "Datatype" field in the data message, and "001839" is extracted from the last field in the topic, and is concatenated with the obtained "emu" to obtain "emu_001839" (devicekey). Since the devicekey and productkey of the device are pre-configured in this platform, the device passes the legal verification, and then the data sent by the device is extracted from the "data" field in the data message reported by the device, and then all the obtained data is stored in the database in the platform standard data format, and then displayed on the page.

[0049] After the object model data is defined, the present invention establishes a connection with the Internet of Things platform by using the MQTT (Message Queuing Telemetry Transport) protocol, and defines a standard universal triplet structure and generation strategy. The triplet structure is shown in Table 3, which provides a variety of device access solutions to optimize the performance of the Internet of Things platform, reduce costs, improve user experience and adapt to changes. When the platform receives data from a third party, since a connection has been established with the third-party platform at this time, there is no need to use the connection method provided by the present invention. The present invention provides different access solutions for different scenarios, namely: one machine and one password, one type and one password pre-registration, one type and one password without pre-registration. The comparison of the three authentication schemes is shown in Table 4.

[0050] Table 3 Triple structure design

[0051]

[0052]

[0053] Table 4 Comparison of different authentication schemes

[0054]

[0055]

[0056] In the above three authentication methods, data is transmitted in plain text during communication with the platform. For scenarios with confidentiality requirements, the platform supports the TLS (Transport Layer Security) protocol for encrypted communication, thereby ensuring the security of interactive data.

[0057] When the device establishes a connection with the platform, it transmits the information provided by the platform that needs to be burned into the device's own firmware and the corresponding authentication type of the device to the SDK (Software Development Kit) provided by the platform. The SDK generates triplet data under different authentication types according to different authentication types, and returns the generated triplet data to the corresponding device. Then the device initiates an MQTT connection to the platform based on the received triplet. The platform performs authentication and authorization based on the triplet data. If it passes, the connection is allowed to be established, otherwise it is rejected. When the device establishes a connection with the platform, the device can report data to the platform. Among them, the device burns the information provided by the platform into its own firmware by calling the application programming interface provided by the platform.

[0058] Specifically, the authentication steps for one-key-one-secret are as follows: Figure 4 As shown, the authentication process is as follows Figure 5 The authentication steps for one-type-one-password pre-registration are as follows Figure 6 As shown, the authentication process is as follows Figure 7 The authentication steps for one type and one password without pre-registration are as follows Figure 8 As shown, the authentication process is as follows Fig. 9As shown. Among them, the one-type one-password pre-registration-free is divided into two steps: S1. Construct a one-type one-password pre-registration activation triplet through the SDK provided by the platform, that is, the authentication type is 3, and after establishing a connection with the platform, obtain mqttClientId and deviceToken; S2. One-type one-password pre-registration-free authentication, the authentication method is the same machine and one password, the difference is: the mqttClientId issued by the platform replaces the mqttClientId in the one-machine and one-password triplet, deviceToken replaces password, the authentication type is 4, and the rest of the process is the same as one-machine and one password. When the platform sends the authentication parameters, it sends the authentication parameters required by the authentication type by publishing the MQTT reservation message, so the device can subscribe to the corresponding topic after the MQTT connection is successfully established, and can still receive the corresponding authentication parameters. After the platform waits for the set time after sending the authentication parameters, for example, 15s, if the device is not offline, it will actively disconnect from the device.

[0059] The following is a specific example to illustrate the construction of a one-secret-one-trick triple:

[0060] The tenant first created products and devices on the cloud platform, where productKey is: wcnProduct, deviceKey is: wcnDeviceKey5, the tenant's unique identifier tenantId is: 1547834736794886145, the current timestamp is: 1710916764306, the signature algorithm used is HmacSHA256, and the deviceSecret is "IqbcEX90fk". After parameter replacement, its mqttClientId is: "wcnProduct.wcnDeviceKey5|securemode=1, authType=1, signmethod=HmacSHA256, timestamp=1710916764306, tenantId=1547834736794886145|"; username is: "wcnDeviceKey5&wcnProduct"; password is calculated through the following steps:

[0061] Set key: "clientId", value: "wcnProduct.wcnDeviceKey5|"; key: "tenanId", value:

[0062] "1547834736794886145"; key: "timestamp", value: "1710916764306"; sort the key dictionary from small to large, and then concatenate the three key-values ​​after sorting to get the plaintext to be signed: "clientIdwcnProduct.wcnDeviceKey5timestamp1710916764306tenantId1547834736794886145". Since the authentication type is one machine and one secret, the signkey is deviceSecert, that is, "IqbcEX90fk", and the signature algorithm uses HmacSHA256. Therefore, password = HmacSHA256({plainText}, {signkey}), that is: password = "da6cc4b6e9094c6b3a4703586266a54390c9770d5a5fb7c11ed236f16ce900b5".

[0063] The overall timing of the device uplink data is as follows Fig.10 As shown, for example, reporting the rated capacity of the battery. As can be seen from the figure, since some devices selected the physical model conversion function when sending data, when the platform receives the data reported by such devices, it will convert these data into data in the platform standard format according to the mapping relationship, and then store the converted data in the database. When the user queries the data reported by the device, since the data reported by some devices uses the physical model conversion function, the platform converts the data format of the data reported by the device into the data format before conversion according to the mapping relationship, and then sends it to the user. Among them, the sample example of device data submission is shown in Table 5, and the sample example of the response message when the platform responds to the device is shown in Table 6.

[0064] Table 5 Device data upload example

[0065]

[0066] Table 6 Example of response message when the platform responds to the device

[0067]

[0068] The overall timing of sending commands to the device is as follows: Fig.11 As shown, for example, reading alarm records. As can be seen from the figure, since the object models of some devices do not conform to the platform standard format, the parameters corresponding to the command are converted according to the mapping relationship, and then the command is sent to the corresponding device. Among them, the standard data format of the command sent from the platform to the device is shown in Table 7, and the data format of the device responding to the platform command is shown in Table 8.

[0069] Table 7 Example of standard data format for commands

[0070]

[0071] Table 8 Example of data format for device response to platform command

[0072]

[0073]

[0074] After receiving the response result, the platform decides whether to perform the corresponding physical model conversion on the response data according to the physical model format of the device. The platform stores the device response result or the converted result in the database to form a complete record of the command sent to the response. After the platform stores the device response result or the converted result in the database, it can directly send the result to the user according to the needs, or wait for the user to obtain the corresponding response result by actively querying the command issuance history.

[0075] System Example:

[0076] This embodiment provides a multi-scenario IoT device access system, which includes a processor, and the processor executes a computer program to implement the steps of the method introduced in the method embodiment. Since the introduction of the method is clear enough, it will not be repeated here.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A multi-scenario IoT device access method, characterized in that: The method comprises the following steps: when the IoT platform accesses an IoT device in a third-party IoT platform using a different communication protocol, setting an association relationship between a field in the communication protocol of the third-party IoT platform and a field in the communication protocol of the IoT platform; When the IoT platform receives a data message sent by the IoT device, the product unique identifier and the device unique identifier corresponding to the IoT device are extracted from the corresponding fields in the data message according to the association relationship, and the extracted identifier is compared with the product unique identifier and the device unique identifier corresponding to the IoT device pre-defined in the IoT platform. If they are consistent, the data sent by the IoT device is extracted from the corresponding fields in the data message according to the association relationship; the extracted identifier and the extracted data are forwarded in the communication protocol format used by the IoT platform.

2. The multi-scenario IoT device access method according to claim 1, characterized in that: Before reporting data, the IoT devices in this IoT platform are authenticated and authorized through the following steps: the authentication type of the IoT device and the parameters of the IoT device are sent to the SDK provided by this IoT platform; the SDK constructs the triple required for establishing an MQTT connection between the IoT device and the IoT platform according to the authentication type and parameters and sends it to the IoT device; the IoT device initiates an MQTT connection to the IoT platform according to the triple; the IoT platform calculates the expected signature according to the triple, compares the expected signature with the signature in the triple, and outputs the authentication result according to the comparison result.

3. The multi-scenario IoT device access method according to claim 2, characterized in that: When the expected signature is consistent with the signature in the triplet, it is determined whether to send authentication parameters to the IoT device according to the authentication type. The IoT device sends a new triplet to the IoT platform according to the authentication parameters. The IoT platform recalculates a new expected signature based on the new triplet, compares the new expected signature with the signature in the new triplet, and outputs the authentication result based on the comparison result.

4. The multi-scenario IoT device access method according to claim 3 is characterized in that: The IoT platform sends the authentication parameters to the IoT device by publishing an MQTT reserved message.

5. The multi-scenario IoT device access method according to claim 2, characterized in that: The IoT device calls the application programming interface provided by the IoT platform to burn the parameters of the IoT device corresponding to the IoT device defined in the IoT platform into the IoT device.

6. A multi-scenario IoT device access system, comprising a processor, characterized in that: The processor executes a computer program to implement the following steps: when the IoT platform accesses an IoT device in a third-party IoT platform that uses a different communication protocol, an association relationship between a field in the communication protocol of the third-party IoT platform and a field in the communication protocol of the IoT platform is set; When the IoT platform receives a data message sent by the IoT device, the product unique identifier and the device unique identifier corresponding to the IoT device are extracted from the corresponding fields in the data message according to the association relationship, and the extracted identifier is compared with the product unique identifier and the device unique identifier corresponding to the IoT device pre-defined in the IoT platform. If they are consistent, the data sent by the IoT device is extracted from the corresponding fields in the data message according to the association relationship; the extracted identifier and the extracted data are forwarded in the communication protocol format used by the IoT platform.

7. The multi-scenario IoT device access system according to claim 6, characterized in that: Before reporting data, the IoT devices in this IoT platform are authenticated and authorized through the following steps: the authentication type of the IoT device and the parameters of the IoT device are sent to the SDK provided by this IoT platform; the SDK constructs the triple required for establishing an MQTT connection between the IoT device and the IoT platform according to the authentication type and parameters and sends it to the IoT device; the IoT device initiates an MQTT connection to the IoT platform according to the triple; the IoT platform calculates the expected signature according to the triple, compares the expected signature with the signature in the triple, and outputs the authentication result according to the comparison result.

8. The multi-scenario IoT device access system according to claim 7, characterized in that: When the expected signature is consistent with the signature in the triplet, it is determined whether to send authentication parameters to the IoT device according to the authentication type. The IoT device sends a new triplet to the IoT platform according to the authentication parameters. The IoT platform recalculates a new expected signature based on the new triplet, compares the new expected signature with the signature in the new triplet, and outputs the authentication result based on the comparison result.

9. The multi-scenario IoT device access system according to claim 8, characterized in that: The IoT platform sends the authentication parameters to the IoT device by publishing an MQTT reserved message.

10. The multi-scenario IoT device access system according to claim 7, characterized in that: The IoT device calls the application programming interface provided by the IoT platform to burn the parameters of the IoT device corresponding to the IoT device defined in the IoT platform into the IoT device.

Images