Log full of: No matching payload found for entity

Hi there. I need help to diagnose the problem.
Some time ago I’ve started adding binary sensors on mqtt platform which are collected from Sonoff RF bridge (Tasmota)

  • platform: mqtt
    state_topic: “tele/rf/RESULT”
    name: ‘PIR Hall 1’
    value_template: ‘{{value_json.RfReceived.Data}}’
    payload_on: ‘1C1DB0’
    off_delay: 3
    device_class: motion
    I have more than 20 of this inputs in my config.yaml. They seem to working fine but my logs are full of:
2020-03-02 12:19:28 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Window Bathroom with state topic: tele/rf/RESULT. Payload: FA1C5E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:28 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: PIR Hall 1 with state topic: tele/rf/RESULT. Payload: FA1C5E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:28 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: PIR Hall 2 with state topic: tele/rf/RESULT. Payload: FA1C5E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: PIR Hall 3 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB3 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: PIR Stairs with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB4 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB5 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB6 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB7 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")
2020-03-02 12:19:31 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: SonoffB8 with state topic: tele/rf/RESULT. Payload: FA502E, with value template Template("{{value_json.RfReceived.Data}}")

This is only small bit of log. Where I made mistake? Anyone can see anything obvious?
Thanks

I assume the problem is that all sensors have the same value_template and if that doesn’t match the configured payload_on , it raises the warnings.
As it’s only a warning you could set the logger to ignore these.

logger:
  default: warn
  logs:
    homeassistant.components.mqtt.binary_sensor: error

I recommend you implement the second strategy (Demultiplexer) presented here:

It not only eliminates the warning message, it simplifies the configuration of each sensor, and reduces the work done by Home Assistant when it receives data for the 20 sensors.

1 Like

The second strategy seems to be quite complicated for me as a new in HA and coding in overall.
Obviously I will give it a try. But if no success - I will go with short and easy way :wink: to ignore error

Many thanks for response

There’s no question that hiding the warning messages is the easiest solution. Preventing the warning messages requires more work (but not that much).

You currently have 20+ sensors and each one’s configuration looks something like this:

- platform: mqtt
  state_topic: tele/rf/RESULT
  name: "PIR Hall 1"
  value_template: "{value_json.RfReceived.Data}}"
  payload_on: "1C1DB0"
  off_delay: 3
  device_class: motion

That 20 x 7 lines = 140 lines of configuration.

If you use Strategy 2, each sensor’s configuration is reduced to:

- platform: mqtt
  state_topic: home/pir_hall_1
  name: "PIR Hall 1"
  off_delay: 3
  device_class: motion

That’s 20 x 5 = 100 lines of configuration (you can reduce it a bit more if you use YAML anchors and aliases).

The only so-called “coding” you need to do is to simply define each sensor’s configuration within rfbridge_demux.py. For example, here’s the configuration for four motion sensors (you would need to supply the actual RF codes):

d = { '1C1DB0':['pir_hall_1','ON','false'],
      '2C8D0E':['pir_hall_2','ON','false'],
      'E5D30E':['pir_hall_3','ON','false'],
      '30D8A0':['pir_stairs','ON','false']
    }

That’s no more difficult than configuring the 20+ sensors you’ve already done.

Thanks.
This all looks not so complicated, but what concerns me is the lines below in the tutorial provided:

p = data.get('payload')

if p is not None:
  if p in d.keys():
    service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
  else:
    service_data = {'topic':'home/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
    logger.warning('<rfbridge_demux> Received unknown RF command: {}'.format(p))
  hass.services.call('mqtt', 'publish', service_data, False)

I just cant understand this.
Is this will be important in my case or I just need to create list/library of payload:[‘topic1’,‘ON’,‘false’] ?
Or I need to use this formula unchanged? with my library of sensors?

Don’t change those lines (the ones you’ve shown in your previous post)). They are responsible for publishing the received data to the correct topic.

The only reason you may want to change anything is if you don’t like the topic it creates. For example, let’s say you want it to publish to:

sensor/pir_hall_1

instead of:

home/pir_hall_1

To change it, just replace the word home with sensor in the two places it’s used in the code.

It’s written in python. Here’s an overview of its operation:

  • It gets payload and confirms it contains a value.
  • It checks if the payload (which is an RF code) exists in the dictionary (that you defined).
  • If it exists, it defines all the options that will be needed to use with the mqtt.publish service. One of the options is the topic which it creates by combining the string home/ with the name you assigned in the dictionary.
  • It runs mqtt.publish using the options it just defined.
  • If the payload does not exist in the dictionary, it prepares a different set of options. It publishes the unknown payload to home/unknown. This is for debugging purposes; you can see which RF codes are not defined in the dictionary.

Awesome. It makes more sense now.
Thank for help. I will try to use this solution this evening.

Hi again.
I have tried suggested solution but is not working for me for some reason. Can’t see changes in entity states after altering all configuration.
this is what I have done:
I created new folder config/python_scripts
I created new file i folder above rfbridge_demux.py

d = { '1C1DB0':['PIR_Hall_1','ON','false'],
      '1C1DB8':['PIR_Hall_2','ON','false'],
      '1C1DBC':['PIR_Hall_3','ON','false'],
      'FA0ADE':['PIR_Stairs','ON','false'],
      '98B060':['PIR_Landing_1','ON','false'],
      'FA502E':['PIR_Living','ON','false'],
      'FA1C5E':['PIR_Kitchen','ON','false'],
      'FA06EE':['PIR_Batchroom','ON','false'],
      'F1F85E':['PIR_Garage','ON','false'],
      '46310A':['Window_Bathroom','ON','false'],
      '46310E':['Window_Bathroom','OFF','false'],
      '440D0A':['Window_Living','ON','false'],
      '440D0E':['Window_Living','OFF','false'],
      '4B170A':['Fridge','ON','false'],
      '4B170E':['Fridge','OFF','false'],
      '386103':['Window_Test_1','ON','false'],
      '72A4C8':['SonoffB1','ON','false'],
      '72A4CC':['SonoffB2','ON','false'],
      '72A4C4':['SonoffB3','ON','false'],
      '72A4C9':['SonoffB4','ON','false'],
      '72A4C2':['SonoffB5','ON','false'],
      '72A4C5':['SonoffB6','ON','false'],
      '72A4C1':['SonoffB7','ON','false'],
      '72A4C3':['SonoffB8','ON','false'],
      'B817E2':['SyfBL','ON','false'],
      'B817E8':['SyfBM','ON','false'],
      'B817E4':['SyfBR','ON','false'],
      '8B0588':['SingleB1','ON','false']
    }

p = data.get('payload')

if p is not None:
  if p in d.keys():
    service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
  else:
    service_data = {'topic':'home/unknown', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
    logger.warning('<rfbridge_demux> Received unknown RF command: {}'.format(p))
  hass.services.call('mqtt', 'publish', service_data, False)

In automations.yaml added:

- alias: 'rfbridge_demultiplexer'
  trigger:
  - platform: mqtt
    topic: tele/rf/RESULT
  action:
  - service: python_script.rfbridge_demux
    data_template:
      payload: '{{trigger.payload_json.RfReceived.Data}}'

In configuration.yaml added:

python_script:

All binary sensors changed to:

#RF Bridge
binary_sensor RF:
#
#PIR Hall
  - platform: mqtt
    state_topic: "home/PIR_Hall_1"
    name: 'PIR Hall 1'
    off_delay: 3
    device_class: motion
#
#PIR Hall 2
  - platform: mqtt
    state_topic: "home/PIR_Hall_2"
    name: 'PIR Hall 2'
    off_delay: 3
    device_class: motion
#
#PIR Hall 3
  - platform: mqtt
    state_topic: "home/PIR_Hall_3"
    name: 'PIR Hall 3'
    off_delay: 3
    device_class: motion
#
#PIR schody
  - platform: mqtt
    state_topic: "PIR_Stairs"
    name: 'PIR Stairs'
    off_delay: 3
    device_class: motion
#
#PIR gora hall 0
  - platform: mqtt
    state_topic: "PIR_Landing_1"
    name: 'PIR Landing 1'
    off_delay: 3
    device_class: motion
#
#PIR salon
  - platform: mqtt
    state_topic: "PIR_Living"
    name: 'PIR Living'
    off_delay: 3
    device_class: motion
#
#PIR kuchnia
  - platform: mqtt
    state_topic: "PIR_Kitchen"
    name: 'PIR Kitchen'
    off_delay: 3
    device_class: motion
#
#PIR lazienka
  - platform: mqtt
    state_topic: "PIR_Batchroom"
    name: 'PIR Bathroom'
    off_delay: 3
    device_class: motion
#
#PIR corridor
  - platform: mqtt
    state_topic: "PIR_Garage"
    name: 'PIR Garage'
    off_delay: 3
    device_class: motion
#
#Kontaktron lazienka okno
  - platform: mqtt
    name: "Window Bathroom"
    state_topic: "Window_Bathroom"
    device_class: window
#
#Kontaktron lodowka
  - platform: mqtt
    name: "Fridge"
    state_topic: "Fridge"
    device_class: opening
#Kontaktron okno salon
  - platform: mqtt
    name: "Window living"
    state_topic: "Window_Living"
    device_class: window
#
#Kontaktron 1
  - platform: mqtt
    state_topic: "Window_Test_1"
    name: 'Test kontakt'
    device_class: Door
    off_delay: 3
#
#
#
#Sonoff pilot przycisk 1
  - platform: mqtt
    state_topic: "SonoffB1"
    name: 'SonoffB1'
    off_delay: 3
#Sonoff pilot przycisk 2
  - platform: mqtt
    state_topic: "SonoffB2"
    name: 'SonoffB2'
    off_delay: 3
#Sonoff pilot przycisk 3
  - platform: mqtt
    state_topic: "SonoffB3"
    name: 'SonoffB3'
    off_delay: 3
#Sonoff pilot przycisk 4
  - platform: mqtt
    state_topic: "SonoffB4"
    name: 'SonoffB4'
    off_delay: 3
#Sonoff pilot przycisk 5
  - platform: mqtt
    state_topic: "SonoffB5"
    name: 'SonoffB5'
    off_delay: 3
#Sonoff pilot przycisk 6
  - platform: mqtt
    state_topic: "SonoffB6"
    name: 'SonoffB6'
    off_delay: 3
#Sonoff pilot przycisk 7
  - platform: mqtt
    state_topic: "SonoffB7"
    name: 'SonoffB7'
    off_delay: 3
#Sonoff pilot przycisk 8
  - platform: mqtt
    state_topic: "SonoffB8"
    name: 'SonoffB8'
    off_delay: 3
#Syf pilot przycisk lewy
  - platform: mqtt
    state_topic: "SyfBL"
    name: 'SyfBL'
    off_delay: 3
#Syf pilot przycisk middle
  - platform: mqtt
    state_topic: "SyfBM"
    name: 'SyfBM'
    off_delay: 3
#Syf pilot przycisk prawy
  - platform: mqtt
    state_topic: "SyfBR"
    name: 'SyfBR'
    off_delay: 3
#Single button 1 bathroom
  - platform: mqtt
    state_topic: "SingleB1"
    name: 'Singleb1'
    off_delay: 3
#

Can anyone check where I am missing something? Many thanks

Before we dive into debugging, let’s confirm Home Assistant is receiving properly formatted payloads vua tele/rf/RESULT.

  • Go to Developer Tools > MQTT
  • In the Listen to a Topic section, enter tele/rf/RESULT in Topic to subscribe to
  • Click Start Listening
  • Now open the Fridge door or walk in front of one of the motion detectors
  • You should see a payload reported.
  • The payload’s structure should look something like this:
{"RfReceived":{"Sync":14110,"Low":480,"High":1380,"Data":"4B170A","RfKey":"None"}}

If you get a payload and it looks something like the example then you have confirmed Home Assistant is connected to the MQTT Broker and receiving properly structured payloads from the Sonoff RF Bridge.

If you don’t get a payload or if it doesn’t have the correct structure, then we need to fix that first.

Thanks for reply

I am receiving all mqtt messages on topic tele/rf/RESULT
in example:

Message 5 received on tele/rf/RESULT at 5:17 PM:
{
    "Time": "2020-03-11T18:17:55",
    "RfReceived": {
        "Sync": 12560,
        "Low": 440,
        "High": 1240,
        "Data": "FA502E",
        "RfKey": "None"
    }
}
QoS: 0 - Retain: false

Before changes, it was everything working fine, except full of warnings in log

I reverted for now to my old configuration.yaml and is working fine again.
So the problem is not in mqtt communication, rather I have made some mistakes when amending and adding config and/or automations.

I’m just wondering…
I have used the same names for binary sensors in new configuration, so I didn’t have to add new entities to Lovelace or changing my existing automations using these entities. Maybe I should change names and do that what i am trying to avoid? is this necessary?

That’s fine as long as you have not defined the same sensors twice within the configuration. For example, I noticed you did this (appended RF to binary_sensor:)

binary_sensor RF:

Is there another binary_sensor: section in your configuration containing the previous version of the sensors? If your configuration contains two versions of the same sensor, like this:

binary_sensor RF:
  - platform: mqtt
    state_topic: "home/PIR_Hall_1"
    name: 'PIR Hall 1'
    off_delay: 3
    device_class: motion

binary_sensor:
  - platform: mqtt
    state_topic: tele/rf/RESULT
    name: 'PIR Hall 1'
    value_template: '{{value_json.RfReceived.Data}}'
    payload_on: '1C1DB0'
    off_delay: 3
    device_class: motion

then Home Assistant will use the second version of the sensor.

No. I have amended the config by replacing whole section on binary_sensor RF:
so that is not an issue

Then I agree with what you said here:

The automation, python_script, and sensor configurations you posted (above) all appear to be correct and should work so the fault lies elsewhere.

You’ve confirmed the payload is in the correct format and arriving on the correct topic. That should trigger automation.rfbridge_demultiplexer and it will call python_script.rfbridge_demux, passing it just the Data portion of the payload.

The python_script will re-publish Data to the appropriate sensor topic.

The sensor subscribed to that topic will have its state updated.

Somewhere in your system, this chain is broken. Start by checking the system log and confirming the automation and python_script are executed when a payload is received,

I have changed once again now to ‘new’ version of the config and I am really suprised as when the PIR is detecting movement, there is no change on state of the entity, BUT!! it triggers automation to turn on the light where automation looks like this:

  alias: Turn on hall light when motion detected
  description: ''
  trigger:
  - entity_id: binary_sensor.pir_hall_1
    platform: state
    to: 'on'
  - entity_id: binary_sensor.pir_hall_2
    from: 'on'
    platform: state
  - entity_id: binary_sensor.pir_hall_3
    platform: state
    to: 'on'
  - entity_id: binary_sensor.pir_stairs
    platform: state
    to: 'on'
  condition:
  - after: '17:30:00'
    before: 08:00:00
    condition: time
  action:
  - data:
      entity_id: switch.hall_light
    service: switch.turn_on

I am confused now as f :slight_smile:

log showing something like that, not many of th

Log Details (WARNING)
Logger: homeassistant.components.python_script.rfbridge_demux.py
Integration: python_script (documentation, issues)
First occured: 7:15:58 PM (1 occurences)
Last logged: 7:15:58 PM

<rfbridge_demux> Received unknown RF command: FB06EE

but that happens I think after when I changed values in directory in rfbridge_demux.py from ‘ON’ to ‘on’ and OFF’ to ‘off’ just to give a try.

I am reverting to ‘old’ for now. I will try to come back to this later this evening.

I have no idea why you would try that. The documentation states the default value for a binary_sensor’s payload_on is ON (not on).

payload_on
(string)(Optional)
The payload that represents the on state.
Default value:
ON

If that automation gets triggered then the binary_sensors are definitely changing state. How exactly are you checking the binary_sensors to conclude that “there is no change on state of the entity”?

Don’t overlook the fact you have configured each binary_sensor with an off_delay of 3 seconds. That means they maintain an on state for just 3 seconds before they are forced back to off. So if you are using Developer Tools > States, you only have 3 seconds to check if a binary_sensor’s state is on before it returns to off.

That message confirms python_script.rfbridge_demux is working and was called by automation.rfbridge_demultiplexer. Those two important links in the chain are functional.

The message was generated by the python_script when it received an RF code (FB06EE) that was not present in the dictionary you defined.

All of the evidence you’ve provided indicates everything is working as it should. The only unsolved mystery is what technique you are using to conclude “there is no change on state of the entity”.