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

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
On

Off

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_update
2 Likes

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:

1 Like

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

tail -f home-assistant.log

1 Like

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

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.

yep, It is planned here

1 Like

This fix seems to have been broken in 0.86.0. I have tried making a new folder under custom_components called mqtt/binary_sensor, and placing the file in there, but have had no success.

My Logs are being flooded once again. :frowning:

Are you sure that’s the right folder structure? mqtt.py is supposed to be in /custom_components/binary_sensor/

Or did something change? I’m still on 0.78.3 and haven’t been keeping up with release notes.

Yeah, MQTT has been changed with 0.86.0 from what I can tell. Everything that works under the umbrella of MQTT now goes in an MQTT folder, not the type of item, such as binary_sensor. I hope that makes sense.

I think I have just managed to fix it in Docker, 0.86.0 for anyone else interested.

My Docker container is called home-assistant-homeassistant currently, so rename yours to whatever your container name is and the path to your configs. Mine is at /home/homeassistant.

The custom_components folder now needs to have an MQTT folder, and then the file named binary_sensor.py

SSH into your machine and execute the following (for Docker).

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

Open (sudo nano) the binary_sensor.py file and comment out these lines, 144, 145, 146 & 147

else: # Payload is not for this entity
# _LOGGER.warning('No matching payload found'
# ' for entity: %s with state_topic: %s',
# self._config.get(CONF_NAME),
# self._config.get(CONF_STATE_TOPIC))
return

Reboot, and sorted! No more log spam again :slight_smile:

2 Likes

Excellent. I’m sure you just saved me at least an hour of my life for when I do get around to upgrading. Thanks.