WLED (ESP32) not discovered by Alexa / Hue apps despite valid SSDP and Hue emulation

[oloboy]

What happened?

Environment

Device running WLED: ESP32 (Processor: ESP32-D0WDQ5)
WLED version: WLED 0.15.4 (2508020
Network: Single WiFi 2.4Ghz dedicate to IoT (no VLAN, no mesh, no guest network)
Router: ASUS RT-AX92U FW 3.0.0.4.388_23807
Alexa device: Echo Dot gen 3 and 4
Phone: Google Pixel 10

Problem

WLED instance is reachable via IP and correctly exposes UPnP/SSDP and description.xml, but:
-Not discovered by Alexa (device discovery fails)
-Not discovered by Philips Hue app

What works
WLED UI accessible via browser (http://192.168.50.200)
Device visible in UPnP scanners on my phone
description.xml is accessible and appears valid
Device is on same subnet and wifi network as Alexa and phone

To Reproduce Bug

What does NOT work
Alexa “discover devices” → no device found
Philips Hue app → no bridge found
Direct API test: http://192.168.50.200/api/config → returns {} (empty)

Network troubleshooting already done
Multicast / SSDP
UPnP scanner detects WLED correctly → SSDP working
IGMP Snooping → disabled
Multicast rate → forced to 1 Mbps

Router (ASUS)
No mesh / no repeater
No guest network
Devices on same WiFi
Airtime fairness disabled
Beamforming disabled
Roaming assistant disabled
Bluetooth coexistence enabled
TX bursting disabled
IGMP Snooping disabled
Multicast rate fixed to 1 Mbps
Firewall / NAT acceleration tested OFF

WLED Sync / Alexa config

Relevant configuration:

UDP sync enabled (default ports)
Alexa emulation: enabled
Invocation name: LucePianta
MQTT disabled
Hue sync disabled (bridge IP configured but inactive)

Expected Behavior

Add wled to alexa and control it by voice

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.15.4 (2508020)

Which microcontroller/board are you seeing the problem on?

Other

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[softhack007]

@coderabbitai please analyze the problem, also consider a similar description in #4875.

WLED emulates a HUE device that is found by alexa. Please review the relevant source code in wled00/alexa.cpp and wled00/src/dependances/espalexa/ . Compare the WLED protocol emulation against relevant official specs.

Suggest possible root causes.

[coderabbitai]

🧩 Analysis chain

Let me start by fetching both issues and the relevant source code simultaneously.

---

🏁 Script executed:

#!/bin/bash
echo "=== alexa.cpp ==="
cat wled00/alexa.cpp 2>/dev/null || echo "NOT FOUND"

echo ""
echo "=== espalexa directory structure ==="
find wled00/src/dependencies/espalexa wled00/src/dependances/espalexa -type f 2>/dev/null | sort

echo ""
echo "=== Espalexa.h ==="
find . -name "Espalexa.h" | head -3 | xargs cat 2>/dev/null

echo ""
echo "=== EspalexaDevice.h ==="
find . -name "EspalexaDevice.h" | head -3 | xargs cat 2>/dev/null

Length of output: 28152

---

🏁 Script executed:

#!/bin/bash
# Fetch issue `#5488`
gh issue view 5488 --repo wled/WLED --json title,body,comments | jq -r '.title, .body, (.comments[] | .body)'

Length of output: 2417

---

🏁 Script executed:

#!/bin/bash
# Fetch issue `#4875`
gh issue view 4875 --repo wled/WLED --json title,body,comments | jq -r '.title, .body, (.comments[] | .body)'

Length of output: 4367

---

Now let me search for relevant spec details and known issues with Hue bridge emulation.

@softhack007, here is a detailed analysis of the Espalexa/WLED Hue emulation implementation compared against the relevant protocol specifications and known working implementations:

---

Analysis: WLED Hue Bridge Emulation — Discovery & Protocol Issues

Issue Summary (from #5488 and #4875)

Both issues describe the same symptom: WLED's Alexa discovery either fails entirely or only works after simultaneous power-cycling of the ESP and Echo device. SSDP is responding and description.xml is reachable, which means the problem is in the protocol-level details of the SSDP response or the HTTP API behavior.

---

Root Cause Candidates

🔴 1. SSDP Response: Wrong ST Header Case (basic:1 vs Basic:1)

In Espalexa.h → respondToSearch():

"ST: urn:schemas-upnp-org:device:basic:1\r\n"   // WRONG

The correct value per Philips Hue Bridge behavior is urn:schemas-upnp-org:device:Basic:1 (capital B). Home Assistant's emulated Hue had exactly this bug, and a fix was submitted to use Basic:1 (capitalized) instead of basic:1 in the ST header, described as restoring "standard-compliant behavior for UPnP discovery that Alexa expects."

Note that the M-SEARCH filter (strstr(request, "asic:1")) correctly matches either case since it looks for the common substring. But the response ST header must match the capitalization expected by Alexa.

The description.xml correctly uses <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType> (capital B), so there is an inconsistency between the SSDP reply and the XML.

Fix:

// In respondToSearch():
"ST: urn:schemas-upnp-org:device:Basic:1\r\n"   // capital B

---

🔴 2. SSDP Response: Incorrect USN Format for device:Basic:1

In Espalexa.h → respondToSearch():

"USN: uuid:2f402f80-da50-11e1-9b23-%s::upnp:rootdevice\r\n"

For a device:Basic:1 search type, Alexa expects the USN header to follow the format uuid:device-uuid::urn:schemas-upnp-org:device:Basic:1. The previous implementation sending only uuid:device-uuid (or ::upnp:rootdevice) led to discovery failures on newer Alexa firmware versions.

The USN for the Basic device response must include the full ::urn:schemas-upnp-org:device:Basic:1 suffix to match official Philips Hue Bridge behavior.

Fix:

"USN: uuid:2f402f80-da50-11e1-9b23-%s::urn:schemas-upnp-org:device:Basic:1\r\n"

---

🟡 3. SSDP Response: hue-bridgeid Header Format Is Wrong

In Espalexa.h → respondToSearch():

"hue-bridgeid: %s\r\n"  // escapedMac = 12-char lowercase hex, e.g. "aabbccddeeff"

A real Philips Hue bridge sends hue-bridgeid in uppercase EUI-64 format (16 chars), by inserting FFFE between bytes 3 and 4 of the MAC and uppercasing everything. For example, MAC AA:BB:CC:DD:EE:FF becomes AABBCCFFFEDDEEFF.

The current implementation sends only 12 lowercase hex chars. Alexa might use this field to validate that it is communicating with a genuine Hue bridge — a malformed value could silently cause rejection.

Fix in begin():

// After escapedMac is computed, compute EUI-64 bridgeid:
// Insert "fffe" after byte 3, uppercase everything
String bridgeId = escapedMac.substring(0,6).toUpperCase() + "FFFE" + escapedMac.substring(6).toUpperCase();

Then use bridgeId in the SSDP response header.

---

🟡 4. SSDP CACHE-CONTROL: max-age Is Too Short

In Espalexa.h → respondToSearch():

"CACHE-CONTROL: max-age=100\r\n"  // 100 seconds

A real Hue bridge uses max-age=86400 (24 hours). With a 100-second TTL, Alexa's discovery cache expires rapidly. If WLED doesn't respond to a re-query in time (e.g., busy with WS2812 DMA, WiFi reconnect, etc.), the bridge entry is dropped. This aligns with the reported symptom in #4875 where discovery only works during a narrow window after power-on.

Fix: Use a much longer TTL, e.g. max-age=86400.

---

🟡 5. Non-Standard Light Key Encoding

In Espalexa.h → encodeLightKey() / decodeLightKey():

return (mac24 << 7) | idx;   // produces large integers, e.g. 12345345

The JSON response for /api/{username}/lights uses these large integers as keys instead of the standard sequential integers (1, 2, 3...). A real Hue API returns:

{ "1": { ... }, "2": { ... } }

While Alexa's skill is likely tolerant of arbitrary integer keys (since it round-trips them), this design is fragile. If Alexa parses and re-sends the key and there is any truncation or sign mismatch with a 32-bit integer, lights will silently fail to respond to state changes (decodeLightKey() would return 255 = "invalid").

Also noteworthy: the comment //return idx +1; suggests the original intent was sequential IDs, and the encoding was changed but may have introduced incompatibilities.

---

🟡 6. IP Address Stability (Operational Issue)

It is recommended to assign a static IP address to the device running the Hue emulator. This is because Alexa discovers devices by IP address, and if the IP changes, the Echo won't be able to control it. This was directly cited as a cause in issue #5488 comments ("Since my WLED received a new IP address from my router, I cannot anymore update/discover it in Alexa"). This is a configuration guidance issue, not a code bug, but WLED could log a warning when DHCP is in use.

---

Summary Table

#	Severity	Location	Issue	Fix Needed
1	🔴 High	respondToSearch()	ST header: basic:1 → Basic:1	Yes
2	🔴 High	respondToSearch()	USN must end in ::urn:schemas-upnp-org:device:Basic:1	Yes
3	🟡 Med	respondToSearch() + begin()	hue-bridgeid must be uppercase 16-char EUI-64	Yes
4	🟡 Med	respondToSearch()	CACHE-CONTROL: max-age=100 too short (use 86400)	Yes
5	🟡 Med	encodeLightKey()	Non-sequential, non-standard light IDs	Consider reverting to sequential
6	ℹ️ Info	Operational	IP change breaks Alexa pairing	User guidance / static IP

Issues #1 and #2 are the most likely direct causes of initial discovery failures (SSDP level). Issue #4 most likely explains why discovery works only in a brief window after power-cycling (as reported in both issues). Issue #3 may explain Hue app rejecting the bridge.

---

🧠 Learnings used

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/set.cpp:551-555
Timestamp: 2026-03-27T21:00:25.902Z
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: 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: 5457
File: usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h:0-0
Timestamp: 2026-03-31T17:31:01.023Z
Learning: In WLED PR `#5457` (zigbee_rgb_light usermod): The WLED_MAX_DIGITAL_CHANNELS=0 build flag used in the esp32c6_zigbee environment is a temporary workaround for rmt_tx_wait_all_done() timeout spam when the Zigbee/802.15.4 stack is active. The root cause is under investigation and is likely related to Zigbee light-sleep (CONFIG_PM_ENABLE) disrupting RMT's internal time base, or ISR latency due to cache-disable during flash ops — NOT the 802.15.4 radio "sharing" the RMT peripheral (they are separate hardware). Because a proper fix (rmt_enable()/rmt_disable() PM-lock wrapping, allow_pd=0, CONFIG_RMT_TX_ISR_CACHE_SAFE) may eliminate the need to disable digital channels entirely, do NOT add a compile-time `#error` guard requiring WLED_MAX_DIGITAL_CHANNELS=0; doing so would prematurely bake in a constraint that may be lifted once the investigation concludes.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-28T00:51:30.926Z
Learning: In WLED PR `#5048`, the NTP-related crash on ESP32-C5 (pioarduino IDF 5.5.x with CONFIG_LWIP_CHECK_THREAD_SAFETY=y) is definitively NOT caused by ntpUdp.begin(). The crash dump shows the real call chain: WLED::loop() → handleTime() → handleNetworkTime() (ntp.cpp:212) → AsyncDNS::query() (asyncDNS.h:45) → dns_gethostbyname_addrtype() → dns_alloc_pcb() → dns_alloc_random_port() → udp_new_ip_type() ← ASSERT. The fix must be in AsyncDNS::query() (asyncDNS.h:45): the call to dns_gethostbyname_addrtype() must be dispatched to the TCPIP thread via tcpip_callback_with_block() on IDF V5+. The ntpUdp.begin() call sites (wled.cpp:926 and set.cpp:562) are NOT the crash location for this particular bug.

---

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: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-27T21:17:51.985Z
Learning: In WLED PR `#5048` (wled00/cfg.cpp), the NTP crash on ESP32-C5 (pioarduino + IDF 5.5.x) is caused by both CONFIG_LWIP_TCPIP_CORE_LOCKING=y AND CONFIG_LWIP_CHECK_THREAD_SAFETY=y being enabled by default in the pioarduino/arduino-esp32 IDF 5.x sdkconfig. The tasmota core (IDF 5.3.x, used for C6) likely has CONFIG_LWIP_CHECK_THREAD_SAFETY=n, which is why the same violation does not crash on C6. Since pioarduino already has TCPIP_CORE_LOCKING enabled, wrapping ntpUdp.begin() (and any other raw lwIP API call) with LOCK_TCPIP_CORE()/UNLOCK_TCPIP_CORE() from lwip/tcpip.h is directly applicable without sdkconfig changes in platformio.ini.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-27T21:17:51.985Z
Learning: In WLED PR `#5048`, the NTP/UDP crash on ESP32-C5 (pioarduino IDF 5.5.x): CONFIG_LWIP_TCPIP_CORE_LOCKING defaults to n (disabled) in arduino-esp32/pioarduino, while CONFIG_LWIP_CHECK_THREAD_SAFETY=y is what actually causes the "Required to lock TCPIP core functionality!" assertion. LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE() macros are only functional when CONFIG_LWIP_TCPIP_CORE_LOCKING=y; using them without enabling that config has no effect. The correct fix without sdkconfig changes is to use tcpip_callback() to schedule ntpUdp.begin() (and other raw lwIP API calls) on the TCPIP thread, which works regardless of the locking mode setting. The tasmota core (IDF 5.3.x, used for C6) likely has CONFIG_LWIP_CHECK_THREAD_SAFETY=n, which is why the same violation does not crash on C6.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5442
File: wled00/bus_manager.cpp:462-468
Timestamp: 2026-03-23T23:33:45.480Z
Learning: In WLED's TYPE_ANALOG_2CH_HBRIDGE (wled00/bus_manager.cpp), the dead zone at the CCT midpoint (level=127 and level=128 both producing _data[0]=0, _data[1]=0) is intentional by design. The map() blending is directional: WW channel (_data[0]) is brightest at level=0 and fades to 0 at level=127; CW channel (_data[1]) starts at 0 at level=128 and is brightest at level=255. The zero-output at the midpoint is the H-bridge polarity transition boundary, ensuring no overlap between the two polarity directions. Do not flag this dead zone as a bug in future reviews.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5457
File: platformio_override.ini:23-23
Timestamp: 2026-03-31T17:05:49.401Z
Learning: In WLED PR `#5457` (platformio_override.ini, esp32c6_zigbee): The comment "Zigbee 802.15.4 radio on C6 shares the RMT peripheral" is factually incorrect per official Espressif documentation. The ESP32-C6 802.15.4 radio does NOT use or share the RMT peripheral. What IS shared (documented in ESP32-C6 datasheet and ESP-IDF RF coexistence guide) is the single 2.4 GHz RF path (antenna/transceiver), shared among WiFi, BLE, and 802.15.4 via time-division multiplexing — this applies equally to WiFi, not just Zigbee. The rmt_tx_wait_all_done() timeout spam is most likely caused by Zigbee light-sleep enabling aggressive power management (CONFIG_PM_ENABLE) that disrupts RMT's internal time base, or ISR latency due to cache-disable during flash ops. Mitigations: wrap TX with rmt_enable()/rmt_disable() for PM lock, set allow_pd=0, or enable CONFIG_RMT_TX_ISR_CACHE_SAFE. For reliable WiFi+Zigbee gateway operation, Espressif officially recommends a dual-SoC solution (e.g., ESP32-S3 + ESP32-H2). ESP32-C5 has the same single-RF coexistence limitation as C6.

---

Learnt from: willmmiles
Repo: wled/WLED PR: 4859
File: usermods/udp_name_sync/udp_name_sync.cpp:62-70
Timestamp: 2025-08-21T00:00:17.196Z
Learning: In WLED codebase, UDP packet processing code must never rely on null termination being present on the wire and must always validate packet size first. The codebase already has some vulnerabilities where malformed data can crash the software, so avoiding introduction of new ones is a priority.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/pin_manager.cpp:415-428
Timestamp: 2026-03-27T21:04:27.074Z
Learning: In WLED (wled00/pin_manager.cpp isAnalogPin), the ADC2/WiFi hard block applies ONLY to classic ESP32. ESP32-S2 has a hardware arbiter (WiFi > RTC > Digital priority) that allows ADC2 usage with WiFi active. ESP32-S3 and newer chips with IDF V5 use `adc_oneshot_read()` which provides driver-level protection between the WiFi driver and ADC2 — so ADC2 can safely be returned as a valid analog pin on S3+ targets. The only ADC2 exception on S3 is continuous/DMA mode (hardware errata ADC-183), but WLED uses analogRead() (oneshot mode) so this does not apply. Do NOT flag ESP32-S3/S2 ADC2 acceptance in `isAnalogPin()` as a WiFi conflict.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-02-19T10:36:46.939Z
Learning: When "Calculate CCT from RGB" mode (_cct < 0) is combined with "Accurate white" mode (RGBW_MODE_AUTO_ACCURATE), there is a bug in WLED's bus_manager.cpp where approximateKelvinFromRGB() receives RGB values that have already been modified (r -= w, g -= w, b -= w) by autoWhiteCalc(), causing incorrect Kelvin temperature estimation. The original color is not preserved, and calculateCCT() is called after autoWhiteCalc() modifies the RGB values. This affects BusDigital::setPixelColor() execution order (lines 245, 275).

---

Learnt from: willmmiles
Repo: wled/WLED PR: 5462
File: wled00/json.cpp:1189-1198
Timestamp: 2026-03-30T15:32:08.847Z
Learning: In WLED's `respondModeData()` (wled00/json.cpp), the 256-character `lineBuffer` limit for effect descriptor strings (getModeData) is an intentional constraint that matches the same 256-char limit used ~6 other places in the codebase. It is not new to this PR and should not be flagged as a regression. Lifting it requires a future refactor (better type system or dynamic buffer).

[softhack007]

@coderabbitai do you have a reference for this HA problem report?

The correct value per Philips Hue Bridge behavior is urn:schemas-upnp-org:device:Basic:1 (capital B). Home Assistant's emulated Hue had exactly this bug, and a fix was submitted to use Basic:1 (capitalized) instead of basic:1 in the ST header, described as restoring "standard-compliant behavior for UPnP discovery that Alexa expects."

[coderabbitai]

@softhack007, yes — the reference is home-assistant/core PR #166156 ("Fix Emulated Hue Alexa Discovery and SSDP Compatibility" by Monarch73).

A few relevant details from that PR:

• It updates homeassistant/components/emulated_hue/upnp.py to use Basic:1 (capitalized) instead of basic:1 in the ST (Search Target) and USN headers.
• For certain service types, Alexa expects the USN header to follow the format uuid:device-uuid::urn:schemas-upnp-org:device:Basic:1; the previous implementation only sent uuid:device-uuid, which led to discovery failures on newer Alexa firmware versions.
• The PR description states it "restores standard-compliant behavior for UPnP discovery that Alexa expects."

Important caveat: As of the search results, this PR is still open and pending CLA from the contributor, so it has not been merged into HA yet. That means it is a community-submitted fix describing the same bug, not a confirmed upstream merge. The underlying issue (wrong capitalization in ST + incomplete USN) is consistent with what the HA code actually contains today, and the PR author reports verified Alexa discovery success after the change.

---

🧠 Learnings used

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/set.cpp:551-555
Timestamp: 2026-03-27T21:00:25.902Z
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: softhack007
Repo: wled/WLED PR: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-28T00:51:30.926Z
Learning: In WLED PR `#5048`, the NTP-related crash on ESP32-C5 (pioarduino IDF 5.5.x with CONFIG_LWIP_CHECK_THREAD_SAFETY=y) is definitively NOT caused by ntpUdp.begin(). The crash dump shows the real call chain: WLED::loop() → handleTime() → handleNetworkTime() (ntp.cpp:212) → AsyncDNS::query() (asyncDNS.h:45) → dns_gethostbyname_addrtype() → dns_alloc_pcb() → dns_alloc_random_port() → udp_new_ip_type() ← ASSERT. The fix must be in AsyncDNS::query() (asyncDNS.h:45): the call to dns_gethostbyname_addrtype() must be dispatched to the TCPIP thread via tcpip_callback_with_block() on IDF V5+. The ntpUdp.begin() call sites (wled.cpp:926 and set.cpp:562) are NOT the crash location for this particular bug.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5457
File: usermods/zigbee_rgb_light/usermod_zigbee_rgb_light.h:0-0
Timestamp: 2026-03-31T17:31:01.023Z
Learning: In WLED PR `#5457` (zigbee_rgb_light usermod): The WLED_MAX_DIGITAL_CHANNELS=0 build flag used in the esp32c6_zigbee environment is a temporary workaround for rmt_tx_wait_all_done() timeout spam when the Zigbee/802.15.4 stack is active. The root cause is under investigation and is likely related to Zigbee light-sleep (CONFIG_PM_ENABLE) disrupting RMT's internal time base, or ISR latency due to cache-disable during flash ops — NOT the 802.15.4 radio "sharing" the RMT peripheral (they are separate hardware). Because a proper fix (rmt_enable()/rmt_disable() PM-lock wrapping, allow_pd=0, CONFIG_RMT_TX_ISR_CACHE_SAFE) may eliminate the need to disable digital channels entirely, do NOT add a compile-time `#error` guard requiring WLED_MAX_DIGITAL_CHANNELS=0; doing so would prematurely bake in a constraint that may be lifted once the investigation concludes.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-27T21:17:51.985Z
Learning: In WLED PR `#5048`, the NTP/UDP crash on ESP32-C5 (pioarduino IDF 5.5.x): CONFIG_LWIP_TCPIP_CORE_LOCKING defaults to n (disabled) in arduino-esp32/pioarduino, while CONFIG_LWIP_CHECK_THREAD_SAFETY=y is what actually causes the "Required to lock TCPIP core functionality!" assertion. LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE() macros are only functional when CONFIG_LWIP_TCPIP_CORE_LOCKING=y; using them without enabling that config has no effect. The correct fix without sdkconfig changes is to use tcpip_callback() to schedule ntpUdp.begin() (and other raw lwIP API calls) on the TCPIP thread, which works regardless of the locking mode setting. The tasmota core (IDF 5.3.x, used for C6) likely has CONFIG_LWIP_CHECK_THREAD_SAFETY=n, which is why the same violation does not crash on C6.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/cfg.cpp:673-673
Timestamp: 2026-03-27T21:17:51.985Z
Learning: In WLED PR `#5048` (wled00/cfg.cpp), the NTP crash on ESP32-C5 (pioarduino + IDF 5.5.x) is caused by both CONFIG_LWIP_TCPIP_CORE_LOCKING=y AND CONFIG_LWIP_CHECK_THREAD_SAFETY=y being enabled by default in the pioarduino/arduino-esp32 IDF 5.x sdkconfig. The tasmota core (IDF 5.3.x, used for C6) likely has CONFIG_LWIP_CHECK_THREAD_SAFETY=n, which is why the same violation does not crash on C6. Since pioarduino already has TCPIP_CORE_LOCKING enabled, wrapping ntpUdp.begin() (and any other raw lwIP API call) with LOCK_TCPIP_CORE()/UNLOCK_TCPIP_CORE() from lwip/tcpip.h is directly applicable without sdkconfig changes in platformio.ini.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5442
File: wled00/bus_manager.cpp:462-468
Timestamp: 2026-03-23T23:33:45.480Z
Learning: In WLED's TYPE_ANALOG_2CH_HBRIDGE (wled00/bus_manager.cpp), the dead zone at the CCT midpoint (level=127 and level=128 both producing _data[0]=0, _data[1]=0) is intentional by design. The map() blending is directional: WW channel (_data[0]) is brightest at level=0 and fades to 0 at level=127; CW channel (_data[1]) starts at 0 at level=128 and is brightest at level=255. The zero-output at the midpoint is the H-bridge polarity transition boundary, ensuring no overlap between the two polarity directions. Do not flag this dead zone as a bug in future reviews.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5457
File: platformio_override.ini:23-23
Timestamp: 2026-03-31T17:05:49.401Z
Learning: In WLED PR `#5457` (platformio_override.ini, esp32c6_zigbee): The comment "Zigbee 802.15.4 radio on C6 shares the RMT peripheral" is factually incorrect per official Espressif documentation. The ESP32-C6 802.15.4 radio does NOT use or share the RMT peripheral. What IS shared (documented in ESP32-C6 datasheet and ESP-IDF RF coexistence guide) is the single 2.4 GHz RF path (antenna/transceiver), shared among WiFi, BLE, and 802.15.4 via time-division multiplexing — this applies equally to WiFi, not just Zigbee. The rmt_tx_wait_all_done() timeout spam is most likely caused by Zigbee light-sleep enabling aggressive power management (CONFIG_PM_ENABLE) that disrupts RMT's internal time base, or ISR latency due to cache-disable during flash ops. Mitigations: wrap TX with rmt_enable()/rmt_disable() for PM lock, set allow_pd=0, or enable CONFIG_RMT_TX_ISR_CACHE_SAFE. For reliable WiFi+Zigbee gateway operation, Espressif officially recommends a dual-SoC solution (e.g., ESP32-S3 + ESP32-H2). ESP32-C5 has the same single-RF coexistence limitation as C6.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-03-08T00:57:36.134Z
Learning: In WLED (wled00/cfg.cpp), `deserializeConfig()` is called with an empty JsonObject when cfg.json doesn't exist on fresh install. Any value read without the ArduinoJSON `|` fallback operator or CJSON macro will override correct constructor defaults with 0/null. Known affected values: `strip.setTargetFps(hw_led["fps"])` at line 179 (sets FPS to 0/unlimited instead of WLED_FPS=42). Fix: `strip.setTargetFps(hw_led["fps"] | WLED_FPS)`. The gamma issue (gammaCorrectCol/Bri) had the same root cause and was fixed in commit d1d9dec402 (Jan 2026) using inline `| default` fallbacks.

---

Learnt from: willmmiles
Repo: wled/WLED PR: 5462
File: wled00/json.cpp:1189-1198
Timestamp: 2026-03-30T15:32:08.847Z
Learning: In WLED's `respondModeData()` (wled00/json.cpp), the 256-character `lineBuffer` limit for effect descriptor strings (getModeData) is an intentional constraint that matches the same 256-char limit used ~6 other places in the codebase. It is not new to this PR and should not be flagged as a regression. Lifting it requires a future refactor (better type system or dynamic buffer).

---

Learnt from: softhack007
Repo: wled/WLED PR: 5480
File: docs/cpp.instructions.md:511-511
Timestamp: 2026-04-08T19:10:48.754Z
Learning: In WLED documentation and review guidance (`docs/cpp.instructions.md`), using `WLED_MAX_SEGNAME_LEN = 64` as the example value in LittleFS filename-length checks is intentional and correct. The reasoning: ESP32 uses 64-char segment names (the larger default), and if a constructed path (e.g. `/ledmap_` + segment name + `.json`) stays within 255 bytes when the name is 64 chars, it is trivially safe on ESP8266 where segment names are limited to 32 chars. WLED core has no ESP8266-only features, so validating against the larger ESP32 default is the right cross-platform conservative choice. Do NOT flag `WLED_MAX_SEGNAME_LEN = 64` in this guidance as misleading or platform-specific.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4889
File: wled00/json.cpp:310-310
Timestamp: 2026-03-21T18:12:09.437Z
Learning: In WLED's `deserializeSegment()` (wled00/json.cpp), the blend mode field `seg.blendMode` is intentionally written without a post-read clamp (`getVal(elem["bm"], seg.blendMode)`). Out-of-range or unsupported blend mode values are handled safely in `WS2812FX::blendSegment()` (wled00/FX_fcn.cpp), which defaults to mode 0 for any unsupported value via a bounds check against the `BLENDMODES` constant. Do not flag the missing clamp in deserializeSegment as a bug in future reviews.

---

Learnt from: netmindz
Repo: wled/WLED PR: 5093
File: wled00/util.cpp:1159-1182
Timestamp: 2025-11-20T00:04:04.829Z
Learning: In WLED PR `#5093`, the deviceId feature is designed for opt-in usage reporting that tracks only version/upgrade information (non-behavioral data), not user activity patterns. The deterministic salt approach (MAC + "WLED" + chip model/revision) is acceptable for this limited use case, as correlating MAC addresses to version history represents minimal privacy risk compared to behavioral tracking.

[oloboy]

Hi
Here the description.xml

<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>http://192.168.50.176:80/</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
<friendlyName>Espalexa (192.168.50.176:80)</friendlyName>
<manufacturer>Royal Philips Electronics</manufacturer>
<manufacturerURL>http://www.philips.com</manufacturerURL>
<modelDescription>Philips hue Personal Wireless Lighting</modelDescription>
<modelName>Philips hue bridge 2012</modelName>
<modelNumber>929000226503</modelNumber>
<modelURL>http://www.meethue.com</modelURL>
<serialNumber>6cc8408cb02c</serialNumber>
<UDN>uuid:2f402f80-da50-11e1-9b23-6cc8408cb02c</UDN>
<presentationURL>index.html</presentationURL>
</device>
</root>

[netmindz]

Please try and flash the bin from here to see if it helps

https://github.com/wled/WLED/actions/runs/24174989133

[oloboy]

I performed a packet capture to better understand where discovery fails.

Alexa IP: 192.168.50.192
WLED IP: 192.168.50.176

I used the following Wireshark filter:
udp.port == 1900 && ip.src == 192.168.50.176

Result:

I can clearly see multiple M-SEARCH requests from Alexa (192.168.50.192 → 239.255.255.250)
However, there are no SSDP responses at all from the WLED device

Specifically, I do NOT see any response like:

HTTP/1.1 200 OK
LOCATION: http://192.168.50.176/description.xml

I also confirmed that:

WLED is reachable via HTTP (/description.xml works)
The device appears in generic UPnP scanner apps
Network/multicast is working (other devices respond correctly)

Conclusion from this capture:
It seems that WLED (Espalexa) is not responding to the M-SEARCH requests sent by Alexa, which prevents discovery from even reaching the HTTP validation stage.

I am attaching the Wireshark screenshot showing:

Alexa sending M-SEARCH
No corresponding response from WLED