I have an ESP8266 with 433mHz transmitter and receiver running Tasmota. In order to be able to use it a little easier in HA, I wanted to switch it to ESPHome. However, I just don’t know why I only see signals in the log and can’t simply pass them on to HA. Just like the other way around, you can send a binary code to the ESPHome, which it then sends in RF. As is also possible with Tasmota via MQTT. It’s much easier to have things like this in HA, to be able to react more flexibly and to program something easier than having to reprogram the ESP every time there are new things or tests.
You can pass the values to Home Assistant through API events or by publishing the received values to a Template Text Sensor.
It’s generally considered better practice to do as much processing as possible on the esp and then only send more summarised and essential info to HA.
That said, there is (often) a way to do whatever you want.
When you’re starting with ESPHome it might feel harder to do it on the ESPHome initially, but after a while you start seeing why it works well that way.
That’s my experience anyway…
1 Like
Pass RF codes from esphome to HA as text_sensors? That makes 0 sense. It creates unnecessary sensors and unnecessary steps/delays between when the signal is sent then received and acted on. Thats like a RF pinball machine. There are special binary sensors for this exact thing, handling received codes. After you set up the rf binary sensors, the next step is to… oh wait, thats it!
Those binary sensor states can be used to trigger automations directly from the esphome sensor or the state changes can picked up in HA and used there.
Keep it simple bud.
My reading of the initial post was that OP wanted options for ways to observe incoming codes in HA without having to watch the log. They did not ask “How can I set up a bunch of individual binary sensors for code combinations I already know?”…
uh, no that was the problem. what to do with or how to use the codes was the question.
That makes more sense now, you just didn’t understand what you read.
I was sitting here thinking “A text sensor? this guy must have fell and bumped his head”
They did, you’re right about that. Over the years you start to notice that because HA, Esphome and etc, have a steep learning curve, you see this a lot. People do the best they can to explain what they want to do. They dont usually know if what theyre asking to do is arguanly the best way, the most efficient way, or even the most reliable way to achieve their goal. If someone asks you for directions do you tell them theyre going the wrong way and need to make a U-turn or do you let them keep going the wrong direction and send them through a maze that adds on 15min travel time?
This is what we have here. You could use a text sensor and get to the same destination but, you are sending through a construction zone over city streets with a 10mph speed limit, it doesnt make any sense to go that way. Besides the fact that either way could work, its not the only consideration. There are far more pro’s than cons by keeping the sensor logic and as much automation logic on the esp. By keeping it on the esp you can still send it RF codes and trigger automations in the event HA or the connection to HA goes down. You have options for redundancy and you can hedge your risk of completely losing functionality.
You split the sensor and automation logic so it can only work as long as both HA and esphome api are working. One little problem with either one and none of it will work. By splitting up sensors and automations like that, you expose yourself to far more risk and there are absolutely no upsides for doing that either. Thats why i said, it makes no sense.
It doesnt really matter which way they meant. Theres a right way and a backwards and wrong way that no one can justify for needing to do it hat way over the other.