Tag the post as ‘solution’ so others can find it easily in this long thread.
I’d love to, but I can see 2 problems here
- You gave us MORE than one solution and and it’s up to a reader to decide which one works best for them.
- I can see no “Solution” checkbox - think you have one if you are a topic starter but I’m not
Now that you mention it, neither do I. You’re right, only the threadstarter can do that. Oh well, people will just have to wade through the thread.
I’ve removed the code, but HA will still issue the same warning
This post reminds me this is something I need to fix I have 34 of these and growing so much log spam!
With so many sensors reporting via the same MQTT topic, I would suggest using Strategy 2: Demultiplexer.
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.
- If the received data matches
2C8D0Athe template reportsON. - Otherwise if the received data matches
2C8D0Ethe template reportsOFF. - If the received data matches neither, the template is still obliged to report a valid value so it reports the current state of
binary_sensor.bathroom_door. In other words, thevalue_templatereports 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.
2 Likes
- platform: mqtt
name: “Front Door”
state_topic: “sonoff_hub/tele/RESULT”
value_template: ‘{{value_json.RfReceived.Data}}’
payload_on: “2B810A”
payload_off: “2B810E”
device_class: door
qos: 1
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
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