Can you please explain the last else statement, what it means and how it is evaluated? I am not a professional programmer and like to understand the code prior to blindly pasting.
{{states(‘binary_sensor.hallway_motion’) | upper}}
This line evaluates in a manner that satisfies the payload check of the software but I don’t understand how.
Thanks for your help…
A wise decision. I’ll explain the operation of the following value_template
value_template: >-
{% if value_json.RfReceived.Data == '2C8D0A' %}
{{'ON'}}
{% elif value_json.RfReceived.Data == '2C8D0E' %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.bathroom_door') | upper}}
{% endif %}
Although it may be self-evident I’ll state it anyway, the purpose of value_template is to report a value. It has to report some kind of valid value. Reporting no value is not an option.
2C8D0A the template reports ON.2C8D0E the template reports OFF.binary_sensor.bathroom_door. In other words, the value_template reports the binary_sensor’s own current state back to itself.A binary_sensor reports its two valid states on and off in lower case. However, when an MQTT Binary Sensor receives data, by default it expects ON and OFF in upper case (see documentation).
That’s why this template employs the upper filter:
{{states('binary_sensor.hallway_motion') | upper}}
It gets the current state of binary_sensor.hallway_motion, let’s say it’s on, then converts it to upper case, so it produces ON. If we didn’t use upper, the {% else %} portion of value_template would report on in lower case. That’s not a state an MQTT Binary Sensor expects to receive by default and so would produce an error message.
I have payload_on and off and still get warnigs
I think it just says that your value_template does not react properly (i.e does not return “ON” or “OFF”) on receiving any payload.
And if you look at your code and compare it with this, for example, hope you’ll understand why you still get warnings.
Then is there a solution to make those log warnings go away?
puting your example into my code gats me a warning
Error loading /config/configuration.yaml: while scanning for the next token found character '%' that cannot start any token in "/config/binary_sensor.yaml", line 23, column 6
- platform: mqtt
name: "Front Door"
state_topic: "sonoff_hub/tele/RESULT"
value_template: >-
{% if value_json.RfReceived.Data == '2B810A' %}
{{'ON'}}
{% elif value_json.RfReceived.Data == '2B810E' %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.front_door') | upper}}
{% endif %}
payload_on: "2B810A"
payload_off: "2B810E"
device_class: door
qos: 1Remove these two lines from your configuration:
payload_on: "2B810A"
payload_off: "2B810E"
They are not needed because the value_template handles the interpretation of the received payload.
For more information, see:
The problem is that yaml check gives error in the file if I put that template there for the character “%”.
it looks like indentation is not right, add a tab in front of every line between value_template and device_class
Thank you, indentation was the problem.
Now, I used this solution to get rid of the pesky “payload not found”, but the messages still appear in the log just like using the old variant.
So what’s the use of it?
EDIT:
My bad, I put to another sensor this template and it stops giving warning in the log
So ALL sensors need this so none of them will give the “payload” warning in log.
Brilliant.
Thank you sir.
I assume the configuration for binary_sensor.front_door looks like this:
- platform: mqtt
name: "Front Door"
state_topic: "sonoff_hub/tele/RESULT"
value_template: >-
{% if value_json.RfReceived.Data == '2B810A' %}
{{'ON'}}
{% elif value_json.RfReceived.Data == '2B810E' %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.front_door') | upper}}
{% endif %}
device_class: door
qos: 1
Assuming it does, what is the exact warning message you are still receiving?
See my above edit 
Yes, all sensors that use the RF bridge.
If you have many sensors, the more efficient solution is to use a demultiplexer automation. It simplifies the configuration of each sensor (no value_template is needed) and reduces the amount of processing Home Assistant performs each time a new payload arrives via sonoff_hub/tele/RESULT.
@123 thank you for the solution. I’ve just had a chance to test it and marked it as the solution.
In my (OP) case, since my sensors don’t send JSON the syntax is a bit simpler. e.g. Each sensors goes from this:
- platform: mqtt
state_topic: "unosensor"
device_class: safety
name: sensor8
payload_on: "8_ON"
payload_off: "8_OFF"
To this:
- platform: mqtt
state_topic: "unosensor"
device_class: safety
name: sensor8
value_template: >-
{% if value == '8_ON' %}
{{'ON'}}
{% elif value == '8_OFF' %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.sensor8') | upper}}
{% endif %}
And as always thank you to all including @AhmadK, @Petrica and other who kept the discussion going to get to a good solution.
That said, I still think reversing the PR that originally caused this, or at least lowering the logging severity level is better. But thanks to the creative folks in community @123’s solution is more than good enough.
In reply to the new feature in OpenMQTTGateway where you can append the data string to the topic name…
How would I use this with a sensor that sends different codes for on and off?
I cannot see how I can use that in a binary_sensor as it cannot listen to two topics at the same time. It can wildcard everything but then we are back to listening to all topics.
You cannot toggle a binary.sensor in an automation so you would have to make some template sensor and several automations and then you may use some of the other hacks already suggested in this now very long discussion. But have I missed something?
Kenneth
Just want to share my experience.
I tried that feature and have to say it’s not for every situation. For example, it’s ok for PIRs that only send one code, but it gets increasingly complicated for anything else - door sensors, wall switches etc.
So I ended up implementing proper value_template templates as described here.
Believe it or not, there is a good reason behind this warning and you’d be better off sorting your config to avoid any “unusual” behaviour caused by ignoring it.
AhmadK
Your experience matches mine. I changed from Tasmota to OpenMQTTGateway because it had the feature of appending the value to the topic path.
But I found that for my 5 window and door sensors I ended up with having to use input_booleans and template binary sensors and automations to get a clean implementation. It got more ugly than using the value_template hack
The word hack here needs to be understood in a positive mood. You guys that contributed in this thread and other threads with the MQTT multiplexed solutions as well as the value template solution have made a huge positive impact to probably 1000s of RF bridge users. I am deeply impressed with the research you did. And I am personally using the value_template solution. I have 5 window/door sensors and 6 motion sensors and a couple of RF buttons so that solution is acceptable from a performance point of view. I deeply thank you for this solution.
I call it a hack because instead of simply specifying an and off an on payload (and assume anything else is ignored - as it is!) we have to use a complex Jinja code with an if - elif - else structure and setting the sensors to its own value. And we set the sensor to its own value also when we receive codes for different sensors. Luckily HA does not create events when you set the binary_sensor to a value it already has. It is an elegant solution to the problem and I am again deeply thankful that you guys found this solution.
It is not an ERROR to use a common MQTT topic for a radio gateway. It is the most practical solution for a gateway running on an ESP8266. The alternative solutions are
The gateway has to be much more complex so that you can define mqtt topics and map multiple codes to the same topic. I am thinking about rewriting OpenMQTTGateway for myself to add a hardcoded map. But it will be a pain to maintain.
HA could be expanded so that a binary sensor can support TWO mqtt topics. That would be a good and clean solution already supported by OpenMQTTGateway and I am sure the devs of Tasmota would add this if it was supported by HA.
HA should stop reporting the errors (remove 3 lines of code). It works. But it removes a debug opportunity for people that wonder why their sensor does not work.
HA could change the logging from errors to warnings and ensure they are not shown in the /dev_info which is an important source of info for dramatic important issues available from the browser.
HA could change the logging so it only reports if no sensors matches a payload. This is what the user needs to know
I am happy with my value_template solution. I am just trying to contribute with ideas that helps making HA easier to use. At the moment we count on users finding this 150+ postings thread on the forum for a solution to a common problem. I am not arguing for myself. I am quote OK. Hack till it hurts as a famous Youtuber says
Example of the value_template solution for users with OpenMQTTGateway
I would like to share a working value_template solution for users that are on OpenMQTTGateway and not Tasmota. There are a few small differences.
First Tasmota returns the data as a string and it is the value in HEX.
OpenMQTTServer returns the value as a number in decimal. This is important as you need to quote the hex string but it will not work if you quote the decimal number
The JSON Payload is different (value_json.value)
First a Binary Sensor for a sensor with both on code and off code (window/door sensors reporting open and closed). In this example I have 3 RF bridges all reporting the sensors in their own topics
OpenMQTTGateway/RFBridge1/433toMQTT
OpenMQTTGateway/RFBridge2/433toMQTT
OpenMQTTGateway/RFBridge3/433toMQTT
I do not care that I get 3 messages that trigger the sensor 3 times. The objective is to ensure the opening or closing of a window is detected. We use the wildcard + in the sensor in HA so it listens on all 3 bridges and triggers 1 to 3 times depending on coverage and noise. Note that the data is not quoted as it is a number and not a string
binary_sensor:
- platform: mqtt
name: "Kitchen Window RF"
state_topic: "OpenMQTTGateway/+/433toMQTT"
value_template: >-
{% if value_json.value == 13718474 %}
{{'ON'}}
{% elif value_json.value == 13718478 %}
{{'OFF'}}
{% else %}
{{states('binary_sensor.kitchen_window_rf') | upper}}
{% endif %}
Same setup but here we use a Motion sensor that only sends a code when detecting motion. There is no off code. We use a 180 second time-out
binary_sensor:
- platform: mqtt
name: "Hallway Motion RF"
state_topic: "OpenMQTTGateway/+/433toMQTT"
value_template: >-
{% if value_json.value == 13621870 %}
{{'ON'}}
{% else %}
{{states('binary_sensor.hallway_motion_rf') | upper}}
{% endif %}
off_delay: 180
Finally an automation triggered by an RF button we have in the kitchen. Here used to trigger a fun message via Alexa. Note that for automations there is no issue with error logging. You can have as many automations you want listening to the same MQTT topic and the payload does not need to be matched. But again note that different value_template needed for OpenMQTTGateway compared to Tasmota.
For this automation I do not use a wildcard as it would trigger the beer message 2-3 times and I would develop an alcohol problem
automation:
- alias: 'Black Button'
initial_state: true
trigger:
platform: mqtt
topic: "OpenMQTTGateway/RFBridge1/433toMQTT"
condition:
condition: template
value_template: '{{ trigger.payload_json.value == 4389249}}'
action:
action:
- service: script.alexa_tts_message
data:
message: 'Would you like a little beer?'
I hope this is useful for people.
All these examples also work with Tasmota but then you need a different value_template to decode the JSON payload. value_json.RfReceived.Data and you then quote the hex number in double quotes -“EB67A1”
Kenneth
The word ‘hack’, whether used in a positive or negative sense, is misplaced when describing the solution to use a template. The implication is that every time someone uses a value_template (rather than payload_on and payload_off) it’s a ‘hack’. It’s not. Templates are one of the most useful and powerful tools in Home Assistant and they have wide-ranging applications.
With over a dozen devices, my recommendation would be to use Strategy 2: Demultiplexer. All of your sensor configurations will be greatly simplified. For example:
- platform: mqtt
name: "Kitchen Window RF"
state_topic: "home/sensor1"
All it requires is one very simple automation and one python_script. You configure each sensor’s parameters (payload, topic, retain) within the python_script. You don’t have to restart Home Assistant or reload a python_script for changes to take effect.
There’s also less to process for Home Assistant. If you use ‘Strategy 1: value_template’, a single topic shared by a dozen sensors means each received payload is evaluated a dozen times (more in your case because of multiple bridges). The demultiplexer solution evaluates the payload only twice (first by the automation and then second by the targeted sensor).
Couldn’t agree more.
But you definitely need to pursue for your solution to be included in HA as the current (official) implementation is an… abomination 
I also have a pair of Sonoff RF Bridges running tasmota. These each publish events when they receive some RF transmission from a sensor; each RF Bridge publishes to a unique topic.
I ended up building a really simple flow in Node Red to de-duplicate events, and the publish the result to a single MQTT topic that used by Home Assistant in the same way as if you had a single RF Bridge. I was going to hack up a little python script, but it turns out a really simple flow can be defined in Node Red to solve the problem. I already had Node Red doing some other unrelated pre-processing of MQTT messages, so this was an easy addition.
When I return from travel (or can get my VPN session up to my router at home), I’ll see about capturing the details of how I did this using a “deduplicate” node that’s out there as a “contributed” node. I think I used https://flows.nodered.org/node/node-red-contrib-deduplicate-adv to this end, along with some other plumbing.