Emulate Alexa devices per segment

[Titanium177]

Is your feature request related to a problem? Please describe.
Yes, i'm using two different stripes with 1 controller. Every Alexa command sets brightness etc. for both ones. The current workaround is to use presets, which limits it to preconfigured scenes.

Describe the solution you'd like
Add a option to emulate alexa devices per segment, just like it already exits for presets.

Describe alternatives you've considered
Adding separate controllers would be a way, but is unnecessary.

[BennoB666]

I hope this feature ist comming. We can save a lot of controller hardware.

[netmindz]

@coderabbitai Is this possible within the current rather basic hack that presents WLED as Hue in order to be controlled from Alexa and also add this feature in a backwards compatible manner?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get issue details
gh issue view 3719 --repo wled/WLED --json title,body,labels,comments | jq '{title, body, labels, comments: .comments[:5]}'

Length of output: 2173

---

🏁 Script executed:

#!/bin/bash
# Find Hue emulation related files
fd -e cpp -e h -e ino | xargs grep -l -i "hue\|alexa\|upnp" 2>/dev/null | head -20

# Also search by filename
fd -i "hue\|alexa\|upnp"

Length of output: 546

---

🏁 Script executed:

#!/bin/bash
cat wled00/alexa.cpp
echo "===== HUE.CPP ====="
cat wled00/hue.cpp

Length of output: 9593

---

🏁 Script executed:

#!/bin/bash
# Check espalexa library for device count limits
fd -e h -e cpp "EspalexaDevice\|espalexa" --full-path | head -10
find . -path "*/espalexa*" -name "*.h" | xargs grep -i "max\|limit\|count\|device" 2>/dev/null | head -30

# Check segment access API
grep -n "getSegment\|getSegmentCount\|segmentCount\|Segment\b" wled00/FX.h | grep -i "segment" | head -30

# Check how segment names are accessed
grep -n "seg.*name\|getName\|seg_name\|segName" wled00/FX.h wled00/json.cpp wled00/set.cpp 2>/dev/null | head -20

# Check alexaNumPresets and related config vars
grep -n "alexaNumPresets\|alexaEnabled\|alexaInvocation" wled00/cfg.cpp wled00/const.h wled00/wled.h 2>/dev/null | head -20

Length of output: 7278

---

🏁 Script executed:

#!/bin/bash
# Check segment count API and max segments
grep -n "getSegmentCount\|getMainSegment\|getSegment\b\|MAX_NUM_SEG\|_segments\b" wled00/FX.h | head -30

# Check WS2812FX/strip class for segment methods
grep -n "getSegmentCount\|getMainSegment\|getSegment\b\|segmentCount\|_segments" wled00/FX.cpp | head -20

Length of output: 1371

---

@netmindz — yes, this is feasible within the existing Hue emulation framework, and it can be done in a backwards-compatible way. Here's a breakdown:

---

How the current system works

alexa.cpp uses the espalexa library to present WLED as a Hue bridge. It registers devices in alexaInit():

• Device 0: global on/off/brightness/colour control
• Devices 1–N: one per preset (up to alexaNumPresets, capped at 9 today)

The onAlexaChange() callback dispatches on dev->getId() to decide whether to call applyPreset() or update global bri/strip.getMainSegment().

---

Is per-segment emulation possible within this framework?

Yes. The same registration pattern can be extended: in alexaInit(), after the main device, iterate strip.getSegmentsNum() and register each segment as a named device. In onAlexaChange(), map the device ID back to a segment index and call strip.getSegment(i).setOpacity(bri) and strip.getSegment(i).setColor(0, color) instead of touching global state.

A sketch of the extension:

// in alexaInit(), new branch for segment mode:
if (alexaExposeSegments) {
  for (unsigned i = 0; i < strip.getSegmentsNum(); i++) {
    Segment& seg = strip.getSegment(i);
    String segName = seg.name ? seg.name : ("Segment " + String(i + 1));
    EspalexaDevice* dev = new EspalexaDevice(segName.c_str(), onAlexaChange,
                                              EspalexaDeviceType::extendedcolor);
    espalexa.addDevice(dev);
  }
}

// in onAlexaChange(), new branch:
// device IDs after 0 (and optionally after preset devices) map to segments
if (alexaExposeSegments) {
  unsigned segIdx = dev->getId() - 1; // adjust offset as needed
  Segment& seg = strip.getSegment(segIdx);
  // apply bri / colour to that segment only
}

---

Backwards compatibility

Achievable with an opt-in config flag (e.g. alexaExposeSegments, defaulting to false). When disabled, existing behaviour (device 0 = global, devices 1–N = presets) is unchanged. Users who want per-segment control enable the flag, which triggers re-discovery by Alexa.

---

Key challenges to be aware of

Challenge	Detail
Device count limit	ESPALEXA_MAXDEVICES defaults to 10 but supports up to 128. On ESP8266 (16 segments max) memory is tight; on ESP32 (up to 64 segments) you'd need to raise this define, possibly platform-conditionally.
Dynamic segments	WLED lets users add/remove segments at runtime. Alexa caches discovered devices, so segment changes need a re-invoke of alexaInit() and Alexa re-discovery — same limitation the preset feature has today.
Preset vs. segment device slots	Both compete for the same device pool. An implementation decision is needed: allow both simultaneously (raise the limit), or make it a mode selection (presets OR segments).
Unnamed segments	Segments can have a nullptr name; a fallback like "Segment N" (using strip.getSegment(i).name) would be needed.
Segment brightness	Global bri shouldn't be modified for per-segment control; seg.setOpacity() targets only that segment.

Overall the architecture already has everything needed — it's an extension, not a rewrite. The main decision points are around the device-count limit tuning and whether to support presets and segments simultaneously.

---

🧠 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.