WLED 13.1 Locks up with ESP32

I have about 1200 LED’s in a segment. It’s not a big deal that it lags a little since it is just lighting a front porch in the evenings most of the time. Last night I saw the update to 13.1 and figured why not. I updated both my ESP8266 running a 50 LED string and my ESP32 running my 1200 LED string.

A few minutes later the LED string on my front porch locked up, basically no response from the WEB UI and the LED’s were stuck with no changes happening. Reset just in case and a few minutes later the same thing happened. https://smile.amazon.com/gp/product/B09DPH1KXF is the controller I am using just in case.

Anyway I was running 13.0-b6 previously and it works perfectly so I rolled back and it is again working just fine. GPIO 2 is used for the string and GPIO 13 is used for a solid state relay but other than that it’s just power and ground. The PSU is rated for 70 amps at 5 volts so I doubt that is an issue and there is a ESP8266 with a PIR motion sensor as well as a DHT22 Temp and Humidity sensor powered by the same PSU.

The initial install was done using the WEB installer and Chrome I updated using the OTA to 13.1 and then downgraded to 13.0-b6 with the OTA through the device WEB UI and it is now working without issue.

Mutt, I’m seeing the similar behavior, but I’m seeing it on v0.13.0-b7 on a Digi-quad. If you’re saying b6 works well, I might go back to that.

My symptoms are surprisingly cyclic though - My lights work fine for about 15 seconds, then they stop for about 7 seconds, then the cycle of 15 and 7 repeats over and over. I can watch the info screen and it shows me the frame rate going from 42 fps when it’s working then drops to 0 when the lights stop, then it bounces back up to 42.

I’ve reduced my ports from 4 to 1 and only have 300 LEDs allocated, but the issue persists.

@MuttMutt Thank you for the detailed report! Do the lock ups only happen on a specific effect?

@sooner I believe your issue is separate, since the web UI remains reachable, but the main loop stalls. It seems typical for a failed network request. Check if MQTT, Blynk, or Hue Sync are enabled (in case of blynk, the token field would read Hidden) and test if disabling them fixes it.

1 Like

@Aircoookie No specific effect at all. In fact even with an effect off it will lock up and the UI will be unresponsive. Sometimes it will lock up after just a few seconds other times it will take a minute or two. With the lights off it’s generally a little longer so to flash back I powered everything off for about 10 seconds turned it on and then hot footed it to my computer to turn off the light and flash it back to 13.0-b6. Now that I think about it I think it started acting up in 13.0-b7 as well but I had so many things going on I just flashed back and didn’t bother with it.

These controllers are a little odd in some ways as well. Maybe it’s the controller that is the main issue in some ways but when flashing via cable you HAVE to hold the flash button down throughout the whole process or they will lock up and fail.

Looking at the other issue that piggy backed on and to just double check I don’t have any of the sync stuff on that I know of outside of whatever it is set to as default. I can run LED FX and have it control the LED’s but I rarely use it and was more just messing around with stuff because I could.

No boxes in those areas were enabled, but updating to 13.1 seems to have fixed the issue. Thanks @Aircoookie for all you do.

I’m having the same issues as @sooner and @MuttMutt and have been fighting and troubleshooting this all day. ESP32 had been running fine for a week on 13.0-b6, and went up to 13.1 yesterday. Constant lockups and disconnections. I enabled the WLED-AP to try to diagnose behavior. During the lockup WLED-AP is available but will not accept connections saying the default password is incorrect. My thinking is the controller is completely locked up. LED strip activity halts, and the on-board LED on the ESP goes out completely. I have tried rolling back to 13.0, and 13.0-b7, and all exhibit the same behavior. I even tore the board out of its project box, disconnected the LED’s and powered straight from a benchtop supply, same behavior. I have been trying to isolate if it’s a power issue, interference issue, or software issue all day today. However since I have nothing else connected but power, bypassed all circuitry and connected the supply directly to the ESP32 VIN and GND pins, with a 2A limit on the supply, it’s not power or interference. It’s probably software from the behaviors I’ve observed.

Things I’ve observed:

  • I was using a steady ping to monitor uptime and when the device goes offline. However, I found having this constant ping going made the lockup occur sooner. Disabling this ping allowed it to operate for several minutes before locking up.
  • Disabling the device integration in HA had a similar effect.
  • Connecting the LED strips makes the lock up occur sooner, sometimes within 1-2 minutes of power up.
  • Latest observation using 13.0-b7: 1. Connecting to WLED-AP immediately after power up. 2. Disconnect after navigating a few menus. 3. Device continues to operate and remains connected to the network, continues to operate. I have been watching this and it’s been up for almost two hours now. I haven’t been able to get this far all day today.

edit: It went for 8h 41h before locking up and dropping off.

Have you tried powering directly through the USB port and seeing how long it stays up? I don’t know why this is, but I’ve found that chips from some manufacturers seem to function fine when powering directly from a USB cable and wall plug/computer, but have a problem with direct 5V injection.

Based on what I’ve seen on an OScope, the power given from a PC USB port or even a wall adapter and well made USB cable is much cleaner than the 5V given by many SMPS. Some chips handle less-clean power better than others. I suspect this, but haven’t proven it definitively.