ESPHome remote_transmitter.transmit_rc_switch_raw returns Pronto instead of code

Hi there!

I recently started working with ESPHome and built a couple of sensors myself. Works fine so far thanks to the great documentation!

Currently I want to smarten up a couple of older devices (One of my stereos and a Fan). They work with IR Remotes and I’ve built a quick prototype with an ESP32 with an IR Receiver and Transmitter (Transmitter unfortunately only works in a very short distance).

The setup works fine as it can read any command and send them via my transmitter. Unfortunately I have a problem with my Fan which uses generic RCSwitch Raw output.

I can read the code of the remote
[19:20:45][D][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11011000000',

but sending it and receiving it again gives me this received information:
[19:21:27][D][remote.pronto:229]: Received Pronto: data=0000 006D 0002 0000 0003 00D3 0005 06C3

Which doesn’t work for my fan.

All commands works except the RCSwitch Raw ones. This is the code I use to send them:

button:
  - platform: template
    name: "Off Fan"
    on_press:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '11011000000'
          protocol: 1

In case it is relevant, here is the code for the Receiver:

remote_receiver:
  pin:
    number: GPIO22
    inverted: true
    mode:
      input: true
      pullup: true
  dump: all

Is there a mistake I am not seeing? Thanks a lot in advance! :slight_smile:

remote_receiver:
  - id: rc_receiver
    pin:
      number: GPIO22
      inverted: True
    dump: rc_switch
    tolerance: 60%
    filter: 250us
    idle: 4ms
    buffer_size: 2kb
remote_transmitter:
  pin: D8
  # RF uses a 100% carrier signal
  carrier_duty_percent: 100%
buttontemplate
    name: RFpirsensor Test Button
    #turn_on_action:
    on_press:
      - remote_transmitter.transmit_rc_switch_raw:
          transmitter_id: rc_transmitter
          code: '001111010010100100001101'
          protocol:
            inverted: false
            pulse_length: 181
          repeat:
            times: 10
            wait_time: 0s

Use dump: raw instead of dump: all

That should work. dump raw data.

Hello and thanks a lot for your help!

Unfortunately this doesn’t work for me. First of all I have IR and not RF, and secondly the buttontemplate does not work for me. I changed it to “- platform: template” and yet there is a problem with it compiling (Couldn’t find ID ‘rc_transmitter’).

Nonetheless using just the different remote receiver code and 100 percent for the transmitter, it looks different than before.

Pressing the Button of the original remote gives me this output from the receiver:

[21:52:25][D][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11011000000'

which is the same.
But sending it with the written command (from the original question), doesn’t give me any received Code.

Also this now does give me unvalid Raw codes for the previously working Remotes, but I guess this is because we only dump rc_switch:
[21:53:21][D][remote.rc_switch:261]: Received RCSwitch Raw: protocol=2 data='00000000000000000000000000000000'

I think the receiving side of this all works, but I have the feeling that I am sending the code in a wrong way?
Changing the dump to all again gives me the said pronto again.

Thanks for your help! :slight_smile:

Thank you for your help! While this does indeed dump all of the raw data, it still isn’t working the way I wished.

Sending the original “Off Fan” button action doesn’t give me any output at all and adding a different button like this:

  - platform: template
    name: "FAN RAW"
    on_press:
      - remote_transmitter.transmit_raw:
          code: [1252, -422, 416, -1261, 1251, -423, 1250, -423, 414, -1263, 416, -1263, 416, -1263, 415, -1264, 415, -1263, 416, -1263, 1251]

Doesn’t give the same output as the input either, thus doesn’t work on the fan :confused:

Am I missing something else?

Thanks so much for your help! Very appreciated!

@itspuia Sorry for the ping from the dead, any chance you figured this out? I’m having similar issues with a heater I just bought.

EDIT: Another strange realization - I have issues with the same rc_switch code: 11011000000. I actually just tested a few of the other buttons which include 11011000010 and 11011001000 and they both work just fine.

So much for dead posts being able to rest in peace… I hope your proud of yourself sir!

Something i’ve noticed when capturing rf codes is sometimes they arent fully captured and decoded so, 1 button press may return some string of say 6 characters while pushing it a second time may give me 8 characters now.

Sometimes you just have to capture the dame button multiple times and youll be able to see which code is complete and not a shortened version. The correct code is usually the one with the most digits and typically all the other buttons will have codes with the same number of digits so, one shouldnt be 6 numbers and another code is 10 numbers. The low one(6) is likely a bad reading.

Also, posting your logs would be helpful as well as details about the heater and it would seem like your config being visable here might be helpful too. The other option is you get to play guessing games with everyone…

Yeah, I’ve done a couple of these before and I’ve gotten all the other buttons working so I think I’m getting the right code. It’s an old “twin star home” infrared space heater. I think it’s something to do with the 11011000000 code which is why I posted here. I’ve actually seen a couple posts of people having issues with the same code which I find strange.

Here’s my yaml if you’d like a look, (base is a template with wifi/logger/etc all defined fyi). I’m only logging rc_switch as I didn’t get anything from the other protocols.

esphome:
  name: nursery-heater
  friendly_name: Nursery Heater

esp8266:
  board: esp01_1m

packages:
  base: !include
    file: templates/base.yaml
    vars:
      friendly_name: ${friendly_name}
    
remote_receiver:
  pin:
    number: GPIO2
    inverted: true
  dump: rc_switch

remote_transmitter:
  pin: GPIO4
  carrier_duty_percent: 50%

button:
  - platform: template
    name: "OnOff"
    on_press:
      - remote_transmitter.transmit_rc_switch_raw:
          code: "11011000010"
          protocol: 4
          repeat:
            times: 5
            wait_time: 0s


  - platform: template
    name: "Temp Up"
    on_press:
      - remote_transmitter.transmit_rc_switch_raw:
          code: "11011000000"
          protocol: 4
          repeat:
            times: 5
            wait_time: 0s

  - platform: template
    name: "Temp Down"
    on_press:
      - remote_transmitter.transmit_rc_switch_raw:
          code: "11011001000"
          protocol: 4
          repeat:
            times: 5
            wait_time: 0s

Here’s a log of me pressing the five buttons on my remote, then pressing my three template buttons in HA to send messages. The OnOff and TempDown buttons both do what they should on the heater, but Temp Up (the 11011000000 button) doesn’t do anything for some reason.

[19:02:48][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000000'
[19:02:49][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000001'
[19:02:50][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000010'
[19:02:51][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000100'
[19:02:52][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='11011001000'
[19:03:16][D][button:010]: 'OnOff' Pressed.
[19:03:16][D][remote_transmitter:075]: Sending remote code...
[19:03:16][W][component:237]: Component api took a long time for an operation (100 ms).
[19:03:16][W][component:238]: Components should block for at most 30 ms.
[19:03:16][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000010'
[19:03:28][D][button:010]: 'Temp Down' Pressed.
[19:03:28][D][remote_transmitter:075]: Sending remote code...
[19:03:28][W][component:237]: Component api took a long time for an operation (101 ms).
[19:03:28][W][component:238]: Components should block for at most 30 ms.
[19:03:28][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011001000'
[19:03:30][D][button:010]: 'Temp Up' Pressed.
[19:03:30][D][remote_transmitter:075]: Sending remote code...
[19:03:30][W][component:237]: Component api took a long time for an operation (100 ms).
[19:03:30][W][component:238]: Components should block for at most 30 ms.
[19:03:30][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=4 data='11011000000'

If you push temp up 3-4 times do you get the same code each time?

Yes sir, occasionally protocol swaps between 1 or 4, but always the same code. I’ve tried with both protocols as well, same results.

Also, I think I’ve got them right as they follow a similar pattern of being different by a single bit (as shown in the log)

You would have much higher changes for success if you just grab the raw timings without rc switch and resend it raw.

This is a proof that is’s neither.
Rc_switch protocols are not real protocols that manufacturers use. It’s just a list of 12 different timing patterns and Rc_switch is giving you the closest one even when it’s not matching.
Thankfully your device is coded to have huge tolerances, so it might accept incorrect signal if it’s fitting in these tolerances. Question of luck.

Just as a followup in case anyone else has similar issues. @Karosm was correct, the rc_switch protocols weren’t quite accurate enough for usage. I ended up setting up IrScrutinizer to capture the codes and it was detected as the “f12x” protocol. I copied the corresponding f12x → pronto codes from IrScrutinizer into esphome which worked properly!

I might have been able to copy the pronto codes directly from the esphome logs, but it’s difficult to tell how accurate they are/aren’t, and IrScrutinizer seemed to have a significant knowledge that helped with getting it correct.

Nice that you resolved it!
Since you had only one “problem” signal, you could grab the raw timings and repeat that or decode it manually.
I still haven’t tried irScrutinize, on my long time waiting list…