mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #832] Changing connection at runtime, second call of autoconnect() portal webpage issue #699
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#699
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 @Bjack795 on GitHub (Feb 21, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/832
Basic Infos
Hardware
WiFimanager Branch/Release:
Esp8266/Esp32:
Hardware: ESP-12e, esp01, esp25
Description
The first time I call autoconnect() function at startup() it's working fine.
Then if I want to change the connection at runtime and I call it again the portal webpage is not working, even though the events in the Serial monitor are the same and I'm able to create the hotspot, I simply can't get access to the portal webpage.
@tablatronix commented on GitHub (Feb 21, 2019):
You are calling autoconnect more than once? Not sure I understand
Code and logs help
@Bjack795 commented on GitHub (Feb 22, 2019):
I explain it better.
In my project your WiFimanager is called at startup with autoconnect() but I noticed that if I were outside my house the code was blocking there because no known wifi is found and it starts the portal loop never ending.
So I modified it slightly, in practise I trigger the timeout exit after 5 "NUM CLIENTS".
returning true for configPortalHasTimeout(). If I'm outside the code goes on after 5 apClientCheck.
If I want I can open the portal before the timeout and register a wifi station, all goes ok.
Then I wanted to call this configuration on demand and not automatically only at the beginning, because maybe when you turn on the device you're not near to a wifi to be connected but then you are.
Calling again autoconnect() in the middle of the operations it starts the portal if no wifi is known, it gives me the IP.
It also shows up the same [EVENTS] in the Serial Monitor (so no error is showing up) but when I connect to the created temporary wifi and I go to the IP address, the portal webpage is no more showing up.
In my opinion, the first time autoconnect() is used some variable is filled up and differs by default.
So on the second call something is going wrong and alla works fine till portal webpage which is not showing up.
I have studied your code but there is something I'm missing, maybe you could tell me why on the second call I have these problems.
Lastly I say that the second call it's happening in the same situation of the startup so I'm not already connected to any wifi even though I'm in the middle of runtime.
Thank you
@Bjack795 commented on GitHub (Feb 22, 2019):
I put the two Serial outputs
FIRST CALL
SECOND CALL
In the first call I was so fast that NUM CLIENTS is not shown for the first time.
In the second call I never reach *WM: [3] -> connectivitycheck.android.com"
@tablatronix commented on GitHub (Feb 22, 2019):
event: mismatch or invalid event#776
We have not figured out what this is yet, seems like a esp lib bug
@tablatronix commented on GitHub (Feb 22, 2019):
esp said that is a harmless error, but it is odd...
you never get to
*WM: [3] -> connectivitycheck.android.com"because your device is not connecting, or failing dns
No idea what would be causing it, I will try to test this, maybe try with startconfigportal, I have used that after autoconnect with no issues
@Bjack795 commented on GitHub (Feb 22, 2019):
Ok I'll try thank you!
@tablatronix commented on GitHub (Feb 22, 2019):
can you try a different client device also just to see
@Bjack795 commented on GitHub (Feb 22, 2019):
I've only my Wemos D32 pro V2
@Bjack795 commented on GitHub (Feb 22, 2019):
I've tried only the startconfigportal, but the problem is the same.
I can see the hotspot, connect to it but then I can't load the options page to connect to a WiFi.
@tablatronix commented on GitHub (Feb 22, 2019):
I mean with another device, like a computer
@Bjack795 commented on GitHub (Feb 22, 2019):
Oh excuse me I didn't see "client" word.
I'll try from the pc.
@tablatronix commented on GitHub (Feb 23, 2019):
I am curious to see if this is some kind of dns issue, have you noticed if the ip is changing the second time?
@Bjack795 commented on GitHub (Feb 23, 2019):
So
Your curiosity could be well posed since I had to add a line to your library some weeks ago for another problem.
Since when I was restarting the board (even the autorestart after the uploading of a new script) the first time it was giving me error 202 that is AUTH_FAIL and the code was blocked there without continuing.
Then restarting again all worked fine.
So I modified the code inserting an ESP.restart() in correspondence of AUTH_FAIL occurrence and I solved that problem.
A friend of mine suggested that it could have been a problem related to the Local IP address (that was always remaining the same) and lease time, since I can't put it as continuos.
In practise my D32 was trying to connect with that IP at first restart-> AUTH_FAIL
Then with another restart -> all fine.
So in my opinion this problem could be related to that, but now it's not exiting with AUTH_FAIL since my ESP is not restarting automatically.
@Bjack795 commented on GitHub (Feb 23, 2019):
PS.
The problem happens either if at startup a connection is established or not.
@tablatronix commented on GitHub (Feb 23, 2019):
I was going to say maybe it is your router, sometimes routers do not let a reconnection so quickly because they think the ip is still connected, but it is probably not that. The test would be to have some delay and call a disconnect between the 2 autoconnects, sounds like maybe the state gets messed up by the first, and a disconnect might fix it WiFi.disconnect(this erased credentials) or a wifi off
@Bjack795 commented on GitHub (Feb 23, 2019):
It can't be the router since if I disconnect the wifi and I call again autoconnect() it connects to the wifi if it has the credentials.
The problem of the double call is on the portal side (that is independent on the router since I can choose my neighbour wifi if I want).
I tried either the WiFi.disconnect(true/false) and the WiFi.mode(WIFI_OFF).
Trying autoconnect() or portalconfig() and none of them changed anything.
The portal is working only at startup.
The connection to a memorized wifi is always working.
@tablatronix commented on GitHub (Feb 23, 2019):
ok I will see if I can reproduce, and you have the latest pull from development?
And you have a current revision esp32?
@Bjack795 commented on GitHub (Feb 23, 2019):
I've downloaded it in December maybe I give it a try with the newest one before making you work.
Yup I have the current revision esp32.
@Bjack795 commented on GitHub (Feb 23, 2019):
Ok same problem with the latest pull from development.
@tablatronix commented on GitHub (Feb 23, 2019):
Where is your wm obj declared, new everytime, or a global ?
@tablatronix commented on GitHub (Feb 23, 2019):
confirmed, using global wm instance.
Last event is staipassigned, I see no client requests either which is odd, I wonder if forgetting the ap will change this, it is as if the client does not ping captive portal cause it thinks it has a good connection, or does not even try.. I am thinking maybe some dhcp session is still the same, not sure how dhcp works, but maybe we can fix somehow
@tablatronix commented on GitHub (Feb 23, 2019):
now its working fine, hmm
@tablatronix commented on GitHub (Feb 23, 2019):
It only happened once, Cannot do it again, works everytime...
@Bjack795 commented on GitHub (Feb 23, 2019):
My wm is always new but I tried also to define it globally in the past.
So your last code is working?
I test it and I tell you.
Thank you.
@tablatronix commented on GitHub (Feb 23, 2019):
I think they were both working, I had once time where it just sat there. Not sure what to make of this.
@Bjack795 commented on GitHub (Feb 23, 2019):
I tried your code with a different "trigger" for the autoconnect()
The first time I called it, it worked, the second time it didn't:
(I've erased the settings to start again the portal, otherwise it would have connected to the saved wifi)
@tablatronix commented on GitHub (Feb 23, 2019):
Can you connect manually? 192.16.4.1?
@Bjack795 commented on GitHub (Feb 24, 2019):
To the portal IP?
What do you mean with "manually"?
@tablatronix commented on GitHub (Feb 24, 2019):
goto web browser and goto it manually, to see if its just the captive portal that is not working
@Bjack795 commented on GitHub (Feb 24, 2019):
I've always done like this, I used the captive portal only twice.
@tablatronix commented on GitHub (Feb 24, 2019):
interesting, can you ping it ?
@Bjack795 commented on GitHub (Feb 24, 2019):
On the second call of autoconnect():
4 packages sent
4 received
min: 1 ms
max: 15 ms
average: 6 ms
@tablatronix commented on GitHub (Feb 24, 2019):
right so its there, and when to goto http://192.168.4.1, you get a timeout ?
@Bjack795 commented on GitHub (Feb 24, 2019):
I can connect to the portal but the access page is not available and of course then it results in a timeout since I simply can't reach the page.
@tablatronix commented on GitHub (Feb 24, 2019):
and how are you closing the first autoconnect? letting it timeout, pressing exit, saving?
@tablatronix commented on GitHub (Feb 24, 2019):
It sounds like the webserver is not setting up correctly the second time.. maybe there is some debugging we can enable, let me check.
@Bjack795 commented on GitHub (Feb 24, 2019):
It depends, I tried both connecting and saving or leaving it to timeout.
@tablatronix commented on GitHub (Feb 24, 2019):
And you are using the example plain, not adding any libraries atm.
have you tried a full flash erase ( desepration )
@Bjack795 commented on GitHub (Feb 24, 2019):
I'm using a plain example (the one posted before).
How can I do a full flash erase?
@tablatronix commented on GitHub (Feb 24, 2019):
you can use esptool , or there is an arduino board menu option, to erase all or wifi
@Bjack795 commented on GitHub (Feb 24, 2019):
I can't find this option here https://github.com/platformio/platform-espressif32/issues/127 in my IDE, since with esptool I'm scared to damage the board.
Where is that arduino IDE option?
@tablatronix commented on GitHub (Feb 24, 2019):
ohh right you use pio, I do also, in arduino IDE you can erase from the board menu I think
@Bjack795 commented on GitHub (Feb 25, 2019):
Nope I use Arduino IDE, the link was to show you the option I can't find.
Could you please tell me where this option is in the Arduino IDE?
@tablatronix commented on GitHub (Feb 25, 2019):
I don't use arduino, But it looks like the device menu
@Bjack795 commented on GitHub (Feb 25, 2019):
In my opinion that option is visible only for some kind of devices, not for the esp32.
I will give a try with esptool if I find the correct firmware to be flashed.
Anyways the problem is certainly in flash memory since I also had that problem on "even" restarts as I said in a previous comment.
So it is something staying there even after a restart and even with a plain sketch.
@tablatronix commented on GitHub (Feb 25, 2019):
ohh right esp32 uses nvs erase, only know how to do it in code.
@tablatronix commented on GitHub (Feb 25, 2019):
esptool erase_flash should work for esp32
@Bjack795 commented on GitHub (Feb 25, 2019):
But is the erase_flash command enough or then I should re-upload the firmware before loading again the sketches?
Since erase_flash command is totally wiping out the memory, bootloader included, or not?
@tablatronix commented on GitHub (Feb 25, 2019):
no bootloader is never erased
@Bjack795 commented on GitHub (Feb 25, 2019):
I flashed the board with
esptool.py --port COM5 erase_flashsuccessful procedure.
I reloaded the sketch and again the same problem with the same outputs:
Erasing flash memory is not working.
@tablatronix commented on GitHub (Feb 25, 2019):
man, I have another esp32, Ill check again on a different one. Do you know if your esp32 is NOT rev 0 ?
@tablatronix commented on GitHub (Feb 25, 2019):
I wonder if
dhcps: send_offer>>udp_sendto result 0has anything to do with it, I am not thinking it does, since you can ping it, but I am wondering what that means.@Bjack795 commented on GitHub (Feb 25, 2019):
I bought this board two months ago, it's d32 pro v.2 that is also a recent project.
I've not checked the revision but it's highly unlikely that it mounts a revision of more than 2 years ago.
If you want I can check it with the procedure but I think that at 99% it's current rev.
@Bjack795 commented on GitHub (Feb 25, 2019):
If the problem is only mine I would do an extensive debugging of your library to know what variables are changing within the first and second call.
@tablatronix commented on GitHub (Feb 25, 2019):
well if you are using a local scoped wifimanager obj and it still happens, then its not wifimanager, since it gets destroyed and recreated each time. it could be something like a race condition, where it is very hard to reproduce, maybe add some delays or wait then try again, and see if it even responds. I would definitely enable all esp debug levels you can, or switch esp32 versions, are you using staging?
@Bjack795 commented on GitHub (Feb 26, 2019):
I'm using this sketch https://github.com/tzapu/WiFiManager/issues/832#issuecomment-466691692
Posted before.
As you can see wm is globally defined.
I will try to add some delays and to see what are the variables not properly reinitializing on the second call.
@Bjack795 commented on GitHub (Feb 26, 2019):
I've enabled a core debug level and I found some strange differences, maybe they're normal but who knows:
First call (first part of log)
Second call (first part of log)
So even though *WM debug is the same, core events seem to differ, what do you think?
@Bjack795 commented on GitHub (Feb 26, 2019):
Other important observations:
This is the registered behaviour if I timeout the first call
Otherwise if I connect on first call:
So two timeouts are needed before a working portal is available.
@tablatronix commented on GitHub (Feb 26, 2019):
I meant you can use local scope and see if its the same, I think you already did though.
@tablatronix commented on GitHub (Feb 26, 2019):
Where is this coming from?
*WM: [1] SETTINGS ERASED
@Bjack795 commented on GitHub (Feb 26, 2019):
Of course I tried putting wm local, same results.
*WM: [1] SETTINGS ERASED
Is coming from the wm.resetsettings() that you can see in the code I posted before, I quoted before and I requote now https://github.com/tzapu/WiFiManager/issues/832#issuecomment-466691692 .
I need it because otherwise the esp is connecting to the known WiFi and all goes ok since portal is not called.
Since I want to test portal I do that thing.
I tried also configPortal for getting the same result.
The point is not there in my opinion.
@tablatronix commented on GitHub (Feb 26, 2019):
I am not testing with that nor is it in the example, I erased credentials or use on demand config so it does not matter. If you erase and do not reboot it can cause issues. Please test without it so we are on the same page, and it removes that variable
@Bjack795 commented on GitHub (Feb 26, 2019):
If I don't put it on the second call of autoconnect(), I connect and the result is that all is ok, but the problem is on the portal.
I tried also configPortal() without resetting any settings and the result is the same.
As I told many times the problem is happening also after reboots so this won't change the result.
Anyways with your sketch you don't have second call issue because you connect on the second call.
That's why I modified it with that line.
@Bjack795 commented on GitHub (Feb 26, 2019):
https://github.com/tzapu/WiFiManager/issues/832#issuecomment-466669608
With this sketch you'll never discover the problem since on the second call you will connect to the saved WiFi.
@tablatronix commented on GitHub (Feb 26, 2019):
I am not saving anything, you said time out, you did not say you were wiping and saving credentials.
Can you post exactly what you are doing, or do nothing and test
@Bjack795 commented on GitHub (Feb 26, 2019):
Ok I do a recap to clear my workflow till now.
Problem
I would like to call the portalAP after:
Discussion
You suggested to use this https://github.com/tzapu/WiFiManager/issues/832#issuecomment-466669608 plain sketch to better understand the behaviour.
The autoconnect() is saving the established connections, so if you say that you're not saving, it must be because you're never connecting the board but only timeouting it.
I modified the sketch triggering the autoconnect() with Serial input instead of a pin state variation and adding the resetsettings().
And I showed the logs I got
First call (first part of log)
Second call (first part of log)
And all the logs above were obtained with this sketch.
Then I went further in the calls, because the same problem I encountered with the second call was present some weeks ago with the restart of my real project.
So that the behaviour was
All this WITHOUT resetting the settings.
I was thinking whether the same was happening with multiple calls without rebooting.
So I used the same plain sketch to see how many calls I needed to make it working after a connection.
I obtained this:
All this keeping resetsettings() in the sketch.
The strange thing is that without resetsettings() after that a connection has been established, the other calls of autoconnect() are working fine, connecting to the saved wifi (this is a difference with respect to the "reboot issue" of some weeks ago).
Then I removed resetsettings(), to see how many timeouts were necessary to reopen the portal correctly, and I obtained this:
Conclusions
It seems that I need an even number of timeouts within two working calls.
Future tests
I will try again to remove resetsettings() and calling only portalConfig() instead of autoconnect(), even though I tried this in the past and didn't work.
This time I will do it systematically.
If this info are not lighting up any lamp, I will look for the state of ANY variable involved in autoconnect() call to see which are the differences between first and second call initial state.
I hope to have been clear now on what I did and what I will do.
@tablatronix commented on GitHub (Feb 26, 2019):
I am opening the portal but not saving, I open it make sure its working and then disconnect, or turn off wifi and let it timeout ( you can press exit, but I am using timeout, 1 test at a time )
@tablatronix commented on GitHub (Feb 26, 2019):
I assume you mean "configportal" not captive portal ( captive portal is the auto popup when joining , you said you manually connect via ip )
@tablatronix commented on GitHub (Feb 26, 2019):
just use the example I posted , reset settings, then comment it out reupload and reboot with no saved wifi.
Then let it start twice, I want to know if the problem is from saving which causes a ton of connection changes.
@tablatronix commented on GitHub (Feb 26, 2019):
If you want to test you cannot have
resetsettingsin your code, it will mess things up due to how it works, it will leave wifi state unknown. Goto info page and click erase, then reboot then test. For all I know your changes to my example are causing the bug...I will try to test similar when I have an esp32 , mine are all in use.
@Bjack795 commented on GitHub (Feb 26, 2019):
So I don't know what to do, since it's the third time I'm saying that I tested both with and without resetsettings ().
Doing exactly what you said, commenting out resetsettings and re-upload the sketch.
The last part of my previous message is entirely without resetsettings ().
I mean from this on:
@Bjack795 commented on GitHub (Feb 26, 2019):
The only difference between my code and yours is that I'm triggering with Serial input and you're using a pin high/low.
The other things are exactly taken from your code (comments included)
@tablatronix commented on GitHub (Feb 26, 2019):
Ok ill test again when I get home and see If I can get the same. Did you say you tried esp32 staging?
@Bjack795 commented on GitHub (Feb 26, 2019):
Ok thanks.
I sincerely don't know what "staging" is.
@tablatronix commented on GitHub (Feb 26, 2019):
Staging is github latest commits master branch, not stable release version
Could be a bug that is already fixed
@Bjack795 commented on GitHub (Feb 26, 2019):
I had a version of 2 months ago but after your suggestion I downloaded and used the latest development release on GitHub development page.
@tablatronix commented on GitHub (Feb 27, 2019):
not wifimanager, esp32
https://github.com/espressif/arduino-esp32/blob/master/docs/arduino-ide/windows.md
@tablatronix commented on GitHub (Feb 27, 2019):
ok I tried everything and It only happened once
but that might have just been that it timed out right as I was getting an IP.
I was using a very short timeout for testing so I did not have to wait so long
One failure after like 30 autoconnects, local and global
@tablatronix commented on GitHub (Feb 27, 2019):
I may have found a bug, it may be related to this
@tablatronix commented on GitHub (Feb 27, 2019):
ok please pull latest changes and see if it is fixed, crossing fingers.
you also might want to update to esp32 master if you are still having issues, just incase it was fixed in esp library ( its a bit of a pain on arduino though )
@Bjack795 commented on GitHub (Feb 27, 2019):
The ESP32 is up to date since Arduino IDE is notifying me every board/library update.
I think last update for esp32 was last week.
I'm at university now, I will test the new pull this evening when I come home.
Crossing my fingers too, thank you very much! 😉
@tablatronix commented on GitHub (Feb 27, 2019):
arduino only shows releases, 32 commits since last release ( you can be sure cutting edge has a bunch of bugfixes already )
Release 1.0.1 January 2019 @me-no-dev me-no-dev released this on Jan 10 · 32 commits to master since this release@Bjack795 commented on GitHub (Feb 27, 2019):
GOOD NEWS
The problem seems solved
First call timeouting (autoconnect()) -> second call perfect (autoconnect())
First call connected (autoconnect()) -> second call perfect (startconfigportal())
The only little problem that remained is that if I'm connected and I do a forced reboot (button or sketch uploaded) the first call is not working and it connects on second call.
This problem is not happening if I reboot with ESP.restart() so I can manage it in another way.
I think that this issue can be checked as "solved".
Where was the problem?
@tablatronix commented on GitHub (Feb 27, 2019):
I had async wifi scanning enabled, and the scandone event was never firing, So it was stuck scanning aps, and the client request was probably being ignored by the esp while it tried to run another scan.
What do you mean forced reboot, press reset and wifi does not connect?
@Bjack795 commented on GitHub (Feb 27, 2019):
Exactly, but I had this issue some weeks ago.
I had no timeout so the project was sticking at start-up and I discovered that if I'm connected and I press reset button AUTH-FAIL event happens (if I well remember it's number 202).
In the past I solved it inserting an ESP.restart() in your library under AUTH FAIL occurrence.
Now I will do something else without touching your code (now I have a timeout so the project won't block there).
Maybe ESP.restart() is closing the connection better than hard resetting so when it turn on again I connect normally.
Instead with hard resetting something is messing up (like with resetsettings () without restarting) and it doesn't connect.
After a timeout it comes back working (maybe the connection is cleaned in some way from the hard reset dross).
@tablatronix commented on GitHub (Feb 27, 2019):
hmm, there was an issue where modems with some multimedia thing enabled would cause failures. its possible your router is not allowing a connection after it drops out, add a delay on startup and see if it helps.
After a reboot there should be nothing to clean up, unless there is some wifi issue with that esp calibration or something, also make sure your power supply can supply 500ma+
@Bjack795 commented on GitHub (Feb 27, 2019):
Till now I'm supplying power by usb since I'm waiting a piece of cable for the battery supply from china.
I will test the delay at start-up.
Otherwise I was thinking to solve it in this way:
I already have a bool telling me if the wifi connection is ok.
I will call autoconnect with 0 timeout (or 2 seconds) at startup.
If the wifi is still not ok then I do another call with small timeout time.
This should lead to a connection if I'm at home, otherwise the wifi would be simply not available.
So in practice I would call two subsequent calls with a very small timeout (now I can 😁)
Then if there is still no connection I will go on with the other lines of code making an advice that no connection is established.
If the user wants to connect to another unknown wifi he will activate the portal from the proper wifi menu in the GUI.
@tablatronix commented on GitHub (Feb 27, 2019):
2 seconds connect timeout sounds short, you could always just use your own connect wait loop
@Bjack795 commented on GitHub (Feb 28, 2019):
The idea is that on startup I don't want to open the portal (so two subsequent "zero" timeout autoconnect ()).
Then the portal is only called on demand in the gui if no connection is established and the user wants it.
@tablatronix commented on GitHub (Feb 28, 2019):
then just turn it off
@Bjack795 commented on GitHub (Feb 28, 2019):
Thank you for the suggestion I will certainly use it.
I'm doing some tests and still the problem of the second call happens but not always, I'm trying to understand when it's happening and when it is not.
Very strange.
@Bjack795 commented on GitHub (Feb 28, 2019):
For example I connect at startup -> ok
I call configportal on demand and I connect-> ok (this was not working before your update)
I call again configportal on demand to test it -> not working
I really don't know what's happening
@tablatronix commented on GitHub (Feb 28, 2019):
are you getting different output now in serial, or it is the same issue, cp is up but you cannot connect to the web server?
@tablatronix commented on GitHub (Feb 28, 2019):
if you are using any library or code that uses the webserver it might cause issues, this is a know thing, but with an empty sketch I have no idea, I would try using staging version, I am sure there are alot of bugs in v1 release
@Bjack795 commented on GitHub (Feb 28, 2019):
I'm using my project (not plain code) but removing server code (that I thought could give some issues).
This weekend I will update up to the staging release and do a more systematic work with debug logs and I will write here a more detailed report.
@Bjack795 commented on GitHub (Mar 2, 2019):
I'm tring to do staging, my release is the 1.0.1 that is the latest for both stable and development.
To do staging I should download the files on their Github page and then how should I update my IDE-installed version?
@Bjack795 commented on GitHub (Mar 2, 2019):
Concerning the tests:
The errors are appearing in a variety of cases so I can't really circumscribe them but I have some more infos.
Additionally to the usual log:
I got another type of problem, in practise sometimes continuosly refreshing portal page I finally get into the wifi list but when I connect to one of them I get:
The only certain thing is that all these problems are happening on second calls.
After a previous successful connection or timeout.
@Bjack795 commented on GitHub (Mar 2, 2019):
Ok the usual problem is not happening on the PC, it's always happening on android.
The second one is happening on both.
@Bjack795 commented on GitHub (Mar 2, 2019):
To resume:
Second call problems
Only on Android
Problem wrong connection
Happening on both, especially on startcofigportal() only.
For example if I call an autoconnect() with no portal (good or bad results, it doesn't matter) then if I call startcofigportal() only it is working.
So from the PC the only problem is when startconfigportal() is the really first call, it must be precedeed by an autoconnect() call.
@Bjack795 commented on GitHub (Mar 2, 2019):
Other info:
Android could also spoil PC portal.
If I get a successful portal connection from an android device and then I do a second portal attempt, neither on PC nor on Android I could connect to the portal page.
First portal Android, second portal PC -> not working
First portal PC, second portal PC -> working
First portal PC, second portal Android -> not working
@Bjack795 commented on GitHub (Mar 2, 2019):
So my working sequence should look like this
The problem is still on Android device
@tablatronix commented on GitHub (Mar 2, 2019):
ok so to summarize, you can always connect to the softap, you never have an issue with that?
You seem to have issues getting an ip or connecting to webserver, NOT using the automatic captive portal. And your logs show that the softap IS 192.168.4.1 everytime ?
@Bjack795 commented on GitHub (Mar 2, 2019):
I can always connect to the hotspot but:
The second problem could be solved either calling the portal after a connect attempt or calling a connect attempt after the portal.
For example I tried resetting the saved connections (from your button in the info part of portal) and calling the portal page firstly, I get 0.0.0.0 etc but if I call a "connect" (autoconnect() without portal) it connects normally.
So when he gives me 0.0.0.0 still memorize correctly the connection.
Always using 192.168.4.1 that is the IP always indicated by the Serial outputs.
@Bjack795 commented on GitHub (Mar 2, 2019):
And apart from that 0.0.0.0 that could occur on startup, on PC it is ALWAYS perfectly working.
The problem is the android device on second call.
EDIT:
The problem is only on my phone, on my brother phone it is working.
@Bjack795 commented on GitHub (Mar 2, 2019):
So to resume there are only two little things you could adjust:
I can manage these problems with my code so if you want you can close the issue.
@tablatronix commented on GitHub (Mar 2, 2019):
An ip of 0.0.0.0 sounds like a bug in esp library. I really would spend the time to learn how to install the staging version
@Bjack795 commented on GitHub (Mar 2, 2019):
I asked you some hints since on their page I could understand what is the procedure to be followed.
@tablatronix commented on GitHub (Mar 2, 2019):
I do not use arduino, I think I posted the link above, it includes creating the board manually in the folder and downloading from github into it, then running the tools scripts
@Bjack795 commented on GitHub (Mar 2, 2019):
Ok thanks I didn't see it above.
I'm sorry.
@Bjack795 commented on GitHub (Mar 3, 2019):
Staging version installed -> still all the problems present.
@Bjack795 commented on GitHub (Mar 3, 2019):
Anyways I overpassed the remaining problems with some code tricks (like restarting after portal calls to avoid second calls) so you can close the issue if you want.
@tablatronix commented on GitHub (Mar 3, 2019):
so bizarre I will keep trying to duplicate, but i have no idea, maybe try setting
WiFi.mode(WIFI_STA)before starting autoconnect, to give it time to start in case there is a race condition in esp code. esp32 wifi does not start automatically like esp8266@Bjack795 commented on GitHub (Mar 3, 2019):
I will try these days, thank you.
@MajorHavoc commented on GitHub (Feb 8, 2024):
I know this is a very old thread, but I have run into this as well. I use auto connect when first starting, and it works just fine if credentials are stored. It puts up the AP, which auto pops-up the captured Wifi page to enter credentials when they are empty. Then everything runs fine.
But I have a button that wants to allow the user to connect to a different WiFi access point, and have the wifi manager save those credentials as the new default.
So I am resetting (wifiManager.resetSettings()) and then trying a new auto connect (wifiManager.autoConnect("Clock Wifi Config")); The auto connect tries 'n' times with empty credentials as expected, and then says it puts up the webpage and AP.
When this happens, the AP shows up on every machine around, but unlike the first time, when I connect to it, it does not put up the capture page. And I also cannot go to 192.168.4.1 and connect on any of 6 or 7 devices. Eventually it times out and fails.
I am wondering what I need to do after resetting the credentials but before calling auto connect again? Any help would be welcomed. I am stuck and cannot get this to work.
This is how the first call looks:
This works fine. Later on, I am doing this when I want the portal again:
And then it goes to the first piece of code above to try again. It fails with empty credentials (probably should not try n times when empty) and then goes into AP mode. The IP is right, I can connect to the AP just fine, I get a proper IP address (192.168.4.100), but no capture page appears and I cannot connect to 192.168.4.1. I have tired this on 6 different devices, iPhones, Macs, PCs, tablets...
Thanks for any ideas or help.