Closed rpatel3001 closed 6 months ago
I was able to work around this issue by creating 2 dummy transmitters to fill up the TX only channels before the receiver gets a channel allocated.
I've just found that this workaround doesn't work with the neopixelbus component (FastLED works with some changes). The neopixel light is setup before the dummy transmitter regardless of the YAML order, so the dummy transmitter reconfigures the RMT channel.
At a minimum the auto channel selection needs to take the channel restrictions into account, and allowing users to choose which RMT channel to use in the YAML file would be useful.
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.
not stale
Hi, Same problem here. Adding 2 dummy transmitters makes the remote_receiver work, but breaks the Neopixel bus.
@rpatel3001 For the time being I've created a quick hack in a separate repository to work around this issue. https://github.com/Jorre05/remote_receiver
I have same problem, this is not stale :-)
Same problem.
@rpatel3001 For the time being I've created a quick hack in a separate repository to work around this issue. https://github.com/Jorre05/remote_receiver
For those of you using an ESP32-S3, channel 2 as suggested in @Jorre05 's github solution does not work, but try using a higher channel, as per the documentation:
The RMT module has eight channels, numbered from zero to seven. Each channel is able to independently transmit or receive signals. • Channel 0 ~ 3 (TX channel) are dedicated to sending signals. • Channel 4 ~ 7 (RX channel) are dedicated to receiving signals.
I used channel 7 (8) and it began working.
Thanks @Jorre05 !
@RENOxDECEPTION Thanks for the update. I've updated the README accordingly
I made short video showcasing the problem. If i find free time i will try to implement something similar in remote_receiver and remote_transmitter like in NeoPixelBus component.
I really thing that this can be fixed in few days max. I just don't have ESP32-S3 for testing.
I think I'm experiencing the same issue with ESP32 (8 RMT channels). The project I'm working on requires 3x IR receivers and up to 5x IR transmitters (I could reduce transmitters if necessary). Using @Jorre05's repo I've got the receivers loading correctly but it's auto-assigning channels 9 - 13 for the transmitters which is obviously failing. Really need to be able to specify the channels for the transmitter component also.
[20:49:33][C][remote_transmitter:015]: Remote Transmitter...
[20:49:33][C][remote_transmitter:016]: Channel: 9
[20:49:33][C][remote_transmitter:017]: RMT memory blocks: 255
[20:49:33][C][remote_transmitter:018]: Clock divider: 80
[20:49:33][C][remote_transmitter:019]: Pin: GPIO5
[20:49:33][C][remote_transmitter:022]: Carrier Duty: 50%
[20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
[20:49:33][C][remote_transmitter:015]: Remote Transmitter...
[20:49:33][C][remote_transmitter:016]: Channel: 10
[20:49:33][C][remote_transmitter:017]: RMT memory blocks: 254
[20:49:33][C][remote_transmitter:018]: Clock divider: 80
[20:49:33][C][remote_transmitter:019]: Pin: GPIO4
[20:49:33][C][remote_transmitter:022]: Carrier Duty: 50%
[20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
[20:49:33][C][remote_transmitter:015]: Remote Transmitter...
[20:49:33][C][remote_transmitter:016]: Channel: 11
[20:49:33][C][remote_transmitter:017]: RMT memory blocks: 253
[20:49:33][C][remote_transmitter:018]: Clock divider: 80
[20:49:33][C][remote_transmitter:019]: Pin: GPIO16
[20:49:33][C][remote_transmitter:022]: Carrier Duty: 50%
[20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
[20:49:33][C][remote_transmitter:015]: Remote Transmitter...
[20:49:33][C][remote_transmitter:016]: Channel: 12
[20:49:33][C][remote_transmitter:017]: RMT memory blocks: 252
[20:49:33][C][remote_transmitter:018]: Clock divider: 80
[20:49:33][C][remote_transmitter:019]: Pin: GPIO15
[20:49:33][C][remote_transmitter:022]: Carrier Duty: 50%
[20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
[20:49:33][C][remote_transmitter:015]: Remote Transmitter...
[20:49:33][C][remote_transmitter:016]: Channel: 13
[20:49:33][C][remote_transmitter:017]: RMT memory blocks: 251
[20:49:33][C][remote_transmitter:018]: Clock divider: 80
[20:49:33][C][remote_transmitter:019]: Pin: GPIO14
[20:49:33][C][remote_transmitter:022]: Carrier Duty: 50%
[20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
@Nixmaster2000
This issue is very specific to the ESP32-C3 variant, which has only 2 receive and 2 transmit channels. Don't use the custom repo for the original ESP32
On Thu, 5 Jan 2023, 22:12 nixmaster2000, @.***> wrote:
I think I'm experiencing the same issue with ESP32 (8 RMT channels). The project I'm working on requires 3x IR receivers and up to 5x IR transmitters (I could reduce transmitters if necessary). Using @Jorre05 https://github.com/Jorre05's repo I've got the receivers loading correctly but it's auto-assigning channels 9 - 13 for the transmitters which is obviously failing. Really need to be able to specify the channels for the transmitter component also.
[20:49:33][C][remote_transmitter:015]: Remote Transmitter... [20:49:33][C][remote_transmitter:016]: Channel: 9 [20:49:33][C][remote_transmitter:017]: RMT memory blocks: 255 [20:49:33][C][remote_transmitter:018]: Clock divider: 80 [20:49:33][C][remote_transmitter:019]: Pin: GPIO5 [20:49:33][C][remote_transmitter:022]: Carrier Duty: 50% [20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG [20:49:33][C][remote_transmitter:015]: Remote Transmitter... [20:49:33][C][remote_transmitter:016]: Channel: 10 [20:49:33][C][remote_transmitter:017]: RMT memory blocks: 254 [20:49:33][C][remote_transmitter:018]: Clock divider: 80 [20:49:33][C][remote_transmitter:019]: Pin: GPIO4 [20:49:33][C][remote_transmitter:022]: Carrier Duty: 50% [20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG [20:49:33][C][remote_transmitter:015]: Remote Transmitter... [20:49:33][C][remote_transmitter:016]: Channel: 11 [20:49:33][C][remote_transmitter:017]: RMT memory blocks: 253 [20:49:33][C][remote_transmitter:018]: Clock divider: 80 [20:49:33][C][remote_transmitter:019]: Pin: GPIO16 [20:49:33][C][remote_transmitter:022]: Carrier Duty: 50% [20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG [20:49:33][C][remote_transmitter:015]: Remote Transmitter... [20:49:33][C][remote_transmitter:016]: Channel: 12 [20:49:33][C][remote_transmitter:017]: RMT memory blocks: 252 [20:49:33][C][remote_transmitter:018]: Clock divider: 80 [20:49:33][C][remote_transmitter:019]: Pin: GPIO15 [20:49:33][C][remote_transmitter:022]: Carrier Duty: 50% [20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG [20:49:33][C][remote_transmitter:015]: Remote Transmitter... [20:49:33][C][remote_transmitter:016]: Channel: 13 [20:49:33][C][remote_transmitter:017]: RMT memory blocks: 251 [20:49:33][C][remote_transmitter:018]: Clock divider: 80 [20:49:33][C][remote_transmitter:019]: Pin: GPIO14 [20:49:33][C][remote_transmitter:022]: Carrier Duty: 50% [20:49:33][E][remote_transmitter:026]: Configuring RMT driver failed: ESP_ERR_INVALID_ARG
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/2934#issuecomment-1372140163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHOR6RCMYO6SYDWCOO4XT3WQ23BTANCNFSM5L2WGMPA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I guess I'd like to report that auto channel assignment is also not working properly with the original ESP32 as channels 9 through 13 aren't valid choices either.
how to chose the transmit channels of the esp32c3? The system auto slect the transmit channels 3, report error
I used @Jorre05 guide but on an m5 atom s3, it threw an error but I picked channel 4 and it worked perfectly. I wish this was fixed in the core platform.
external_components:
- source: github://Jorre05/remote_receiver
components: [ remote_receiver ]
remote_receiver:
pin:
number: GPIO1
inverted: true
rmt_channel: 4
dump: all
how to chose the transmit channels of the esp32c3? The system auto slect the transmit channels 3, report error
Make them unavailable by using another components if you have ram/flash/pins to waste or change the order of components in yaml code
@nixmaster2000 This issue is very specific to the ESP32-C3 variant, which has only 2 receive and 2 transmit channels. Don't use the custom repo for the original ESP32
That is not correct. This issue still exists and also affects ESP-S3 variants, and possibly others.
Wow many thanks!
Using external component from github://Jorre05/remote_receiver worked for me. I replaced a Tuya CBU module with a esp8685-wroom-06 in a S16 Smart Remote IR Controller and now it's working.
Here's the config just in case someone needs it.
external_components:
- source: github://Jorre05/remote_receiver
components: [ remote_receiver ]
substitutions:
devicename: ir-livroom
upper_devicename: AC livroom
esphome:
name: ir-livroom
friendly_name: ir-livroom
esp32:
board: esp32-c3-devkitm-1
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$"
ota:
password: "$$$$$$$$$$$$$$$$$$$$$$"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Ir-Livroom Fallback Hotspot"
password: "$$$$$$$$$$$$"
captive_portal:
web_server:
port: 80
remote_transmitter:
pin: GPIO7
carrier_duty_percent: 30%
remote_receiver:
id: rcvr
pin:
number: GPIO3
inverted: True
rmt_channel: 2
tolerance: 55%
dump: all
climate:
- platform: daikin
name: "$upper_devicename Living AC"
receiver_id: rcvr
Thanks @Jorre05 for the fix @pbadmin can your device boot up if you're using esp-idf framework? mine didn't
Thanks @Jorre05 for the fix @pbadmin can your device boot up if you're using esp-idf framework? mine didn't
@ferbulous I'm using ESPhome plugin from HASSIO (HomeAssistant OS)
Thanks @Jorre05
I also needed this feature for remote_transmitter
If anyone else needs it, it is available here:
https://github.com/predam/remote_transmitter
The Jorre05 workaround seems to have broken on_XXXX calls from the device for me (for IR Receive anyway). Anyone else experiencing this? I have an on_magiquest callout to a homeassistant service I was trying to set up for my kids after gong to Great Wolf Lodge. I have this working on an ESP8266 device (or did....haven't tested recently) but M5Atoms don't work. I'll get the ir magiquest output in the logs, but no event call.
@Jorre05, @predam have you tried upstreaming the fixes? Is there a PR?
@Jorre05, @predam have you tried upstreaming the fixes? Is there a PR?
No, I did a quick and dirty fix to get my receiver working. A proper implementation that works for other variants is a lot more work. My fix may even break other things that I'm not aware of.
I too used the workaround suggested by rpatel3001. For my specific use case, there is an ESP32-C3 SuperMini (AliExpress) with one IR transmitter and one IR receiver (HX1838). I added a "dummy" transmitter along with the actual transmitter before the receiver. My configuration YAML is below in case you to struggle with that aspect.
remote_transmitter:
- id: IR_LED
pin: GPIO8
# infrared remotes use a 50% carrier signal
carrier_duty_percent: 50%
- id: dummy_1
pin: GPIO9
# infrared remotes use a 50% carrier signal
carrier_duty_percent: 50%
remote_receiver:
pin:
number: GPIO7
inverted: true
dump: raw
The latest ESPHome release contains a PR ( https://github.com/esphome/esphome/pull/6497 ) that seems to fix this issue for me.
The problem
I'm trying out the M5Stack IR receiver/transmitter combo. Setting up the receiver to dump all received messages fails to set up the RMT peripheral. I have a hunch it's related to the channel selection, as the config dump shows channel 0, but the docs say 0/1 are TX only and 2/3 are RX only. I tried this on both GPIO1 and GPIO19 (the pins broken out onto Grove connectors on this board).
Which version of ESPHome has the issue?
2021.12.3
What type of installation are you using?
Docker
Which version of Home Assistant has the issue?
n/a
What platform are you using?
ESP32-IDF
Board
M5Stack Stamp C3
Component causing the issue
remote_receiver
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response