[GH-ISSUE #1588] Example for making (re-)connecting to WLAN robust #1356

New issue

Closed

opened 2026-02-28 01:29:44 +03:00 by kerem · 4 comments

kerem commented

2026-02-28 01:29:44 +03:00

Owner

Originally created by @probonopd on GitHub (Apr 16, 2023).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1588

Often one finds this

#include <WiFiManager.h>

void setup() {
  WiFiManager wifiManager;
  wifiManager.autoConnect();
}

void loop() {
  // main program logic here
}

This has two downsides:

If the WLAN connection drops while the device is connected, it never re-connects when the WLAN re-appears
If the WLAN is not in range while the device is powered on, then the device will hang on the configuration portal forever

To make it more robust, I would suggest an approach that:

If the WLAN is not in range or is not configured, opens the configuration portal only for 180 seconds
After the timeout, continously tries to reconnect to the WLAN
If the WLAN is in range when the device is powered on but goes out of range thereafter, then the device should not open the configuration portal forever but should periodically try to join the network again

Is the following code suitable to do that?

#include <WiFiManager.h> 

WiFiManager wifiManager;

void setup() {
  wifiManager.setConnectTimeout(60); // Set the connection timeout to 60 seconds
  wifiManager.setConfigPortalTimeout(180); // Set the configuration portal timeout to 180 seconds
  wifiManager.autoConnect(); // Try to connect to the WLAN with saved credentials, or create an AP with a default name if not successful for 180 seconds
}

void loop() {
  if (WiFi.status() !=
      WL_CONNECTED) { // Check if the device is not connected to the WLAN
    wifiManager.setConfigPortalTimeout(0); // Disable the configuration portal
    while (WiFi.status() !=
           WL_CONNECTED) { // Continue attempting to connect until a successful
                           // connection is made
      delay(5000);
      WiFi.begin(); // Try to connect to the WLAN again
    }
  }
  
   // main program logic here
}

Do you think the logic could be further improved?

I suggest to add such an example to the documentation.

Originally created by @probonopd on GitHub (Apr 16, 2023). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1588 Often one finds this ``` #include <WiFiManager.h> void setup() { WiFiManager wifiManager; wifiManager.autoConnect(); } void loop() { // main program logic here } ``` This has two downsides: * If the WLAN connection drops while the device is connected, it never re-connects when the WLAN re-appears * If the WLAN is not in range while the device is powered on, then the device will hang on the configuration portal forever To make it more robust, I would suggest an approach that: * If the WLAN is not in range or is not configured, opens the configuration portal only for 180 seconds * After the timeout, continously tries to reconnect to the WLAN * If the WLAN is in range when the device is powered on but goes out of range thereafter, then the device should not open the configuration portal forever but should periodically try to join the network again Is the following code suitable to do that? ``` #include <WiFiManager.h> WiFiManager wifiManager; void setup() { wifiManager.setConnectTimeout(60); // Set the connection timeout to 60 seconds wifiManager.setConfigPortalTimeout(180); // Set the configuration portal timeout to 180 seconds wifiManager.autoConnect(); // Try to connect to the WLAN with saved credentials, or create an AP with a default name if not successful for 180 seconds } void loop() { if (WiFi.status() != WL_CONNECTED) { // Check if the device is not connected to the WLAN wifiManager.setConfigPortalTimeout(0); // Disable the configuration portal while (WiFi.status() != WL_CONNECTED) { // Continue attempting to connect until a successful // connection is made delay(5000); WiFi.begin(); // Try to connect to the WLAN again } } // main program logic here } ``` Do you think the logic could be further improved? I suggest to add such an example to the documentation.

kerem closed this issue

2026-02-28 01:29:44 +03:00

kerem commented

2026-02-28 01:29:44 +03:00

Author

Owner

@Laxilef commented on GitHub (Sep 15, 2023):

I also see this problem

@Laxilef commented on GitHub (Sep 15, 2023): I also see this problem

kerem commented

2026-02-28 01:29:44 +03:00

Author

Owner

@B1ackt34 commented on GitHub (Feb 15, 2025):

Thank you for the example, a good one to start from.

@B1ackt34 commented on GitHub (Feb 15, 2025): Thank you for the example, a good one to start from.

kerem commented

2026-02-28 01:29:44 +03:00

Author

Owner

@probonopd commented on GitHub (Feb 17, 2025):

tablatronix closed this as completed 2 days ago

Was this implemented?

@probonopd commented on GitHub (Feb 17, 2025): > [tablatronix](https://github.com/tablatronix) closed this as [completed](https://github.com/tzapu/WiFiManager/issues?q=is%3Aissue%20state%3Aclosed%20archived%3Afalse%20reason%3Acompleted)[2 days ago](https://github.com/tzapu/WiFiManager/issues/1588#event-16323203091) Was this implemented?

kerem commented

2026-02-28 01:29:44 +03:00

Author

Owner

@tablatronix commented on GitHub (Feb 18, 2025):

Its in user code, not something we need to add to wm core

@tablatronix commented on GitHub (Feb 18, 2025): Its in user code, not something we need to add to wm core