log warning "No matching payload found for entity"

Tags: #<Tag:0x00007fd073978588>


So I followed your instructions and it solved the error logging. AWESOME, Thank you!!
My question is how do I know if I need to update the file on an upgrade?

Is there a simple way to know if the file has been updated on the next upgrade? I believe I can edit the new one to take out the offending lines of code but I am not sure where to fined the file or know if it has been upgraded.

Thanks for the solution…


Using the custom component solves the problem of having to modify file each time after HA upgrade. For all platforms if a custom component is defined then it will be used in favor of the component coming from the distribution package.

You could use a scrape sensor to get the state of the PRs for a component from github or set a file size sensor that will compare the size of the sensor after each HA update against the base size.

Alternatively, you can check the release notes of HA for breaking changes in order to see if it was modified or, if there are a large number of MQTT related errors in the log it is likely due to modifications made in the platform (as it was the case with this change). Meanwhile, the custom component works fine.

I’m unsure what the author of the PR was thinking when making the change, but there are perfectly reasonable cases where the old way was fine even if using the same topic (such as the OpenMQTT where all sensors have different payloads although posting to same topic). Regardless, that modification was the cause for many others.


Me too as of my last update, multiple “No matching payload found for entity.” every time a sensor is triggered.

I get these log errors from any of my one way binary sensors on an 433 RF Bridge where each sensor uses a different MQTT payload value on the same rf bridge topic (which in itself was a cludge to get around the lack of a ‘resetting’ binary sensor component). I invested a lot of nights to get that all working well too…


So folks, it seems there is a lot support for rolling back the PR that enabled the extra warning logging. Doesn’t seem to add value to anyone, and instead floods logs. I’m unfortunately not experienced enough with software/open source projects, but what is the process to undo that change? Can someone with more skill who’s hopefully reading this thread roll back the log warning?


Easiest way of solving this is to set a custom component in regard of with the 5 offending lines removed (see post no 17).


I have a binary sensor define as follows

- platform: mqtt
  name: "mqtt_a8"
  state_topic: "x10/A8"
  payload_on: "On"
  payload_off: "Off"
  qos: 0

and the MQTT message payload received is (checked via MQTT.fx)
topic=x10/A8 , payload=On

However i keep on getting

[homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: mqtt_a8 with state_topic: x10/A8
and the binary sensor is never set. What am I doing wrong?


That warning message should not affect the functionality of the binary sensor. I don’t have any X10 devices however, most likely, the problem is that the physical device only sends one code (which is mapped as “On”). As HA receives only On, it cannot use it as trigger for any automation.

If this is the case then the solution is to reset it to off each time an on message is received (see following automation):

- alias: Reset binary sensor state
  initial_state: 'on'
    - platform: state
      entity_id: binary_sensor.mqtt_a8
      to: 'On'
    - service: mqtt.publish
        topic: 'x10/A8'
        payload: 'Off'

As a general rule of thumb, mqtt binary sensors should either i) have the same topic and use different payloads for on and off or (such as a8_on and a8_off; a9_on/a9_off, etc) ii) have different topics (x10/a8, x10/a9) and on and off can be used as payloads as such.

The current implementation of mqtt binary sensor takes into consideration only the second situation while for first case it throws the warning message (the issue is that having a large number of sensors, that send their payload very fast, would completely flood the HA log). The discussion above is in regard of removing the code that generates the issue so single topic with different payloads can be used without affecting the functionality.

The warning message suggests you have different payloads thus multiple sensors firing in the same topic so you should analyse what is the actual situation. Also, mqtt is case sensitive so x10/A8 is different than X10/a8 and x10/a8.


That’s what I’m using (different topics, each with its payload)

[email protected]:~ $ mosquitto_sub -h localhost -t x10/A8


Looks like my Python script was generating an extra linefeed of which on MQTT.fx was not visible. Problem now solved.


Hi all,

Hey was there a move tp roll back the offending PR that’s causing the ‘No matching payload’ errors ?
I’ve just rebuilt my HA RPi setup and was surprised that I still have these errors.
Sure I’ll do the work around as suggested above, but am wondering if this problem is now a permanent feature or not.


sigh I guess the lack of affirmative replies means it is not being addressed.

Does anyone happen to know how to apply the above workaround (remove lines from the .py file) in a docker installation?


@mr.sneezy @ee1 I have this in custom_components/binary_sensor, saved as It fixes the binary sensor problem in the logs.

Support for MQTT binary sensors.
For more details about this platform, please refer to the documentation at
import asyncio
import logging

import voluptuous as vol

from homeassistant.core import callback
import homeassistant.components.mqtt as mqtt
from homeassistant.components.binary_sensor import (
    BinarySensorDevice, DEVICE_CLASSES_SCHEMA)
from homeassistant.const import (
from homeassistant.components.mqtt import (
import homeassistant.helpers.config_validation as cv

_LOGGER = logging.getLogger(__name__)

DEFAULT_NAME = 'MQTT Binary sensor'



    vol.Optional(CONF_NAME, default=DEFAULT_NAME): cv.string,
    vol.Optional(CONF_PAYLOAD_OFF, default=DEFAULT_PAYLOAD_OFF): cv.string,
    vol.Optional(CONF_PAYLOAD_ON, default=DEFAULT_PAYLOAD_ON): cv.string,
    vol.Optional(CONF_FORCE_UPDATE, default=DEFAULT_FORCE_UPDATE): cv.boolean,

def async_setup_platform(hass, config, async_add_devices, discovery_info=None):
    """Set up the MQTT binary sensor."""
    if discovery_info is not None:
        config = PLATFORM_SCHEMA(discovery_info)

    value_template = config.get(CONF_VALUE_TEMPLATE)
    if value_template is not None:
        value_template.hass = hass


class MqttBinarySensor(MqttAvailability, BinarySensorDevice):
    """Representation a binary sensor that is updated by MQTT."""

    def __init__(self, name, state_topic, availability_topic, device_class,
                 qos, force_update, payload_on, payload_off, payload_available,
                 payload_not_available, value_template):
        """Initialize the MQTT binary sensor."""
        super().__init__(availability_topic, qos, payload_available,
        self._name = name
        self._state = None
        self._state_topic = state_topic
        self._device_class = device_class
        self._payload_on = payload_on
        self._payload_off = payload_off
        self._qos = qos
        self._force_update = force_update
        self._template = value_template

    def async_added_to_hass(self):
        """Subscribe mqtt events."""
        yield from super().async_added_to_hass()

        def state_message_received(topic, payload, qos):
            """Handle a new received MQTT state message."""
            if self._template is not None:
                payload = self._template.async_render_with_possible_json_value(
            if payload == self._payload_on:
                self._state = True
            elif payload == self._payload_off:
                self._state = False


        yield from mqtt.async_subscribe(
            self.hass, self._state_topic, state_message_received, self._qos)

    def should_poll(self):
        """Return the polling state."""
        return False

    def name(self):
        """Return the name of the binary sensor."""
        return self._name

    def is_on(self):
        """Return true if the binary sensor is on."""
        return self._state

    def device_class(self):
        """Return the class of this sensor."""
        return self._device_class

    def force_update(self):
        """Force update."""
        return self._force_update

RF devices with Sonoff RF Bridge on Tasmota Firmware: get sensor state on startup

Hi Kanga,

Thanks, yes I did that too now.

It does fix the nuisance error batches for me also, but it would be best for HA if these things got addressed without cludges.
I have an ever growing list of special cludge work arounds like this for my components and sensors (and two unresolved ones), if I ever loose my RPi and backups I’m never going to recover all of these tweaks and I’m going to try a different automation system :slight_smile:


If you’ve got fixes, please do raise a PR (pull request) so that it can get included in Home Assistant. How to submit changes is explained here, but really small ones (fixing typos etc) can be done through the web UI on GitHub in a pinch.


@Sthope See above.


I backup weekly to Google Drive, a USB thumb drive and my PC for this exact reason.


I’m not quite so thorough, SD card and sometime to NAS.

The trouble with all the required tweaks is it’s taking HA far far away from being a simple to use widely compatible system.
When I started the project to use HA on RPi last October, and integrated some stuff in only a day or so of tinkering I thought it was wonderfully easy and told all my friends about it and it’s virtues.
Now days I say nothing, as I don’t want my friends to to hate me for getting them involved :slight_smile:


Thanks @kanga_who, @Petrica

I did something essentially the same. Will post detailed steps here that might help others confidently do this in a Docker installation without worrying about if the code you listed is the most current version of

Working inside config directory, make custom components directory:

mkdir -p custom_components/binary_sensor

Copy currently loaded to above directory:

sudo docker cp home-assistant:/usr/src/app/homeassistant/components/binary_sensor/ ./custom_components/binary_sensor/

Comment out offending lines by adding #. I chose to leave the “else” and “return” and only comment out 3 lines:

sudo nano ./custom_components/binary_sensor/

   def state_message_received(topic, payload, qos):
        """Handle a new received MQTT state message."""
        if self._template is not None:
            payload = self._template.async_render_with_possible_json_value(
        if payload == self._payload_on:
            self._state = True
        elif payload == self._payload_off:
            self._state = False
        else:  # Payload is not for this entity
#                _LOGGER.warning('No matching payload found'
#                                ' for entity: %s with state_topic: %s',
#                                self._name, self._state_topic)

Restart HASS:

sudo docker restart home-assistant

Check that upon start HASS used the custom component:

cat home-assistant.log

WARNING (MainThread) [homeassistant.loader] You are using a custom component for binary_sensor.mqtt which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.

Then enjoy the silence :smile: :

tail -f home-assistant.log


I agree sneezy. The constant tweaking and breaking changes are starting to get old. Got a few friends who like Homeseer for fully local processed HA. Going to stick with HASS for a bit longer though - it has potential.


So the end result of all of this is that we have to hack the core to remove such spam to the log? There has to be a better solution for mqtt traffic that is all sent over the same topic (no way around this). My setup is working well, but I dont see why this was added. Should be an optional verbosity or something for people that do want this specific testing. I already have payload_on and off specified like so (snippet):

  - platform: mqtt
    name: OpenMQTTGateway
    state_topic: "home/OpenMQTTGateway/LWT"
    payload_on: "Online"
    payload_off: "Offline"
    device_class: "connectivity"
  - platform: mqtt
    name: outlet_1_rf
    state_topic: 'home/433toMQTT'
    payload_on: '4543795'
    payload_off: '4543804'
    retain: true
  - platform: mqtt
    name: outlet_2_rf
    state_topic: 'home/433toMQTT'
    payload_on: '4543939'
    payload_off: '4543948'
    retain: true
  - platform: mqtt
    name: outlet_3_rf
    state_topic: 'home/433toMQTT'
    payload_on: '4544259'
    payload_off: '4544268'
    retain: true


I installed home assistant a few days ago and am hitting this issue with 433mhz motion and window sensors using OpenMQTTGateway on an esp8266 as an MQTT broker. IDK who is “correct” here and if each device should use a different topic or not. For now I am implementing a custom_component by copying from /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/binary_sensor/ and commenting out the three lines that spam my log. I’ll have to try to remember to check for other changes to that file after upgrades now. A modification to OpenMQTTGateway would be nice I guess, with the topic as the sensor ID and “on” as the payload.