mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #424] Using autoconnect to connect to WIFI, then startConfigPortal, fails to connect/save new credentials #355
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#355
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 @Jsolo1 on GitHub (Sep 15, 2017).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/424
Hi, the idea is the following, by default I'm using Autoconnect to connect to a saved wifi network, but I also want to bring up the Configuration Portal by pressing a button.
It connects to wifi fine, it brings up the portal fine in case I press the button, but if I select a new wifi SSID and password, it seems to ignore it, It doesn't connect to it and it doesn't save the credentials.
From the code it never resets even if it hits the timeout.
Any idea? Thanks
@tablatronix commented on GitHub (Sep 15, 2017):
Did you enable debug and watch serial monitor when saving?
@Jsolo1 commented on GitHub (Sep 15, 2017):
I think I found what the problem is.
In the function :
If it's already connected, it doesn't try to connect again. Even commenting the lines:
Still doesn't work because WiFi.begin() won't work if there is already a connection made.
So the only solution would be to disconnect the Wifi (without deleting the credetials) and then try to connect again.
Maybe something like:
WiFi.disconnect(false);Or
Would do the trick?
@Jsolo1 commented on GitHub (Sep 15, 2017):
Yes, it works! This is the code:
The only problem are those commented lines to "fix for auto connect racing issue" Any idea what do they do?
Thanks
@tablatronix commented on GitHub (Sep 15, 2017):
Yeah thats a known issue, already fixed in next release.
I have no idea what those lines are for, either, I think it is to handle a race condition when the esp is already connecting internally. I think there are some bugs in the older sdk that say do not call begin when already connected, ir it can crash, so they disconnect first, this just bails.
#407
@Jsolo1 commented on GitHub (Sep 20, 2017):
Thank you
@tablatronix commented on GitHub (Sep 20, 2017):
I think a workaround, would be to disconnect in your own code beforehand. Not sure if we can hotfix this or not