Mqtt.py log warning "No matching payload found for entity"

[123 (Taras)]

@AhmadK

I can see no “Solution” checkbox

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.

[Mosl]

I’ve removed the code, but HA will still issue the same warning

[Thomas_Brady]

This post reminds me this is something I need to fix I have 34 of these and growing so much log spam!

[123 (Taras)]

@Thomas_Brady

something I need to fix I have 34 of these and growing

With so many sensors reporting via the same MQTT topic, I would suggest using Strategy 2: Demultiplexer.

[tmharris]

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…

[123 (Taras)]

@tmharris

like to understand the code prior to blindly pasting

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 2C8D0A the template reports ON.
• Otherwise if the received data matches 2C8D0E the template reports OFF.
• 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, 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.

[kriss13 (Cristian)]

• 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

[AhmadK (akasma74)]

@kriss13

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.

[kriss13 (Cristian)]

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: 1

[123 (Taras)]

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:

Sonoff RF Bridge. Strategies for receiving data

Here are two strategies for receiving payloads published by a Sonoff RF Bridge (flashed with Tasmota firmware). Strategy 1: value_template In this strategy, all sensors are subscribed to the same topic published by the RF Bridge. The topic's structure depends on how you defined it when you configured *your* RF Bridge. This example will use `tele/RF_Bridge/RESULT`. Change that to whatever you have set for your Bridge. Because all sensors are subscribed to the same topic, a sensor will receive pa…

[kriss13 (Cristian)]

The problem is that yaml check gives error in the file if I put that template there for the character “%”.

[AhmadK (akasma74)]

it looks like indentation is not right, add a tab in front of every line between value_template and device_class

[kriss13 (Cristian)]

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.

[123 (Taras)]

@kriss13

but the messages still appear in the log just like using the old variant

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?

[kriss13 (Cristian)]

See my above edit

[123 (Taras)]

@kriss13

So ALL sensors need this so none of them will give the “payload” warning in log.

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.

[ee1]

@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.

[KennethLavrsen]

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

[AhmadK (akasma74)]

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.

[KennethLavrsen]

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