Improve Boot preset handling

[smitty078]

TODO:
•New commit coming soon to address conversation thus far.
•Update documentation throughout project
•Testing

Problem

Previously, boot preset application depended on the normal loop path. handlePresets() in the main loop is gated behind realtime mode checks:

if (!realtimeMode || realtimeOverride || (realtimeMode && useMainSegmentOnly))

If realtime mode became active before the first normal preset processing pass, the boot preset could be skipped or only partially applied. This was especially problematic for boot presets intended to set LiveDataOverride (lor).

---

Solution

This PR adds handlePresets() and handlePlaylist() calls during setup().

The startup-time calls are intentionally placed:

• after UsermodManager::setup()
• after any required config migration save (serializeConfigToFS())
• before normal network and realtime activity begins

This placement avoids calling usermod JSON handlers before setup while ensuring boot presets are processed deterministically during startup.

---

Behavior Changes

Earlier and More Consistent “LEDs On” Timing

For users utilizing a boot preset with on:true, LEDs may now turn on earlier during boot.

Because the boot preset is now applied earlier in the startup sequence, lights may illuminate faster than before. During testing, this range varied greatly with a range of 100ms faster to almost 2s faster.

This is particularly beneficial for users powering controllers from a physical wall switch who expect lights to turn on immediately when power is applied.

Users who intentionally relied on the previous delayed or inconsistent timing — particularly setups sensitive to brownouts or power fluctuations — may need to adjust any related delays accordingly.

While the previous behavior could vary depending on timing and realtime state, the new behavior should provide more consistent startup timing across reboots and power-on events on the controller.

Improvements to Boot Preset Capabilities

• The boot preset or playlist can now reliably set lor during startup.
• A boot playlist can set lor:1 or lor:2 at the top level of the playlist, or in the first playlist entry.
• A boot preset that sets lor:1 or lor:2 can set a single chained preset using the ps JSON API.

Example:

{ "lor": 2, "ps": 250 }

This is useful for a boot preset to establish realtime override behavior first and then immediately advance to another preset.

[coderabbitai]

Walkthrough

The PR refines preset initialization logic by exempting CALL_MODE_INIT from preset state change notifications in handlePresets(), and adds boot-time preset handling in WLED::setup() that calls handlePresets() twice to support one-time numeric preset chaining during device startup.

Changes

Preset Initialization and Boot Handling

Layer / File(s)	Summary
Preset State Change Detection wled00/presets.cpp	handlePresets() condition is updated to add CALL_MODE_INIT exception alongside existing CALL_MODE_BUTTON_PRESET handling for cycling marker (~) logic, preventing preset state changes from being marked during initialization.
Boot Preset Initialization wled00/wled.cpp	WLED::setup() adds conditional block that calls handlePresets() twice with yield() between when bootPreset > 0, enabling one-time preset chaining for numeric boot presets.
Code Formatting wled00/presets.cpp	Trivial whitespace change at end of deletePreset().

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Improve Boot preset handling' accurately reflects the main change—enhancing how boot presets are applied during WLED startup to ensure deterministic processing.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[smitty078]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@wled00/presets.cpp`:
- Around line 197-200: The guard currently lets any fdo["ps"] value through for
CALL_MODE_INIT (so string cycling specs like "1~5~" reach deserializeState);
restrict the CALL_MODE_INIT exception to numeric preset values by adding a type
check (e.g. fdo["ps"].is<int>() or appropriate numeric type) to the existing
condition (mirror the pattern used for CALL_MODE_BUTTON_PRESET which checks
fdo["ps"].is<const char *>()), so only numeric "ps" values are preserved for
deserializeState() and non-numeric strings are removed with fdo.remove("ps") to
avoid unintended playlist/cycling behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8125ad27-4651-45d0-adf2-70d57c1158bb

📥 Commits

Reviewing files that changed from the base of the PR and between c050973 and 88994e9.

📒 Files selected for processing (2)

• wled00/presets.cpp
• wled00/wled.cpp

[DedeHai]

would a playlist not be able to do the same?
I do not see a significant speed increase, maybe 100ms.

[smitty078]

would a playlist not be able to do the same? I do not see a significant speed increase, maybe 100ms.

Thanks for the feedback! Hence why I’m still in draft mode - I’m not ready to say this is review or merge ready just yet.

1. In my initial test I thought the same thing but was unable to get a playlist to do the same thing. There may very well be a similar improvement needed for a boot playlist - I have not yet investigated that codepath but will.

2. I wonder if the speed increase I see is specific to my hardware and/or environment. My controller is at the edge of WiFi range, so maybe that impacts startup time for WiFi fairly significantly for me. I’ll update my statement on performance before submitting for review.

[willmmiles]

Re performance changes: I do expect that the latency of how long it takes the main loop to get around to applying the boot preset will be highly dependent on environment and wifi setup. In fact, one down side of the proposed new approach is that it may lead to more devices showing visible stutters and hiccups during the connection sequence, as the light "starts up" earlier. There's undoubtedly room for improvement there -- I suspect some of the execution order details in the current code are workarounds for issues with older platforms that may not still apply. I don't think we should spend too much time worrying about this (either way) at the moment.

Re ps vs playlists: there's a very real sense in which the functionality of "ps" and "playlist" overlap: "ps" could (almost) be implemented as a single-entry "playlist" with 0 delay. In this context, both approaches require extra work at setup() time -- but realistically we probably should handle both, if only so that we don't have to document a bunch of special cases.

In practice I think this works out to something like:

if (bootPreset > 0) {
   handlePreset();   // execute boot preset
   handlePlaylist();  // if boot preset set a playlist, process it
   handlePreset();   // if either of the above set a preset for deferred execution, execute it now
}

[willmmiles]

How could this be true during setup()?

[willmmiles]

Why do we need to yield() from setup()? That seems quite strange to me -- we haven't even turned the network on yet at this point.

[willmmiles]

This will never execute because the boot preset hasn't been parsed yet, and thus no playlist can be in flight.

[DedeHai]

Re performance changes: I do expect that the latency of how long it takes the main loop to get around to applying the boot preset will be highly dependent on environment and wifi setup. In fact, one down side of the proposed new approach is that it may lead to more devices showing visible stutters and hiccups during the connection sequence, as the light "starts up" earlier. There's undoubtedly room for improvement there -- I suspect some of the execution order details in the current code are workarounds for issues with older platforms that may not still apply. I don't think we should spend too much time worrying about this (either way) at the moment.

Re ps vs playlists: there's a very real sense in which the functionality of "ps" and "playlist" overlap: "ps" could (almost) be implemented as a single-entry "playlist" with 0 delay. In this context, both approaches require extra work at setup() time -- but realistically we probably should handle both, if only so that we don't have to document a bunch of special cases.

In practice I think this works out to something like:

if (bootPreset > 0) {
   handlePreset();   // execute boot preset
   handlePlaylist();  // if boot preset set a playlist, process it
   handlePreset();   // if either of the above set a preset for deferred execution, execute it now
}

With the reports about brownouts which may be related to faster LED turnon time (I measured roughly 1.2s vs 2.5s in 0.15) making it more consistent would be a welcome improvement, albeit this may cause some transitional friction with existing setups that have insufficient power stability