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

mqtt
Tags: #<Tag:0x00007fd073b0c048>

#1

After upgrading to .63 from .58 I have warnings in the log file every time HASS gets an MQTT message seemingly complaining about no matching payload, even though the message payload matches the definitions in the binary sensor.

Log messages:

2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor7 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor6 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor3 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor5 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor4 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor2 with state_topic: unosensor
2018-02-11 14:35:33 WARNING (MainThread) [homeassistant.components.binary_sensor.mqtt] No matching payload found for entity: sensor1 with state_topic: unosensor
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor7 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.7528663>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor6 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.753482>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor3 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.7538924>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor5 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.7542672>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor4 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.754615>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor2 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.754946>
2018-02-11 14:35:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: exception=, message=No matching payload found for entity: sensor1 with state_topic: unosensor, level=WARNING, source=components/binary_sensor/mqtt.py, timestamp=1518377733.7552676>

Binary sensor definitions:

binary_sensor:

  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor1
    payload_on: "1_ON"
    payload_off: “1_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor2
    payload_on: "2_ON"
    payload_off: “2_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor3
    payload_on: "3_ON"
    payload_off: “3_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor4
    payload_on: "4_ON"
    payload_off: “4_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor5
    payload_on: "5_ON"
    payload_off: “5_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor6
    payload_on: "6_ON"
    payload_off: “6_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor7
    payload_on: "7_ON"
    payload_off: “7_OFF”
  • platform: mqtt
    state_topic: "unosensor"
    device_class: safety
    name: sensor8
    payload_on: "8_ON"
    payload_off: “8_OFF”

Confirmation that payloads do indeed match by subscribing to the same topic:

:/var/opt/homeassistant$ mosquitto_sub -h 127.0.0.1 -p 1883 -t unosensor
1_OFF
2_OFF
3_OFF
4_OFF
5_OFF
6_ON
7_OFF
8_OFF

Interstingly the sensors do seem to reflect the intended state (on or off based on MQTT payload), but still get the warnings in the log. Any ideas?


Help with mqtt templating (from Domoticz)
Sonoff RF bridge - getting bombarded with No matching payload found for entity warnings
433toMQTTto433 Bidirectional Arduino Gateway
Problems withe Sonoff RF Bridge and HA
Automation's not working after recent update
#2

This is related to this change : https://github.com/home-assistant/home-assistant/pull/11836

Apparently some guy tought it would make sense to trigger a Warning when a recevied message is not either matching “payload_on” or “payload_off” for any entity listening to the topic.

So, if you have 8 entities listening to the same topic, you would have warnings (7) on the ones who arent supposed to be reacting…


#3

It’s a bit strange to have all of your devices listening to the same topic but expecting different payloads, but as a result this is expected behaviour and you can ignore the warnings.


#4

well we’re not the only ones : 433mhz, infrared IR to and from MQTT on ESP8266

This project is a gateway relaying all 433mhz codes recevied to one topic :slight_smile:


#5

Thank you @pixeye33 and @marthocoo for confirming I don’t actually have a problem.

@marthocoo I don’t think it’s strange at all. For some context on my project, it’s a custom built wired security panel that ultimately relies on an Arduino Uno to relay sensor state via MQTT. So the Arduino can have any number of sensors on one device. It’s essentially a multi-entity device. It would not be practical for every sensor to publish on a sifferent state topic. For example, if I deploy 5 such Arduino’s with a dozen sensor inputs on each I would need to subscrube to 60 topics.

MQTT is intended as a many-to-many communication protocol, so it’s very reasonable to broadcast messages to multiple entities even if some may not be interested to some of those messages.


#6

I agree that this use case isn’t something that should be generating warnings.

This change should be reverted, unless a better case can be made for the warnings; in which case, there should not be a warning logged for every entity listening to a topic without a matching payload, but rather once per topic, only if none of the entities listening to it don’t find a matching payload.

I realise that would not be a small change, but if it’s not worth making then I think it just highlights how this is logfile-bloating at best.

I don’t want to have to disable warnings for this, but I can’t have 8 (who knows how many others have) warnings every time a 443mhz payload is sent to MQTT.


#7

Thanks for pointing out! After adding the payload_on and payload_off to my binary_sensor the error msg is gone and working again :slight_smile:


#8

Actually, that is what wildcards are for. I can subscribe to the states of all of my lights with “home/#/lights”

However, I do agree it was a bad idea to add the warning. The warning was added because someone didn’t like an else statement that did nothing. The reality is that empty else is sort of a hack to stop state updates when nothing changes. I don’t use it myself, but I can see the use cases.


#9

is there not a voting process before potentially flooding peoples log?

why was this changed when its not universally beneficial?


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


#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


#14

if you think it is necessary we can implement this ft which should resolve this issue:


#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

Integrating RF devices with sonoff rf bridge on Tasmota Firmware
#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:


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