[Solved] How to prevent mqtt automation from triggering upon restart homeassistant or reload automations?

Configuration
,
1

Hi,

Hope someone can help me out.

I have a pushbutton (binary_sensor) and a door relay (switch) which are operated through mqtt, how can I prevent them from triggering when restarting homeassistant or reloading the automations?

My configuration:

Raspberry Pi with homeassistant v0.106.6

configuration.yaml

binary_sensor:
  - platform: rpi_gpio
    ports:
      4: Frontdoor Pushbutton
      27: Backdoor Pushbutton

switch:
  - platform: rpi_gpio
    ports:
      5: Frontdoor Lock
      6: Backdoor Lock
    invert_logic: true

lock:
  - platform: template
    name: Frontdoor
    value_template: "{{ is_state('switch.frontdoor_lock', 'off') }}"
    unlock:
      service: script.turn_on
      entity_id: script.unlock_frontdoor
    lock:
      service: switch.turn_off
      entity_id: switch.frontdoor_lock
  - platform: template
    name: Backdoor
    value_template: "{{ is_state('switch.backdoor_lock', 'off') }}"
    unlock:
      service: script.turn_on
      entity_id: script.unlock_backdoor
    lock:
      service: switch.turn_off
      entity_id: switch.backdoor_lock

mqtt_statestream:
  base_topic: home-domotica
  publish_attributes: true
  publish_timestamps: true
  include:
    entities:
      - binary_sensor.backdoor_pushbutton
      - binary_sensor.frontdoor_pushbutton
      - lock.frontdoor
      - lock.backdoor

scripts.yaml

unlock_frontdoor:
  alias: Frontdoor Unlock
  sequence:
  - service: switch.turn_on
    entity_id: switch.frontdoor_lock
  - delay: 00:00:04
  - service: switch.turn_off
    entity_id: switch.frontdoor_lock
unlock_backdoor:
  alias: Backdoor Unlock
  sequence:
  - service: switch.turn_on
    entity_id: switch.backdoor_lock
  - delay: 00:00:04
  - service: switch.turn_off
    entity_id: switch.backdoor_lock

automations.yaml

- id: '154895186df23'
  alias: Frontdoor Lock
  trigger:
  - platform: mqtt
    topic: home-domotica/lock/frontdoor/set
  condition:
  - condition: state
    entity_id: script.unlock_frontdoor
    state: 'off'
  action:
  - service_template: lock.{{trigger.payload}}
    entity_id: lock.frontdoor
- id: '154895142df79'
  alias: Backdoor Lock
  trigger:
  - platform: mqtt
    topic: home-domotica/lock/backdoor/set
  condition:
  - condition: state
    entity_id: script.unlock_backdoor
    state: 'off'
  action:
  - service_template: lock.{{trigger.payload}}
    entity_id: lock.backdoor

Ubuntu VM with homeassistant v0.106.6 in venv.

configuration.yaml:

lock:
  - platform: mqtt
    name: "Frontdoor"
    state_topic: "home-domotica/lock/frontdoor/state"
    command_topic: "home-domotica/lock/frontdoor/set"
    payload_unlock: "unlock"
    payload_lock: "lock"
    state_locked: "locked"
    state_unlocked: "unlocked"
#   qos: 1
#   retain: true
#   optimistic: false
    value_template: '{{ value }}'
  - platform: mqtt
    name: "Backdoor"
    state_topic: "home-domotica/lock/backdoor/state"
    command_topic: "home-domotica/lock/backdoor/set"
    payload_unlock: "unlock"
    payload_lock: "lock"
    state_locked: "locked"
    state_unlocked: "unlocked"
#   qos: 1
#   retain: true
#   optimistic: false
    value_template: '{{ value }}'

Tried with retain: false and/or optimistic: true but as soon as the raspberry pi is booting or homeassistant is restarting or I reload the automations or I turn off and on the lock automation both frontdoor and backdoor locks are cycling, as in opening and closing. How can I prevent this?

Any help will be appreciated!

Regards,
Donald.

2

I had exactly the same issue with my blinds, that were opening every time I restared HA. It turned out that I had automation that as a trigger was checking state change of my harmony remote to: ‘PowerOff’ - I excluded from: condition, since it could vary, depending on what activity was active prior to switching equipment off. It turned out that during startup harmony integration was slow with reporting hub status and automation was triggered as shortly after HA startup reported state was changing from Undefined to PowerOff, triggering automation…
I’m not familiar with MQTT, so I can’t tell exactly what might be wrong, but I’d look at trigger in your automation, it seems to activate automation during startup. Can you look at MQTT log if there is something there? Perhaps this will somehow help to remediate: https://www.home-assistant.io/docs/mqtt/birth_will/

3

Hi Mirek,

There is no from or to in mqtt, just a payload, and that one is lock or unlock.
I already tried to delay the automations by 2 minutes after homeassistant was restarting, but that didn’t help also.
I already make use of the birth and will messages in the mqtt clients, no change in behavier.
Strange thing is that I have several mqtt automations and only the locks are having this isue, all other switches and lights do not have this issue.

4

If your lock ever contained ‘retain : true’ , these messages are in the mqtt database and received as soon as HA restarts. So first step is to start MQTT Explorer and remove these messages from the MQTT database.

5

Hi Francis,

That did the trick, finally working, I thought when I set the retain at false it would update the database too, but it didn’t.

root@mediaserver:/home/donald# mosquitto_pub -h localhost -t home-domotica/lock/frontdoor/set -u *masked* -P *masked* -n -r -d
Client mosqpub|125511-mediaser sending CONNECT
Client mosqpub|125511-mediaser received CONNACK (0)
Client mosqpub|125511-mediaser sending PUBLISH (d0, q0, r1, m1, 'home-domotica/lock/frontdoor/set', ... (0 bytes))
Client mosqpub|125511-mediaser sending DISCONNECT
root@mediaserver:/home/donald# mosquitto_pub -h localhost -t home-domotica/lock/backdoor/set -u *masked* -P *masked* -n -r -d
Client mosqpub|125676-mediaser sending CONNECT
Client mosqpub|125676-mediaser received CONNACK (0)
Client mosqpub|125676-mediaser sending PUBLISH (d0, q0, r1, m1, 'home-domotica/lock/backdoor/set', ... (0 bytes))
Client mosqpub|125676-mediaser sending DISCONNECT
root@mediaserver:/home/donald#

Thank you very much, I was struggling for months to find the problem.

Best Regards,
Donald.