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

Development
10

Hello, I agree with this point of view. why was this changed when its not universally beneficial?
I am using OpenMQTTGateway that use the same topic for a lot of 433 sensors, so I have a lot of error in my log. It is really bad for my.
Thanks.

2 Likes
11

Same issue for me, logs flooded with errors. Also using the 433toMQTT ESP8266 Gateway which requires all subscibed to topic home/433toMQTT with different payloads.

12

Same problem is here. I’m also using the 433toMQTT ESP8266 Gateway. And getting too many warning in log files. It’s disturbing…

13

ditto for me. 433toMQTT gateway is great, but so many errors in log

1 Like
14

if you think it is necessary we can implement this ft which should resolve this issue:
https://github.com/1technophile/OpenMQTTGateway/issues/170

15

Hi Florian,

I don’t think that is highly useful to modify the unique topic functionality (at least until implementing json payload).

For a fairly number of 433 Mhz devices (about 30 - PIR sensors, wall switches and plugs remotes) it works fine with the same topic; also, considering that some of these send on and off (or need to) there is quite some heavy traffic between HA and the MQTT server. Even so, 1m processor load (Ubuntu Server VM on a Core i5 4th gen NUC) barely spikes above 0.40 when more than 6 or 7 MQTT devices were simultaneously firing events.

Due to the PR mentioned above, for each sensor triggering there are 100 or so warning messages and 1m processor load easily passes 2.00 or even 2.50 and then keeps it high for several minutes.

Simply removing the PR from mqtt.py (the 5 rows below) and chmod 444 solved the problem so I’m against modifying the unique topic, at least for now :slight_smile:

        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
16

Hi @Petrica

Thanks for the feedback. And these measures.

I will see if the modificationcan be done in the scope of json implementation.

17

Simply removing the PR from mqtt.py (the 5 rows below) and chmod 444 solved the problem

sorry for stupid question but where can i find mqtt.py in hassio?

18

@typeonegative you can donwload this https://github.com/Sthopeless/HA-Playground/blob/master/mqtt.py and put it inside custom_components\binary_sensor\ inside the configuration folder.

The changes are already done :slight_smile:

3 Likes
19

@Sthope thank you!

20

First problem I found log warning “No match payload found for entity” when the binary_sensor is offline (switch off) which cannot be found or get respond by HA.

Secondly, other binary_sensor which is online (switch on). Show correctly in HA. However, in homekit display crazy open/closed.

Example. I have 5 binary_sensor of door sensor. door 1 - door 5. When door 1 open in HA show correctly but in homekit show all door 1 - door 5 open and closed again and again which don’t show the correct door open.

21

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…

22

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.

23

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…

24

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?

25

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).

26

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?

27

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.

28

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.

29

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.