WLED - 0.15.1 release prep

[netmindz]

Issue to check that the bugfixes since 0.15.0 that have been back ported from main to 0_15_x have been tested on that branch before we release the official 0.15.1 release

• bugfix in enumerating buttons and busses
• Fix wipe effect smoothness
• fixed refs to removed usermod
• Improved framerate control code - strip.show(), strip.service()
• Fix for Segment "update" hint not disappearing
• Fixes first pixel not being set
• Bugfix for incorrect wifi-hardware timing
• Multifix
• fix reproduction in game of life
• Fix for ESPNow remote causing output glitches
• Proper fix for #3605 & #4346
• WWA strip support & parallel I2S for S2/S3 (bumping outputs from 5/4 to 12)
• BUGFIX in oscillate FX
• Fix for #3955: added a delay after switching relay
• FX: Waterfall, Matripix & Dissolve fix
• BUGFIX PWM brightness discontinuity (fixes #4396)
• palette effect overflow fix
• Update readme.md for rgb-rotary-encoder usermod
• BUGFIX for Fairy & Fairytwinkle FX
• Idle current bugfix
• Playlist output glitchfix update: found it also happens on S3
• Fix output glitches when playlist changes preset for S2 and C3
• Add correct pin availability for ESP32 Mini modules
• Cherry pick mulifix
• platformio_override.sample.ini does not work - 'No option 'default_partitions' in section: 'esp32_idf_V4''

[DedeHai]

I ticked off the ones I am confident to not introduce any bugs.

#4474 Relay delay fix: I am not too sure that this fix will not introduce "white flash" issue in some setups. In the issue raised, the delay fixes it but there might be LED types that work better without the delay. So far, no complaints by beta testers.

[netmindz]

Thanks @DedeHai that's a big help

[DedeHai]

just wanted to test some of the fixes and can't get it to run on my C3 setup. Even a flash wipe did not help.

When I install 0.15 it works just fine, 0.15.1beta2 always throws this error, even on a fresh install. OTA to 0.15 and its fixed, OTA to beta2 and the error is back.

uncaught (in promise) TypeError: Cannot read properties of null (reading 'classList')
    at setEffectParameters ((index):1:107042)
    at updateSelectedFx ((index):1:101109)
    at updateUI ((index):1:99212)
    at (index):1:81805
    at <anonymous>

edit: same on ESP32

[Arcitec]

@DedeHai 100%. Same error happens to me. It happens when using WiFi but not when using Ethernet btw.

• 0.15.1.beta2 tag on main: Works.
• 0_15_x branch: Broken.

I saw that the git diff shows that sevral new "classList" property accesses were added to the code in the 0_15_x branch compared to the older beta2 tag. But it doesn't explain why it seems to work via Ethernet on the new branch.

But there's also a ticket here which says that it (or at least a bug with the exact same symptom) was introduced all the way back in 0.15.0: #4535

[Arcitec]

I have also spotted another issue in 0_15_x branch / 0.15.1.beta2 tag. Is this a known issue? I can move it to a new ticket if that's better!

• WLED 0.15.1 responds very slowly to ESP-NOW remote commands.
• Saw it when using a ESP-NOW remote which pairs with the WiFi/network-based remote control feature of WLED. It uses the "ESP-NOW" protocol.

Here's a video showing how slow WLED 0.15.1 is:

• At 0:02: Pressing "off". The right strip immediately turns off.
• At 0:12: The left strip finally turns off too. 10 seconds later!
• At 0:16: Pressing "on". The right strip immediately turns on.
• At 0:21: The left strip finally turns on too. 5 seconds later.
• At 0:24: Pressing "off". The right strip immediately turns off.
• At 0:45: The left strip finally turns off too. 21 seconds later!
• As you see, the delay on the left side is very random and inconsistent. Sometimes it's even very short. It also seems to get better for a while after WLED reboots, but I am not sure yet, still testing to find a consistent pattern...
• Left strip: Using 0.15.1.beta2 tag (since that's the only one that doesn't have the "classList" bug from the previous message). This strip responds many seconds after the remote control's network command is sent. Connected via Ethernet. Built via the esp32_eth environment.
• Right strip/light bar: Using 0.14.3 release. Connected via WiFi.
• Hardware controllers: Exact same hardware on both.
• Flashing to WLED WLED_ 0.14.4_ESP32_audioreactive (and connecting via WiFi because the 0.14.4 Ethernet binary doesn't support ESP-NOW) on the left controller makes them both respond rapidly to remote control presses. So the issue seems to be in 0.15.1.
• Still investigating this so if I find more insight into what's going wrong in 0.15.x, I'll let you know.
• Update: Wait, I just looked at ESP-NOW. It seems to be a separate protocol which doesn't use the home network (WiFi/Ethernet) at all. It says that it's a direct chat between the remote and the ESP32 via Bluetooth or WiFi-direct. So that's great news in terms of narrowing down the issue, if that's true. That means the slow responsiveness is definitely in WLED 0.15.x and not related to the controller hardware/home network connection (since older WLED versions are responsive on this hardware), since ESP-NOW doesn't use the home network.
• Beware if you want to help test this ESP-NOW protocol issue: The delay is RANDOM. Sometimes it's fast/responsive for a while. It can even be all good for like 20 minutes or more, and then suddenly it becomes slow again. I haven't found the pattern yet!

0.15.1-delay.mp4

General WLED 0.15.1 review:

• I have been using the 0.15.1.beta2 tag on main, and it has been very stable in all other feature testing: WiFi, Ethernet, Colors, Pins, Control Button, AudioReactive, etc.
• The only issues I've seen are this network slowness (the code probably gets stuck in some long buggy loop) and the 0_15_x branch having the classList bug mentioned in the previous message.

[Arcitec]

Okay, this may be an important discovery:

I was able to find why ESP-NOW remote control support is only in WLED_0.14.4_ESP32_audioreactive and not in 0.14.4_esp32_ethernet.

There was a comment in the WLED platformio config in 0.14.4:

• -D WLED_DISABLE_ESPNOW ;; ESP-NOW requires wifi, may crash with ethernet only
• So in WLED 0.14.x and earlier, the ESP-NOW feature only existed in WLED versions that are WiFi-only.
• If the 0.14.x and earlier firmwares are built with ethernet support WLED_USE_ETHERNET, then those platform configs always disabled ESP-NOW.
• In 0.15.x this was changed and WLED has enabled ESP-NOW for ethernet firmwares too.

This may be the issue. ESP-NOW may still be unstable when the ESP32 SDK has both ESP-NOW and Ethernet support enabled at the same time.

In fact, 0.14.4 and 0.15.x use the exact same ESP32 SDK version. Nothing has changed. Yet WLED now enables both features at the same time. That may still be problematic, if there's some bug (random freezing/slowdown) in the ESP32 SDK when both of those features are combined.

Unfortunately it's become a very intermittent issue now, with loooong stretches of time (20+ minutes so far) without any ESP-NOW remote slowness on 0.15.x. But then suddenly it'll be super slow again. I hate when bugs are random.

---

My best idea right now is to bump the ESP32 SDK version used by WLED and hoping that Espressif has fixed the bug in a newer SDK. It's outdated (platform = espressif32@3.5.0). Perhaps the latest 3.x SDK has fixed whatever ESP-NOW bug this was. What do you think about bumping to the latest 3.x platform? What's involved in doing such a bump? Is it just a matter of changing the common platform line since it's all still within the 3.x SDK branch? Or are there more platformio.ini locations that need to be bumped?

I know that Espressif tends to backport bugfixes to the v3.x SDK line for years after it was "abandoned and not getting new features", so WLED is definitely missing out on various important ESP 3.x SDK bug fixes already! But perhaps it's only truly fixed in ESP32 4.x SDK where all their latest development is going on... I know that the rewrite of WLED to v4 SDK has been stalled since January though, since there's a lot of variable renaming and validation to do with such a big change.