[GH-ISSUE #91] ESP does not remember configuration #68

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

Originally created by @Oripy on GitHub (Feb 4, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/91

Hello!

Thank you for this library, it is very useful!

I am running into an issue, I updated the library and now my ESP does not remember the configuration:

  • I am able to configure using the portal.
  • The Wifi connects to the chosen SSID (with the right password entered) just fine.
  • But if I reboot the device, the configuration is lost and my device goes to access point mode again.

Note that it used to work fine when the configuration was stored on the EEPROM. Now that you removed this dependency, where is it stored?

Originally created by @Oripy on GitHub (Feb 4, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/91 Hello! Thank you for this library, it is very useful! I am running into an issue, I updated the library and now my ESP does not remember the configuration: - I am able to configure using the portal. - The Wifi connects to the chosen SSID (with the right password entered) just fine. - But if I reboot the device, the configuration is lost and my device goes to access point mode again. Note that it used to work fine when the configuration was stored on the EEPROM. Now that you removed this dependency, where is it stored?
kerem closed this issue 2026-02-28 01:23:13 +03:00
Author
Owner

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

hi,

the config is stored by the expressif sdk itself now (still in eeprom, but managed by the sdk)

what version of wifimanager are you using and of esp8266 core?

have you got any delay() in setup() ?

cheers

On 4 Feb 2016, at 12:11, Oripy notifications@github.com wrote:

Hello!

Thank you for this library, it is very useful!

I am running into an issue, I updated the library and now my ESP does not remember the configuration:

I am able to configure using the portal
The Wifi connects to the chosen SSID (with the right password entered) just fine
But if I reboot the device, the configuration is lost and my device goes to access point mode again
Note that it used to work fine when the configuration was stored on the EEPROM Now that you removed this dependency, where is it stored?


Reply to this email directly or view it on GitHub https://github.com/tzapu/WiFiManager/issues/91.

<!-- gh-comment-id:179757397 --> @tzapu commented on GitHub (Feb 4, 2016): hi, the config is stored by the expressif sdk itself now (still in eeprom, but managed by the sdk) what version of wifimanager are you using and of esp8266 core? have you got any delay() in setup() ? cheers > On 4 Feb 2016, at 12:11, Oripy notifications@github.com wrote: > > Hello! > > Thank you for this library, it is very useful! > > I am running into an issue, I updated the library and now my ESP does not remember the configuration: > > I am able to configure using the portal > The Wifi connects to the chosen SSID (with the right password entered) just fine > But if I reboot the device, the configuration is lost and my device goes to access point mode again > Note that it used to work fine when the configuration was stored on the EEPROM Now that you removed this dependency, where is it stored? > > — > Reply to this email directly or view it on GitHub https://github.com/tzapu/WiFiManager/issues/91.
Author
Owner

@osos commented on GitHub (Feb 4, 2016):

I have the same issue.

how is it handled by the expressif sdk? I do not see any call to any function for storage in the code.

Also is this only on version 2.1.0 of the esp8266 arduino or also on 2.0.0 ?

<!-- gh-comment-id:179768090 --> @osos commented on GitHub (Feb 4, 2016): I have the same issue. how is it handled by the expressif sdk? I do not see any call to any function for storage in the code. Also is this only on version 2.1.0 of the esp8266 arduino or also on 2.0.0 ?
Author
Owner

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

all versions of the esp8266 SDK handle the saving of ssid and pass in eeprom

do you have a resetSettings() or disconnect() anywhere in your code?

<!-- gh-comment-id:179771109 --> @tzapu commented on GitHub (Feb 4, 2016): all versions of the esp8266 SDK handle the saving of ssid and pass in eeprom do you have a resetSettings() or disconnect() anywhere in your code?
Author
Owner

@osos commented on GitHub (Feb 4, 2016):

so it is handled by the WiFi-class ?

no I do not have any resetsettings() or disconnect() in the code.

<!-- gh-comment-id:179772397 --> @osos commented on GitHub (Feb 4, 2016): so it is handled by the WiFi-class ? no I do not have any resetsettings() or disconnect() in the code.
Author
Owner

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

well, lower level than any arduino stuff
i think set config saves it

<!-- gh-comment-id:179775614 --> @tzapu commented on GitHub (Feb 4, 2016): well, lower level than any arduino stuff i think set config saves it
Author
Owner

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

guys, i ve just rememberd running into a similar behaviour at some point,
in my case, if i had the Flash size of the module set to the wrong size, nothing would work.

Could you check you have the flash size set properly 512kB, 1MB, 4MB for your module, and that the module is indeed that size (example sketch esp8266/CheckFlashConfig)

<!-- gh-comment-id:179783070 --> @tzapu commented on GitHub (Feb 4, 2016): guys, i ve just rememberd running into a similar behaviour at some point, in my case, if i had the Flash size of the module set to the wrong size, nothing would work. Could you check you have the flash size set properly 512kB, 1MB, 4MB for your module, and that the module is indeed that size (example sketch esp8266/CheckFlashConfig)
Author
Owner

@Oripy commented on GitHub (Feb 4, 2016):

Wait, I may have found why it behaves like this in my case.
My code do a "triple" connect:

  • First try to connect to hardcoded SSID values ("factory" settings for internal tests)
  • if failed try the previously entered values (if any)
  • if failed again go to Access Point

I guess that my first try with my hardcoded values is erasing the previously entered values! If so, I guess I will have to branch from WiFiManager to reimplement EEPROM config saves or swap the first two tests.

I will try that the next time I have a chance to work on this project (maybe this week-end).

<!-- gh-comment-id:179803801 --> @Oripy commented on GitHub (Feb 4, 2016): Wait, I may have found why it behaves like this in my case. My code do a "triple" connect: - First try to connect to hardcoded SSID values ("factory" settings for internal tests) - if failed try the previously entered values (if any) - if failed again go to Access Point I guess that my first try with my hardcoded values is erasing the previously entered values! If so, I guess I will have to branch from WiFiManager to reimplement EEPROM config saves or swap the first two tests. I will try that the next time I have a chance to work on this project (maybe this week-end).
Author
Owner

@osos commented on GitHub (Feb 4, 2016):

I am pretty sure I have chosen the right flash size: ESP-01 1MB (64SPIFS). I will check up and revert on this,

However, I am still interested in documentation on how the storage of the ssid/password storage is triggered and any limitations or requirements in SDK in this regard. Do you have a pointer to such documentation?

<!-- gh-comment-id:179814065 --> @osos commented on GitHub (Feb 4, 2016): I am pretty sure I have chosen the right flash size: ESP-01 1MB (64SPIFS). I will check up and revert on this, However, I am still interested in documentation on how the storage of the ssid/password storage is triggered and any limitations or requirements in SDK in this regard. Do you have a pointer to such documentation?
Author
Owner

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

hi,
but why not let wifimanager do all?
autoConnect does all that and you don t need to do yourself anymore wifi begin, or anything like that...

if you do need to try first with factory settings as you say, i think there is a flag so you can tell it to not persist the values to the db
do WiFi.persistent(false) before your begin, then try another WiFi.persistent(true) before wifimanager, if it doesn t connect... not sure if it will work though

<!-- gh-comment-id:179814073 --> @tzapu commented on GitHub (Feb 4, 2016): hi, but why not let wifimanager do all? autoConnect does all that and you don t need to do yourself anymore wifi begin, or anything like that... if you do need to try first with factory settings as you say, i think there is a flag so you can tell it to not persist the values to the db do `WiFi.persistent(false)` before your begin, then try another `WiFi.persistent(true)` before wifimanager, if it doesn t connect... not sure if it will work though
Author
Owner

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

@osos from the esp8266 sdk guide
7. wifi_station_set_config
Function:
Set WiFi station configuration, and save it to flash
Note:
• This API can be called only if ESP8266 station is enabled.
• If wifi_station_set_config is called in user_init , there is no need to
call wifi_station_connect after that, ESP8266 will connect to router
automatically; otherwise, need wifi_station_connect to connect.
• In general, station_config.bssid_set need to be 0, otherwise it will
check bssid which is the MAC address of AP.
• This configuration will be saved in flash system parameter area if
changed.
Prototype:
bool wifi_station_set_config (struct station_config *config)

<!-- gh-comment-id:179816334 --> @tzapu commented on GitHub (Feb 4, 2016): @osos from the esp8266 sdk guide 7. wifi_station_set_config Function: Set WiFi station configuration, and save it to flash Note: • This API can be called only if ESP8266 station is enabled. • If wifi_station_set_config is called in user_init , there is no need to call wifi_station_connect after that, ESP8266 will connect to router automatically; otherwise, need wifi_station_connect to connect. • In general, station_config.bssid_set need to be 0, otherwise it will check bssid which is the MAC address of AP. • This configuration will be saved in flash system parameter area if changed. Prototype: bool wifi_station_set_config (struct station_config *config)
Author
Owner

@Oripy commented on GitHub (Feb 4, 2016):

Thank you for the info on Wifi.persistant(), I will try it, it seems to be just the thing I need.

autoConnect does all that and you don t need to do yourself anymore wifi begin, or anything like that...

I do not understand your comment, is there a way to set a default value that is already defined just after flashing a brand new ESP8266?

<!-- gh-comment-id:179822395 --> @Oripy commented on GitHub (Feb 4, 2016): Thank you for the info on Wifi.persistant(), I will try it, it seems to be just the thing I need. > autoConnect does all that and you don t need to do yourself anymore wifi begin, or anything like that... I do not understand your comment, is there a way to set a default value that is already defined just after flashing a brand new ESP8266?
Author
Owner

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

sorry, i missed your factory defaults wish
to set your defaults you d need to do a begin the first time you run it, so you could do something like
wifi get ssid
if ssid is blank/null try connecting with your defaults
go through wait for connection results
then add all the simple autoConnect from wifi manager, it will see you are connected and return
if you are not connected it will start config portal
if you already have a ssid, then you must not be at first run

<!-- gh-comment-id:179825125 --> @tzapu commented on GitHub (Feb 4, 2016): sorry, i missed your factory defaults wish to set your defaults you d need to do a begin the first time you run it, so you could do something like wifi get ssid if ssid is blank/null try connecting with your defaults go through wait for connection results then add all the simple autoConnect from wifi manager, it will see you are connected and return if you are not connected it will start config portal if you already have a ssid, then you must not be at first run
Author
Owner

@Oripy commented on GitHub (Feb 4, 2016):

Thank you for your time! I will close this issue as soon as I checked that this was my problem.

<!-- gh-comment-id:179829968 --> @Oripy commented on GitHub (Feb 4, 2016): Thank you for your time! I will close this issue as soon as I checked that this was my problem.
Author
Owner

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

cool , do let us know :)

<!-- gh-comment-id:179834036 --> @tzapu commented on GitHub (Feb 4, 2016): cool , do let us know :)
Author
Owner

@osos commented on GitHub (Feb 5, 2016):

I did use the right flash size. However, I did have some FS access which also failed.
After removing the FS code and chosing a diffrent SPIFS ratio, it works.

Maybe the SDKs continues save of the credentials damages some of the flash cells?

Anyway it works now, using WifiManager 0.9, ESP8266 2.0.0 and Arduino 1.6.7.

The sketch is a simple DHT22 waking up after deepsleep posting its data to thingspeak.com.

<!-- gh-comment-id:180273434 --> @osos commented on GitHub (Feb 5, 2016): I did use the right flash size. However, I did have some FS access which also failed. After removing the FS code and chosing a diffrent SPIFS ratio, it works. Maybe the SDKs continues save of the credentials damages some of the flash cells? Anyway it works now, using WifiManager 0.9, ESP8266 2.0.0 and Arduino 1.6.7. The sketch is a simple DHT22 waking up after deepsleep posting its data to thingspeak.com.
Author
Owner

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

yeah, some weird stuff happening with spiffs/eeprom/credentails, i have seen some other weird behaviour cleared after a FS.format()

btw, could you let me know in a week or so if your deep sleeping sensor is still working?
i have one that after a few days, it goes through the motions alright, it s just the http request that is failing... based on newer sdk. another one that i have and is based on an older sdk, maybe 1.2 , has worked flawlessly for more than half a year...

<!-- gh-comment-id:180279559 --> @tzapu commented on GitHub (Feb 5, 2016): yeah, some weird stuff happening with spiffs/eeprom/credentails, i have seen some other weird behaviour cleared after a FS.format() btw, could you let me know in a week or so if your deep sleeping sensor is still working? i have one that after a few days, it goes through the motions alright, it s just the http request that is failing... based on newer sdk. another one that i have and is based on an older sdk, maybe 1.2 , has worked flawlessly for more than half a year...
Author
Owner

@PuceBaboon commented on GitHub (Feb 5, 2016):

Interesting you should say that. I have two battery-powered sensors which
I recently
updated (-not- using WiFiManager) using Arduino-ICE 1.6.7 with 2.1.0-rc2
and they've
both gone off line after maybe only five days, whereas before they'd been
running quite
happily for weeks (of course, the reason I updated them was because I'd
made some
changes too, so it's a bit early to point a finger at anything other than
my poor
programming). :-)
I need to go and retrieve them and plug them into my laptop to see what
they're showing
on the serial port.

On 5 February 2016 at 19:00, tzapu notifications@github.com wrote:

yeah, some weird stuff happening with spiffs/eeprom/credentails, i have
seen some other weird behaviour cleared after a FS.format()

btw, could you let me know in a week or so if your deep sleeping sensor is
still working?
i have one that after a few days, it goes through the motions alright, it
s just the http request that is failing... based on newer sdk. another one
that i have and is based on an older sdk, maybe 1.2 , has worked flawlessly
for more than half a year...


Reply to this email directly or view it on GitHub
https://github.com/tzapu/WiFiManager/issues/91#issuecomment-180279559.

<!-- gh-comment-id:180292849 --> @PuceBaboon commented on GitHub (Feb 5, 2016): Interesting you should say that. I have two battery-powered sensors which I recently updated (-not- using WiFiManager) using Arduino-ICE 1.6.7 with 2.1.0-rc2 and they've both gone off line after maybe only five days, whereas before they'd been running quite happily for weeks (of course, the reason I updated them was because I'd made some changes too, so it's a bit early to point a finger at anything other than my poor programming). :-) I need to go and retrieve them and plug them into my laptop to see what they're showing on the serial port. On 5 February 2016 at 19:00, tzapu notifications@github.com wrote: > yeah, some weird stuff happening with spiffs/eeprom/credentails, i have > seen some other weird behaviour cleared after a FS.format() > > btw, could you let me know in a week or so if your deep sleeping sensor is > still working? > i have one that after a few days, it goes through the motions alright, it > s just the http request that is failing... based on newer sdk. another one > that i have and is based on an older sdk, maybe 1.2 , has worked flawlessly > for more than half a year... > > — > Reply to this email directly or view it on GitHub > https://github.com/tzapu/WiFiManager/issues/91#issuecomment-180279559.
Author
Owner

@osos commented on GitHub (Feb 8, 2016):

After getting wifi manager working with my dht connected esp-01, it just gone offline 6 hours ago.

Will se if I can work out the state when I get home.

<!-- gh-comment-id:181341468 --> @osos commented on GitHub (Feb 8, 2016): After getting wifi manager working with my dht connected esp-01, it just gone offline 6 hours ago. Will se if I can work out the state when I get home.
Author
Owner

@osos commented on GitHub (Feb 11, 2016):

@PuceBaboon, @tzapu regarding the DHT22 and other stop working see: https://github.com/esp8266/Arduino/issues/654 og https://github.com/esp8266/Arduino/issues/1594

Seems the new SDK for esp8266 does not allow "NoInterrupt", which is used inter alia in the DHT lib.
Interrupt-driven DHT lib can be found here: https://github.com/chaeplin/PietteTech_DHT-8266

<!-- gh-comment-id:182795053 --> @osos commented on GitHub (Feb 11, 2016): @PuceBaboon, @tzapu regarding the DHT22 and other stop working see: https://github.com/esp8266/Arduino/issues/654 og https://github.com/esp8266/Arduino/issues/1594 Seems the new SDK for esp8266 does not allow "NoInterrupt", which is used inter alia in the DHT lib. Interrupt-driven DHT lib can be found here: https://github.com/chaeplin/PietteTech_DHT-8266
Author
Owner

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

ooo... what a great piece of intel.... thanks, i will try it in the next couple of days... would be great if this sorted it

<!-- gh-comment-id:182796189 --> @tzapu commented on GitHub (Feb 11, 2016): ooo... what a great piece of intel.... thanks, i will try it in the next couple of days... would be great if this sorted it
Author
Owner

@Oripy commented on GitHub (Feb 15, 2016):

Sorry for the late feedback.
I tried several things but I'm not good enough to understand what is going on. So I modified my requirements and the "factory settings" are accessed only when a button is pressed during boot. That solved my issue, but it is a workaround.

<!-- gh-comment-id:184115105 --> @Oripy commented on GitHub (Feb 15, 2016): Sorry for the late feedback. I tried several things but I'm not good enough to understand what is going on. So I modified my requirements and the "factory settings" are accessed only when a button is pressed during boot. That solved my issue, but it is a workaround.
Author
Owner

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

hi, you could just add this at the begging of your sketch , before any wifiManager stuff

if(!WiFi.SSID() || WiFi.SSID() == "") {
  WiFi.begin(default_ssid, default_pass);
}

(code not tested)

<!-- gh-comment-id:184116985 --> @tzapu commented on GitHub (Feb 15, 2016): hi, you could just add this at the begging of your sketch , before any wifiManager stuff ``` if(!WiFi.SSID() || WiFi.SSID() == "") { WiFi.begin(default_ssid, default_pass); } ``` (code not tested)
Author
Owner

@fvpalha commented on GitHub (Jul 15, 2016):

I have the same problem. The new SDK (1.5.4) does not change the SSID and PASSWORD in STATION mode.

<!-- gh-comment-id:233058703 --> @fvpalha commented on GitHub (Jul 15, 2016): I have the same problem. The new SDK (1.5.4) does not change the SSID and PASSWORD in STATION mode.
Author
Owner

@kadellabs commented on GitHub (Nov 4, 2017):

hi how to get ssid and password of previously connected WIFI ? in esp8266-01

<!-- gh-comment-id:341878161 --> @kadellabs commented on GitHub (Nov 4, 2017): hi how to get ssid and password of previously connected WIFI ? in esp8266-01
Author
Owner

@bhrigs commented on GitHub (Jun 14, 2018):

Erasing the flash completely (you need to upload the blank_1MB.bin file to 0x000000, 0x100000, 0x200000 and 0x300000) as per the following link, solved it for me:
http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/

<!-- gh-comment-id:397194346 --> @bhrigs commented on GitHub (Jun 14, 2018): Erasing the flash completely (you need to upload the blank_1MB.bin file to 0x000000, 0x100000, 0x200000 and 0x300000) as per the following link, solved it for me: http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/
Author
Owner

@tablatronix commented on GitHub (Jun 14, 2018):

Or use esptool..

<!-- gh-comment-id:397283298 --> @tablatronix commented on GitHub (Jun 14, 2018): Or use esptool..
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#68
No description provided.