mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #1142] Hard reset required after autoConnect before fauxmoESP/Alexa can discover devices. #977
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#977
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 @ddweber456 on GitHub (Nov 10, 2020).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1142
Question: I thought this issue had been address or did I just miss something?
Hardware
WiFimanager Branch/Release:
Esp8266/Esp32:
Hardware: ESP-12e, esp01, esp25
ESP Core Version: 2.4.0, staging
LittleFS at version 0.1.0
ArduinoJson at version 5.13.5
ESP8266WiFi at version 1.0
WiFiManager at version 2.0.3-alpha
ESP8266WebServer at version 1.0
DNSServer at version 1.1.1
fauxmoESP at version 3.1.1
ESPAsyncTCP at version 1.2.2
Description
After successful autoConnect and the saving of the parameters, I have to do a hard reset before the ESP is in the correct configuration Alexa can discover devices with fauxmoESP. I have WiFi.mode(WIFI_STA); in the setup().
Settings in IDE
Module: Wemos D1, v1.4 Higher Bandwidth
Additional libraries:
Sketch
Debug Messages
@tablatronix commented on GitHub (Nov 11, 2020):
Make sure your esp is still in sta mode after wm exits. Not sure what else it could be
@ddweber456 commented on GitHub (Nov 11, 2020):
What am I missing. At the very end of the degug it looks to me like it's in STA mode.
Where do I put the WiFi.mode(WIFI_STA); if not at the beginning of setup() ?
@tablatronix commented on GitHub (Nov 11, 2020):
Yeah that should be good,
where in this log is the problem? How are you checking that your connectivity is working etc
@ddweber456 commented on GitHub (Nov 11, 2020):
I really appreciate your help and time on this, Thanks.
OK I'm back on 0.15.0, I had this problem from the very start, so it's not anything new with the alpha release. I added a couple of WiFi.printDiag(Serial); commands after the autoConnect to check the status. Is there something else I should do?
Here are the serial print logs from the autoConnect and then from the hard reset.
autoConnect:
And here is the serial log with the hard reset:
In the autoConnect serial print log I'm getting " 22:40:04.036 -> *WM: [ERROR] WiFi.begin res: "
Let me know what you think.
@tablatronix commented on GitHub (Nov 11, 2020):
Thats odd, the first log says it connected, this one says it doesnt.
I wonder why, definitely a connection issue, which esp lib version are you using ?
@ddweber456 commented on GitHub (Nov 11, 2020):
ESP 2.5.0
ESP8266 board mgr 2.7.4
@tablatronix commented on GitHub (Nov 11, 2020):
Not a fritzbox router is it ?
@ddweber456 commented on GitHub (Nov 11, 2020):
Tp-Link. Actually just install a new Tp-Link. Haven't done anything with ESP yet.
@tablatronix commented on GitHub (Nov 11, 2020):
Try a full flash erase yet?
@ddweber456 commented on GitHub (Nov 12, 2020):
I have. The reset is needed on all the devices. About 30 or 40 8266 so far. It's become standard operating procedure to do a hard reset, but I know that's not right.
@tablatronix commented on GitHub (Nov 12, 2020):
It must have something to do with fauxmo, maybe mdns interferes with the udp ?
Have you tried a basic ping example ? Or some other network check ?
is it pingable ?
@tablatronix commented on GitHub (Nov 12, 2020):
Which fauxmo library are you using ?
@ddweber456 commented on GitHub (Nov 12, 2020):
I'm using the current 3.1.1
Let me see if I can Ping it after the autoConnect.....
No I can not ping it, before or after the reset
@tablatronix commented on GitHub (Nov 12, 2020):
I mean which one, there seems to be a bunch xoseperez/fauxmoESP ?
@ddweber456 commented on GitHub (Nov 12, 2020):
I'm sorry. Support for the fauxmoESP and been transferred to Paul, @pvint https://github.com/vintlabs/fauxmoESP
@tablatronix commented on GitHub (Nov 12, 2020):
ok they should fix that in platform io
I will see if I can install it
@ddweber456 commented on GitHub (Nov 12, 2020):
Agreed. Maybe someone with the expertise could assist @pvint in making the platform io happen.
@pvint commented on GitHub (Nov 12, 2020):
I hadn't thought of the lib in platformio, thanks for mentioning it. I took a look and I see how it works now. I'll try to get it and Arduino updated later today.
@tablatronix commented on GitHub (Nov 12, 2020):
I think the old one would have to be removed first to avoid confusion, unless the name changes. i assume you are maintaining a fork, and the source is abandoned?
@pvint commented on GitHub (Nov 12, 2020):
Xose, the original author, has handed it over to me to maintain. I've updated the library.json file on the original repo, which I believe should update it.
@pvint commented on GitHub (Nov 22, 2020):
I've looked at this a bit more and took some packet captures when it fails and when it works. For some reason the ESP8266 is sending a RST, ACK packet back to the Amazon echo . Everything seems the same up until that packet, and in the "good" scenario, it sens a SYN ACK and everything continues.
I have a bit more info here: https://github.com/vintlabs/fauxmoESP/issues/123#issuecomment-731847618
@ddweber456 commented on GitHub (Nov 24, 2020):
Just curious if anyone has had a chance to investigate the findings that Paul, FauxmoESP, was able to see with the packet capture. I'm still having the issue of the required hard reset and would really like to get that resolved if possible. Let me know if there is anything I can do to help.
@tablatronix commented on GitHub (Nov 24, 2020):
you would have to eliminate WM and see if it can be reproduced with just esp examples, and then reach out to espressif, does sound like sdk issue.
What happens if you just do a esp.reset() ? or wdt reset ?
@ddweber456 commented on GitHub (Nov 24, 2020):
It seems like I would have to do the esp.reset() as part of the autoConnect? Unless I can conditionally esp.reset() coming out of autoConnect. Ideas?
@tablatronix commented on GitHub (Nov 24, 2020):
You only have this issue when saving new wifi ?
You can use the saveconfig callback to flag a reset maybe?
The only time I have seen reset issues with wifi saving is when the flash is corrupt and a full erase via esptool/arduino fixes it
@ddweber456 commented on GitHub (Nov 24, 2020):
Yes, the only time I see the issue is when saving new WiFi credentials.
Several months back, I did see the comments regarding the corrupt flash, I was hopeful, but that didn't help.
@tablatronix commented on GitHub (Nov 24, 2020):
It hardly ever does anything but maybe try adding a WiFi.reconnect() after ?
@ddweber456 commented on GitHub (Nov 25, 2020):
The WiFi.reconnect() did not do the trick. I think we maybe lookin in the wrong place.
Shawn, I'm not the most experienced coder, but it look like to me that autoConnect() call to connectWiFi() when saving credentials it does not return to the calling function cleanly. Otherwise, I think I should be seeing the *WM: IP Address ... in the first serial print log below:
Serial print log when saving wifi credentials via autoConnect():
Serial print log after doing the hard reset:
@tablatronix commented on GitHub (Nov 25, 2020):
Yes your saves are failing, your code is checking the return true? Not sure what is failing or if begin is failing, not sure why, have you tried a different esp a different lib version?
@ddweber456 commented on GitHub (Nov 25, 2020):
I have only tried this on the 8266. But on many 8266s. All have the same issue and want a hard reset before they will communicate with Alexa. After that they are very, very stable. Multiple power re-boots, power outages, wifi going away for period of time. No Issues.
What lib version would you recommend?
I don't know if it makes a difference but FauxmoESP runs as a UDP.
@ddweber456 commented on GitHub (Nov 25, 2020):
I just modified the example AutoConnect sketch from the 0.15.0 WiFiManager lib. Modified it just enough to blink the on-board LED and I'm getting the same serial print log as before:
Serial print log from autoConnect() saving wifi credentials:
After ESP8266 hard reset:
Here is the code:
The {ERROR} *WM : WiFi.begin res: that we're seeing in the first Serial print log is un-expected, I'm starting to think this is NOT the problem. If everyone else is able to use the 8266 as a STA right after the autoConnect() without doing a hard reset, then something else is going on. I'm going to share this with @pvint - vintlabs/FauxmoESP. See if he can shed his intelligence on the subject. Thanks Paul for your help.
David
@tablatronix commented on GitHub (Nov 25, 2020):
Ok so I am going to say use the dev/alpha version, there was some fixes for this kind of stuff added and better logging. I cannot say for sure but there was some clean connect stuff I worked out to fix odd issues like this
@tablatronix commented on GitHub (Nov 25, 2020):
There is a clean connect, let me find it
These are new might only be in the github version, development branch
// set wifi connect retries
// wm.setConnectRetries(2);
// This is sometimes necessary, it is still unknown when and why this is needed but it may solve some race condition or bug in esp SDK/lib
// wm.setCleanConnect(true); // disconnect before connect, clean connect
Some other things you can try, set proper country
set channel, shrug
// set country
// setting wifi country seems to improve OSX soft ap connectivity,
// may help others as well, default is CN which has different channels
wm.setCountry("US");
Finally, make sure you are using a good power supply!
@pvint commented on GitHub (Nov 25, 2020):
I just tested with the development branch, both with and without
.setCleanConnect(true)and the issue remains. I'll try to look a bit more later on.@ddweber456 commented on GitHub (Nov 29, 2020):
@pvint were you able to do any additional testing? Could this be because FauxmoESP is using UDP?
Even though we are seeing an ERROR from WM: connectWiFi() returning to the calling WM: autoConnect() (see comment of 5 days ago https://github.com/tzapu/WiFiManager/issues/1142#issuecomment-733396464 ) it appears most everyone else is able use the ESP as a STA without doing a hard reset. It not just my code that is producing this WM: ERROR, it is also happening in the example sketches WM 0.15.0. https://github.com/tzapu/WiFiManager/issues/1142#issuecomment-733456344
@tablatronix commented on GitHub (Nov 30, 2020):
It could be router specific. I will test this on some of my boards when I have time.
If you have a bin? I can try that too. Otherwise I will use latest stable of all and wm /dev latest
@ddweber456 commented on GitHub (Dec 1, 2020):
I've taken the unit to 8 to 10 client locations, there's no difference. I've always had to do a hard reset.
Any progress in finding a fix? Is there anything I can help you with?
david
@ddweber456 commented on GitHub (Dec 3, 2020):
@tablatronix Hey, just checking in to see if you had made any progress. I hope the silence is not an indication of bad news.
@tablatronix commented on GitHub (Dec 3, 2020):
Sorry I will try to test here tomorrow
@pvint commented on GitHub (Dec 4, 2020):
It would be interesting to try to reproduce the issue in a simpler manner - get rid of all the fauxmo stuff and just insert a
sendUDPPacket(data, dst, port)sort of thing and see if we can narrow it down. (I made up that function name...)I'll try to have a look in the morning (in 12 hours or so)
@tablatronix commented on GitHub (Dec 4, 2020):
I am not sure what to expect here, it seems to work, not sure how I test it, alexa needs wemo skill ? My homeassistant isnt finding a new device but I do have these
[FAUXMO] Responding to M-SEARCH requestand@tablatronix commented on GitHub (Dec 4, 2020):
fauxmo runs a webserver, I would suspect that before anything, make sure wm is destroyed before starting the fauxmo one
@ddweber456 commented on GitHub (Dec 4, 2020):
That sounds good...sooo how do you stop a server?
@tablatronix commented on GitHub (Dec 4, 2020):
I have seen issues with running another webserver even though wm stops it
Maybe since we are using a shared pointer for the webserver now, or maybe stop() is not enough, I have not really had a look at it
@ddweber456 commented on GitHub (Dec 4, 2020):
What if I did all the WiFiManager stuff, including the WiFiManager MW; in it own function, called from Setup(). When focus is lost, that should destroy WM and the Server. Right?
@tablatronix commented on GitHub (Dec 4, 2020):
It should, if you take it out of global scope.
@ddweber456 commented on GitHub (Dec 7, 2020):
The ESP SDK is very persistent in keeping the server, once established, connected and running. Moving the creation of the server out of global scope in its own separate function did not work. Server remained regardless of scope.
@ddweber456 commented on GitHub (Dec 8, 2020):
@tablatronix Could it be that somehow WM is effecting Port 80, blocking FauxmoESP from being able to use 80 to receive UDP messages?
@tablatronix commented on GitHub (Dec 8, 2020):
Yes, that is what I think, if you use an alt port to test it will be evident.
I meant to say that the other day, using 2 web servers on the same port seems to be impossible, not sure how to properly destruct the webserver
@ddweber456 commented on GitHub (Dec 8, 2020):
Can you be a little more specific how and where to implement is for testing? thanks
@tablatronix commented on GitHub (Dec 8, 2020):
wm.setHttpPort(); you can set the port in the dev branch
@pvint commented on GitHub (Dec 8, 2020):
Just to interject - I think this is moot... port 80 is for TCP on the webserver. When we see the issue with UDP on fauxmoESP it's on totally different ports.
I got looking at this more yesterday, but I'm still a bit stumped. Might look more tomorrow.
@tablatronix commented on GitHub (Dec 8, 2020):
I saw port 80 in the example, so did not want to assume if it was the default or not, was not sure what v3 was or if I needed which for alexa, also was not sure if the webserver was necessary
Either way I never got the devices discovered to test
@tablatronix commented on GitHub (Dec 9, 2020):
mdns uses udp no ?
@tablatronix commented on GitHub (Dec 9, 2020):
well that didn't work
tried adding MDNS.end(); no change
@tablatronix commented on GitHub (Dec 9, 2020):
I can confirm using non 80 port on wm webserver works, so not sure if you are using udp on port 80, but it seems to not matter it phy is using it its using it. I will ask around and look at the esp sdk and see if we can close it better or proper of if its a bug. But not sure if its that, as it seems only only break when saving new creds.
Maybe when add async compate we can just use the same server as we can now.
@ddweber456 commented on GitHub (Dec 10, 2020):
Preliminary tests show that using the above with a port other than 80, Alexa is able to Discover the devices without doing a hard reset.
@tablatronix commented on GitHub (Dec 10, 2020):
I have debugged everything I could tcp_close does not return any errors, did not see any asynctcp begin bind errors going to ask the esp folks if they know what the sdk does. I do not have time to gdb this deeper
@ddweber456 commented on GitHub (Dec 10, 2020):
Unfortunately, I could not get the fauxmo.server(80) and Alexa Discover Devices it to work together without doing the hard reset after saving WiFi credentials via autoConnect().
Maybe? Someone else has a solution?
Like you, I can't spend more time of this issue right now. A better solution if just an OTA away.
Shawn and Paul, Thank you very much for help.
Here is the minimum code for WifiManager and FauxmoESP:
@DietmarHoch commented on GitHub (Dec 27, 2020):
Hi,
run into the same Problem with a ESP32 (M5 ATOM) with ESPAsyncWebServer.
i am using the arduino ide with esp library 1.0.4 and also try the 1.0.5 rc4
wifimanager ist 2.0.3 alpha
the Output at the console:
the bind error: -8 comes from the esp_lwip andsays that the adress is in use
is there a way to reset the ESP32 in case of the bind error -8?
maybe as a interim solution.
stay healthy
@tablatronix commented on GitHub (Dec 27, 2020):
I have asked and gotten no response even though we close the sdk seems to hang on I will have to keep investigating and check with idf and sdk
@DietmarHoch commented on GitHub (Dec 27, 2020):
thanks for the quick response,
do you think a reset (if server.begin fails) is a solution?
i have no idea how to catch the error, because the "server.begin()" returns nothing
@tablatronix commented on GitHub (Dec 27, 2020):
as you say, there are no return checking, BUT I have added debugging to all server methods, server, socket close, open etc, and saw no errors from the sdk that would imply the socket is still open, so I am thinking it is an esp bug
@tablatronix commented on GitHub (Dec 27, 2020):
Where did you get this error?
18:21:56.811 -> [E][AsyncTCP.cpp:1287] begin(): bind error: -8@DietmarHoch commented on GitHub (Dec 28, 2020):
it's from the Arduino IDE. serial Console (Core Debug Level: "Debug")
i think at this line of code:
server.begin();
@tablatronix commented on GitHub (Dec 28, 2020):
I will try that I did not test against async or get any logging errors
@SaeDocas commented on GitHub (Dec 30, 2020):
I can confirm I have this issue too. Was pretty hard to figure out and it is definitely related to Fauxmo being initialised right after WifiManager.
@ddweber456 commented on GitHub (Dec 31, 2020):
Enhancement? Maybe, to get around this issue:
Provide a true/false test if autoConnect() is activated and stored credentials/parameters. This would allow the coded to do ESP.restart() or any other specialized code in series with autoConnect().
@PauloFDO commented on GitHub (Jan 9, 2021):
I'm so glad that I found this post, I have been going crazy for days now wondering why Alexa cannot detect anything when I use WifiManager, not ideal but the hard reset seems to do the trick, I can't contribute but I would like to thank you all for the efforts being made here and for the suggested workaround.
@SaeDocas commented on GitHub (Jan 9, 2021):
Yes! I think we should put in a pr updating readme with this error, a lot of people are definitely having a bad time trying to find the error in their code...
@pvint commented on GitHub (Jan 9, 2021):
I got looking at this again today, and cannot find a resolution. I feel the issue is on the side of arduino/esp8266, and I've created an issue there https://github.com/esp8266/Arduino/issues/7818
Sorry for some misleading info before - I got chasing a red herring (on the UDP stuff) and missed the simple face that the "new" webserver wasn't receiving anything on port 80.
@tablatronix commented on GitHub (Jan 9, 2021):
Its not an error its a bug.. workarounds is the only solution atm
@pvint commented on GitHub (Jan 11, 2021):
Good news!
I just tested, and apparently this has already been fixed in the latest Arduino core for esp8266! See https://github.com/esp8266/Arduino/issues/7818
@tablatronix commented on GitHub (Jan 11, 2021):
I commented on that issue, but Its not there.. odd
Thanks for that, I will test here too.
@tablatronix commented on GitHub (Feb 5, 2021):
Can you all confirm this works now and close this ?
@Lakko-ph commented on GitHub (Feb 16, 2021):
I have this issue on a ESP32. So i'm thinking this is not been fixed yet on esp32.
The strange thing is that on an old Honor V10 running Android 10 i haven't this issue but on Xiaomi mi10 and Samsung A51 both on Android 11 have this issue that goes away when i reset the board.
@dmlambo commented on GitHub (May 20, 2023):
I'm going to revive this bug since I've sort of found the problem. The implementation of lwip in NONOS doesn't handle the netif IP change correctly if the netif was first bound to 0.0.0.0 (IE in AP mode). When the change happens to STA, and an ip is assigned, the correct sequence of events does not get fired, and some pcbs are left dangling in an active/ESTABLISHED state. I can't say the right thing to do, since some of the code is closed. However, I've found a workaround:
I haven't tried putting this into the WiFiManager codebase, and I'm not very familiar with it, so I probably wouldn't be the one to fix it. But it should be fixed, because it's really annoying. :)
@tablatronix commented on GitHub (May 20, 2023):
Are you running the latest esp library?
@dmlambo commented on GitHub (May 20, 2023):
Whatever comes down with platformio. Uses esp8266 arduino 3.1.2.
@tablatronix commented on GitHub (May 20, 2023):
Ok I can check but usually these unsavable issues are corrupt flash and should be fully wiped or try another module