WiFi.connecting() returns false after WiFi.connect()?

Troubleshooting
1

I am using a photon running 0.8.0-RC.11 SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED).

In my setup() function I am switching wifi on then checking the number of stored credentials and then calling WiFi.connect(). At this point I have been using a while-loop(WiFi.connecting()) to provide a timeout. However, this appears to return false and thus my timeout loop never runs and the check after that if(!WiFi.ready()) is true. The network connection error code returned at this point is -29. The log trace indicates that it spent 2 milliseconds between WiFi.connect() and the error code output after if(!WiFi.ready()).

I have removed the while(WiFi.connecting()) and implemented waitFor(WiFi.ready, timeout); instead - this works as expected.

Why is the WiFi.connecting() returning false and what does -29 mean?

2

How long do you allow for WiFi.connecting() to become true before checking?
Since there are two HW devices involved in the process some asynchronicity is to be expected which may cause the lag between initiation of the process and the feedback about the fact.

3

@ScruffR Pretty much immediately. See the code snippet below:

WiFi.connect();
Log.trace("wifiOn() called connect");
While (WiFi.connecting()) {timeout checked here}        //now replaced with waitFor(WiFi.ready, timeout);
if (!WiFi.ready() && hasStoredCredentials)
{
     errorno = getNetworkConnectionError();
     Log.trace("wifiOn() failed connection error %i", errorno);
}

BTW, is WiFi.off() the only way to stop the search for networks once WiFi.connect() is called?
Is this what the WICED error code means? NO_STORED_AP_IN_DCT -29 It wasn’t ready?

Is the rewrite of the IP stack as mentioned by Will Hart meant to sort out this fiddlely API with the WIFI module?

4

Try adding a delay(10) or so between.

I haven't tried but if it's anything like Particle.conncet() then WiFi.disconnect() should be preventing any further attempts - it might not actually end a currently running one tho'

This could be a race condition.

Not sure, since the WiFi management is a lower layer (1/2) than the IP (3) stack.