Abstract: The HUAWEI CLOUD IoT platform carries the functional responsibilities of north-south data interconnection.
This article is shared from HUAWEI CLOUD community " How to develop products based on HUAWEI CLOUD IoT platform ", author: Super. Wen.
The HUAWEI CLOUD IoT platform carries the functional responsibilities of north-south data interconnection. In the process of implementing end-to-end IoT services based on the HUAWEI CLOUD IoT platform, developers need to perform secondary development based on the platform. In this article, let’s talk about product development first.
product development
In the IoT platform integration solution, the IoT platform, as the link between the previous and the next, opens up API interfaces to the application server and provides API docking to devices of various protocols. In order to provide richer device management capabilities, the IoT platform needs to understand the capabilities of the access device and the message format of the data reported by the device. Therefore, users need to complete the development of product models and codec plug-ins on the console. When implementing an IoT solution based on the IoT platform, the detailed operations to be completed are shown in the following table:
After the device access service is activated, the complete process of using the device access service is mainly divided into product development, application-side development, device-side development, and daily management.
Product development : Before connecting to the device, the developer conducts the corresponding development work based on the console, including creating products, creating devices, developing product models online, developing plug-ins online, online debugging, self-service testing, and releasing products.
Device side development : The device side can access the IoT platform by integrating SDK, modules or native protocols.
Application-side development : The rich device management capabilities of the IoT platform are opened to the outside world through APIs, and application developers can develop the required industry applications based on the API interface, such as smart city, smart park, smart industry, Internet of Vehicles and other industry applications to meet different needs. Industry needs
Daily management: After the real device is connected, daily device management is performed based on the console or API interface.
Product model introduction
The product model, also known as Profile, is used to define the attributes of an access device (such as color, size, collected data, identifiable instructions, or events reported by the device), and then pass the manufacturer, device type, and device model. , which uniquely identifies a device for easy platform identification. The product model can be developed without code in the device access console.
A product model is a document that describes what a device is, what it can do, and how it can be controlled. Developers build an abstract model of a device on the IoT platform by defining a product model, so that the platform can understand the services, properties, commands and other information supported by the device, such as colors, switches, etc. After defining a product model, you can use the product model defined on the console when registering the device.
In the HUAWEI CLOUD IoT platform, the product model is the key content of device access, which includes the capabilities and services provided by the device, as well as the data format of the device's uplink and downlink. For example, when the device reports data to the platform, the platform will match the product model according to the keywords of the reported data, and verify the data format with the matched product model file. Only the data that is successfully matched will be saved on the platform. If the match is unsuccessful, the IoT platform will discard the reported data as illegal data.
Product Information : Describe the basic information of a device, including manufacturer ID, manufacturer name, device type, and protocol type. For example, the manufacturer name of the water meter is "HZYB", the manufacturer ID is "TestUtf8ManuId", the device type is "WaterMeter", and the protocol type is "CoAP".
Service Capability : Describes the business capability of the device. After dividing the device business capability into several services, define the attributes, commands, and command parameters of each service. Taking a water meter as an example, the water meter has various capabilities, such as reporting various data such as water flow, alarm, electricity, connection, etc., and can accept various commands issued by the server. When the product model file describes the capabilities of the water meter, the capabilities of the water meter can be divided into five services, each of which needs to define its own reporting attributes or commands.
Product Model Case: Smart Water Meter
The HUAWEI CLOUD IoT platform provides a variety of methods for defining product models. Developers can choose the corresponding method to define product models according to their own needs:
- Import library model (platform preset product model)
- Upload model file (offline development)
- Excel import
- Custom function (online development)
Device codec plugin
Introduction to Codec Plugins
What is a codec plugin?
The codec plug-in can decode the data (binary format) reported by the terminal into data that the application server can "read" (JSON format), and encode the server-side downlink command data (JSON format) into something that the terminal device can "understand and execute". data (in binary format).
Why use codec plugins?
NB-IoT devices use binary format or tlv format data.
The CoAP protocol is used for communication between the NB-IoT device and the IoT platform. The payload of the CoAP message is the application layer protocol data, and the format of the application layer data is defined by the device itself. Since NB-IoT devices generally have high requirements for power saving, application layer data generally does not use JSON format data.
The application server side does not understand binary format or tlv format data.
How to develop codec plugins?
There are three ways to develop codec plug-ins: graphical development, offline development, and scripted development. Because offline development of plug-ins is more complicated and time-consuming, it is recommended to use graphical codec development plug-ins.
Graphical development refers to the rapid development of a product's codec plug-in in a visual way when the device is connected to the console.
Offline development refers to secondary development using the Java code Demo of the codec plug-in to implement codec functions, complete plug-in packaging and quality inspection, etc.
Scripted development refers to the use of JavaScript scripts to implement encoding and decoding functions.
HUAWEI CLOUD IoT platform graphical codec plug-in development adopts the technology of abstracting and encapsulating the original plug-in development code. Developers do not need to understand the Java programming language, but only need to define the format of the device code stream on the development interface, and code the code. The attribute relationship between the stream and the profile is mapped by dragging and dropping. After clicking deploy, the Portal will automatically generate the plug-in according to the developer's design and package and deploy it to the IoT platform.
For the uplink message sent by the device, first parse the CoAP message to obtain the application layer data, and then call the plug-in provided by the device manufacturer to decode, so as to send the message to the application platform; for the downlink message from the application platform, it is necessary to call the codec provided by the device manufacturer. Decode the plugin, assemble the CoAP message and send it to the device, as shown in the figure below. In addition, the codec plug-in is also responsible for encoding commands issued by the platform and responses to reported data.
data reporting
The message processing flow includes the data reporting processing flow and the command issuing processing flow. The data reporting processing flow is shown in the following figure.
After the connection between the device and the IoT platform is completed, once the device is powered on, the device collects and reports data based on the business logic defined on the device, which can be triggered by cycles or events. Devices can send data to the IoT platform in the following ways:
Device message reporting : The device can report the custom data of the device to the platform through the message reporting interface. The platform does not parse and store the message reported by the device, but forwards it to other HUAWEI CLOUD cloud services for storage and processing through data forwarding rules. Further data processing is performed through the console or API interface of other cloud services.
Device raw data (binary) reporting : The device can report the device's original code stream through the binary reporting interface. The platform parses the device's raw data into the JSON format defined by the product model through the codec plug-in, and reports the parsed data to the device access service for processing. related business processing.
Device attribute reporting : The device reports the attribute data defined in the product model to the platform through the attribute reporting interface, and the data parsed by the platform is reported to the device access service for related business processing.
Gateway batch attribute reporting : The gateway device reports the data of batch devices to the platform at one time, and the data parsed by the platform is reported to the device access service for related business processing.
In the data reporting process, there are two need to use codec plug-ins.
- Decode the binary stream data reported by the device into JSON formatted data and send it to the application server.
- Encodes the JSON format data responded by the application server into binary stream format data and sends it to the device.
Issuing the command
Command distribution means that the platform sends commands to the device, and the device responds and executes the command, so as to achieve the effect of remote control from the platform to the device.
The processes of immediate delivery and cache delivery of the two protocols, LwM2M/CoAP and MQTT, are listed here, as shown in the figure.
The application sends a command to the IoT platform, and the platform will find the corresponding codec plug-in according to the corresponding product information, encode the command request, and send the command to the device; if the command succeeds or fails, the command will be updated according to the issued result. Status, if the device responds to the command, it will update the command status to "Execution Successful" or "Execution Failed".
Since the use of MQTT does not require codec plug-ins, the form of transparent transmission is directly used. When the command is issued immediately, the application sends the command to the IoT platform, the platform sends the command to the device, returns the execution result, and informs the execution result by message .
The application cache sends commands. When the device is offline, the command is written into the cache queue and the message status is updated. Until the device reports data, the device goes online, subscribes to the message delivery topic, sends the message, and updates the message status.
Device codec plugin example:
For more learning content, please [Follow IoT IoT Community]
Add HUAWEI CLOUD IoT Assistant WeChat account (hwc-iot), reply "Read" for more information
Click Follow to learn about HUAWEI CLOUD's new technologies for the first time~