I am working on a project to have an ESP32S with WS2812B leds on each step of my staircase. I chose ESPhome running under HA in Docker to run the sequences with PIR sensors. The project has 796 LED’s in total that are split into 14 partitions (variable lenghts).
I am now working multiple days to get rid of the problems that I experience but can’t get my head around it. Basically, the created YAML file is functional with the fastled integration. Some chunks of the code (forget indentation, in YAML it is correct and it works):
light:
- platform: fastled_clockless
chipset: WS2812B
rgb_order: GRB
internal: true
pin: GPIO4
num_leds: 796
name: “staircase”
id: staircase
.# Creating 14 partitions for each step
.# LED strip WS2812B, total 796 LEDs
. # Step 1: 52 LEDS - LED 0 to LED 51
- platform: partition
name: “step1”
id: step1
internal: true
segments:
- id: staircase
from: 1
to: 50
etc.
.# Run light on from bottom to top
- id: lightdownup
then:
- light.turn_on:
id: step1
transition_length: !lambda |-
return id(transition);
brightness: !lambda |-
return id(brightness);
red: !lambda |-
return id(red);
green: !lambda |-
return id(green);
blue: !lambda |-
return id(blue);
- light.turn_on:
id: step2… etc,
Skipping further code as it doesn’t contribute to the problem.
To start, I do experience the well known flickering that has been described in many other topics. These glitches increase when either monitoring live with the ‘log’ function and when connected to HA via the API. Without, flickering is rather limited. Cause is to be found in interrupt issues as I see.
To solve that, I’ve tried to step to NeoPixelBus instead:
light:
- platform: neopixelbus
type: GRB
variant: WS2812X
method: ESP32_I2S_1
pin: GPIO4
num_leds: 796
name: “staircase”
id: staircase
However, it became clear to me that NeoPixelBus either or not combined with partitions screws up as soon as more than 350 LED’s are used.
I have ran endless attempts to fix these problems.
Played with different NeoPixelBus and FastLed libraries (not at the same time of course):
platformio_options:
lib_deps:
- NeoPixelBus@2.6.0 (by the way, the currently standard distrubution 2.5.7 doesn’t work at all)
(- AsyncTCP)
(- FastLED@3.4.0)
None of them solved the issue.
The final suggestion that I see around is playing with interrupt handling, such as including one of the following above the #include “FastLED.h” in fastled_light.h:
#define FASTLED_INTERRUPT_RETRY_COUNT
#define FASTLED_ALLOW_INTERRUPTS 0
Unfortunately it is not easy to do this as the subsequent libraries (in this case fastled_light.h) are overwritten each time when compiled with the one from the source base, which is somewhere out of the ESPHOME docker container.
So now after explaining I have some questions that somebody may be able to answer:
-
I prefer NeoPixelBus as it handles the output to the LED’s via DMA or other non-interrupt based method, which is a root solution. Would it be possible to address ~800 LED’s in the way described above flawlessly in an ESP32S with ESPhome? How?
-
If Fastled is the option left (which by itself functions, but with the glitches), how can I play with the abovementioned inclusion of the #defines for the fastled interrupts, I have no clue how to change the source base outside the HA ESPhome container.
-
Any other solution would be welcome, if you need additional info, please phrase as I am out of creativity here…
1 post - 1 participant
Read full topic
I’ve got something complicated and it’s working but neither of these ways.