WLED-AP Network Won't Show Up - NodeMCU

[uxigene]

What happened?

I’m trying to flash the WLED firmware to a NodeMCU. Although the firmware uploads successfully, I cannot see the WLED-AP network. I have an 8×32 WS2812B LED matrix connected to D4 (GPIO2) with an external power supply. After flashing, only a single white LED lights up. I've also tried to upload it to my second (same) NodeMCU without anything connected to it with same results.

I’ve attempted erasing the chip using esptool and have also tried flashing with esptool, WLED web installer, and ESP Flasher. Flashing a simple sketch with AP mode works correctly, so the board itself seems functional.

I have tried flashing the following WLED versions: WLED_0.15.0_ESP8266.bin WLED_0.15.1.beta1_ESP8266.bin WLED_0.15.1_ESP8266.bin WLED_0.16.0-alpha_ESP8266.bin

Chip details: Chip type: ESP8266EX Features: Wi-Fi, 160 MHz Crystal frequency: 26 MHz

UPDATE

Same results when compiled from source.

To Reproduce Bug

Connect an 8×32 WS2812B LED matrix to D4 (GPIO2) of a NodeMCU, with an external power supply. Flash the NodeMCU with WLED firmware. Attempt to connect to the WLED-AP network on a phone or computer.

Expected Behavior

The NodeMCU should broadcast a Wi-Fi network named WLED-AP.

Install Method

Binary from WLED.me

What version of WLED?

WLED_0.15.0_ESP8266.bin

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

Anything else?

No response

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[softhack007]

@uxigene did you try a "8266 compat" bin, like WLED_0.15.1_ESP8266_compat.bin ?

These binaries are build with an older network stack, and less demanding flash speed requirements.

[uxigene]

@softhack007 thanks for replying. Unfortunately it didn't work either.

[uxigene]

Compiled from source with same result.

[DedeHai]

Compiled from source with same result.

compile width debug enabled and check serial output for some insight

[uxigene]

compile width debug enabled and check serial output for some insight

Enabled debug in wled.h file and run Upload and Monitor.

// to toggle usb serial debug (un)comment the following line
#define WLED_DEBUG

// filesystem specific debugging
#define WLED_DEBUG_FS

But there is no output. I can only see this message:

Please build project in debug configuration to get more details about an exception.
See https://docs.platformio.org/page/projectconf/build_configurations.html


--- Terminal on /dev/cu.usbserial-1410 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, esp8266_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

Same if I run pio device monitor -p /dev/cu.usbserial-1410 -b 115200 Am I doing something wrong?

[srt4328-ui]

Hi there - I'm having same issue as @uxigene.

I'm trying to start a fresh esp8266ex module (as I have several slack to use) while diving into the fascinating world of WLED. My modules are 8266ex, 160 with 4M flash. After installing current or compiling my own binaries in PIO, I will not see the WLED_AP on my phone, and if it should happen to show up (intermittent) I can't log in using the default pass. I've tried compiling using WiFi credentials in myconfig.h, but no luck, but this may be related to the fact that I'm using source from 0_16.

If I use WLED_08.5.0, I can reliably see and access the MCU GUI via the WLED_AP, but couldn't get the Wifi station credentials to work(AP was only access)- didn't fully vet this since I was looking for proof of good module. An older version of Tasmota works excellently (can scan Wifi networks and join from web installer) - chatter on Tasmota suggest Wifi issues in newer code were related to SDK and AP/STA mode running concurrently on the 8266.

I tried erasing the flash and using the WLED_0.15.1_ESP8266_compat.bin as suggested by @softhack007 with no change (don't see the WLED_AP and using web installer to add station credentials doesn't work either). I erased the flash (esptool via M$ command line) and applied WLED_0.15.1_esp8266_debug.bin.

Initial_esp-webtools-log is a ~ five minute log post flash and reset. I then used the WLED web installer to set the local WiFi credentials (manually, no networks were discovered during scan). I let this run for a few minutes and download the log file. I reset the MCU using the hardware button and let the log run for a few more minutes before downloading that log as well. Those last two logs appear to have been captured in Chinese/Japanese characters, so I did not include them.

File esp-webtools-logs (1) was captured some 40 minutes after the firmware flash only because the other log files were unreadable (to me). This log will show the MCU trying to attach the the local network access point (SSID The_Garage). While typing this note and letting that log collect, I did finally see the WLED_AP, but when I tried to join it with the default password, my phone gave me a response of "Unable to join the network."

FWIW, the local WiFi access point I'm using is operating in mixed b/g/n mode (2.4G only) if that is relevant (there was some chatter on Tasmota about STA mode preferring one in the newer SDK).

esp-web-tools-logs (1).txt

Initial_esp-web-tools-log.txt

[DedeHai]

Network event 8 according to the event list means "ARDUINO_EVENT_WIFI_STA_GOT_IP6" i.e. IPv6 address. you need IPV4, set your router accordingly.

[uxigene]

@srt4328-ui I was able to flash v0.8.5 and it starts WLED-AP. I could enter WIFI credentials. So, v0.8.5 looks functional for me. It looks that there are some troubles with AP in latest versions. I'll try to find which version exacly is faulty. Setting WIFI credentials in myconfig.h seams to not work either.

[softhack007]

Setting WIFI credentials in myconfig.h seams to not work either.

It does work, however these credentials will only be used if you erase your board completely before flashing. In case of wsec.json already existing, the "credentials" from the file will be used instead of myconfig.h. Even when wsec.json only has "empty" credentials.

[uxigene]

Setting WIFI credentials in myconfig.h seams to not work either.

@softhack007 I'm building v0.15.1 from source:

1. Updated config.
2. nodemcuv2/Platform/Erase Flash (also tryied esptool erase-flash).
3. nodemcuv2/General/Upload.

Updated my_config.h

#define CLIENT_SSID "My double verified SSID"
#define CLIENT_PASS "My double verified PASS "
#define MDNS_NAME   "wled"
#define MAX_LEDS    256 

So, looks like for newer versions higher then v0.8.6 WLED AP doesn't show up and updating my_config.h as a workaround also seams to not help.

[uxigene]

After flashing multiple binaries, I discovered the following: – Versions newer than 0.8.6 fail to start the access point, although the NodeMCU still boots with the default orange LEDs. – Versions newer than 0.9.1 also fail to start the access point, but in this case, a single LED lights up white.

[softhack007]

updating my_config.h as a workaround also seams to not help.

I can say that updating my_config.h does still work, at least in version 0.14.0 and later. I use it frequently for my development boards, and never had a problem that my credentials from my_config.h were not used after a clean install.

Maybe there is a problem with the Wi-Fi code on 8266, or even an electrical issue with your device that causes Wi-Fi startup to fail.

Actually its very unlikely that generic Wifi problems on 8266 existed since version 0.9 . 0.9 is many years old, so lots of users would have noticed it in the last ~5 years.

"8266ex" is the normal processor model that's present in almost every NodeMCU and other 8266 boards.

[uxigene]

– Versions newer than 0.8.6 fail to start the access point, although the NodeMCU still boots with the default orange LED. – Versions newer than 0.9.1 also fail to start the access point, but in this case, a single LED lights up white.

UPDATE: While 0.8.6 is starting the access point, it does not connect to WiFi after submiting credentials. So, the last functional version for my NodeMCU is 0.8.5

[uxigene]

electrical issue with your device that causes wifi startup to fail

Very unlikely. I also tested with another NodeMCU with no wiring at all, and the results were the same. I would also expect faulty wiring or device to cause issues regardless of the firmware version.

Here is my wiring for reference:

8x32 Matrix | NodeMCU
------------------------
DIN         | D4 (GPIO 2)
------------------------
GND         | GND
-----------------------
5V          | VIN

[srt4328-ui]

Thanks for the responses all - I appreciate you giving your input and time to this endeavor! I'm still running through some permutations, but I still have don't have a working Wifi capable firmware.

@DedeHai - Thanks for the input! Unfortunately, I can find no way to check anything related to IPV6 on the TPLINK Access Point I'm using (TL-WA801N): there is noting in the manual or GUI settings of the AP for IPV6. The DHCP server resides in this simple wireless access point, so I didn't mess with my router.

@uxigene - Thanks for the sanity check! I didn't spend a ton of time using WLED_8.5.0, so it may have worked perfectly and I just didn't verify the connections in my wireless network AP.

@softhack007 - I appreciate your input and time. Once I managed to get debug working with my builds, I was able to confirm my suspicion that myconfig.h didn't seem to be affecting the binary build. I'm using the output below (post flash) as evidence the wifi station info from myconfig.h is not being used during compilation.

[WiFi: Defaulf SSID (Your_Network) used]

Maybe I'm still missing something critical here, but the default 'Your Network' happens even if the define statement in wled.h is uncommented (line 13)

esp-web-tools-logs (3).txt

I'm going to try a few more ideas.

[srt4328-ui]

Putting the station Wifi credentials into the platformio.override.ini produced the desired affect of forcing the MCU to attempt to connect to the wireless LAN access point after flash and subsequent reboot. Sadly this still is not working as intended, but it was what I was hoping would happen by using the myconfig.h parameters. I'm laboring under the idea that the overarching issue with ESP8266 WiFi has to do with Wifi.SoftAP, and that WLED would turn off the AP if the station credentials were present at boot. If this is actually the cause, then the message below might shed some light on why the device is still not connecting to the local wireless access point.

Initial connect or forced reconnect (@ 0s). WiFi: Defaulf SSID (The_Garage) used. initConnection() called @ 0s. ...... Access point disabled (init). [21:26:37][APdisconnect] set_config failed!

esp-web-tools-logs (5).txt

There still is a possibility that I'm going about this the hard way by using 0.16_alpha source.... I tried to use 0.14 earlier this evening and due to a stunningly silly error, I spent a lot of time re-installing VSC/PIO only to have the source from 0.14 not compile. Now that I have 0.16a compiling and all the dependencies sorted out, I might revisit a custom 0.14 build.

Below are the parameters I'm using in my override.ini file For those who may be reading this and not using WLED_0.16.0_alpha source, there may not be a nodemcuv2_160 environment built in older sources. The release name is of my own choosing so I can somewhat keep track of different permutations binaries - though my methods are starting to border on manic, 'scorched-earth' and I'm starting to worry I may fix the issue without remembering which dozen or so lines of code I remarked out!

[platformio] default_envs = nodemcuv2_160

[env:nodemcuv2_160] extends = env:nodemcuv2 board_build.f_cpu = 160000000L build_flags = ${common.build_flags} ${esp8266.build_flags} -D WLED_RELEASE_NAME="ESP8266_160_B1D" #- DWLED_DISABLE_2D -D WLED_DEBUG -DDEBUG_ESP_WIFI -DDEBUG_ESP_PORT=Serial -D WLED_DISABLE_PARTICLESYSTEM2D -D WLED_USE -D WLED_DISABLE_ALEXA -D WLED_DISABLE_ESPNOW -D WLED_DISABLE_INFRARED -D CLIENT_SSID='"The_Garage"' -D CLIENT_PASS='"redacted"'

[srt4328-ui]

Adding a quick update here - it appears my issue may be bifurcated (two parts) - something possibly quirky with WLED/8266 Wifi and something with the way my 802.11 AP is setup that doesn't work with the current espressif SDK. I reverted back to WLED_0.8.5.0 - the wifi scan works but the MCU will not join any of my 802.11b/g/n APs.

I pivoted back to using Tasmota to troubleshoot: I had previously tested with Tasmota version 9.3.1 and had no issues scanning wifi networks and joining them. I confirmed this is still the case, and then loaded the latest 8266 (1M) release of Tasmota15.1.0.2. I can scan and see available networks, but I can't join them - I tried switching to 11b then 11g only. Prior to getting started with WLED, I had bought a new router with the plan to retire my older wifi equipment, so now seems like a good time to start. I'll setup the new router to look into resolving the Wifi connectivity issues using Tasmota to test, and once that is resolved I will reinstall WLED and see if there is still an issue.

[srt4328-ui]

Update - spun up new Mikrotik router as a fancy AP last night. I would have like to have gotten more testing done, but unfortunately the new router was stuck in boot mode and I spent most of my time getting it back in working order. I confirmed that the latest release of Tamota was able to successfully grab an IP from the AP before going to bed.

This morning, I checked to see if the MCU was still holding an IP and link to the new AP, and it was. I then flashed the MCU with WLED_8.5.0 and it appeared to join the AP without any trouble, but this was not thoroughly tested. I moved on to WLED_0.15.1_ESP8266_compat (standard binary - not custom compile). Wifi scan doesn't work from web install and after manually entering the station credentials, I found the MCU was not pulling an IP lease from the AP.

Next steps will be to get the new AP permanently installed into my home network and triage the fall out from various 'smart' devices. While this has no bearing on the veracity of the WLED code, it will significantly expedite further testing, as it will help to expose any routing issues in the new AP or home network (I use different VLANs for different traffic and the WLED devices will be in there own VLAN). Once that is settled, I plan to revisit custom binaries with debug in hopes of finding a resolution.

Before I began the journey of getting the new AP online, I tried using a new (factory sealed) 8266 and followed the same protocol of testing with Tasmota (old then new) as a sanity check to be sure the connectivity was not an issue unique to the board I was testing with.

[DoraDeu]

Same issue on my side. Hardware: ESP8266EX on a H801 with 1MB Flash Memory. I installed all WLED versions that the web installer offered but no AP is shown after the sucessfull flash. Tasmota (flashed the same way) works perfectly. In the internet I found many reports that first flashing Tasmota and then flashing WLED would fix it. Unfortunately I was not able to check this out because even with the minimal version of Tasmota there was not enough Flash Memory left to flash WLED from the Tasmota Web UI.

[srt4328-ui]

Hi @DoraDeu! Thanks for the note.

In my searches for answers I saw the same information, but I haven't fully vetted that yet. I did attempt to follow those instructions, but at that time I wasn't aware that there was something going on between my old wireless network and the 8266.

I've just now got all the bugs worked out of my new wireless network (I hope!) and have resolved all inter-VLAN routing issues. I hope to be able to devote some time resuming testing later today.

[srt4328-ui]

Just started poking around and the new router is already helpful. I haven't managed to get the router debug turned on just yet, but here's a preview from the standard log.

2025-11-24 12:07:35 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: connected, signal strength -62 2025-11-24 12:07:39 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: disconnected, extensive data loss, signal strength -62

How I got here was by performing a fresh web install and letting the website determine the version (WLED 0.15.1/2507300 (esp8266)). Post flash, I used the web installer to manually set the station credentials (Wifi Scan did not detect access points). As expected, the web page informed me that the MCU could not join the network. I pressed the reset button and repeated 'Config Wifi' from the web installer. This time the wireless network name was populated with the correct SSID that I previously entered, but again there were no other access points discovered by Wifi scan.

The MCU is on the opposite side of the room from the AP (approx 11.5 feet (3.5m) if a tangent was drawn between them)

Here's a more thorough log of the interaction between the MCU and the AP:

11-24 11:42:45 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: connected, signal strength -59 2025-11-24 11:42:50 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: disconnected, unicast key exchange timeout, signal strength -68 2025-11-24 11:44:36 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: connected, signal strength -58 2025-11-24 11:44:41 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: disconnected, unicast key exchange timeout, signal strength -65 2025-11-24 11:45:01 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: connected, signal strength -60 2025-11-24 11:45:06 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: disconnected, unicast key exchange timeout, signal strength -69 2025-11-24 11:46:20 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: connected, signal strength -58 2025-11-24 11:46:24 wireless,info 84:F3:EB:8E:63:60@wlan3 2.4G: disconnected, extensive data loss, signal strength -58

From here I will most likely retire the remaining mesh access point from my old Wifi network and see if this has any affect. I don't expect a change from this as previous testing with the new access point using Tasmota and an old version of WLED work without any obvious wireless issues. After that I will revisit custom binaries with debug turned on.

[DoraDeu]

Thank you for the update! I hope that one of the developers find some time to look at it. The fact that the last working version of WLED has been identified should help to find out what has been changed to fail on some hardware now. Running Tasmota without any problem should prove that the root cause can´t be defect hardware.

[softhack007]

@srt4328-ui Thanks for the testing and the logs :-)

disconnected, extensive data loss, signal strength -62

This is very low considering the small distance you describe; -62DB is 1-2 bars ("Fair" to "Low"). "Disconnected" also implies that the MCU has connected, so its using the right credentials for connecting.

Running Tasmota without any problem should prove that the root cause can´t be defect hardware.

I know you all don't want to hear it, but this does not exclude cheap hardware. It proves that the tasmota code is better in establishing the connection, nothing more. WLED uses the standard arduino functions for Wifi. Not sure what tasmota is doing, most likely they are not running the "soft AP" in parallel, while trying to connect to the network.

Wifi initial connecting draws a lot of power from the LDO, and some cheap LDOs are not capable of sustaining the power flow, so the 8266 tries to lower power output until its radio gets stable. One possible solution is to add a capacitor between 3.3V and GND pins, to stabilize the 3,3V power rail of the board - see https://kno.wled.ge/basics/wiring-guides/

There are a few things you could still try without a soldering iron:

Wifi Settings:

• Force 802.11g mode (ESP8266 only)
• Disable WiFi sleep
• mDNS address: clear (empty = no mDNS)
• (Wi-Fi router) use a fixed Wifi channel, instead of "auto" (4-8 seem to work best)
• (you) increase the distance between router and your MCU - sometimes a too-strong Wi-Fi signal can cause problems, too

A custom build with -D WLED_BOOTUPDELAY=600 - this will add a small delay at startup, which might be enough for the LDO voltage output to stabilize.

@blazoncek @DedeHai @lost-hope any additional thoughts?

[blazoncek]

IMO any and all "AP won't show" type of reports are due to sub-par hardware, incorrect hardware (controller) or wiring set-up or misconfigured WLED. Why? I've created more than 100 WLED devices (lamps, megatrees, fence and roof lining, etc) using ESP devices (8266, ESP32, S2, C3, S3) from various batches and each and every one of them entered AP mode successfully on 1st boot.

[softhack007]

@blazoncek yes, also my observation - with exception of these "lolin" C3 and S3 boards, where we found a workaround with -D LOLIN_WIFI_FIX. It turned out that the root cause was not defective hardware, but cheap / bad board design, or another "wemos" board design problem described here.

Just saying it's not the first time that boards with a cheap design cause problems that appear like a software failure. In the case of 8266, its a known fact that some boards have problems coming from cheap LDO parts, which leads to connectivity issues.

[srt4328-ui]

Thanks @blazoncek and @softhack007 for your input: I appreciate you both taking the time to add your insight and experience!

I had heard of the filter capacitor issue with some of the inexpensive boards, but wasn't aware there were other hardware design issues in the antenna section. The boards I'm testing with have the Wemos name screened on the PCB though they were sourced from Aliexpress, so they could be a cheap copy of a cheap copy.

Currently, the test configuration consists of the board powered by a USB cable that is connected to a PC. There are no ancillary connections to the boards, not even header pins. I'll look into modifying one of the boards as I'm intrigued about the antenna section and it may be useful to become familiar with that area should I need to modify the board for an external antenna later.

I did test (briefly) with a modified version of 0.16.0-alpha yesterday, and while it would not complete the Wifi.scan for available networks, adding the station credentials to the overide.ini did allow the MCU to connect, pull an IP and then drop the connection in such a short period that I'm surprised it was captured.

Later testing with Tasmota revealed that older version 9.3.0 works the best with the MCU wireless, and that the latest version will successfully scan available networks, but sometimes will not join them right away, or it will drop connection and then rejoin (intermittent). I'll spare everyone the details of testing since they don't lead to a solid conclusion. Tasmota reports an even lower signal level (-69) using mode 11n, channel 1.

From here I plan to look further into possible wifi interference using some testing functions of the router. While I know this is probably not the root cause of the issue with WLED, I hope it will correct any issues that might affect the wireless network performance and prevent me from looking into issues with WLED that are really external to the MCU.

The router is currently set to indoor mode, US national standards, WEP2-PSK, 11-g/n, 20Mhz wide channels. I'm certain I set the wireless was to b/g/n, and wonder if it changed when I committed to the new firmware, so more testing!

[DedeHai]

I found this about software vs. hardware: https://github.com/esp8266/Arduino/discussions/8163#discussioncomment-4975317 the whole discussion is pretty much exactly about this issue and in the end it was mostly hardware. It also explains why the "LOLIN_WIFI_FIX" is needed to fix bad hardware design. While there are a few things that can be done in software, it is undocumented and as you can read in the comments I linked even subject to speculation among the experts and on top of that it changes "at random" on each SDK update, that is why older versions or different software like tasmota or ESPeasy can behave differently. From my own experience: some boards with sub-par antenna design have a really hard time on WIFI channels 1-3 and 9-11 but work well on 4-8, confirming the linked discussion.

p.s. I just realised: I completely forgot to update the default AP channel WLED uses from 1 to 7, I thought I had done this months ago...

[DedeHai]

@uxigene I added a potential fix, it will be in the nightly build within 24h. Can you please test if it changes anything regarding "AP not showing up"? You need to erase the flash i.e. do a fresh install directly to the nightly build for it to do anything. You can use direct upload using VScode or https://wled-install.github.io/ although I do not know when exactly that site updates the nightly builds, so may take 48h.

[blazoncek]

@DedeHai selecting 7 is a bad choice as it partially overlaps with 6 and (all the way up to) 11. If you found that channel 1 is not "good" then next best choice would/should be 6 as far as WiFi spectrum (and interference) goes.

[DedeHai]

good point, I will update it to 6. I will also do this as a PR so it will show in the changelog