[GH-ISSUE #216] AP mode stuck on after STA re-connected #175

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

Originally created by @mtnbrit on GitHub (Aug 13, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/216

Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks.

Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no?

Originally created by @mtnbrit on GitHub (Aug 13, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/216 Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks. Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no?
kerem closed this issue 2026-02-28 01:23:50 +03:00
Author
Owner

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

hi,

that s what should happen, when connected it goes back to STA mode.

do you still see the ap’s after some time? some devices just seem to cache the list of avaiable APs for a while…

cheers

On 13 Aug 2016, at 09:06, mtnbrit notifications@github.com wrote:

Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks.

Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/216, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2FkLzBmBt6WhgY5T794GSfkXhEgKCpks5qfV8AgaJpZM4JjndB.

<!-- gh-comment-id:239798212 --> @tzapu commented on GitHub (Aug 15, 2016): hi, that s what should happen, when connected it goes back to STA mode. do you still see the ap’s after some time? some devices just seem to cache the list of avaiable APs for a while… cheers > On 13 Aug 2016, at 09:06, mtnbrit notifications@github.com wrote: > > Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks. > > Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/216, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2FkLzBmBt6WhgY5T794GSfkXhEgKCpks5qfV8AgaJpZM4JjndB.
Author
Owner

@mtnbrit commented on GitHub (Aug 15, 2016):

Definitely it stays in AP+STA mode, still see the ssid permanently.

Sent from my iPhone6

On Aug 15, 2016, at 6:13 AM, tzapu notifications@github.com wrote:

hi,

that s what should happen, when connected it goes back to STA mode.

do you still see the ap’s after some time? some devices just seem to cache the list of avaiable APs for a while…

cheers

On 13 Aug 2016, at 09:06, mtnbrit notifications@github.com wrote:

Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks.

Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/216, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2FkLzBmBt6WhgY5T794GSfkXhEgKCpks5qfV8AgaJpZM4JjndB.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<!-- gh-comment-id:239844909 --> @mtnbrit commented on GitHub (Aug 15, 2016): Definitely it stays in AP+STA mode, still see the ssid permanently. Sent from my iPhone6 > On Aug 15, 2016, at 6:13 AM, tzapu notifications@github.com wrote: > > hi, > > that s what should happen, when connected it goes back to STA mode. > > do you still see the ap’s after some time? some devices just seem to cache the list of avaiable APs for a while… > > cheers > > > On 13 Aug 2016, at 09:06, mtnbrit notifications@github.com wrote: > > > > Hi, Im seeing my devices are all showing their config APs after they lost connection to their normal AP today. So they lost connection to the stored AP in STA mode, after the timeout, the config AP is started, then the normal AP comes back and they re-connect in STA mode, but in fact its in AP+STA mode as I still see the APs broadcasting in my wifi networks. > > > > Even if they are in config mode, clearly if they are able to reconnect to the stored ssid, then config AP mode should be canceled and just go back to regular STA mode, no? > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub https://github.com/tzapu/WiFiManager/issues/216, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2FkLzBmBt6WhgY5T794GSfkXhEgKCpks5qfV8AgaJpZM4JjndB. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or mute the thread.
Author
Owner

@kentaylor commented on GitHub (Sep 25, 2016):

Your issue reads to me as:-

  1. AP is missing so as specified by autoconnect go into config mode.
  2. AP comes back, connects to network but device stays in config mode.

If so, that is how WiFiManager is programmed to behave. It will connect back to the network because it is simultaneously in AP and STA mode as configured at github.com/tzapu/WiFiManager@028bdeeb17/WiFiManager.cpp (L154) but remains in config mode. That is an undesirable situation in my view. You can put a timeout on config mode so it will drop out of config mode after a while which may work for you.

You would like it to go out of AP mode when it successfully reconnected and it could be programmed that way but there is problems with that logic. It would then become impossible to change networks when a network to which it can connect is visible and many applications should still function even without a WiFi network so for those applications you don't want it to jump into config mode every time the WiFi network goes away.

I don't think there is any way to automatically know when it should go into config mode, only a human has the knowledge of whether a new network is required or it is better to wait for the network to come back. Therefore you require a human to initiate config mode and here is an example that works that way - https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitch .

<!-- gh-comment-id:249451001 --> @kentaylor commented on GitHub (Sep 25, 2016): Your issue reads to me as:- 1. AP is missing so as specified by autoconnect go into config mode. 2. AP comes back, connects to network but device stays in config mode. If so, that is how WiFiManager is programmed to behave. It will connect back to the network because it is simultaneously in AP and STA mode as configured at https://github.com/tzapu/WiFiManager/blob/028bdeeb17ef12b8dc0c2fc05fc3ae4bc102ba70/WiFiManager.cpp#L154 but remains in config mode. That is an undesirable situation in my view. You can put a timeout on config mode so it will drop out of config mode after a while which may work for you. You would like it to go out of AP mode when it successfully reconnected and it could be programmed that way but there is problems with that logic. It would then become impossible to change networks when a network to which it can connect is visible and many applications should still function even without a WiFi network so for those applications you don't want it to jump into config mode every time the WiFi network goes away. I don't think there is any way to automatically know when it should go into config mode, only a human has the knowledge of whether a new network is required or it is better to wait for the network to come back. Therefore you require a human to initiate config mode and here is an example that works that way - https://github.com/kentaylor/WiFiManager/tree/master/examples/ConfigOnSwitch .
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#175
No description provided.