mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-28 01:25:49 +03:00
[GH-ISSUE #1103] calling setDebugOutput(false) causes autoconnect to fail and go straight to config (DEV BRANCH 2.0.3) #943
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#943
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 @tavdog on GitHub (Aug 2, 2020).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1103
Basic Infos
Using Adafruit featheresp32 target with platformio. Problem is not present on Adafruit huzzahesp8266
Hardware
WiFimanager Branch/Release:
Esp8266/Esp32:
Hardware: ESP-12e, esp01, esp25
ESP Core Version: 2.4.0, staging
Description
With wifi already configured, if device is flashed with code that executes wm.setDebugOutput(false) autoconnect fails immiediatly (does not wait for connect timeout) and goes straight to config portal. The device connects file if calling wm.setDebugOutput(true) or line ommitted.
Settings in IDE
Module: featheresp32
Additional libraries:
Sketch
Debug Messages
@tablatronix commented on GitHub (Aug 2, 2020):
I dont understand this says
Which is not cp ...
@tavdog commented on GitHub (Aug 2, 2020):
That is output when debugOutput is at default or set to true. The failure case is the first pasted block
FAILURE OUTPUT when debugOutput is set to false
Here output stops and it goes straight into configportal without connectiong.
@tablatronix commented on GitHub (Aug 2, 2020):
Hmm ill test it here and see if I can reproduce.
@tavdog commented on GitHub (Aug 3, 2020):
The logging stops because it is at that point that setDebugOutput(false) is called. My hunch is that it might just be a weird issue with esp32 and timing. Since it takes more cycles to print out the debugging info it gives the esp32 more time to connect in the background maybe ? I'll test by adding a delay and see if that helps.
Here is more of the preceding code that shows the parameters added then the debug call.
...... nope. setting a 10sec delay did not help.
@tavdog commented on GitHub (Aug 3, 2020):
Found it ! removing the line : wm.setConnectTimeout(15); fixed it. Also calling with a much larger number (15000) fixes it.
Hmm. Well, thanks for your time and a great library.
@tablatronix commented on GitHub (Aug 3, 2020):
There is an ongoing ESP32 bug that several people with certain routers are having where connections take a very long time, if you remove the timeout it will use the default esp32 connect wait loop.
I think may be you experiencing this issue , where it always fails on first connection.
I find it odd that you thought debugoutput had something to do with it.. that is a bit odd if it was true.
#1067