Remove 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
1 Like
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.
1 Like
@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.
1 Like
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
1 Like
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.
I think we park the discussion about classification and words here. I still love you, anyway
As I said above I like both solutions and it is an individual thing which one is best. For I like to understand what I am doing and I have a background with Pascal, C, and Perl but not Python. Yet! The value_template was easy to understand and maintain for me. But reading your script and how brief it is I will study it in near future - if nothing else then to learn as the python script feature in HA seems pretty powerful
From a performance point of view my HA runs on a machine that only runs HA and has plenty of CPU power. And it is also part of the decision that the RF sensor solution is one I plan to use less as it is not that reliable a technology. Soon I will have a few outdoor Motion sensors and a couple of RF buttons.
The performance gain is an interesting thing to dig into.
The value_template as you correctly say means that HA will evaluate each message on the common topic once per sensor. But CPU cycles are cheap compared to I/O. Once the MQTT message is loaded I cannot imagine it takes many CPU cycles to repeat the matches for each sensor.
The multiplexing method however means sending the result of the multiplexing to the MQTT broker as a TCP/IP communication and is also involves a delay in the broker. I bet you need to have 100+ sensors before the multiplexing method is faster. Maybe on a Raspberry Pi the gain is more significant but with an Intel based fast PC it will be the I/O between HA and MQTT broker that becomes the significant delay.
This does not take away the fact that the multiplexing solution is very elegant and performance is probably still so fast that noone notice.
I agree with you that the difference in performance may be difficult to perceive on anything other than a low-performing platform. Nevertheless, when given a choice, it seems prudent to choose the more efficient solution.
Donāt overlook the fact that most everything having to do with Home Assistant is based on python, an interpreted language. In contrast, the mosquitto MQTT broker is written in C and compiled for the target platform. The pub-sub cycle is executed very fast, especially if the client and broker are on the same host. Even if the two are hosted on a separate machines, transit time is negligible on a 100 Mbps or (1 Gbps) ethernet connection (and the payload typically fits into a single TCP packet).
Another advantage of Strategy 2 is that it leaves the door open to additional enhancements. For example, one could implement support for Home Assistantās MQTT Discovery. That would eliminate the need to manually add sensors to the config file.
I leave enhancements to Strategy 2 an exercise for someone else (I donāt even own a Sonoff RF Bridge).
Another solution could be a differenciation of the RF value published by OMG into 2 , one as an RF sensor identifier and one as the sensor state.
If we add the RF sensor identifier to the topic, and just publish a state payload it should answer the need isnāt it?
Example with a GS WDS07:
- decimal value when close 2952974 -> unit 61620 / state: closed
- decimal value when open 2952970 -> unit 61620 / state: open
Will give the following publishing:
- OpenMQTTGateway/433toMQTT/61620 {state:ācloseā}
- OpenMQTTGateway/433toMQTT/61620 {state:āopenā}
This approach could also a first step for an MQTT convention support like Homie
Yes. I use the WDS07 as Window sensors. But how will you get that Unit code? The sensor sends two codes. One for closed and one for open (and some codes also for battery low I believe).
But to use it the Gateway software has to know a common ID fingerprint of the two so the open and close are published to the same topic name. Where do you get the 61620 from? I cannot see any data received from the sensor that connects the open and close data to the same physical sensor.
Here is the trick:
2952974 -> bin 1011010000111100001110
2952970 -> bin 1011010000111100001010
The 20th digit correspond to the sensor state.
If we take the first 19 digits we could use it as an identifier, they are indeed a constant depending on the sensor.
61620 and this proposal comes from the pilight decoding method discussed here