Overview
Introduction
FunctionGraph can be utilized to convert binary data into JSON data or vice versa. This feature is used when the device has limited capabilities and can only report basic binary data. FunctionGraph supports Node.js, Python, Java, Go, C#, PHP, Cangjie, and custom runtimes, meeting multiple development requirements. You can check run logs and graphical monitoring data in real time, greatly improving development and debugging efficiency.

- FunctionGraph hosts and computes event-driven functions in a serverless context while ensuring high reliability, high scalability, and zero maintenance. All you need to do is write your code and set conditions.
- For details about FunctionGraph billing, see FunctionGraph Billing Overview. You pay only for what you use and you are not charged when your code is not running.

Check the following guide about data conversion for different protocols:
Process
- Creating a product: Create a CoAP or MQTT product and device on IoTDA. For details, see Creating a Product.
- Access the IoTDA service page and click Access Console. Click the target instance card.
- Choose Products in the navigation pane and click Create Product. Set the parameters as prompted and click OK.
- Writing the FunctionGraph codec:
- Create an event function. The event function must be created in the same region as that of the created product. Otherwise, the function cannot be referenced by the product. You can check the region in the upper left corner of the console.
Figure 2 FunctionGraph-based development - Checking regions
- Writing codecs. FunctionGraph supports multiple runtime languages, including Python, Node.js, Java, Go, C#, PHP, Cangjie, and custom runtimes. The supported versions vary depending on the languages. For details, see Supported Programming Languages.
- Create an event function. The event function must be created in the same region as that of the created product. Otherwise, the function cannot be referenced by the product. You can check the region in the upper left corner of the console.
- Deploying the FunctionGraph codec:
- Return to the IoTDA console, open the product page, click the Codec Development tab, and select FunctionGraph. If you use the tool for the first time, perform access authorization.
Figure 3 FunctionGraph-based Development - Codec authorization
- After the authorization is successful, select the target function created in 2 and click Deploy.
Figure 4 FunctionGraph-based Development - Codec deployment
- Return to the IoTDA console, open the product page, click the Codec Development tab, and select FunctionGraph. If you use the tool for the first time, perform access authorization.
Communications with FunctionGraph Through APIs
- If the reported data is binary data, IoTDA automatically encodes and stores the data using Base64. For example, if a device reports data [0x01, 0x02], the data stored in IoTDA is AQI=.
CoAP products report binary data by default. The data is then encoded using Base64 and sent to the codec. MQTT(S) products report data in the selected data format. The data is then encoded if necessary. For details, see Creating a Product.
- After receiving data, IoTDA transmits the data to FunctionGraph in a specific format if the codec exists. The following table lists the related parameters and data format (fixed format A).
Table 1 Upstream data format Parameter
Mandatory
Type
Description
codecType
Yes
String
Definition
Execution type. decode indicates upstream decoding (from binary code streams to JSON data), and encode indicates downstream encoding (from JSON data to binary streams).
message
Yes
String
Definition
String data in JSON format, which contains the topic and payload parameters.
- topic: For MQTT products, the reported topic is carried. For CoAP products, the value is null.
- payload: Base64 data encoded from the data reported by the device. (For MQTT products, you can select the encoding format on the product page.)
Example of a decoding request sent by IoTDA to FunctionGraph (for CoAP products):{ "codecType": "decode", "message": "{\"topic\": null,\"payload\": \"AABQAFo=\"}" }
Example of a decoding request sent by IoTDA to FunctionGraph (for MQTT products):
{ "codecType": "decode", "message": "{\"topic\": \"$oc/devices/661f99d6da14e268414f0af6_longsj123/sys/properties/report\",\"payload\": \"AABQAFo=\"}" }
- FunctionGraph decodes the data and returns the result. The following table lists the related parameters and data format (fixed format B).
Table 2 Downstream data format Parameter
Mandatory
Type
Description
status
Yes
String
Definition
Execution result. 200 indicates success, and other values indicate failure.
message
Yes
String
Definition
String data in JSON format. Used for decoding binary code stream data into JSON data.
Example of a decoding request sent by FunctionGraph to IoTDA:{ "status": 200, "message": "{\"msg_type\":\"properties_report\",\"services\":[{\"service_id\":\"smokerdector\",\"properties\":{\"level\":258,\"temperature\":3.4}}]}" }
- The data initially provided by the platform or applications for delivery is in JSON format and needs to be converted into binary code streams using the codec before final delivery.
- Before delivering data, IoTDA transmits the data in a specific format to FunctionGraph if the codec exists. The following table lists the related parameters and data format (fixed format A).
Table 3 Upstream data format Parameter
Mandatory
Type
Description
codecType
Yes
String
Definition
Execution type. decode indicates upstream decoding (from binary code streams to JSON data), and encode indicates downstream encoding (from JSON data to binary streams).
message
Yes
String
Definition
String data in JSON format.
Example of an encoding request sent by IoTDA to FunctionGraph:{ "codecType": "encode", "message": "{\"msg_type\":\"commands\",\"service_id\": \"smokerdector\",\"paras\": {\"value\": 1},\"command_name\": \"SET_ALARM\",\"hasMore\": 0,\"request_id\": 1}" }
- FunctionGraph decodes the data and returns the result. The following table lists the related parameters and data format (fixed format C).
Table 4 Downstream data format Parameter
Mandatory
Type
Description
status
Yes
String
Definition
Execution result. 200 indicates success, and other values indicate failure.
message
Yes
String
Definition
String data in JSON format, which contains the payload parameter.
- payload: byte[] data decoded by FunctionGraph.
Example of an encoding request sent by FunctionGraph to IoTDA:{ "status": 200, "message": "{\"payload\":[2,1,0,0,1]}" }
- The platform delivers the binary code streams encoded by the codec to the device. For example, [2,1,0,0,1].
IoTDA Product Model Data Format
Scenario |
Item |
Message Type |
Supported Protocol |
Description |
---|---|---|---|---|
Decoding (from binary code streams to JSON data) |
Device reporting properties |
properties_report |
All |
|
Device returning a command response |
command_response |
All |
||
Device returning a response to the platform for property setting |
properties_set_response |
MQTT/MQTTS |
Device returning a response to the platform for property setting |
|
Device returning a response to the platform for property query |
properties_get_response |
MQTT/MQTTS |
Device returning a response to the platform for property query |
|
Device reporting messages |
message_up |
MQTT/MQTTS |
||
Encoding (from JSON data to binary code streams) |
Platform delivering commands |
commands |
All |
|
Platform responding to device property reporting |
properties_report_reply |
NB-IoT (CoAP) |
Platform responding to device property reporting (NB-IoT devices) |
|
Platform setting device properties |
properties_set |
MQTT/MQTTS |
||
Platform querying device properties |
properties_get |
MQTT/MQTTS |
||
Platform delivering messages |
messages |
MQTT/MQTTS |
{ "status": 200, "message": "${Decoded JSON data}" }
${Decoded JSON data} is in the JSON format required by the platform.
- Device reporting properties
1 2 3 4 5 6 7 8 9 10
{ "msg_type": "properties_report", "services": [{ "service_id": "Battery", "properties": { "batteryLevel": 57 }, "event_time": "20151212T121212Z" }] }
Table 6 Data format of device reporting properties Parameter
Mandatory
Type
Description
Message Type
Yes
String
Message type. The value is fixed to properties_report.
services
Yes
List<ServiceProperty>
List of device services. For details, see the ServiceProperty structure table.
Table 7 ServiceProperty structure Parameter
Mandatory
Type
Description
service_id
Yes
String
Service ID of the device.
properties
Yes
Object
Service properties, which are defined in the product model associated with the device.
event_time
No
String
UTC time when the device collects data. The format is yyyyMMddTHHmmssZ, for example, 20161219T114920Z.
If this parameter is not carried in the reported data or is in incorrect format, the time when the platform receives the data is used.
- Responding to the Platform for Property Setting
1 2 3 4 5 6
{ "msg_type": "properties_set_response", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "result_code": 0, "result_desc": "success" }
Table 8 Data format of device returning a response to the platform for property setting Parameter
Mandatory
Type
Description
Message Type
Yes
String
Message type. Fixed value:
properties_set_response
request_id
No
String
Unique identifier of the request. If this parameter is carried in a message received by a device, the parameter value must be carried in the response sent to the platform. If the decoded message does not contain this field, the value of request_id in the topic is used.
result_code
No
Integer
Execution result. 0 indicates success, and other values indicate failure. If this parameter is not carried, the execution is considered successful.
result_desc
No
String
Description of the property setting response.
- Responding to the Platform for Property Query
1 2 3 4 5 6 7 8 9 10 11 12 13 14
{ "msg_type": "properties_get_response", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "services": [ { "service_id": "analog", "properties": { "PhV_phsA": "1", "PhV_phsB": "2" }, "event_time": "20190606T121212Z" } ] }
Table 9 Data format of device returning a response to the platform for property query Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at properties_get_response.
request_id
No
String
Unique identifier of the request. If this parameter is carried in a message received by a device, the parameter value must be carried in the response sent to the platform. If the decoded message does not contain this field, the value of request_id in the topic is used.
services
Yes
List<ServiceProperty>
List of device services. For details, see the ServiceProperty structure table.
Table 10 ServiceProperty structure Parameter
Mandatory
Type
Description
service_id
Yes
String
Service ID of the device.
properties
Yes
Object
Service properties, which are defined in the product model associated with the device.
event_time
No
String
UTC time when the device collects data. The format is yyyyMMddTHHmmssZ, for example, 20161219T114920Z.
If this parameter is not carried in the reported data or is in incorrect format, the time when the platform receives the data is used.
- Responding to the Platform for Command Delivery
1 2 3 4 5 6 7 8 9 10
{ "msg_type": "command_response", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "result_code": 0, "command_name": "ON_OFF", "service_id": "WaterMeter", "paras": { "value": "1" } }
Table 11 Data format of device returning a command response Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at command_response.
request_id
No
String
Unique identifier of the request. If this parameter is carried in a message received by a device, the parameter value must be carried in the response sent to the platform. If the decoded message does not contain this field, the value of request_id in the topic is used.
result_code
No
Integer
Execution result. 0 indicates success, and other values indicate failure. If this parameter is not carried, the execution is considered successful.
response_name
No
String
Response name, which is defined in the product model associated with the device.
paras
No
Object
Response parameters, which are defined in the product model associated with the device.
- Device Reporting Messages
1 2 3 4
{ "msg_type": "message_up", "content": "hello" }
Table 12 Data format of device reporting messages Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at message_up.
content
No
String
Message content.
{ "codecType": "encode", "message": "${JSON data sent from the platform to FunctionGraph}" }
${JSON data sent from the platform to FunctionGraph} is the JSON data sent by the platform to FunctionGraph before encoding.
- Platform delivering commands
1 2 3 4 5 6 7 8 9
{ "msg_type": "commands", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "command_name": "ON_OFF", "service_id": "WaterMeter", "paras": { "value": 1 } }
Table 13 Data format of platform delivering commands Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at commands.
request_id
Yes
String
Unique ID of a request. The ID is delivered to the device through a topic.
service_id
No
String
Service ID of the device.
command_name
No
String
Command name, which is defined in the product model associated with the device.
paras
No
Object
Command execution parameters, which are defined in the product model associated with the device.
- Platform Setting Device Properties
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
{ "msg_type": "properties_set", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "services": [{ "service_id": "Temperature", "properties": { "value": 57 } }, { "service_id": "Battery", "properties": { "level": 80 } } ] }
Table 14 Data format of platform setting device properties Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at properties_set.
request_id
Yes
String
Unique identifier of the request. If this parameter is carried in a message received by a device, the parameter value must be carried in the response sent to the platform.
services
Yes
List<ServiceProperty>
List of device services.
ServiceProperty Structure
Table 15 ServiceProperty structure Parameter
Mandatory
Type
Description
service_id
Yes
String
Service ID of the device.
properties
Yes
Object
Service properties, which are defined in the product model.
- Platform Querying Device Properties
1 2 3 4 5
{ "msg_type": "properties_get", "request_id": "42aa08ea-84c1-4025-a7b2-c1f6efe547c2", "service_id": "Temperature" }
Table 16 Data format of platform querying device properties Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at properties_get.
request_id
Yes
String
Unique ID of a request. The ID is delivered to the device through a topic.
service_id
No
String
Service ID of the device.
- Platform Responding to Device Property Reporting (NB-IoT Devices)
1 2 3 4 5
{ "msg_type": "properties_report_reply", "request": "213355656", "result_code": 0 }
Table 17 Data format of platform responding to device property reporting Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at properties_report_reply.
request
No
String
Base64-encoded string of property reporting.
result_code
No
Integer
Execution result of property reporting.
has_more
No
Boolean
Whether a cache command exists.
- Platform Delivering Messages
1 2 3 4
{ "msg_type": "messages", "content": "hello" }
Table 18 Data format of platform delivering messages Parameter
Mandatory
Type
Description
Message Type
Yes
String
The value is fixed at messages.
content
No
String
Content of command delivery.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot