Photon set Particle.connect() Timeout?

I am attempting to set a timeout for the Particle.connect() function. If Photon is unable to connect to the WiFi within 15s, I want to stop the connection service so user application code can be executed normally. (I would prefer to have SYSTEM_THREAD remain DISABLED)

With the code below, if Particle.disconnect() is called while Photon is attempting to connect, the approximate behaviour is that execution of the code in loop() takes approximately 20 times longer.

Are there any other solutions?

ApplicationWatchdog wifiWatchDog(15*1000, wifi_disconnect);
unsigned long last_wifi_connect_ms = 0;
unsigned long wifi_reconnect_delay = 15*1000;

void setup(){


  "Some Other Code"

void loop()
  last_wifi_connect_ms = millis();
  if(!Particle.connected() && (millis() - last_wifi_connect_ms > wifi_reconnect_delay || last_wifi_connect_ms < wifi_reconnect_delay)){
    Serial.printf("\nReattempt WiFi Connection\n");
    if (wifi_reconnect_delay < 4*60*1000){
      wifi_reconnect_delay *= 2;
      wifi_reconnect_delay = DEFAULT_WIFI_RECONNECT_DELAY;
      Serial.printf("\n WiFi Connected\n");
 "Some Other Code"

void wifi_disconnect(){
  Serial.println("\nWiFi Discounnected\n");

Any reason for that?
Are you using non-AUTOMATIC mode?
Have you tried a software timer to call Particle.disconnect()?
You can also check WiFi.ready() before trying to connect to the cloud.

The application code has been written with single threaded in mind. Having SYSTEM_THREAD ENABLED may cause some issues.

I am using SEMI_AUTOMATIC mode.

I did try using Particle.disconnect(). The result is it takes like 20 times longer to execute the code in loop() if Particle.disconnect() is called while Photon is attempting to connect.

According to Particle Doc, WiFi.ready() " will return true once the device is connected to the network and has been assigned an IP address. Otherwise, it will return false ." I’m not quite sure how that helps before connect to the cloud. Could you please elaborate?

That wasn’t there originally :wink:

The actual cloud connection should take about one second when the device is already connected to the WiFi network.
Particle.connect() wihtout being connected to WiFi first will implicitly take all the prerequisite steps but keep blocking for the entire process. If you break that up into individual steps your code will stay in charge more and can be more granular in deciding when to do what and how lown you’d be prepared to wait for the sub-steps.

“may cause” shouldn’t be the excluding argument.
I cannot really see a lot of cases where the occasional waitFor() statement sprinkled in would help pre-/circumvent any issue.

If I understood correctly, should I call WiFi.connect() then Particle.connect()?

What’s the differences between WiFi.connect() and Particle.connect() other than one connects to WiFi while the other one connects to Particle cloud?

Is there any secret system function that would check for the availability of WiFi networks stored in Photon?

As indicated above Particle.connect() - when called without any prerequisite calls - will internally call WiFi.on() and wait, WiFi.connect() and wait and finally do its own cloud connect stuff including DNS resolution, finding the “nearest” Particle cloud server and then connect to that.

WiFi.connect() will only call WiFi.on() (when needed) and wait and then connect to the local WiFi AP to acquire an IP - that’s it.

No, no secret function …

… but there is a clearly documented one here

And in combination with WiFi.scan() you can correlate the stored networks with the currently available ones.

Thank you! WiFi.getCredentials() and WiFi.scan() is the solution that I’m looking for.

1 Like

If photon was already connected to the cloud, if the WiFi signal disappears, photon automatically attempt to reconnect(Signal light flashing green). Is there a way to disable that? I have tried to use Particle.disconnect() and WiFi.disconnect(), none of which can stop photon from keep reconnecting(Signal light flashing green).

Are you sure you want that?
You may have very brief WiFi “outages” (e.g. regular IP release) that automatism would overcome without too much interruption, but if you disabled the auto-reconnect you’d have to deal with all of these in your code too.

But if you want to take things in your own hands, you should use SYSTEM_MODE(MANUAL), SYSTEM_THREAD(ENABLED) and subscribe to the relevant system events

The thought of wanting to manually control the WiFi that is because after WiFi signal has been lost, probably due to resources used by re-connection, loop() is called by the system approximately once every 40 seconds under my current application code, which is way too long.

Furthermore, from my own tests, the description under System Threads Enabled differs from the actual behavior.
Below is the documented behavior:
System mode `AUTOMATIC` mode connects to the cloud as soon as possible. Neither has an effect on when the application `setup()` function is run - it is run as soon as possible, independently from the system network activities, as described above.
The behavior that I have encountered was:
System mode `AUTOMATIC` mode will attempt to connect to cloud ASAP and setup() is block even if SYSTEM_THREAD has been ENABLED

I can’t confirm that.
What device OS version are you running?
Can you provide the particle serial inspect log of your device?

Device OS v1.0.1

I have tested with 1.1.0 and 1.2.1-rc.2 and also know that SYSTEM_THREAD(ENABLED) did in earlier versions, although I can’t vouch for 1.0.1 explicitly.

Can you also provide some test code to test on the same basis?