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

123 · March 24, 2019, 7:48pm

Are you getting “No matching payload found for entity” WARNING messages in your log?

kslb · March 24, 2019, 7:57pm

Yes… But before 0.90.x was working fine…

123 · March 24, 2019, 8:03pm

That’s the story of Home Assistant in a nutshell.

ivladz · March 24, 2019, 8:10pm

I took another route to “solve” this issue/limitation.
I’ve created a flow in NodeRed for each sensor that listen on the common MQTT topic (let’s say “/home/OpenMQTTGateway/433toMQTT”) and then publishes “on”/“off” to a topic dedicated to that specific sensor based on the RF codes.

Here is one of the flows:

[{"id":"e888d4cc.d27748","type":"mqtt in","z":"36c2f961.cc6cc6","name":"","topic":"home/OpenMQTTGateway/433toMQTT/#","qos":"0","datatype":"auto","broker":"6398ff0c.afd62","x":160,"y":230,"wires":[["d77d794e.908848"]]},{"id":"d77d794e.908848","type":"json","z":"36c2f961.cc6cc6","name":"value","property":"payload","action":"","pretty":false,"x":160,"y":280,"wires":[["291ede36.c1bf02"]]},{"id":"291ede36.c1bf02","type":"function","z":"36c2f961.cc6cc6","name":"Vlad DoorA","func":"value = msg.payload.value.toString();\nif (value == \"3169034\") {\n    msg.payload = \"on\";\n    return msg;\n} else if (value == \"3169038\") {\n    msg.payload = \"off\";\n    return msg;\n} else {\n    return null;\n}\n","outputs":1,"noerr":0,"x":360,"y":280,"wires":[["32e87ea3.ff8ad2"]]},{"id":"32e87ea3.ff8ad2","type":"mqtt out","z":"36c2f961.cc6cc6","name":"","topic":"/home/sensor/door/vladrooma","qos":"1","retain":"false","broker":"6398ff0c.afd62","x":650,"y":280,"wires":[]},{"id":"6398ff0c.afd62","type":"mqtt-broker","z":"","name":"mosquitto-hassio","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

xenio · March 24, 2019, 8:14pm

I am on 0.90.1 and the only way to make it works is to copy the entire folder /components/mqtt from the source code and copy it to custom_components/ commenting the LOGGER lines on binary_sensor.py
I think copying only the file binary_sensor.py does not works because of dependencies.
With the full folder I am getting warnings override for: mqtt.switch, mqtt.sensor, mqtt.light and the one we need mqtt.binary_sensor

123 · March 24, 2019, 8:33pm

Your solution is what I offered to someone else in this thread. I used an automation but the principle is the same, namely you create a ‘demultiplexer’. Payloads from the single topic are re-published into individual topics.

home/rtl_433 ==> DEMUX ----> home/sensor1
                       |
                       |---> home/sensor2
                       |
                       |---> home/sensor3
                       |
                       |---> home/sensor4
                       |
                       |---> home/sensor5

home/sensor1 ==> Sensor1
home/sensor2 ==> Sensor2
home/sensor3 ==> Sensor3
home/sensor4 ==> Sensor4
home/sensor5 ==> Sensor5

I also posted the demultiplexer automation in the same thread. It’s for payloads from rtl_433 but easily adapted for other RF bridges.

BTW, if you are using OpenMQTTGateway, there’s a post within this thread, by @1technophile , explaining how to make it publish to one topic per sensor. If you make his suggested modification, there’s no need for demultiplexing.

EDIT

Here’sanother example of demultiplexing and is for a Tasmota-based Sonoff RF Bridge and assumes Sync contains a unique identifier for each RF button.

123 · March 24, 2019, 8:36pm

I’m using 0.90.1 and can confirm that the solution I provided above does not need a custom MQTT component. My MQTT binary_sensor is using the 0.90.1 release version of the MQTT component and, with my suggested solution, the sensors do not cause the “No matching payload …” message to appear.

ivladz · March 24, 2019, 8:43pm

BTW, if you are using OpenMQTTGateway , there’s a post within this thread, by @1technophile , explaining how to make it publish to one topic per sensor. If you make his suggested modification, there’s no need for demultiplexing.

Well, it’s one topic per value as far as I understood. I have a door sensor that sends 2 codes, and I would need a binary_sensor subscribed to these 2 topics (can this even be done?).
Anyway, the demultiplexer solution gives me more control and with less configuration in home assistant.

I may have stumbled upon your post about the automation demultiplexer while trying to figure this out and this was what inspired me to go this route.
So, for that, I want to say thanks

123 · March 24, 2019, 8:48pm

I also use Node-red and, when I first encountered this issue, my first thought was to create a flow to demultiplex the MQTT topic. Then I challenged myself to create an automation to do it … and it was easier than I thought. Whether Node-red or an automation, as long as it gets the job done.

AhmadK · March 25, 2019, 8:36am

Apparently that “topic per value” approach is best suitable suitable for one-code devices.
But in a case like yours there’s still hope.
For example, you can create 2 automations (each subscribe to its topic) that change state of an input_boolean, and a template sensor that reflects its state if you prefer something fancier that a toggle switch in your GUI.
I haven’t tired it yet (too many devices to convert), but it should work.

I believe there are other ways to do that, anyone?

Petrica · March 25, 2019, 8:48am

If not upgrading that often, can still do brain surgery with a hammer and modify the binary_sensor.py directly in the site-packages folder It will be overwritten each time a new HA version is installed, though.

Best way to solve this is to reverse the PR that introduced the warning in the first place.

AhmadK · March 25, 2019, 8:52am

I started from there, but read this and my next post.

AhmadK · March 25, 2019, 8:53am

Ok, I think I got it, thanks to @123 .

An MQTT binary sensor HAS to know its state, and it can be done either by providing value_template that returns ON/OFF (default payload_on/payload_off values) OR making sure payload_on and payload_off are the only values that being published to that topic.
Having only payload_on and payload_off defined and allowing something that is not matched by above mentioned payloads to be published to that topic triggers that warning.
So basically that warning means: look, your MQTT switch received a message, but couldn’t react (as there is no corresponding rule in a form of payload_xxx OR value_template ), something is wrong with your configuration.
Pretty obvious, isn’t it.

And there are at least 3 ways to get rid of that warning with binary_sensors:

Provide value_template definition that returns only ON/OFF
Provide payload_on and payload_off AND make sure these are the only 2 values that are allowed in that topic.
Provide value_template definition that returns only payload_on or payload_off values

I’m off to fix my switches

Petrica · March 25, 2019, 9:23am

But it’s not wrong OpenMQTT binary sensors work fine while removing the four lines in the binary_sensor.py.

Anyway, I can’t test it but for binary sensors that only use one value (switches, PIR sensors) an automation that forwards each payload into its separate mqtt topic could be used and then change the binary sensor topic (for open door sensors or other devices that send two codes it needs templating).

- platform: "mqtt"
  name: "friendly_name"
  state_topic: "home/433toMQTT/code_from_device"
  payload_on: 'code_from_device'
  payload_off: 'off'
  force_update: true
  off_delay: 1


- alias: OpenMQTT forward
  initial_state: True
  trigger:
    - platform: mqtt
      topic: 'home/433toMQTT'
  action:
    - service: mqtt.publish
      data_template:
        topic: 'home/433toMQTT/{{trigger.payload}}'
        payload_template: '{{ trigger.payload}}'

AhmadK · March 25, 2019, 9:33am

yes, it’s not wrong.
I presume the author just wanted to make easier debugging situations like “Why on Earth my sensor is not working?!” as potentially that can happen.
And yes, you can get rid of these warnings just by fixing your config and not touching the HA code, result!

yes, there are many ways to skin a cat
I use input_booleans and this automation (one per device)

- alias: "[int] pir__catch_code__groung_floor__hall"
  initial_state: true
  trigger:
    platform: mqtt
    topic: !secret rf_bridge__topic
  condition:
    condition: template
    value_template: "{{ (trigger.payload_json['value'] == 13937454) and (states.input_boolean.pir_groung_floor_hall.state == 'off') }}"
  action:
  - service: input_boolean.turn_on
    data:
      entity_id: input_boolean.pir_groung_floor_hall
  - delay: !secret pir__reset_indicator_interval
  - service: input_boolean.turn_off
    data:
      entity_id: input_boolean.pir_groung_floor_hall

but maybe it’s time to enable value as topic suffix and replace it with MQTT binary sensor with off_delay…

UPDATE: here is my version for PIRs - instead of input_boolean and automation I can have just

- platform: mqtt
  name: pir_1st_floor_landing
  state_topic: !secret pir_1st_floor_landing_topic
  value_template: 'ON'
  device_class: motion # this bit can be moved to customize_glob.yaml for all pir_*
  off_delay: !secret pir_off_delay

I like it!

123 · March 25, 2019, 12:28pm

I imagine the automation you posted was meant to represent the concept and not a working example? These lines below will produce a horrendously long MQTT topic because the typical payload is a long string in JSON format.

    - service: mqtt.publish
      data_template:
        topic: 'home/433toMQTT/{{trigger.payload}}'
        payload_template: '{{ trigger.payload}}'

Ideally, you want to demultiplex tele/rf_bridge/RESULT using each sensor’s unique identifier, or its unique payload, instead of its entire payload. I’ve already supplied links to two other relevant examples of demultiplexer automations (see above), but it’s worth repeating at least one of them.

In this post, the assumption is the RF buttons are uniquely identified by Sync.

  - alias: 'sonoff bridge demultiplexer'
    hide_entity: true
    trigger:
      platform: mqtt
      topic: tele/sonoff/RESULT
    action:
      service: mqtt.publish
      data_template:
        topic: "home/button/{{trigger.payload_json.RfReceived.Sync|string }}"
        payload: 'ON'

Binary_sensors are defined for each RF button:

  - platform: mqtt
    name: "Button 1"
    state_topic: "home/button/13550" # <--- 13550 comes from Sync
    off_delay: 1

  - platform: mqtt
    name: "Button 2"
    state_topic: "home/button/13560"
    off_delay: 1

If Sync can’t be used to uniquely identify the RF device, then the recourse is to use the device’s payload which is often represented by Data.

    action:
      service: mqtt.publish
      data_template:
        topic: "home/button/{{trigger.payload_json.RfReceived.Data|string }}"
        payload: 'ON'

  - platform: mqtt
    name: "Button 1"
    state_topic: "home/button/2B4AC"
    off_delay: 1

This works as long as the RF devices only report when they are on and not off such as certain models of motion sensor, RF button, and contact sensor (that’s the same constraint you mentioned for your automation example).

If the RF devices report both their on and off states (two payloads), yet have no unique identifier within the payload, then this simplistic demultiplexing automation is no longer useful. It will produce two topics per sensor and that’s unusable for MQTT Sensor or Binary Sensor.

For this situation, the automation’s data_template requires a more complex template that is aware of each sensor’s Data payload, representing on and off, and forwards it to the sensor’s single topic. It’s not difficult, just more work.

Petrica · March 25, 2019, 12:34pm

Nope; it is a working automation for use with OpenMQTT 433Mhz gateway (codes received from the 433Mhz devices are up to 10 char in length if not using the JSON functionality for the payload). Agree that using JSON payload in the topic is a no go.

klogg · March 25, 2019, 2:58pm

For PIRs with only one state I use the method given by @123

Am I missing something* or is there a down side to this solution, because I can’t see one? All the other solutions seem to require more code.

*Serious question, not trying to be difficult.

123 · March 25, 2019, 3:19pm

None that I’m aware of.

FWIW, if there are many sensors, my preferred solution is the demultiplexer because I believe it’s more efficient. Here’s why:

Imagine you have ten binary_sensors and all are subscribed to one topic: tele/rf_bridge/RESULT.
Each time the topic has a new payload it’s evaluated ten times (once by each binary_sensor).

Using a demultiplexer:

Each time the topic has a new payload it’s evaluated by the automation which forwards the payload to a specific topic.
The binary_sensor subscribed to the topic evaluates the payload.

That’s a maximum of two evaluations for every payload as opposed to ten per payload.

So if you only have 2 or 3 devices then the demultiplexer automation and the template-based solution are equally efficient. However, when there are many devices, the demultiplexer has the advantage.

klogg · March 25, 2019, 3:51pm

Good point. But (and I haven’t entirely thought this through…) how does this method deal with a mix of sensors some of which have two states and some only one. Specifically, what if you wish to retain the states of door/window sensors which have two states but do not want to retain states of PIR sensors which have only one?

The demultiplexer would presumably need a (possibly very) complex template to decide when to retain?