improve bootup behaviour for boot presets#5686
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
Walkthrough
ChangesBoot-up LED color initialization
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@coderabbitai please check for any edge cases that may have a changed behaviour and come up with a test plan to verify this PR works as intended. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
# Get the PR diff
gh pr diff 5686 --repo wled/WLED
echo "===== wled.cpp segment ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "bootPreset\|turnOnAtBoot\|briS\|colPri\|transitionDelay\|beginStrip\|BLACK\|DEFAULT_COLOR\|bootTime\|CALL_MODE_INIT" -A2 -B2
echo "===== FX.h segment ====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "DEFAULT_COLOR\|bootTime\|bootupDelay\|colors\[0\]\|BLACK\|WLED_BOOTUPDELAY" -A5 -B2
echo "===== wled.h colPri ====="
gh api repos/wled/WLED/contents/wled00/wled.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "colPri\|colSec" -A2 -B2Length of output: 11599 🏁 Script executed: #!/bin/bash
# Get full beginStrip function from PR branch
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "beginStrip\|void WLED::begin" -A 80 | head -120
echo "=====FX.h Segment constructor====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "Segment()\|Segment ::\|bootTime\|bootupDelay\|colors\[0\]" -A 10 -B 5 | head -80Length of output: 9859
Edge Case AnalysisEC-1:
|
| # | turnOnAtBoot |
bootPreset |
rlyPin |
transitionDelayDefault |
Notes |
|---|---|---|---|---|---|
| T-1 | false | 0 | none | 700ms (default) | Baseline: all off at boot |
| T-2 | true | 0 | none | 700ms | LEDs on at briS, fade from black |
| T-3 | true | 0 | none | 0 | Instant on, no fade |
| T-4 | false | N (valid preset) | none | 700ms | Preset applied, LEDs may be off |
| T-5 | true | N (valid preset) | none | 700ms | LEDs on + preset fades in from black |
| T-6 | true | N (valid preset) | none | 0 | Instant preset, no fade |
| T-7 | true | 0 | configured | 700ms | Relay controls on/off, then fade |
| T-8 | false | N | configured | 700ms | Relay stays off, preset applied silently |
| T-9 | true | N (playlist preset) | none | 700ms | Playlist boot preset |
| T-10 | true | 0 | none | 700ms | briS = 0 (first install fallback) |
Test Cases
T-1: All Off at Boot
- Set
turnOnAtBoot = false,bootPreset = 0. - Power cycle.
- Expected: All LEDs remain off. No flicker on first frame.
- Check:
bri = 0, no relay command issued, strip dark.
T-2: Turn-On Fade from Black
- Set
turnOnAtBoot = true,bootPreset = 0, default orange color saved,transitionDelayDefault = 700ms. - Power cycle.
- Expected: LEDs fade from black to
briSbrightness in orange over ~700ms. - Check: No flash of orange before fade starts; brightness reaches
briSexactly.
T-3: Instant Turn-On (No Fade)
- Set
turnOnAtBoot = true,bootPreset = 0,transitionDelayDefault = 0. - Power cycle.
- Expected: LEDs turn on instantly at
briS, no fade transition. - Check: No visible ramp-up from zero.
T-4: Boot Preset Only (LEDs Stay Off?)
- Set
turnOnAtBoot = false,bootPreset = N(preset with explicit brightness embedded). - Power cycle.
- Expected (verify): Does the preset turn on the LEDs if it has a
brifield? Or do LEDs stay off becausebri = 0? - Check:
brivalue after boot; compare with and without brightness saved in the preset.
T-5: Turn-On + Boot Preset Fade
- Set
turnOnAtBoot = true,bootPreset = N,transitionDelayDefault = 700ms. - Power cycle.
- Expected: LEDs start black, fade to the preset's colors at
briSbrightness over 700ms. - Check: No orange flash before fade; all segment channels (col0, col1, col2) fade correctly;
briSis respected vs. preset brightness.
T-6: Turn-On + Boot Preset Instant (No Fade)
- Set
turnOnAtBoot = true,bootPreset = N,transitionDelayDefault = 0. - Power cycle.
- Expected: Preset applied immediately at
briSwith no fade. - Check: Same as T-5 but instantaneous.
T-7: Relay + Turn-On + Boot Preset
- Configure relay pin, set
turnOnAtBoot = true,bootPreset = N. - Power cycle.
- Expected: Relay fires, LEDs turn on after relay delay, preset fades in.
- Check:
strip.show()is NOT called before relay activates; no premature LED output.
T-8: Power Toggle After Boot (briLast regression)
- Any configuration.
- Power cycle, wait for boot to complete.
- Toggle LEDs off via button or API.
- Toggle LEDs back on.
- Expected: LEDs restore to the expected brightness (
briSor preset brightness). - Check: Confirm
briLastholds the correct value—not0—after boot.
T-9: Boot Playlist Preset
- Set
bootPreset = Nwhere N is a playlist preset. - Power cycle.
- Expected: Playlist starts, advances entries correctly, no duplicate first-entry playback.
- Check: Playlist timing is correct; first entry isn't played twice.
T-10: First-Install (briS = 0)
- Factory reset (or manually set
briS = 0in config). - Set
turnOnAtBoot = true. - Power cycle.
- Expected: LEDs turn on at brightness 128 (fallback).
- Check: Not dark; confirms
bri = briS ? briS : 128fallback works.
T-11: New Segment Within 5-Second Boot Window
- Power cycle, immediately (< 5 seconds) go to the segment editor and add a new segment.
- Expected: New segment starts black instead of orange.
- Check (UX regression): Does the user see unexpected black? Is this behavior acceptable? After 5 seconds, verify new segments correctly start in orange.
T-12: Multi-Segment Boot Preset
- Configure a preset that defines 3+ segments with different colors.
- Set
bootPreset = N,turnOnAtBoot = true. - Power cycle.
- Expected: All active segments fade from black to their respective preset colors. Inactive segments remain black/off.
- Check:
colors[1]andcolors[2]also transition correctly (not justcolors[0]).
T-13: Non-Fade Transition Mode
- Set the transition mode to a non-fade type (e.g., Wipe),
bootPreset = N,turnOnAtBoot = true. - Power cycle.
- Expected: Per PR description, LEDs start at default brightness immediately without fading from black.
- Check: No black-to-color animation; LEDs snap to preset state.
T-14: WLED_BOOTUPDELAY Defined
- Compile with
WLED_BOOTUPDELAY = 10000(10s). - Power cycle; wait 8 seconds, add a segment.
- Expected: Segment still starts black (within 15s window).
- Wait 16 seconds, add another segment.
- Expected: Segment starts in orange (outside window).
The most critical cases to verify first are EC-3 (transition not restored for boot preset path, affecting whether fade-in actually occurs), EC-4 (briLast not set, affecting power toggle), and EC-2 (whether bri stays 0 when turnOnAtBoot = false + bootPreset > 0 renders the preset invisible until handlePresets() in setup()).
|
I tested all the suggested cases and made some improvements. this is how it works now, copy from source code comment for reference:
|
There was a problem hiding this comment.
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/wled.cpp`:
- Line 624: Fix the typo in the comment on line 624 where "booup" is misspelled.
Change "booup" to "bootup" in the comment that starts with "if a booup preset is
set" to correctly read "if a bootup preset is set".
🪄 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: 3ae61826-11cf-47e0-bd66-338208522b86
📒 Files selected for processing (1)
wled00/wled.cpp
|
@coderabbitai full review, take the test plan above into account and check if there is inconsistencies for edge cases. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
echo "===== Full wled.cpp beginStrip function ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "" | grep -A 120 "beginStrip"
echo ""
echo "===== Full Segment constructor in FX.h ====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "" | grep -A 40 "Segment()"
echo ""
echo "===== wled.h colPri / colSec / briLast / briS ====="
gh api repos/wled/WLED/contents/wled00/wled.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "colPri\|colSec\|briLast\|briS\b" -A 1 -B 1
echo ""
echo "===== setup() in wled.cpp - handlePresets call context ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "" | grep -A 60 "void WLED::setup"Length of output: 21332 🏁 Script executed: #!/bin/bash
echo "===== Segment constructor full body (FX.h around lines 564-640) ====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | sed -n '564,640p'
echo ""
echo "===== beginStrip full (wled.cpp lines 606-646) ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | sed -n '606,650p'
echo ""
echo "===== Check for colors[0] BLACK forcing after applyPreset in wled.cpp ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "colors\[0\]\|BLACK\|applyPreset\|bootPreset\|WLED_BOOTUPDELAY\|bootupTime\|bootTime" -A 2 -B 2
echo ""
echo "===== Check transitionDelayDefault restoration and bootPreset coloring in wled.cpp ====="
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "transitionDelay\|CALL_MODE_INIT\|colorUpdated" -A 2 -B 2
echo ""
echo "===== Check FX.h for bootupTime / WLED_BOOTUPDELAY in constructor ====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "bootupTime\|WLED_BOOTUPDELAY\|millis\|colors\[0\].*BLACK\|colors\[0\] = BLACK" -A 3 -B 3Length of output: 12574
Full Review — Boot Behavior Refactor (
|
| Test | Verdict | Notes |
|---|---|---|
| T-1 (off at boot, no preset) | ✅ | bri=0, strip shown via strip.show() (no-relay path), orange color pre-loaded for when user turns on |
| T-2 (turn-on fade, no preset) | ✅ | bri=briS, transition restored via strip.setTransition(transitionDelayDefault), segment starts black (constructor), fades to orange |
| T-3 (instant turn-on, no preset, trans=0) | ✅ | Transition is 0, colorUpdated applies immediately |
| T-8 (power toggle / briLast) | ✅ | briLast=briS set in the else branch (line 631); briLast defaults to 128 in wled.h otherwise |
T-10 (first install, briS=0) |
✅ | bri = briS where briS is 128 by default — the guard bri = briS ? briS : 128 from old code is no longer needed since UI prevents 0; initialize is fine |
| EC-8 (copy constructor) | ✅ | Boot-time black only in default constructor; copy/move constructors unaffected |
| EC-9 (colors[1]/[2]) | ✅ | Constructor initializes to {DEFAULT_COLOR, BLACK, BLACK} so secondary/tertiary are already black |
⚠️ Issues Found
🔴 Issue 1 — PR Description Says "5 seconds", Code Uses 2 Seconds
FX.h, line 599:
uint32_t bootupTime = 2000; // 2s should be more than enough to init bootup-segments to blackThe PR objectives state: "Segments created within the first 5 seconds after bootup default to black" — but the code uses 2000ms. The comment also says "2s". One of them is wrong. If real hardware with WLED_BOOTUPDELAY=0 takes more than 2 seconds to reach beginStrip() in edge cases (slow flash, heavy usermod setup), segments created during setup() before beginStrip() completes would fall outside the 2s window and not get the black override.
Recommendation: Decide on the correct value (2s or 5s), update both the code and the PR description/comments to match.
🔴 Issue 2 — Boot Preset Fade Depends on Preset's Own Stored Transition Value (EC-3)
In beginStrip():
strip.setTransition(0); // line 609 — zeroed for all paths
if (bootPreset > 0) {
applyPreset(bootPreset, CALL_MODE_INIT); // may or may not restore transition
}
else {
// ...
strip.setTransition(transitionDelayDefault); // only restored here
}
colorUpdated(CALL_MODE_INIT); // runs with transition=0 if preset didn't set onestrip.setTransition(transitionDelayDefault) is only restored in the else branch. For the bootPreset > 0 path, whether a fade-from-black occurs depends entirely on whether applyPreset() sets a transition value from the preset's stored JSON. If the preset was saved without an explicit transition field, the transition stays 0 and the boot preset appears instantly even when the user expects a fade.
The PR description says "if 'fade' transition is used, then it will still fade from black" — but users who rely on transitionDelayDefault (set globally in LED settings) would not get the fade unless their preset was captured with transition data.
Recommendation: Either restore
transitionDelayDefaultbeforecolorUpdatedalso in the boot preset branch, or document clearly that the boot preset fade requires the preset to have been saved with an explicit transition value.
🟡 Issue 3 — Boot Preset Applied Twice (EC-2, EC-12)
beginStrip() calls applyPreset(bootPreset, CALL_MODE_INIT) at line 634.
Then setup() (lines 506–510) calls handlePresets() which applies the same boot preset again:
if (bootPreset > 0) {
handlePresets(); // re-applies boot preset
handlePlaylist();
handlePresets(); // applies again for anything queued
}For regular presets this is likely benign (idempotent color/effect state). For playlists (T-9), the playlist is started in beginStrip via applyPreset, then handlePlaylist() advances it, and handlePresets() may start it again. Whether this causes the first entry to play twice depends on playlist timer state. The PR author confirmed T-9 was tested, but it's worth verifying with a playlist preset that has a very short first-entry duration (e.g., 500ms) where double-firing would be noticeable.
Recommendation: Consider skipping the
applyPresetcall inbeginStripand relying solely on thehandlePresets()call insetup(), or add a guard that avoids re-applying if the preset was already applied duringbeginStrip.
🟡 Issue 4 — briLast Not Synced to Preset Brightness After Boot (EC-4 refinement)
When turnOnAtBoot = true and bootPreset > 0:
bri = briS(line 629)applyPreset()may setbrito the preset's stored brightness (e.g., 200)briLastis never updated in this path
Result: After boot, bri = 200 (from preset) but briLast remains whatever was in config (e.g., 128). When the user toggles off and back on, brightness jumps back to 128, not 200. This is surprising if the boot preset was intentionally configured to run at a specific brightness.
Recommendation: After
applyPreset, ifbri > 0, setbriLast = brito ensure power-toggle restores to the preset's brightness.
🟢 Issue 5 — Typo in Source Comment
wled.cpp, line 624:
// if a booup preset is set, ...
Should be bootup.
Test Case Matrix Summary
| Case | EC | Verdict |
|---|---|---|
T-4 (off + boot preset, preset has on:true) |
EC-2 | ✅ Works via applyPreset setting bri |
| T-5 (on + boot preset, fade) | EC-3 | |
| T-6 (on + boot preset, no fade) | EC-3 | ✅ Instant (transition=0) |
| T-7 (relay + boot preset) | EC-6 | ✅ strip.show() skipped when rlyPin ≥ 0 |
| T-9 (playlist boot preset) | EC-12 | |
| T-11 (new segment < 2s window) | EC-7 | ✅ Black (constructor), but "5s" in PR description is incorrect — actual is 2s |
| T-12 (multi-segment preset) | EC-9 | ✅ colors[1]/[2] initialized to BLACK by constructor |
| T-13 (non-fade transition mode) | EC-11 | ✅ Per design: no fade from black for non-fade transitions |
| T-14 (WLED_BOOTUPDELAY compile) | EC-7 | ✅ bootupTime += WLED_BOOTUPDELAY handles this correctly |
The most important items to address before merge are Issue 1 (2s vs 5s discrepancy) and Issue 2 (silent dependency on preset-stored transition for the boot fade). Issues 3 and 4 are lower priority but worth noting.
[full_review]
✏️ Learnings added
Learnt from: DedeHai
URL: https://github.com/wled/WLED/pull/5686
Timestamp: 2026-06-20T07:56:49.662Z
Learning: In WLED PR `#5686` (boot behavior refactor), the `Segment` default constructor in `wled00/FX.h` forces `colors[0] = BLACK` when `millis() < 2000 + WLED_BOOTUPDELAY`. This is the mechanism for the boot-time fade-from-black. The value 2000ms was used in code though the PR description stated 5 seconds — actual is 2 seconds.
Learnt from: DedeHai
URL: https://github.com/wled/WLED/pull/5686
Timestamp: 2026-06-20T07:56:49.662Z
Learning: In WLED PR `#5686` (boot behavior refactor), `strip.setTransition(transitionDelayDefault)` is only restored in the `else` (no boot preset) branch of `beginStrip()` in `wled00/wled.cpp`. For the `bootPreset > 0` path, the transition stays 0 unless `applyPreset()` sets it from the preset's stored JSON data. The fade-from-black for boot presets depends on whether the preset was saved with an explicit transition value.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
|
note: the rabbit is wrong about most things except the default transition time. |
|
TODO: remove the 2s boot timeout and move the orange color to set.cpp |
|
@coderabbitai if I change the segment constructor to use all black i.e. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
echo "===== makeAutoSegments in FX_fcn.cpp ====="
gh api repos/wled/WLED/contents/wled00/FX_fcn.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "makeAutoSegments\|setSegment\|addSegment\|Segment(" -A 5 -B 2 | head -80
echo ""
echo "===== Segment creation in json.cpp ====="
gh api repos/wled/WLED/contents/wled00/json.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "setSegment\|addSegment\|Segment(\|DEFAULT_COLOR\|colors\[0\]" -A 5 -B 2 | head -100
echo ""
echo "===== setSegment / addSegment signatures in FX.h ====="
gh api repos/wled/WLED/contents/wled00/FX.h?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "setSegment\|addSegment" -A 3 -B 1 | head -60
echo ""
echo "===== Where makeAutoSegments is called ====="
gh api repos/wled/WLED/contents/wled00/FX_fcn.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "makeAutoSegments" -A 2 -B 2
gh api repos/wled/WLED/contents/wled00/wled.cpp?ref=refs/pull/5686/head --jq '.content' | base64 -d | grep -n "makeAutoSegments" -A 2 -B 2Length of output: 11351
Path 1: Segment created from the UI via the JSON API (
|
| Call site | Segments should be |
|---|---|
beginStrip() (boot) |
BLACK — preset/boot logic takes over |
set.cpp after finalizeInit() |
Orange — user reconfigured LEDs |
The simplest fix is to set the color in set.cpp after the makeAutoSegments() call, so the boot path is unaffected:
// set.cpp, after strip.makeAutoSegments() (line ~222)
if (aligned) {
strip.makeAutoSegments();
// newly auto-created segments should show default color in the UI
for (size_t s = 0; s < strip.getSegmentsNum(); s++) {
Segment& seg = strip.getSegment(s);
if (seg.isActive() && seg.colors[0] == BLACK)
seg.colors[0] = DEFAULT_COLOR;
}
} else {
strip.fixInvalidSegments();
}The colors[0] == BLACK guard avoids overwriting segments that already have a user-set color (e.g., if only one bus was added and existing segments are untouched).
Summary
With these two changes, the constructor can safely become {BLACK, BLACK, BLACK} and the entire millis() boot-window hack can be removed. The orange color is now set explicitly only where it makes semantic sense: in the UI API layer (json.cpp) and in the user-triggered LED reconfiguration path (set.cpp), not in the constructor.
✏️ Learnings added
Learnt from: DedeHai
URL: https://github.com/wled/WLED/pull/5686
Timestamp: 2026-06-21T06:31:20.156Z
Learning: In WLED (wled00/json.cpp), `deserializeSegment()` has a `presetId` parameter (default 0) and a local `newSeg` bool that is set to `true` when `appendSegment()` is called. The combination `newSeg == true && presetId == 0` reliably identifies a segment newly created from the UI/API (not from a preset). This is the correct injection point for setting `colors[0] = DEFAULT_COLOR` on UI-created segments.
Learnt from: DedeHai
URL: https://github.com/wled/WLED/pull/5686
Timestamp: 2026-06-21T06:31:20.156Z
Learning: In WLED (wled00/FX_fcn.cpp), `makeAutoSegments()` is called from two places: `beginStrip()` during boot (segments should remain BLACK) and `set.cpp` after `finalizeInit()` when the user reconfigures LEDs (segments should start orange/DEFAULT_COLOR). The orange color assignment for auto-segments should be done in `set.cpp` after the `makeAutoSegments()` call, not inside `makeAutoSegments()` itself, to avoid affecting boot-time segment initialization.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
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/FX_fcn.cpp`:
- Around line 1994-1996: The loop at line 1994 uses the variable s as the upper
bound, but when s equals 0, a fallback segment can still be created at line
1990, meaning the actual segment count is now greater than s. This causes the
loop to skip execution entirely, leaving the fallback segment's colors[0]
uninitialized to the default orange color. Replace the loop condition that uses
s with the actual segment count after the fallback creation logic (use the
current size of the _segments array) to ensure all segments including the
fallback are initialized with the default color.
🪄 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: b7783d8c-211f-4664-be91-b7a6fa92159b
📒 Files selected for processing (5)
wled00/FX.hwled00/FX_fcn.cppwled00/data/settings_leds.htmwled00/json.cppwled00/wled.cpp
✅ Files skipped from review due to trivial changes (1)
- wled00/data/settings_leds.htm
|
good to merge from my side. @willmmiles you mentioned breaking changes but I can't really think of anything bad... |
3 participants
changes made:
full refactor of the bootup behaviour regarding "bootup preset" and "turn on at boot" here is how it works now:
Segments created by a bootup presets no longer use the DEFAULT_COLOR but start out black: segments created within the first 5s after bootup default to black
DEFAULT_COLOR used for new segments is now the same as the bootup color (AA which is 170 changed to A0 which is 160)
TLDR;
no matter if "turn on at boot" is now set or not, boot up presets are applied correctly. If "turn on at boot" is set, LEDs always turn on.
Summary by CodeRabbit