fastled_clockless flickering when using addressable_lambda

[Tyde]

The problem

I am using the fastled_clockless platform with a WS2812B chipset on both esp32 and esp8266. With both devices I get the following issue:

Let's assume I use the following minimal example

esphome:
  name: ledstrip-particle

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: ""

ota:
  password: ""

wifi:
  ssid: <redacted>
  password: <redacted>

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Ledstrip-Particle"
    password: "geAqcpjv3Ogv"

captive_portal:

light:
  - platform: fastled_clockless
    chipset: WS2812B
    pin: GPIO23
    num_leds: 149
    rgb_order: GRB
    name: "FastLED WS2811 Light"
    gamma_correct: 1.0
    effects: 
      - addressable_lambda: 
          name: "issue"
          update_interval: 10ms
          lambda: |-
            auto basecolor = esphome::Color(10, 7, 3);
            it.all()=basecolor;
      - addressable_lambda: 
          name: "issue high"
          update_interval: 10ms
          lambda: |-
            auto basecolor = esphome::Color(40, 28, 12);
            it.all()=basecolor;

When I use the light without the addressable_lambda effects the light is stable and doesnt flicker. As soon as I activate one of the effects, I see a noticable flickering in the lights. To investigate the issue I connected my Logic Analyzer and got the following data for the effect issue

It is clearly visible, that somehow the constant color value that I set at the output gets modified and about every second time there is an addition of 1 happening in the output values, which results in the flickering. If we just look at one pixel index we can also see that the values do change over time:

This is mostly visible at low values, but looking at the data, this issue also happens when I set higher Color values. It just isn't as noticeable to the eye.

This issue is not happening, when I just set the light with home assistant, as It just sets the light once and then does not send out any data anymore until I change the color in home assistant again.

Which version of ESPHome has the issue?

2021.12.3

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

2021.12.5

What platform are you using?

ESP32

Board

esp32doit-devkit-v1

Component causing the issue

fastled

Example YAML snippet

esphome:
  name: ledstrip-particle

esp32:
  board: esp32doit-devkit-v1
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: ""

ota:
  password: ""

wifi:
  ssid: <redacted>
  password: <redacted>

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Ledstrip-Particle"
    password: "geAqcpjv3Ogv"

captive_portal:

light:
  - platform: fastled_clockless
    chipset: WS2812B
    pin: GPIO23
    num_leds: 149
    rgb_order: GRB
    name: "FastLED WS2811 Light"
    gamma_correct: 1.0
    effects: 
      - addressable_lambda: 
          name: "issue"
          update_interval: 10ms
          lambda: |-
            auto basecolor = esphome::Color(10, 7, 3);
            it.all()=basecolor;
      - addressable_lambda: 
          name: "issue high"
          update_interval: 10ms
          lambda: |-
            auto basecolor = esphome::Color(40, 28, 12);
            it.all()=basecolor;

Anything in the logs that might be useful for us?

No response

Additional information

No response

[martgras]

Do you see the flickering with update_interval: 1s ? 10ms might be too fast

[Tyde]

Yes the issue persists with an update_interval: 1s The difference is now, that it of course only updates every second.

It is also visible in this video: https://nextcloud.danielthiem.eu/s/pZ3s9x2eSBMkmrf

[martgras]

I know this is more trial & error but I had issues as well a few weeks ago. Can't remember the exact details but I ended up using neopixelbus instead of fastled and switched from SPI (default) to RMT mode It's used to visualize air quality on a 8x4 Stick As you can see I also tested a couple of variants - or maybe I just don't notice the flickering :)

light:
  - platform: neopixelbus
    #platform: fastled_clockless
    type: GRB
    variant: WS2812
    method: ESP32_RMT_0
    #chipset: WS2812
    #rgb_order: GRB
    color_correct: [75%, 75%, 75%]
    restore_mode: ALWAYS_ON
    num_leds: 32
    name: "NeoPixel Light"
    id: neostick
    pin: 25

display:
  - platform: addressable_light
    id: led_matrix_display
    addressable_light_id: neostick
    width: 8
    height: 4
    update_interval: 5s
    lambda: |-
      static uint8_t last_iaq ;
       ....

These issues can be hard to track down as most of the functionality is in the underlying libraries (neopixel, fasted) and we have to isolate if it's due to the libraries or a esphome issue

[Tyde]

Indeed, neopixel seems to not show that issue:

Still it would be intersting to find out the cause of the issue with fastled

[martgras]

my guess is that RMT instead of SPI makes the difference. If that theory is correct you should be able to repro with neopixel if you use SPI again

[Tyde]

Tell me if I am misinterpreting this, but isn't the WS2812 clockless? Doen't that mean that I would not be using SPI in any of these libraries?

Also the code I initially found the issue with I originally wrote with just the FastLED library without esphome. There this flickering issue is not present. Somehow with the interaction with esphome this problem appeared.

[martgras]

Can't answer your question completely. From browsing over the code I'd say SPI is the default for ESP32 https://github.com/esphome/esphome/blob/f0b183a55276c512af1d06c2d41db04afc12b94f/esphome/components/neopixelbus/light.py#L98

[OttoWinter]

Precisely because the chips are clockless small differences in the timing lead to different data being interpreted (flickering).

Yeah neopixelbus nowadays seems to support better transmission methods for both esp32 and esp8266.

Not sure where you get SPI from @martgras , the link you posted shows that i2s (not spi) is the default. Indeed the SPI interface is only used for chips with an additional clock signal.

[martgras]

Thanks Otto for the clarification. Mixed up i2s and spi My observations were only from trial and error. RMT was the best option for my setup

[Tyde]

Precisely because the chips are clockless small differences in the timing lead to different data being interpreted (flickering).

I am having a bit trouble following here: If you look at the timing in my examples, you can see, that (to me) this seems unlikely due to misinterpretations of timings. (Datasheet for WS2812B)

1. The timings are all very regular (e.g T1H is always 750 ns T01 is always 250 ns and TH+TL is consistently at 1.25 µs)
2. The "error" I see is not caused by some singular bits flipping but rather the values are either correct or +1 (See the difference @ the green channel: 7 is 0b00000111 and 8 is 0b00001000, so 4 bits have flipped)

This would lead me to the assumption that it is rather a issue with the values set not being correct or being manipulated (Also I don't see the issue when I am just using the FastLED library without esphome). Correct me if I am wrong, please.

[OttoWinter]

Hmm yeah that is interesting. I agree that 0b00000111 -> 0b00001000 difference would be hard to explain with just bad timings.

Then again I can't really see how this could be directly due to the ESPHome addressable light code, as the problematic bits (color/gamma correction etc) are all done in the addressable light base, and so would affect both components. Perhaps it's a weird interaction with how ESPHome uses fastled, but unsure; Given there's a good alternative with neopixelbus that even has more features I won't look into this much further, but might be interesting to investigate.

The relevant lines are:

• https://github.com/esphome/esphome/blob/2a84db7f850e49994852e410487bbc45c01bfe80/esphome/components/fastled_base/fastled_light.h#L227-L230
• https://github.com/esphome/esphome/blob/2a84db7f850e49994852e410487bbc45c01bfe80/esphome/components/fastled_base/fastled_light.cpp#L37
• and for neopixelbus https://github.com/esphome/esphome/blob/2a84db7f850e49994852e410487bbc45c01bfe80/esphome/components/neopixelbus/neopixelbus_light.h#L123-L127
• https://github.com/esphome/esphome/blob/2a84db7f850e49994852e410487bbc45c01bfe80/esphome/components/neopixelbus/neopixelbus_light.h#L92)

[martgras]

Neopixelbus seems to be the better alternative. FWIW I tried upgrading to fastled 3.4/3.5 and it doesn't work at all on my M5 Atom matrix. It doesn't crash anymore as with 3.3 but somehow RMT is not working anymore. Using i2s works with 3.5 But I don't understand fastled well enough to find the reason

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.