Using `np` in preset doesn't work when triggered by button

[eosti]

What happened?

The API command {"np": true} works when activated from the UI, but not when activated from a button.

To Reproduce Bug

Create a playlist with a few entries, all with manual (i.e. t=0) timing. Create another preset that runs {"np":true} to advance to the next preset in the playlist.

Activate the playlist. Looking at the JSON state, I see {"ps": 7,"pl":10} where 7 and 10 correspond to the active preset and playlist, respectively.

Expected Behavior

If I use the UI to activate the "next preset" preset, the next preset in the playlist fires as expected. If I assign the preset to a button, and press the button, the active preset does not change, and instead the playlist gets unloaded ({"ps":7,"pl":-1}). I expected both methods of running the "next preset" preset to act the same.

Install Method

Self-Compiled

What version of WLED?

WLED 17.0.0-dev (2605011)

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

Potentially introduced by #3827.

Code of Conduct

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

[willmmiles]

I ran in to this one myself a couple weeks back with a button-based project - it's definitely counterintuitive.

The root issue is that the concept of "preset" is overloaded: in one context, people use it as a "predefined state" -- right up to wanting WLED to report a "currently active preset". In another context, a "preset" is a block of saved API commands and could (in theory) call for anything -- such a playlist operation, or a partial state change that depends on the previous state.

There's a little bit of deeper research needed here to get to the ideal API. Probably we want to move the decision to unload the current playlist in to deserializeState() and consider which keys should trigger it instead of making it a general part of the preset execution process.