Message Communications

What Do I Do If Data Reporting Fails?

1. If the device was registered by calling an API, check whether the device has been deleted by the IoT platform because the device did not go online within the timeout period. If the device has been deleted, re-register the device and report data again.
2. Check whether the product information specified when you called the API to register the device is consistent with that in the product model.
3. Check whether the property names in the reported message are the same as the service properties defined in the product model.
4. If the fault persists, check whether the network connection between the device and the platform is normal and whether the device is running properly.

Should I Use the Message Reporting API or Property Reporting API to Report Device Data?

It depends. If you want the data to be parsed by the IoT platform, use the property reporting API. You need to develop product models in this case. If you want the data to be transparently transmitted by the platform, use the message reporting API. Product models are not required.

How Can I Check Whether Device Message Reporting Is Successful on the IoT Platform?

Device messages are transparently transmitted, so you can check the report result by message tracing and run logs.

• Message tracing: Log in to the IoTDA console, choose Devices > All Devices in the navigation pane, select a device to access its details page, and click Start Trace on the Message Trace tab page.
• Run logs: Configure run logs by referring to Usage of Run Logs and view the run logs after the function is enabled.

Why Can't I See the Data Reported by a Device on the IoTDA Console?

Possible Causes:

The reported device properties do not match the properties defined in the product model.

Solutions:

1. View the product information of the device and check whether the properties in the product model are consistent with those reported by the device.
2. Log in to the IoTDA console, choose Devices > All Devices in the navigation pane, select a device to access its details page, and click Start Trace on the Message Trace tab page. After the device reports the data again, check whether related logs exist. If no log exists, the data does not reach the IoT platform. In this case, check the network status on the device side. If logs exist, view the error information in the logs.
3. You can also choose O&M > Run Logs in the navigation pane, and configure the run logs by referring to Description of Run Logs. After the run logs are enabled, you can view the error information in the logs.

Why Was Data Displayed in the Device Shadow Inconsistent with That Reported by the Device?

When a device accesses a service, the binary data reported by the device is encoded in Base64 format, so it initially appears to be inconsistent. Once the data is decoded, it will be consistent.

Why Can't a Device Report Data Using a Custom Topic?

Possible Causes:

The custom topic does not match or does not have the permission to push data.

Solutions:

The prefix of the message topic has been specified as $oc/devices/{device_id}/user/ by the platform. You can only add custom parts of non-variables after the preset prefix. Before using a custom topic to report data, ensure that the topic exists and has the release permission.

Figure 1 Custom topic

Why Did Devices Fail to Receive Data Reporting Responses?

• If the codec was developed online, Add Response Field must be selected under Data Reporting.
  Figure 2 Adding a new message
  
• If the codec is developed offline, the cloudRsp logic must be defined in the codec code.
  Figure 3 Codec code example
  

Why Is Data Reporting Successful at One Place But Fails Elsewhere?

Contact the NB-IoT network carrier to check whether the NB-IoT card has geographical restrictions and the local NB-IoT network status.

How Do I Convert a String Reported by an NB-IoT Device into Binary Code?

Convert the string to ASCII format first, and then to the binary code. For example, convert abc to ASCII (979899) and then to binary (011000010110001001100011).

Why Are Garbled Characters Displayed on the Platform When Chinese Data Is Reported?

Description:

When the MQTT.fx device simulator is used to report data, the JSON character string contains Chinese characters, as shown in the following figure.

Figure 4 MQTT.fx data reporting

Garbled characters are displayed after alarms are reported to the IoTDA platform, as shown in the following figure.

Figure 5 Device details

Possible Causes:

The MQTT.fx device simulator does not support Chinese characters.

Solution

1. Do not use Chinese characters when interacting with the platform.
2. Perform Unicode encoding on Chinese characters in the reported data.
3. Replace the third-party device simulator. The Device Simulator developed by IoTDA is recommended.

How Do I Deliver a Command to a Device Using LwM2M over CoAP?

Choose Device > All Devices in the navigation pane, select a device to access its details page, choose the Cloud Delivery tab page, go to the Command Delivery tab page, and click Deliver Command.

For details, see LwM2M/CoAP Device Command Delivery.

How Do I Deliver Commands to an MQTT Device?

Choose Device > All Devices in the navigation pane, select a device to access its details page, choose the Cloud Delivery tab page, go to the Command Delivery tab page, and click Deliver Command.

For details, see MQTT Device Command Delivery.

What Should I Do If a Command Fails to Be Delivered?

Description:

An error occurs when you call the API for delivering a command, or the API call successes but the device does not receive the command.

Possible Causes:

1. The API does not support the device protocol.
2. The downstream topic subscribed by the device is incorrect, or the upstream topic and message body of the device are incorrect.

Solutions:

1. Check whether the API supports the device protocol. Synchronous commands can be delivered only to MQTT devices.
2. For synchronous command delivery:
   • Check whether the device has subscribed to the downstream topic. If not, the device cannot receive commands from the platform. For details, see Platform Delivering a Command.
   • If the device has received the command, ensure that the device responds to the platform within 20 seconds after receiving the command (however, there is no time limit on a device's response to a message delivered by the platform), and the upstream topic and message body of the response are correct. Otherwise, an error will be reported by the API. request_id is carried in the downstream message.
3. For asynchronous command delivery:

   Check the value of input parameter send_strategy to see if the command is delivered immediately or cached before delivery.

   • Immediate delivery: The device receives the command immediately if the device is online.
   • Delayed delivery: The device receives the command only after the device reports data.

Can a Command Be Successfully Delivered When the Device Is Abnormal or Offline?

If the command is a synchronous one, the delivery will fail.

If the command is an asynchronous one and the input parameter send_strategy is set to delay, the command will be cached and will not be delivered until the device reports data or goes online.

Why Does a Command or Properties Delivery Always Time Out?

When you call an API to deliver commands or properties or to query properties, the intended device needs to respond in a timely manner. Otherwise, the delivery or query times out.

Does the IoT Platform Support Asynchronous Command Resending?

Yes, the platform supports asynchronous command resending. If the platform does not receive an ACK message after sending an asynchronous command to a device, the platform resends the command after 10s to 15s. You can see when the command was sent on the IoTDA console (to be specific, choose Devices > All Devices in the navigation pane, click View in the row of a device, and choose the Commands tab page). If the platform still does not receive an ACK message from the device, the platform resends the command after 20s to 30s, and tries again another 40s to 60s. 80 to 180 seconds after the preceding attempts, if the platform still does not received an ACK message from the device, the command status changes to Timed out.

What Are the Command and Message Statuses on the IoT Platform?

Command Status for Devices That Use LwM2M over CoAP

The figure below shows the conversion between command statuses.

Figure 6 Command status conversion

Message Status for Devices That Uses MQTT

• PENDING: The platform has cached the message because the device is offline.
• TIMEOUT: The message has been cached on the platform for more than 1 day and has not been delivered.
• DELIVERED: The message has been delivered to the device.
• FAILED: The message fails to be delivered to the device.

The figure below shows the conversion between message statuses.

Figure 7 Message status transition

Can the IoT Platform Deliver Commands in Batches?

Yes. An application can deliver commands in batches by calling the API for creating a batch task.

Commands delivered in batches are pending commands.

What Do I Do If Calling Synchronous APIs Failed or Timed Out?

Generally, synchronization command delivery times out because a device does not respond within 20 seconds. Use a physical device or simulator to simulate response reporting (Response to Synchronous Command Delivery, Response to Property Modification Request, or Response to Property Query Request). Note that the value of request_id in the response reported by the device must be the same as that delivered by the platform.

Why Only One Command is Successful and the Statuses of Other Commands Are Sent When I Deliver Multiple Commands to an LwM2M Device?

Commands are asynchronously delivered to LwM2M devices one by one. After the response of the previous command is received, the next command can be delivered.

Why Did an NB-IoT Device Keep Receiving a Same Control Command from the IoT Platform?

After receiving a command delivered by the platform, the device must return an ACK response to the platform. Otherwise, the platform considers that the command has failed to be delivered, and delivers the command repeatedly until it receives the ACK response or the command expires.