mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 09:05:56 +03:00
[GH-ISSUE #336] Unable to connect to a new AP if currently connected to the old AP #280
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#280
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @babitsky on GitHub (Mar 22, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/336
Hello,
I'm calling startConfigPortal on demand.
The module is currently connected to AP "x".
Using the config portal, I select a new AP "y", with new credentials.
The module attempts to connect to the new AP "y", but "fails" (inappropriate optimization for this scenario) since it remains connected to "x":
New AP "y" and its credentials are therefore lost.
Module remains connected to "x".
@pbecchi commented on GitHub (Mar 25, 2017):
I have exactly the same problem!
One I am connected to an AP I cannot change it with startconfigportal call!
@telanoc commented on GitHub (Mar 30, 2017):
I would add
WiFi.disconnect(true)to force a disconnection (and clearing of saved credentials) before callingstartConfigPortal().@tzapu commented on GitHub (Mar 30, 2017):
hi guys,
this is a bug in the library, the disconnect trick will work as a workaround
cheers
@mouk commented on GitHub (Apr 18, 2017):
@tzapu has this bug been reported?
@babitsky commented on GitHub (Apr 18, 2017):
@telanoc I'm not sure clearing the credentials is the best solution... At least not for my application.
My suggestion is to add a check in
connectWifi()to make sure the "Already connected. Bailing out." code is not executed when connecting to a new SSID (the&& (WiFi.SSID() == ssid)part):I plan to submit it as a pull request one day, when I learn how to do it :)
So far, it seems to have solved the problem for me completely.