[GH-ISSUE #903] AutoConnect always goes to AP on reboot #764

New issue

Closed

opened 2026-02-28 01:26:57 +03:00 by kerem · 17 comments

kerem commented 2026-02-28 01:26:57 +03:00

Owner

Copy link

Originally created by @devilstower on GitHub (Jun 24, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/903

I'm thinking that either I have a fundamental misunderstanding, or something is fundamentally wrong.

If I reduce my code to the smallest snippet possible:

    WiFiManager wifiManager;
    wifiManager.autoConnect("Config");

What happens the first time through is that the config screen appears. I select my network, enter the password, the system restarts on the selected network and all is well (well, I need to understand how to get it to display something other than the config screen on the new network, but that's for another day).

The problem is that, every time I restart the system, it goes right back to AP mode and behaves as if the config was never successful. If I check, it appears that the information is being successfully saved, and the switchover occurs without a hitch. It's just that every restart acts like the first.

I'm on version 0.14, on an Arducam ESP8266 Uno V2.

What am I missing? Thanks.

Originally created by @devilstower on GitHub (Jun 24, 2019). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/903 I'm thinking that either I have a fundamental misunderstanding, or something is fundamentally wrong. If I reduce my code to the smallest snippet possible: ``` WiFiManager wifiManager; wifiManager.autoConnect("Config"); ``` What happens the first time through is that the config screen appears. I select my network, enter the password, the system restarts on the selected network and all is well (well, I need to understand how to get it to display something _other than_ the config screen on the new network, but that's for another day). The problem is that, every time I restart the system, it goes right back to AP mode and behaves as if the config was never successful. If I check, it appears that the information is being successfully saved, and the switchover occurs without a hitch. It's just that every restart acts like the first. I'm on version 0.14, on an Arducam ESP8266 Uno V2. What am I missing? Thanks.

kerem 2026-02-28 01:26:57 +03:00

• closed this issue
• added the
  Question
  wontfix
  DEV Help Wanted
  Documentation
  labels

kerem commented 2026-02-28 01:26:57 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jun 24, 2019):

So your code stops at autoconnect and waits ?

<!-- gh-comment-id:505219721 --> @tablatronix commented on GitHub (Jun 24, 2019): So your code stops at autoconnect and waits ?

kerem commented 2026-02-28 01:26:57 +03:00

Author

Owner

Copy link

@devilstower commented on GitHub (Jun 25, 2019):

No, it goes to AP mode, even if there are good credentials. I can trap for
it by simply doing a loop with WiFi myself, but otherwise it seems to plow
on past. Not a show stopper, since I can simply avoid going to autoconnect
if I make a connection with WiFi. But something I thought autoconnect was
supposed to handle.

Thanks! Terrific library. Now I need to find a good example of someone
modifying the config screen to display more info.

Mark

On Monday, June 24, 2019, Shawn A notifications@github.com wrote:

So your code stops at autoconnect and waits ?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tzapu/WiFiManager/issues/903?email_source=notifications&email_token=AAOPC3AKJ7I4SW3U2UKGQTLP4FKUHA5CNFSM4H3BI5B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOQVCI#issuecomment-505219721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOPC3AWDP6PQ6KGNPV6AB3P4FKUHANCNFSM4H3BI5BQ
.

<!-- gh-comment-id:505232370 --> @devilstower commented on GitHub (Jun 25, 2019): No, it goes to AP mode, even if there are good credentials. I can trap for it by simply doing a loop with WiFi myself, but otherwise it seems to plow on past. Not a show stopper, since I can simply avoid going to autoconnect if I make a connection with WiFi. But something I thought autoconnect was supposed to handle. Thanks! Terrific library. Now I need to find a good example of someone modifying the config screen to display more info. Mark On Monday, June 24, 2019, Shawn A <notifications@github.com> wrote: > So your code stops at autoconnect and waits ? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/tzapu/WiFiManager/issues/903?email_source=notifications&email_token=AAOPC3AKJ7I4SW3U2UKGQTLP4FKUHA5CNFSM4H3BI5B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOQVCI#issuecomment-505219721>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAOPC3AWDP6PQ6KGNPV6AB3P4FKUHANCNFSM4H3BI5BQ> > . >

kerem commented 2026-02-28 01:26:57 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jun 25, 2019):

I am saying what do logs say are you sure the esp is not starting ap mode?

<!-- gh-comment-id:505236316 --> @tablatronix commented on GitHub (Jun 25, 2019): I am saying what do logs say are you sure the esp is not starting ap mode?

kerem commented 2026-02-28 01:26:57 +03:00

Author

Owner

Copy link

@akouz commented on GitHub (Jun 27, 2019):

I have the same issue. Until I saw this topic I thought this is as it supposed to be, and I should store/restore credentials myself.

<!-- gh-comment-id:506280828 --> @akouz commented on GitHub (Jun 27, 2019): I have the same issue. Until I saw this topic I thought this is as it supposed to be, and I should store/restore credentials myself.

kerem commented 2026-02-28 01:26:57 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jun 27, 2019):

Well the esp auto starts the ap so just making sure wm is actually running and you are not just assuming it is, set wifi mode to sta in your sketch to make sure.

If your credentials are not being remembered after reboots its usually a flash corruption and erase flash fixes it, always erase flash when switching to new sdks etc

<!-- gh-comment-id:506318567 --> @tablatronix commented on GitHub (Jun 27, 2019): Well the esp auto starts the ap so just making sure wm is actually running and you are not just assuming it is, set wifi mode to sta in your sketch to make sure. If your credentials are not being remembered after reboots its usually a flash corruption and erase flash fixes it, always erase flash when switching to new sdks etc

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@akouz commented on GitHub (Jun 27, 2019):

In my case apparently the reason was in a redundant old WiFi initialisation code I left in the setup(). After cleaning up it works as described. Thank you so much for your effort. Overall it is a great and very handy library, thanks a lot.

<!-- gh-comment-id:506324407 --> @akouz commented on GitHub (Jun 27, 2019): In my case apparently the reason was in a redundant old WiFi initialisation code I left in the setup(). After cleaning up it works as described. Thank you so much for your effort. Overall it is a great and very handy library, thanks a lot.

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@devilstower commented on GitHub (Jun 27, 2019):

The mode problem was indeed the issue. The WiFi credentials were being
remembered, but for some reason the system was booting directly into AP.
Forcing it into STA allowed me to proceed.

Thanks.

On Thu, Jun 27, 2019 at 7:26 AM Alex Kouznetsov notifications@github.com
wrote:

In my case apparently the reason was in a redundant old WiFi
initialisation code I left in the setup(). After cleaning up it works as
described. Thank you so much for your effort. Overall it is a great and
very handy library, thanks a lot.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tzapu/WiFiManager/issues/903?email_source=notifications&email_token=AAOPC3DQDL7QYQCQ553VYKLP4SWXBA5CNFSM4H3BI5B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYW6LNY#issuecomment-506324407,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOPC3DV4VEAQ6374AIXA2TP4SWXBANCNFSM4H3BI5BQ
.

<!-- gh-comment-id:506360968 --> @devilstower commented on GitHub (Jun 27, 2019): The mode problem was indeed the issue. The WiFi credentials were being remembered, but for some reason the system was booting directly into AP. Forcing it into STA allowed me to proceed. Thanks. On Thu, Jun 27, 2019 at 7:26 AM Alex Kouznetsov <notifications@github.com> wrote: > In my case apparently the reason was in a redundant old WiFi > initialisation code I left in the setup(). After cleaning up it works as > described. Thank you so much for your effort. Overall it is a great and > very handy library, thanks a lot. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/tzapu/WiFiManager/issues/903?email_source=notifications&email_token=AAOPC3DQDL7QYQCQ553VYKLP4SWXBA5CNFSM4H3BI5B2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYW6LNY#issuecomment-506324407>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAOPC3DV4VEAQ6374AIXA2TP4SWXBANCNFSM4H3BI5BQ> > . >

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@markg85 commented on GitHub (Jul 19, 2019):

I have this very same issue.
My fix too was forcing the mode to be WIFI_STA when there is a connection....

I'm also very sure this doesn't happen on the main branch so you might have a regression here.

<!-- gh-comment-id:513328556 --> @markg85 commented on GitHub (Jul 19, 2019): I have this very same issue. My fix too was forcing the mode to be WIFI_STA when there is a connection.... I'm also very sure this doesn't happen on the main branch so you might have a regression here.

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jul 20, 2019):

This is the default ESP behavior, just set the mode in setup and it will remember it always

<!-- gh-comment-id:513465022 --> @tablatronix commented on GitHub (Jul 20, 2019): This is the default ESP behavior, just set the mode in setup and it will remember it always

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@markg85 commented on GitHub (Jul 20, 2019):

This is the default ESP behavior, just set the mode in setup and it will remember it always

isn't that why we use a WiFiManager in the first place, to manage these things for us? ...
This isn't the first thing either that i need to put in my setup and loop code that is WiFi specific (besides the WiFiManager initialization code). The WiFiManager really should do this! And if it's not then it's a bug in my opinion.

I think you can expect there to be no* WiFi specific code in the main setup/loop code besides setting up WiFiManager itself. So you should probably set the mode in the constructor (or in connectWifi).

* well, i do need to check if there is a connection for other services to start once that connection is there. It would be neat to have a callback when there is a connection (and a disconnect too) as that prevents making my loop code heavier.

<!-- gh-comment-id:513471566 --> @markg85 commented on GitHub (Jul 20, 2019): > This is the default ESP behavior, just set the mode in setup and it will remember it always isn't that why we use a WiFiManager in the first place, to manage these things for us? ... This isn't the first thing either that i need to put in my setup and loop code that is WiFi specific (besides the WiFiManager initialization code). The WiFiManager _really_ should do this! And if it's not then it's a bug in my opinion. I think you can _expect_ there to be no* WiFi specific code in the main setup/loop code besides setting up WiFiManager itself. So you should probably set the mode in the constructor (or in connectWifi). \* well, i do need to check if there is a connection for other services to start once that connection is there. It would be neat to have a callback when there is a connection (and a disconnect too) as that prevents making my loop code heavier.

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jul 21, 2019):

This is part of ESP default functionality of persistent, it has nothing to do with WM

If a user wants to run a softap, in their own code then they can, why should WM override their code ?

Either way
This is already a feature in development branch, if you call autoconnect WM assumes you want WIFI_STA and sets it for you when configportal Exits it is called _usermode, I can add a setter for people that do not know how esp works also, but this should be working

<!-- gh-comment-id:513508318 --> @tablatronix commented on GitHub (Jul 21, 2019): This is part of ESP default functionality of persistent, it has nothing to do with WM If a user wants to run a softap, in their own code then they can, why should WM override their code ? Either way This is already a feature in development branch, if you call `autoconnect` WM assumes you want `WIFI_STA` and sets it for you when configportal Exits it is called `_usermode`, I can add a setter for people that do not know how esp works also, but this should be working

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@markg85 commented on GitHub (Jul 21, 2019):

This is part of ESP default functionality of persistent, it has nothing to do with WM

If a user wants to run a softap, in their own code then they can, why should WM override their code ?

Either way
This is already a feature in development branch, if you call autoconnect WM assumes you want WIFI_STA and sets it for you when configportal Exits it is called _usermode, I can add a setter for people that do not know how esp works also, but this should be working

You might be missing the point here.
I m well aware of _usermode and am on the development branch. You say that it sets the mode to WIFI_STA "when configportal exits". It doesn't when it never enters the configportal (aka, when it connects to a user/pass it had stored). It should set the mode to WIFI_STA in both cases. Not only when the configportal exits.

That should - imho - be the default behavior. If a user wants to override it to softap then the user should just do so... i don't see a problem there. WM "might" need an option to allow a user override in that case or the user should be expected to always override after WM has done it's thing.

I hope you can reconsider marking this issue as a wontfix as there definitely is a bug still.

<!-- gh-comment-id:513508840 --> @markg85 commented on GitHub (Jul 21, 2019): > This is part of ESP default functionality of persistent, it has nothing to do with WM > > If a user wants to run a softap, in their own code then they can, why should WM override their code ? > > Either way > This is already a feature in development branch, if you call `autoconnect` WM assumes you want `WIFI_STA` and sets it for you when configportal Exits it is called `_usermode`, I can add a setter for people that do not know how esp works also, but this should be working You might be missing the point here. I m well aware of `_usermode` and am on the development branch. You say that it sets the mode to WIFI_STA "when configportal exits". It doesn't when it never enters the configportal (aka, when it connects to a user/pass it had stored). It should set the mode to WIFI_STA in _both_ cases. Not _only_ when the configportal exits. That should - imho - be the default behavior. If a user wants to override it to softap then the user should just do so... i don't see a problem there. WM "might" need an option to allow a user override in that case _or_ the user should be expected to always override _after_ WM has done it's thing. I hope you can reconsider marking this issue as a wontfix as there definitely is a bug still.

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Jul 21, 2019):

The default behavior is to not modify esp persistent mode.( which is WIFI_STA+WIFI_AP)

The better option here is for a library to do nothing, and require users to write proper user code and not have the library change stuff when it does different things.

<!-- gh-comment-id:513509260 --> @tablatronix commented on GitHub (Jul 21, 2019): The default behavior is to not modify esp persistent mode.( which is WIFI_STA+WIFI_AP) The better option here is for a library to do nothing, and require users to write proper user code and not have the library change stuff when it does different things.

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@SteveRMann commented on GitHub (Aug 14, 2019):

I had a similar issue on a recent project (not using WiFiManager), but it may explain what happened.

I had some code working just fine on a Wemos D1 Mini, but after a library upgrade, it stopped connecting to my WiFi. I determined that if I use ESP8266WiFi library Version 2.5.0 or later, all I get from WiFi.status() is WL_NO_SSID_AVAIL.

By reverting to ESP8266WiFi library Version 2.4.2, in my IDE, I can get a connection with the same sketch.

The fix was to put WiFi.enableInsecureWEP(); before WiFi.begin().

this works...
In setup() add WiFi.enableInsecureWEP(); before you instantiate WiFiManager:

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
    //WiFiManager
  //Local intialization. Once its business is done, there is no need to keep it around
  WiFi.enableInsecureWEP();
  WiFiManager wifiManager;

<!-- gh-comment-id:521095520 --> @SteveRMann commented on GitHub (Aug 14, 2019): I had a similar issue on a recent project (not using WiFiManager), but it may explain what happened. I had some code working just fine on a Wemos D1 Mini, but after a library upgrade, it stopped connecting to my WiFi. I determined that if I use ESP8266WiFi library Version 2.5.0 or later, all I get from WiFi.status() is **WL_NO_SSID_AVAIL**. By reverting to ESP8266WiFi library Version 2.4.2, in my IDE, I _can_ get a connection with the same sketch. The fix was to put _WiFi.enableInsecureWEP();_ before WiFi.begin(). this works... In setup() add WiFi.enableInsecureWEP(); before you instantiate WiFiManager: ``` void setup() { // put your setup code here, to run once: Serial.begin(115200); //WiFiManager //Local intialization. Once its business is done, there is no need to keep it around WiFi.enableInsecureWEP(); WiFiManager wifiManager; ```

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Aug 14, 2019):

interesting, I just noticed these new options a couple days ago when browsing the esp code. This would be router dependent I assume, or an open network

<!-- gh-comment-id:521326561 --> @tablatronix commented on GitHub (Aug 14, 2019): interesting, I just noticed these new options a couple days ago when browsing the esp code. This would be router dependent I assume, or an open network

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@SteveRMann commented on GitHub (Aug 15, 2019):

Yes, my router is ancient; 3-years old. It does not support WPA but the esp8266WiFi library Version 2.5.0 made WPA the default.

Now, how do I handle bad passwords?

<!-- gh-comment-id:521512482 --> @SteveRMann commented on GitHub (Aug 15, 2019): Yes, my router is ancient; 3-years old. It does not support WPA but the esp8266WiFi library Version 2.5.0 made WPA the default. Now, how do I handle bad passwords?

kerem commented 2026-02-28 01:26:58 +03:00

Author

Owner

Copy link

@tablatronix commented on GitHub (Dec 4, 2019):

Add this to docs and an example

<!-- gh-comment-id:561463904 --> @tablatronix commented on GitHub (Dec 4, 2019): Add this to docs and an example

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

revert-1849-master

feature_fastconnect

feature_auth

feature_slimable

PEAP

feature_statichtmlparams

feature_asyncwebserver

feature_pagestringsref

parameter-smart-ptr

gh-pages

Legacy_v1

hotfixes

autochannelselect_feature

travis

smartconfig

v2.0.17

v2.0.16-rc.2

v2.0.15-rc.1

v2.0.0-rc.1

v2.0.14-beta

v2.0.13-beta

v2.0.12-beta

v2.0.11-beta

v2.0.10-beta

v2.0.9-beta

v2.0.8-beta

2.0.7-beta

2.0.6-beta

2.0.5-beta

2.0.4-beta

0.16.0

2.0.3-alpha

0.15.0

0.14

0.13

0.12

0.11

0.10

0.9

0.8

0.7

0.6

0.5

v0.4

v0.3

v0.2

v0.1

Labels

Clear labels   

📶 WiFi

  

🕸️ HTTP

  

Branch

  

DEV Help Wanted

  

Discussion

  

Documentation

  

ESP32

  

Example

  

Good First Issue

  

Hotfix

  

In Progress

  

Incomplete

  

Needs Feeback

  

Priority

  

QA

  

Question

  

Task

  

Upstream/Dependancy

  

bug

  

duplicate

  

enhancement

  

invalid

  

pull-request

Mirrored from GitHub Pull Request

  

wontfix

No labels

📶 WiFi

🕸️ HTTP

Branch

DEV Help Wanted

Discussion

Documentation

ESP32

Example

Good First Issue

Hotfix

In Progress

Incomplete

Needs Feeback

Priority

QA

Question

Task

Upstream/Dependancy

bug

duplicate

enhancement

invalid

pull-request

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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#764

No description provided.