Help with Unintentional Automation Triggering - Find the "Ghost" Trigger

Hi,

This is driving me crazy. If anyone can help, I’d really appreciate it.

This automation (code below) got triggered twice in the last week without anyone actually pressing the input boolean that’s supposed to trigger it. The worst thing is, the automation activates a really loud siren sound over the outdoor speakers → unhappy neighbors. It’s purpose is to be there in case someone is trying to break in the home; at that point, anyone with Home Assistant (just 2 of us) can press the boolean “on” and trigger it. But, this week I was at work and my wife/partner was at the gym, neither of us using HA, when it triggered… and it happened more than once about 1-2 hours apart. Neither of us had HA open or were using it. The only way to trigger this automation is to turn the boolean to “on”.

The only other relevant thing from the day was that our internet service provider was having outages; the internet was intermittently on / off / on.

Here is the code:

alias: >-
  Activate siren sound on outdoor speakers with input boolean toggle titled
  "Siren"
description: ""
trigger:
  - platform: state
    entity_id:
      - input_boolean.siren
    to: "on"
    id: Siren.ON
  - platform: state
    entity_id:
      - input_boolean.siren
    to: "off"
    id: Siren.OFF
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id: Siren.ON
        sequence:
          - service: media_player.volume_set
            data:
              volume_level: 0.75
            target:
              entity_id:
                - media_player.front_porch_sonos
                - media_player.back_deck_upstairs_sonos
                - media_player.back_patio_downstairs_sonos
          - service: media_player.play_media
            data:
              media_content_type: music
              media_content_id: http://xxx.xxxx.x.xx:xxxx/local/Siren.mp3
            target:
              entity_id:
                - media_player.front_porch_sonos
                - media_player.back_deck_upstairs_sonos
                - media_player.back_patio_downstairs_sonos
          - service: notify.home_assistant
            data:
              message: Outside Sirens Activated!!!
      - conditions:
          - condition: trigger
            id: Siren.OFF
        sequence:
          - service: media_player.media_stop
            data: {}
            target:
              entity_id:
                - media_player.front_porch_sonos
                - media_player.back_deck_upstairs_sonos
                - media_player.back_patio_downstairs_sonos
          - service: media_player.volume_set
            data:
              volume_level: 0.5
            target:
              entity_id:
                - media_player.front_porch_sonos
                - media_player.back_deck_upstairs_sonos
                - media_player.back_patio_downstairs_sonos
          - service: notify.home_assistant
            data:
              message: Outdoor Sirens deactivated.
    default: []
mode: single

Nothing in the traces? (—> changed variables)

Is this input_boolean used elsewhere?

If you’re using the uptime sensor, you could add a condition:


  - "{{ ( now() - states('sensor.uptime')|as_datetime |as_local ) > timedelta(minutes=2) }}"

1 Like

@pedolsky thank u for your thoughts. Attached is a screenshot of the trace from one of the 2 instances when it fired - they appear identical except for the times. The changed variables is below that. As far as I can tell, it was just the input boolean that changed to on. That boolean is only on one card in HA. Nothing else has access to it.

As far as the uptime sensor goes, I’m curious to learn more. Is this what you’re talking about? Do I just add the uptime integration and then add the condition you suggested to my automation? And then, how does that help?

‘’’
this:
entity_id: automation.sound_file_experiment
state: ‘on’
attributes:
last_triggered: ‘2022-09-30T14:22:07.465819+00:00’
mode: single
current: 0
id: ‘1658406920174’
friendly_name: >-
Activate siren sound on outdoor speakers with input boolean toggle titled
“Siren”
last_changed: ‘2022-09-30T12:06:39.421227+00:00’
last_updated: ‘2022-09-30T14:22:09.344132+00:00’
context:
id: 01GE7CDBGEJCN6CTC2VRP29163
parent_id: 01GE7CDBG62TVS8CTAZS3N86BX
user_id: null
trigger:
id: Siren.ON
idx: ‘0’
alias: null
platform: state
entity_id: input_boolean.siren
from_state:
entity_id: input_boolean.siren
state: ‘off’
attributes:
editable: true
icon: mdi:alarm-light-outline
friendly_name: Siren
last_changed: ‘2022-09-30T14:22:08.905574+00:00’
last_updated: ‘2022-09-30T14:22:08.905574+00:00’
context:
id: 01GE7CDBG62TVS8CTAZS3N86BX
parent_id: null
user_id: 9e41c3e94e6249ba97623563f0c7fafe
to_state:
entity_id: input_boolean.siren
state: ‘on’
attributes:
editable: true
icon: mdi:alarm-light-outline
friendly_name: Siren
last_changed: ‘2022-09-30T14:30:53.447094+00:00’
last_updated: ‘2022-09-30T14:30:53.447094+00:00’
context:
id: 01GE7CXBR6BCJ1RQ5MD2X5KXGV
parent_id: null
user_id: 9e41c3e94e6249ba97623563f0c7fafe
for: null
attribute: null
description: state of input_boolean.siren
‘’’

Yes, it’s the uptime integration.

If you can really rule out the possibility that the switch was activated accidentally, I’ll just assume that the internet failure was to blame.

1 Like

Thanks again… and what is that uptime condition actually doing? Does it limit the automation to only work while the internet is online?

It prevents the automation from being triggered immediately after HA restart.

1 Like

That’s a great idea! Thank u! One other thought/question… are you aware of any way (integration or other) to drill down on what user or device triggered an automation?

There was a recent discussion on this.

1 Like

That’s the. test automation:


alias: 1 Test - what caused the State-Change?
description: ""
trigger:
  - platform: state
    entity_id: input_boolean.siren
condition: []
action:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.context.parent_id == none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.user_id == none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.id != none }}"
        sequence:
          - service: notify.persistent_notification
            data:
              title: Likely Physical switched
              message: |
                ParentID: None || UserID: None || ID: CONTENT
                context.parent_id: {{ trigger.to_state.context.parent_id }}
                context.user_id: {{ trigger.to_state.context.user_id }}
                context.id: {{ trigger.to_state.context.id }}
      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.context.parent_id != none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.user_id == none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.id != none }}"
        sequence:
          - service: notify.persistent_notification
            data:
              title: Likely Automation switched
              message: |
                ParentID: CONTENT || UserID: None || ID: CONTENT
                ParentID: None || UserID: None || ID: CONTENT
                context.parent_id: {{ trigger.to_state.context.parent_id }}
                context.user_id: {{ trigger.to_state.context.user_id }}
                context.id: {{ trigger.to_state.context.id }}
      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.context.parent_id == none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.user_id != none }}"
          - condition: template
            value_template: "{{ trigger.to_state.context.id != none }}"
        sequence:
          - service: notify.persistent_notification
            data:
              title: Likely UI switched
              message: |
                ParentID: None || UserID: None || ID: CONTENT
                context.parent_id: {{ trigger.to_state.context.parent_id }}
                context.user_id: {{ trigger.to_state.context.user_id }}
                context.id: {{ trigger.to_state.context.id }}
    default: []
mode: single


I will provide the link once I have found it.

1 Like

Found it: https://community.home-assistant.io/t/work-with-triggered-by-in-automations/400352/9?u=pedolsky

1 Like

Can you look back at the history of the boolean and see if it went to either ‘unknown’ or ‘unavailable’ at the time right before it triggered?

If it did then that’s the issue.

you can solve that by specifying a ‘from:’ in the trigger so it ignores the transitions between any other states:

trigger:
  - platform: state
    entity_id:
      - input_boolean.siren
    from: 'off'
    to: "on"
    id: Siren.ON
  - platform: state
    entity_id:
      - input_boolean.siren
    from: 'on'
    to: "off"
    id: Siren.OFF
1 Like

That’s a great thought. I don’t see a history, but may be looking in the wrong place. Do these screenshots look right, or should I be somewhere else?

it’s likely less useful to look at it on your phone since the screen is wonky but…

in a browser open up the history tab and then select that boolean at the times in question to see if there is anything strange there.

also, do you have input_booleans being recorded in the recorder? if not then you won’t see it in history either.

1 Like

I didn’t have the recorder integration. Wasn’t even aware of it. But, will definitely install now!

1 Like

I thought I was losing my mind when some of my devices would take actions for what seemed like no reason. Turns out, some of the integrations will get confused and trigger the wrong device if the IP address of your devices end up changing when your router is rebooted. I changed every single device to a static ip address on my network and on the router/dhcp server, reserved that address and asigned it to only that one devce (I think what I said was rdundant - but on some devices you can set it on the device - so I do it where one would expect the ip address to be assigned by the dhcp server, but I also assign it on those devices as well) - and the problem never came back. Voila! Maybe not your problem but that is what solved it for me. I thought I was losing my mind. I ws very surprised that some of the integrations must be relying upon the IP address of a device istead of on it’s mac address which is what would really be the right wayt to code an integration… :slight_smile:

2 Likes

This would be a really good thought, and I’ll heed your advice to reserve static IPs anyway. But this automation is composed of just one helper and one automation (no IP addresses). The actual devices (speakers in this case) are in the automation’s action, but there is also a push notification in the action, and it got triggered too. So, it looks like the whole automation got triggered (not just the devices).

Does the trace show anything - it wouid show what had triggered the change… Also in your startup for HA do you update or reset the input booleans or ther settings? Maybe HA got restarted? Also check under settings I think it is - “related” - anything else use that same boolean? Is it possiblke that switch loses and then regains access top your network and something happens then when it disconnects and/or reconnects?

1 Like

The trace shows the automation was triggered by the input boolean titled “siren”. That boolean only takes part in that one automation. I’m not sure how to check whether my input booleans reset at restart. I don’t think they do because I’ve done many system restarts in the past and the automation has never been activated.