Automations are triggered by events. Something happening is an event. Something not happening is the absence of an event. How can something be triggered by something not happening???
Not sure I understand why you “fear” a valid, reasonable solution. It is creating the event you’re looking for. I.e., when the timer expires, then the cover hasn’t moved in the specified time period, and that’s the “event” you want.
I don’t use covers, and I’m not that familiar with how they generally work, but yes, I’d agree that this is something the cover entity should do – i.e., indicating it’s moving or not. This isn’t in the state? I.e., open, closed, opening, closing, …???
Regarding you last solution, why would this not work (i.e., without the need for the automations/scripts):
Oh. I Didn’t know that.
I posted this code as I not long ago did something similar, and this was the code I used (I of course adapted it to this example).
I also see that my code doesn’t really add anything compared to your code further up the thread. But hey, nobody complains about to many examples
of course it can’t. No, I was looking for the end of the triggering event. But that will probably be clear…
Well, fear might be a bit heavy. Surprised would be better? that we have to create the even manually, use a timer with a hardcoded length, instead of the integration doing that in core. We cant use a template like in the media_play.play media where we use the length of the media file. Here we have to estimate. Since the automation triggers each second, I figured 2 seconds would be enough for the ‘off’ event to be created. But that was just a bit sharp. restarting for 3 now…
It would be really nice to have an event_stopped event in HA core. We have many events that are binary, these are clear. This one isn’t, (clear nor digital) but would warrant its own
No, its state is always open or closed, hence my FR to change that, as apparently other cover integrations do. Or at least have an attribute.
I dont know, I ave been struggling with this all day, in many variants. it simply doesnt track the value_template, other than on sensor.time. Which can take up to a minute. Which of course is unacceptable for a frontend representation.
the input_boolean is a nice technique indeed. Just too bad it isn’t using the new Script logic was really happy to use the script and mode: parallel as I had posted it…
An “event stopped” event? What is that? What does that even mean? And what do you mean by “events that are binary”? An event is something that ocurrs in an instant, it’s not off & on.
I think you mean you want “something” to monitor for a particular event, and after it sees it, it waits until it doesn’t see it for at least X seconds, and when it doesn’t it does something (fire another event, trigger an automation, etc.) And then it starts monitoring for the event again, …
FWIW, you could probably do something like this (using the new automation capabilities that are hopefully coming soon):
Every time cover.raamverduistering_stookhok changes state (or an attribute changes) the action will start running, or restart running. So the service step would only be executed if the entity changed at least once, and then didn’t change for at least 3 seconds.
Is that what you’re wanting?
And since the new modes will only be available in scripts first, then you could do this instead:
for starters, this works now, perfection. So a big thanks is in order! thanks.
automation:
- alias: Cover stookhok is moving
trigger:
platform: state
entity_id: cover.raamverduistering_stookhok
action:
# service: script.trigger
- service: input_boolean.turn_on
entity_id: input_boolean.raamverduistering_stookhok_moving
- service: timer.start
entity_id: timer.raamverduistering_stookhok_moving
- alias: Cover stookhok no longer moving
trigger:
- platform: event
event_type: timer.finished
event_data:
entity_id: timer.raamverduistering_stookhok_moving
condition: []
action:
- service: input_boolean.turn_off
entity_id: input_boolean.raamverduistering_stookhok_moving
- service: notify.system
data_template:
title: Cover is no longer moving
message: >-
Cover is
{%- set position = state_attr('cover.raamverduistering_stookhok','current_position')|int %}
{%- set phrase = 'positioned at: ' %}
{%- if is_state('cover.raamverduistering_stookhok','closed')%} Closed
{%- elif position|int == 100 %} Open
{%- else %} {{phrase}}{{position}}
{% endif %}
and, this customization reflects that in the frontend:
homeassistant:
customize:
cover.raamverduistering_stookhok:
templates:
icon: >
if (entities['binary_sensor.raamverduistering_stookhok_moving'].state == 'on') return 'mdi:animation';
if (state == 'open' && attributes.current_position == 100) return 'mdi:window-shutter-open';
if (state == 'closed') return 'mdi:window-shutter';
else return 'mdi:window-shutter-alert';
icon_color: >
if (entities['binary_sensor.raamverduistering_stookhok_moving'].state == 'on') return 'red';
if (state == 'open' && attributes.current_position == 100) return 'gold';
if (state == 'closed') return 'darkblue';
else return 'green';
not sure this is true, at least not in the way I meant it to. I tried to express the desire to template the time it takes to go from moving to not moving. Might be a chicken an egg issue…
yes, an event stopped. the event would be state_changed_to_moving. and state changed from moving to not moving. or playing, or any other event that takes more time than the instant.
But, maybe this is all caused by the integration not correctly stating the opening/closing.
I’d simply like to trigger as we can do with a light. turn_on/off, and between it is glowing. these event are missing here. I can only trigger on the attribute current_position to be changing…
hmm, I guess yes, will have to try and see if that ends up doing the same How would the binary_sensor need to be templated with this? because that’s the end goal, have a binary change state, and show the frontend the cover is moving or not.
so a little more experimenting seems to allow for determining ‘opening’ and ‘closing’, by adding 1 script.cover_stookhok_position, and adding that in the sequence before the existing one:
script:
cover_stookhok_position:
alias: Cover stookhok position
mode: restart
sequence:
- condition: template
value_template: >
{{toposition != fromposition}}
- service: input_boolean.turn_on
data_template:
entity_id: >
input_boolean.{{'cover_stookhok_opening' if toposition > fromposition else 'cover_stookhok_closing'}}
# below not needed because booleans are turned off anyway. and always start from 'off'
# - service: input_boolean.turn_off
# data_template:
# entity_id: >
# input_boolean.{{'cover_stookhok_opening' if toposition < fromposition else 'cover_stookhok_closing'}}
automation:
- alias: Cover stookhok
trigger:
platform: state
entity_id: cover.raamverduistering_stookhok
action:
- service: script.cover_stookhok_position
data_template:
toposition: '{{trigger.to_state.attributes.current_position}}'
fromposition: '{{trigger.from_state.attributes.current_position}}'
- service: script.cover_stookhok
this in turn allows me to customize the icon even better, and, instead of the ‘motion’ icon, show ‘archive-arrow-down’ and ‘archive-arrow-up’
which is a nice and unforeseen use of these ‘Archive’ icons…
homeassistant:
customize:
cover.raamverduistering_stookhok:
templates:
icon: >
if (entities['input_boolean.cover_stookhok_opening'].state == 'on') return 'mdi:archive-arrow-up';
if (entities['input_boolean.cover_stookhok_closing'].state == 'on') return 'mdi:archive-arrow-down';
if (state == 'open' && attributes.current_position == 100) return 'mdi:window-shutter-open';
if (state == 'closed') return 'mdi:window-shutter';
else return 'mdi:window-shutter-alert';
icon_color: >
if (entities['binary_sensor.raamverduistering_stookhok_moving'].state == 'on') return 'red';
if (state == 'open' && attributes.current_position == 100) return 'gold';
if (state == 'closed') return 'midnightblue';
else return 'green';
Then you could do your notifying based on state changes of input_select.raamverduistering_stookhok in a separate automation. And, of course, change your icon customizations based on the one input_select instead of two input_boolean's.
I suppose you could even extend the options to include closed, opened & partially_opened, and at the end of the script, use new|float to decide if the cover was fully closed, fully opened, or somewhere in between.
as a matter of fact, I was already tinkering with that … My notification does something alike already.
for reference up to the post before the above, I can confirm all issues gone! no incidental double turned on booleans, which are now replaced by the input_select. Ive simply added the notification to the one automation as final step:
raamverduistering_stookhok:
mode: restart
sequence:
- service: input_select.select_option
entity_id: input_select.raamverduistering_stookhok
data_template:
option: >
{{'opening' if new|float > old|float else 'closing'}}
- delay: 2 # might require 3, to be seen in practice
- service: input_select.select_option
entity_id: input_select.raamverduistering_stookhok
data:
option: stationary
- condition: state
entity_id: input_boolean.notify_developing
state: 'on'
- service: notify.system
data_template:
title: Cover is no longer moving
message: >-
{{as_timestamp(now())|timestamp_custom('%X')}} - Cover is
{%- set position = state_attr('cover.raamverduistering_stookhok','current_position')|int %}
{%- set phrase = 'positioned at: ' %}
{%- if is_state('cover.raamverduistering_stookhok','closed')%} Closed
{%- elif position|int == 100 %} Open
{%- else %} {{phrase}}{{position}}
{% endif %}
When a template is rendered has more to do with where that template is used than by the template itself. E.g., if it’s used in a condition of an automation, then it is rendered when a trigger fires. But if it’s used in a template trigger, or a template sensor, that’s a different story. It’s that use case that determines when to render the template. E.g., as currently implemented, there would be no way to get that template to render based on time changing if it was used in a template trigger. But if it was used in a template sensor, then one can use the sensor’s entity_id option to force when the template is evaluated.
because the input_select can be manipulated in the frontend, and here it is only used to store the state the automation sets it to, Ive also created a safer sensor, to show in the frontend:
sensor:
- platform: template
sensors:
cover_stookhok_position:
friendly_name: Stookhok position
value_template: >
{% set position = state_attr('cover.raamverduistering_stookhok','current_position')%}
{% set state = states('input_select.raamverduistering_stookhok')%}
{% if state == 'Stationary' %} {{state}} at {{position|int}} %
{% else %} {{state}}
{% endif %}
Question, considering the above: there is no backend option to set for an input_select, to not allow manual manipulating somehow?
