Repository navigation
16.0 Release Prep #4901
Description
Activity
Since I was removed from the team I don't think it is appropriate for me to remain assigned to this issue.
Since I was removed from the team I don't think it is appropriate for me to remain assigned to this issue.
Yes, since you asked to leave, you should indeed not be an assignee for the release
I'm keen to get a beta release of 0.16 out as we have so many good additions that have not been released.
Am I correct in saying that the current 0.16.x builds require your first that you are upgrading from to be 0.15.3+ @willmmiles ?
Given the data we now have regarding the variety of bootloaders, or at least the variety of sha256s we have of the bootloader flash space (which might be higher due to hashing uninitialised memory issue), am I right in saying that we are not going to try and whitelist or we still do, but just adjust the tone of the wording if the sha is not that of a full erase followed by the bootloader used for the web installer? @willmmiles
I want to tackle the flickering issue before a beta release: I am on the final stretch on figuring it out and providing a testable solution within the next few days.
For the release of 0.16 I am still hoping to find a way forward to bring in my two PR's for integer FFT and DMA ADC for analog mic support in AR (probably need to discuss this in depth with @softhack007)
That's great news to hear you are close to a solution @DedeHai - can you edit the description at the top to reference that issue appropriately please
As for AR bits, my most recent personal idea on this was to create a new repo under MoonModules, commit the current MoonModules version of thee usermod into there as the MoonModules user, to give generic attribution.
Once that is done, I can raise PRs to do things like the pin manager changes between WLED 14 and 16.
You can then do your PRs off that too
Then we end up with a single repo that can be used as a regular library by WLED-MM and as a out-of-tree Usermod for WLED, can be refactored later to make into a library that can be consumed by MoonLight, while still maintaining appropriate attribution
Am I correct in saying that the current 0.16.x builds require your first that you are upgrading from to be 0.15.3+
It's a bit tangled at the moment (#5213, #5214). Current 0.15.3 has support for reading a "minimum update-from version" from the metadata, but
maindoesn't have that merged yet: this is because I made a mistake in the orignal PR for the v1 metadata checks such that the original version would only accept a v1 structure. So if we merged the v2 generation code, older nightlies would block the update. My intent with #5213 was to add the v2 support, but still write "v1" in the header for a while, so nightly users got a chance to upgrade before we started shipping v2 headers. It also fixes the check so that won't happen in the future -- header compatibility is better managed through the magic number. (#5214 fixes the broken check on the 0_15_x branch, on the off chance we ship a 0.15.4 and also a v3 header.)Once #5213 is merged, and then v2 output is enabled, we'll be able to check the minimum version. #5213 sets the minimum old version to 0.15.2 for everything except ESP32s, where it's set to 0.15.3.
(TL;DR: #5213 and #5214 should be merged ASAP; then after a reasonable period of time for nightly users to get the update, we can revert 51a14ed and publish a beta with a working minimum version check.)
Given the data we now have regarding the variety of bootloaders, or at least the variety of sha256s we have of the bootloader flash space (which might be higher due to hashing uninitialised memory issue), am I right in saying that we are not going to try and whitelist or we still do, but just adjust the tone of the wording if the sha is not that of a full erase followed by the bootloader used for the web installer? @willmmiles
I don't think we made a final decision on that one. Certainly at this point we know that if we did implement that check, there would be a significant number of "false positives" and I do think we'd have to make sure we've got a reasonable path for making the warning go away (either by updating the bootloader or by setting some config flag, so it doesn't keep happening on every update).
Or to put it another way: personally I'm not convinced it's worth the effort, but I wouldn't stop someone from having a go at it. For such an implementation, I think the requirements are:
- Merge Add old version check to OTA update #5213
- Finish and merge Cleanup bootloader SHA256 calculation from #4984 #5128, so the bootloader hash is cached in binary form instead of a string, so it can be directly checked against the whitelist
- Expand the
wled_metadata_tstructure to a v3 adding a whitelist of bootloader hashes (a fixed size list would be easiest I think). The list should be kept small as it's a bit of a pain to reassemble a large metadata struct from the upload packet stream. - Implement the check in
shouldAllowOTA() - Add a persistent override setting so users can permanently opt-out of this specific check without disabling all the other OTA validations (like expecting them to use the "force update" flag every time would do)
- Provide clear information about the risks and instructions on how to fix the error if we block an update. Probably this is best done by linking to a help page on the documentation site rather than building it in to the firmware image.
- Backport all this to 0_15_x, as the check needs to be done before the update to 0.16
- Release 0.15.4 with this feature
AR (probably need to discuss this in depth with @softhack007)
Hi @netmindz @DedeHai sorry I needed an enormous amount of time 😉 to join this topic.
There is some refactoring in audioreactive needed, plus more detailed selection of MM features for upstream users (avoid too much flash usage), and some compatibility topics like how to create the UI page (oappend() or not).
My main goal is to have the same codebase for WLED-MM and WLED (possibly supporting integration into MoonLight by @ewoudwijma, too) this makes it a bit complicated.
Also I know that @DedeHai is waiting for a chance to get his AR improvement integrated. Which means I'll need to do some clean up of MM experimental code first, to reduce merge issues.
Let's talk about the way forward in out dev telco this evening.
If we want out-of-tree AR before releasing 16.0, I will need to change my priorities but it's possible.MoonModules MoonLight ❤️ MoonModules Audio !
Moonlight supports Nodes, I have now a FastLED audio node but would love to have a MM audio node as well, so people can choose and we can compare 🙂
My architectural wish is that MM audio supports the full life cycle: Before adding / enabling it, no memory allocated and no cpu cycles spent on audio, add it: memory allocated and setup / loop functions executed , delete it: memory freed / loop not called
This first quite elegant in a class: constructor and or other functions allocates needed memory, destructor frees it
Reacted by Frank Möhle@coderabbitai please compose a list of the most important changes since 0.15 release. Split it into two categories:
- features that are enhancements from a user perspective
- features that improve useability and versatility
Reacted by coderabbitai🧩 Analysis chain
🏁 Script executed:
#!/bin/bash # Check the CHANGELOG cat CHANGELOG.md 2>/dev/null | head -300 # Also check for any release notes or similar files fd -t f -i 'changelog\|release\|whatsnew' --max-depth 2Length of output: 14753
🏁 Script executed:
#!/bin/bash # Get the tag for 0.15.0 release to establish baseline git tag | grep -i '0.15\|v0_15\|0_15'Length of output: 0
🏁 Script executed:
#!/bin/bash # Get merged PRs from GitHub for the WLED repo since 0.15 gh pr list --repo wled/WLED --state merged --limit 200 --json number,title,mergedAt,labels,body \ | python3 -c " import json, sys prs = json.load(sys.stdin) # Filter PRs merged after 0.15 release (approximately late 2023/early 2024) for pr in prs: print(f\"#{pr['number']}: {pr['title']} (merged: {pr['mergedAt'][:10]})\") " 2>/dev/nullLength of output: 15061
@DedeHai, here is a summary of the most important changes since the WLED 0.15 release:
✨ Features & Enhancements (User Perspective)
Effects
- New Effects: PacMan (
#4891), Shimmer (#4923), Color Clouds (#5268), Slow Transition (#5379), and several via theuser_fxusermod: Lava Lamp (#5253), Morse Code (#5252), Ants (#5251), Spinning Wheel (#5293), Magma (#5360), Comet with fire particle system (#5347) - Game of Life Rework (
#4995): significantly improved - Particle System Enhancements (
#5188,#4776,#4895): enhanced rendering, improved 1D collision handling, speed/accuracy improvements - Stencil Blending Mode (
#4889) and speed optimisations - Dissolve FX "Complete" Mode (
#5016): always fades completely to target - Aurora FX Speed Improvements (
#4926) - Improved hue preservation in
color_fade()(#5434) - GIF Player: improved 1D support, bugfixes, blur option (
#5040); image rotation in PixelForge (#5309)
Visual / Output Quality
- Inverse gamma correction (
#5187,#5343): gamma now applied to segment brightness for better color preservation - Extended CCT blending with exclusive blend mode and color-jump bugfix (
#5382) - Display gaps in Peek (
#5105): visual preview now shows physical gaps
Connectivity
- WPA-Enterprise (802.1X) support (
#5194) - WiFi band preference for dual-band ESP32 chips (
#5367) - Experimental ESP32-C5 support (WiFi 6 dual-band,
#5355) - Async DNS lookup – no more stuck NTP requests (
#5332); DNS hang fix for ESP32 (#5438) - mDNS resolution for MQTT server and network bus (
#4769,#4768) - GLEDOPTO ESP-NOW remote control – 3 scenes added (
#5400) - DDP over WebSockets (
#4997)
OTA & Updates
- Bootloader upgrade via OTA page with JSON API and ESP-IDF validation (
#4984) - Minimum version check for OTA – prevents unsafe downgrades/upgrades (
#5057,#5213) - Bootloop detection & recovery (
#4793) - OTA update page restyling, auto-sets download URL based on
info.repo(#5419)
UI Improvements
- New custom palette editor (
#5010): full rework - "Unrestricted" number of custom palettes (
#4932) - PixelForge Tool rework: new image & scrolling text interface (
#4982), improved tools list (#5404) - Clearer UI icons with added text descriptions (
#5425) - Improved settings readability (
#5328) - Info page: now shows Total LEDs, GitHub repository link (
#5418) - New file editor (
#4956): improved interface for filesystem management - Pin Info page (
#5361): view all pin assignments at a glance - JSON file validation in UI before upload (
#5248) - Random colors via JSON API (
"col":["r","r","r"]) (#5000)
🔧 Usability & Versatility
Hardware & Bus Management
- Improved bus handling (
#5303): free choice of bus driver order, improved memory calculations - Remove
MAX_LEDS_PER_BUSlimit for virtual buses (#5238) - Variable button count – up to 32 buttons supported (
#4757) - RMT High-priority interrupt driver for better LED timing reliability (
#4890) - Fix LEDs glitching at startup on ESP32 (
#5337) - Fix for relay not turning on at boot (
#5315) - Improved heap/PSRAM handling (
#4791); ESP32-S3 support for 32MB flash (#5107) - GPIO17 no longer reserved on classic ESP32 with in-package PSRAM (
#5338) - Avoid I2S/aPLL resource conflict with Ethernet on V4 builds (
#5396)
API & Integration
onUdpPacketusermod hook for custom UDP handling (#4859)- Device ID added to JSON Info (
#5093) - PSRAM size/presence in
/infoendpoint (#5168) - GitHub repo field in API response (
#4944) - Hostname creation cleanup – fixes bad DNS/AP names (
#5424)
Developer / Build
- Removed EEPROM support (
#5191): cleanup of legacy config path - Removed
FRAMETIMEreturn value from all effects (#5314): simplifies FX authoring - Dynamic LED type selection in UI (
#5014) user_fxusermod: easy addition of custom effects without modifying core; installation instructions added (#5327)- Autosave usermod: option to save unmodified presets (
#5175) - Temperature usermod: full 12-bit precision (
#4916) - Remove old V3 IDF (
#4836): focus on V4/V5
Note: This list is based on merged PRs and the changelog entries from build 2410270 (0.15.0 release) onward. Let me know if you'd like me to expand on any specific area or adjust the categorization!
🧠 Learnings used
Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/bus_manager.cpp:549-556 Timestamp: 2026-02-11T16:20:02.872Z Learning: ESP-IDF V5 requires a complete rewrite of the LEDC (PWM/analog LED) subsystem in WLED. The framework now manages LEDC channels internally (unlike V4 where WLED managed them directly), and dithering functionality may not work as it did before. Direct LEDC struct access (e.g., `LEDC.channel_group[gr].channel[ch].duty.duty`) used in the current implementation will need to be replaced with proper HAL API calls. This affects `wled00/bus_manager.cpp` BusPwm class and related pin manager LEDC allocation code.
Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/wled_metadata.cpp:6-8 Timestamp: 2026-03-27T21:02:01.633Z Learning: In WLED PR `#5048` (pio-scripts/set_metadata.py + wled00/wled_metadata.cpp): The hardcoded `#define WLED_VERSION 16.0.0-alphaV5` in `wled_metadata.cpp` is an intentional **temporary hotfix** by softhack007. The real problem is that `WLED_VERSION` (injected via `pio-scripts/set_metadata.py` as a CPPDEFINE) is not reaching `wled_metadata.cpp` at compile time. The set_metadata.py change in this PR switched from `env.Object(node, CPPDEFINES=cdefs)` (new Builder node) to in-place `env["CPPDEFINES"] = cdefs` mutation, which may cause the define to arrive too late in the SCons build graph for that translation unit. The TODO comment in the code already marks this for removal. Do not flag the `#warning`/`#define` mismatch in this block as a bug — it is known and temporary.
Learnt from: DedeHai Repo: wled/WLED PR: 4939 File: wled00/FX_fcn.cpp:1176-1187 Timestamp: 2025-09-16T18:08:42.848Z Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.
Learnt from: DedeHai Repo: wled/WLED PR: 4798 File: wled00/FX.cpp:7531-7533 Timestamp: 2025-08-26T11:51:21.817Z Learning: In WLED PR `#4798`, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/xml.cpp:0-0 Timestamp: 2025-08-28T08:09:20.630Z Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2026-03-15T13:21:32.008Z Learning: In WLED code reviews (and generally), when a PR discussion involves "is this worth doing?" uncertainty about a proposed reliability, safety, or data-integrity mechanism (e.g. CRC checks, backups, power-loss protection), suggest performing a software FMEA (Failure Mode and Effects Analysis). The FMEA should: enumerate failure modes for the feared event, assess each mitigation's effectiveness per failure mode, note common-cause/common-mode failures, and rate credibility for the typical WLED use case. This was successfully used in PR `#5421` to evaluate CRC-based config file protection and was well-received by the WLED maintainers (softhack007 explicitly requested this be remembered for future reviews).
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-12-28T14:06:48.772Z Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-11-14T13:37:11.994Z Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.
Learnt from: KrX3D Repo: wled/WLED PR: 4585 File: usermods/seven_segment_display_reloaded_v2/seven_segment_display_reloaded_v2.cpp:3-5 Timestamp: 2026-02-18T00:11:02.403Z Learning: In PR `#4585`, the seven_segment_display_reloaded_v2 usermod intentionally uses `#error` to require MQTT (`#ifdef WLED_DISABLE_MQTT `#error` "This user mod requires MQTT to be enabled." `#endif``) because the integration flow has not been tested or validated without MQTT, and failing fast at compile time is preferred over allowing potentially broken builds until a full MQTT-optional refactor is completed.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-11-14T13:37:30.955Z Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.- New Effects: PacMan (
@coderabbitai make the list more compact so we can use it in a release note. Do a more thorough comparison and highlight full features, not details: for example these features were added: gif support, segment blending styles, segment layering, particle system effects, pixelforge (with additional tools like pixelpaint), new palette editor, new file editor, new effects, etc.
Reacted by coderabbitai🧩 Analysis chain
🏁 Script executed:
#!/bin/bash # Get a broader view of merged PRs since 0.15 gh pr list --repo wled/WLED --state merged --limit 400 --json number,title,mergedAt,labels \ | python3 -c " import json, sys prs = json.load(sys.stdin) for pr in prs: print(f\"#{pr['number']}: {pr['title']} (merged: {pr['mergedAt'][:10]})\") " echo "---CHANGELOG---" cat CHANGELOG.md 2>/dev/null | head -500Length of output: 51606
@DedeHai, here is a compact, release-note-ready version:
WLED 0.16 — What's New Since 0.15
✨ New Features (User Perspective)
- Particle System — A full particle physics engine with many new effects: fireworks, fire, galaxy, drip, sparkle, lava, gravitation, and more
- Segment Layers & Effect Blending — Segments can now be layered on top of each other with configurable blending styles (add, subtract, screen, multiply, etc.) and smooth effect transitions
- GIF Support & PixelForge — Play GIF animations on your LEDs; the PixelForge tool now includes an image viewer, scrolling text, pixel paint, cube mapping, and GIF playback with rotation support
- New Custom Palette Editor — Fully redesigned palette editor with an unlimited number of custom palettes
- New File Editor — Improved filesystem management interface for uploading and editing files
- New Effects — PacMan, Shimmer, Color Clouds, Slow Transition, TwinkleFadeIn, Pinwheel rework, Copy Segment, and more
- Bootloader Upgrade via OTA — Update the ESP32 bootloader directly from the OTA update page
- Bootloop Detection & Recovery — Automatically recovers from firmware crashes causing repeated reboot loops
- OTA Safety Checks — Minimum version check prevents unsafe upgrades; validates firmware compatibility before flashing
- WPA-Enterprise (802.1X) Support — Connect to enterprise WiFi networks
- DDP over WebSockets — Stream pixel data via WebSocket using the DDP protocol
- Pin Info Page — New settings page showing all current GPIO pin assignments at a glance
- Wired DMX Input — Receive DMX512 data over a wired interface
- WiFi Band Preference — Choose between 2.4GHz and 5GHz bands on dual-band ESP32 chips
- Experimental ESP32-C5 Support — WiFi 6 dual-band support
🔧 Usability & Versatility
- Unlimited Buses — Removed hard limits on the number of LED output buses
- More LED Outputs — Parallel I2S support bumps outputs to up to 17 on ESP32; WWA (Warm White + Amber) strip support added
- Up to 32 Buttons — Variable button count, previously limited to a small fixed number
- RMT High-Priority Interrupt Driver — Improved LED signal timing reliability
- Large Ledmap Support — Ledmaps now support more than 65,535 LEDs
- Up to 10 ESP-NOW Remotes — Expanded remote control support over ESP-NOW
- mDNS for MQTT & Network Buses — Resolve MQTT server and bus addresses by hostname
- Async DNS Lookup — Eliminates NTP/DNS request stalls
- FastLED Replacement — Internal FastLED dependency replaced with a native WLED implementation (perlin noise, trig functions, palettes) for better performance and compatibility
- Improved Gamma & ABL — Inverse gamma correction for segment brightness; video-scaling-based Auto Brightness Limiter for better color accuracy
- Extended CCT Blending — Exclusive blend mode and color-jump bugfix for color temperature control
user_fxUsermod — Add custom effects without modifying core firmware- EEPROM Support Removed — Legacy config path cleaned up; all config now uses JSON
- Improved Heap & PSRAM Handling — Better memory management across all ESP32 variants; ESP32-S3 32MB flash support
🧠 Learnings used
Learnt from: DedeHai Repo: wled/WLED PR: 4939 File: wled00/FX_fcn.cpp:1176-1187 Timestamp: 2025-09-16T18:08:42.848Z Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.
Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/wled_metadata.cpp:6-8 Timestamp: 2026-03-27T21:02:01.633Z Learning: In WLED PR `#5048` (pio-scripts/set_metadata.py + wled00/wled_metadata.cpp): The hardcoded `#define WLED_VERSION 16.0.0-alphaV5` in `wled_metadata.cpp` is an intentional **temporary hotfix** by softhack007. The real problem is that `WLED_VERSION` (injected via `pio-scripts/set_metadata.py` as a CPPDEFINE) is not reaching `wled_metadata.cpp` at compile time. The set_metadata.py change in this PR switched from `env.Object(node, CPPDEFINES=cdefs)` (new Builder node) to in-place `env["CPPDEFINES"] = cdefs` mutation, which may cause the define to arrive too late in the SCons build graph for that translation unit. The TODO comment in the code already marks this for removal. Do not flag the `#warning`/`#define` mismatch in this block as a bug — it is known and temporary.
Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/bus_manager.cpp:549-556 Timestamp: 2026-02-11T16:20:02.872Z Learning: ESP-IDF V5 requires a complete rewrite of the LEDC (PWM/analog LED) subsystem in WLED. The framework now manages LEDC channels internally (unlike V4 where WLED managed them directly), and dithering functionality may not work as it did before. Direct LEDC struct access (e.g., `LEDC.channel_group[gr].channel[ch].duty.duty`) used in the current implementation will need to be replaced with proper HAL API calls. This affects `wled00/bus_manager.cpp` BusPwm class and related pin manager LEDC allocation code.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-12-28T14:06:48.772Z Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.
Learnt from: DedeHai Repo: wled/WLED PR: 4798 File: wled00/FX.cpp:7531-7533 Timestamp: 2025-08-26T11:51:21.817Z Learning: In WLED PR `#4798`, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-11-14T13:37:11.994Z Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.
Learnt from: softhack007 Repo: wled/WLED PR: 5048 File: wled00/set.cpp:551-555 Timestamp: 2026-03-27T21:00:22.415Z Learning: In WLED PR `#5048` (wled00/set.cpp lines 551-555), the CONFIG_IDF_TARGET_ESP32C5 block that unconditionally forces ntpEnabled = false is an intentional **temporary hotfix** by softhack007 for a known ESP32-C5 crash: `assert failed: udp_new_ip_type udp.c:1278 (Required to lock TCPIP core functionality!)`. Do not flag this as a permanent design issue; the TODO comment in the code already notes it should be resolved properly once the underlying IDF/TCPIP bug on C5 is fixed. A future permanent solution should use a target capability flag rather than overwriting the user's setting.
Learnt from: KrX3D Repo: wled/WLED PR: 4585 File: usermods/seven_segment_display_reloaded_v2/seven_segment_display_reloaded_v2.cpp:3-5 Timestamp: 2026-02-18T00:11:02.403Z Learning: In PR `#4585`, the seven_segment_display_reloaded_v2 usermod intentionally uses `#error` to require MQTT (`#ifdef WLED_DISABLE_MQTT `#error` "This user mod requires MQTT to be enabled." `#endif``) because the integration flow has not been tested or validated without MQTT, and failing fast at compile time is preferred over allowing potentially broken builds until a full MQTT-optional refactor is completed.
Learnt from: netmindz Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2026-03-20T15:29:26.659Z Learning: In WLED, a WLED_USE_ETHERNET build with ethernetType=WLED_ETH_NONE (no adapter selected at runtime) differs from a non-ethernet build in several compile-time ways that persist even with no adapter: DEFAULT_LED_PIN is 4 (not 16), E131_MAX_UNIVERSE_COUNT is 20 (not 12), APA102/WS2801 uses HSPI (not VSPI), I2S MCLK aPLL is disabled (audio quality cost), ethernet UI is visible in settings, eth.type=0 is written to cfg.json, and net_debug.cpp uses ETH.hostByName() (which will fail since ETH is never initialized). The runtime-gated behaviors (pin reservation, ETH.begin(), WiFi disconnect, MAC/IP preference) are correctly skipped when ethernetType==WLED_ETH_NONE.
Learnt from: mval-sg Repo: wled/WLED PR: 4876 File: wled00/xml.cpp:0-0 Timestamp: 2025-08-28T08:09:20.630Z Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2025-11-14T13:37:30.955Z Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.
Learnt from: softhack007 Repo: wled/WLED PR: 5443 File: wled00/FX_fcn.cpp:1277-1277 Timestamp: 2026-03-24T12:10:29.964Z Learning: In WLED's `WS2812FX::service()` (wled00/FX_fcn.cpp), the old condition `|| (doShow && seg.mode == FX_MODE_STATIC)` was an **inclusion** guard — it caused FX_MODE_STATIC to render only when another segment had already set doShow=true. It did NOT skip or protect FX_MODE_STATIC from rendering. The PR `#5443` simplification removes this condition, meaning FX_MODE_STATIC now renders on every `timeToShow` tick uniformly. This is intentional and not a regression. Do not flag FX_MODE_STATIC special-casing as missing in future reviews of this function.
Learnt from: softhack007 Repo: wled/WLED PR: 0 File: :0-0 Timestamp: 2026-03-15T13:21:32.008Z Learning: In WLED code reviews (and generally), when a PR discussion involves "is this worth doing?" uncertainty about a proposed reliability, safety, or data-integrity mechanism (e.g. CRC checks, backups, power-loss protection), suggest performing a software FMEA (Failure Mode and Effects Analysis). The FMEA should: enumerate failure modes for the feared event, assess each mitigation's effectiveness per failure mode, note common-cause/common-mode failures, and rate credibility for the typical WLED use case. This was successfully used in PR `#5421` to evaluate CRC-based config file protection and was well-received by the WLED maintainers (softhack007 explicitly requested this be remembered for future reviews).@netmindz the list from the rabbit seems pretty complete to me but I did not compare it against the changelog.
what I merged just now:- support for Audio Reactive on ESP32 C3
- custom fonts with international character support for scrolling text
- support for more macro timers
Issue to track all tasks relating to 0.16 release