Output the value in hex as an esphome event?

[awdark]

So I went down a whole rabbit hole trying to improve the reliability of 433mhz signals. This by far is the most straightforward implementation of the cc1101 library I could find. Tasmota has a hint of it, OpenMQTTGateway makes references to it but doesn't seem to play nice with the wt32-eth01

I am trying to make an ethernet based 433mhz bridge that will essentially mirror the SonOff RF Bridge https://esphome.io/components/rf_bridge.html

sonoff-rf

api:
  services:
    - service: send_rf_code
      variables:
        sync: int
        low: int
        high: int
        code: int
      then:
        - rf_bridge.send_code:
            sync: !lambda 'return sync;'
            low: !lambda 'return low;'
            high: !lambda 'return high;'
            code: !lambda 'return code;'

rf_bridge:
  on_code_received:
    - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'return format_hex(data.sync);'
            low: !lambda 'return format_hex(data.low);'
            high: !lambda 'return format_hex(data.high);'
            code: !lambda 'return format_hex(data.code);'

WT32-eth01 currently still testing

esphome:
  name: wt32-eth01-cc1101
  friendly_name: wt32-ETH01-cc1101
  includes:
    - cc1101.h
  libraries:
    - SPI
    - "SmartRC-CC1101-Driver-Lib"  
  
esp32:
  board: esp-wrover-kit
  framework:
    type: arduino

ethernet:
    type: LAN8720
    mdc_pin: GPIO23
    mdio_pin: GPIO18
    clk_mode: GPIO0_IN
    phy_addr: 1
    power_pin: GPIO16

api:
  services:
    - service: send_rf_code_raw_wt32 # send as [1,10,399]
      variables:
        sendCode: int[]
      then:
        - lambda: get_cc1101(transciver).beginTransmission();
        - remote_transmitter.transmit_raw:
            code: !lambda 'return sendCode;'
        - lambda: get_cc1101(transciver).endTransmission();
    - service: send_rf_rcswitch_wt32 # send as   code: '001010011001111101011011'
      variables:
        sendCode: string
      then:
        - lambda: get_cc1101(transciver).beginTransmission();
        - remote_transmitter.transmit_rc_switch_raw:
            code: !lambda 'return sendCode;'
            protocol: 1  # if I ever figure out how to send a number through a service 
        - lambda: get_cc1101(transciver).endTransmission();
 sensor:
  - platform: custom
    lambda: |-
      auto my_sensor = new CC1101(
        14, // SCK
        4, // MISO
        15, // MOSI
        12, // CSN
        2, // GDO0 (TX) # Try different GPIO
        35, // GDO2 (RX)
        200, // bandwidth_in_khz
        433.92 // freq_in_mhz
      );
      App.register_component(my_sensor);
      return {my_sensor};
    sensors:
      id: transciver
      internal: true
remote_transmitter:
  - pin: GPIO2 # This is GDO0
    carrier_duty_percent: 100%
    id: transmitter_1

remote_receiver:
  - pin: GPIO35 # This is GDO2
    tolerance: 50%
    #filter: 100us
    dump:
      - raw
      - rc_switch
    on_rc_switch: 
      then:
        - homeassistant.event:
            event: esphome.rf_code_received
            data:
              code: !lambda 'return x.code;'
    

Currently this can not send, I suspect GPIO2 might not be a good choice but I took the suggestion from the ESPsomfy config with the WT32-eth01 + cc1101 config. I was reading the issues and will definitely take a rtl-sdr to it.

When this receives a RC_Switch compatible message, a binary value is sent to home assistant as an event.esphome.rf_code_received and under code the value is outputted decimal, but viewed as a string because it needs quotes but good enough.

Basically I am trying to make it so I can use it in automations when "When esphome.rf_code_received event is fired" matches the code. Or run an automation where I can "Call a service 'esphome.sonoff_rf_send_rf_code' on" unless there is an easier way that I have been foolishly overlooking. Maybe just use what I have and match it with binary. I will see when I get home from work.

Edit
Receive is good enough just deal with another variable as a trigger no big deal

For reference a button press on my remote would produce the following
CC1101 Logs in ESPHome
[20:06:33][I][remote.raw:028]: Received Raw: 1089, -373, 343, -1097, 353, -1094, 361, -1078, 1082, -370, 1095, -358, 372, -1068, 360, -1075, 384, -1085, 1077, -374, 343, -1096, 354, -1094, 360, -1079, 1089, -374, 1093, -362, 353, -1094, 363, -1079, 1084, -369, 344, -1090, 369, -1069,
[20:06:33][I][remote.raw:041]: 1109, -350, 362, -1084, 363, -1090, 372, -1065, 366
[19:57:45][I][remote.rc_switch:261]: Received RCSwitch Raw: protocol=1 data='100011000100011001001000'

RTL433
time : 2024-04-16 19:59:24
model : Smoke-GS558 id : 4881
unit : 17 learn : 0 Raw Code : 126231

SonOff RF
event_type: esphome.rf_code_received
data:
device_id: e64809142a83f62d434462bc56c01f4e
sync: 2b84
low: 017c
high: 044c
code: 008c4648
origin: LOCAL
time_fired: "2024-04-17T03:00:39.729662+00:00"
context:
id: 01HVMZZKNHJWE3M92ANP0560H2
parent_id: null
user_id: null

CC1101
event_type: esphome.rf_code_received
data:
device_id: 6f154bd5249461c56bb179a88732c146
code: "9193032"
origin: LOCAL
time_fired: "2024-04-17T03:00:39.759935+00:00"
context:
id: 01HVMZZKPFXHMDZ3W47NDRQX4P
parent_id: null
user_id: null

[awdark]

Sending is a low priority for me, just one of those "nice to have"

Sending appears to do something on both GPIO02 as well as GPIO17 but I can only assume is malformed data
https://i.imgur.com/PFGicfv.png

In order from left to right
Remote button press

Sending raw as integer array
[1093, -386, 352, -1070, 360, -1102, 359, -1085, 1077, -372, 1092, -363, 351, -1069, 386, -1078, 357, -1085, 1091, -352, 369, -1069, 382, -1072, 359, -1080, 1104, -346, 1094, -361, 374, -1070, 360, -1101, 1089, -345, 367, -1097, 352, -1094, 1088, -344, 378, -1090, 344, -1090, 369, -1071, 356]

Sent in as RCSwitch with the binary value '100011000100011001001000' with and without the quotes
Sent in as RCSwtich as a decimal value 9193032 with and without the quotes

[20:24:09][D][sensor:094]: 'transciver': Sending state -99.00000 with 0 decimals of accuracy
[20:24:10][W][component:232]: Component api took a long time for an operation (340 ms).
[20:24:10][W][component:233]: Components should block for at most 30 ms.
[20:24:10][D][sensor:094]: 'transciver': Sending state -96.00000 with 0 decimals of accuracy
[20:24:10][I][remote.raw:041]: Received Raw: 282
[20:24:10][D][sensor:094]: 'transciver': Sending state -99.00000 with 0 decimals of accu

Sending the raw value the sample cc1101-esp32.yaml produces a more normal
[20:22:20][I][remote.raw:041]: Received Raw: 270
[20:22:24][I][remote.raw:041]: Received Raw: 270
[20:22:27][I][remote.raw:041]: Received Raw: 269

[dbuezas]

I haven't tried an esp32 for this, but there are other reports in this repo of people having issues with it. Your suspicion about the gpio selection is an interesting one