B4R Question WiFi connect timeout value

[BertI]

Anyone know if/how the WiFi connection timeout value can be altered? I notice if I try and connect an ESP8266 with the intrinsic AutoConnect function enabled then the timeout appears to be 15s whereas if the AutoConnect is disabled it is 75s. I have noticed some issues with the AutoConnect function so am preferring to turn this off and implement a B4R level monitor/reconnect. Erel's recent introduction of an async connect method has definitely helped in this respect , however I'm not sure if there will be a long term problem if I'm trying to reconnect more regularly than the 75s timeout or even if 75s is a fixed value.

 

[Erel]

There is a 15 seconds timeout in the synchronous Connect methods. This is implemented in the library code (rESP8266WiFi.cpp - line 33 - 41)
There is no similar timeout in the async method. It simply polls the connection state.

I don't see where the 75s timeout comes from.

however I'm not sure if there will be a long term problem if I'm trying to reconnect more regularly than the 75s timeout or even if 75s is a fixed value.

You will need to test it.

 

[BertI]

Thank's for pointing me to where the 15s timeout is set. However I still get a 75s timeout if I try the synchronous connection with the autoconnect turned off. If I change the 15000ms timeout in the cpp file to 10000ms I get a 70s timeout. Here is my test code below. This also shows Autoreconnect and persistent attributes turned off but I think it is just the Autoconnect one which makes the difference. The code for re enabling these is also included just for completeness:

#Region Project Attributes
    #AutoFlushLogs: True
    #CheckArrayBounds: True
    #StackBufferSize: 3000
#End Region

Sub Process_Globals
    'These global variables will be declared once when the application starts.
    'Public variables can be accessed from all modules.
    Public Serial1 As Serial
    Public wifi As ESP8266WiFi
    Public t As ULong
       
End Sub

Private Sub AppStart
    Serial1.Initialize(115200)
    Log("AppStart")
   
    RunNative("StopAutoConnect",Null)
    RunNative("StopAutoReconnect",Null)
    RunNative("StopPersistent",Null)
    RunNative("SetSTA", Null)
   
    t=Millis
    Log("Connection success = ", wifi.Connect2("xyz","12345678"))
    Log("Time taken (ms): ",Millis-t)
End Sub

#if C
  void SetSTA(B4R::Object* o) {
  WiFi.mode(WIFI_STA);
  }
  void EnAutoReconnect(B4R::Object* o) {
  WiFi.setAutoReconnect(true);
  }
  void StopAutoReconnect(B4R::Object* o) {
  WiFi.setAutoReconnect(false);
  }
  void EnAutoConnect(B4R::Object* o) {
  WiFi.setAutoConnect(true);
  }
  void StopAutoConnect(B4R::Object* o) {
  WiFi.setAutoConnect(false);
  }
  void EnPersistent(B4R::Object* o) {
  WiFi.persistent(true);
  }
  void StopPersistent(B4R::Object* o) {
  WiFi.persistent(false);
  }
#end if

 

[BertI]

It appears that the 'problem' might actually be related to the AutoReconnect feature rather than AutoConnect. From what I can loosely understand, if AutoReconnect is disabled then I think the WiFi.waitForConnectResult() function doesn't work as you might expect and seems to have a timeout of 60s. So the reason for the 75s overall timeout is 15s due to (rESP8266WiFi.cpp - line 33 - 41) plus 60s whilst the function waits for the result of WiFi.waitForConnectResult().

I couldn't find a way (that worked) to adjust the 60s timeout for WiFi.waitForConnectResult(), so instead I tried replacing

return WiFi.waitForConnectResult() == WL_CONNECTED;

with

return WiFi.status() == WL_CONNECTED;

in rESP8266WiFi.cpp. This worked in the sense that the timeout was now always 15s and you did still get a connected or not connected indication at the end of it.

However... the same was not true for the AsyncConnect method. In this case the function is looking for WiFi.status() codes other than idle status and disconnect before it returns with a connection status (and presumably pulls the function out of the polling mechanism at that point). From my experimentation I don't think the WiFi.status codes return what you might expect from their descriptions in this situation.

Whilst I'm not so concerned about not getting a 'failed to connect' callback indication from AsynConnect, what I am concerned about is the possibility that by regularly calling AsyncConnect (e.g let's say every 30s) before the polling callback returns with anything, that the mechanism might then be stacking up more 'stuff' in the polling queue than it will remove - eventually leading to overflows or stack issues perhaps?. I don't know if it works like that so sorry for the poor description but hope you understand what I mean. If so, would it be possible for a call to the AsyncConnect function to 'unstack' a previous one, or is that implicit anyway ?

In terms of getting a negative connect indication within a shorter timeout can there be a way to implement a controlled timeout for the Async polling like there is for the non async method? E.g by using some global variable to track the time?. My C is too poor for me to work out how to implement this, nor do I know that doing this won't mess up something else in the bigger picture.. On the other hand if calling AsyncConnect before it has chance to do it's callback is ok then I can just implement a timeout in the B4R domain.

Why do I need to disable AutoReconnect in the first place you might ask? Because it seems to mess with the reliability of connections through the Access Point which I'm turning back on when the main WiFi connection drops for any prolonged period (so that you can still communicate with the device in some way). I haven't figured that one out yet... possibly AutoReconnect is changing WiFi modes whilst it's hunting, certainly it will switch radio channels away from the AP default for one thing, since only one radio, but that's not the only cause.

NB. Whilst trying to find a way to change the inherent WaitForConnectResult timeout I came across the below but not quite sure where to use it. My experimantation of placing it in various places with a different timeout values haven't worked so far

the function's prototype is
int8_t waitForConnectResult(unsigned long timeoutLength = 60000);