Do something when Alexa Timer has expired

Blueprints Exchange
,
Tags: #<Tag:0x00007f325f9c1d80> #<Tag:0x00007f325f9c1c68>
#1

image
image661Ă—687 32.7 KB

When a timer of an Echo or other Alexa device has expired, the defined actions will be executed. Fo example, you can make your lights flash or turn off a smart plug.

Requirements:

Blueprint:

Click the badge to import this Blueprint: (needs Home Assistant Core 2021.3 or higher)

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

blueprint:
  name: Do something when Alexa Timer has expired
  description: When a timer of an Echo or other Alexa device has expired, the defined actions will be executed.
  domain: automation
  input:
    echo_device_next_timer:
        name: Alexa Device
        description: Please select a sensor.*_next_timer entity to define the observed Alexa Device.
        selector:
            entity:
                domain: sensor
                device_class: timestamp
    target_action:
        name: Action
        description: What should be done, when the timer expires?
        selector:
            action:
            
variables:
  timestamp_sensor: !input 'echo_device_next_timer'
  
trigger:
  - platform: state
    entity_id: !input 'echo_device_next_timer'
    
condition:
  - condition: not
    conditions:
      - condition: state
        state: unavailable
        entity_id: !input 'echo_device_next_timer'
        
action:
  - delay: >
        {% set index = (((state_attr(timestamp_sensor, 'sorted_active') | from_json)) | list | length) - 1 %}
        {{ ((state_attr(timestamp_sensor, 'sorted_active') | from_json)[index][1].remainingTime/ 1000)| round(0) }}
  - condition: not
    conditions:
      - condition: state
        entity_id: !input 'echo_device_next_timer'
        state: unavailable
  - condition: template
    value_template: '{{ as_timestamp(states(timestamp_sensor)) - as_timestamp(now()) < 0| int}}'
  - choose:
    default: !input 'target_action'
    
mode: parallel
max: 10

Thanks to @finity for contributing ideas and code to this blueprint.

2 Likes
Alexa Media Player timers as a trigger
Heads up! Upcoming breaking change in the Template integration
Adding another trigger/condition to an automation that is running from a blueprint?
#2

Any way you could just use turn_on and then turn_off because some lights don’t support flash?

#3

This should be possible, but requires a lot of logic, since you also have to look at the current state of the lights. For example, if a light is on, it must also be on afterwards. If it is off before, it must also be off afterwards. This is difficult, because you don’t select a single entity as a light, but whole groups.

Which lights are affected by the problem? I use Philips hue and Osram Lightify - they support it.

#4

some things in the automation part don’t make sense:

why do you have this (constantly counting down to 0) delay as the first action?

- delay: '{{ as_timestamp(states(timestamp_sensor)) - as_timestamp(now()) | int}}'

what actually triggers the automation to start the actions?

when I set a timer the state changes once and never again after that. Unless it’s watching for a change in the attributes continuously then once that state is set to the time then the trigger is gone.

unless the reason for the above delay is to capture the original amount of time in the timer then use that to set the delay? I then see that you have a test that the timer end time is before now before the lights flash.

if that’s the case then why not just use the second condition (checking if now is after the timer end time) to actually trigger the automation and remove both the delay and that condition?

and last (I think…) why do you create the timestamp_sensor variable, put the timer entity into it then use the timestamp_sensor in the time calculations? Why can’t you just use the echo_device_next_timer directly in the time calculation?

They all seem redundant to me and overly complicate the code unless I’m overlooking something obvious.

#6

Every state-change of the observed sensor.*_next_timer entity.

You are right, it is possible to directly use echo_device_next_timer.

Home Assistant evaluates triggers only when the state of the observed entity changes. But here only now() changes – there is no state change when the timer expires. Therefore, this trigger would not work.

#7

in the recent versions of HA now() is observed just like any other entity and would cause the template to be evaluated as well. It updates every minute. - https://www.home-assistant.io/docs/configuration/templating/#time

#8

Obviously, updating every minute is not enough. My solution offers an immediate reaction. Actually, I don’t quite understand what’s wrong with this blueprint. Sure, there will be other solutions to do this. If you’re able to do this, you’re welcome :slight_smile:

#9

But how could that be?

the timer entity only ever updates once when the timer is set. Then you are using that unchanging state to then compare to the now() function. And the now() function in a template still only updates every minute. So there is nothing there to trigger an evaluation of the template more than once every minute.

So how does yours update immediately in the action but using the same template as the trigger is “obviously…not enough”?

I’m just trying to help you streamline your code. And to help others who see and use your code streamline theirs as well. If you don’t want to modify it then you can obviously do what you want. But at least you’ve learned something. And if you haven’t at least I tried… :slightly_smiling_face:

#10

It looks like there are some misunderstandings with the code. The light-flashes are executed after the delay-action, which ends exectly at the same time as the timer does. So there is no trigger needed at the time the timer expires.

Comments are of course always welcome. At this point, however, I would suggest that you give this blueprint a try to convince yourself of its functionality.

#11

I agree

but only if the update for the now() function is evaluated at exactly the same time. Since it only updates at the minute then it’s not guaranteed to happen at the same time. Which is likely why you needed to put the “< 0” comparison in there. If you put “=0” then it’s likely that the condition will never be met and so the action steps after that will be aborted.

As far as the delay it seems like you are using it as a sort of timer since the template will begin counting down using the now() function. Delays aren’t timers, per se. The setting isn’t meant to count down. They expect a fixed value. But even if they did work like that since the now() in a template only updates every minute then the delay will count down only around 60 seconds every jump. It won’t count down every second and so it will not instantaneously time out and continue the actions the second that the timer is finished.

you can test this for yourself.

Put the templates for the delay and the final condition into the template editor and watch what happens. you will see that the templates are only evaluated every minute (or if you cheat you can force an update by refreshing the page but that defeats the purpose of the test).

#12

Not really.

The light.toggle service in a repeat while with a final light.turn_off to ensure it isn’t left on.

However, I agree it’s more efficient to use flash if the light supports it.

#13

My Tuya lights don’t support flash.

#14

To move forward at this point, I would ask you to suggest a concrete alternative, as you say less complex, way of implementation. Then I can check if your theoretical approach works in practice.

#15

Oh well, good idea, I hadn’t thought of the toggle service. It should work with that.

#16

Here is a simplified version in automation format that works the same as the blueprint.

- alias: Flash Lights when Alexa Timer has expired
  trigger:
    - platform: template
      value_template: "{{ (as_timestamp(states('sensor.garage_dot_next_timer')) - as_timestamp(states('sensor.date_time_iso'))) <= 0 }}"
      # value_template: "{{ (as_timestamp(states('sensor.garage_dot_next_timer')) - now().timestamp()) <= 0 }}"
  condition:
    - condition: not
      conditions:
        - condition: state
          state: unavailable
          entity_id: sensor.garage_dot_next_timer
  action:
    - service: switch.toggle
      entity_id: switch.garage_lights_switch
    - delay:
        seconds: 1
    - service: switch.toggle
      entity_id: switch.garage_lights_switch
  mode: parallel
  max: 10

I originally had the now() function used to trigger the automation but then I found that there is a bug using now() to trigger automations (even tho it works exactly as expected in template sensors).

It still won’t be guaranteed to trigger at exactly the same time as the timer ends since both the datetime sensor and now() will only ever update at the start of every minute. They removed the possibilities of us using sub-minute triggers a couple of releases back and there hasn’t been a satisfactory resolution (that I’m aware of) to trigger down to the second. So unfortunately it could be up to a minute late triggering the lights to flash after the timer expires.

edit: I take that back…

It is a hack but I think you could start a HA timer for the same duration as the alexa timer then use the timer finished as the trigger to flash the lights. It’s the only way I know to get the one second update frequency since now() ever only updates every minute.

You could do that in one automation but it does get more complicated. If I get it worked out I’ll post it later.

#17

Thanks for your reply. I tried it out and as you said, the trigger is not triggering perfectly on the second. There is still a big delay. Still, thanks for taking the trouble to contribute as well.

Please give my automation a try. I know, it’s not perfect in coding style, but it’s working perfectly to the second. I don’t think, that there is a less complex way to do it that works to the second. You will be surprised how reliable it works :wink:

#18

hmmm…

I agree and it was partly me…

it seems that the template containing the now() function in the delay gets forced to be evaluated and is set immediately when the automation is triggered and then completely ignores any values after that so the now() function in the delay never needs to be re-evaluated after that and if it does then it doesn’t matter. So the “evaluated only at the start of the minute” statement in the docs isn’t entirely valid.

And then the condition is treated the same way in that the template gets forced to be evaluated at the end of the delay. So as long as the delay is set correctly the lights get flashed at the same time the timer expires.

All of that adds up to it working as you say it does…

So I was wrong.

BUT :wink:

I still say that I don’t see a reason for that variable. just use the timer state directly in the calculations.

But too… :slightly_smiling_face:

As I’ve been playing with this trying to work out how this is supposed to work and I saw there is a limitation in that it will only work correctly if there is only one timer active at a time.

Unless you stop the timer that has already expired before the completion of the next subsequent timer then the timer state will never change and all of the templates that use the state to calculate the delay and the condition won’t work correctly. Once you stop the currently expired (but still “active”) then the state changes to the correct completion time for the next timer or to the time that the currently completed timer is stopped - whichever is later.

I know that’s confusing but as an example:

start a one minute timer. Then start a two minute timer.

after the one minute timer expires the automation causes the lights to flash. But if you DON’T stop the expired one minute timer and you allow it to keep going (for another let’s say 5 minutes) the second timer expiring won’t flash the lights again when it’s done. But once you do stop the first timer then the state updates to that time (even tho it’s been 4 minutes after the two minute timer should have expired) and then the lights will flash.

At least that’s been my experience in testing this out.

There has to be a way to be able to determine the delay of each subsequent timer that is set to trigger each parallel run of the automation to correctly flash the lights when each timer expires.

I’m still going to plug away at that part and I’ll post it here if you are interested. Let me know if you are.

This has fun digging in and trying to figure out how this works. Even tho I was wrong… :smiley:

1 Like
#19

Hi,

installed (is it called like this? :slight_smile: ) this blueprint but actually I think my light (original Hue light E27 Color connected to bridge) is not supporting “flash”.
In the description it said that this was supported, is this wrong? When I just trigger the automation created based on the blueprint, nothing happens aswell :frowning:

#20

Is it a light on the hue bridge? You can try the “flash” functionality like this in the developer tools:

image

#21

Yes, you are absolutely right about that. I don’t think there is a way to get rid of this, as the alexa integration will only inform us about the second timer AFTER stopping the first one. So if you have 2 timers, like a one minute timer, and a two minute timer starting at nearly the same time, and you stop the first timer directly after it expires, then the second timer will flash the lights as well. If you don’t stop the first one, then you’ll miss the second one. Hopefully you want to stop the first one, otherwise your echo keeps ringing for quite some time :stuck_out_tongue:

Yes. I’ll remove this redundency in the next release.

Every contribution is apprechiated. I’ll work on a blueprint version where the user is able to select the action themselve, too. This will get us rid of the “flash”-problematic that some lights don’t support it as well.

1 Like