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 MQTT.py 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 mqtt.py 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 mqtt.py 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 mqtt.py 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'
trigger:
- platform: state
entity_id: binary_sensor.mqtt_a8
to: 'On'
action:
- service: mqtt.publish
data:
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)
pi@hassbian:~ $ mosquitto_sub -h localhost -t x10/A8
OnOff
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.
Thanks.
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 mqtt.py. 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
https://home-assistant.io/components/binary_sensor.mqtt/
"""
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 (
CONF_FORCE_UPDATE, CONF_NAME, CONF_VALUE_TEMPLATE, CONF_PAYLOAD_ON,
CONF_PAYLOAD_OFF, CONF_DEVICE_CLASS)
from homeassistant.components.mqtt import (
CONF_STATE_TOPIC, CONF_AVAILABILITY_TOPIC, CONF_PAYLOAD_AVAILABLE,
CONF_PAYLOAD_NOT_AVAILABLE, CONF_QOS, MqttAvailability)
import homeassistant.helpers.config_validation as cv
_LOGGER = logging.getLogger(__name__)
DEFAULT_NAME = 'MQTT Binary sensor'
DEFAULT_PAYLOAD_OFF = 'OFF'
DEFAULT_PAYLOAD_ON = 'ON'
DEFAULT_FORCE_UPDATE = False
DEPENDENCIES = ['mqtt']
PLATFORM_SCHEMA = mqtt.MQTT_RO_PLATFORM_SCHEMA.extend({
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_DEVICE_CLASS): DEVICE_CLASSES_SCHEMA,
vol.Optional(CONF_FORCE_UPDATE, default=DEFAULT_FORCE_UPDATE): cv.boolean,
}).extend(mqtt.MQTT_AVAILABILITY_SCHEMA.schema)
@asyncio.coroutine
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
async_add_devices([MqttBinarySensor(
config.get(CONF_NAME),
config.get(CONF_STATE_TOPIC),
config.get(CONF_AVAILABILITY_TOPIC),
config.get(CONF_DEVICE_CLASS),
config.get(CONF_QOS),
config.get(CONF_FORCE_UPDATE),
config.get(CONF_PAYLOAD_ON),
config.get(CONF_PAYLOAD_OFF),
config.get(CONF_PAYLOAD_AVAILABLE),
config.get(CONF_PAYLOAD_NOT_AVAILABLE),
value_template
)])
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,
payload_not_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
@asyncio.coroutine
def async_added_to_hass(self):
"""Subscribe mqtt events."""
yield from super().async_added_to_hass()
@callback
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(
payload)
if payload == self._payload_on:
self._state = True
elif payload == self._payload_off:
self._state = False
self.async_schedule_update_ha_state()
yield from mqtt.async_subscribe(
self.hass, self._state_topic, state_message_received, self._qos)
@property
def should_poll(self):
"""Return the polling state."""
return False
@property
def name(self):
"""Return the name of the binary sensor."""
return self._name
@property
def is_on(self):
"""Return true if the binary sensor is on."""
return self._state
@property
def device_class(self):
"""Return the class of this sensor."""
return self._device_class
@property
def force_update(self):
"""Force update."""
return self._force_updateHi 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 
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.
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
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 mqtt.py.
Working inside config directory, make custom components directory:
mkdir -p custom_components/binary_sensor
Copy currently loaded mqtt.py to above directory:
sudo docker cp home-assistant:/usr/src/app/homeassistant/components/binary_sensor/mqtt.py ./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/mqtt.py
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(
payload)
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)
return
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 
:
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):
binary_sensor:
- 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 mqtt.py from /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/binary_sensor/mqtt.py 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.