Closed schmurtzm closed 5 months ago
fastled_base source fastled_base issues fastled_base recent changes (message by IssueLinks)
Yes, that is correct. Both fastled and remote transmitter use the same RMT peripheral in the ESP32, so they will clash if used together. Instead you can try neopixelbus with the i2s methods.
Thanks, I didn't know this problem about rmt driver. Neopixel could be an alternative but it impacts the quality of the communication with my i2c. With the actual version of esphome, if you use Neopixel with esp32, the esp32 can't connect to wifi anymore. You have to choose "bit bang" method or to force the update of the neopixel library to 2.6.x to use it successfully with i2s method.
But in all cases neopixelbus creates some instabilities on I2C : when I use neopixelbus my apds9960 gives often I2C errors (yes I have many i2c devices and my i2c cable is a little long but I don't have this problem when I use FastLed).
So I don't have the perfect solution for the moment.
There is no way to solve this problem with the rmt driver or an alternative way to drive an IR led with esp32 ?
fastled_clockless source fastled_clockless issues fastled_clockless recent changes (message by IssueLinks)
I'm also having this problem and would be very interested in a solution.
With the help of @ssieb I found an unstable workaround to get fastled_clockless
to kinda work with remote_transmitter
.
Using the add_define custom component, you can define FASTLED_ESP32_I2S
which will instruct the fastled_clockless
library to not use RMT allowing it to co-exist with the remote_transmitter
. When doing this the remote_transmitter
works as expected, but fastled_clockless
glitches enough to make it almost unusable.
To test this clone custom_components locally to ssieb_components
and include the following yaml:
external_components:
- source:
type: local
path: ssieb_components
components: [add_define]
add_define:
- name: "FASTLED_ESP32_I2S"
Since fastled_clockless
is so unstable in I2S mode I would not consider this a fix. A bad hack at best.
Same problem here: fasted + remote transmitter == fail
Same issue. Neopixelbus works good (with standard settings from the site).
likely the same issue as #2934, because fastled_clockless and remote_receiver/transmitter don't allow selecting which RMT channel to use. neopixelbus by default chooses channel 1, which doesn't clash with the default channel 0 of the others.
I just ran into this bug, and it was very difficult to figure out what was going on. Would it be possible to add a check to the YAML parser when these two integrations are combined since this is a known bug?
This is also possibly related to https://github.com/esphome/issues/issues/3463 if the Ethernet or NTP integrations use RMT channel 0.
With the recent addition of the ESP32 RMT LED Strip component, we can now specify alternate RMT channels for the LEDs to use so that they don't conflict with the remote_transmitter
on RMT channel 0.
Switching my LEDs to use esp32_rmt_led_strip
instead of fastled_clockless
fixed this issue.
Example yaml:
- platform: esp32_rmt_led_strip
internal: true
chipset: WS2812
pin: GPIO26
num_leds: 120
rgb_order: GRB
id: bed_head_light_strip
name: Head LEDs
restore_mode: ALWAYS_OFF
rmt_channel: 1
- platform: esp32_rmt_led_strip
chipset: WS2812
internal: true
pin: GPIO27
num_leds: 90
rgb_order: GRB
id: bed_foot_light_strip
name: Foot LEDs
restore_mode: ALWAYS_OFF
rmt_channel: 2
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Hass.io ESP (ESP32/ESP8266, Board/Sonoff):
ESP32-WROOM-32D
ESPHome version (latest production, beta, dev branch)
ESPHome v1.16.2
Affected component:
fastled_clockless + remote_transmitter
Description of problem: Calling remotetransmitter.transmit*, while having the fastled component, crashes the ESP 32. The leds does not need to be on. Logs below. Problem very similar to #1059
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried:
Removing the fastled_clockless section and the IR is OK without any crash.. Good to know : the IR signal is really sent just before the crash.