How to properly reconnect an Electron to the cloud

Troubleshooting
1

Hi all,

There are couple different ways to reconnect a device (Electron) when the Particle cloud disconnects. We would like to know the most appropriate/best method in order to reconnect a device after disconnecting from the cloud.

Setup:
We are running and Electron in manual mode and with system threading enabled.

Pseudo-Code
Our pseudo-code that we have currently for reconnecting an electron (this function is called in loop() that runs at 1 Hz):

reconnect():
     if particle is not connected:
         particle connect
         failedConnect++
         if failedConnect > 3:
             system reset
     else:
         failedConnect = 0

Our team thinks this may not be most appropriate method in order to reconnect a device after losing connection. Are there any steps that we are missing or is there is a better way to reconnect a device?

Thanks,
Jeff

1 Like
2

As established by @ScruffR here:

 Particle.connect();
  if (waitFor(Particle.connected, 60000)) {
    // connection established within 60 seconds
    // procede
  }
  else {
    // no connection 
    // act appropriately depending on your use case
  }

is an elegant means of establishing whether or not a cellular device is connected, with a sufficiently long timeout, in MANUAL mode.

However, the question of what action to take upon that else condition is contingent upon both your use case and, more importantly, the type of connectivity error you may be experiencing. A reset may be sufficient in some cases, but I’m curious to learn why your device is unable to sustain its cloud connection.

1 Like
3

Thank you for the reply.

The issue of our devices being unable to sustain a cloud connection is still an ongoing (couple weeks long) ticket so I don’t have a answer yet.

We will issue a longer waiting period for the reconnect function as suggested and determine if the device reconnects.

Thanks,
Jeff

1 Like
4

Sorry I missed the part about cellular, in the original thread - in that case the cell connection can even take up to 5 minutes (300000ms).

2 Likes
5

According to the documentation: “After you call Particle.connect(), your loop will not be called again until the device finishes connecting to the Cloud. Typically, you can expect a delay of approximately one second.” Will the connect function be a blocking call for the entire 5 minutes or just the ~1s? Using the waitFor() function as mentioned, it seems like it will not be blocking.

When using the particle.connect(), is it best to call it once and continue our loop (with no particle functions) for the 5 minute period or can we call it once a minute without resulting in any problems? We don’t want any blocking calls (if possible) in order to continue reading external electronics and possibly send data at a later time after re-connecting.

6

This is true for the default SYSTEM_MODE(AUTOMATIC) without SYSTEM_THREAD(ENABLED) but for non-AUTOMATIC and/or SYSTEM_MODE(ENABLED) it's not.
Hence the proposed approach will work in all cases. For the default mode the check will immediately return true (as the connection was already established before even getting there) and for the other scenarios the required waiting time will be added as needed (up to the stated max period).

If you want to have your code execute while a connection attempt is ongoing, then you may need to go a slightly different route but make sure to not call Particle.connect() again while a previous attempt hasn't finished.
Also be aware that the communication with the cellular modem will always impact overall performance of the system and hence you'll see some blocking.

2 Likes
7

How can one determine if a previous attempt has finished, mainly attempt failed?

8

I’d use something like this

const uint32_t CONNECTION_TIMEOUT = 300000;
uint32_t       msLastConnection   = 0;

  if(!Particle.connected() && (!msLastConnection || millis() - msLastConnection > CONNECTION_TIMEOUT)) {
    Particle.connect();
    msLastConnection = millis();
    // some other prep stuff
  }
2 Likes
10

That should also work.
However, I’d write switch(failedConnect++) and do away with all these other failedConnect++; lines inside that switch block.

1 Like
11

Good call, thanks for your help!

12

Why did you remove the working code above? Doesn’t it work?