Esphome - publish rf codes in mqtt

Tags: #<Tag:0x00007f739a1272c0>

Good day, looking for a bit of guidance.
Im attempting to capture rf codes and then republish them via mqtt.
this gets me the codes in the console:

remote_receiver:
  pin: GPIO27
  dump: rc_switch
  filter: 4us
  idle: 4ms
  on_raw:
    then:
    - mqtt.publish:
        topic: tele/esphome/rfbridge/RESULT
        payload: !lambda |-
          return id(remote.rc_switch).state;

However, whilst I think the trigger “on_raw” is correct, I havent been able to work out how to template the payload so that it pubishes the code that was the trigger.

Thank you

The esphome docs deal with how to obtain the codes. It has nothing to do with MQTT.

I know that. I can alreay obtain the codes and trigger a binary sensor.

What I want to do is re-publish the code as an mqtt message

Using the latest Esphome-Dev add-on for Hassio, you can use this code,

remote_receiver:
  pin: 4
  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms
  on_rc_switch:
    - mqtt.publish:
        topic: bridge/rf/result        
        payload: !lambda |-
          char buff[21];
          sprintf(buff, "%llu", x.code);
          return buff;

I couldn’t figure out how to make use of on_raw effectively - as the x variable only contained the raw RF data - so you still needed to use the encode library from RC Switch to get it into a hex/binary string. And I don’t know enough about Esphome to figure out how to call methods from existing libraries.

See https://github.com/esphome/esphome/pull/983 for reference.

Thank you very much. I’d abandoned this as I never got a reply. What I wanted to do was get the bridge to pick up the rf signal from a sensor and publish it as an mqtt payload. That way you wouldn’t have to list every sensor in the esphome yaml.

So in theory your suggested code should accomplish this?

Yeah, I was trying to achieve the same thing, saw your post - and thought I’d add a reply when I found something (so someone didn’t end up like you and I).

My original goal was to have multiple RF Sonoff Bridges that ingested the RF data and sent it as a MQTT payload - so that I could have a single sensor fed by multiple RF sources (for reliability/coverage). I didn’t want to define the sensor on the bridge - but on Hassio itself.

But if you are defining the sensor on the Sonoff Bridge itself - you can actually just define the MQTT broker details and the MQTT sensor is automatically created and detected by Hassio.

Eg. Just put this

mqtt:
  broker: 10.0.0.2
  username: livingroom
  password: MyMQTTPassword

So I guess my question is, do you have multiple bridges, where you want to define one sensor centrally - or just a single bridge?

Thank you very much again.
I define the sensors in HA and use this

Which allows me to use as many rfbridges as i want.

Ah, so I guess here’s how you can do it then

mqtt:
  broker: 10.0.0.2
  username: livingroom
  password: MyMQTTPassword
  id: mqtt_client

remote_receiver:
  pin: 4
  filter: 100us
  tolerance: 50%
  idle: 2ms
  on_rc_switch:
    - lambda: !lambda |-
        char buff[21];
        sprintf(buff, "rf/bridge/%llu", x.code);
        id(mqtt_client).publish(buff, "ON");

thank you very much.

so no need to add the topic after on_rc_switch? it 's in the lambda function i see.

also noted you removed the “dump: rc_switch” parameter.

It just depends on what you are trying to achieve. If you are using sensors that only have a single state (eg. PIR) then the above code gives you a way of sending the MQTT payloads to individual topics.

Eg.


   - platform: mqtt
     name: 'Hallway PIR 1'
     state_topic: 'rf/bridge/101112'
     <<: &common_pir
       off_delay: 5
       device_class: motion

   - platform: mqtt
     name: "Hallway PIR 2"
     state_topic: 'rf/bridge/456789'
     <<: *common_pir

   - platform: mqtt
     name: "Landing PIR 1"
     state_topic: 'rf/bridge/123456'
     <<: *common_pir

The dump: rc_switch line is merely for debugging to see the RF code in the Esphome log console. I turn it on when I need to sniff for a new 433Mhz device to see what the code is, then turn it off to avoid the device needlessly logging.


I took a slightly different approach though as I needed to support multi-state devices (eg. doors) and I didn’t want to have to reload Hassio every time I added a sensor to configuration.yaml

So instead, I used MQTT discovery with NodeRed and a number of modified Sonoff T2 light switches acting as 433MHz bridges.

Node Red Flow

This only needs to be updated and run when you add a new sensor.

[{"id":"9993cb8d.82e7c8","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"f3b79420.a8ffe8","type":"mqtt out","z":"9993cb8d.82e7c8","name":"","topic":"","qos":"","retain":"","broker":"2ec7481f.cfe868","x":1070,"y":300,"wires":[]},{"id":"39715738.293628","type":"function","z":"9993cb8d.82e7c8","name":"","func":"function hexa(num) { return parseInt(num, 2).toString(10) }\nfunction nameToId(name) { return name.replace(/ /g,\"_\").toLowerCase(); }\n    \nfunction templateDevice(device) {\n    obj = {};\n    \n    id = nameToId(device.name);\n    obj.payload = {\n        name: device.name,\n        state_topic: 'rf/bridge/all',\n    };\n    obj.topic = 'homeassistant/binary_sensor/' + id + '/config';\n    \n    switch (device.type) {\n        case 'pir':\n        case 'vibration':\n            obj.payload.off_delay = 5;\n            obj.payload.device_class = 'motion';\n            obj.payload.payload_on = hexa(device.on);   \n            break;\n        case 'door':\n        case 'opening':\n            obj.payload.payload_on = hexa(device.open);\n            obj.payload.payload_off = hexa(device.close);\n            obj.payload.device_class = 'door';\n            break;\n        default:\n            obj = false;\n    }\n    \n    return obj;\n}\n\n// Process entities\nfor (index = msg.payload.length - 1; index >= 0; --index) {\n    msg.payload[index] = templateDevice(msg.payload[index]);\n}\n\nreturn msg;","outputs":1,"noerr":0,"x":590,"y":300,"wires":[["9f0dc2fb.11f02"]]},{"id":"db249a23.e95418","type":"inject","z":"9993cb8d.82e7c8","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":240,"y":300,"wires":[["16dced2d.c73ef3"]]},{"id":"9f0dc2fb.11f02","type":"split","z":"9993cb8d.82e7c8","name":"","splt":"\\n","spltType":"str","arraySplt":"1","arraySpltType":"len","stream":false,"addname":"","x":750,"y":300,"wires":[["a4d3a9d.be33a58"]]},{"id":"a4d3a9d.be33a58","type":"function","z":"9993cb8d.82e7c8","name":"","func":"return msg.payload;","outputs":1,"noerr":0,"x":910,"y":300,"wires":[["f3b79420.a8ffe8"]]},{"id":"8afe9a3f.f15358","type":"comment","z":"9993cb8d.82e7c8","name":"RF MQTT","info":"","x":240,"y":260,"wires":[]},{"id":"16dced2d.c73ef3","type":"template","z":"9993cb8d.82e7c8","name":"Sensors","field":"payload","fieldType":"msg","format":"json","syntax":"plain","template":"[\n    {\n        \"on\": \"0000000111110100\",\n        \"name\": \"Hallway PIR 1\",\n        \"type\": \"pir\"\n    },\n    {\n        \"open\": \"0000000111110101\",\n        \"close\": \"0000000111110111\",\n        \"name\": \"Boiler Room Door\",\n        \"type\": \"door\"\n    }  \n]","output":"json","x":420,"y":300,"wires":[["39715738.293628"]]},{"id":"2ec7481f.cfe868","type":"mqtt-broker","z":"","name":"MQTT-Server","broker":"192.168.1.1","port":"1883","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

Esphome

mqtt:
  broker: 10.0.0.2
  username: myuser
  password: mypassword
  id: mqtt_client
  discovery: false

remote_receiver:
  pin: 4
#  dump: rc_switch
  filter: 100us
  tolerance: 50%
  idle: 2ms
  on_rc_switch:
    - lambda: !lambda |-
        char code[21];
        sprintf(code, "%llu", x.code);
        id(mqtt_client).publish("rf/bridge/all", code); 

With this, it only needs NodeRed to create the sensor, Hassio does the rest after that.

This is very good. I did read in another post someone modifying T2 switches, which is the perfect bridge solution as most likely they’re spread all over the house.
In my case i have replaced all my switches with T2s and this would work great.
I have been using the sonoff rfbridge with tasmota for rf senssors for about 2 years now and what i found was that for PIRs it works very well. However for door/contact sensors it was not reliable unless the sensor was relatively close to the bridge. So i gave up on the contact sensors and switched to zigbee (zigbee2tasmota) for those, whilst retaining rf for pirs.

The zigbee contact sensors are very reliable, I use a cc2530+2591 flashed with zigbee2tasmotta connected to wifi via a sonoff basic and it covers the required area (3000sqf) well plus i dont need to plug it to my server. It’s remote.

Nevertheless, had i been able to get the rf contact sensors to work reliable, i probably wouldnt have switched.

For your modified T2s, did you modify the board to use its rf chip as i saw in the other post? or you just added a receiver or similar.

Thank you for sharing all this information/experience.

Its probably this post - Converting a Sonoff TX/T1/T2/T3 into a Sonoff Bridge

Just a single resistor was required - and its very similar to the RFR3/Bridge hack to make use of the onboard RF receiver (pin 10 on the RF chip to GPIO 3 with a 220ohm resistor). But you can just use a regular piece of wire.

There’s enough room on the board for the wire/resistor to fit without it affecting the cover/screws, you just route it around the buttons.

So there’s a few dozen T2’s in my house, all acting as 433MHz receivers. It has rendered the Sonoff Bridges that I bought as fairly useless now, but I’ll keep them for 433MHz transmit for the future.

Yes exactly that post. should have guessed it was yours :smiley:
once again thank you for sharing this information.
indeed this mod does away with the need for rfbridges completely.

did you try the mod using tasmotta? I presume you’d also get a “code” via the tasmota console.
reason i ask is because my switches are tasmotized

I’ve never used Tasmota I’m afraid. I found Esphome so easy to flash via the web interface in Hassio that I just stuck with it.

thank you. I’ll give it a try with tasmota and see what i get.
just in case would you mind sharing one of your esphome switch.yaml

So there’s no configuration at all in Hassio - and the only other configuration for Esphome is what I posted above.

thank you for all your help

Good afternoon @blessani I saw that you understood a lot about Esphome and I need your help if possible? I am trying to transmit through Sonoff Bridge and without success I am using EspHome (dev) I know it has a bug but I do not know how to change and recompile it because when I change and I will recompile it changes everything I did and compiles in a buggy way, you are a enthusiastic like me for EspHome so I’m asking you for help because this is the last piece with tasmota because the rest is all with EspHome.

Make a new topic, include your config - then DM me and I’ll have a look. I haven’t done any transmit with my bridge, so I’m not super familiar with it. But I can have a play.