Concurrent remote receiver & transmitter on same pin

[Rjevski]

Describe the problem you have/What new integration you would like

I would like to know if it's possible/supported to have a remote receiver & transmitter component on the same pin.

The idea would be to "MITM" an existing device's infrared communications. For example the IR climate component allows to not only control an aircon via IR but also to update its own state from a remote_receiver, in such a way that you can keep using the aircon's original remote and have ESPHome's climate component also react to those changes.

Here's an example config:

# receives IR codes from the official remote and updates our internal state
remote_receiver:
  pin:
      number: GPIO16
      inverted: true
      mode: INPUT_OUTPUT_OPEN_DRAIN
      allow_other_uses: true
  id: ir_receiver
  dump: pronto

# transmits IR codes to control the aircon
remote_transmitter:
  carrier_duty_percent: 100%
  pin:
      number: GPIO16
      mode: INPUT_OUTPUT_OPEN_DRAIN
      inverted: true
      allow_other_uses: true

climate:
  - platform: hitachi_ac344
    name: "Air conditioner"
    supports_heat: True
    supports_cool: True
    receiver_id: ir_receiver

Please describe your use case for this integration and alternatives you've tried:

This pattern being officially supported would make integrating into infrared devices such as aircons much easier as it only requires tapping a single wire (the wire/pin from the original IR receiver) and is non-destructive as no original traces are cut.

In contrast, a real MITM with remote receiver/transmitter on separate pins would require splicing the ESP into the IR path, cutting the trace from the original IR receiver.

Additional context

There's an existing discussion around such a "hack" including some success reports.

However, I have tried this on an ESP32 and got broken behavior where an open-drain pin becomes low (as in hard pull to ground) after the remote_transmitter component is used.

I narrowed it down to the fact that ESP32 uses the RMT subsystem to handle IR communications where as others do it in software - this would explain why the people on that discussion had success; they must've used an ESP8266?

Before raising an issue on the main issue tracker I wanted to check whether this is something we wanted to support and whether it warrants an "official" issue on the issue tracker.

[glmnet]

sounds like a bug to me. Did you try both arduino and idf? not sure if that would make a difference. May be you can try a custom lambda to reconfigure the pin after code is transmitted

[swoboda1337]

I know this old but I managed to get it working on esp32 see the yaml below.

Note that on_transmit and on_complete are currently in dev and will hopefully make it into the next release.

To properly fix this a new version of the RMT driver is required but the workaround does the job.

remote_receiver:
  id: rx_id
  pin:
    id: rx_gpio_id
    number: GPIO10
    allow_other_uses: true
  dump: raw

remote_transmitter:
  id: tx_id
  pin:
    id: tx_gpio_id
    number: GPIO10
    allow_other_uses: true
  carrier_duty_percent: 100%
  on_transmit:
    then:
      - lambda: |-
          id(tx_gpio_id)->pin_mode(gpio::FLAG_OUTPUT);
          id(tx_id)->setup();  // workaround
  on_complete:
    then:
      - lambda: |-
          id(rx_gpio_id)->pin_mode(gpio::FLAG_INPUT);

interval:
  - interval: 30sec
    then:
      - remote_transmitter.transmit_raw:
          code: [614, -614, 600, -614, 614, -614, 601, -614]