why use a generic when you have the actual turn_off? I haven’t gone through the code so I can’t be certain it will help better. All I can say is that I would trust script.turn_off more than homeassistant.turn_off based on helping people in the past.
Not to mention, I just found a way to get visual countdowns in lovelace using just a single timestamp. It’s complicated, I plan on posting about it in the future.
I hope not too far in the future… I could use it 
Struggling to make it work. It might not be possible. (without a custom card)
Could your timestamp method replace the current timer integration and repurpose whatever lovelace web gatdgety thingy that uses?
It’s already built into home assistant. I’m just trying to use the element in the button card. A custom card would be able to use the element with a specific format and it would countdown. You’d just need to make a sensor with the state set as the starttime with the under the hood format (YYYY-mm-ddTHH:MM:SS.FFFFFF+ZZ:ZZ), the one you see in last_updated etc.
Problem is: I don’t know what I’m doing in these languages. I only half know. I understand the code, but not all the calls so I have to poke around. I don’t know ts or js languages so I have to google every call and just stare at docs.
A familiar feeling 
1 Like
Now you know how the rest of us mere mortals feel every day! 
Yeah, I started reading your replies and I was really confused about why my suggestion wouldn’t work for you when it worked perfectly for me. 
But it’s good to know it worked to at least get you going before you decide if you’re going to jump in and change things around per petro’s suggestions.
do I get it right that every automation that uses delay should be converted like
action:
- service: script.turn_off
data:
entity_id: script.instead_of_action
- service: script.turn_on
data:
entity_id: script.instead_of_action
looks a bit stupid as internally they definitely can turn a running script off before turning it on and I believe it would cost nothing.
Is the script/automation proceed from after delay if called again while already running?
By the way, there is nothing about it in docs or is it?
Well, I think it’s personal. At some point I converted some of my subsystems (namely, alarm PIRs and heating control) to timers and they work solid. Maybe it depends on what functionality is used.
I don’t use ‘visual countdown’ (and that bit is not ideal, just waiting for some PRs to improve it).
Depends on how your automations are built. The only time delay in an action causes a problem is if the automation triggers again whilst in the delay. If you can design around that ‘feature’ then you don’t need to use a script. Using the script is an option, but that option is two-fold. If you do it the way you did it it would stop the first run of the script and start it again from the beginning. If you don’t stop the script in the action, then the second call will be ignored and the first one continues uninterrupted.
So it’s all dependent on your use case and how you’ve designed your automations in the first place.
Agree. I personally don’t use such technique but was curious as it seems like many people get caught by scripts not running when they try to run them again (and there is nothing in the docs about the behaviour you’ve just described). And it was a surprise to me that automations are the same in that department.