mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 09:05:56 +03:00
[GH-ISSUE #585] Can't seem to successfully restart after resetSettings() #488
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#488
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 @cmarrin on GitHub (Apr 7, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/585
Basic Infos
Hardware
WiFimanager Branch: Development
Esp8266
Hardware: WeMos D1 Menu
Core Version: tip of tree
Description
I'm building a clock with a WeMos D1 Mini. Everything works. The system comes up, network connects (credentials are already there), it fetches data from Weather Underground, snags the current time and displays it.
If I use the hack of calling resetSettings before calling autoConnect, that works too. I connect to the AP from my iPhone, it brings up the web page, I tap on my SSID, enter the password and hit save. The system starts back up and all is well.
But now I've added a menu which allows me to reset the network and start over. It dutifully brings up the config portal, I enter my credentials and hit save. But this time, it says "*WM: 5000 ms connectTimeout set, waiting for connect...." at which point it outputs dots for 5 seconds and then starts the config portal again. If I reset the ESP at this point it boots back up, connects to the network and everything works.
I've tried lots of things. It seems like WifiManager is getting itself into a funny state that it can't get out of. Any ideas?
Settings in IDE
Module: NodeMcu, Wemos D1
Additional libraries:
Sketch
https://github.com/cmarrin/Clocks/blob/master/OfficeClock/OfficeClock.ino
Libraries
My own
https://github.com/cmarrin/m8r
with these includes
#include <m8r.h>
#include <m8r/Blinker.h>
#include <m8r/BrightnessManager.h>
#include <m8r/ButtonManager.h>
#include <m8r/Max7219Display.h>
#include <m8r/StateMachine.h>
#include <m8r/WUnderground.h>
And these libraries installed from the LibraryManager
#include <WiFiManager.h>
#include <Ticker.h>
#include <Adafruit_GFX.h>
#include <Max72xxPanel.h>
#include <JsonListener.h>
#include <JsonStreamingParser.h>
#include <ESP8266HTTPClient.h>
WiFiManager requires PR https://github.com/tzapu/WiFiManager/pull/584
@tablatronix commented on GitHub (Apr 7, 2018):
I will look, are you setting a connecttimeout to 5s ?
@cmarrin commented on GitHub (Apr 8, 2018):
Doesn't look like there's an option for that. After the ConfigPortal succeeds, it uses _saveTimeout and I don't see any way to modify that with the public API. I did try changing the value to 10 seconds and that didn't help.
But I have more information. My system scrolls a message telling the user to go to the config portal to setup. That message is still scrolling when it tries to connect. When I turn off that message it succeeds, so I think my scroller is starving the network logic.
But then I have another problem. The first thing I do on startup is to try to access a server using HttpClient and that fails. When I reset and the network starts normally from boot, it accesses it fine
@cmarrin commented on GitHub (Apr 8, 2018):
And I'm finding that it's not just a timing issue, where I'm trying to access the network too soon. When the network sets up after a successful run of the ConfigPortal, it is not setup correctly. On a fail I try to use HttpClient to talk to the network again and it always fails.
@tablatronix commented on GitHub (Apr 8, 2018):
connectTimeout is a user setting
@tablatronix commented on GitHub (Apr 8, 2018):
your sketch doesn't exist
@cmarrin commented on GitHub (Apr 8, 2018):
Sorry, sketch url updated.
It's not using the connectTimeout when restarting. It using the saveTimeout which I don't see any api to change.
I have a solution!!!
Not sure why, but after the config portal runs and succeeds it sets up the network. But it seems to set it up incorrectly because it can't connect to anything. I'm readying WiFi.localIP() which is correct. But doing this:
with a valid URL times out.
So I added a callback with setAPCallback and when it fires I set a flag. On return from autoConnect() if that flag is set I do ESP.reset() to restart the system and it comes back up normally and succeeds.
This is a good workaround for me. Is there any information I can gather to help understand why the network didn't come up correctly after ConfigPortal?
@tablatronix commented on GitHub (Apr 8, 2018):
Ohh yeah I just added savetimeout change it could be a bug
@tablatronix commented on GitHub (Apr 8, 2018):
Give me the entire log, you can increase the debug level in .h to 3 also.
So to summarize after autoconnect fail, configportal save, network does not actually work? Or your httpd doesnt work?
@cmarrin commented on GitHub (Apr 8, 2018):
I increased the debug level to DEVELOPER. Here are the logs.
Coming up normally:
Office Clock v1.0
*WM: [1] AutoConnect
*WM: [2] Connecting as wifi client...
*WM: [3] wifi station disconnect
*WM: [1] Connecting to saved AP: marrin
*WM: [3] enableSTA PERSISTENT ON
*WM: [1] connectTimeout not set, ESP waitForConnectResult...
*WM: [2] Connection result: WL_CONNECTED
*WM: [3] lastconxresult: WL_CONNECTED
*WM: [1] IP Address: 10.0.1.109
Wifi connected, IP=10.0.1.109
Getting weather and time feed...
URL='http://api.wunderground.com/api/xxxxxxxxxxxxxxxx/conditions/forecast/q/CA/Los_Altos.json?a=9069'
got response: 200
Got payload, parsing...
Time set to:Sun Apr 08, 2018 08:39:12 AM, next setting in 1308 seconds
Temps - current:51, low:48, high:65
After asking it to reset network settings:
*WM: [3] unloading
*WM: [1] SETTINGS ERASED
*WM: [3] enableSTA PERSISTENT ON
*WM: [1] AutoConnect
*WM: [2] Connecting as wifi client...
*WM: [3] wifi station disconnect
*WM: [1] No saved credentials, skipping wifi
*WM: [2] Connection result: WL_NO_SSID_AVAIL
*WM: [3] lastconxresult: WL_NO_SSID_AVAIL
*WM: [3] wifi station disconnect
*WM: [2] Disabling STA
*WM: [2] Enabling AP
*WM: [1] StartAP with SSID: MT Galileo Clock
*WM: [2] AP has anonymous access!
*WM: [1] AP IP address: 192.168.4.1
Entered config mode:ip=192.168.4.1, ssid='MT Galileo Clock'
*WM: [3] setupConfigPortal
*WM: [1] Starting Web Portal
*WM: [3] dns server started with ip: 192.168.4.1
*WM: [2] HTTP server started
*WM: [2] WiFi Scan done
*WM: [2] Config Portal Running, blocking, waiting for clients...
*WM: [2] NUM CLIENTS: 0
After entering credentials into config portal:
*WM: [2] NUM CLIENTS: 0
*WM: [3] -> captive.apple.com
*WM: [2] <- Request redirected to captive portal
*WM: [2] <- HTTP Root
*WM: [3] -> 192.168.4.1
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] WiFi Scan done
*WM: [3] -> captive.apple.com
*WM: [2] <- Request redirected to captive portal
*WM: [2] <- HTTP Root
*WM: [3] -> 192.168.4.1
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] Scan is cached
*WM: [3] -> captive.apple.com
*WM: [2] <- Request redirected to captive portal
*WM: [2] <- HTTP Root
*WM: [3] -> 192.168.4.1
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] Scan is cached
*WM: [2] <- HTTP Wifi
*WM: [2] Scan is cached
*WM: [1] 7 networks found
*WM: [2] DUP AP: marrin
*WM: [2] DUP AP: xfinitywifi
*WM: [2] AP: -24 marrin
*WM: [2] AP: -81 PabellonExt2.4
*WM: [2] AP: -84 ATT296
*WM: [2] AP: -88 xfinitywifi
*WM: [2] AP: -95 BNAN wifi
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [3] Sent config page
*WM: [3] -> captive.apple.com
*WM: [2] <- Request redirected to captive portal
*WM: [2] <- HTTP Root
*WM: [3] -> 192.168.4.1
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] Scan is cached
*WM: [3] -> captive.apple.com
*WM: [2] <- Request redirected to captive portal
*WM: [2] <- HTTP Root
*WM: [3] -> 192.168.4.1
*WM: [3] lastconxresult: WL_IDLE_STATUS
*WM: [2] WiFi Scan done
*WM: [2] <- HTTP WiFi save
*WM: [3] Method: POST
*WM: [3] Sent wifi save page
*WM: [2] process connect
*WM: [2] Connecting as wifi client...
*WM: [3] wifi station disconnect
*WM: [1] Connecting to new AP: marrin
*WM: [3] enableSTA PERSISTENT ON
*WM: [1] 5000 ms connectTimeout set, waiting for connect....
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] .
*WM: [2] Connection result: WL_CONNECTED
*WM: [3] lastconxresult: WL_CONNECTED
*WM: [1] Connect to new AP [SUCCESS]
*WM: [1] Got IP Address:
*WM: [1] 10.0.1.109
*WM: [2] disconnect configportal
*WM: [1] config portal exiting
Wifi connected, IP=10.0.1.109
Getting weather and time feed...
URL='http://api.wunderground.com/api/xxxxxxxxxxxxxxxx/conditions/forecast/q/CA/Los_Altos.json?a=67207'
[HTTP] GET... failed, error: connection refused(-1)
Time set to:Sun Apr 08, 2018 08:45:01 AM, next setting in 120 seconds
Temps - current:52, low:48, high:65
@cmarrin commented on GitHub (Apr 8, 2018):
And I retry the URL every 2 minutes and it remains unable to connect. If I reset manually or add my logic to do ESP.reset() after config portal runs, all is well
@tablatronix commented on GitHub (Apr 8, 2018):
K thanks, did you add a getmode to your code to see if sta mode is active after wm returns to your code?
@cmarrin commented on GitHub (Apr 9, 2018):
I just checked. It's in STA+AP mode, which is what it's in when it's working, so it doesn't seem like that's it
@tablatronix commented on GitHub (Apr 9, 2018):
K thanks, I will try to test and make a sketch.
Are you using latest staging of all libs?
@cmarrin commented on GitHub (Apr 9, 2018):
I'm using the latest released versions of everything, installed via Library Manager. The exception is Adafruit_GFX, where I'm using my own fork with one small change. My plan is to move the change I made there (the ability to get the xAdvance of a given character) into my own sketch so I won't need that anymore. I assume you won't be using any of that display logic in whatever test you're doing.
I will try to make a smaller test case on my end as well
Thanks
@tablatronix commented on GitHub (Apr 9, 2018):
latest released?
as in esp8266 2.4.1? You know it has some major bugs right?
have you tried, master/staging to see if this is a esp8266 bug that has been fixed?
@cmarrin commented on GitHub (Apr 9, 2018):
Oh, sorry. Wasn't thinking about the ESP toolchain. I did try 2.4.1 and it did not go well. I'm using 2.3.0 which I've been using for quite a while and it seems pretty stable.
@tablatronix commented on GitHub (Apr 9, 2018):
2.3.0 has even bigger bugs. It doesnt even erase flash properly and currupts your flash.
@cmarrin commented on GitHub (Apr 9, 2018):
Hmmm. I haven't been doing a lot with Flash storage lately. What version do you use?
Just for some background. I've used LOTS of versions of the ESP8266 SDK and many ways of building and running ESP code. Arduino has annoyed me in the past because it has a lot of RAM overhead. Building raw, using https://github.com/pfalcon/esp-open-sdk, I was finding I could save 5K or more. But that required me to use a custom Makefile and didn't give me all the nice Arduino libraries. So I bit the bullet and came back to Arduino. The Arduino toolchain has gotten more efficient in later versions and I've gotten aggressive about using PROGMEM, so my memory usage is fine now.
@tablatronix commented on GitHub (Apr 9, 2018):
Flash as in wifi settings not eeprom. I added erase flash workarounds in dev but you have to enable it
@tablatronix commented on GitHub (Apr 10, 2018):
I just fixed that savetimeout turns out 5 seconds was too short, I removed it entirely.
@cmarrin commented on GitHub (Apr 10, 2018):
Thanks, I'll update and retry. What version of the ESP SDK do you use?
@tablatronix commented on GitHub (Apr 10, 2018):
I use staging for dev, but I like 2.4.1
@tablatronix commented on GitHub (Apr 10, 2018):
2.3.0 is ok, but you have to work around some issues #430
But this is going away fast, because its sdk 1.5.3