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

Development
121

Can I just add a further complication? (For fun?)
I have more than one RF Bridge* so my automations have to have different dictionaries which made it a lot harder to construct without errors. I’m not complaining I like the result but I leave it as an exercise for you if you’d like to consider a ‘super-deluxe’ method.

*I have three actually, which I now think is overkill but I was having some problems with dead spots causing some sensors to be unreliable no matter where I placed the Bridges. I still occasionally get sensors stuck in the ON position so I wonder if it is just cheap sensors not performing properly or something else going on^. I am however not sure that the third Bridge was necessary. But even so, because of the layout of my house I do need two.

^Comments welcome if this could be something I am overlooking in the processing. Thinking, as I write this, I am wondering if two sensors firing simultaneously could cause one to not be registered by HA in time?

122

I’d just keep things simple and use three independent demultiplexer automations (i.e. one per RF bridge).

Don’t forget that the root cause of this ‘fun’ is the fact the RF bridge publishes everything to one topic. There aren’t too many ways to handle this arrangement. Either you have all sensors subscribed to the RF bridge’s single topic (or in your case to one of three different RF bridges) or one automation that creates multiple topics, one per sensor. Both solutions have pros and cons and it’s up to the user to ‘pick their poison’.

There’s no escaping the ‘lots of editing’ task. It’s either going to be in creating big dictionaries for the automation or in creating templates for every sensor. As the saying goes: Six of one, half a dozen of the other. :slight_smile:

123

Can you mention what RF bridge do you use?

If you’re not already using it, you might want to have a look at OpenMQTT Gateway as, for multiple RF bridges connected to same topic, the de-duplication is done at bridge level (so no need for multiple topics to be dealt with by HA); RF signal is picked up by the closest bridge and case the other bridges pick it up too, then it won’t be published if it occurs in a 2 to 3 seconds interval after initial publish. But again, this requires bridges to subscribe to same MQTT topic but to have different board names.

124

On this topic. Is that the main difference / benefit of using Tasmota flashed Sonoffs RF Bridge Vs a OpenMQTTGateway flashed Sonoffs RF bridge?

125

Do you know if it’s possible to create a python_script which does the job of preparing all three values AND then publishes a message?

126

Have I done it? No.

But it might be fun to try. :slight_smile: (… and I leave it as an exercise for someone else)

Based on the example shown in the documentation, I expect it would provide more flexibility.

127

Which is what I’ve done, and as I said I am happy with the results and I don’t expect to have to edit the three automations again (ha ha!!!) so now it is done I can forget it…

(I was just fishing in case there was a super-deluxe option. I didn’t expect it though.)

They are Sonoff RF Bridges flashed with Tasmota. I was, once upon a time bridging with Open MQTT Gateway to use Owntracks but I have long since closed that open port and moved away from having any open. (I can use VPN now if I need remote access).

128

I couldn’t resist experimenting with python_script. :slight_smile:

It offers several advantages:

  • It’s far simpler than using templates.
  • There’s only one instance of the ‘command dictionary’.
  • The dictionary is easier to maintain.
  • Because it’s a python_script, you can add items to the dictionary without having to restart Home Assistant.

To make this work, you have to configure Home Assistant to use the python_script component.

  1. Add python_script: to your configuration file.
  2. Create the following sub-directory: config/python_scripts
  3. Restart Home Assistant.

Create a new file in config/python_scripts called rfbridge_demux.py with the following contents:

d = { 'A1A':['sensor1','ON','true'],
      'A2A':['sensor1','OFF','true'],
      'B1B':['sensor2','ON','false'],
      'C1C':['sensor3','ON','false']
    }

p = data.get('payload')

if p is not None:
  if p in d.keys():
    service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
  else:
    service_data = {'topic':'home/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
    logger.warning('<rfbridge_demux> Received unknown RF command: {}'.format(p))
  hass.services.call('mqtt', 'publish', service_data, False)

Obviously you will have to modify the dictionary so it contains your RF bridge’s commands. The format of each item in the dictionary is straightforward:
'payload':['topic','state','retain']

Here’s the required automation. It’s much simpler than the previous version using templates.

- alias: 'rfbridge_demultiplexer'
  trigger:
  - platform: mqtt
    topic: tele/RF_Bridge/RESULT
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.RfReceived.Data}}'

I tested it and can confirm it works. Feel free to modify rfbridge_demux.py to suit your specific needs.

1 Like
129

And you made my day! Thanks man. Great stuff, will think about it when I wake up properly :slight_smile:
Yesterday I spent re-thinking my configuration and came up with another solution.
In my case (PIRs/smoke detectors, 3-state door contacts) it is not that reasonable to have separate MQTT topics as only multi-code devices struggle from that “No matching payload” warning (yeah, we are still on this topic) and it can be easily avoided by defining a proper value_template/payload_xxx combination.
So I took a combined approach based on some demuxing - currently I have 1 per code type per device type (meaning one for PIRs, one for smoke detectors and 3 for 3-state door contacts). It’s compact and relatively easy to maintain when you get an idea… :wink:

I think we can stop spamming this topic with it and I’m going to create a separate one in Share your project section to describe my approach so others can find it easier and discuss/improve etc.

Anyway, you did a fantastic job here and I think the topic problem is solved now with plenty of options available.

130

Tag the post as ‘solution’ so others can find it easily in this long thread.

131

I’d love to, but I can see 2 problems here

  1. You gave us MORE than one solution and and it’s up to a reader to decide which one works best for them.
  2. I can see no “Solution” checkbox - think you have one if you are a topic starter but I’m not :wink:
132

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.

133

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

134

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

135

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

136

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…

137

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.

2 Likes
138
  • 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

139

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.

140

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