14.1 can't connect to router on 14.1 on ESP8266 Wemos D1 mini #3690
Comments
|
I would suspect WiFi issues (channel overlap, interference, etc). |
|
Same issue with nodemcu. 14.0 works fine. Upgrade brakes wifi connectivity (using Unifi network). |
|
I will describe the issue I had with one of ESP8266 devices which was sitting 30cm from access point and was unreachable over WiFi. There was another ESP32-S2 with similar issues though that one was far from any AP (>10m outdoor). With 0.13.x the ESP was reachable but was occasionally dropping in and out of WiFi. That was observable in UniFi controller (I use Ubiquiti UniFi with several APs and switches). The drops were rare and didn't last long. After I updated it to 0.14 (somewhere in July 2023) I immediately noticed that the device was visible and connected to the network but I was unable to connect to UI. It would just stall loading it. I went ahead an purchased another AP (UAP-AC-M) and installed it about 30cm from the device as it was in an awkward spot where WiFi signal was poor. It didn't help. It turned out that I had to fix APs to have channel allocation permanent and dispersed as far as possible (the two APs on the same channel had to be physically furthest from each other), I also disabled BSS transitions and Fast roaming though these two didn't seem t have any real effect in my set-up. After all my APs were set to fixed channels (1, 6 and 11) and APs using the same channel were separated as far as possible, all connectivity problems went away. Immediately. |
|
I have the same or a similar problem and it is definitely not the same as the 14.0 Wifi issues. With 14.0 I had connection problems that I thought came from a new device (which I had not used with WLED < 14), but maybe it's the new Arduino core then. Anyway I changed my Wifi settings to less crowded channels and it helped to some extent. However, immediately after the update to 14.1 the device (now hanging on the wall controlling an LED strip, 50cm to the AP, working flawlessly so far) became unresponsive. The UI would load slowly or not at all. I needed to change something in LED settings and it was impossible to get there. In the browser I was able to directly open the update section after a reboot and install 14.0. It took pretty long but eventually worked. After reboot everything worked again. So my problem is definitely something in 14.1. My device is NodeMCU v2 (ESP8266) |
|
For list of changes and possible causes see changelog and explanations in #3685. As far as I can see there were no changes (except an option to force G mode on ESP8266) to networking. And the change of Arduino core happened somewhere in between 0.14.0-b1 and 0.14.0-b2 and not in 0.14.1. #3526, #3502, #3496, #3484, #3487, #3445, #3466, #3296, #3382, #3312, #3593, #3490, #3573, #3517, #3561, #3555, #3541, #3536, #3515, #3522, #3533, #3508, #3622, #3613, #3609, #3632, #3566, #3665, #3672 @sl1txdvd what you are describing was exactly my case. Solved by WiFi reconfiguration. Unfortunately I do not know if we have any option to change WiFi operation from within WLED as we use standard approach which hasn't changed in a few years. |
|
As I said, that solved my problems introduced by 14.0. Which works for me. But it does not solve the problems introduced by 14.1. As you say, Arduino core change was in 14.0. The same problem would not return in 14.1 then under the exact same circumstances while 14.0 is not affected. It's a different issue. |
|
FWIW I just tried Back to 14.0, everything's fine. |
|
Unfortunately I have no resolution for you but to stay on 0.14 or earlier. |
|
@sl1txdvd Would you mind sending me a copy of your configuration, from the 'backup configuration' feature? I haven't been able to replicate your issue here on my test setup. I'd like to try with your specific settings. |
|
another one with the same issue. also tried a reflash but still failed. 4 other devices running 14.1 are ok. but one doesnt like it. |
|
@willmmiles I try to attach the config here. I changed the ssid of my wifi. |
|
Thanks, I think that's helped pin it down, I've been able to reproduce the OTA issue here. |
|
@sl1txdvd does anything change if you use DHCP? |
|
0.14.1 is buggy |
|
As of 0.14.1 the ESP's with WLED are no longer able to connect to my UniFi AP's. Reverting to 0.13.3 fixes the issue |
|
Could this be a problem with UniFi AP's. in general? Or perhaps with having multiple UniFi AP's? Because I seeing the same thing with versions >13.1 on all esp8266's . And I also have UniFi AP's. 2 older UAP-AC. Although I managed one good build with 14.0 for a esp8266. But cannot I reproduce the build now for some reason. |
|
Running UniFi too. I don’t recall any issues on 0.14.0, but I’ve just reverted to it from 0.14.1 because of this thread, so I’ll take note from here on. In my situation the ESP32 just disappears from my network after approximately 10 hours. It does not create its own network even after I changed it to create it on network disconnect and not just on boot w/o network. There are certainly a lot of UniFi networks in this thread. I have 4 APs in my network. Two of them are definitely in range. Bonus: i have three wled devices which should all be ESP32’s. Only one is experiencing issues on 0.14.1 (which is now downgraded to 0.14.0). Scratch that - I just checked my unifi logs, and it does not seem to indicate that the other two 0.14.1's aren't having problems. While they reconnect, shortly after, my problem device doesn't. Unifi logs. In this view, |
|
Dumping more info because I have a working/not working situation, so maybe something is useful. The network
wled-light-1-6
wled-light-50-2
wled-light-5-3
|
|
This issue is not isolated to UniFi, I am experiencing the same and I am running eero (6 Pro x2). No issues with esp32 however all esp8266's required rolling back to 0.14.0. |
|
Same here with mikrotik network |
|
Same bug here, WLED 14.1 is unusable using a hw-622 based relay board with official binary: version 14.1: root@ap-01:~# ping 192.168.1.170 PING 192.168.1.170 (192.168.1.170): 56 data bytes 64 bytes from 192.168.1.170: seq=0 ttl=255 time=191.526 ms 64 bytes from 192.168.1.170: seq=3 ttl=255 time=28.830 ms 64 bytes from 192.168.1.170: seq=4 ttl=255 time=100.870 ms 64 bytes from 192.168.1.170: seq=5 ttl=255 time=155.209 ms 64 bytes from 192.168.1.170: seq=6 ttl=255 time=205.415 ms 64 bytes from 192.168.1.170: seq=7 ttl=255 time=44.909 ms 64 bytes from 192.168.1.170: seq=9 ttl=255 time=456.499 ms 64 bytes from 192.168.1.170: seq=11 ttl=255 time=96.057 ms 64 bytes from 192.168.1.170: seq=12 ttl=255 time=169.681 ms 64 bytes from 192.168.1.170: seq=13 ttl=255 time=222.849 ms 64 bytes from 192.168.1.170: seq=14 ttl=255 time=275.832 ms 64 bytes from 192.168.1.170: seq=17 ttl=255 time=80.973 ms 64 bytes from 192.168.1.170: seq=18 ttl=255 time=133.357 ms 64 bytes from 192.168.1.170: seq=19 ttl=255 time=186.415 ms ^C --- 192.168.1.170 ping statistics --- 28 packets transmitted, 14 packets received, 50% packet loss round-trip min/avg/max = 28.830/167.744/456.499 ms version 14.0: root@ap-01:~# ping 192.168.1.170 PING 192.168.1.170 (192.168.1.170): 56 data bytes 64 bytes from 192.168.1.170: seq=0 ttl=255 time=5.305 ms 64 bytes from 192.168.1.170: seq=1 ttl=255 time=3.813 ms 64 bytes from 192.168.1.170: seq=2 ttl=255 time=3.317 ms 64 bytes from 192.168.1.170: seq=3 ttl=255 time=4.153 ms 64 bytes from 192.168.1.170: seq=4 ttl=255 time=2.788 ms 64 bytes from 192.168.1.170: seq=5 ttl=255 time=10.441 ms 64 bytes from 192.168.1.170: seq=6 ttl=255 time=4.197 ms 64 bytes from 192.168.1.170: seq=7 ttl=255 time=14.618 ms 64 bytes from 192.168.1.170: seq=8 ttl=255 time=2.988 ms 64 bytes from 192.168.1.170: seq=9 ttl=255 time=22.101 ms 64 bytes from 192.168.1.170: seq=10 ttl=255 time=11.045 ms 64 bytes from 192.168.1.170: seq=11 ttl=255 time=5.834 ms 64 bytes from 192.168.1.170: seq=12 ttl=255 time=5.880 ms 64 bytes from 192.168.1.170: seq=13 ttl=255 time=3.900 ms 64 bytes from 192.168.1.170: seq=14 ttl=255 time=90.145 ms 64 bytes from 192.168.1.170: seq=15 ttl=255 time=4.071 ms 64 bytes from 192.168.1.170: seq=16 ttl=255 time=6.595 ms 64 bytes from 192.168.1.170: seq=17 ttl=255 time=9.376 ms ^C --- 192.168.1.170 ping statistics --- 18 packets transmitted, 18 packets received, 0% packet loss round-trip min/avg/max = 2.788/11.698/90.145 ms |
|
Chiming in to say I've lost contact with my now |
|
I've just observed this issue with a D1 Mini NodeMCU based on the ESP8266-12F. Fine on 0.14.0, unusable on 0.14.1. The device connects to my Unifi U6-Pro, but I can get close to no data through. It works intermittently for a few seconds, then nothing at all, this then repeats. It appears that turning off Fast BSS Transition helps a little, but it does not fully resolve the issue. Interestingly, I have another non-Mini NodeMCU which initially showed the same issue on a Unifi U6-Mesh, but that cleared up after power cycling the device and the access point. I still see frequent reconnects, about every 30 minutes, but it's usable. |
|
Chiming in. All my WLED's were on 13.3 - no issues. Updated all of them to 14.1 today They now ALL fail %100. All offline. An unplug/plug will have them connect for a few minutes, but then they all drop off again shortly. Reflashing these will be a nightmare where some are located. :\ |
If you've enabled the self-hosted AP, you could disable your own wifi for a while while you reboot them and then flash them via a phone/laptop.. I dread this situation :O |
|
Please read the whole thread but pay attention to this post: |
good post - but also 2 friends of mine updated using different boards and had to also roll back (we popped 14.1 on them to test) same result. And I'm sure lots of "set it and forget it" boards would have the same issue but won't be updated at all. The ones i'm using have been stable for a VERY long time. zero drops. they also have antennas that clip on to improve signal. Multiple people in here with various boards all having the exact same issue. I don't buy the "it's weak antenna" reasoning when those same boards worked fine for a very long time, then failed after update, to only work again perfectly once rolled back. edit: taking a peek at other issues open, seems like MANY others are having many of the same issues with 14.1 - not just this thread. |
confused, the entire thread is full of people telling you they are having problem solely with 0.14.1, yet you keep pointing out wifi issues ? |
|
There were no changes to networking in 0.14.1 but we did switch ESP8266 platform for 0.14.0 as required with newer NeoPixelBus (requiring newer C++ compiler). @doronazl there were no changes to wifi implementation in 0.14.1 compared to 0.14.0. Not a single one. |
|
I don't have issues anymore, but other people still do. Guess you'll have to try yourself. |
|
FYI it may be worth checking this thread on WLED forum. |
|
Sigh now that Home Assistant is forcing v 0.14.x my automations are no longer working. |
|
Yeah, I am having problems again as well. As soon as I update to 14.4, the wifi breaks. I am buying an ESP32 with wifi now. Tired of this. @blazoncek Ah yes, changing the wifi channel to 11 actually worked. Mine wasn't on 13 before though, but on channel 6. I also have the same device with esphome running in my network without issues though, so I don't believe it is an upstream bug. |
|
For me my UniFi AP that has the WLEDs connected is and has always been on channel 11. WLED 0.14.x just breaks the ESPs :( |
For me 0.14.0 still works but no more after that. |
|
On my wireless network, esp8266 devices work with tasmota and esphome without problems, but with wled 0.14.4 they lose the connection shortly after turning on, making them unusable. |
…3690 and #3685) some users have reported that releases after 0.14.0 are not working reliably. So we add a few "compat" for 8266 that try to reproduce the buildenv of 0.14.0 as much as possible. * platform and platform_packages from 0.14.0 * not using PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48 * due to smaller IRAM, we had to move some functions back from IRAM to normal flash (may cause slowdown)
|
There seems to be some consensus that 0.14.0 worked while later releases have problems 🤔 As the wifi code is part of the framework and not under our control, I've tried to reproduce the 8266 build environment of 0.14.0 in 0_15. Actually, there are still some differences, as we cannot go back to NeoPixelBus below 2.7.9. But it might be worth a try. Please try one of the for example
Please inform us if these compat bins work better for you, If yes, then we could also add the same compatibility builds to 0.14.4. |
|
... another feature that possibly interferes with Wifi is ESP-NOW support. Even when you keep esp-now remotes disabled in wifi settings, the esp-now driver in the core is still active. To remove ESP-NOW, you'll need a custom build with |
…3690 and #3685) some users have reported that releases after 0.14.0 are not working reliably. So we add a few "compat" for 8266 that try to reproduce the buildenv of 0.14.0 as much as possible. * platform and platform_packages from 0.14.0 * not using PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48 * due to smaller IRAM, we had to move some functions back from IRAM to normal flash (may cause slowdown)
@softhack007 I've uploaded the compat version for the ESP8266 4MB and at first glance it is stable ( I will report back after a longer period to be sure, currently only up for 2 hours ). |
Did you reload the WLED integration in HA? It didn't update the version until I did that. 
|
Thanks!! That did the trick |
|
@softhack007 I had 1 drop in 3 days, that is a big win in my books! With v0.14.x I had a wifi drop each 2 minutes!! |
|
Tested with 0.15.0-b5 and now wled is very stable, thanks a lot. |
|
Another hint for anyone having issues with WiFi connection (and multiple APs used but not limited to): Make sure all of your APs with 2.4GHz SSIDs have forced 20MHz channel mode. Even if one of them will have 40MHz channels (or auto switching if available) you may experience severe connectivity issues which may not be limited to ESP8266. |
|
i can confirm the same thing. was having issues with 50% packet loss on v0.15.0-b6 went back to 0.14.0 and it works great. i have 2 unifi ap-6-pro aps |
…led#3690 and wled#3685) some users have reported that releases after 0.14.0 are not working reliably. So we add a few "compat" for 8266 that try to reproduce the buildenv of 0.14.0 as much as possible. * platform and platform_packages from 0.14.0 * not using PIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48 * due to smaller IRAM, we had to move some functions back from IRAM to normal flash (may cause slowdown)
|
Same here. Tried 14.1, 14.4, 15.0-b7, 15.0-b5. All have large packet loss to AP (eero 6), and dropped connections to the HTTP port. 14.0 works fine. I can reproduce on 7+ Wemos D1 mini clones from two manufacturers |
|
@SuperTango @raptordemon did you try the See #3690 (comment) |
|
Complete noob here. I've been making a bunch of stuff and ordered a pack of these D1 minis and had the hardest time getting them to work (downgraded to 14.0 and it works great), but I've read that these NEED the extra CPU power to 160 mhz to run normally. Is this the case? It seems like some of the faster / more cpu intensive effects are running slower than on my ESP32's (or am I imagining it?). Any way to boost the CPU to 160 and keep 14.0? |
|
_compact binary (from latest Release CI) mentioned in this comment worked |
|
Even though i seemed to have had problems with the hardware power delivery with the constant connection problems (looked exactly like boot loop after experiencing boot loops with d1 devices), it might of instead been the wlan stability. Ive not tested it yet, but my d1's are waiting to be upgraded. I did order esp32 to replace them though. _compact release is releaving that issue it seems after reading some. Is the compact release part of wled in such ways that it gets updates and stays as _compact after each release? |
Can cofiirm! I've used 13 channel. after I've changed AP channel to 1 connection problem has gone. |
|
Confirming an issue between v14.1 and latest v15. Bought a 3 pack of ESP8266, two of two had problems maintaining a connection to my unifi network. Unifi says good connection, put couldn't open up the web page (sometimes got as far as seeing "WLED" title on tab but that's it), and pings to device failed over 90% of the time. Installing v14 worked like a charm--no issues at all. Web page loaded up with zero issues first try on this version. |
Yup, same here. 14.0 is the last version that stays rock solid on my Ubiquiti gear, if I go any higher I get disconnects or actual reboots. |
and others
What happened?
After the upgrade to 14.1 WLED wasn't accessable anymore. Erasing the flash and flashing 14.0 solved the issue. Another upgrade to 14.1 resulted in broken wifi again. If you flash 14.1 manually, you can connect to the WLED-AP, but after you configure the router connection, things break.
To Reproduce Bug
Install 14.1 and connnect to existing network
Expected Behavior
WLED should connect
Install Method
Binary from WLED.me
What version of WLED?
14.1
Which microcontroller/board are you seeing the problem on?
ESP8266
Relevant log/trace output
No response
Anything else?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: