JSON API "ps" state object does not execute by automated calls

[UsableLoki8221]

What happened?

The 'ps' state object in the JSON API does not work when automated (by scheduled time or by calling with other presets interacting).

To Reproduce Bug

I created a preset with {"on":true,"ps":"1~169r"} so that my instance will turn on and choose a random preset out of 169. The preset works well when I manually click on the preset to activate it. However, when this preset is scheduled in the 'time-controlled presets' in the time & macros section the "ps":"1~169r" does not execute; the state of the lights stays the same even though they at least turned on.

I attempted to mitigate this and chain another preset to call the main randomizing preset and found the problem carried {"ps":"200"} --> {"on":true,"ps":"1~169r"} --> light on, but no change in active preset.
Same when I tried using the legacy API: PL=211 --> {"on":true,"ps":"1~169r"} --> light on, but no change in active preset
As well as when the "on" API was removed: {"ps":"200"} --> {"ps":"1~169r"} --> no change in active preset.

I can confirm that {"ps":"1~169r"} does work to randomly choose a preset between 1-169 when I actively tap/click this preset.

Expected Behavior

The 'ps' state object should change a preset when used in scheduling or interacting preset functions.

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.15.3 (2508020)

Which microcontroller/board are you seeing the problem on?

ESP32-S3

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[UsableLoki8221]

The tilde symbol seemed to have reformated some of the message at points (~)

[willmmiles]

Preset chaining is not supported from non-interactive contexts. This is intentional to avoid the possibility of some preset chain creating a loop, eg. 100: {"ps": 200}, 200: {"ps": 100}. (Otherwise we'd have to keep an arbitrarily long list of presets that had already been executed in this sequence.)

[UsableLoki8221]

But preset chaining does seem like a good feature to have though, would it not? Disabling this seems restrictive with regard to the nature of WLED. If someone has know-how to utilize the API creatively then creating an unintentional loop with preset chaining should be part of the organic process of programming things. If creating a loop locks up WLED functionality though then perhaps the 'ps' API could have a ~10-second safety lockout before it is executable again?

Thanks for your response and clarification, by the way. I appreciate you took the time to review and answer my ticket!

[DedeHai]

But preset chaining does seem like a good feature to have though

there is playlists for this purpose. regarding "selecting a random preset" can be done the same way: with a playlist.

[UsableLoki8221]

Unfortunately playlists are limited to 100 presets where I'd need 169. Each selected preset only has a max run time of ~1hr,49min which can't sync to where the power-on state initiates a new preset state, and the shuffle/repeat setting makes it so that once a preset has ran it won't occur again until the remaining presets in the playlist have also ran.

[DedeHai]

Sounds like you are in usermod territory or even xlights?

[UsableLoki8221]

No, just native WLED install. But since the 'ps' API is intentionally disabled for non-interactive functions I'm considering rebuilding an install with that enabled if I can find where it is

[UsableLoki8221]

Found it- in "wled00\presets.cpp"

    if (!(tmpMode == CALL_MODE_BUTTON_PRESET && fdo["ps"].is<const char *>() && strchr(fdo["ps"].as<const char *>(),'~') != strrchr(fdo["ps"].as<const char *>(),'~')))
      fdo.remove("ps"); // remove load request for presets to prevent recursive crash (if not called by button and contains preset cycling string "1~5~")

It could be useful for others if this can be retained using a cooldown---

    static unsigned long lastPsExecution = 0;
    unsigned long now = millis();
    if (!(tmpMode == CALL_MODE_BUTTON_PRESET && fdo["ps"].is<const char *>() && strchr(fdo["ps"].as<const char *>(),'~') != strrchr(fdo["ps"].as<const char *>(),'~'))) { //(if not called by button and contains preset cycling string "1~5~")
      if (now - lastPsExecution >= 2000) { //2 second cooldown block to prevent instant looping recursive crash
        lastPsExecution = now;  // allow ps execution
      } else {
        fdo.remove("ps");       // cooldown active, block ps to prevent instant looping if 2 presets get chained together
      }
    }

[UsableLoki8221]

Tested this edit on a custom install of WLED and works safe and well. Feel free to close this out unless there is some interest to incorporate this into the main build.

[BeeFox-sys]

I feel like this should be enabled, or at least given a toggle. if infinite loops are a worry, we could choose to limit the chain length to something high that realistically won't be reached unless its by accident, like 500.

[softhack007]

But preset chaining does seem like a good feature to have though

there is playlists for this purpose. regarding "selecting a random preset" can be done the same way: with a playlist.

I agree with @DedeHai - we do have playlist for exactly this purpose. You can use a "playlist" preset ID in all places that accept a preset ID. A preset that calls another preset is a special case that will always invite trouble, for example in UI, by delaying effect activation (lock timeouts), by producing a flood of state update messages, by indirect recursions (stack smashing) between several presets, or during PS saving "without state change".

If we can avoid, i would prefer to not support presets that call another preset. Not with a one-shot cooldown, not with a recursion limit.

[softhack007]

If I understood the comment in the source code correctly, preset cycling string "1~5~" is already supported. So a preset cycling string 1~1~ would be equivalent to branching to preset 1, right?