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
• 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''
• LED data corruption with RMT driver

[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 on a ESP32-based board. 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 several 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

---

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 some random ESP-NOW remote slowness (the code probably gets stuck in some long, buggy loop) and the 0_15_x branch having the classList bug.

[DedeHai]

regarding the "frame rate control" PR: in one of the last comments (#4244 (comment)) the android effect is mentioned. I fixed that one up in #4522

although not tested by users, I am pretty sure that the refactored android effect works the same as the original. cherry picking that PR should fix the issue mentioned in the comment.

[blazoncek]

@DedeHai classList error fixed.

[Arcitec]

@blazoncek Perfect! Was it fixed by this commit? It's the only new commit so I guess it is?

2f31ff0

Edit: Yeah that fixed the classList issue. It wasn't able to find that element before, so "null" was returned instead of the element.

[Arcitec]

I have some big progress on the ESP-NOW bug. It is not unique to 0.15.1. It's a serious ESP32 hardware bug. So I documented it in a new ticket where we can discuss workarounds, since it wasn't exclusive to 0.15.

#4703

[MakerMatrix]

I was prompted to report this here - It seems there are ongoing issues with the RMT driver in 0.15.0 through 0.15.1-beta2 (possibly some of the 0.15.0 betas as well - I have not tested), causing flickering/flashing and lighting of LEDs past the ones that are configured for output. This is discussed at length in #4389.

[Arcitec]

@MakerMatrix That's right. But check the status in that topic (I admit it's long and I have only skimmed through it myself). It seems the issue is RMT and that the solution will be to use I2S in parallel instead:

But there's some discussion about what to do:

Blaz: #4389 (comment)

I don't think we'll backport RMT solution into 0.15 as it is already waiting in beta for quite some time without any proper feedback from beta testers and 0.16 will bring so many enhancements and performance improvements that it makes no sense to invest time in 0.15.x.

@willmmiles (12 hours ago): #4389 (comment)

As for backporting to 0.15.1: I believe that this is a big enough problem to warrant a real fix, even if we're just changing the default hardware assignment to parallel I2S as a mitigation. Whatever it turns out to be, I don't expect it to be a difficult port, and I think we'd be doing users a big disservice if we ship something this broken as the next release.

Long at the short of it: I'm still investigating and I'll hopefully have more answers as to the root cause and possible mitigation soon.

I would agree that just disabling RMT is a good enough solution for 0.15.1 and that it sounds reasonable to implement it in 0.15.1 to fix this issue while people await 0.16.0.

It might be as easy as disabling the code path that uses RMT mode when length is under 300 LEDs (if I understood correctly, that's when RMT is used). So that it always uses the normal rendering mode from 0.14.x.