I've got a recurring problem with devices loosing connection to the Arduino cloud. They usually run fine for random amount of days and then suddenly stop. Pushing the reset will have it up and running again.
I've caught the following debug info when the devices are stalled:
ArduinoIoTCloudTCP::handle_SubscribeMqttTopics could not subscribe to /a/t/"MY-UID"/e/i
My program is still looping but it never succceds in reconnecting to the cloud.
I have a slight suspicion this could be related to my MKR-board having being mapped to different Arduino.cc accounts in the past but I've done what I can to remove it from old accounts.
I've tried updating the Nina-firmware to the latest (1.3.0)
Hi Patrik, I'm facing exactly the same issue since yesterday too. However, my MKR-board has never been mapped to any different Arduino.cc account... Let's see if someone can help us.
I've been having similar problems for the last couple of days with a MKR WiFi 1010 that was working fine with the Arduino IoT Cloud last week. Even a simple "button push" application based on the example templates fails to update a property on a dashboard on the Arduino IoT Cloud, whereas it worked fine last week.
On the serial console, I see the expected output: "Connected to ", "WiFi status 3", "Connected to Arduino IoT Cloud" but nothing further from the ArduinoCloud library -- no error messages or further status updates -- even when I change setDebugMessageLevel to 4. The device side of my application continues to run fine, with my button presses and releases reflected on an LED in software, so it seems that it's the transactions with the Arduino IoT Cloud that are disappearing silently into a hole.
I wonder whether this is a current issue with the Arduino IoT Cloud. Oddly, despite not updating, my linked property on the IoT Cloud dashboard always shows as having been refreshed "within the last few seconds" and yet my MKR WiFi 1010 device shows as "offline" under the Devices tab. Another oddity is that a "ping" to mqtts-sa.iot.arduino.cc currently returns 100% packet loss, whether sent from my board, a separate PC or different IP addresses on distant networks. Unless it's been deliberately configured that way, that suggests to me a broken connection within the Cloud.
I'd be curious to hear whether others are having similar experiences and whether my observations above are relevant or "red herrings".
... and now it's working again! I didn't change anything -- just powered up the MKR WiFi 1010 board with the serial monitor running. At first, I received a continuous stream of error messages:
***** Arduino IoT Cloud - configuration info *****
Device ID: <MY-DEVICE>
Thing ID: <MY-THING>
MQTT Broker: mqtts-sa.iot.arduino.cc:8883
WiFi.status(): 0
Current WiFi Firmware: 1.4.1
Connected to "<MY_SSID>"
ArduinoIoTCloudTCP::handle_SubscribeMqttTopics could not subscribe to /a/t/<MY-THING>/shadow/
Check your thing configuration, and press the reset button on your board.
ArduinoIoTCloudTCP::handle_SubscribeMqttTopics could not subscribe to /a/t/<MY-THING>/e/i
Check your thing configuration, and press the reset button on your board.
:
(repeated indefinitely)
:
ArduinoIoTCloudTCP::handle_SubscribeMqttTopics could not subscribe to /a/t/<MY-THING>/e/i
Check your thing configuration, and press the reset button on your board.
(Obviously, I've substituted , and for the true values above)
When I pressed the reset button on the board, the device started up again as above, but without any error messages this time. When I checked the property in my dashboard on the Arduino IoT Cloud platform, the property was being updated correctly as before when it was working.
It's fairly clear to me from the above results that the only element that could have changed since yesterday is the Arduino IoT Cloud. Any ideas on what's been happening?
Incidentally, I just tried a "ping" to mqtts-sa.iot.arduino.cc -- it still doesn't respond, even with my IoT Thing communicating correctly with the Arduino IoT Cloud. I therefore assume that was a "red herring", and that ping responses have been disabled from the relevant server.