Hello to the forum. I have a question. I have created an automation that sends me a message by telegram when someone rings the doorbell. This works without any problems … If now my daughter is at the front door, then it rings not only once but very often, and each time a message is sent by telegram and my smartphone comes with the beeping not behind. Is it possible to limit the automation so that it is triggered only once? Then the automation is locked for one minute and then becomes active again. I have already looked at the “conditions” but have not found a suitable solution. For help or tips, I would be grateful.
- Speak with your daughter.
- You could turn the automation ‘off’ at the end of the action part and turn it on with another automation after some time.
EDIT: Something like this:
- alias: doorbell rings
trigger:
platform: state
entity_id: some.switch
state: 'on'
action:
- service: notify...
...
- service: automation.turn_off
entity_id: automation.doorbell_rings
- alias: doorbell automation on
trigger:
platform: state
entity_id: automation.doorbell_rings
to: 'off'
for: "00:01:00"
action:
service: automation.turn_on
entity_id: automation.doorbell_rings
Thank you for the answer and help. I have talked to my daughter several times and can confirm that changing the automation is the simpler solution …
Thanks for the help
You can do it in one automation by adding a condition like the following:
- alias: doorbell rings
trigger:
...
condition:
condition: template
value_template: >
{% set last = state_attr('automation.doorbell_rings', 'last_triggered') %}
{{ last is none or (now() - last).total_seconds() > 60 }}
action:
...
Thanks Phil for your answer
Thanks Phil. Solved a big issue for me. IMHO this functionality should be built-in to automations.
Starting with the 0.113 release, one can now do:
- alias: doorbell rings
trigger:
...
mode: single
action:
...
- delay: 60
This will prevent the actions from running again for 60 seconds (or whatever amount of delay is used.)
too bad we can’t use that with multiple triggers. Would it somewhere in the future be possible to use something like this:
- trigger_delay: 60
?
btw just found this nice addition to the timing templates:
Didnt use the last is none
yet, but that I see this, will change all accordingly. That can be done with multiple triggers:
- condition: template
value_template: >
{% set last = trigger.from_state.last_changed %}
{{last is none or (now() - last).total_seconds() > 120}}
cool.
sure:
- alias: Daughters presence
id: Daughters presence
initial_state: false
trigger:
platform: state
entity_id:
- group.daughter_1
- group.daughter_2
- device_tracker.daughter_3
- device_tracker.daughter_4
condition:
- condition: state
entity_id: input_boolean.notify_presence
state: 'on'
# - condition: template
# value_template: >
# {{is_state('input_boolean.notify_presence','on')}}
- condition: template
value_template: >
{{trigger.to_state is not none and
trigger.from_state is not none and
trigger.to_state.state in ['home','not_home'] and
trigger.to_state.state != trigger.from_state.state}}
- condition: template
value_template: >
{% set last = trigger.from_state.last_changed %}
{{last is none or (now() - last).total_seconds() > 120}}
# {{(now() - trigger.from_state.last_changed).total_seconds() > 120}}
action:
service: notify.notify
data_template:
title: >
Daughter {{'arrived at' if is_state(trigger.entity_id,'home') else 'left'}} home
message: >-
{{as_timestamp(now())|timestamp_custom('%X')}}
{{trigger.to_state.name}} {{'arrived at' if is_state(trigger.to_state,'home') else 'left'}} home.
if I’d use the
- delay: 60
ending the action block, I would prevent triggering all together, while it could be a different daughter entering the premises
Ok, thanks, I see what you did there. Yes, this looks like potentially a common use case, so it might make sense to add something “native” for it. Although I wouldn’t call it “trigger_delay”, since that would have the wrong connotation. Maybe something more along the lines of “min_trigger_period” or something. Yeah, I’d say, go ahead and add a WTH or Feature Request topic.
cool, I’ll do that. Prefer the WTH for now, since the has the dev’s attention
I will also link to this topic.
thanks!
edit