Updated on 2025-07-29 GMT+08:00

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

Figure 1 Use of FunctionGraph

  1. Creating a product: Create a CoAP or MQTT product and device on IoTDA. For details, see Creating a Product.
    1. Access the IoTDA service page and click Access Console. Click the target instance card.
    2. Choose Products in the navigation pane and click Create Product. Set the parameters as prompted and click OK.
  2. Writing the FunctionGraph codec:
    1. 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
    2. 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.
  3. Deploying the FunctionGraph codec:
    1. 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
    2. After the authorization is successful, select the target function created in 2 and click Deploy.
      Figure 4 FunctionGraph-based Development - Codec deployment

Communications with FunctionGraph Through APIs

Figure 5 Process

  1. 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.

  2. 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=\"}"
    }
  3. 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}}]}"
     }
  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.
  5. 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}"
    }
  6. 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]}"
     }
  7. 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

Table 5 Data format of a product model

Scenario

Item

Message Type

Supported Protocol

Description

Decoding

(from binary code streams to JSON data)

Device reporting properties

properties_report

All

Device reporting properties

Device returning a command response

command_response

All

Device returning a command response

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

Device reporting messages

Encoding

(from JSON data to binary code streams)

Platform delivering commands

commands

All

Platform delivering commands

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 setting device properties

Platform querying device properties

properties_get

MQTT/MQTTS

Platform querying device properties

Platform delivering messages

messages

MQTT/MQTTS

Platform delivering messages

Data Decoding Format

When the platform receives data from the device, the platform sends the binary code stream in the payload to FunctionGraph. FunctionGraph decodes the binary stream into the JSON format defined in the product model. The JSON format can be identified by the platform. The following is the decoded data in JSON format:
{
     "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.

Data Encoding Format

When the platform delivers data to the device, the platform sends the JSON data defined by the product model to FunctionGraph. (If the data is not in that JSON format, the encoding and decoding may fail.) FunctionGraph encodes the JSON data into binary code streams that can be identified by the device. The following is the data in JSON format sent by the platform to FunctionGraph:
{
    "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.