Why is rc_switch_raw data not being matched to my binary_sensor?

ESPHome
1

hey! I just did the HW mod on a Sonoff RF Bridge since it didn’t catch all RF signals flying around my house. I did setup one device already, but I’m struggeling to get esphome to do anything useful with my second device: It’s a door sensor that send open and closed codes: The closed received code is:

[01:16:16][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1001010101101001011010100110100110010101011010010110101001101001'

Open:

[01:17:22][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=8 data='1001010101101001011010010110100110010101011010010110100101101001'

This is the .yaml for one of the codes received:

  - platform: remote_receiver
    id: pardorr_vrum_open
    internal: true
    rc_switch_raw:
      code: '1001010101101001011010010110100110010101011010010110100101101001'
      protocol: 8
    filters:
      delayed_off: 100ms

Second one is just different code. I made a template, but it´s not recognized after upload, still shows the original received RCSwitch Raw Here´s the template:

  - platform: template
    name: Pardörr Vardagsrum
    device_class: door
    lambda: |-
      if (id(pardorr_vrum_open).state) {
        return true;
      } else if (id(pardorr_vrum_closed).state) {
        return false;
      } else {
        return {};
      }

If anyone has any idea why, please let me know

1 Like
2

I have exactly the same problem with rc_switch_raw protocol 8. At the same time rc_switch_raw protocol 1 works perfectly…

1 Like
3

Hmm… OK, do you also have nice and neat readings of the codes? Most of the time, my received codes are close to perfect, with close to no incomplete codes. If that’s the case for you aswell, then I’m guessing it’s a problem when matching these codes to the definitions in esphome?

I’m pinging @OttoWinter and hoping that maybe he can find some time to take a look?

4

Yes, exactly, it all looks perfect. My protocol 8 codes are actually exactly the same length as yours, so I’m pretty sure it is the same problem. And by checking the same binary sensor code with the other RF-switch I have (rc_switch_raw, protocol 1) I have excluded a problem in my YAML code.

5

Same problem here using a Sonoff basic RF (receiver soldered directly to ESP8266 pin; commands from my garage door opener are received and can be read in the log without problems):

[15:32:53][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=1 data='0010110010010110101101100100000000101100'
[15:32:53][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=1 data='1010110011100010011011111111101110101100111000100110111111111011'
[15:32:53][D][remote.rc_switch:243]: Received RCSwitch Raw: protocol=1 data='1010110011100010011011111111101110101100111000100110111111111011'

(I’m using the second code only and discarding the first one as it appears unreliable)

and the corresponding binary_sensor:

binary_sensor:

  - platform: remote_receiver
    id: receive_on
    name: "Switch 1 (RF-On)"
    internal: true
    on_press:
      then:
      - switch.turn_on: relay
      - light.turn_on: led
    rc_switch_raw:
      code: '1010110011100010011011111111101110101100111000100110111111111011'
      protocol: 1

nothing happens when I press my remote button, although the received command appears just like in the binary sensor in the log.

6

Seems that the length of the received code is the common thing for the issue we’re having since you have the code received using protocol 1

7

Strangely it appears it also doesn’t work if I only scan for a randomly picked shorter subset of the entire binary code (not sure if this is a valid way of using this integration). Is it useful to file for a bug report or is this thread sufficient to get the attention from the developers?

8

I just checked, and there is already a great post over at github

1 Like
9

I know this is an old post, but it’s still unresolved so I’ll continue here, I too tested with my garage remote that also reports a long code in protocol 1 ‘1111110110000001101100010101110111111101100000011011000101011101’

Same issue as you botch on protocol 1 as on protocol 8. I have other 433 devices that use protocol 1, shorter codes ‘101010100100001010000110’ that work just fine.

Has anyone tried using the raw dump?