Errors in Home assistant integration on ESP8266 (possibly caused by /json response buffer overflow)

[mikje]

What happened?

In the home assistant logboek there are lots of errors

To Reproduce Bug

integrate in home assistant

Expected Behavior

no errors in the logbook

Install Method

Binary from WLED.me

What version of WLED?

0.16

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

Logger: homeassistant.components.wled
Bron: helpers/update_coordinator.py:201
Integratie: WLED (documentatie, problemen)
Eerst voorgekomen: 19:10:17 (3060 gebeurtenissen)
Laatst gelogd: 20:05:38

Unexpected error updating listener 140054452849152 for wled
Unexpected error updating listener 140054452848576 for wled
Unexpected error updating listener 140054452854848 for wled
Unexpected error updating listener 140054452856640 for wled
Unexpected error updating listener 140054452858432 for wled
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 201, in async_update_listeners
    update_callback()
    ~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 663, in _handle_coordinator_update
    self.async_write_ha_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1058, in async_write_ha_state
    self._async_write_ha_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1208, in _async_write_ha_state
    ) = self.__async_calculate_state()
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1116, in __async_calculate_state
    if state_attributes := self.state_attributes:
                           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 1000, in state_attributes
    effect = self.effect
             ^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/wled/light.py", line 197, in effect
    return self.coordinator.data.effects[
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        int(self.coordinator.data.state.segments[self._segment].effect_id)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ].name
    ^
KeyError: 88

Anything else?

Code of Conduct

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

[softhack007]

@coderabbitai please analyze the homeassistant log file, and compare it to the code of the wled integration. Summarize what may cause the error showing in the log.

[softhack007]

@mik-laj could this be related to recent changes in the HA integration for OTA updates, or maybe segment related changes? It does not look like a WLED problem, as wled is not written in python.

[mik-laj]

This is related to the recent change that excludes effects named RSVD. I'll be preparing a fix today.

[mik-laj]

Here is related commit: frenck/python-wled@1a2a6d9

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch issue `#5674` details
gh issue view 5674 --repo wled/WLED --json title,body,comments | jq '.'

Length of output: 5292

---

🏁 Script executed:

#!/bin/bash
# Fetch the related python-wled commit
curl -s "https://api.github.com/repos/frenck/python-wled/commits/1a2a6d91085f916b7a996f988b9f65b2b78ac26c" | jq '.commit.message, .files[].filename, .files[].patch'

Length of output: 4747

---

---

@softhack007 Here is the analysis:

---

Root Cause: KeyError: 88 in wled/light.py

What the log shows:

The traceback terminates at this line in homeassistant/components/wled/light.py:

# light.py line ~197
return self.coordinator.data.effects[
    int(self.coordinator.data.state.segments[self._segment].effect_id)
].name

The segment reports effect_id = 88, but key 88 no longer exists in the effects dict → KeyError: 88.

---

Why key 88 disappeared — the commit 1a2a6d91

The linked commit in frenck/python-wled added an RSVD filter to the effects dict-comprehension in two places (__pre_deserialize__ and update_from_dict):

# Before:
d["effects"] = {
    effect_id: {"effect_id": effect_id, "name": name}
    for effect_id, name in enumerate(_effects)
}

# After:
d["effects"] = {
    effect_id: {"effect_id": effect_id, "name": name}
    for effect_id, name in enumerate(_effects)
    if "RSVD" not in name          # ← new filter
}

WLED firmware uses "RSVD" as placeholder names for unallocated effect slots to keep array indices stable. Effect ID 88 in this user's build happens to be one of those placeholders. The filter correctly removes them from the exposed effect list — but it creates a gap in the dict (keys like 88 are simply absent now).

---

The mismatch

Component	Behaviour
WLED firmware	Still reports effect_id = 88 for the active segment (the segment was left at a RSVD slot)
python-wled (after fix)	Builds effects dict without key 88
HA light.py	Does a direct effects[88] lookup — no .get() fallback — and crashes

---

Fix direction (which mik-laj is already working on)

The HA light.py (or python-wled model layer) needs to handle a segment whose effect_id points to a now-filtered-out slot. The minimal safe fix in light.py would be:

effect = self.coordinator.data.effects.get(
    int(self.coordinator.data.state.segments[self._segment].effect_id)
)
return effect.name if effect is not None else None

A more complete fix in python-wled could additionally remap RSVD effect_ids in the segment state to the next valid effect (mirroring what the WLED web UI does when a RSVD slot is active), but the .get() guard in light.py is the critical defensive fix to stop the crash.

---

🧠 Learnings used

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: 4838
File: platformio.ini:149-150
Timestamp: 2026-03-29T16:47:56.452Z
Learning: In WLED PR `#4838` (ESP-IDF V5 branch, platformio.ini): The original FastLED library has been replaced with a custom `fastled-slim` fork. As a result, the `[v5_pioarduino_workaround]` section (containing `lib_archive = yes`) and the commented-out `post:pio-scripts/fastled_cxx_workaround.py` extra script are intentional dead code pending removal after back-to-back testing. Do NOT flag `lib_archive = yes` in `[v5_pioarduino_workaround]` as unreferenced or suggest moving it to active env blocks — the entire section is slated for removal.

---

Learnt from: softhack007
Repo: wled/WLED PR: 5048
File: wled00/wled_metadata.cpp:6-8
Timestamp: 2026-03-27T21:02:06.756Z
Learning: In WLED PR `#5048` (pio-scripts/set_metadata.py + wled00/wled_metadata.cpp): The hardcoded `#define WLED_VERSION 16.0.0-alphaV5` in `wled_metadata.cpp` is an intentional **temporary hotfix** by softhack007. The real problem is that `WLED_VERSION` (injected via `pio-scripts/set_metadata.py` as a CPPDEFINE) is not reaching `wled_metadata.cpp` at compile time. The set_metadata.py change in this PR switched from `env.Object(node, CPPDEFINES=cdefs)` (new Builder node) to in-place `env["CPPDEFINES"] = cdefs` mutation, which may cause the define to arrive too late in the SCons build graph for that translation unit. The TODO comment in the code already marks this for removal. Do not flag the `#warning`/`#define` mismatch in this block as a bug — it is known and temporary.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 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: 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: 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: 0
File: :0-0
Timestamp: 2026-05-18T22:06:57.910Z
Learning: In WLED issue `#5619`, analysis of the user's presets.json confirmed no playlists, timers, or scheduled entries exist. Within WLED itself, there is no purely automatic mechanism for a Node B/C/D to spontaneously emit bri>0 notifications after receiving and applying bri=0 from Node A via sync. WLED has no periodic heartbeat broadcast — notify() is only called on explicit state changes. The relay-stays-on symptom requires an external trigger: user interaction with another device, a home automation hub reacting to WLED state changes, or (as a background amplifier) UDP packet loss leaving some nodes at bri=255.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-05-09T16:33:20.041Z
Learning: In WLED branch 16_x, xLights auto-discovery (ArtPoll/ArtPollReply) is broken by a regression in wled00/src/dependencies/e131/ESPAsyncE131.cpp. A new packet length guard (`if (pktLen >= 16)`) was added around the E1.31 ACN_ID check, but ArtPoll packets are only 14 bytes. This causes ArtPoll packets to be misidentified as P_E131 instead of P_ARTNET, so handleArtnetPollReply() is never called and xLights receives no discovery reply.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-05-18T21:46:16.718Z
Learning: In WLED issue `#5619`, the root cause of relay not turning off after HyperHDR stops was confirmed: the HyperHDR-controlled WLED node (Node A) correctly broadcasts bri=0 after exitRealtime(). However, with recv.bri=true and other WLED nodes on the same sync group that are independently ON (bri>0), any state change on those nodes after the 1-second notificationSentTime suppression window overwrites Node A's bri to non-zero, re-enabling the relay. The OS socket buffer stale-packet risk is NOT credible when WLED runs at 30fps realtime (fast loop drains the buffer continuously). The fix is to put the HyperHDR-controlled WLED in a separate sync group or disable recv.bri on it.

---

Learnt from: KrX3D
Repo: wled/WLED PR: 4585
File: usermods/seven_segment_display_reloaded_v2/seven_segment_display_reloaded_v2.cpp:3-5
Timestamp: 2026-02-18T00:11:02.403Z
Learning: In PR `#4585`, the seven_segment_display_reloaded_v2 usermod intentionally uses `#error` to require MQTT (`#ifdef WLED_DISABLE_MQTT `#error` "This user mod requires MQTT to be enabled." `#endif``) because the integration flow has not been tested or validated without MQTT, and failing fast at compile time is preferred over allowing potentially broken builds until a full MQTT-optional refactor is completed.

[mik-laj]

@mikje Can you share diagnostics data for this device and device state?
Here is docs about diagnostics data:
https://www.home-assistant.io/integrations/diagnostics/#downloading-diagnostics
To get device data, you need to visit the page http://<DEVICE-IP>/json.

I'm wondering how you managed to set up an effect that has an ID identical to the RSVP effect.

[mikje]

{"state":{"on":true,"bri":35,"transition":7,"bs":0,"ps":-1,"pl":-1,"ledmap":0,"AudioReactive":{"on":false},"nl":{"on":false,"dur":60,"mode":1,"tbri":0,"rem":-1},"udpn":{"send":false,"recv":true,"sgrp":1,"rgrp":1},"lor":0,"mainseg":0,"seg":[{"id":0,"start":0,"stop":12,"len":12,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,160,0],[0,0,0],[0,0,0]],"fx":9,"sx":128,"ix":128,"pal":50,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":1,"start":0,"stop":12,"len":12,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":2,"start":1,"stop":12,"len":11,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":3,"start":2,"stop":12,"len":10,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":4,"start":3,"stop":12,"len":9,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":5,"start":4,"stop":12,"len":8,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":6,"start":5,"stop":12,"len":7,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":7,"start":6,"stop":12,"len":6,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":8,"start":7,"stop":12,"len":5,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":9,"start":8,"stop":12,"len":4,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":10,"start":9,"stop":12,"len":3,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":11,"start":10,"stop":12,"len":2,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0},{"id":12,"start":11,"stop":12,"len":1,"grp":1,"spc":0,"of":0,"on":true,"frz":false,"bri":255,"cct":127,"set":0,"lc":1,"col":[[255,180,0],[0,0,0],[0,0,0]],"fx":88,"sx":128,"ix":128,"pal":0,"c1":128,"c2":128,"c3":16,"sel":true,"rev":false,"mi":false,"o1":false,"o2":false,"o3":false,"si":0,"m12":0,"bm":0}]},"info":{"ver":"16.0.0","vid":2605030,"cn":"Niji","release":"ESP8266","repo":"wled/WLED","deviceId":"b26ccbf216c8f702609dfda784d9df087ef513ce5a","leds":{"count":12,"pwr":113,"fps":43,"maxpwr":1080,"maxseg":16,"bootps":8,"seglc":[1,1,1,1,1,1,1,1,1,1,1,1,1],"lc":1,"rgbw":false,"wv":0,"cct":0},"str":false,"name":"WLED_regenmini","udpport":21324,"simplifiedui":false,"live":false,"liveseg":-1,"lm":"","lip":"","ws":1,"fxcount":220,"palcount":72,"cpalcount":0,"umpalcount":0,"cpalmax":10,"maps":[{"id":0}],"wifi":{"bssid":"E4:38:83:72:9A:16","rssi":-58,"signal":84,"channel":1,"ap":false},"fs":{"u":57,"t":1024,"pmt":0},"ndc":2,"arch":"esp8266","core":"3.1.2","clock":80,"flash":4,"lwip":2,"freeheap":16936,"uptime":87170,"time":"1970-1-2, 00:12:50","um":[32],"u":{"AudioReactive":["<button class=\"btn btn-xs\" onclick=\"requestJson({AudioReactive:{enabled:true}});\"><i class=\"icons off\">&#xe08f;</i></button>"]},"opt":79,"brand":"WLED","product":"FOSS","mac":"e89f6d93f498","ip":"192.168.0.42"},"effects":["Solid","Blink","Breathe","Wipe","Wipe Random","Random Colors","Sweep","Dynamic","Colorloop","Rainbow","Scan","Scan Dual","Fade","Theater","Theater Rainbow","Running","Saw","Twinkle","Dissolve","Dissolve Rnd","Sparkle","Sparkle Dark","Sparkle+","Strobe","Strobe Rainbow","Strobe Mega","Blink Rainbow","Android","Chase","Chase Random","Chase Rainbow","Chase Flash","Chase Flash Rnd","Rainbow Runner","Colorful","Traffic Light","Sweep Random","Chase 2","Aurora","Stream","Scanner","Lighthouse","Fireworks","Rain","Tetrix","Fire Flicker","Gradient","Loading","Rolling Balls","Fairy","Two Dots","Fairytwinkle","Running Dual","RSVD","Chase 3"]}

[mikje]

config_entry-wled-01JMAEAFDKE41E06ARNY7VC3T6.json

[softhack007]

"effects":["Solid","Blink","Breathe","Wipe","Wipe Random","Random Colors","Sweep","Dynamic","Colorloop","Rainbow","Scan","Scan Dual","Fade","Theater","Theater Rainbow","Running","Saw","Twinkle","Dissolve","Dissolve Rnd","Sparkle","Sparkle Dark","Sparkle+","Strobe","Strobe Rainbow","Strobe Mega","Blink Rainbow","Android","Chase","Chase Random","Chase Rainbow","Chase Flash","Chase Flash Rnd","Rainbow Runner","Colorful","Traffic Light","Sweep Random","Chase 2","Aurora","Stream","Scanner","Lighthouse","Fireworks","Rain","Tetrix","Fire Flicker","Gradient","Loading","Rolling Balls","Fairy","Two Dots","Fairytwinkle","Running Dual","RSVD","Chase 3"]}

I'm wondering why the "effects":[ list from /json ends with "Chase 3" 🤔 @willmmiles is this expected on 8266?

[mik-laj]

cat tests/components/wled/Untitled-1.json | jq '.effects |to_entries | map({name:.value, index:.key}) '

[
  {
    "name": "Solid",
    "index": 0
  },
  {
    "name": "Blink",
    "index": 1
  },
  {
    "name": "Breathe",
    "index": 2
  },
  {
    "name": "Wipe",
    "index": 3
  },
  {
    "name": "Wipe Random",
    "index": 4
  },
  {
    "name": "Random Colors",
    "index": 5
  },
  {
    "name": "Sweep",
    "index": 6
  },
  {
    "name": "Dynamic",
    "index": 7
  },
  {
    "name": "Colorloop",
    "index": 8
  },
  {
    "name": "Rainbow",
    "index": 9
  },
  {
    "name": "Scan",
    "index": 10
  },
  {
    "name": "Scan Dual",
    "index": 11
  },
  {
    "name": "Fade",
    "index": 12
  },
  {
    "name": "Theater",
    "index": 13
  },
  {
    "name": "Theater Rainbow",
    "index": 14
  },
  {
    "name": "Running",
    "index": 15
  },
  {
    "name": "Saw",
    "index": 16
  },
  {
    "name": "Twinkle",
    "index": 17
  },
  {
    "name": "Dissolve",
    "index": 18
  },
  {
    "name": "Dissolve Rnd",
    "index": 19
  },
  {
    "name": "Sparkle",
    "index": 20
  },
  {
    "name": "Sparkle Dark",
    "index": 21
  },
  {
    "name": "Sparkle+",
    "index": 22
  },
  {
    "name": "Strobe",
    "index": 23
  },
  {
    "name": "Strobe Rainbow",
    "index": 24
  },
  {
    "name": "Strobe Mega",
    "index": 25
  },
  {
    "name": "Blink Rainbow",
    "index": 26
  },
  {
    "name": "Android",
    "index": 27
  },
  {
    "name": "Chase",
    "index": 28
  },
  {
    "name": "Chase Random",
    "index": 29
  },
  {
    "name": "Chase Rainbow",
    "index": 30
  },
  {
    "name": "Chase Flash",
    "index": 31
  },
  {
    "name": "Chase Flash Rnd",
    "index": 32
  },
  {
    "name": "Rainbow Runner",
    "index": 33
  },
  {
    "name": "Colorful",
    "index": 34
  },
  {
    "name": "Traffic Light",
    "index": 35
  },
  {
    "name": "Sweep Random",
    "index": 36
  },
  {
    "name": "Chase 2",
    "index": 37
  },
  {
    "name": "Aurora",
    "index": 38
  },
  {
    "name": "Stream",
    "index": 39
  },
  {
    "name": "Scanner",
    "index": 40
  },
  {
    "name": "Lighthouse",
    "index": 41
  },
  {
    "name": "Fireworks",
    "index": 42
  },
  {
    "name": "Rain",
    "index": 43
  },
  {
    "name": "Tetrix",
    "index": 44
  },
  {
    "name": "Fire Flicker",
    "index": 45
  },
  {
    "name": "Gradient",
    "index": 46
  },
  {
    "name": "Loading",
    "index": 47
  },
  {
    "name": "Rolling Balls",
    "index": 48
  },
  {
    "name": "Fairy",
    "index": 49
  },
  {
    "name": "Two Dots",
    "index": 50
  },
  {
    "name": "Fairytwinkle",
    "index": 51
  },
  {
    "name": "Running Dual",
    "index": 52
  },
  {
    "name": "RSVD",
    "index": 53
  },
  {
    "name": "Chase 3",
    "index": 54
  }
]

cat tests/components/wled/Untitled-1.json | jq '.state.seg[].fx'
9
88
88
88
88
88
88
88
88
88
88
88
88

Now this doesn't look like a problem in the HA integration, but rather like a problem in the WLED firmware, because the effect (fx field) in the segments references an index that doesn't exist in the effects array.