mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #620] Loss of connection after reboot operation #518
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#518
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 @ghost on GitHub (Jun 11, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/620
With Nodemcu works 100% even after reboot
With ESP-01you need to setup again (network selection, password and ...) after reboot
Is the hardware problem a software problem
@tablatronix commented on GitHub (Jun 11, 2018):
Did you try erasing the flash?
@tablatronix commented on GitHub (Jun 11, 2018):
So do you think it is not saving the wifi credentials on save ?
What do the serial logs say ?
@tablatronix commented on GitHub (Jun 11, 2018):
Hmmm same with the autoconnect example?
@ghost commented on GitHub (Jun 11, 2018):
autoconnect example
code
serial logs
⸮*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: AutoConnectAP
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Handle root
*WM: Scan done
*WM: Pro-Syrian.com
*WM: -57
*WM: DemirT
*WM: -73
*WM: Emirhan
*WM: -84
*WM: iPhone
*WM: -96
*WM: Sent config page
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Scan done
*WM: Pro-Syrian.com
*WM: -57
*WM: DemirT
*WM: -77
*WM: Emirhan
*WM: -87
*WM: iPhone
*WM: -92
*WM: Sent config page
*WM: Handle root
*WM: Handle root
*WM: Handle root
*WM: Scan done
*WM: Pro-Syrian.com
*WM: -58
*WM: DemirT
*WM: -73
*WM: iPhone
*WM: -91
*WM: Sent config page
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: WiFi save
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Connection result:
*WM: 4
*WM: Failed to connect.
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: WiFi save
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Already connected. Bailing out.
connected...yeey :)
serial logs
After separation of current
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.102
connected...yeey :)
@ghost commented on GitHub (Jun 11, 2018):
coode with blynk token
serial
⸮*WM: Adding parameter
*WM: Blynk
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 0
*WM: SET AP STA
*WM:
*WM: Configuring access point...
*WM: Blynk
*WM: AP IP address:
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Handle root
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Handle root
*WM: Handle root
*WM: Handle root
*WM: Scan done
*WM: Pro-Syrian.com
*WM: -51
*WM: DemirT
*WM: -78
*WM: Sent config page
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: WiFi save
*WM: Parameter
*WM: Blynk
*WM: de745e5d128647da853bb17127106bf7
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Connection result:
*WM: 3
[213913]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ / '/
///_, /////_
/__/ v0.5.2 on ESP8266
[213915] Connecting to blynk-cloud.com:80
[214073] Ready (ping: 1ms).
serial logs
After separation of current
*WM: Blynk
*WM:
*WM: AutoConnect
*WM: Connecting as wifi client...
*WM: Using last saved values, should be faster
*WM: Connection result:
*WM: 3
*WM: IP Address:
*WM: 192.168.1.102
[3680]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ / '/
///_, /////_
/__/ v0.5.2 on ESP8266
[3687] Connecting to blynk-cloud.com:80
[3831] Invalid auth token
[8831] Connecting to blynk-cloud.com:80
[8973] Invalid auth token
[13974] Connecting to blynk-cloud.com:80
[14113] Invalid auth token
[19114] Connecting to blynk-cloud.com:80
[19251] Invalid auth token
[24252] Connecting to blynk-cloud.com:80
[24390] Invalid auth token
[29391] Connecting to blynk-cloud.com:80
[29717] Invalid auth token
[34718] Connecting to blynk-cloud.com:80
[35149] Invalid auth token
[40150] Connecting to blynk-cloud.com:80
[40287] Invalid auth token
[45288] Connecting to blynk-cloud.com:80
[45424] Invalid auth token
@tablatronix commented on GitHub (Jun 11, 2018):
so now you get connection result of 3, sounds like your router
@ghost commented on GitHub (Jun 11, 2018):
[45288] Connecting to blynk-cloud.com:80
[45424] Invalid auth token
It is connected to the Internet but is offline with Blynk
@joeldhenry commented on GitHub (Dec 13, 2020):
it appears that wifi manager doesn't save parameters like it does the ssid and password. i think you must implement your own custom saving code, so that after a reboot the token still exists.
@tablatronix commented on GitHub (Dec 14, 2020):
pretty much yes, WM has no native FS dependancy