starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-27 00:55:52 +03:00

[GH-ISSUE #1752] Enhancement request : reconnect to AP when available, even if portal was started #1485

New issue

Closed

opened 2026-02-28 01:30:15 +03:00 by kerem · 8 comments

kerem commented

2026-02-28 01:30:15 +03:00

Owner

Originally created by @alka79 on GitHub (Jul 16, 2024).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1752

For static devices, most of the time, connection loss is due to AP reboot or power failure.
In that situation, you mostly just want to reconnect to the AP as soon as it is back online and avoid long timeouts.

My I suggest the following behaviour: (I am thinking non-blocking )
When portal is automatically started because of AP connection loss, run every N seconds a passive scan for APs in the background .
When the AP is available again and no-one is connected to the portal, close the portal and reconnect to AP immediately.

Hope you will consider,

Originally created by @alka79 on GitHub (Jul 16, 2024). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1752 For static devices, most of the time, connection loss is due to AP reboot or power failure. In that situation, you mostly just want to reconnect to the AP as soon as it is back online and avoid long timeouts. My I suggest the following behaviour: (I am thinking non-blocking ) When portal is automatically started because of AP connection loss, run every N seconds a passive scan for APs in the background . When the AP is available again and no-one is connected to the portal, close the portal and reconnect to AP immediately. Hope you will consider,

kerem closed this issue

2026-02-28 01:30:15 +03:00

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@TheToymaker93 commented on GitHub (Nov 5, 2024):

@alka79 Did you figure out a way to get this working? I'm trying to achieve a similar thing and having no luck. Don't suppose you came up with a work-around?

@TheToymaker93 commented on GitHub (Nov 5, 2024): @alka79 Did you figure out a way to get this working? I'm trying to achieve a similar thing and having no luck. Don't suppose you came up with a work-around?

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@gpena208777 commented on GitHub (Nov 13, 2024):

Bumping this

@gpena208777 commented on GitHub (Nov 13, 2024): Bumping this

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@klasik16 commented on GitHub (Jan 3, 2025):

We all need this feture. in other case this lib cannot be used in serious projects.

@klasik16 commented on GitHub (Jan 3, 2025): We all need this feture. in other case this lib cannot be used in serious projects.

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@klasik16 commented on GitHub (Jan 3, 2025):

@tablatronix what about this?

@klasik16 commented on GitHub (Jan 3, 2025): @tablatronix what about this?

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@phelbas commented on GitHub (Apr 20, 2025):

This is a key usage problem with this library. If it cannot connect upon start up - for whatever transient reason! - and drops into config mode, the device becomes useless unless power cycled again.

@phelbas commented on GitHub (Apr 20, 2025): This is a key usage problem with this library. If it cannot connect upon start up - for whatever transient reason! - and drops into config mode, the device becomes useless unless power cycled again.

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@tablatronix commented on GitHub (Apr 20, 2025):

Setconfigportaltimeout

@tablatronix commented on GitHub (Apr 20, 2025): Setconfigportaltimeout

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@alka79 commented on GitHub (Apr 20, 2025):

@tablatronix Sorry to raise this again. Setconfigportaltimeout exists for a while, it is not an appropriate solution. It is pretty obvious IMHO when you try to use it.

How long do you set Setconfigportaltimeout ?

Either you set a short delay (say 30 sec) to have a relative fast reconnect after connection loss. But then you only have 30sec windows to connect to the Portal when it is really required, ie not realistic in real life.
To be practical, you MUST set Setconfigportaltimeout to a reasonably long delay, at least a few minutes. And then you ALWAYS wait for that timeout.
This is what I meant by "without waiting for long timeout". I did not elaborate, thinking that you would get the point.

I iimplemented the logic in my code. It works fine:

if wifi connection is lost for some delay, open softAP (Portal). No timeout so that I can connect to softAP if needed.
while softAP is open, scan for AP in the background every 5 secs.
if AP is available again and no-one is connected to softAP, reconnect to AP and close softAP.

I also added led blinking to visually indicate that SoftAP is open.

@alka79 commented on GitHub (Apr 20, 2025): @tablatronix Sorry to raise this again. Setconfigportaltimeout exists for a while, it is not an appropriate solution. It is pretty obvious IMHO when you try to use it. How long do you set Setconfigportaltimeout ? Either you set a short delay (say 30 sec) to have a relative fast reconnect after connection loss. But then you only have 30sec windows to connect to the Portal when it is really required, ie not realistic in real life. To be practical, you MUST set Setconfigportaltimeout to a reasonably long delay, at least a few minutes. And then you ALWAYS wait for that timeout. This is what I meant by "without waiting for long timeout". I did not elaborate, thinking that you would get the point. I iimplemented the logic in my code. It works fine: - if wifi connection is lost for some delay, open softAP (Portal). No timeout so that I can connect to softAP if needed. - while softAP is open, scan for AP in the background every 5 secs. - if AP is available again and no-one is connected to softAP, reconnect to AP and close softAP. I also added led blinking to visually indicate that SoftAP is open.

kerem commented

2026-02-28 01:30:16 +03:00

Author

Owner

@tablatronix commented on GitHub (Apr 20, 2025):

Set it to 30 seconds and reboot. This was supposed to leverage esp autoreconnect. But it seems to be unreliable. I will see about this.

The proper workflow should be

User code logic, reboot counter, autoconnect loop for 60seconds etc. reboot and retry whatever.

Start cp

User loop check for wifi status changes or use wifi events, stop cp etc.

Not sure there is a surefire way to implement in library not user code. I will find issues with autoreconnect and see about doing automatic scan for ap callbacks or auto exit cp config

You can always use reconnecttimeout of 60 seconds and cp for 2 minutes

@tablatronix commented on GitHub (Apr 20, 2025): Set it to 30 seconds and reboot. This was supposed to leverage esp autoreconnect. But it seems to be unreliable. I will see about this. The proper workflow should be User code logic, reboot counter, autoconnect loop for 60seconds etc. reboot and retry whatever. Start cp User loop check for wifi status changes or use wifi events, stop cp etc. Not sure there is a surefire way to implement in library not user code. I will find issues with autoreconnect and see about doing automatic scan for ap callbacks or auto exit cp config You can always use reconnecttimeout of 60 seconds and cp for 2 minutes