WARNING in log when using MQTT Auto discovery feature Tasmota v6.7

[DeviousPenguin]

Home Assistant release with the issue:

0.100.3

Operating environment (Hass.io/Docker/Windows/etc.):

From System Health:

• dev: false
• docker: false
• hassio: false
• os_name: Linux (Raspbian Buster)
• python_version: 3.7.3
• version: 0.100.3
• virtualenv: true

Integration:

MQTT:

https://www.home-assistant.io/integrations/mqtt/

Description of problem:

I'm using a Sonoff Basic flashed with the latest stable version of Tasmota, v6.7. I'm trying to use it with Home Assistant (HA).

I've set it up following the instructions here: https://github.com/arendst/Tasmota/wiki/Home-Assistant using the MQTT Auto Discovery feature.

I'm using Mosquitto as my MQTT broker, and MQTT seems to be working OK and I can already control the Sonoff using Nodered for example. After setting the SetOption19 ON command in Tasmota my device appears in HA, and appears to work OK.

However I'm getting a warning/error in my log file afterwards:

2019-10-28 18:29:56 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Speakers Button1 with state_topic: speakers_12A4AB/stat/RESULT

I would like to fix this warning, as a warning indicates something is wrong here.

If I have set up the auto discovery incorrectly, I am happy to try again.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

mqtt:
  discovery: true
  discovery_prefix: homeassistant
  broker: !secret mqtt_server
  port: !secret mqtt_port
  keepalive: 60
  certificate: !secret mqtt_cert
  username: !secret mqtt_username
  password: !secret mqtt_password

Traceback (if applicable):

n/a

Additional information:

n/a

[towerhand]

I’m getting the same, it started with tasmota 6.7 so I’m assuming is a tasmota issue and not a HA issue.

[DeviousPenguin]

I’m getting the same, it started with tasmota 6.7 so I’m assuming is a tasmota issue and not a HA issue.

That certainly is possible, I'm happy to create an issue on the Tasmota repo instead if that is the case.

I'm not entirely sure how auto discovery works behind the scenes, but I did keep the Tasmota console open the entire time, but Tasmota did not show any error messages, which is why I think it's more likely to be a HA issue as the warning/error is in the HA log.

Would you mind tell me what device you are using Tasmota on and what your error message says? Thanks

[towerhand]

I have 4 sonoff basics flashed with tasmota 6.7.1.

2019-10-28 21:33:08 WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Sonoff Button1 with state_topic: Tasmota/wax_warmer_mudroom/stat/RESULT

[RIKWEBB]

Yeah getting this on all my Tasmota devices since upgrading to 6.7. Example: WARNING (MainThread) [homeassistant.components.mqtt.binary_sensor] No matching payload found for entity: Conservatory Top Lights Button1 with state_topic: Conservatory-Switch/stat/RESULT

[ascillato]

Hi,

This warning is explained by @effelle in the Tasmota's pull request that adds a new button discovery functionality.

Does not affect the usage of Tasmota or HA.

Please check https://github.com/arendst/Tasmota/pull/6737

Thanks.

[effelle]

I'm still thinking is related to #22172. @towerhand

I’m getting the same, it started with tasmota 6.7 so I’m assuming is a tasmota issue and not a HA issue.

Button and switched as binary_sensorwere disabled since V6.3-6.4 and I've done a fix last week under 6.7. That's why you never see the issue that shows up some months ago.

@emontnemery: I know is just a warning and not an error, and in truth there is a quick fix already as you reported on the other issue

logger:
  default: info
  logs:
    homeassistant.components.mqtt.binary_sensor: critical

but could you gently have a look on the new generated json? For me seems all in place and respecting the protocol:

{
  "name": "Sonoff Switch1",
  "stat_t": "~stat/RESULT",
  "value_template": "{{value_json.SWITCH1}}",
  "pl_on": "ON",
  "avty_t": "~tele/LWT",
  "pl_avail": "Online",
  "pl_not_avail": "Offline",
  "uniq_id": "471XXX_SW_1",
  "device": {
    "identifiers": [
      "471XXX"
    ],
    "connections": [
      [
        "mac",
        "XX:XX:E3:47:10:78"
      ]
    ]
  },
  "~": "sonoff/",
  "frc_upd": true,
  "pl_off": "OFF"
}

The issue is present on manually created sensor too so is not related only to HAss discovery:

 - platform: mqtt
    name: "Pir ES Suite"
    payload_on: "1"
    device_class: motion
    state_topic: "Suite2/tele/PIR_ES"
    off_delay: 10

[towerhand]

Disabling the entity in HA removes the warning in the logs too. I don’t need the binary_sensor added by the 6.7 update anyway especially since it didn’t change state at any point when I had it enabled, so it’s useless for my sonoff basics.

[RIKWEBB]

Disabling the button on all my devices seems to have worked.

[effelle]

Obviously removing the entities solve the issue, but as I said, it happens with manually added mqtt binary sensors too. I've uploaded the latest stable (6.7.1) on a brand new Sonoff Basic R2 right now and the state of the button changes as it should do. Since was never connected to HA I thought was the best way to test again.

03:05:22 MQT: sonoff/stat/RESULT = {"BUTTON1":"TOGGLE"}
03:05:22 MQT: sonoff/stat/RESULT = {"POWER":"ON"}
03:05:22 MQT: sonoff/stat/POWER = ON

@towerhand Did you try to disable and then re-enable setoption19 to see if it works well? It´s late here, but if you like you can ping me tomorrow on our Discord channel (or DrZzs or Digiblur or Superhouse channel) and we will have a look together. Even if you don't use them could be interesting to see if there is something wrong with the code.

[DeviousPenguin]

logger: default: info logs: homeassistant.components.mqtt.binary_sensor: critical

@effelle Thanks for sharing the 'quick fix' - it does indeed stop the WARNING messages in my home-assistant.log file, however the WARNING messages still appear in the 'logs' part of HA's Dev Tools UI.

@towerhand Did you try to disable and then re-enable setoption19 to see if it works well?

I have tried setting setoption19 to OFF, rebooting the Tasmota device, then setting setoption19 back to ON and I still get the same WARNING messages in my log.

EDIT: I should also add that I've updated my HA to v0.101.0 a few hours ago and am still getting the same errors.

[effelle]

Disabling and enabling setoption19 doesn't get rid of the warning, is just to "unblock" a stuck sensor, because Tasmota will blank all the config information and send empty messages to HA.

@DeviousPenguin yep, I tested 101 build too. Updated a D1 Mini with a button, pressed --> change state correctly reported --> warning on logs --> sensor off after a second as expected.

[DeviousPenguin]

Disabling and enabling setoption19 doesn't get rid of the warning, is just to "unblock" a stuck sensor, because Tasmota will blank all the config information and send empty messages to HA.

Ok, I just wanted to check I didn't do anything wrong when setting up the MQTT auto discovery, as usually when I get WARNING and ERROR messages in my HA log it means I've done something wrong when setting up the integration, and is often something as simple as incorrect YAML spacing.

However it seems that multiple people here have set up MQTT auto discovery correctly, it is working as intended, yet they are still getting a (incorrect? false positive?) WARNING messages in thier log, so I'm 90% sure this is a HA issue and not a Tasmota one.

It would be nice to fix this issue, I imagine I won't be the first or last person to see these WARNING messages, assume there is something wrong or they have incorrectly set up the integration, and would prevent many future forum threads/github issues.

[effelle]

Sadly I need a reply from someone of HAss team. If a code change is needed on my side I first need to know what is going on.

[DeviousPenguin]

Sadly I need a reply from someone of HAss team.

It's a shame there are a so many HA issues and only a few main HA devs, so it may take a while for a reply.

I'll see if I can summon a dev using discord or the forum to take a look at this issue.

[effelle]

If you find someone to speak with ping me too. Perhaps I'll be online.

[pszafer]

@effelle as from here I see that you sending json {"POWER":"ON"}. I guess value template is wrong.

You can modify warning here https://github.com/home-assistant/home-assistant/blob/f8d3ea20b6e7495f508673fb797dde72868f605f/homeassistant/components/mqtt/binary_sensor.py#L193 to something like this

_LOGGER.warning(
                    "No matching payload found" " for entity: %s with state_topic: %s. Payload: %s, with val template %s",
                    self._config[CONF_NAME],
                    self._config[CONF_STATE_TOPIC], payload, value_template
                )

and look how does it look like.

[effelle]

@pszafer Pawel, {"POWER":"ON"} is the json of the relay (sensor) and is triggered after the Json of switches/buttons (binary sensor). Then the json sent out is
sonoff/stat/RESULT = {"BUTTON1":"TOGGLE"} or sonoff/stat/RESULT = {"SWITCH1":"ON"} But yes, I'll have a look on it as soon as I can.

[Theb-1]

Hopefully I'm not over/under thinking this. I think HA will complain anytime Tasmota sends a payload of "TOGGLE" since the valid payloads for a binary sensor are "ON" and "OFF". I'm not seeing a payload of "TOGGLE" on my 6.6 devices and they are all happy.

[effelle]

@Theb-1 on 6.6 you button/switches were not working properly or at all. You probably right about toggle payload, was used on earlier version of tasmota (5.13-->) and probably something changes in more than 2 years of evolution. As a confirmation of what you say I found a special configuration on Binary_Sensor page to emulate toggle state:

Toggle the binary sensor each time a message is received on state_topic
binary_sensor:
  - platform: mqtt
    state_topic: "lab_button/cmnd/POWER"
    value_template: "{%if is_state(entity_id,\"on\")-%}OFF{%-else-%}ON{%-endif%}"

I'm quite sure is a recent add, but on GH I can see just the latest 3-4 changes. Anyway, I can probably adapt it for our JSON parser, I'll have a look next week. Thanks man!

[bikefright]

@Theb-1 @effelle I think you are on to something with your comments about TOGGLE.

I have 16 x Sonoff S20 and 2 x Sonoff Basic, all of which were running 6.6.0 prior to today when I upgraded to 6.7.1 at which point I started seeing these "No matching payload" warning messages in HA.

I previously took the "easy" route of HA auto discovery having enabled option19.

After the upgrade, I get a new binary_sensor button (in this case: homeassistant/binary_sensor/39DXXX_BTN_1) for each sonoff device whose JSON looks like this:

{
  "name":"sonoff-5202 Button1",
  "stat_t":"~stat/RESULT",
  "value_template":"{{value_json.BUTTON1}}",
  "pl_on":"TOGGLE",
  "avty_t":"~tele/LWT",
  "pl_avail":"Online",
  "pl_not_avail":"Offline",
  "uniq_id":"39DXXX_BTN_1",
  "device":{
    "identifiers":[
      "39DXXX"
    ],
    "connections":[
      [
        "mac",
        "XX:XX:2D:39:D4:52"
      ]
    ]
  },
  "~":"sonoff-5202/",
  "off_delay":1
}

I guess I would expect to see a pl_on: "ON" and pl_off: "OFF" in order that HA is "happy" with these new button binary sensors. The switch entity for the same sonoff basic (MQTT topic: homeassistant/switch/39DXXX_RL_1) has the expected pl_on: "ON" and pl_off: "OFF"

As I currently have no need to use a button press to trigger an action elsewhere in my home automation, I've just disabled these button entities using the HA Entity Registry editor.

[effelle]

Gentlemen, I do apologize for the delay, busy week. I've just pull a PR on our side to change the topic from /stat/RESULT to stat/SWITCHx or stat/BUTTONx. Seems HA get confused because is receiving two messages in the same topic (one for the switch/button and one for the relay) too quick, since are published at the very same time by Tasmota. Have a different topic solved the issue to the root. Probably could be solved on HA side, but since we have an imminent new release I prefer to patch it right now.

@pszafer : Pawel, I submitted a PR (#28707) against binary_sensor.py with your suggestion, helped me a lot to understand and catch the issue and was already merged. Thanks man.

@Theb-1, @bikefright : TOGGLE is a valid payload and can be used with no issue changing accordingly the template. Anyway, I've changed a bit the switches behavior when they are used in toggle mode (switchmode 0): now on every change of state the entity will maintain his status, different from buttons where the status will revert to OFF after one seconds to avoid HOLD events.

@DeviousPenguin : The PR should be merged right on time for release 7.1. Perhaps we will see it on tomorrow's builds (15/11/2019). If all goes fine close this issue. If you have any doubt please ping me on my Discord (or SuperHouse or Digiblur or DRZzs).

For all the rest, thanks for your time and help to improve Tasmota!

Federico Support Information See Wiki for more information. See Chat for more user experience. See Community for forum. See Code of Conduct

[bikefright]

@effelle No apology needed on the timeline. I'll probably wait for 7.1 release and test again. If I have a moment over the weekend I might download the development release (I see your commit there already) and try it on a brand new TH16 I have in a box (as yet unknown to HA). Thanks for your contribution to an invaluable project!

[DeviousPenguin]

@DeviousPenguin : The PR should be merged right on time for release 7.1. Perhaps we will see it on tomorrow's builds (15/11/2019). If all goes fine close this issue.

Thanks very much, that great news. I'll keep this open and I'll look forward to testing out Tasmota v7.1 once it's released.

[DeviousPenguin]

Ok, I've just updated 2 out of many Tasmota devices to 7.1.1 and these WARNING messages are no longer there for the updated devices, the fix has worked, so I'm going to close this now.

I found the best way to update was to backup the old settings JSON, with decode-config, then turn off HA discovery before updating, SetOption19 0 from console.

Then do the minimal and full firmware flash to update, restore settings, then turn HA discovery back on with SetOption19 1

Once all that is done, restart HA to see if there are any WARNING messages in log.

Thanks very much for fixing this issue @effelle

[bikefright]

Ditto. Brand new TH16 + DS18B20 temp sensor setup without issues @7.1.1 and configured into HA with no error messages. Rebooted server running portainer+HA+MQTT for good measure and all is fully functional. Thanks for fixing this. Only deviation for me is to set the grouptopic back to "sonoffs" - I'll re-brand all my devices in the coming weeks via tasmoadmin :-)

[effelle]

Only deviation for me is to set the grouptopic back to "sonoffs" - I'll re-brand all my devices in the coming weeks via tasmoadmin

That's is because starting from dev release 7 the naming system was (finally!) changed. All Sonoff / Sonoffs text in the code where replaced with Tasmota / Tasmotas. To manage your device give a spin to TDM. I know is not embedded on HA but still is a very good piece of software and dosn't hammer your devicese with continuosly HTTP requests.

[bikefright]

Good tip @efelle - TDM looks fab. In my defence, I'm running tasmoadmin in a separate container that I control, but I can see that there is already a docker container for TDM https://hub.docker.com/r/marcelkordek/tasmota-device-manager so I'll give it a spin for sure.