I cannot make my Opta reliably connect to the Arduino cloud. Usually I get this console error:
ArduinoIoTCloudTCP::handle_ConnectMqttBroker could not connect to iot.arduino.cc:8883 Error: -2
Exactly what error does the "-2" represent?
I tried the other solutions from the forum but I couldn't get it working. According to the Thing log it had about 5% uptime yesterday. I'm using the simplest code possible, from the online OTA example, except I select "Ethernet" in order to use the hard-wired Ethernet port. OTA has worked sometimes, and even the dashboard worked on occasion with a simple boolean input & output.
Is there a certain sequence of power-up and cloud service startup required? Does the Opta or cloud software simply not auto-recover if there's a connection hiccup? Any help would be great.
Hi @conpewter, -2 error in mqtt client stands for connection refused by the server, have you correctly provisioned the board from ArduinoCloud? this may happen if the certificates are not present on the board. Can you try to delete the device and recreate it?
If the correct certificates are not present on the board, how would it occasionally work?
I figured out that the refused connections would only occur after a soft reset when loading new software, either through the IDE or via OTA, and would also keep occuring after the cloud watchdog forced a reset. I was blaming my software but noticed that the reset button or a power reset would almost always fix the issue. I get continuous uptime after a good reset
So the refused connections occur 90% of the time immediately after a soft reset, and stay that way. Good connections occur 90% of the time after a hard reset, and also stay that way.
I haven't dug further into what's going on. Could there be a memory area that's not getting cleared, such as something to do with the server handshake and/or SSL?
Given the above, let me know if I should still try recreating the device.
Then can be related to the certificate storage, these kind of issues are hard to replicate since we need to find a way to corrupt the fs. Are you able to use a custom core? So that I can prepare a patch for you to verify if that is the case.
can you apply my fork? This adds some debug messages on the ssl client and help us to understand where the issue is. I suspect it may be an fs corruption problem.
you can follow this guide to install a custom core version
The connection problems occured with ArduinoCore_mbed 4.1.3, but since updating to 4.1.5, I cannot make the problems occur. It seems there were a few changes made that are crash/blocking/lockup related, and perhaps that fixed the problem. Reverting back to 4.1.3 causes the startup problems to occur again. I see your core fork is based on 4.1.5 or newer, so is there something you would still like to see if I try the new core?
(I was confused for a bit because the version numbers of the libraries, such as Ethernet, within core 4.1.5 have not changed from 4.1.3, even though the source code has changed. Those library version numbers need to be maintained or discarded, imo. On top of that, the cloud editor is still using core 4.1.3, which explains why the cloud editor USB & OTA uploads were still locking up while the local IDE USB uploads were working fine.)
[edit] To be clear, updating ArduinoCore_mbed to 4.1.5 fixes the cloud connection problems that occurred after most soft-resets.
Happy to hear that this fixed you issue. We usually wait some time, before releasing a core also in the cloud, this 4.1.5 was released just few days ago, we are releasing it on Monday on the cloud editor. The 4.1.4 had a bug that we didn't notice so we didn't release it on the cloud editor. I don't need to try anything since the issue was solved. Thanks for your report!