[GH-ISSUE #104] Working while not connected to Wifi #79

Closed
opened 2026-02-28 01:23:18 +03:00 by kerem · 7 comments
Owner

Originally created by @elieyal on GitHub (Feb 16, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/104

@tzapu, first, same as everyone, I think this library is amazing....
I have some flows I'm trying to do, maybe you can help me think on how to integrate this library into my flows:

  1. The first time installation of the board in a new place where there is a new WiFi network
  2. Letting the board continue to work as usual (inputs and outputs) while it's not yet connected to a network
  3. Working as usual while WiFi is lost and resuming connection when the WiFi is again available
  4. Changing the WiFi network on demand.

the idea behind these flows is very simple:

  1. Configure and test
  2. Move to a new place to do the actual work - reconfigure on site
  3. make sure it's working no matter what - and stable.
  4. Resume connectivity if lost.

Now the first flow is simple from your examples, but how can the board continue to work (with my board, gpio0 is an input button and gpio2 is output according to the button) if there is no WiFi configured?

What will happen if the WiFi is lost at some point? I have this in my current board:
//set IP if not correct
IPAddress ipadd = WiFi.localIP();
if( ipadd!= ip) {
WiFi.config(ip, gateway, subnet);
}
// Connect to WiFi network
WiFi.begin(ssid, password);
counter = 0;
while (WiFi.status() != WL_CONNECTED) {
Serial.print(".");
override_check();
delay(250);

}
Serial.println("");
Serial.println("WiFi connected");
// Start the server
server.begin()

Unfortunately, in your example you are using the ESP8266WebServer that I'm not so fund of, so i cant use your example that much (why use it when ESP8266WiFi is much more simpler?).

And last, you wrote in the documentation NOT to use both on demand and the autoConnect. so my question is how do I setup my board in one place and than move it to another place to work? how can I change the settings on demand but after the first initialization?

Thank you so much for the help!!

Originally created by @elieyal on GitHub (Feb 16, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/104 @tzapu, first, same as everyone, I think this library is amazing.... I have some flows I'm trying to do, maybe you can help me think on how to integrate this library into my flows: 1. The first time installation of the board in a new place where there is a new WiFi network 2. Letting the board continue to work as usual (inputs and outputs) while it's not yet connected to a network 3. Working as usual while WiFi is lost and resuming connection when the WiFi is again available 4. Changing the WiFi network on demand. the idea behind these flows is very simple: 1. Configure and test 2. Move to a new place to do the actual work - reconfigure on site 3. make sure it's working no matter what - and stable. 4. Resume connectivity if lost. Now the first flow is simple from your examples, but how can the board continue to work (with my board, gpio0 is an input button and gpio2 is output according to the button) if there is no WiFi configured? What will happen if the WiFi is lost at some point? I have this in my current board: //set IP if not correct IPAddress ipadd = WiFi.localIP(); if( ipadd!= ip) { WiFi.config(ip, gateway, subnet); } // Connect to WiFi network WiFi.begin(ssid, password); counter = 0; while (WiFi.status() != WL_CONNECTED) { Serial.print("."); override_check(); delay(250); ``` } Serial.println(""); Serial.println("WiFi connected"); // Start the server server.begin() ``` Unfortunately, in your example you are using the ESP8266WebServer that I'm not so fund of, so i cant use your example that much (why use it when ESP8266WiFi is much more simpler?). And last, you wrote in the documentation NOT to use both on demand and the autoConnect. so my question is how do I setup my board in one place and than move it to another place to work? how can I change the settings on demand but after the first initialization? Thank you so much for the help!!
kerem closed this issue 2026-02-28 01:23:18 +03:00
Author
Owner

@pieman64 commented on GitHub (Feb 16, 2016):

@elieyal when you move to a new place WiFiManager will automatically take care of things for you i.e. the SSID and pwd of the AP will not be stored in your ESP so it will bring up the autoConnect for you to configure the new location.

<!-- gh-comment-id:184661201 --> @pieman64 commented on GitHub (Feb 16, 2016): @elieyal when you move to a new place WiFiManager will automatically take care of things for you i.e. the SSID and pwd of the AP will not be stored in your ESP so it will bring up the autoConnect for you to configure the new location.
Author
Owner

@elieyal commented on GitHub (Feb 16, 2016):

Right.
This is when I use the AutoConnect. But what will happen if my WiFi network will be gone and the board will restart? In this case, the AutoConnect will be brought up and my board will be on-hold until it's re-configured.
In my case, I don't have one board, i have 20 of them :-)
Re-configuring all of them is a problem.
I cant use the AutoConnect and OnDemand in the same board so it's a problem.
my flow should be like this:

  1. if there is no SSID - bring up the portal for configuration (and in the mean time wait for gpio inputs and act when button pressed)
  2. if ssid exists - try to connect to it. use it only. while trying to connect - continue to wait for gpio inputs
  3. if a button is pressed for more than 5 seconds - bring up the portal for Wifi change (but continue to wait for gpio inputs)

does this make sense? maybe i should use only the onDemand, but how do i know that the SSID is stored?

<!-- gh-comment-id:184666584 --> @elieyal commented on GitHub (Feb 16, 2016): Right. This is when I use the AutoConnect. But what will happen if my WiFi network will be gone and the board will restart? In this case, the AutoConnect will be brought up and my board will be on-hold until it's re-configured. In my case, I don't have one board, i have 20 of them :-) Re-configuring all of them is a problem. I cant use the AutoConnect and OnDemand in the same board so it's a problem. my flow should be like this: 1. if there is no SSID - bring up the portal for configuration (and in the mean time wait for gpio inputs and act when button pressed) 2. if ssid exists - try to connect to it. use it only. while trying to connect - continue to wait for gpio inputs 3. if a button is pressed for more than 5 seconds - bring up the portal for Wifi change (but continue to wait for gpio inputs) does this make sense? maybe i should use only the onDemand, but how do i know that the SSID is stored?
Author
Owner

@tzapu commented on GitHub (Feb 16, 2016):

after the initial setup, WiFiManager no longer interacts with your module.
if the connection comes and goes at least as far as i know, the default behaviour of the esp is to reconnect
you can use just on demand and a couple of ifs to duplicate the functionality of autoConnect and to have your sketch working , etc. you do not need to know what the ssid is

  • when sketch starts issue WiFi.begin()
  • if this fails (wait for connection result) or in your case you can check if WiFi.SSID() is empty, start on demand portal

while serving the config portal, the sketch is blocked. this is unlikely to change at any point due to how it all links together.

<!-- gh-comment-id:184669948 --> @tzapu commented on GitHub (Feb 16, 2016): after the initial setup, WiFiManager no longer interacts with your module. if the connection comes and goes at least as far as i know, the default behaviour of the esp is to reconnect you can use just on demand and a couple of ifs to duplicate the functionality of autoConnect and to have your sketch working , etc. you do not need to know what the ssid is - when sketch starts issue WiFi.begin() - if this fails (wait for connection result) or in your case you can check if WiFi.SSID() is empty, start on demand portal while serving the config portal, the sketch is blocked. this is unlikely to change at any point due to how it all links together.
Author
Owner

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

Can you handle connection failures on your own and only start up
startConfigPortal() in a special mode or button press and not use autoconnect at all. ( the esp8266 will do its own autoconnect regardless, so thats fine )

otherwise just use your code as usual ?

Or are you wanting the portal to always be available, and also run your loops ?
Like STA + AP and always allow settings changes ?

also your

while (WiFi.status() != WL_CONNECTED)

loop is probably going to be very blocking and probably not wise.

<!-- gh-comment-id:185850554 --> @tablatronix commented on GitHub (Feb 18, 2016): Can you handle connection failures on your own and only start up `startConfigPortal()` in a special mode or button press and not use autoconnect at all. ( the esp8266 will do its own autoconnect regardless, so thats fine ) otherwise just use your code as usual ? Or are you wanting the portal to always be available, and also run your loops ? Like STA + AP and always allow settings changes ? also your ``` while (WiFi.status() != WL_CONNECTED) ``` loop is probably going to be very blocking and probably not wise.
Author
Owner

@tzapu commented on GitHub (Feb 19, 2016):

while (WiFi.status() != WL_CONNECTED)

this seems to be exactly what is in the official WiFI.waitForConnectResult() btw
no timeout, no nothing, so i assume the espressif sdk has some other timeouts or something to not go into an infinite loop

<!-- gh-comment-id:186101089 --> @tzapu commented on GitHub (Feb 19, 2016): ``` while (WiFi.status() != WL_CONNECTED) ``` this seems to be exactly what is in the official WiFI.waitForConnectResult() btw no timeout, no nothing, so i assume the espressif sdk has some other timeouts or something to not go into an infinite loop
Author
Owner

@tzapu commented on GitHub (Feb 19, 2016):

sorry, i stand corrected, the loop is actually

uint8_t ESP8266WiFiSTAClass::waitForConnectResult() {
    //1 and 3 have STA enabled
    if((wifi_get_opmode() & 1) == 0) {
        return WL_DISCONNECTED;
    }
    while(status() == WL_DISCONNECTED) {
        delay(100);
    }
    return status();
}
<!-- gh-comment-id:186101732 --> @tzapu commented on GitHub (Feb 19, 2016): sorry, i stand corrected, the loop is actually ``` uint8_t ESP8266WiFiSTAClass::waitForConnectResult() { //1 and 3 have STA enabled if((wifi_get_opmode() & 1) == 0) { return WL_DISCONNECTED; } while(status() == WL_DISCONNECTED) { delay(100); } return status(); } ```
Author
Owner

@kentaylor commented on GitHub (May 2, 2016):

@tzapu I think the function uint8_t WiFiManager::waitForConnectResult() at https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L293 does not go into an infinite loop because the espressif sdk will only return WL_DISCONNECTED for a limited time when in station mode.

@elieyal The example at https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitch/ConfigOnSwitch.ino will do most of your scenario. To run that example you need the version of WiFiManager at https://github.com/kentaylor/WiFiManager/ .

You asked for:-
"1. if there is no SSID - bring up the portal for configuration (and in the mean time wait for gpio inputs and act when button pressed)"

If it has never had an SSID entered it will bring up the portal for configuration but ignore gpio inputs. If it has ever had an SSID entered it will function as normal.

"2. if ssid exists - try to connect to it. use it only. while trying to connect - continue to wait for gpio inputs"

Assuming the device has at some time in its life been provided with an SSID it does exactly that. Sketch will function with or without being connected to a WiFi access point and device will connect automatically in the background if the WiFi access point is ever seen. It will also reconnect every time the WiFi access point comes and goes.

"3. if a button is pressed for more than 5 seconds - bring up the portal for Wifi change (but continue to wait for gpio inputs)"

The example brings up the portal immediately rather than waiting 5 seconds but it is easily changed to wait 5 secs. It will ignore GPIO inputs when the portal is open.

Opening the configuration portal is rare and it is human initiated so most applications should be OK with being non functional while WiFi is being configured.

Also in your original scenario you wanted to take the devices to a second location with different WiFi credentials after testing them at a first location. With the WiFi Manager version at https://github.com/kentaylor/WiFiManager/ you can set the WiFi credentials of the second location while still at the first after testing. You will lose WiFi access at the first but will be able to just switch on the device at the second and it will work.

<!-- gh-comment-id:216389783 --> @kentaylor commented on GitHub (May 2, 2016): @tzapu I think the function uint8_t WiFiManager::waitForConnectResult() at https://github.com/kentaylor/WiFiManager/blob/master/WiFiManager.cpp#L293 does not go into an infinite loop because the espressif sdk will only return WL_DISCONNECTED for a limited time when in station mode. @elieyal The example at https://github.com/kentaylor/WiFiManager/blob/master/examples/ConfigOnSwitch/ConfigOnSwitch.ino will do most of your scenario. To run that example you need the version of WiFiManager at https://github.com/kentaylor/WiFiManager/ . You asked for:- "1. if there is no SSID - bring up the portal for configuration (and in the mean time wait for gpio inputs and act when button pressed)" If it has never had an SSID entered it will bring up the portal for configuration but ignore gpio inputs. If it has ever had an SSID entered it will function as normal. "2. if ssid exists - try to connect to it. use it only. while trying to connect - continue to wait for gpio inputs" Assuming the device has at some time in its life been provided with an SSID it does exactly that. Sketch will function with or without being connected to a WiFi access point and device will connect automatically in the background if the WiFi access point is ever seen. It will also reconnect every time the WiFi access point comes and goes. "3. if a button is pressed for more than 5 seconds - bring up the portal for Wifi change (but continue to wait for gpio inputs)" The example brings up the portal immediately rather than waiting 5 seconds but it is easily changed to wait 5 secs. It will ignore GPIO inputs when the portal is open. Opening the configuration portal is rare and it is human initiated so most applications should be OK with being non functional while WiFi is being configured. Also in your original scenario you wanted to take the devices to a second location with different WiFi credentials after testing them at a first location. With the WiFi Manager version at https://github.com/kentaylor/WiFiManager/ you can set the WiFi credentials of the second location while still at the first after testing. You will lose WiFi access at the first but will be able to just switch on the device at the second and it will work.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#79
No description provided.