Home Assistant not showing main color

[tsmithf2020]

What happened?

i just updated my 2 wled device, and HA no longer show what color they are in, i can change it to preset colors, but the color state is always the same

To Reproduce Bug

update to 16 and HA

Expected Behavior

showing color like it use too

Install Method

Binary from WLED.me

What version of WLED?

Installed version: WLED 16.0.0 (2605030)

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[DedeHai]

@coderabbitai any insight on this? How does HA read the color?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 5605 --repo wled/WLED --comments

Length of output: 138

---

🌐 Web query:

Home Assistant WLED integration how does it read color state

💡 Result:

Home Assistant’s WLED integration gets the current color from WLED’s reported segment state, and exposes only the segment’s “primary” color as the light entity color.

• Where it reads it in HA: each WLED segment light entity returns its color from coordinator.data.state.segments[segment_id].color.primary (RGB uses the first 3 channels; RGBW uses all 4). [1]
• Where that comes from in WLED: WLED’s JSON API reports per-segment colors in state.seg[].col, where col[0] is the primary color (and can include a 4th “W” channel on RGBW setups). [2]
• Implication: effects that use secondary/tertiary colors (col[1], col[2]) won’t be reflected/controlled as separate colors in Home Assistant; the integration is designed around the primary color only. [3]

Sources: [1] Home Assistant wled/light.py (segment light rgb_color/rgbw_color) (github.com), [2] WLED JSON API (state.seg[].col) (kno.wled.ge), [3] HA WLED integration docs (primary color limitation) (home-assistant.io)

Citations:

• 1: https://github.com/home-assistant/core/blob/dev/homeassistant/components/wled/light.py
• 2: https://kno.wled.ge/interfaces/json-api/
• 3: https://www.home-assistant.io/integrations/wled/

---

🏁 Script executed:

#!/bin/bash
gh issue view 5605 --repo wled/WLED

Length of output: 783

---

🌐 Web query:

Home Assistant WLED light.py rgb_color segment color primary col

💡 Result:

In Home Assistant’s WLED integration, the light entity’s rgb_color maps to the segment’s primary color only (WLED JSON seg[].col[0]). Home Assistant currently cannot set WLED’s secondary/tertiary segment colors (col[1], col[2]) via the integration. [1]

If you need the actual WLED segment color fields:

• WLED JSON API: each segment has col, an array of up to 3 colors: primary, secondary, tertiary; each color is an RGB (or RGBW) byte array. [2]
  Example payload conceptually looks like:
  {"seg":[{"id":<segId>,"col":[[r,g,b],[r,g,b],[r,g,b]]}]}. [2]

Workarounds:

• Configure secondary/tertiary colors in WLED and save a preset, then activate the preset from Home Assistant (restores all colors). [1]
• Or call WLED’s JSON API directly (REST/command) to set seg[].col[...]. [2]

Sources: Home Assistant WLED integration docs [1]; WLED JSON API docs [2].

---

🌐 Web query:

WLED 0.16 changelog JSON API segment color col changes

💡 Result:

In the WLED 0.16 / 16.0 timeframe, the JSON API segment color col field gained a more flexible input format (and a new “random color” option):

1) seg[].col now accepts multiple types per color slot

Instead of only [[r,g,b(,w)], ...], each of the up-to-3 segment colors can be any of: int | string | object | array. (github.com)

Per the release notes:

• int = Kelvin temperature (or 0 for black/off)
• string = hex color in [WW]RRGGBB
• object = per-channel control, e.g. {"r":0,"g":127,"b":255,"w":255} (each optional)
• array = direct channel values [r,g,b,w] (w optional) (github.com)

So you can now send (examples):

{"seg":[{"id":0,"col":["FF0000","00FF00","0000FF"]}]}

{"seg":[{"id":0,"col":[{"r":255,"g":64},{"b":255},0]}]}

2) Random colors via col (“r”) (added for 16.0)

WLED 16.0 adds the ability to set random colors via the JSON API, and the JSON API docs describe using "r" inside col to randomize one or more of the 3 color slots. (github.com)

Example:

{"seg":[{"id":0,"col":["r",[0,0,0],"r"]}]}

Citations:

• 1: https://github.com/wled/WLED/releases
• 2: https://github.com/wled/WLED/releases
• 3: https://github.com/wled/WLED/releases/tag/v16.0.0

---

🌐 Web query:

WLED 0.16 JSON state response col format changed hex string instead of array

💡 Result:

In WLED 0.16 (aka v16.0.0) the JSON API’s per-segment col field was extended so each of the up-to-3 colors is no longer guaranteed to be an [r,g,b,(w)] array.

As of the change, each entry in seg[].col can be any of: array, string (hex), object (per-channel), or int (Kelvin/black): (github.com)

• array: [r,g,b] or [r,g,b,w]
• string: hex form of [WW]RRGGBB (leading WW only for RGBW) (github.com)
• object: e.g. {"r":0,"g":127,"b":255,"w":255} (channels optional)
• int: Kelvin temperature (or 0 for black)

So if your /json/state response now shows e.g. "col":["FF0000","000000","000000"] (or RGBW like "col":["10FF0000", ...]), that’s expected—update your client to accept both the old nested arrays and the newer hex-string (and other) variants. (github.com)

Citations:

• 1: https://github.com/wled/WLED/blob/main/CHANGELOG.md
• 2: https://github.com/wled/WLED/blob/main/CHANGELOG.md
• 3: https://github.com/wled/WLED/blob/main/CHANGELOG.md

---

🌐 Web query:

Home Assistant WLED integration update 0.16 color parsing fix col string hex

💡 Result:

WLED’s JSON API gained support for HEX color strings in the "col" field (instead of only [r,g,b,(w)] arrays), e.g. "col":["RRGGBBWW"] (note the white channel at the end) and this requires Home Assistant / its python-wled client to treat "col" as array-or-string and decode the hex when it’s a string. [1]

A minimal “color parsing fix” (what HA effectively needs) looks like:

def parse_wled_col(col):
    # WLED JSON "col" can be e.g. [255,0,0] / [255,0,0,0] OR "RRGGBBWW"
    if isinstance(col, (list, tuple)):
        return list(col)  # already [r,g,b,(w)]
    if isinstance(col, str):
        s = col.strip().lstrip("#")
        if len(s) == 6:   # RRGGBB
            r,g,b = int(s[0:2],16), int(s[2:4],16), int(s[4:6],16)
            return [r,g,b]
        if len(s) == 8:   # JSON API: RRGGBBWW
            r,g,b,w = int(s[0:2],16), int(s[2:4],16), int(s[4:6],16), int(s[6:8],16)
            return [r,g,b,w]
    raise ValueError(f"Unsupported WLED col value: {col!r}")

If you’re dealing with MQTT color topics instead of the JSON API, WLED documents HEX as #RRGGBB or #WWRRGGBB (white at the front), so you’d decode the 8-digit form differently in that path. [2]

Sources: WLED changelog entry about HEX "col" in JSON API [1]; WLED MQTT documentation for #RRGGBB / #WWRRGGBB [2].

[1] https://github.com/wled/WLED/blob/main/CHANGELOG.md
[2] https://github.com/Aircoookie/WLED/wiki/MQTT/43e11efa926d42b62cda616eb3e80d3b40c50c11

---

🌐 Web query:

python-wled library col hex string parsing issue WLED 16

💡 Result:

WLED 0.16’s Extended JSON API allows seg[].col[] entries to be strings: “hex representation of [WW]RRGGBB” (i.e., typically no leading #). [1]

python-wled’s Color._deserialize() does try to handle string colors, but it currently slices assuming a leading # (it parses at offsets 1,3,5). That breaks on WLED’s RRGGBB strings (e.g. "FFAA00"), causing wrong values or ValueError during int(..., 16). [2]

Fix (library-side): accept both formats (with/without #) and optionally [WW]RRGGBB:

def parse_hex(s: str) -> tuple[int,int,int] | tuple[int,int,int,int]:
    s = s.strip()
    if s.startswith("#"):
        s = s[1:]
    if len(s) == 6:          # RRGGBB
        r,g,b = (int(s[i:i+2], 16) for i in (0,2,4))
        return (r,g,b)
    if len(s) == 8:          # WWRRGGBB (per WLED docs)
        w,r,g,b = (int(s[i:i+2], 16) for i in (0,2,4,6))
        return (r,g,b,w)     # or keep (w,r,g,b) depending on your model
    raise ValueError(f"Bad hex color: {s!r}")

Workaround (caller-side): if you control the payloads you send, avoid string colors and send col as arrays like [[r,g,b]] (WLED’s JSON API example). [3]

Sources: WLED changelog on col string format [1]; python-wled model code showing the #-assumption offsets [2]; WLED JSON API example using array colors [3].

[1] (github.com)
[2] (raw.githubusercontent.com)
[3] (kno.wled.ge)

Citations:

• 1: https://github.com/wled/WLED/releases?utm_source=openai
• 2: https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py
• 3: https://kno.wled.ge/interfaces/json-api/?utm_source=openai

---

@DedeHai — Here's what's happening:

How HA reads the WLED color

Home Assistant's WLED integration reads color via the python-wled library, pulling the primary color from each segment — specifically state.seg[].col[0] in WLED's JSON API response. Secondary and tertiary colors (col[1], col[2]) are not surfaced in HA at all — the integration is designed around the primary color only.

Why WLED 0.16 breaks it

In WLED 0.16, the seg[].col field was extended so each color entry is no longer guaranteed to be a [r,g,b,(w)] array — it can now be an array, a hex string (e.g. "RRGGBB"), an object (e.g. {"r":255,"g":64}), or an int (Kelvin temperature).

The python-wled library's Color._deserialize() method does try to handle string colors, but it assumes a leading # (parsing at offsets 1, 3, 5). This breaks on WLED's bare RRGGBB hex strings (e.g. "FFAA00"), causing wrong values or a ValueError.

Root cause summary

Step	What happens
WLED 0.16 sends state	col field may now be "FF0000" (string) instead of [255,0,0] (array)
python-wled tries to parse	Expects #FF0000, gets FF0000 → parse fails / returns garbage
HA displays color	Shows wrong/stale color because deserialization silently fails

Where the fix needs to land

This is a python-wled library bug (hence the external label on the issue). The Color._deserialize() method needs to be updated to handle bare RRGGBB hex strings (and optionally WWRRGGBB for RGBW). The fix would look roughly like:

def parse_col(col):
    if isinstance(col, list):
        return col  # old format: [r, g, b, (w)]
    if isinstance(col, str):
        s = col.lstrip("#")  # handle both "RRGGBB" and "#RRGGBB"
        if len(s) == 6:
            return [int(s[i:i+2], 16) for i in (0, 2, 4)]
        if len(s) == 8:  # WWRRGGBB (RGBW)
            return [int(s[i:i+2], 16) for i in (2, 4, 6, 0)]
    # handle int (Kelvin) or object formats as needed

The issue should be reported upstream to the python-wled library (maintained by @frenck) and/or the Home Assistant WLED integration. Once python-wled is updated, HA will need to bump its dependency version to pick up the fix.

[DedeHai]

@coderabbitai you analysis is flawed. look at serializeSegment(), the state json did not change format fundamentally. there must be a different reason.

[coderabbitai]

🧩 Analysis chain

You're right to push back — let me look at the actual serializeSegment() implementation before drawing conclusions.

---

🏁 Script executed:

#!/bin/bash
# Find serializeSegment in the codebase
rg -n "serializeSegment" --type cpp -C 2

# Also find where col is serialized
rg -n "\"col\"" --type cpp -C 5

Length of output: 9612

---

Let me look at the full color serialization block in detail.

---

🏁 Script executed:

#!/bin/bash
# Read the full serializeSegment function
sed -n '563,660p' wled00/json.cpp

Length of output: 3361

---

You're right — the format hasn't changed: serializeSegment() still always writes col as [[r,g,b],[r,g,b],[r,g,b]] integer arrays. My previous analysis was wrong. Let me look at this more carefully — specifically the python-wled parsing side and any structural changes in WLED that might affect what HA sees.

Let me read the full issue and also check what the python-wled rewrite changed in color handling.

---

🏁 Script executed:

#!/bin/bash
# Get full issue details
gh issue view 5605 --repo wled/WLED --json title,body,labels,comments

# Also look at the WLED changelog for 0.16 color-related changes
rg -n "color|col|Color" CHANGELOG.md | head -60

Length of output: 30010

---

The col format is indeed unchanged — you're right. Let me now look at the actual python-wled parsing code to find the real cause.

This is very helpful. Now I can see what the real issue likely is. Let me check the current mashumaro-based python-wled Segment model and which new fields WLED 0.16 introduces.

---

🏁 Script executed:

#!/bin/bash
# Check git log for when new segment fields (bm, lc, set, si, m12) were added
git log --oneline --all -- wled00/json.cpp | head -20

# Check what new fields are in serializeSegment that didn't exist before
# Look for bm, lc, set, si, m12 in git history
git log --oneline --all --diff-filter=M -- wled00/json.cpp | head -10

# Show the actual diff for recent json.cpp changes related to segment serialization
git log --oneline -10

Length of output: 2297

---

🏁 Script executed:

#!/bin/bash
# Fetch current python-wled models.py from GitHub
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py" | head -200

# Also check what segment fields were added in the blendMode commit
git show 9cf3a7d1 -- wled00/json.cpp | grep "^+" | grep -E '"bm"|"lc"|"set"|"si"|"m12"|blendMode|serializeSegment' | head -30

Length of output: 6640

---

🏁 Script executed:

#!/bin/bash
# Get the full Segment model from python-wled
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py" | grep -n "class Segment\|alias\|field\|color\|Color\|lc\|bm\|set\|si\|m12" | head -80

# Also get lines 200-400 of models.py to see the Segment class fully
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py" | sed -n '200,420p'

Length of output: 12674

---

🏁 Script executed:

#!/bin/bash
# Check serializeInfo for leds/lc output
rg -n '"lc"\|"seglc"\|LightCapability\|getLightCapabilities\|lightCapabilities' wled00/json.cpp | head -30

# See the leds serialization section
sed -n '700,800p' wled00/json.cpp

# Also check for any HA/python-wled open issues about WLED 16
gh search issues "WLED 16 color" --repo home-assistant/core --limit 5 2>/dev/null || true
gh search issues "python-wled WLED 16" --limit 5 2>/dev/null || true

Length of output: 4688

---

🏁 Script executed:

#!/bin/bash
# Check how WLED pushes websocket/notify updates - does it send full state or partial?
rg -n "notify\|websocket\|ws\.text\|sendStateJson\|serializeState" wled00/json.cpp | head -30
rg -n "notify\|sendStateJson\|wsSend\|ws\.text" wled00/notify.cpp 2>/dev/null | head -30
rg -n "notify\|sendStateJson\|wsSend\|ws\.text" wled00/wled.cpp 2>/dev/null | head -20

# Fetch HA WLED light.py to see how it reads color from segment
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/light.py" | grep -n "color\|rgb\|primary\|col\|lc\|capability\|Capability" | head -40

Length of output: 1088

---

🏁 Script executed:

#!/bin/bash
# Get more context from HA light.py - specifically the LIGHT_CAPABILITIES_COLOR_MODE_MAPPING usage
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/light.py" | sed -n '100,200p'

# Also check LightCapability enum in python-wled const.py
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/const.py" | grep -A 20 "LightCapability"

# Check what lc bits mean
rg -n "getLightCapabilities\|LightCapabilities\|LIGHT_CAPABILITY\|lightCap" wled00/wled.h wled00/FX_fcn.cpp 2>/dev/null | head -20

Length of output: 4213

---

🏁 Script executed:

#!/bin/bash
# Get LIGHT_CAPABILITIES_COLOR_MODE_MAPPING from HA light.py
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/light.py" | sed -n '1,100p'

# Also check getLightCapabilities in WLED source
rg -n "getLightCapabilities\|getMaxCapabilities" wled00/FX_fcn.cpp | head -10
grep -n "getLightCapabilities\|getMaxCapabilities" wled00/wled.h wled00/FX.h 2>/dev/null | head -10

Length of output: 3120

---

🏁 Script executed:

#!/bin/bash
# Get LIGHT_CAPABILITIES_COLOR_MODE_MAPPING from HA const.py
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/const.py" | grep -A 50 "LIGHT_CAPABILITIES_COLOR_MODE_MAPPING"

# Also check what getLightCapabilities returns / how _capabilities is set
rg -n "_capabilities\|setCapabilities\|getLightCap" wled00/FX.h | head -20
rg -n "_capabilities\|setCapabilities\|getLightCap" wled00/FX_fcn.cpp | head -20

Length of output: 1656

---

🏁 Script executed:

#!/bin/bash
# Find where _capabilities is set on a Segment in WLED
rg -n "_capabilities" wled00/FX_fcn.cpp | head -30
rg -n "_capabilities" wled00/FX.h | head -20

# Also check the seglc output more carefully - is it truly dense (skipping inactive) in WLED 0.16?
# vs how was it done before?
git log --oneline --all -- wled00/json.cpp | head -5
git show HEAD -- wled00/json.cpp | grep -A 15 "seglc\|lcarr"

Length of output: 572

---

🏁 Script executed:

#!/bin/bash
sed -n '990,1060p' wled00/FX_fcn.cpp

# Also check the seglc JSON serialization with current HEAD
grep -n "seglc\|lcarr" wled00/json.cpp

Length of output: 3287

---

🏁 Script executed:

#!/bin/bash
# Fetch the full State model and how segments dict is built
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py" | grep -n "class State\|segments\|segment_id\|Segment\|Dict\|dict\|seglc" | head -40

# Also check for the SEG_CAPABILITY_* constants in WLED
rg -n "SEG_CAPABILITY" wled00/const.h wled00/FX.h 2>/dev/null | head -10

Length of output: 2596

---

@DedeHai — You're correct, and I apologize for the flawed earlier analysis. After deeper investigation, here's the accurate picture:

What serializeSegment() actually outputs for col

The format is always integer arrays — unchanged:

[[r,g,b],[r,g,b],[r,g,b]]          (RGB)
[[r,g,b,w],[r,g,b,w],[r,g,b,w]]    (RGBW)

using sprintf_P with [%u,%u,%u] / [%u,%u,%u,%u] format, written via serialized(colstr). The flexible int|string|object|array input format is only for deserializeSegment(), never for output.

What HA actually does to read color

1. python-wled fetches /json/state, uses State.__pre_deserialize__ to convert the seg array to a dict keyed by enumeration index (0, 1, 2…), overwriting each segment's id with the enumeration index.
2. Color._deserialize receives [[r,g,b],[r,g,b],[r,g,b]] — since each entry is a list (not a string), it passes them through directly as Color(primary=[r,g,b], ...).
3. HA light.py reads coordinator.data.state.segments[self._segment].color.primary[:3] for rgb_color.

What changed in WLED 0.16 that HA might trip over

Two new fields appear in serializeSegment() output that weren't there before:

• bm (blendMode) — added in commit 9cf3a7d1
• lc (per-segment light capabilities) — replacing the seglc array in /json/info

Mashumaro should ignore unknown fields by default (no forbid_extra_keys in BaseConfig), but worth verifying the exact mashumaro version bundled with HA doesn't have stricter behavior.

The more significant change is the deprecation direction for lc: WLED 0.16 added // deprecated, use state.seg[].lc to seglc in /json/info, but python-wled's Segment model has no lc field. The per-segment lc from state is silently ignored, so HA still depends on the deprecated seglc array for determining color mode.

Most likely actual bug

HA determines whether to show color controls in __init__ (once, not on refresh):

color_modes := LIGHT_CAPABILITIES_COLOR_MODE_MAPPING.get(
    coordinator.data.info.leds.segment_light_capabilities[segment]
)

If this fails or returns None (e.g. due to an IndexError on seglc, or an unrecognized LightCapability bitmask), the entity permanently stays in ColorMode.BRIGHTNESS — no color is ever shown. This would explain "color state is always the same."

Suggested investigation: Check whether the seglc array from /json/info on WLED 0.16 produces a value that maps correctly through LIGHT_CAPABILITIES_COLOR_MODE_MAPPING. The capability bits themselves are unchanged (SEG_CAPABILITY_RGB=1, SEG_CAPABILITY_W=2, SEG_CAPABILITY_CCT=4), but if the mashumaro deserialization of the Info/Leds model is failing on a new WLED 0.16 field, segment_light_capabilities might come back as an empty list — and then seglc[segment] throws an IndexError that silently prevents color mode from being set.

The fix likely needs to land in python-wled to handle WLED 0.16's new segment fields.

🔍

[softhack007]

@coderabbitai please create a concise summary overview (with examples) of which /json/info items are read by the HomeAssistant WLED integration, and how these fields have changed between release 16.0.0 and the previous 0.15.5 release. With examples that clarify differences. Do the same for other /json/ endpoints of WLED that are relevant for HomeAssistant integration.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# 1. Get full serializeInfo and serializeState from current HEAD (16.0.0)
grep -n "serializeInfo\|serializeState\|serializeLeds\|serializePalettes\|serializeEffects\|serializeNetworks\|serializeNodes" wled00/json.cpp | head -30

# 2. Get the full serializeInfo function
awk '/^bool serializeInfo\(/{p=1} p{print NR": "$0} /^}$/{if(p){p=0}}' wled00/json.cpp | head -150

# 3. Check git tags to find the right tag for 0.15.0 / 0.15.5
git tag | grep -E "v0\.15|v16|v0\.14" | sort

Length of output: 728

---

🏁 Script executed:

#!/bin/bash
# Fetch full python-wled models.py
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/models.py"

Length of output: 33046

---

🏁 Script executed:

#!/bin/bash
# Fetch HA WLED coordinator.py to see which endpoints are polled
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/coordinator.py"

# Fetch HA WLED sensor.py to see which info fields are used
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/sensor.py" | head -200

# Fetch HA WLED const.py
curl -s "https://raw.githubusercontent.com/home-assistant/core/dev/homeassistant/components/wled/const.py"

Length of output: 15250

---

🏁 Script executed:

#!/bin/bash
# Get full serializeInfo() function from current HEAD
echo "=== serializeInfo (HEAD) ==="
sed -n '/^void serializeInfo/,/^}/p' wled00/json.cpp

echo ""
echo "=== serializeState (HEAD, first 120 lines) ==="
sed -n '/^void serializeState/,/^}/p' wled00/json.cpp | head -120

echo ""
echo "=== serializeSegment (HEAD) ==="
sed -n '/^void serializeSegment/,/^}/p' wled00/json.cpp | head -120

Length of output: 9521

---

🏁 Script executed:

#!/bin/bash
# Compare json.cpp between v0.15.0 tag and HEAD for serializeInfo/serializeState/serializeSegment
git show v0.15.0:wled00/json.cpp | sed -n '/^void serializeInfo/,/^}/p' > /tmp/info_0150.txt 2>/dev/null || echo "Tag v0.15.0 not found"
git tag | grep -i "0\.15\|15\." | sort

# Try alternate tag names
git show "v0.14.4":wled00/json.cpp 2>/dev/null | sed -n '/^void serializeInfo/,/^}/p' | head -80 || true

Length of output: 38

---

🏁 Script executed:

#!/bin/bash
# Get LightCapability from python-wled const.py
curl -s "https://raw.githubusercontent.com/frenck/python-wled/main/src/wled/const.py"

Length of output: 1432

---

🏁 Script executed:

#!/bin/bash
# Get serializeSegment with explicit line range
grep -n "void serializeSegment" wled00/json.cpp
echo "---"
# Get from line where serializeSegment starts to ~120 lines after
START=$(grep -n "^void serializeSegment" wled00/json.cpp | cut -d: -f1)
END=$((START + 130))
sed -n "${START},${END}p" wled00/json.cpp

Length of output: 172

---

🏁 Script executed:

#!/bin/bash
# Find a commit representing 0.15.x - look at git log for version string changes
git log --oneline --all | grep -iE "0\.15|release|version" | head -20
git log --oneline --all | head -30

# Also check what the version string was before 16.0.0
git log --oneline --all -- wled00/const.h | head -10

Length of output: 3717

---

🏁 Script executed:

#!/bin/bash
# Get serializeSegment from HEAD using awk
awk '/^static void serializeSegment/{p=1} p{print NR": "$0} /^}$/{if(p){p=0; exit}}' wled00/json.cpp

echo ""
echo "=== Commit 1ee42f02 (version change) info ==="
git show 1ee42f02 --stat

echo ""
echo "=== serializeInfo from just before version-change commit ==="
git show 1ee42f02^:wled00/json.cpp | awk '/^void serializeInfo/{p=1} p{print NR": "$0} /^}$/{if(p){p=0; exit}}'

echo ""
echo "=== serializeSegment from just before version-change commit ==="
git show 1ee42f02^:wled00/json.cpp | awk '/^static void serializeSegment/{p=1} p{print NR": "$0} /^}$/{if(p){p=0; exit}}'

Length of output: 13718

---

@softhack007 — Here is a concise comparison of what HA reads from each WLED JSON endpoint and how things changed.

---

How HA Reads WLED JSON Endpoints

HA uses the python-wled library (via WLED.update()) which fetches /json (combined state + info + effects + palettes) on every polling cycle, plus /json/presets separately. If WebSocket support is detected (info.ws ≥ 0), it switches to WebSocket push instead of polling. Below is a field-by-field breakdown.

---

1. /json/info — serializeInfo()

Fields HA Actually Reads

WLED JSON key	HA model path	Used for
ver	info.version	Version checks, palette ID base logic
name	info.name	Device friendly name
mac	info.mac_address	Unique ID, MAC mismatch check
ip	info.ip	IP sensor
arch	info.architecture	Device type detection (esp01/esp02/esp8266/esp32)
core	info.arduino_core_version	Diagnostics
brand	info.brand	Device info
product	info.product	Device info
vid	info.build	Build ID
release	info.release	OTA firmware filename selection
udpport	info.udp_port	UDP port sensor
live	info.live	Realtime mode state
lm	info.live_mode	Live mode string
lip	info.live_ip	Live source IP
ws	info.websocket	WebSocket availability (-1 = disabled → None)
fxcount	info.effect_count	Number of effects
palcount	info.palette_count	Number of built-in palettes
cpalcount	info.custom_palette_count	⚠️ Semantics changed (see below)
str	info.sync_toggle_receive	UDP sync toggle flag
freeheap	info.free_heap	Free heap sensor
uptime	info.uptime	Uptime sensor
fs.u, fs.t, fs.pmt	info.filesystem.*	FS usage, preset modification time
wifi.{bssid,rssi,signal,channel}	info.wifi.*	WiFi sensors
leds.count	info.leds.count	LED count sensor
leds.pwr	info.leds.power	Estimated current sensor
leds.fps	info.leds.fps	(available but not surfaced as sensor)
leds.maxpwr	info.leds.max_power	Max power sensor (gates current sensor)
leds.maxseg	info.leds.max_segments	Segment limit
leds.lc	info.leds.light_capabilities	OR of all segment capabilities (bitmask)
leds.seglc	info.leds.segment_light_capabilities	Per-segment capabilities array → determines ColorMode
leds.rgbw	info.leds.rgbw	Deprecated, still read
leds.wv	info.leds.wv	Deprecated, still read
leds.cct	info.leds.cct	Deprecated, still read

Fields Output by WLED but Not Read by HA (silently ignored by mashumaro)

Key	Present in 0.15.x¹	Present in 16.0.0	Notes
cn (codename)	✅	✅	Not in Info model
repo	✅	✅	Not in Info model
deviceId	✅	✅	Not in Info model
leds.bootps	✅	✅	Boot preset ID, not in Leds model
simplifiedui	✅	✅	Not in Info model
liveseg	✅	✅	Not in Info model
maps	✅	✅	LED map array, not in model
ndc	✅	✅	Node count, not in model
opt	✅	✅	Build options bitmask, not in model
clock, flash	✅	✅	Hardware info, not in model
leds.matrix	✅	✅	2D matrix dims, not in model
umpalcount	❌	✅	NEW in 16.0.0 — usermod palette count
umpalnames	❌	✅	NEW in 16.0.0 — usermod palette name array
psram, psrSz	✅	✅	PSRAM info (ESP32 only), not in model

¹ "0.15.x" refers to the pre-16.0.0 development snapshot; the last stable release was 0.15.0.

⚠️ Changes That Matter for HA

A. ver format: "0.15.0" → "16.0.0"

The version scheme changed (commit 1ee42f02). AwesomeVersion handles both formats. The key consequence is the palette ID base check:

# python-wled const.py
CUSTOM_PALETTE_ID_CHANGE_VERSION = AwesomeVersion("16.0.0")
# 0.15.x: custom palettes counted down from ID 255
# 16.0.0: custom palettes start at ID 200; usermod palettes use 255-201

0.15.x:  custom palette 1 = ID 255, palette 2 = ID 254 ...
16.0.0:  custom palette 1 = ID 200, palette 2 = ID 199 ...
         usermod palettes: ID 255 down to 201

python-wled already handles this via CUSTOM_PALETTE_ID_CHANGE_VERSION. ✅

B. cpalcount semantics changed

In 16.0.0, cpalcount includes gray placeholder slots for usermod palette entries (not just user-created custom palettes). The new umpalcount field gives the actual usermod palette count, but HA ignores it. Net result: HA may synthesize slightly wrong custom palette entries but this is non-critical.

C. seglc (deprecated) — ⚠️ Key color mode risk

// 16.0.0 serializeInfo() — seglc loop:
for (size_t s = 0; s < nSegs; s++) {
    if (!strip.getSegment(s).isActive()) continue;  // ← skips inactive!
    unsigned lc = strip.getSegment(s).getLightCapabilities();
    totalLC |= lc;
    lcarr.add(lc);  // deprecated, use state.seg[].lc
}

seglc is a dense array of active segments only, not indexed by segment ID. If any segment before segment N is inactive, seglc[N] doesn't correspond to segment N. HA's LIGHT_CAPABILITIES_COLOR_MODE_MAPPING lookup uses seglc[segment_id], which can produce the wrong ColorMode — e.g., reporting ColorMode.BRIGHTNESS for an RGB segment.

The replacement state.seg[].lc (per-segment, ID-aligned) is output correctly in serializeSegment(), but python-wled's Segment model has no lc field, so it is silently dropped.

---

2. /json/state — serializeState() + serializeSegment()

Top-Level State Fields

WLED JSON key	HA model path	Notes
on	state.on	On/off
bri	state.brightness	Master brightness
transition	state.transition	Transition speed (×100ms)
ps	state.preset_id	Current preset (-1 → None)
pl	state.playlist_id	Current playlist (-1 → None)
mainseg	state.main_segment_id	Main segment ID
ledmap	state.ledmap	Active LED map index
lor	state.live_data_override	Live override mode
nl.*	state.nightlight.*	Nightlight state
udpn.*	state.sync.*	UDP sync config

bs (blendingStyle) — NEW, added in 16.0.0-era development, not in State model, silently ignored.

Per-Segment Fields (seg[])

The col format is unchanged between 0.15.x and 16.0.0 — it is always integer arrays on output:

RGB:  "col": [[255,170,0], [0,0,0],   [0,0,0]]
RGBW: "col": [[255,170,0,0], [0,0,0,0], [0,0,0,0]]

WLED field	python-wled Segment field	Read by HA?
id	segment_id	✅ (key for segments dict)
start, stop	start, stop	✅
on	on	✅
bri	brightness	✅
col	color (Color object)	✅ color.primary[:3] → rgb_color
fx	effect_id	✅
sx	speed	✅
ix	intensity	✅
pal	palette_id	✅
cct	cct	✅
sel	selected	✅
grp, spc, of	grouping, spacing, offset	✅
rev, mi	reverse, mirror	✅
frz	freeze	✅
n	name	✅
c1, c2, c3	custom1/2/3	✅
o1, o2, o3	option1/2/3	✅
set	set_id	✅ (in model)
si	sound_simulation	✅ (in model)
m12	expand_1d	✅ (in model)
lc	❌ not in Segment model	❌ silently dropped
bm	❌ not in Segment model	❌ silently dropped

⚠️ Key Issue: seg[].lc Silently Dropped

// Example segment output in 16.0.0 (and late 0.15.x-dev):
{
  "id": 0, "start": 0, "stop": 144,
  "col": [[255,170,0],[0,0,0],[0,0,0]],
  "lc": 1,   ← RGB_COLOR capability — NOT parsed by python-wled
  "bm": 0    ← blendMode — NOT parsed by python-wled
}

Since lc is dropped from the Segment model, HA cannot use the per-segment, ID-aligned capability for determining ColorMode. It falls back entirely on the deprecated seglc dense array from /json/info, which may be misaligned if segments are not contiguous.

---

3. /json/palettes and /json (combined)

The palette list is a simple JSON array of name strings — format unchanged. The reorganized ID space (new in 16.0.0) is handled in python-wled via the CUSTOM_PALETTE_ID_CHANGE_VERSION check.

The effects list (/json → effects) is a flat string array — format unchanged.

---

Summary: Actionable Items for the python-wled Fix

Item	Risk	Fix location
seglc index ≠ segment ID (inactive segs skipped)	⚠️ Wrong ColorMode for some configs	python-wled: add lc: LightCapability to Segment model; HA: use seg[].lc instead of seglc
bm (blendMode) not in Segment model	Low (not used by HA yet)	python-wled: add blend_mode: int to Segment
umpalcount/umpalnames ignored	Low	python-wled: add to Leds or Info model if needed
Color._deserialize string hex offset bug (1,3,5 instead of 0,2,4)	Medium (if WLED ever sends hex strings in state response — currently it does not)	python-wled: fix slice offsets

[softhack007]

• lc (per-segment light capabilities) — replacing the seglc array in /json/info
• seglc index ≠ segment ID (inactive segs skipped)

@DedeHai my educated guess is that this change (if confirmed) might cause the difference. We had a few "mud fights" already with HA devs about these so-called "capbilities" and questions like "why does one light need several brightness controls".

Some examples

• Invalid response from WLED API in Home Assistant when simply turning on the LED strip #4546
• Incorrect Light Capabilities set when LED strips is only On/Off #2979
• WLED devices expose an impossible (or undocumented) light capability #2983
• Nightlight target brightness can be 0, while brightness cannot be 0. #293
• Unknown character in presets.json - homeassistant integration  #2755
• Option to disable CCT channel because it is not supported by HA integration anymore #2526
• Auto return to Solid effect when color pic. (not work when effects running) #1690
• Segments name on HomeAssistant #3419
• MQTT Discovery on Home Assistant Not Working #172
• "MQTT entity name starts with the device name in your config" when using SHT usermod (HA specific) #3506

[DedeHai]

I do not use HA, maybe this issue should be raised with them to check what causes it?

[softhack007]

same here - no HA with wled integration in my house.

@netmindz do you have a "working link" to HA devs?

[ptryk]

there seems to be a discussion on HA about this here:
home-assistant/core#170435

[netmindz]

I don't really use HA for control of WLED, but I do have an HA setup. I don't use segments at all