I am running an ESP32 Direct Connected device with STDK v2.3.2.
The device has been working fine with the same code and environment, but since yesterday it has been repeatedly restarting.
After analyzing the logs, I found that if a PUBACK for a QoS1 PUBLISH sent immediately after MQTT cloud connection is not received within 12 seconds, _iot_mqtt_chunk_expire_timeout fires and the SDK calls esp_restart().
I (57368) ST: status: cloud_connected(6)
I (57178~57948) [IoT]: st_cap_send_attr > publish event (seq 1~10)
W (67598) [IoT]: _iot_mqtt_process_received_publish > duplicated PUB packet 6600
I (69388) [IoT]: _iot_mqtt_chunk_expire_timeout > Timeout
I (2827) [IoT]: esp_ip_event_post_to_user > got ip ← restart
This started happening without any code changes, and around the same time I noticed the SmartThings Developer Console was returning 500 errors.
I suspect there may be an issue on the server side that is preventing PUBACK from being processed properly. Could you please check if there is anything wrong on the server side?
Hi, @JohnJo
Since you mentioned this started after the 500 issue.
Can you help us confirm this issue remains, please? The other one is solved, as mentioned in this thread:
Thank you for confirming that the issue has been resolved. I tried again and can now access the Product page without any problems.
We are currently preparing for WWST certification, and once certified, we plan to ship a product with the SmartThings SDK built in. For that reason, I’d like to understand the nature of the issue that was just resolved a bit more precisely.
What exactly was the issue that was resolved?
The Product page access error occurred about three times this month, each on a different day. Was this a temporary server-side outage, or was it caused by an update that was in progress?
Is it related to the MQTT connection issue on the device side?
During the same period, our test device connected to SmartThings showed a recurring behavior: it logged that it had not received a PUBACK from the server, after which the SDK performed an esp_restart and kept retrying the connection. I’m wondering whether this MQTT-side symptom shares the same root cause as the console issue that was just resolved, or whether it’s a separate matter.
Impact on production (certified) devices
My understanding is that WWST-certified devices connect to the same production cloud/broker as test devices. If that’s correct, it seems a server-side issue like this would affect certified products in the same way — is that right? If this particular incident was limited to the test/development environment only, I’d appreciate confirmation of that as well.
Recommended resilience pattern
Even when the server is healthy, I believe a transient network drop could still cause a lost PUBACK. In that situation, is it the intended behavior for the SDK to reboot via esp_restart and repeat, or is there a recommended way to handle this by reconnecting without rebooting? This matters to us because a reboot loop like this would be a real problem for the user experience in a shipped product.
Our device repeatedly fails to connect to the SmartThings server. The MQTT connection itself succeeds, but the sign-in handshake right after never completes — the device logs GG connection fail after about 5 seconds, disconnects, and retries.
I (52207) [IoT]: iot_es_connect(1225) > MQTT connect success success/try : 1/1
I (52207) [IoT]: _iot_mqtt_listen_socket(1015) > Enter Socket listen thread
W (57227) [IoT]: iot_es_connect(1271) > GG connection fail
I (57237) [IoT]: st_mqtt_disconnect(1628) > mqtt disconnect 0
I (57247) [IoT]: st_mqtt_destroy(1213) > Waiting socket thread exit
I (57257) [IoT]: _iot_mqtt_listen_socket(1025) > Exit Socket listen thread
E (57357) [IoT]: _do_iot_main_command(745) > failed to iot_es_connect for communication try count 0 next after 2000 ms
I (57367) [IoT]: iot_set_st_ecode(1628) > update last_st_ecode (0) -> (20)
Since the MQTT broker connection and topic subscription succeed and only the server’s sign-in response times out, this looks like a server-side issue rather than a device or network problem. Could you please check whether there is currently a problem on the SmartThings server side?
This problem has continued for a week now. With the same firmware on the same device, it connects to SmartThings fine on some days and fails on others — sometimes even within the same day (no connection for ~3 hours, then it suddenly works and stays stable for the rest of the day). Nothing changes on the device or network side.
To be clear, I’m not reporting the earlier console 500 error — that’s resolved. The current issue is on the device-to-cloud connection side: the MQTT PUBACK-not-received restarts and the “GG connection fail” sign-in timeouts.
I’m not ruling out a problem in my firmware or STDK usage, but I need to understand the actual cause. Last time I only got “it’s resolved, please try again,” with no explanation of what was wrong — and now a similar problem is back.
Since I’m preparing for WWST certification and commercialization, I need to know whether this can also happen on production devices. At minimum: was this a server-side issue or a problem on my side? And if server-side, what was the scope — e.g., an outage in a test-related microservice that did not affect production?
Also, for context: I’ve been developing this Direct Connected device for 4 months now, and this problem never occurred during that entire time. It only started about two weeks ago. Was there any change on your side around that time that could be related?
We checked with the team regarding the previous 500 error. The issue was isolated to the web side and should not have affected device connectivity. The team also mentioned that there have not been any significant updates since the beginning of May that would explain multiple occurrences on different days.
Regarding the device restart behavior, we consulted the STDK team. Their guidance is that device restarts should generally occur only during a device reset or during offline self-diagnosis. Under normal operating conditions, if a connection is lost, the expected behavior is to reconnect rather than restart the device.
If the PUBACK/restart behavior continues to occur, please collect and share:
The complete device logs.
The timestamps when the issue occurs.
This information will help the team investigate the behavior further.
