Thanks for the info, @ScruffR.
I was hoping it would be possible to trigger the re-connection from the cloud side.
My applications (maybe for most users) involve hard to access devices, so maintaining remote connectivity is critical. I am focusing a lot of effort to understand how to make the device as robust as possible.
Unfortunately there is no way to know what the LED did at the time; device is locked up in a panel 200 miles away. Not so easy to reset the device either.
That’s definitely a possibility. But loop() is still running, as the device never stopped logging periodically.
Oct 19 10:56:19 27001c000d47353136383631 [app] WARN: -- MARK --
Oct 19 11:04:47 27001c000d47353136383631 [app] WARN: -- MARK --
Oct 19 11:13:15 27001c000d47353136383631 [app] WARN: -- MARK --
Oct 19 11:21:43 27001c000d47353136383631 [app] WARN: -- MARK --
I have tested the code below to deal with cloud connection loss; I would prefer not to continuing to run the code while trying to reconnect.
// attempt reconnect if cloud connection lost
if ( !Particle.connected() )
if ( reconnTry++ == 0 )
CloudLostMillis = now;
deltaCloudLostMillis = 0;
rc = CONN_LOST;
// attempt reconnection
// reconnection attempts timed out --> system reset
if ( deltaCloudLostMillis > RECONN_TO_MS )
*resetReason = PARTICLE_TO;