mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #1214] On demand portal: Updating (just) password does not save and then does not shut down portal #1033
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#1033
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 @OldGreyCells on GitHub (Feb 16, 2021).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1214
Basic Infos
Hardware
WiFimanager Branch/Release: Development
Esp8266/Esp32:
Hardware: ESP-12e
Core Version: 2.4.0, staging
Description
When re-entering the AP portal on demand:
Expected results
New password is saved and the WiFI [re]connected using new value.
Actual Result:
Updated password is not saved, the client is dropped (from the AP) and WiFi is disconnected - messages from wm:
The AP portal then keeps running, ignoring the
wm.setConfigPortalTimeout(140);(I suspect I have to stop the portal programmatically, but would expect the portal timeout to be honoured.)
Possibly another issue: If the SSID is selected and a wrong password is entered for the currently connected network, I would expect to disconnect from current network - this isn't the case.
Settings in IDE
Module: Wemos D1
Additional libraries: None
Debug Messages
@tablatronix commented on GitHub (Feb 16, 2021):
These are 2 conditions that I think are undefined
I will take a look, pretty sure I do not have issues for these yet, thanks
@OldGreyCells commented on GitHub (Feb 16, 2021):
I think this is similar to #1203 in that it's partly a UI issue - the SSID looks like it is filled in but at save time it is not set (as in
*WM: [2] No ssid, skipping wifi save).Everything works as expected if you select or fill in the SSID on the portal (apart from remaining connected to the existing network if you deliberately set the wrong password - this could be very confusing because the user will think they've entered the right password until the device is reset... - perhaps a separate issue to raise?
@joannela commented on GitHub (Aug 24, 2021):
hi there! i am having this exact same issue. did it get resolved? i am working with v 0.14.