Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MQTT Automations firing twice when MQTT discovery is enabled #14047

Closed
aderusha opened this issue Apr 22, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@aderusha
Copy link

commented Apr 22, 2018

Home Assistant release with the issue: 0.67.1

Last working Home Assistant release (if known): Unknown

Operating environment (Hass.io/Docker/Windows/etc.): Ubuntu 16.04 LTS
Clean install of OS in new VM, Hass installed and configured per this script: https://hastebin.com/umihamideq.sh

Component/platform: MQTT with Discovery enabled

Description of problem:
I'm working on tracking down a bug in my HASP project and I've narrowed it down to behavior I'm seeing in Hass where MQTT messages incoming under the homeassistant namespace trigger automations twice, but only if discovery is enabled.

I've deployed a clean installation of Hass 0.67.1 on a VM named hasstest running a new installation of Ubuntu 16.04. I have added the following lines to the stock config (link to full configuration.yaml):

mqtt:
  discovery: true

I've then created two simple automations in automations.yaml as shown below:

- alias: TestAutomation1
  trigger:
  - platform: mqtt
    topic: 'homeassistant/test1'
    payload: 'trigger'
  action:
  - service: mqtt.publish
    data:
      topic: 'homeassistant'
      payload: 'TestAutomation1 response'

- alias: TestAutomation2
  trigger:
  - platform: mqtt
    topic: 'test2/test2'
    payload: 'trigger'
  action:
  - service: mqtt.publish
    data:
      topic: 'homeassistant'
      payload: 'TestAutomation2 response'

When I send the following command, I receive two responses: mosquitto_pub -t homeassistant/test1 -m trigger -h hasstest -V mqttv311

2018-04-22 09:22:10.906 homeassistant/test1 trigger
2018-04-22 09:22:10.947 homeassistant TestAutomation1 response
2018-04-22 09:22:10.984 homeassistant TestAutomation1 response

When I send the following command, I only receive one response: mosquitto_pub -t test2/test2 -m trigger -h hasstest -V mqttv311

2018-04-22 09:22:13.508 test2/test2 trigger
2018-04-22 09:22:13.548 homeassistant TestAutomation2 response

If I comment out discovery: true from configuration.yaml, the behavior reverts to what I would expect - one trigger == one action for both automations

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

mqtt:
  discovery: true

automations.yaml

- alias: TestAutomation1
  trigger:
  - platform: mqtt
    topic: 'homeassistant/test1'
    payload: 'trigger'
  action:
  - service: mqtt.publish
    data:
      topic: 'homeassistant'
      payload: 'TestAutomation1 response'

- alias: TestAutomation2
  trigger:
  - platform: mqtt
    topic: 'test2/test2'
    payload: 'trigger'
  action:
  - service: mqtt.publish
    data:
      topic: 'homeassistant'
      payload: 'TestAutomation2 response'

Traceback (if applicable):

Additional information: Forum post here.

@OttoWinter

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

This is expected with the MQTT specification. With MQTT discovery enabled, Home Assistant subscribes to <discovery_prefix>/# which by default is homeassistant/#. When you send a message to homeassistant it will match both your own subscription in the automation and the subscription by discovery:. The MQTT specification states:

When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.

As there's no way for the MQTT client to know for which subscription a PUBLISH packet belongs, this is a limitation of MQTT and we can't fix it. I would recommend just using another topic other than homeassistant or setting a discovery_prefix:.

@aderusha

This comment has been minimized.

Copy link
Author

commented Apr 22, 2018

First, thanks for the clarification! I think that at least tells me a bit about where I need to go with this. As this is a project that several people are using, I'm reticent to change namespace but even more so to require using a non-standard discovery_prefix, it's either break everyone's configuration or break their configuration while also breaking their ability to use other things which expect the standard prefix. You've given me a lot to chew on and I appreciate the insight and fast response time.

@aderusha aderusha closed this Apr 22, 2018

@OttoWinter

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2018

As a work-around you could do the following:

 - alias: TestAutomation1
  trigger:
  - platform: mqtt
    topic: 'homeassistant/#'
    payload: 'trigger'
  condition:
    condition: template
    value_template: '{{ trigger.topic == 'homeassistant/test1' }}'
  action:
  - service: mqtt.publish
    data:
      topic: 'homeassistant'
      payload: 'TestAutomation1 response'

I know it's ugly but it would not end up breaking a bunch of things.

@home-assistant home-assistant locked and limited conversation to collaborators Jul 26, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.