esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 35 forks source link

ESP32 + fastled_clockless + remote_transmitter -> crash when using "remote_transmitter.transmit" #1973

Closed schmurtzm closed 5 months ago

schmurtzm commented 3 years ago

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:


# ========================= IR Remote Buttons =========================
  - platform: template
    name: "IR test 1"
    turn_on_action:
    - remote_transmitter.transmit_jvc:
        data: 0x10EF

# ========================= Lights  =========================  
light:
  - platform: fastled_clockless
    chipset: WS2812
    pin: GPIO17
    num_leds: 4
    rgb_order: GRB
    name: "Myleds"

# ========================= IR =========================  
remote_transmitter:
    pin: GPIO4
    carrier_duty_percent: 50%

Logs (if applicable):

[1B][0;36m[D][switch:021]: 'IR test 1' Turning ON.[1B][0m
[1B][0;36m[D][esp-idf:000]: E (1268331) rmt: rmt_driver_install(725): RMT driver already installed for channel
[1B][0m
[1B][1;31m[E][component:092]: Component was marked as failed.[1B][0m
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x400e2bad  PS      : 0x00060031  A0      : 0x8008536d  A1      : 0x3ffbe770  
A2      : 0x00000000  A3      : 0x3ffc14e8  A4      : 0x00000000  A5      : 0x00060021  
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3ffbe770  
A10     : 0x00000003  A11     : 0x00060023  A12     : 0x00060021  A13     : 0x00000000  
A14     : 0x00060023  A15     : 0x00000000  SAR     : 0x0000001a  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000001c  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  
Core 1 was running in ISR context:
EPC1    : 0x400e2bad  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40087179

Backtrace: 0x400e2bad:0x3ffbe770 0x4008536a:0x3ffbe7a0 0x40084af5:0x3ffbe7d0 0x40166347:0x3ffbc5d0 0x400f12be:0x3ffbc5f0 0x4008b5e9:0x3ffbc610 0x40089e05:0x3ffbc630

Rebooting...

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.

probot-esphome[bot] commented 3 years ago

fastled_base source fastled_base issues fastled_base recent changes (message by IssueLinks)

OttoWinter commented 3 years ago

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.

schmurtzm commented 3 years ago

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 ?

probot-esphome[bot] commented 3 years ago

fastled_clockless source fastled_clockless issues fastled_clockless recent changes (message by IssueLinks)

lanrat commented 3 years ago

I'm also having this problem and would be very interested in a solution.

lanrat commented 3 years ago

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.

cromulus commented 3 years ago

Same problem here: fasted + remote transmitter == fail

riclun80 commented 3 years ago

Same issue. Neopixelbus works good (with standard settings from the site).

rpatel3001 commented 2 years ago

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.

DaAwesomeP commented 2 years ago

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?

DaAwesomeP commented 2 years ago

This is also possibly related to https://github.com/esphome/issues/issues/3463 if the Ethernet or NTP integrations use RMT channel 0.

lanrat commented 1 year ago

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
rpatel3001 commented 5 months ago

closed by https://github.com/esphome/esphome/pull/6497