[GH-ISSUE #703] Reset or power off requires additional reset to connect

kerem commented

2026-02-28 01:25:59 +03:00

Owner

Originally created by @nhlives on GitHub (Aug 17, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/703

WiFimanager Release: Version 0.14.0 using the Arduino IDE Library Manager

#include <ArduinoJson.h>
#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>
#include <ESP8266httpUpdate.h>
#include <ESP.h>
#include <DNSServer.h>
#include <ESP8266WebServer.h>
#include "WiFiManager.h"

Hardware: ESP-12E
Core Version: 2.4.2

Problem description
Mainly a question for now. On a power off or reset, the ESP requires an additional reset or power off/power on to connect. After a reset/power off, the sketch goes into the portal mode after failing to connect with a WM: 4. It doesn't matter if I have it connected to the USB or not. In a normal production mode, a power off/on would go through this cycle requirement. Even using the portal after the first reset will not clear the issue. Only the second reset / power off/on will connect.

I have implemented the portal timeout wifiManager.setConfigPortalTimeout(120); and the ESP.reset(); procedure which fixes the problem. I find this a bit of a kluge though. Is this expected behavior or should I try something else for a recovery?

Log:
*WM:
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 4
Entered config mode
192.168.4.1
LimitedMobility
*WM:
*WM: Configuring access point...
*WM: LimitedMobility
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
failed to connect and hit timeout

ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
vbb28d4a3
~ld
*WM: Adding parameter
*WM:
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.73

Module: NodeMcu

Originally created by @nhlives on GitHub (Aug 17, 2018). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/703 WiFimanager Release: Version 0.14.0 using the Arduino IDE Library Manager #include <ArduinoJson.h> #include <Arduino.h> #include <ESP8266WiFi.h> #include <ESP8266HTTPClient.h> #include <ESP8266httpUpdate.h> #include <ESP.h> #include <DNSServer.h> #include <ESP8266WebServer.h> #include "WiFiManager.h" Hardware: ESP-12E Core Version: 2.4.2 Problem description Mainly a question for now. On a power off or reset, the ESP requires an additional reset or power off/power on to connect. After a reset/power off, the sketch goes into the portal mode after failing to connect with a WM: 4. It doesn't matter if I have it connected to the USB or not. In a normal production mode, a power off/on would go through this cycle requirement. Even using the portal after the first reset will not clear the issue. Only the second reset / power off/on will connect. I have implemented the portal timeout wifiManager.setConfigPortalTimeout(120); and the ESP.reset(); procedure which fixes the problem. I find this a bit of a kluge though. Is this expected behavior or should I try something else for a recovery? Log: *WM: *WM: *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 4 Entered config mode 192.168.4.1 LimitedMobility *WM: *WM: Configuring access point... *WM: LimitedMobility *WM: AP IP address: *WM: 192.168.4.1 *WM: HTTP server started failed to connect and hit timeout ets Jan 8 2013,rst cause:2, boot mode:(3,7) load 0x4010f000, len 1384, room 16 tail 8 chksum 0x2d csum 0x2d vbb28d4a3 ~ld *WM: Adding parameter *WM: *WM: *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 3 *WM: IP Address: *WM: 192.168.1.73 Module: NodeMcu

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

The esp cannot do a softreset after programming, you have to reset it. Its a feature.
Is this what you mean ?

@tablatronix commented on GitHub (Aug 17, 2018): The esp cannot do a softreset after programming, you have to reset it. Its a feature. Is this what you mean ?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

Or are you saying your esp will not connect to saved wifi after a reboot ?

@tablatronix commented on GitHub (Aug 17, 2018): Or are you saying your esp will not connect to saved wifi after a reboot ?

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

No matter how many times I reset, the pattern of reset followed by not connecting followed by reset followed by connect repeats.

@nhlives commented on GitHub (Aug 17, 2018): No matter how many times I reset, the pattern of reset followed by not connecting followed by reset followed by connect repeats.

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

So yes it’s the second second case

@nhlives commented on GitHub (Aug 17, 2018): So yes it’s the second second case

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

4 = "WL_CONNECT_FAILED", // 4 STATION_CONNECT_FAIL, STATION_WRONG_PASSWORD(NI)

do you have some kind of begin code in your sketch ?
try adding a delay and see if it fixes it, this is odd, It could be that we are connecting mid connection, this was a problem with some versions of the esp lib

@tablatronix commented on GitHub (Aug 17, 2018): 4 = "WL_CONNECT_FAILED", // 4 STATION_CONNECT_FAIL, STATION_WRONG_PASSWORD(NI) do you have some kind of begin code in your sketch ? try adding a delay and see if it fixes it, this is odd, It could be that we are connecting mid connection, this was a problem with some versions of the esp lib

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

Not any begin() in my code unless something embedded in the OTA library. In fact I get this with the two library examples I have tried. I'll try adding a delay but I have loaded the AutoConnect example as a test. I did not use my browser to connect to the portal during the test.

The log from the AutoConnect example:

*WM: Connection result:
*WM: 4
*WM:
*WM: Configuring access point...
*WM: AutoConnectAP
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started

==>HW reset here

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.73
connected...yeey :)

==>HW reset here

*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 4
*WM:
*WM: Configuring access point...
*WM: AutoConnectAP
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started

@nhlives commented on GitHub (Aug 17, 2018): Not any begin() in my code unless something embedded in the OTA library. In fact I get this with the two library examples I have tried. I'll try adding a delay but I have loaded the AutoConnect example as a test. I did not use my browser to connect to the portal during the test. The log from the AutoConnect example: *WM: Connection result: *WM: 4 *WM: *WM: Configuring access point... *WM: AutoConnectAP *WM: AP IP address: *WM: 192.168.4.1 *WM: HTTP server started ==>HW reset here *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 3 *WM: IP Address: *WM: 192.168.1.73 connected...yeey :) ==>HW reset here *WM: AutoConnect *WM: Connecting as wifi client... *WM: Using last saved values, should be faster *WM: Connection result: *WM: 4 *WM: *WM: Configuring access point... *WM: AutoConnectAP *WM: AP IP address: *WM: 192.168.4.1 *WM: HTTP server started

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

Added a 5000 ms delay in the AutoConnect example. No change. Apparently we cannot read the eeprom after a reset or power off/ power on. Until another reboot. Doesn't seem to matter.

@nhlives commented on GitHub (Aug 17, 2018): Added a 5000 ms delay in the AutoConnect example. No change. Apparently we cannot read the eeprom after a reset or power off/ power on. Until another reboot. Doesn't seem to matter.

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

Seems like 5 seconds isn't enough. I have been testing with three different ESP12E's. The last one worked for awhile with no delay and then started acting like the other two. I decided to give the yield() delay(10000) another chance. So far that works on all of the sketches so far. I will continue to test :-)

@nhlives commented on GitHub (Aug 17, 2018): Seems like 5 seconds isn't enough. I have been testing with three different ESP12E's. The last one worked for awhile with no delay and then started acting like the other two. I decided to give the yield() delay(10000) another chance. So far that works on all of the sketches so far. I will continue to test :-)

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

We dont read anything we just call begin and the esp does it.

Try setting autoconnect false

@tablatronix commented on GitHub (Aug 17, 2018): We dont read anything we just call begin and the esp does it. Try setting autoconnect false

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

On two of the ESP12E's it remains an issue.

@nhlives commented on GitHub (Aug 17, 2018): On two of the ESP12E's it remains an issue.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

you can also try increasing the connecttimeout

@tablatronix commented on GitHub (Aug 17, 2018): you can also try increasing the connecttimeout

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

"We dont read anything we just call begin and the esp does it."
Got it :-)

I'll play around with connecting myself to see if that changes the behavior. Thanks for your help. The sketch I have now will recover if necessary.

@nhlives commented on GitHub (Aug 17, 2018): "We dont read anything we just call begin and the esp does it." Got it :-) I'll play around with connecting myself to see if that changes the behavior. Thanks for your help. The sketch I have now will recover if necessary.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 17, 2018):

Well ok but it sounds like a bug somewhere that needs a fixin

@tablatronix commented on GitHub (Aug 17, 2018): Well ok but it sounds like a bug somewhere that needs a fixin

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 17, 2018):

How would you like to handle it. Just leave this open for now?

@nhlives commented on GitHub (Aug 17, 2018): How would you like to handle it. Just leave this open for now?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 18, 2018):

Yeah just update if you figure anything out
Did you try turning autoconnect off?

@tablatronix commented on GitHub (Aug 18, 2018): Yeah just update if you figure anything out Did you try turning autoconnect off?

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 18, 2018):

Nothing on the autoconnect off yet.

@nhlives commented on GitHub (Aug 18, 2018): Nothing on the autoconnect off yet.

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Aug 18, 2018):

An observation: I had one of the ESP12e's that was unable to re-flash using the Arduino IDE. A little research and I find that long running loops can brick a ESP. Thinking that might be the case, I downloaded the NodeMCU PyFlasher program thinking I was going to have to re-flash. First I tried just erasing flash. That cleared up the IDE flashing problem...and a little surprising is seems to have fixed the reboot issue. I have run the erase flash on all three ESP 12e's, uploaded the sketch and now I do not see the problem. I keep resetting thinking it will return but so far works like a champ.
Curious. The only long running loop that I have tried lately is one of your example program. Not ready to point fingers there yet but I might see if the issue returns if I rerun one of those programs.

@nhlives commented on GitHub (Aug 18, 2018): An observation: I had one of the ESP12e's that was unable to re-flash using the Arduino IDE. A little research and I find that long running loops can brick a ESP. Thinking that might be the case, I downloaded the NodeMCU PyFlasher program thinking I was going to have to re-flash. First I tried just erasing flash. That cleared up the IDE flashing problem...and a little surprising is seems to have fixed the reboot issue. I have run the erase flash on all three ESP 12e's, uploaded the sketch and now I do not see the problem. I keep resetting thinking it will return but so far works like a champ. Curious. The only long running loop that I have tried lately is one of your example program. Not ready to point fingers there yet but I might see if the issue returns if I rerun one of those programs.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 18, 2018):

If you ever used an older version of esp lib on those , there were several bugs that corrupt your flash, I always erase flash using esptool when starting a new project or upgrading libs.

long running loops are not a problem as long as you have a delay(0) or yield in there to feed watch dog wifi stuff, also the flash only has about 1,000,000 writes if you loop write to flash you will fry the flash sectors.

@tablatronix commented on GitHub (Aug 18, 2018): If you ever used an older version of esp lib on those , there were several bugs that corrupt your flash, I always erase flash using esptool when starting a new project or upgrading libs. long running loops are not a problem as long as you have a delay(0) or yield in there to feed watch dog wifi stuff, also the flash only has about 1,000,000 writes if you loop write to flash you will fry the flash sectors.

kerem commented

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

Author

Owner

@FulvioSpelta commented on GitHub (Aug 19, 2018):

Hi all, just to say that i can reprodruce the problem using:

development branch downloaded on 08/18/2018
esp8266 core 2.4.1
AutoConnectWithFSParameters example source

@FulvioSpelta commented on GitHub (Aug 19, 2018): Hi all, just to say that i can reprodruce the problem using: - development branch downloaded on 08/18/2018 - esp8266 core 2.4.1 - AutoConnectWithFSParameters example source

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 19, 2018):

ok I will take a look

@tablatronix commented on GitHub (Aug 19, 2018): ok I will take a look

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 23, 2018):

have you tried a better power supply?

@tablatronix commented on GitHub (Aug 23, 2018): have you tried a better power supply?

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 23, 2018):

oh I added this to that example a little while ago

are you sure its not this ?

  // always start configportal for a little while
  wm.setConfigPortalTimeout(60);
  wm.startConfigPortal("AutoConnectAP","password");

@tablatronix commented on GitHub (Aug 23, 2018): oh I added this to that example a little while ago are you sure its not this ? ``` // always start configportal for a little while wm.setConfigPortalTimeout(60); wm.startConfigPortal("AutoConnectAP","password"); ```

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 23, 2018):

I removed that, i cannot reproduce this..

@tablatronix commented on GitHub (Aug 23, 2018): I removed that, i cannot reproduce this..

kerem commented

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

Author

Owner

@gregsvo commented on GitHub (Nov 12, 2018):

This is happening to me as well, every other reset or power off and it works again. Very strange. Exact same behavior as nhlives stated here

@gregsvo commented on GitHub (Nov 12, 2018): This is happening to me as well, every other reset or power off and it works again. Very strange. Exact same behavior as [nhlives stated here](https://github.com/tzapu/WiFiManager/issues/703#issuecomment-413967565)

kerem commented

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

Author

Owner

@nhlives commented on GitHub (Nov 12, 2018):

Try erasing the flash

@nhlives commented on GitHub (Nov 12, 2018): Try erasing the flash

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (May 25, 2020):