I have two hand-made WLED installations, one running WLED SR version 0.13.3 and the other a self-compiled version of WLED version 0.14.0-b1 with the AudioReactive Usermod.
For both, I’d like to setup a physical button that cycles through playlists. Each button press should move to the next playlist. I have this successfully running on 0.13.3 SR, to do so I have the following:
Setup a new Preset (ID#2) with the API Command: P1=10&P2=14&PL=~ - the playlists are in presets 10-14
In Config/Time & Macros - for Button 0 short press, I’ve put in 2 to select the above command.
Using the button on the device successfully cycles through playlists.
I’ve done basically the same thing in my custom compiled 14.0-b1 installation and every button goes to the first playlist and never iterates up. In this case:
There is a preset (ID#99) with the API Command P1=20&P2=22&PL=~ - the playlists are in presets 20, 21 & 22.
In Config/Time & Macros - for Button 0 short press, I’ve put in 99 to select the above command/preset
Both devices have GPIO #17 set for the button press - both with Pushbutton as the type. The hardware is the same (though obviously built seperately). For the 0.14 installation, I’ve tried both with and without the internal resistor. Both are running an ESP32 dev board.
Feels like I’ve missed something obvious. Any help?
All good - so I checked out repo and built main. No change in the button behaviour and I now get LOTS of flickering during presets, especially during transitions between presets in a playlist. Seems to be worse when a preset uses all the LEDs (there are 279 in this layout). I’m only running at 2A when a power supply capable of 3A.
That all said, reflashing back to 0.14.0-b1 resolves the flickering - but obviously no button fix. Thar build is still a custom compile - with audioreactive usermod as I mentioned in original post.
Is the flickering a known beta 2/3 issue? It’s very likely I’m doing something wrong as this is the first board where I’ve had a crack at Platform.IO and custom builds.
Fwiw - the flickering also appears in the peek display.
Still flashing/flickering - still worse in transitions. Possibly not quite as bad as my build, but could be subjective. I made a video, but the compression in Google Photos hides the flashing of the UI.
FWIW - my LEDs have 9 segments. I’ve tried clearing the segments and treated the string as a single segment. Still flickers - it kind of looks like a brightness cycle up/down by 20% or so.
That would suggest it’s hardware related. I’m not counting that out BUT… I’ve narrowed the different behaviour to this commit.
Any builds using commits earlier don’t have the pulsing/flashing that I’m seeing. This one (and later) do have it.
@blazoncek any thoughts on the flashing/pulsing and the commit that introduced it? You mentioned earlier about a button fix - when was this committed? I don’t see any change in button behaviour (from my OP) on any build I’ve tried.
NeoPixelBus 2.7.5 is mandatory for UCS890x chipset and as such we can’t go without it.
It did introduce quite a few new features including new brightness bus and deprecated NePixelBrightnessBus which WLED was using.
So the flickering (which I am also seeing) can be attributed to NPB 2.7.5 but there are also many other factors that can contribute. I.e. usermods.
As for buttons, 0.14 introduced asynchronous loading of presets to combat (and avoid) preset corruption during saves. This may have introduced the inability to cycle playlists using button presses. IDK I never used it.
If you are familiar with compiling source, add a few debug printouts in handlePreset() and/or other preset handling functions. Playlist is just another preset but has a completely different workflow so it may be difficult to track down.
Ok, so I’ve done a little digging and debugging. Worked out how to use NetDebug and found what I think is the problem.
Line 174 of presets.cpp
It resets the presetCycCurr variable to the current preset. But the current preset is an actual display preset - not a playlist, so the incrementing has now been broken. eg.
My playlists are number 20-22
In playlist 20, I have preset 1 & 3
Line 174 puts 1 or 3 into presetCycCurr
Later in parseNumber() when it tries to increment… 1 or 3 + 1 is below presetCycMin so it returns that instead - in my case always 20. So it replays the same playlist over and over.
I’ve done a build commenting out line 174 and the behaviour returns to normal. Either clicking the Preset that has the incrementing command OR pressing the button on the device connected to the same preset correctly cycles through the playlists.
I’m not sure what that line is supposed to be doing so didn’t want to submit a patch to remove it. @blazoncek how do you want to proceed here? Should I log a bug and a PR and we can discuss there? Any hints on what that line is otherwise trying to do?
Just open an issue on Github with exact description as above.
You can label it a bug and someone will take a look what else breaks if that line is removed.