I have a built a nice little Cloud project with an R4 and it works perfectly for a while then the device falls off the cloud (disconnected). In this circumstance I would really expect the built in Cloud libraries detect this and to retry the connection silently and bring the device online again. However, this does not seem to be the case.
I've tried a number of approaches (conn.check disconnect callback.....etc) to handling this disconnect in my own code but so far I've no working way to detect the issue and reconnect. The device has not crashed and is still performing its function its just no longer connected to the cloud.
What is the best practice way to stop your Arduino Cloud device falling off the cloud and not coming back by itself? I'm getting very fed up of a hardware re-boot every couple of days. This is seriously undermining the usability of the the otherwise very simple to use Arduino Cloud.
Hi @ianw38543. I recommend leaving the UNO R4 WiFi board connected to your computer with a USB cable and running a serial terminal program. The Thing sketch will typically print some logs about the status of connectivity to the Wi-Fi access point as well as to the Arduino Cloud servers.
When a Thing sketch is generated, a line like this is added to your sketch, which allows you to control this logging behavior:
/*
The following function allows you to obtain more information
related to the state of network and IoT Cloud connection and errors
the higher number the more granular information you’ll get.
The default is 0 (only errors).
Maximum is 4
*/
setDebugMessageLevel(2);
The default level 2 is reasonable to get started on the investigation but you can increase the level in order to get more detailed information about the problem.
Since it sounds like the occurrence of the fault is on the order of days, I'm doubtful that the Serial Monitor feature of Arduino Cloud will be suitable. If you have Arduino IDE installed, you can try using its Serial Monitor (which is a little bit more appropriate for this use case of long term logging), but best would be to use a standalone terminal. I can recommend the free open source PuTTY terminal:
Thank you, that all makes sense. The device is installed in and managing my Darkroom environment so its not so easy to hook things up to. I had considered adding an SDCARD to spool out my logs, but I can try putty as it wont require dismantling the installation. The monitor is pretty useless over the time frame of the problem as you surmise although I have had tried this. Its either some kind of resource running out or some kind of failure in the networking. I fairly sure of the latter as the local operation of the device continues. Probably it would be useful if the essentially autonomous R4 device had a local rolling log cache that could be dumped on restart. Maybe a feature for R5 (-:
It is a bit more complex because you would need to add code to the sketch to log to the SD card (while the sketch already logs to serial), but otherwise it is an excellent idea!
I recommend PuTTY because it is the best terminal I have found that meets my requirements of being cross-platform and open source. However there are definitely some other nice terminals that are either operating system-specific or closed source but still free so if for some reason PuTTY doesn't meet your needs, you should be able to find some alternatives to try.
I think it is possible to do this. You can see some demonstrations of writing data to the flash memory in the "Preferences" library examples (though I'm not sure whether the key-value based data structure used by that library is well suited to this specific use case).
If you are going to do something like this, keep in mind that the flash memory has a limited number of write cycles so you should avoid a program configuration that writes excessively. The flash is rated for something like 100000 cycles so you don't need to worry at all about the impact of occasional writes. There are probably some other libraries available to help with this.
This is an update on this issue. I have now been able to trace the system while operational until it falls off the cloud. Since my previous post I've upgraded the Aurudio firmware (0.4.1) but this has made no difference to the issue. This is what I have learned so far:
The problem appears to begin with the loss of the wifi/internet connection which is detected.
The connection handler Conn.Check(); knows the connection is down and tries to reconnect,
it does this every 500ms for about 30 times before my main loop code runs again about once every 10 seconds, and then the whole thing just keeps repeating. So my device is working but cant bring its-self back online as I suspected. It keeps logging:
Retrying in "500" milliseconds
Connection to "xxx" failed
The laptop I'm tracing to has reconnected to the same wifi network by itself, and if I reboot the R4 it will reconnect.
So the problem seems to be that the connection handler is unable to get the on board ESP to reconnect. This appears to be either a problem in the ESP firmware or the connection handler library code.
I have seen online that on other Arduinos support an ESP.reset(); or ESP.restart(); command. I'm wondering if I can do this in my code if I can avert the problem of getting stuck offline. This is not fixing the real cause of the problem but might give me a way out.
Since the disconnect is picked up in my NetworkConnectionEvent::DISCONNECTED routine this would seem the logical place to reset the ESP. Doing this on every disconnect should not be necessary but it might fix my problem. (I've already tried calling connectToWiFi(); with no luck)
How can I reset the on-board ESP on the R4? should I reset or restart? Any suggestions or alternative approaches appreciated.
My latest version calls NVIC_SystemReset(); (to reboot the whole R4) in the NetworkConnectionEvent::DISCONNECTED callback. This is looking promising, but is a terrible way to solve the issue. I still would like to get to the bottom of this so that whatever the underlying issue is can be properly handled (and fixed for everyone in a library update). I'm hoping someone will post how to cleanly reset/restart the ESP32 and the wifi and Aurdio.Cloud layers without re-booting the whole thing. I have tried writing AT+RST to serial2 but did not have much success (may not have done this correctly) An alternative next step would be to try to debug deeper into the ESP communication to get closer to the root cause.
void doThisOnDisconnect(){
/* add your custom code here */
WiFi.begin(SECRET_SSID,SECRET_OPTIONAL_PASS);
}
Without the code above, the R4 Wifi gets disconnect and does not reconnect when I reboot my router.
With the code it does come back online nicely after a router reboot 8-).
Thanks I will try WiFi.begin(SECRET_SSID,SECRET_OPTIONAL_PASS); alone. I had tried calling my connecttoWifi() which includes this line with out much joy. I'll let you know how it goes.
Well less than 24hrs and its offline again. I'm afraid that just doing wifi.begin has not worked for me. The R4 is back in the loop described above... so for now I'm reverting to the reboot code and I'll see how it survives over a longer period.
I'm still looking at this. There really needs to be an improvement to the connectionhandler library. .check know there's a problem but fails to fix it. I'm also not convinced all disconnections are signalled to the call back routine.
I have been thrilled with the utility and ease of getting my projects online. But early on in my project of greenhouse control beginning in May 2024, both "devices" Arduino R4s would daily disconnect and I would have to reboot them. Without changing the code at all that no longer happens. I had tried several of the software fixes without success.
Is this a known issue that has been corrected on the Arduino Cloud end?
For those interested, the reboot in the code I described above works most of the time but I really would like to see the Arduino team address these issues properly as I'm still having offline episodes.
Recently, I have a new problem that the cloud is showing my device status as online, and last time seen as more than 24 hours previously, the variables are not updating and it clearly stuck offline. A hard reboot of the device immediately solves the issue. While this new issue is probably a cloud issue. I think the code supporting the on board Wifi really needs some attention before reputational damage occurs. Whether this is a library update or just example code that's rock solid, it doesn't matter, uptime connectivity just needs addressed please.
I am getting exactly the same condition cloud showing online yet no data is being received or sent. The device is working fine it is just not reporting data. Rebooting gets it all working again.
Very frustrating…
I still have the same problem. But now I have observed, that exactly after 14 days (at 2 p.m. exact on the minute) the connection was "lost". I assume that it was not a connection problem, it was done by the system after exact 14 days. All functions worked proper, only the data connection to the cloud stopped!
Do you have the same?
I’ll trace it now again and guess in exact 14 days I’ll have the same.
Keep you updated.
