WiFi.begin() restriction / override?

[kcbudd]

I was working on a little project where I'd like to have the oak connect to different WiFi access points in different situations.  I've run into a stumbling block, though, that's preventing me from using the ESP8266 functions that I need. 
 
At a prescribed time I disconnect from the particle cloud with Particle.disconnect().  I can scan the APs in the area with WiFi.scanNetworks().  If I try to include WiFi.begin(SSID) in my code, though, I'm stopped at compile-time with:

Code: [Select]

call to 'ESP8266WiFiClass::begin' declared with attribute error: You must use the WiFi config mode to change the Oaks network info.
Is this really something I cannot do, even if I accept the caveat that I'm overriding the existing Particle config and might not be able to get back on the particle cloud?  Is there any efficient programmatic way to utilize the ESP8266 WiFi connect functionality in the Oak?

[kcbudd]

So, first I tried removing the attribute error from ESP8266WiFi.h, only to discover that the relevant functions had also been removed from ESP8266WiFi.cpp.  d'oh. 
 
However, after reading the source, it turns out that this little snippet works just fine:

Code: [Select]

      WiFi.disconnect()
      WiFi.persistent(false);
      wstatus = WiFi.begin_internal(wSSID, NULL, 0, NULL);
(Where wSSID is a char* containing the SSID I'm interested in connecting to.)

It associates with the designated AP just fine.. I can communicate, and when I'm done I can just call WiFi.disconnect() again, and Particle.connect() returns it to it's original AP & config.  Yay!
(It should be mentioned that this is all in SYSTEM_MODE(SEMI_AUTOMATIC); )

[defragster]

That looks likes a good and generally useful solution that I and others might make use of.  If you posted an example piece of code that could be helpful and maybe worthy of the WiKi.

[digi_guy]

This is great! And could potentially avoid using the config mode for resetting the network. 

You could set up have a button set up on an interrupt that turns on the oak's AP. Then connect to the Oak's server and give it a new ssid/pw that it could connect to.

Thanks!

[kcbudd]

I've made another discovery.

If you call the above code snippet and FAIL to associate with an AP three times in succession then the Oak suddenly reboots into "config mode."  Once it does that it stays there (even if you power cycle it) until you send it a new WiFi config association request.  (After which it goes right back to running your user sketch.)

I can't find anything in the modified Oak ESP8266WiFi library that causes this, so maybe it's actually something in the firmware itself.   I haven't had time to play with it since that discovery, but I want to try SYSTEM_MODE(MANUAL), and also maybe see if there's any call I can make between association attempts that resets the counter or prevents the oak from going back into config mode.

Alternatively, of course, I could just reflash it (serial) as a raw ESP8266 device, but I'd rather not as I'd like to keep the oak / cloud functionality if I can (even if I'm only partially leveraging it.)

[PeterF]

Hi kcbudd, would firstly like to say that this is great info you've put up... I will be finding it useful shortly with some of my projects, and I'm sure plenty of other people will also.

Is that behaviour (the reset after failures) still present when the board is in Manual Config mode? As if it is, that sounds like a bug, as that is exactly the behaviour that I thought that variant was supposed to prevent.

Pete

[kcbudd]

Ah ha!  Manual config mode... how did I miss that?!    Yes, that seems to have eradicated the behavior.   Though, truth be told, not long after testing it I just did away with the bank 0 config firmware and instead used the serial I/O flashing method for my program... just for expediency.  I was having trouble with a library that was throwing a WDT stack trace, and it was becoming very cumbersome to get the thing out of config mode every time to re-flash it.