[GH-ISSUE #314] persistent problems #262

New issue

Closed

opened 2026-02-28 01:24:24 +03:00 by kerem · 2 comments

kerem commented

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

Owner

Originally created by @tablatronix on GitHub (Feb 10, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/314

Since this keeps coming up and is a problem, and some have suggested to NOT use persistent to avoid these issues, I have looked into this.

persistent flag affects flash in these locations and methods

ESP8266WiFiGenericClass
mode
enablesta ( calls mode )

ESP8266WiFiSTAClass
begin
disconnect calls(enableSTA -> mode if wifioff arg is true)
_smartConfigCallback

callees of disconnect
ESP8266WiFiScanClass::scanNetworks
ESP8266WiFiMesh::connectToNode
ESP8266WiFiMulti::run

ESP8266WiFiAPClass
softAP
softAPdisconnect

It looks like the best way to deal with this is to just not use persistent and enable it when we are saving, or manually set configs, this should prevent saving softap info and stop disconnect problems that can occur inside scannetworks etc.

I have kind of been against this option since I do not like toggling a users globals, But I cannot see another way to avoid this, as persistent was badly implemented in my opinion.

This is also a concern since we do not want flash wear everytime an ap goes down, or in a reset loop. Since everytime the ap is started its saved.

Originally created by @tablatronix on GitHub (Feb 10, 2017). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/314 Since this keeps coming up and is a problem, and some have suggested to NOT use persistent to avoid these issues, I have looked into this. persistent flag affects flash in these locations and methods **ESP8266WiFiGenericClass** `mode` `enablesta` ( calls mode ) **ESP8266WiFiSTAClass** `begin` `disconnect` calls(enableSTA -> mode if wifioff arg is true) `_smartConfigCallback` **callees of disconnect** `ESP8266WiFiScanClass::scanNetworks` `ESP8266WiFiMesh::connectToNode` `ESP8266WiFiMulti::run` **ESP8266WiFiAPClass** `softAP` `softAPdisconnect` It looks like the best way to deal with this is to just not use persistent and enable it when we are saving, or manually set configs, this should prevent saving softap info and stop disconnect problems that can occur inside scannetworks etc. I have kind of been against this option since I do not like toggling a users globals, But I cannot see another way to avoid this, as persistent was badly implemented in my opinion. This is also a concern since we do not want flash wear everytime an ap goes down, or in a reset loop. Since everytime the ap is started its saved.

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Feb 20, 2017):

ok some caveats I found.

You cannot completely manage both persistent and current configs by switching persistent on and off,. mostly because when you use begin it calls enablesta which then calls mode() so if if you are in AP_STA mode current it will be saved to flash. Also enablesta, and disconnect do not respect persistent in this manner, they always and only perform current mode checks, and they will return if already set, so you might not get the expected result when going back and forth with persistent.

Then there are other issues with the SDK itself, the SDK will not perform some softap stuff if softap mode is not current mode. so if you try to disconnect ap whe mode is STA it will not save etc.

There are also rules in the SDK or bugs, that can cause issues without these checks, so you might not be able to set default config to a different config than current, cause it could introduce crashes, i am not entirely sure if the checks are there to prevent these issues, or if they are just bypass optimizations eg.
do not set STA id already STA (but what if we toggled persistent and have since changed modes ?)

Without digging through the commits, I do not know.

by checks i mean stuff like

    if(wifi_get_opmode() == (uint8) m) {
        return true;
    }

It should be possible to preserve mode, and restore it. It should also be possible to have persistent user AP_STA mode, and not have wifimanager interfere with it.

@tablatronix commented on GitHub (Feb 20, 2017): ok some caveats I found. You cannot completely manage both persistent and current configs by switching persistent on and off,. mostly because when you use `begin` it calls `enablesta` which then calls `mode()` so if if you are in AP_STA mode current it will be saved to flash. Also enablesta, and disconnect do not respect persistent in this manner, they always and only perform current mode checks, and they will return if already set, so you might not get the expected result when going back and forth with persistent. Then there are other issues with the SDK itself, the SDK will not perform some softap stuff if softap mode is not current mode. so if you try to disconnect ap whe mode is STA it will not save etc. There are also rules in the SDK or bugs, that can cause issues without these checks, so you might not be able to set default config to a different config than current, cause it could introduce crashes, i am not entirely sure if the checks are there to prevent these issues, or if they are just bypass optimizations eg. do not set STA id already STA (but what if we toggled persistent and have since changed modes ?) Without digging through the commits, I do not know. by checks i mean stuff like ``` if(wifi_get_opmode() == (uint8) m) { return true; } ``` It should be possible to preserve mode, and restore it. It should also be possible to have persistent user AP_STA mode, and not have wifimanager interfere with it.

kerem commented

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

Author

Owner

@tablatronix commented on GitHub (Aug 29, 2017):

oh and _persistent is protected, so you cannot even check the darn things state

@tablatronix commented on GitHub (Aug 29, 2017): oh and `_persistent` is protected, so you cannot even check the darn things state