WiFi.connect() blocking application thread when stored credentials cannot be connected to

Using SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED) on 0.8.0-RC.10 I am seeing the following behaviour when there are stored credentials but they have the wrong password or the device is out of range of the stored WAP that after WiFi.connect() is called the application thread is blocked and the LED will flash constantly green with occasional stops for solid white. I don’t think this used to happen??

I can fix this by turning the WiFi.off() if after calling WiFi.connect() and a timeout period there is no connection AND there are stored credentials (correct or not). This doesn’t seem a very elegant way of handling this condition which others must have experienced?

Let me ping someone that might be able to help, @rickkas7, @ParticleD, or @mstanley are you able to assist?


For those still finding this topic when looking for a solution to blocking behavior:

WiFi.connect is not blocking, unless you are calling it too often!

It is scheduled on the system thread, but if you call it too often, you fill up the async system task queue and the next call will block.

My solution:

  • Call it only every 60 seconds when wifi is not connected
  • Check WiFi.connecting() and don’t call connect when it returns true.
1 Like

@Elco, I have comments in my source code, which has come from others (@rickkas7 ?) , that there is not need to ever call WiFi.connect() more than once because it keeps on trying.

Of course, if you WiFi.disconnect(), you will need to call it again.