Cloud reconnect in SYSTEM_MODE(MANUAL)/SYSTEM_THREAD(ENABLED)

Having trouble when cloud connection is lost. Photon appears unable to reconnect to cloud.

Running in SYSTEM_MODE(MANUAL) and SYSTEM_THREAD(ENABLED).

Everything works great under these conditions:

  • Manual connect to cloud via Particle.connect()
  • Cloud connection stays alive nicely via frequent calls to Particle.process()
  • If WiFi network goes away (e.g., power down of WiFi Access Point we’re connected to), and then comes back (e.g., WiFi Access Point is powered back up), the Photon magically reconnects to the WiFI and then the cloud, without any special intervention from the application code. (Nice!)

However, in the following scenario there is a problem:

  • If the WiFi network connection stays up, but the Internet connection beyond the Access Point goes down (or perhaps is running very slow), then the cloud connection dies (makes sense) (Particle.connected() returns false, but WiFi.ready() returns true)

  • Yet, when the Internet connection beyond the Access Point returns, the cloud connection doesn’t restore. (i.e., Particle.connected() continues to return false). Not automatically, not with attempted intervention via various reconnect call sequences from application code. Have tried application code call sequences such as: WiFi.disconnect(), WiFi.off(), Particle.connect(); as well as just Particle.connect().

I haven’t been able to find any application code call sequence I can make that will get the cloud connection back once it fails like this. The only way I’m able to get the cloud connection back is to power cycle the whole system (at which point it connects fine to the cloud).

Running firmware 0.6.2

How can I make the cloud connection reconnect when running in SYSTEM_MODE(MANUAL) and SYSTEM_THREAD(ENABLED)?

Just for completeness, could you add a Particle.disconnect() call to your scenario - e.g. one Particle.connected() goes false?

Thanks for the idea, @ScruffR. Added that, but no luck. Tried sequences such as:

Particle.disconnect()
Particle.connect()

Particle.disconnect()
WiFi.disconnect()
Particle.connect()

Particle.disconnect()
WiFi.disconnect()
WiFi.off()
Particle.connect()

No luck. ;(

Adding some delay between switching off/disconnecting and trying to reconnect would be good too
e.g.

  if(!Particle.connected()) {
    Particle.disconnect();
    Particle.process();
    WiFi.off();
    for(uint32_t ms = millis(); millis() - ms < 500; Particle.process();
    Particle.connect()
    waitFor(Particle.connected, 30000);
  }

Especially the waitFor() (or any similar strategy) is important since calling Particle.connect() - which is non-blocking (!) - while another connection attempt was already running will permanently knock back the connection and hence counteract the actual goal.

I was having similar issues. Being in sleep mode, my Photon would not actually try to connect after a Particle.connect() call. What did the trick for me was to call WiFi.on() first followed by a Particle.connect() call. This did the trick and made the Photon actual try to connect to the network (RGB blinks green).

I am not sure if Particle.connect() already turns on the WiFi radio in case it’s off, but this worked for me.

I tried adding the delays as you suggested, @ScruffR. It seems like that may have made some improvement. Based on some limited testing, it seems like it is now capable of reconnecting in some situations. It seems like it has success if the network comes back relatively quickly (like within the first two or so 30 second retry sequences). However, if it takes longer for the network to come back (for example, 4-5 minutes = ~8 30-second retry sequences), then it is not able to reconnect. Other ideas?

If you have WiFi connection but no cloud available you could try to ping some internet address to test for connectivity before issuing the Particle.connect() - if it’s not there, don’t try to connect.

But all of this (including the explicit WiFi.on() suggested by @morduno) should not be required - Particle.connect() should do it all .
@rickkas7, this should be addressed by Particle IMHO.

1 Like