A plug with a switch

It works (mostly)!!

The ESP-01S (ESP8266) has been inserted between the RF receiver and the built-in MCU. ESP receives the RF data on the white wire, and if the address is correct, forwards that to the MCU on the green wire. It monitors the relay state on the yellow wire.

I set this up in Tasmota very quickly, to about 66% of a solution. Currently I can’t figure out how to tell Tasmota that a pin is just a binary input. It seems to support so many things, but not just a simple binary input!!

So, last night I switched it over to ESPHome, and was able to see how it might provide a solution. But again stopped at about 66% of the full solution. This time, I can read the pin as a binary sensor. But I haven’t figured out how to forward the RF data on to the MCU.

Both solutions hold so much promise, but are missing the mark right now. If anyone has input on how to resolve either case, I’m all ears.

I had to drill through the PCB because there was not enough space around the board edge to route wires. Also provides a little better stress relief.

Shouldn’t be a problem. Post your actual code.

On the ESPHome side, this is what I have. I did not find any info at all on how to do what I need, so this is what I am starting with.

esphome:
  name: esp-01s-1
  friendly_name: ESP-01S-1

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "[REDACTED]"

ota:
  - platform: esphome
    password: "[REDACTED]"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esp-01S-1 Fallback Hotspot"
    password: "[REDACTED]"

captive_portal:

web_server:
  port: 80

binary_sensor:
  - platform: gpio
    name: "GE Wireless Outlet"
    pin:
      number: GPIO3
      inverted: false
      mode:
        input: true
        pullup: false

remote_receiver:
  dump: "all" # I haven't figured out the actual protocol.
  filter: 150us
  pin: 
    number: GPIO2
    inverted: false
    mode:
      input: true
      pullup: true

remote_transmitter:
  pin: GPIO1
  carrier_duty_percent: 100%

What I need to do is receive data on GPIO2. If the data matches what I have set as the correct info, then send that out GPIO1. It’s not specific to RF or IR. It should work with any data coming in on a pin. But my use case is RF, obviously.

For Tasmota, there is no code (that I know of). It’s just UI configs and dropdowns. And in the pin assignment screen, Tasmota offers no option for a simple digital input, or at least I haven’t figured out which one it is. The Tasmota data forwarding setup was trivial, using rules:

Rule1 on RfReceived#Data=0x12 do RfSend {"data":0x12,"bits":24,"protocol":1,"repeat":4,"pulse":211} endon
Rule2 on RfReceived#Data=0x14 do RfSend {"data":0x14,"bits":24,"protocol":1,"repeat":4,"pulse":211} endon

But I can’t find any way to make GPIO3 connected to the relay a binary sensor in Tasmota. It needs to just tell me that the relay is engaged or not, and look like something useful, but read-only in HA. All the options I’ve tried (switch, button, light and relay) result in something the user is expected to be able to set, which is not right. Or it doesn’t show up in HA at all.

At the moment, I need to take the device apart and re-flash it over serial. I tried going from ESPHome to Tasmota with the Tasmota minimal firmware. But I failed to remember the Tasmota firmware would not have any network config, and the minimal firmware doesn’t have the captive portal for setting up the WiFi. So, until re-flashed, it’s down. Will be doing that tonight.

It’s kind of confusing and I don’t even remember anymore what was your original approach.
Let’s try to keep it simple as possible.
“If the data matches what I have set as the correct info”. Give an example of “correct info”.
Also post your log for what you received with that “dump: all” in this case.

Take a look at the two rules I included above (found elsewhere online) for Tasmota. I need to replicate that behavior in ESPHome.

Or I need to get Tasmota to handle a binary sensor and present it as such in HA.

The ESPHome logs have a lot of decoded noise in them, including my button pushes. So, I know ESPHome is receiving the wireless data.

To apply those tasmota “rules” directly you need the signal to get decoded with same protocol that tasmota did. But it doesn’t have to be so complicated.

Simply, what does your dump: all prints out?

ps. do you need pullup on receiver pin?

Edit: looking at your “rules” I would guess its Rc_switch.

remote_receiver:
  dump: rc_switch
  filter: 150us
  pin: 
    number: GPIO2
    inverted: false
    mode:
      input: true

The Tasmota rules already work. I’m trying to replicate the functionality of the Tasmota rules in ESPHome.

The dump prints out thousands of garbage lines in the log. It scrolls by so fast, I am not able to capture a button press and analyze it so far. I’ll try to capture something meaningful from it.

So did you try with rc_switch approach I posted above?
Do you have same hardware setup that received with tasmota?

Haven’t gotten that far yet. But your comment about it possibly being a rc_switch compatible protocol did spur some search ideas I hadn’t thought of yet.

Looked thru Tasmota docs some more and found this: RF Transceiver - Tasmota which apparently is based on the rc_switch project here: GitHub - sui77/rc-switch: Arduino lib to operate 433/315Mhz devices like power outlet sockets., and that has some good protocol documentation.

Yes. I’ve been using the RF receiver that’s built into the dumb GE wireless outlet, since everything is now soldered into it. But I need to set up a better way to test both Tasmota and ESPHome. Flashing back and forth between the two on a single ESP is getting annoying. :wink:

You don’t need to get mad with that. It’s enough to receive the code once decoded to some protocol (rs switch I suspect). If that doesn’t match post the dumb you receive.
Output tells what issue you have.

I have no problems receiving and decoding the data.

I just need to know how to pack that up and send it right back out. It seems like ESPHome should have some kind of way to process the received data to verify it’s the correct address, and then send it back out. Tasmota does it with two lines of rules.

The other path to solution is to get Tasmota to handle a simple binary input as a sensor and present it to HA. Seems like that should be a trivial use case. But alas, I have not found the magic juju.

You want to see it your way.
It’s dirty simple, but you need to post what you receive/ decode on esphome.

Hm, well I apologize for that. It’s not my intention. I’m working from a position of a high level of ignorance still. I’ve only worked on this for a few weeks. What is it that makes you think I am tying to do this differently than what you are expecting?

Care to explain? Or are you unable to explain without a sample of the data? I don’t understand why it requires a sample of data before you can describe what needs to be done. I can of course supply the data, once I have things back on line and receiving again, and will do that asap.

I don’t want to just record/regurgitate codes. I need to know what the actual data is in the transmission, so I can verify the sent data is valid before forwarding that onto the MCU.

Because the “rule” on esphome should be built according to the received/decoded data. If your setup doesn’t have successful reception, there’s nothing to do.
Only based on your logs I can suggest something.

I can give a code:

binary_sensor:
  - platform: remote_receiver
    name: "RF Signal Received"
    rc_switch_raw:
      code: 0x12
      protocol: 1

but if your setup doesn’t receive that, it will never work…

But I don’t need a binary sensor. I need to verify code 0x12 is valid and then send the same code back out.

It was just an example to validate your 0x12.

I don’t want to insist, but feel free to post what you receive…

# Example automation for decoded signals
remote_receiver:
  ...
  on_samsung:
    then:
    - if:
        condition:
          or:
            - lambda: 'return (x.data == 0xE0E0E01F);'  # VOL+ newer type
            - lambda: 'return (x.data == 0xE0E0E01F0);' # VOL+ older type
        then:
          - ...

Taken from :point_down:

I guess it is now enough to link to :point_down:

To close the loop for you? :curly_loop:

1 Like

If it ever was…

Finally set up my test rig so that I can test both Tasmota and ESPHome a lot easier.

I’ve read this page several times and did not catch what that example was trying to show. Thank you!

I’ve come up with this, which is getting a compile error. And I can’t figure out how to work with a lambda. Been digging around, and have not found any detailed docs. Only brief mentions about it with non-relevant examples. Links with better lambda info welcome. EDIT: found this.

remote_receiver:
  dump: "all"
  filter: 150us
  pin: 
    number: GPIO3
    inverted: false
    mode:
      input: true
      pullup: true
  on_rc_switch:
    then:
    - if:
        condition:
          lambda: 'return (x.data == 0x14);' # "On" button
        then:
        - remote_transmitter.transmit_rc_switch_raw:
            code: '000000000000000000010100' # AKA 0x14
            protocol:
              pulse_length: 800
              sync: [1,31]
              zero: [1,3]
              one: [3,1]
              inverted: false

remote_transmitter:
  pin: GPIO1
  carrier_duty_percent: 100%

Compilation says this:

/config/esphome/esp-01s-2.yaml: In lambda function:
/config/esphome/esp-01s-2.yaml:66:17: error: 'struct esphome::remote_base::RCSwitchData' has no member named 'data'
   66 |           lambda: 'return (x.data == 0x14);' # "On" button
      |                 ^~~~
*** [.pioenvs/esp-01s-2/src/main.cpp.o] Error 1

What do I need to do to get this lambda thing to compile?

I’ll tell you if you post your logs for dump… :wink:

Take your time. anyway, for rcswitch syntax is x.code