[GH-ISSUE #952] WifiMulti support #805

Open
opened 2026-02-28 01:27:08 +03:00 by kerem · 17 comments
Owner

Originally created by @Bolukan on GitHub (Oct 7, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/952

Basic Infos

I would like to register multiple Wifi stations (SSID's). If the device enters the configportal it should be an option to keep (max 2) existing SSID's (show SSID's).

Hardware

WiFimanager Branch/Release:

  • Master
  • Development

Esp8266/Esp32:

  • ESP8266
  • ESP32

Description

My use case is I move these devices between my main network and my "mancave" network, or towards a friend. I want to keep multiple SSID's present on the device. As is known esp devices support up to max 3 SSID's.

I would like to register multiple Wifi stations (SSID's). If the device enters the configportal it should be an option to keep (max 2) existing SSID's (show SSID's).

The library should support some kind of WiFiMulti. This could be implemented as a fallback scenario if the primary SSID is not available and the scan identifies SSID-2 or SSID-3. It should try to connect to them before opening an AP.

Originally created by @Bolukan on GitHub (Oct 7, 2019). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/952 ### Basic Infos I would like to register multiple Wifi stations (SSID's). If the device enters the configportal it should be an option to keep (max 2) existing SSID's (show SSID's). #### Hardware **WiFimanager Branch/Release:** - [ ] Master - [x] Development **Esp8266/Esp32:** - [x] ESP8266 - [x] ESP32 ### Description My use case is I move these devices between my main network and my "mancave" network, or towards a friend. I want to keep multiple SSID's present on the device. As is known esp devices support up to max 3 SSID's. I would like to register multiple Wifi stations (SSID's). If the device enters the configportal it should be an option to keep (max 2) existing SSID's (show SSID's). The library should support some kind of WiFiMulti. This could be implemented as a fallback scenario if the primary SSID is not available and the scan identifies SSID-2 or SSID-3. It should try to connect to them before opening an AP.
Author
Owner

@tablatronix commented on GitHub (Oct 7, 2019):

Multi ssid have to be stored somewhere.

<!-- gh-comment-id:539245337 --> @tablatronix commented on GitHub (Oct 7, 2019): Multi ssid have to be stored somewhere.
Author
Owner

@Bolukan commented on GitHub (Oct 8, 2019):

Of course. I somewhere remembered the esp stores multiple ssid’s in it’s memory (and I don’t refer to EEPROM, but the system memory) as I once analyzed the system memory storage. See wifi_station_ap_number_set and related functions for the direction I was considering. I will dig into it whether this still can be used for this purpose.

<!-- gh-comment-id:539362897 --> @Bolukan commented on GitHub (Oct 8, 2019): Of course. I somewhere remembered the esp stores multiple ssid’s in it’s memory (and I don’t refer to EEPROM, but the system memory) as I once analyzed the system memory storage. See wifi_station_ap_number_set and related functions for the direction I was considering. I will dig into it whether this still can be used for this purpose.
Author
Owner

@tablatronix commented on GitHub (Oct 8, 2019):

It might store those, but it is not handled automatically. So logic needs to be added, and they have never been tested afaik

https://github.com/esp8266/Arduino/issues/2698

Please test those and dump memory after resets and see what you have and post your findings to that issue above please

<!-- gh-comment-id:539596958 --> @tablatronix commented on GitHub (Oct 8, 2019): It might store those, but it is not handled automatically. So logic needs to be added, and they have never been tested afaik https://github.com/esp8266/Arduino/issues/2698 Please test those and dump memory after resets and see what you have and post your findings to that issue above please
Author
Owner

@Bolukan commented on GitHub (Oct 8, 2019):

I’ll look into it

<!-- gh-comment-id:539602042 --> @Bolukan commented on GitHub (Oct 8, 2019): I’ll look into it
Author
Owner

@Bolukan commented on GitHub (Oct 9, 2019):

I tested the functions mentioned in esp8266/Arduino#2698 and had three AP's to use. The conclusion is how the SDK stores AP's in the five memory locations is unpredictable.

It is possible to read them with wifi_station_get_ap_info.
However, I have indications of the use of pointers within flash to limited memory station_config areas(!) as the same information appears multiple times after one change, and changes have strange effects:
0:
1: AP-guest
2: AP-mancave
3: AP-general
It is possible to choose which AP should be activated (wifi_station_ap_change), that works predictable.
wifi_station_ap_change(3), wifi_station_get_config: AP-general. The chip remembers which memory slot contain the last (default) AP.

But starting from the above situation, this is one of the test results:
WiFi.begin(AP-mancave)
0:
1:
2: AP-mancave
3: AP-mancave
Why is 1 deleted? And why after a reset the first situation reappears (so I can reproduce this endless)

I did not find a way to manipulate how new AP's are stored, but at this moment I cannot predict the SDK-method: entries seems to be stored multiple times (can be effect of pointers) and storage of new entries don't minimize damage to other entries.

To be continued. Input is appreciated.

<!-- gh-comment-id:540050627 --> @Bolukan commented on GitHub (Oct 9, 2019): I tested the functions mentioned in esp8266/Arduino#2698 and had three AP's to use. The conclusion is how the SDK stores AP's in the five memory locations is unpredictable. It is possible to read them with wifi_station_get_ap_info. However, I have indications of the use of pointers within flash to limited memory station_config areas(!) as the same information appears multiple times after one change, and changes have strange effects: 0: <empty> 1: AP-guest 2: AP-mancave 3: AP-general It is possible to choose which AP should be activated (wifi_station_ap_change), that works predictable. wifi_station_ap_change(3), wifi_station_get_config: AP-general. The chip remembers which memory slot contain the last (default) AP. But starting from the above situation, this is one of the test results: WiFi.begin(AP-mancave) 0: <empty> 1: <empty> 2: AP-mancave 3: AP-mancave Why is 1 deleted? And why after a reset the first situation reappears (so I can reproduce this endless) I did not find a way to manipulate how new AP's are stored, but at this moment I cannot predict the SDK-method: entries seems to be stored multiple times (can be effect of pointers) and storage of new entries don't minimize damage to other entries. To be continued. Input is appreciated.
Author
Owner

@tablatronix commented on GitHub (Oct 9, 2019):

I guess we were assuming, it would use the current wifi_station_ap_change(INDEX)

perhaps
wifi_station_ap_number_set(5,4,3,2,1) to set the location in memory?

<!-- gh-comment-id:540136031 --> @tablatronix commented on GitHub (Oct 9, 2019): I guess we were assuming, it would use the current wifi_station_ap_change(INDEX) perhaps wifi_station_ap_number_set(5,4,3,2,1) to set the location in memory?
Author
Owner

@Bolukan commented on GitHub (Oct 9, 2019):

Also for other future participants:

bool wifi_station_ap_number_set(uint8 ap_number) sets the number of memory slots available. 5 is a common number (example code in the NONOS library). It is directly correlated to the number of records and the records themselves returned by the next function:
uint8_t wifi_station_get_ap_info (struct station_configc onfig[]) retrieves number and content of the AP's.
uint8 wifi_station_get_current_ap_id (void) returns the current AP.

As you state, bool wifi_station_ap_change (uint8_t current_ap_id) changes to the specific AP (I read about it in some old bug report Espressif solved, but this bug report also confirmed the objective). But it is buggy: other AP's disappear and if another - disappeared - AP is chosen the ESP8266 can't connect (so this bug distorts the function of your device). After a reset the AP's are still in memory.

Then more guesses:
Somewhere in the flash the default AP at boot-up is saved. I expect wifi_station_get_config_default to be related.

Trick: Set persistent=false before disconnect to keep your AP in flash (otherwise the call of wifi_station_set_config() deletes the AP (current AP? More tests needed).

The wifi_station_ap_change function seems to corrupt the internal memory buffer with the five AP's (disappearing AP's) but not the flash memory, because after a reset AP-info reappears.

message to self: try: wifi_station_restore_config

<!-- gh-comment-id:540186110 --> @Bolukan commented on GitHub (Oct 9, 2019): Also for other future participants: **bool [wifi_station_ap_number_set](https://github.com/renzenicolai/esp8266-firmware/blob/590284f08210c8511711e628b0426e176985b235/lib/libmain/user_interface.s#L2888)(uint8 ap_number)** sets the number of memory slots available. 5 is a common number ([example code in the NONOS library](https://github.com/espressif/ESP8266_NONOS_SDK/blob/590fd5492276b5cd9c34c3c5470272ead632be5f/examples/IoT_Demo/include/user_config.h#L81)). It is directly correlated to the number of records and the records themselves returned by the next function: **uint8_t wifi_station_get_ap_info (struct station_configc onfig[])** retrieves number and content of the AP's. **uint8 wifi_station_get_current_ap_id (void)** returns the current AP. As you state, **bool wifi_station_ap_change (uint8_t current_ap_id)** changes to the specific AP (I read about it in some old bug report Espressif solved, but this bug report also confirmed the objective). But it is buggy: other AP's disappear and if another - disappeared - AP is chosen the ESP8266 can't connect (so this bug distorts the function of your device). After a reset the AP's are still in memory. Then more guesses: Somewhere in the flash the default AP at boot-up is saved. I expect **wifi_station_get_config_default** to be related. Trick: Set persistent=false before disconnect to keep your AP in flash (otherwise the call of wifi_station_set_config(<empty>) deletes the AP (current AP? More tests needed). The wifi_station_ap_change function seems to corrupt the internal memory buffer with the five AP's (disappearing AP's) but not the flash memory, because after a reset AP-info reappears. message to self: try: wifi_station_restore_config
Author
Owner

@Bolukan commented on GitHub (Oct 14, 2019):

I propose to close this issue, as I see not enough possibilities with the current SDK. I prefer to keep support for multiwifi based on the possibilities of Espressif’s SDK, and not use SPIFFS/EEPROM for storing SSID’s. That would complicate the library.

<!-- gh-comment-id:541756280 --> @Bolukan commented on GitHub (Oct 14, 2019): I propose to close this issue, as I see not enough possibilities with the current SDK. I prefer to keep support for multiwifi based on the possibilities of Espressif’s SDK, and not use SPIFFS/EEPROM for storing SSID’s. That would complicate the library.
Author
Owner

@tablatronix commented on GitHub (Oct 15, 2019):

Do you think it needs more testing, or should we pressure espressif with these findings, an sdk feature should work if it says it does.

<!-- gh-comment-id:541993789 --> @tablatronix commented on GitHub (Oct 15, 2019): Do you think it needs more testing, or should we pressure espressif with these findings, an sdk feature should work if it says it does.
Author
Owner

@hoekbrwr commented on GitHub (Oct 15, 2019):

As I had interruption of Wifi to Internet I activated my Hotspot for Internet connection to 4G data and I would like to have automatic switchover to that in Neopixelclock sync. So this would be a nice application.

<!-- gh-comment-id:542120633 --> @hoekbrwr commented on GitHub (Oct 15, 2019): As I had interruption of Wifi to Internet I activated my Hotspot for Internet connection to 4G data and I would like to have automatic switchover to that in Neopixelclock sync. So this would be a nice application.
Author
Owner

@Bolukan commented on GitHub (Oct 15, 2019):

Ok @tablatronix , I agree with you we should report our problems to Espressif and see whether they will solve it. If we don't ask, they cannot help.

My guess is it would help if we deliver one or more clean test cases to show the unexpected behaviour. Otherwise a little piece of the implementation could cause or influence the outcome without Espressif and you knowing how my tests went. I can prepare some scripts but need some time (busy week+weekend).

Two parts:

  • If a second SSID is started (wifi_station_set_config), the old one gets saved. But the location is not logic and multiple copies appear. (shown by wifi_station_get_ap_info)
  • Second issue is if you choose a SSID (wifi_station_ap_change) other entries (wifi_station_get_ap_info) disappear.

As I suspect some difference between cache and flash, the tests should try both variants.

<!-- gh-comment-id:542354740 --> @Bolukan commented on GitHub (Oct 15, 2019): Ok @tablatronix , I agree with you we should report our problems to Espressif and see whether they will solve it. If we don't ask, they cannot help. My guess is it would help if we deliver one or more clean test cases to show the unexpected behaviour. Otherwise a little piece of the implementation could cause or influence the outcome without Espressif and you knowing how my tests went. I can prepare some scripts but need some time (busy week+weekend). Two parts: - If a second SSID is started (wifi_station_set_config), the old one gets saved. But the location is not logic and multiple copies appear. (shown by wifi_station_get_ap_info) - Second issue is if you choose a SSID (wifi_station_ap_change) other entries (wifi_station_get_ap_info) disappear. As I suspect some difference between cache and flash, the tests should try both variants.
Author
Owner

@tablatronix commented on GitHub (Oct 16, 2019):

Yes if you can throw a unit test togather that would be great, you can stick it on gist if you want, so it can be forked and modified

<!-- gh-comment-id:542471353 --> @tablatronix commented on GitHub (Oct 16, 2019): Yes if you can throw a unit test togather that would be great, you can stick it on gist if you want, so it can be forked and modified
Author
Owner

@snick-m commented on GitHub (Nov 17, 2022):

I'm also in need of this feature as I'm trying to build a portable device that would likely be taken from home to school and would remember both WiFis so that it can connect to whichever is available. From my looking around the connected issues, this is not yet supported in the WiFiManager library. Where may I pick up if I were to work on getting this support?

<!-- gh-comment-id:1318074413 --> @snick-m commented on GitHub (Nov 17, 2022): I'm also in need of this feature as I'm trying to build a portable device that would likely be taken from home to school and would remember both WiFis so that it can connect to whichever is available. From my looking around the connected issues, this is not yet supported in the WiFiManager library. Where may I pick up if I were to work on getting this support?
Author
Owner

@iKK001 commented on GitHub (Nov 26, 2023):

does anybody know if this has been implemented ? (i.e. possibility to store two (ore more) SSID/PW to be able to use the same ESP32-device on two locations (home and work) without AccessPoint showing up but connectiong at both locations) ??

<!-- gh-comment-id:1826940091 --> @iKK001 commented on GitHub (Nov 26, 2023): does anybody know if this has been implemented ? (i.e. possibility to store two (ore more) SSID/PW to be able to use the same ESP32-device on two locations (home and work) without AccessPoint showing up but connectiong at both locations) ??
Author
Owner

@snick-m commented on GitHub (Nov 27, 2023):

It has not been implemented yet as per my knowledge. I did want to work on adding support for this but never got around to actually exploring it.

<!-- gh-comment-id:1827142542 --> @snick-m commented on GitHub (Nov 27, 2023): It has not been implemented yet as per my knowledge. I did want to work on adding support for this but never got around to actually exploring it.
Author
Owner

@iKK001 commented on GitHub (Nov 27, 2023):

Thanks for your feedback. Same here I wanted to get into this myself - but I had to realize, I am just not knowledgable enough to dare to get into the ESP32-SDK storage of SSID/PW. There are some solutions in other forums that store additional SSID/PW's into Flash or EEPROM. But I don't think this is safe !!!!

Therefore my question, does anybody know how to add support for two (or more) SSID/PW's storage with the ESP32-SDK ???

<!-- gh-comment-id:1827688795 --> @iKK001 commented on GitHub (Nov 27, 2023): Thanks for your feedback. Same here I wanted to get into this myself - but I had to realize, I am just not knowledgable enough to dare to get into the ESP32-SDK storage of SSID/PW. There are some solutions in other forums that store additional SSID/PW's into Flash or EEPROM. But I don't think this is safe !!!! Therefore my question, does anybody know how to add support for two (or more) SSID/PW's storage with the ESP32-SDK ???
Author
Owner

@dBitech commented on GitHub (Mar 14, 2024):

I too am intrested in a solution to this

<!-- gh-comment-id:1997175277 --> @dBitech commented on GitHub (Mar 14, 2024): I too am intrested in a solution to this
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#805
No description provided.