Lights on ESP32 controller turning themselves off ESP8266 remain on

[P3TACCO]

What happened?

I'm reopening this bug report

I have WLED controllers, I tried four (and now 2 Athom ESP32) running on ESP32 two on ESP8266. All are running version 0.14.4 WLED.
The ESP32 controllers turn themselves off (power cycle back to default state) at random intervals. The time delay may be 2 minutes or 30. The Power button in the app goes out when the lights go off. The Nightlight mode is off and the timer function is not started.
The ESP8266 based controllers stays on indefinitely until commanded off - I have them hooked up to Gemstone house lights they're running for about 8 hours continuously each night.

Update: 9/27/2024
I purchased two ESP32 Athom LED Strip Light Controllers linked from the WLED site
They are doing the exact same thing

https://www.athom.tech/blank-1/wled-esp32-music-addressable-led-strip-controller

I left the power up default behavior in the default config -> orange color (ffa000) 128 brightness level (half)

To Reproduce Bug

Run WLED on an ESP32 based controller.
Turn on the lights.
Wait.
The lights will turn themselves off after a variable amount of time (always shorter than one hour) back to the default power up state.

Update: 9/27/2024
I turn on the lights - for testing I'm selecting color 255,0,0,0 and brightness 255 (full)
after a variable but relatively short period of time there is some type of power cycle/glitch
The LEDs go to the default power on state - orange and 128 brightness

Expected Behavior

Lights remain on at the level and color set until commanded off.
Mirroring the behavior of the ESP8266 controllers.

Install Method

Binary from WLED.me

What version of WLED?

0.14.4 Build 2405180

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

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

[P3TACCO]

I reset one of the ESP32 controllers to factory defaults and reinitialized. I haven't set up any presets in it. It still does the same thing.

I've also tried turning the Wi-Fi sleep on and off without a change to the behavior.

Something has to be triggering the software power button to the off state.

Both ESP32 controllers have onboard microphones, the ESP8266 does not.
I reflashed one of the ESP32 controllers with the plain version of WLED and the same behavior occurs.

This behavior occurs with both short (2-10) and long (170 and 400) strings of leds.
It occurs when using the controller power pass through and also using a separate power supply and pulling only the data output from the ESP32 controller.

[P3TACCO]

I reflashed one of the ESP32 controllers with WLED 14.3 and the same behavior occurs.

[DedeHai]

any buttons configured? what is your hardware setup?

[P3TACCO]

It is a readymade "Gledopto" unit. It has a single button which turns the lights on and off (long press resets the controller).

It does the same thing with three different 12V power supplies. I set it up to operate my house lights where I was only pulling data through the board, not LED power. They'd operate correctly (RGBW- effects, etc) but turned off spontaneously after a few minutes. The ESP8266 "Ericsity" readymade box with nearly identical features stays on indefinitely until commanded off.

On the desk for testing it is providing power to the few LEDs I have connected.

Either way - same behavior. I've turned it on via the app, desktop tool and the front button - same behavior.

The Data is coming out from GPIO2

[blazoncek]

Have you talked to Gledopto? It seems like hardware issue.

[P3TACCO]

Not yet, Not a bad idea.
Thanks

I disabled the pushbutton in the config. No change

Any idea what hardware issue might be causing this?

[P3TACCO]

I'm going to return theses controllers and try a different one.
For now I'll close this thread, thanks

[P3TACCO]

Did a little more testing. These units are power cycling for some reason. If I set a color and brightness after a variable period they cycle off and back on to the default on setting.

I ordered two of the Athom models

[P3TACCO]

Received the Athom controllers today, they're doing exactly the same this as the previous ESP32 units

[P3TACCO]

My house permanent Gemstone lights have two power supplies, each power supply has 4 taps 12V 8A each.
All 8 power taps are used.
The main house has 431 LEDs on controller A
The garage has 168 LEDs on controller B
There are power injection points along the strings and the power supplies are reliable and steady
The LEDs are RGBW pucks
In this configuration the controllers are not passing through power, only the data line is tapped.

This behavior also occurs with a wall wart 12V power supply and only 10 LEDs attached for testing
It also occurs when using a dedicated 2A 12V LED driver power supply and only a few LEDs attached.

I've also tested it with just the controller connected to power, no LEDS attached and monitoring the state within the WLED app.

The same behavior occurs - at some short interval after the lights are turned on, they power cycle back to the default setting.

[P3TACCO]

I retrograded the controllers to WLED 0.13.3 - same behavior

Also tried 0.15.0-b3 - same behavior

[willmmiles]

OK, I'm getting that your devices are sometimes unexpectedly rebooting. Given that you've tried different hardware, that suggests something else in the environment might be responsible. Are your devices being controlled by some other software integration? If so, what?

To complete the hardware testing, I'd suggest leaving a device isolated from your wifi for a bit. Connect to it while it's in AP mode and change the lighting without joining it to your wifi; and then leave it be for a while and see if it still resets. If that seems OK, it's a strong indication that something on your network is triggering the fault - and that gives us something further to dig in to.

[softhack007]

This reminds me of an old (and still unsolved) problem with wifi routers from AVM ("FritzBox"). If you have a FritzBox or Unify router, it could be that the esp32 regularly reboots. It also seems to happen more often if you have a wifi mesh to extend the range.

• Reboot with the new OS7.50 from the Fritzbox 7590 #2932

There have been a lot of discussion and investigations, and the root cause seems to be so somewhere deep inside the espressif wifi driver (which is not under our control). The only known workaround is to install a firmware that was build with the "V4" framework:

https://github.com/Aircoookie/WLED/blob/1ff667b7eff07ebad100e48eb871c698eab11a71/platformio.ini#L490

FritzBox hardware is used a lot in Germany, however almost unknown in the rest of the world.

[P3TACCO]

Interesting. Thanks for the leads.
I found a thread from a few years ago talking about the MQTT settings even without MQTT turned on.

I'll do some more experimenting. Take one of the controllers off the wifi. Play with the settings.

I'm in the US and I have three Grandstream Wifi6 APs. They're all PoE wired back to the main switch and firewall/router. The controllers don't move inside the house so I wouldn't expect them to be handing off. But the polling issue is a good lead.

I really want to solve this. In my application they have to be on wifi. I really want the faster, more responsive ESP32.

[willmmiles]

The only known workaround is to install a firmware that was build with the "V4" framework

I'm still comparatively new around here - what were the issues with the newer framework revisions? Was it just size, the buggy arduino cores in the 2.0.x series, all of the above, or something else? I'll admit I build WLED with platform = espressif32@ ~6.3.2 for all of my ESP32s, except when I'm chasing a particular bug report.

[softhack007]

I'm still comparatively new around here - what were the issues with the newer framework revisions?

Hi @willmmiles, maybe you're still new, but a very valuable dev team member already 🥇

There were a lot of problems with the new arduino 2.0.x revisions in the past, but I agree it has become usable with arduino-esp32 v2.0.9 and v2.0.14 (I still have doubts about anything that came after 2.0.14).

So core stability problems seem to be solved now; personally, I often use 2.0.14 on esp32 for development and testing.

I think that two issues remain

1. flash size - builds with the new framework are like +250kb in program size. This is too much for the typical 4MB device.

• we could enable -flto (needs platform 6.6.0 or later) to reduce firmware size (between 200kb and 400kb). Downside: it makes crash dumps (stack traces from exception decoder) unreadable. Maybe that's something for 0.15.1.
• we could reduce the LittleFS partition to 512kb, this adds like 256kb space for program. However, this change would make it impossible to OTA update older versions.

2. in userland most people flash their devices once from install.wled.me, then update by OTA. Unfortunately, OTA cannot update the bootloader. Going to the new framework means that we'll have lots of "V3 bootloader and V4 firmware" setups. In the past this caused very unresponsive devices (suspected case LittleFs). Not sure if this is still happening. We definitely need more testing to safeguard the "OTA to V4" upgrade path on esp32.

All is just about esp32 -- esp32-s3, esp32-s2, and esp32-c3 already run happily with the new framework, but they have almost nothing in common with classic esp32.

@P3TACCO would it be an option for you to try a board with ESP32-S3?

[softhack007]

@P3TACCO you can install a "V4" firmware from https://wled-install.github.io/

V4 might be worth a try in your case, as the wifi feature support is better in the new framework.

[P3TACCO]

I think we ate getting somewhere.
I took one of the Athom controllers off my wifi. And it stayed in the config I set for over 9 hours.

So the leads above on wifi seem to be narrowing this down.
I'll read through the last 3 posts and give tgem a try.

[willmmiles]

Yes, try the v4 build; if that still has trouble, I can give you an beta web server queue build that's aimed at trying to better handle some load issues that can cause crashes.

[P3TACCO]

Ok this is promising. I think we've correctly identified the issue as related to wifi.

Last night I edited the wifi configuration and deleted the mDNS address on both controllers. You all have been describing over polling so I thought this might be an issue.

On one controller I also unchecked the "disable wifi sleep" box.

It was about 9 pm, I turned on both controllers to a non boot up state (full white, 255 brightness).
This morning at 8 AM both controllers were still in the selected state.

So I think the mDNS was the problem inside my network. I'll turn no wifi sleep back on and continue testing.

I'm going to hook one up to my house LEDs and do some more testing, but this is promising.

I'll experiment with the V4 binary too.

[blazoncek]

What's your router/AP brand? #2932 #2751

[P3TACCO]

I have a TP Link Omada OC200 Controller, ER605 Firewall/Router and a TL-SG3428MP 24 port POE switch.
I'm using three Grandstream GWN 7664 APs for Wifi.
The ER605 is the DHCP server, I had configured all of the WLED controllers with Static IPs from within WLED.
My next test would have been an IP reservation inside the router.

I've had one of the Athom controllers connected to my main house string (431 pixels) for 4 hours, so far it's running correctly and has not rebooted.

[blazoncek]

You may want to verify WiFi settings (fast roaming, etc), lock channel width, lock channels, etc.
And then use Wireshark to monitor what's causing reboots.

[P3TACCO]

Since I deleted the mDNS entry both controllers have been running properly.
Everything remains on until commanded off, and all functions work, no spontaneous reboots.

I haven't been able to,take the time to identify the particular issue.

I am running AdBlock and my DNS settings point to that server. I wonder if it keeps trying to reconcile the ip address and the mDNS name and that is causing the saturation/reboots.

When I get some time over winter I'll play with it.

Thank you all for the leads and info that helped me solve this issue.

[P3TACCO]

Appears to be a network issue related to ESP32 wifi