Remote Receiver no longer dumps 'rc_switch' to log when using 'on_rc_switch' automation

[mmotley999]

The problem

I'm running a Sonoff RF bridge and using a remote receiver automation so I can get details for Govee water sensors, such as alert type and battery level. I'm using an "on_rc_switch:" lambda automation to break out the code and, while not the cleanest as I'm still testing, functional (and why I love ESPHome so much).

I notice that I no longer see rc_switch message dumps, which makes it difficult to add new devices since I can't see the codes they are sending. However, binary sensors using codes outside the lambda still work fine, so everything co-exists.

I'm not sure if this is a bug or by design, and whether there is a way to maintain this functionality when using a remote_receiver automation (e.g. some kind of procedure call in the lambda to output the rc_switch codes?)

Which version of ESPHome has the issue?

2022.2.6

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.2.9

What platform are you using?

ESP8266

Board

Sonoff RF Bridge

Component causing the issue

remote_receiver

Example YAML snippet

remote_receiver:
  pin:
    number: GPIO4
  dump: rc_switch
  tolerance: 50%
  filter: 4us
  idle: 4ms
  # buffer_size: 1kb
  on_rc_switch:
    then:
      - lambda: |-
          // Check for Govee water detectors
          uint16_t addr, event;
          uint8_t event_type;
          uint8_t bytes[8], i;
          uint64_t shift, copy;
          
          shift = x.code << 1;
          copy = shift;
                           
          // Break it out
          for (i=0 ; i < 8 ; i++ ) {
            bytes[7-i] = copy & 0x00000000000000FF;
            copy = copy >> 8;
           };
          
          // Address
          addr = (bytes[2] << 8) | bytes[3];
         
          // Event type, nibble of byte 4
          // 0xC is battery
          event_type = bytes[4] & 0x0F;
          
          // Full event, strip off upper nibble
          event = (bytes[4] << 8) | bytes[5];
          event &= 0x0FFF;

          // Check for water heater sensor
          if (addr == 0x4fde) {
            if (event_type == 0xc) {
              // Battery update
              id(leakwhbat).publish_state((float)bytes[5]);
            }
            if (event == 0xafa) {
              // Button Press, reset water leak
              id(leakwhdetect).publish_state(false);
            }
            if (event == 0xbfb) {
              // Water leak
              id(leakwhdetect).publish_state(true);
            }
          }
          return;
        
remote_transmitter:
  pin: GPIO05
  carrier_duty_percent: 100%

  
# Battery Level Sensor

sensor:
  - platform: template
    name: "Water Heater Leak Battery Level"
    unit_of_measurement: "%"
    accuracy_decimals: 0
    id: leakwhbat

# Binary Sensors
binary_sensor:

  # Water leak detected, updated by lambda
  - platform: template
    name: "Water Heater Leak Detected"
    id: leakwhdetect
    

# Test DOOR using contact sensors
# These binary sensors still function normally when contact sensor activated

  - platform: template
    name: "Test Door"
    device_class: door
    id: testdoor

  - platform: remote_receiver
    name: "Test Door Open"
    internal: true
    on_press:
      then:
        - binary_sensor.template.publish:
            id: testdoor
            state: ON
    rc_switch_raw:
      code: '111100100010000000001010'
      protocol: 1
    filters:
      - delayed_off: 500ms

  - platform: remote_receiver
    name: "Test Door Close"
    internal: true
    on_press:
      then:
        - binary_sensor.template.publish:
            id: testdoor
            state: OFF
    rc_switch_raw:
      code: '111100100010000000001110'
      protocol: 1
    filters:
      - delayed_off: 500ms

Anything in the logs that might be useful for us?

Messages like this are no longer in the logs:

Received RCSwitch Raw: protocol=1 data='01001111110111101111101111111011111110001011111'

Additional information

No response

[Dacesilian]

Hello, I've noticed exactly this behavior. Why have you closed this issue? Thank you.