Draft
Conversation
- Create usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h with full implementation: FreeRTOS task for Zigbee stack, attribute set callbacks for On/Off + Level Control + Color Control clusters, colorHStoRGB() conversion, and config persistence via addToConfig/readFromConfig - Create usermods/zigbee_rgb_light/README.md with hardware requirements, enable instructions, WiFi/Zigbee coexistence notes, and platformio_override.ini example - Create wled00/usermods_list.cpp to conditionally include/register the usermod under #ifdef USERMOD_ZIGBEE_RGB_LIGHT - Add USERMOD_ID_ZIGBEE_RGB_LIGHT (59) to wled00/const.h Co-authored-by: netmindz <442066+netmindz@users.noreply.github.com> Agent-Logs-Url: https://github.com/wled/WLED/sessions/fb0cc4ff-60ec-4e31-ba9d-19027c40294a
Address code review feedback: protect shared state between the Zigbee FreeRTOS task and the WLED main loop with a FreeRTOS mutex. The attribute callback and applyState() now acquire zbStateMutex before reading/writing powerOn, zbBrightness, zbHue, zbSaturation. Co-authored-by: netmindz <442066+netmindz@users.noreply.github.com> Agent-Logs-Url: https://github.com/wled/WLED/sessions/fb0cc4ff-60ec-4e31-ba9d-19027c40294a
- Remove wled00/usermods_list.cpp (old registration approach) - Add usermods/zigbee_rgb_light/library.json with Zigbee lib deps - Rename .h to .cpp following other usermod conventions - Update README to document custom_usermods instead of build flags Co-authored-by: netmindz <442066+netmindz@users.noreply.github.com> Agent-Logs-Url: https://github.com/wled/WLED/sessions/e8f06557-562a-4982-84fc-298a483eb548
Co-authored-by: netmindz <442066+netmindz@users.noreply.github.com> Agent-Logs-Url: https://github.com/wled/WLED/sessions/e8f06557-562a-4982-84fc-298a483eb548
Use a custom linker section to hold dynamic arrays such as the usermod list. This provides an extensible solution for wider use in the future (such as FX or Bus drivers), as well as IDF v5 compatibility.
Replace the old dynarray.py (which appended tools/dynarray.ld as a separate linker script) with the V5 version that patches sections.ld in-place, injecting .dynarray entries inside the existing .flash.rodata output section. This avoids creating an extra ELF PT_LOAD segment that caused the ESP-IDF v5 bootloader to assert: rom_index < 2. Also update validate_modules.py to the V5 version (nm-based validation), add wled00/dynarray.h (generic DECLARE_DYNARRAY/DYNARRAY_MEMBER macros), and delete the now-obsolete tools/dynarray.ld and tools/esp8266_rodata.ld.
Move esp_coex_wifi_i154_enable() from the ZigbeeRGBLightUsermod constructor to setup(). The constructor runs during static initialization (do_global_ctors), before the IDF coexistence subsystem is ready, causing a null pointer dereference (Load access fault, MTVAL=0x10). Moving it to setup() is safe because UsermodManager::setup() runs before WiFi.mode(WIFI_STA) in wled.cpp. Also add library.json and zigbee_rgb_light.cpp for the custom_usermods + REGISTER_USERMOD() pattern used by the V5 dynarray build system.
Wrap all WLED_MAX_DIGITAL_CHANNELS #define directives in const.h with #ifndef guards so that a -D flag on the compiler command line takes precedence without triggering redefinition warnings. This is needed for the Zigbee build which sets -DWLED_MAX_DIGITAL_CHANNELS=0 to disable RMT-based LED buses (the 802.15.4 radio shares the RMT peripheral).
Add custom_usermods = zigbee_rgb_light so the V5 build system automatically discovers and links the Zigbee usermod via library.json and REGISTER_USERMOD().
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughIntroduces a new Zigbee RGB Light usermod for ESP32-C6 that integrates WLED with the ESP Zigbee stack to expose the device as a Zigbee HA Color Dimmable Light endpoint. Includes build configuration, library dependencies, comprehensive documentation, and supporting core framework updates. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
netmindz
added
enhancement
connectivity
Member
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (5)
wled00/data/index.js (1)
3451-3452: Align version-info persistence across all report-failure paths.Line 3452 now persists
version-info.jsonon exception, but the HTTP non-OK path (Line 3444-Line 3447) still doesn’t. This creates inconsistent re-prompt behavior depending on failure type.♻️ Proposed consistency fix
.then(res => { if (res.ok) { if (alwaysReport) { showToast('Thank you! Future upgrades will be reported automatically.'); } else { showToast('Thank you for reporting!'); } updateVersionInfo(info.ver, false, !!alwaysReport); } else { - showToast('Report failed. Please try again later.', true); - // Do NOT update version info on failure - user will be prompted again + showToast('Report failed', true); + updateVersionInfo(info.ver, false, !!alwaysReport); } }) .catch(e => { console.log('Failed to report upgrade', e); showToast('Report failed', true); updateVersionInfo(info.ver, false, !!alwaysReport); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@wled00/data/index.js` around lines 3451 - 3452, The HTTP non-OK failure branch should persist version-info just like the exception branch; inside the non-200 response handling (the block that currently calls showToast('Report failed', true) for HTTP errors around the response check), call updateVersionInfo(info.ver, false, !!alwaysReport) so that version-info.json is updated consistently across all report-failure paths (use the same arguments as the exception handler).wled00/network.cpp (1)
441-449: Redundant preprocessor guard.The
#if defined(ARDUINO_ARCH_ESP32)at line 441 is unnecessary since this code is already nested inside#ifdef ARDUINO_ARCH_ESP32from line 434.🔧 Proposed fix
case ARDUINO_EVENT_WIFI_AP_START: DEBUG_PRINTLN(F("WiFi-E: AP Started")); - `#if` defined(ARDUINO_ARCH_ESP32) // Flush any ghost associations left over from a previous AP session. // On ESP32-C6 with Zigbee coexistence the AP goes through a stop/start // cycle during WiFi mode initialisation. The IDF station list is NOT // fully cleared by that cycle, so prior partial-association entries can // persist and fill the max_connection table — causing new clients to be // rejected with 802.11 status code 16 (ASSOCIATION_DENIED_NO_MORE_STA). esp_wifi_deauth_sta(0); // 0 = deauth ALL stations (aid=0 means broadcast) - `#endif` break;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@wled00/network.cpp` around lines 441 - 449, Remove the redundant inner preprocessor guard around the deauth call: delete the lines starting with "#if defined(ARDUINO_ARCH_ESP32)" and its matching "#endif" so the existing esp_wifi_deauth_sta(0); call and its comment remain directly inside the outer `#ifdef` ARDUINO_ARCH_ESP32 block; this keeps the deauth behavior intact while eliminating the duplicate conditional.platformio_override.ini (1)
10-13: Minor: Redundant unflag entries.Both
-D CORE_DEBUG_LEVEL=0(with space) and-DCORE_DEBUG_LEVEL=0(without space) are unflagged. While this is defensive (as noted in research.md), it adds clutter. PlatformIO normalizes these internally, so typically only one form is needed.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@platformio_override.ini` around lines 10 - 13, The build_unflags section contains duplicate entries for the same macro: both "-D CORE_DEBUG_LEVEL=0" and "-DCORE_DEBUG_LEVEL=0"; remove one of them to avoid clutter—keep a single canonical form (e.g., "-D CORE_DEBUG_LEVEL=0") in the build_unflags list while leaving the other entries like "-D WLED_RELEASE_NAME=..." unchanged and preserve the build_unflags key.usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h (2)
362-374: Add error logging for mutex/platform config failures.If mutex creation fails (line 363), the function returns silently without logging. Similarly, platform config failure logs to DEBUG but doesn't clean up the mutex. Adding error logs helps debugging initialization issues.
♻️ Proposed improvement
zbStateMutex = xSemaphoreCreateMutex(); - if (!zbStateMutex) return; + if (!zbStateMutex) { + DEBUG_PRINTLN(F("ZigbeeRGBLight: Failed to create mutex")); + return; + } // Configure the Zigbee platform now ... esp_zb_platform_config_t platform_cfg = {}; platform_cfg.radio_config.radio_mode = ZB_RADIO_MODE_NATIVE; platform_cfg.host_config.host_connection_mode = ZB_HOST_CONNECTION_MODE_NONE; if (esp_zb_platform_config(&platform_cfg) != ESP_OK) { DEBUG_PRINTLN(F("ZigbeeRGBLight: esp_zb_platform_config failed")); + vSemaphoreDelete(zbStateMutex); + zbStateMutex = nullptr; return; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h` around lines 362 - 374, If xSemaphoreCreateMutex() fails, log an error (use DEBUG_PRINTLN or equivalent) instead of returning silently; when esp_zb_platform_config(&platform_cfg) fails, log the detailed error and free the previously created mutex (zbStateMutex) before returning to avoid a leak. Specifically update the initialization sequence around zbStateMutex, xSemaphoreCreateMutex(), esp_zb_platform_config_t platform_cfg and esp_zb_platform_config() to emit clear error messages for both failure cases and call vSemaphoreDelete(zbStateMutex) (or the appropriate delete function) when platform configuration fails after the mutex was created.
320-326: Channel 26 restriction limits interoperability.Setting only channel 26
(1 << (26 - 11))ensures zero WiFi spectral overlap, but the device won't join coordinators operating on other Zigbee channels (11-25). Consider making this configurable or using a broader channel mask that avoids the WiFi channels in use.💡 Optional: Make channel configurable
+#ifndef ZIGBEE_CHANNEL + `#define` ZIGBEE_CHANNEL 26 +#endif + // Set the primary channel mask. -esp_zb_set_primary_network_channel_set(1 << (26 - 11)); +esp_zb_set_primary_network_channel_set(1 << (ZIGBEE_CHANNEL - 11));🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h` around lines 320 - 326, The code hard-sets the Zigbee primary channel mask to only channel 26 via esp_zb_set_primary_network_channel_set(1 << (26 - 11)), which prevents joining coordinators on channels 11–25; change this to use a configurable channel mask or a broader default (e.g., mask for channels 11–25 or a mask that excludes specific WiFi-overlapping channels) instead of a single-bit constant. Add a new configurable variable/define (e.g., zigbee_channel_mask or get_zigbee_channel_mask()) and replace the literal call to esp_zb_set_primary_network_channel_set(...) with esp_zb_set_primary_network_channel_set(zigbee_channel_mask) so users can set the mask at build/runtime or use a safer default that preserves interoperability. Ensure the new symbol is documented where defaults are set and validate the mask covers only channels 11–26 as required by the stack.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@platformio_override.ini`:
- Around line 30-32: The hardcoded user path in board_build.flash_extra_images
(the boot_app0.bin entry) breaks portability; replace the literal
"~/.platformio/packages/..." with a PlatformIO package or environment variable
reference (e.g., use PlatformIO's package directory variable such as
${platformio.packages_dir}/framework-arduinoespressif32/tools/partitions/boot_app0.bin
or an env var like ${env.HOME}/.platformio/packages/...), updating the
board_build.flash_extra_images line so it derives the packages path from a
variable instead of a hardcoded user home path.
In `@usermods/zigbee_rgb_light/README.md`:
- Around line 45-58: The README example uses ${esp32.large_partitions_min_fs}
(tools/WLED_ESP32_8MB_256KB_FS.csv) which differs from the actual
platformio_override.ini used by the Zigbee usermod; update the README snippet to
reference the Zigbee-specific partition table (tools/WLED_ESP32_8MB_Zigbee.csv)
so the example matches the implementation and ensures required partitions
(zb_storage and zb_fct) are present for the Zigbee stack; specifically modify
the README's platformio_override.ini example to use the Zigbee partitions and
mention zb_storage and zb_fct as required partitions.
In `@wled00/idf_component.yml`:
- Around line 1-6: Remove the unnecessary espressif/esp_matter dependency from
the dependencies block in idf_component.yml: delete the entire
"espressif/esp_matter" mapping (including its registry_url and version keys) so
only the required "idf" dependency remains; leave the "idf" entry (version
'>=5.1.0') intact to avoid changing other build settings.
In `@wled00/network.cpp`:
- Line 448: After calling esp_wifi_deauth_sta(0) you must reset the software
client counter to match the hardware state; add apClients = 0 immediately after
the esp_wifi_deauth_sta(0) call so subsequent WIFI_AP_STADISCONNECTED handling
that does the decrement (--apClients) cannot underflow and the reconnect check
(if (--apClients == 0 && ...) behaves correctly.
---
Nitpick comments:
In `@platformio_override.ini`:
- Around line 10-13: The build_unflags section contains duplicate entries for
the same macro: both "-D CORE_DEBUG_LEVEL=0" and "-DCORE_DEBUG_LEVEL=0"; remove
one of them to avoid clutter—keep a single canonical form (e.g., "-D
CORE_DEBUG_LEVEL=0") in the build_unflags list while leaving the other entries
like "-D WLED_RELEASE_NAME=..." unchanged and preserve the build_unflags key.
In `@usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h`:
- Around line 362-374: If xSemaphoreCreateMutex() fails, log an error (use
DEBUG_PRINTLN or equivalent) instead of returning silently; when
esp_zb_platform_config(&platform_cfg) fails, log the detailed error and free the
previously created mutex (zbStateMutex) before returning to avoid a leak.
Specifically update the initialization sequence around zbStateMutex,
xSemaphoreCreateMutex(), esp_zb_platform_config_t platform_cfg and
esp_zb_platform_config() to emit clear error messages for both failure cases and
call vSemaphoreDelete(zbStateMutex) (or the appropriate delete function) when
platform configuration fails after the mutex was created.
- Around line 320-326: The code hard-sets the Zigbee primary channel mask to
only channel 26 via esp_zb_set_primary_network_channel_set(1 << (26 - 11)),
which prevents joining coordinators on channels 11–25; change this to use a
configurable channel mask or a broader default (e.g., mask for channels 11–25 or
a mask that excludes specific WiFi-overlapping channels) instead of a single-bit
constant. Add a new configurable variable/define (e.g., zigbee_channel_mask or
get_zigbee_channel_mask()) and replace the literal call to
esp_zb_set_primary_network_channel_set(...) with
esp_zb_set_primary_network_channel_set(zigbee_channel_mask) so users can set the
mask at build/runtime or use a safer default that preserves interoperability.
Ensure the new symbol is documented where defaults are set and validate the mask
covers only channels 11–26 as required by the stack.
In `@wled00/data/index.js`:
- Around line 3451-3452: The HTTP non-OK failure branch should persist
version-info just like the exception branch; inside the non-200 response
handling (the block that currently calls showToast('Report failed', true) for
HTTP errors around the response check), call updateVersionInfo(info.ver, false,
!!alwaysReport) so that version-info.json is updated consistently across all
report-failure paths (use the same arguments as the exception handler).
In `@wled00/network.cpp`:
- Around line 441-449: Remove the redundant inner preprocessor guard around the
deauth call: delete the lines starting with "#if defined(ARDUINO_ARCH_ESP32)"
and its matching "#endif" so the existing esp_wifi_deauth_sta(0); call and its
comment remain directly inside the outer `#ifdef` ARDUINO_ARCH_ESP32 block; this
keeps the deauth behavior intact while eliminating the duplicate conditional.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: b7914af7-f2d1-499c-b7b4-23a2af370c1a
⛔ Files ignored due to path filters (2)
tools/WLED_ESP32_8MB_256KB_FS.csvis excluded by!**/*.csvtools/WLED_ESP32_8MB_Zigbee.csvis excluded by!**/*.csv
📒 Files selected for processing (12)
platformio.iniplatformio_override.iniusermods/zigbee_rgb_light/README.mdusermods/zigbee_rgb_light/library.jsonusermods/zigbee_rgb_light/research.mdusermods/zigbee_rgb_light/usermod_zigbee_rgb_light.husermods/zigbee_rgb_light/zigbee_rgb_light.cppwled00/const.hwled00/data/index.jswled00/idf_component.ymlwled00/network.cppwled00/um_manager.cpp
Comment on lines
+30
to
+32
| board_build.flash_extra_images = | ||
| 0x8000 ${BUILD_DIR}/partitions.bin | ||
| 0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin |
Contributor
There was a problem hiding this comment.
Hardcoded path reduces portability.
The path ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin assumes a specific PlatformIO installation location. This will break on:
- Windows (uses
%USERPROFILE%\.platformioor custom paths) - Custom PlatformIO core directories
- CI/CD environments with non-standard paths
Consider using PlatformIO's package path variables for better portability.
🔧 Suggested fix using environment variables
board_build.flash_extra_images =
0x8000 ${BUILD_DIR}/partitions.bin
- 0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin
+ 0xe000 ${platformio.packages_dir}/framework-arduinoespressif32/tools/partitions/boot_app0.binNote: The exact variable syntax may vary. You may need to verify the correct PlatformIO variable for the packages directory.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| board_build.flash_extra_images = | |
| 0x8000 ${BUILD_DIR}/partitions.bin | |
| 0xe000 ~/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin | |
| board_build.flash_extra_images = | |
| 0x8000 ${BUILD_DIR}/partitions.bin | |
| 0xe000 ${platformio.packages_dir}/framework-arduinoespressif32/tools/partitions/boot_app0.bin |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@platformio_override.ini` around lines 30 - 32, The hardcoded user path in
board_build.flash_extra_images (the boot_app0.bin entry) breaks portability;
replace the literal "~/.platformio/packages/..." with a PlatformIO package or
environment variable reference (e.g., use PlatformIO's package directory
variable such as
${platformio.packages_dir}/framework-arduinoespressif32/tools/partitions/boot_app0.bin
or an env var like ${env.HOME}/.platformio/packages/...), updating the
board_build.flash_extra_images line so it derives the packages path from a
variable instead of a hardcoded user home path.
usermods/zigbee_rgb_light/README.md
Outdated
Comment on lines
+45
to
+58
| ```ini | ||
| ; platformio_override.ini – Zigbee RGB Light on ESP32-C6 | ||
| [env:esp32c6_zigbee] | ||
| extends = env:esp32c6dev_8MB | ||
| platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip | ||
| platform_packages = | ||
| board_build.partitions = ${esp32.large_partitions_min_fs} | ||
| build_unflags = | ||
| -D WLED_RELEASE_NAME=\"ESP32-C6_8MB\" | ||
| build_flags = ${env:esp32c6dev_8MB.build_flags} | ||
| -D WLED_RELEASE_NAME=\"ESP32C6_Zigbee\" | ||
| -DZIGBEE_MODE_ED=1 | ||
| custom_usermods = zigbee_rgb_light | ||
| ``` |
Contributor
There was a problem hiding this comment.
Documentation example differs from actual implementation.
The README example uses ${esp32.large_partitions_min_fs} (which resolves to tools/WLED_ESP32_8MB_256KB_FS.csv), but the actual platformio_override.ini uses tools/WLED_ESP32_8MB_Zigbee.csv.
The Zigbee-specific partition table includes zb_storage and zb_fct partitions required by the Zigbee stack (as documented in research.md). Users following the README example may get build/runtime errors due to missing Zigbee partitions.
📝 Suggested fix
; platformio_override.ini – Zigbee RGB Light on ESP32-C6
[env:esp32c6_zigbee]
extends = env:esp32c6dev_8MB
platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip
platform_packages =
-board_build.partitions = ${esp32.large_partitions_min_fs}
+board_build.partitions = tools/WLED_ESP32_8MB_Zigbee.csv
build_unflags =
-D WLED_RELEASE_NAME=\"ESP32-C6_8MB\"
build_flags = ${env:esp32c6dev_8MB.build_flags}🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 46-46: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@usermods/zigbee_rgb_light/README.md` around lines 45 - 58, The README example
uses ${esp32.large_partitions_min_fs} (tools/WLED_ESP32_8MB_256KB_FS.csv) which
differs from the actual platformio_override.ini used by the Zigbee usermod;
update the README snippet to reference the Zigbee-specific partition table
(tools/WLED_ESP32_8MB_Zigbee.csv) so the example matches the implementation and
ensures required partitions (zb_storage and zb_fct) are present for the Zigbee
stack; specifically modify the README's platformio_override.ini example to use
the Zigbee partitions and mention zb_storage and zb_fct as required partitions.
Comment on lines
+1
to
+6
| dependencies: | ||
| espressif/esp_matter: | ||
| registry_url: https://components.espressif.com | ||
| version: '>=1.3.0' | ||
| idf: | ||
| version: '>=5.1.0' |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does esp-zigbee-lib require esp_matter dependency?
💡 Result:
No, esp-zigbee-lib does not require esp_matter dependency. esp-zigbee-lib is a standalone binary library component for Espressif's Zigbee SDK, built on ESP-IDF and ZBOSS stack (via esp-zboss-lib). Official documentation and component registry pages show no dependency on esp_matter, which is a separate Matter SDK component with its own dependencies like esp_delta_ota and esp_secure_cert_mgr. Zigbee examples use only esp-zigbee-lib and esp-zboss-lib in idf_component.yml files. Matter-Zigbee bridges may use both together, but esp-zigbee-lib itself is independent.
Citations:
- 1: https://components.espressif.com/components/espressif/esp-zigbee-lib
- 2: https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/introduction.html
- 3: https://components.espressif.com/components/espressif/esp-zigbee-lib/versions/1.0.0/dependencies?language=
- 4: https://components.espressif.com/components/espressif/esp-zboss-lib
- 5: https://git.spencerplus.com/Josh/esp32_Simple_Light/src/branch/main/main/idf_component.yml
- 6: https://github.com/espressif/esp-zigbee-sdk
- 7: https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/developing.html
- 8: https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/index.html
Remove the esp_matter dependency from idf_component.yml.
The espressif/esp_matter dependency in this file is unnecessary for Zigbee functionality. According to official Espressif documentation, esp-zigbee-lib is a standalone component that does not require esp_matter. Zigbee and Matter are distinct protocols; while both may coexist in a Matter-Zigbee bridge, esp-zigbee-lib itself has no dependency on esp_matter. This dependency should be removed to avoid unnecessary bloat and potential build complications.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@wled00/idf_component.yml` around lines 1 - 6, Remove the unnecessary
espressif/esp_matter dependency from the dependencies block in
idf_component.yml: delete the entire "espressif/esp_matter" mapping (including
its registry_url and version keys) so only the required "idf" dependency
remains; leave the "idf" entry (version '>=5.1.0') intact to avoid changing
other build settings.
| // fully cleared by that cycle, so prior partial-association entries can | ||
| // persist and fill the max_connection table — causing new clients to be | ||
| // rejected with 802.11 status code 16 (ASSOCIATION_DENIED_NO_MORE_STA). | ||
| esp_wifi_deauth_sta(0); // 0 = deauth ALL stations (aid=0 means broadcast) |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if apClients is used elsewhere in ways that could be affected by underflow
rg -n --type=cpp -C2 '\bapClients\b' wled00/Repository: wled/WLED
Length of output: 1153
🌐 Web query:
Does esp_wifi_deauth_sta trigger WIFI_AP_STADISCONNECTED events in ESP-IDF?
💡 Result:
Yes, calling esp_wifi_deauth_sta triggers WIFI_EVENT_AP_STADISCONNECTED events in ESP-IDF.
Citations:
- 1: https://docs.espressif.com/projects/esp-idf/en/v4.4-rc1/esp32/api-guides/wifi.html
- 2: https://docs.espressif.com/projects/esp-idf/en/v5.2-beta2/esp32/api-guides/wifi.html
🏁 Script executed:
sed -n '440,460p' wled00/network.cppRepository: wled/WLED
Length of output: 1022
🏁 Script executed:
rg -n --type=cpp 'apClients' wled00/ -A1 -B1Repository: wled/WLED
Length of output: 853
Reset apClients = 0 after deauth to ensure state consistency.
Calling esp_wifi_deauth_sta(0) on the AP start event (line 448) clears all station associations at the hardware level and triggers WIFI_AP_STADISCONNECTED events. If the software counter apClients is 0 when these disconnect events fire, decrementing at line 408 causes underflow to 255 (byte type). This breaks the reconnect logic if (--apClients == 0 && ...), preventing the expected WiFi reconnection when all clients are cleared.
Add apClients = 0; immediately after the esp_wifi_deauth_sta(0) call to keep the software state synchronized with the hardware state after the flush.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@wled00/network.cpp` at line 448, After calling esp_wifi_deauth_sta(0) you
must reset the software client counter to match the hardware state; add
apClients = 0 immediately after the esp_wifi_deauth_sta(0) call so subsequent
WIFI_AP_STADISCONNECTED handling that does the decrement (--apClients) cannot
underflow and the reconnect check (if (--apClients == 0 && ...) behaves
correctly.
…reconnect WLED's initConnection() calls WiFi.mode(WIFI_MODE_NULL) during WiFi reconnection, which tears down the WiFi stack and resets the 802.15.4 coexistence arbiter configuration. This caused intermittent WiFi drops when the Zigbee radio was active. Changes: - Re-call esp_coex_wifi_i154_enable() and re-apply IEEE802154_MIDDLE priority in connected() override on every WiFi reconnect - Fix HUE_ECHO_WINDOW_MS constant from 5000 to 1500 to match actual usage in echo suppression logic - Replace hardcoded 1500ms values in zbUpdateState() with the HUE_ECHO_WINDOW_MS constant Test results improved from 22/31 to 28/31 (best run), with sustained HTTP going from complete failure to 10/10 at avg 0.89s response time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Work in progress - awaiting hardware
Others have tested and been able to add the device to HA and control the on of and brightness