There are many causes of device connection failures; for example, the connection between the device and the cloud network is unavailable, device authentication fails, or the connection times out due to poor Wi-Fi signal. You can troubleshoot accordingly based on the type of the error log in the SDK during device connection. Generally, you can troubleshoot in the following steps:
/* default MQTT/CoAP timeout value when connect/pub/sub (unit: ms) */ #define QCLOUD_IOT_MQTT_COMMAND_TIMEOUT (5 * 1000)
DeviceSecret) are all correctly configured, you can check whether the system time of the device is correct; for example, you can run
adb shell dateto view the system time of an Android device.
The IoT access layer has the logic of exclusive device login. If the same device ID is logged in from another place, the existing login will be kicked offline by the new login. Therefore, if the device keeps going online and offline, you can check whether there are different users or threads performing login operations by using the same device ID.
You can configure device status change notifications in the message queue of the product information. Then, device status change notifications will be pushed to the corresponding message queue.
Generally, there are the following causes:
TIMEOUTevent is received in the
sampleevent callback function for you to troubleshoot the problem.
When you use the device SDK to establish an MQTT connection, if automatic reconnection is enabled (which is enabled by default) in the initialization parameters, the device will automatically reconnect. The
Yield function in the SDK will determine the network connection status based on whether the message sending/receiving and heartbeat packet behavior are normal. If the connection is interrupted, automatic reconnection will be performed. In addition, to avoid frequent reconnection when the network fails, the SDK reconnection interval changes exponentially from the minimum value; that is, if reconnection fails again, the interval will be doubled. If the reconnection interval reaches the maximum value but reconnection still fails, a reconnection timeout error will be returned.
If the connection is manually interrupted in ways such as actively calling the
Destroy function, automatic reconnection will not be performed.
The default setting of the maximum reconnection interval is in qcloud_iot_export_variables.h:
/* MAX MQTT reconnect interval (unit: ms) */
If an error occurs during compilation with remote dependencies, it is probably because that the remote library has not been updated in time. You can modify the dependency method to local dependency in the
We recommend you do the following:
getaddrinfosystem function assigns a large amount of memory for IPv6, and if the SDK only uses IPv4, you can consider optimizing the memory assignment operation by
getaddrinfo, which reduces the RAM usage.
MQTT uses persistent TCP connections and needs the heartbeat packet mechanism to ensure that the connection is active. The device C-SDK follows the keep-alive mechanism in the MQTT specifications. qcloud_iot_export_variables.h contains the default setting of the heartbeat packet sending cycle:
/* default MQTT keep alive interval (unit: ms) */
In a heartbeat sending cycle, if the device does not successfully send the MQTT control messages (including
QoS 1 PUB messages) and receive the corresponding ACK messages, it will send
MQTT PINGREQ to the cloud and wait for the cloud to return a
PINGRESP message. If the device does not receive the
PINGRESP message in a certain period of time, it will deem the connection interrupted and perform automatic reconnection.
Currently, IoT Hub supports MQTT QoS 0 and QoS 1 but not QoS 2. For a QoS 0 message, after the
Publish function is called and returns a success, the device will use the TCP/IP protocol stack to ensure the message delivery, and the SDK will not implement subsequent processing. However, for a QoS 1 message, the SDK will maintain a message status queue, further track and give a response based on the MQTT PUBACK message, and inform you of whether the QoS 1 message has been successfully delivered or failed due to timeout in the corresponding event callback. Then, you can determine whether to send the message again.
Yieldfunction in the device C-SDK do?
Yield function is used to perform tasks such as reading MQTT messages, processing messages, timeout requests, and heartbeat packets, and managing reconnection status in the current thread context. It is an important step for devices to perform IoT communications over MQTT. In a single-thread single-task scenario, this function must be called and executed in your logic code loop. In a multi-thread multi-task scenario, you can use an independent thread task to execute this function and set a certain thread priority to prevent the thread from being suspended for a long time. For directions on how to use this function, please see the corresponding code sample.
Yes. To use MQTT APIs in a multi-thread environment, you need to pay attention to the following. For more code samples, please see
IOT_MQTT_Yieldshould have a certain execution time to prevent it from being suspended or preempted for a long time.
Starting from v2.3.1, the device log reporting feature is available in the device C-SDK, which can report the device operation logs to the cloud over HTTP and display the logs in the console for you to remotely diagnose and monitor the device status. As log reporting uses an independent communication channel, remote diagnosis can be performed even when the network communication is normal but the MQTT connection is abnormal.