Home Assistant Community

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

Tags: #<Tag:0x00007fcf4b7df060>

I am using HASSIO 0.89.1 on raspberry, I am not able to find : home-assistant-homeassistant:/usr/src/app/homeassistant/components/mqtt/binary_sensor.py

how did you do it?


Thank you very much.
I was able to imported on nodred, was the quotes used are not valid, I found the following: A flow must be valid json in order to import. You can paste it into https://jsonlint.com to see what errors are detected. after changing the quotes to " now is working


Since v0.89.0-ish custom-components requires all component files, the workaround is unusable especially when uploading via Configurator.

I’ve added a new issue (https://github.com/home-assistant/home-assistant/issues/22172)


I was finally able to apply the patch suggested, but I copied all under MQTT for v0.9 under my custom-folder then commented those 4 lines in binary_sensor.py suggested by kanga_who, this was after successfully using nodRed suggestion by jwoodard80 but in my case having many rf senseros, it was just cleaner doing this directly with the binary_sensor.yaml, I downloaded ver 0.9 from https://github.com/home-assistant/home-assistant/releases and from the home-assistant-0.90.0.zip file i copied the complete mqtt folder inside homeassistant/components/ folder into my custom_components folder, them comment the 4 suggested lines, and I have no more warnings when I have an RF sensor, triggering in a different mqtt bibary_sensor. but fully agree with wmrato this should be reverted on the official release and not being patched


Hi all.
I’m running 0.90.1 and I’ve used @kanga_who suggestion but it’s not working. I still have many errors.
I’ve put in the “custom_components” folder an additional folder named “mqtt” and inside I’ve placed the “binary_sensor.py” file with the 4 lines commented.
What am I doing wrong ?!?


I offer another solution to prevent the “No matching payload” message from appearing.

For an MQTT Binary sensor, the default for payload_on is ON and for payload_off it’s OFF (i.e. uppercase). On the other hand, the state of a binary_sensor can either be on or off (i.e. lowercase). Keeping this important distinction in mind, we can use it to construct a value_template that ensures the payload always matches something and never nothing.

This example assumes Data=2C8D0A indicates the door is open and Data=2C8D0E indicates the door is closed. Here’s the important part, if the payload contains neither 2C8D0A or 2C8D0E, it reports the binary_sensor’s current state. In other words, no matter what it receives in the payload, the value_template always reports a valid state.

- platform: mqtt
  name: 'Bathroom Door'
  state_topic: 'tele/RF_Bridge/RESULT'
  value_template: >-
    {% if value_json.RfReceived.Data == '2C8D0A' %}
    {% elif value_json.RfReceived.Data == '2C8D0E' %}
    {% else %}
      {{states('binary_sensor.bathroom_door') | upper}}
    {% endif %}
  device_class: Door

If you have a sensor that does not report an off state then you can compensate by using the off_delay option.

In this example, Data=E5D30E indicates the motion sensor is on but there’s no command available to indicate when the sensor is off. I have set off_delay: 15 so the motion sensor will automatically set itself to off after 15 seconds.

- platform: mqtt
  name: 'Hallway Motion'
  state_topic: 'tele/RF_Bridge/RESULT'
  value_template: >-
    {% if value_json.RfReceived.Data == 'E5D30E' %}
    {% else %}
      {{states('binary_sensor.hallway_motion') | upper}}
    {% endif %}
  off_delay: 15
  device_class: motion
0.90: Remote UI, Streams, User Groups

I have the same problem, but I can not resolve with off_delay function.
I’m using it for alarming ON and alarming OFF.

So delay is not option, because I can not turn OFF alarm by time, but need to read OFF data…

Maybe (I will try this week) my solution for alarming is allways to use ON function but with diferrent received data… based on that maybe I can do action… will see…


I agree. The example I provided was applicable for a motion sensor.

Your situation requires turning an Alarm on and off. Obviously any time-based solution to turn it off is inappropriate.

I don’t see how you can do what you need using a single RF button that sends one state. You would need to use two such buttons, one to set Alarm to on and another button to set the Alarm to off.


I’m using 2 alarms in HA, one with DSC and one with HA.
For HA I’m using button A and button B, for DSC I’m using button C and button D.
I have RF key with 4 buttons… The problem is that now I’m using 2 Sonoff RF bridge receives, so I must figure how to manage this… but firstly RF bridge No.1 must be working to turn ON/OFF (currently only ON is working - before was working all fine)… I will report with code how I did it…


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


Yes… But before 0.90.x was working fine…


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


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":""}]

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


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.


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.


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.


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

1 Like

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.


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?


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 :slight_smile: 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.