Good point. It’s certainly conflicting with my other statements lol.
1 Like
how did that “template stop working” look like, could you explain?
UPDATE: as pointed out by Mutt, you need to remove double quotes surrounding your template if you use value_template: > for it to work as expected (because with quotes the result of your template will be that quoted string, no real template rendering there)
Well, I hoped to use the remaining attribute but it’s not usable atm.
I think Tom’s suggestion is good enough - just create a sensor that is updated every minute, it’s simple.
For the data source use input_datetime - store time when you start your timer and use it instead of remaining in that template sensor above. A bit complicated but it does work.
One of my sensors for LL shows number of seconds if it’s less that a minute and then updates every minute - looks great 
It has nothing to do with timers but the approach is exactly the same (apart from I don’t use sensor.time at all, update is done by an automation with a template trigger)
UPDATE: tried to start a timer with duration: 90000 and its countdown just disappears
And yes, there currently is an implicit limit - the function used assumes it’s always HH:MM:SS so when it gets days it doesn’t work as expected.
I’ve just created a new issue.
@AhmadK I must admit I was a little overwhelmed with the help that I was getting. I obviously was not conveying very well my issue.
You are also all correct about the double quotes in the template, they should not be there. It did not stop the template from working, the double quotes where appearing on the display as strings before and after the date. My apologies if I created confusion by leaving them.
@AhmadK I am quite happy that you found the issue. I am grateful to all for the help.
1 Like
you edited your initial post so I spent some time finding where I saw that hint about conversion to string.
Actually, I think that’s another issue with timer - even if they fix the Lovelace bit, one won’t be able to use duration attribute in their automations directly as they’ll need to convert its string representation back to datetime/whatever. And it’s poor because currently we don’t know what the format is (well, it’s easy to guess but it’s a) not documented b) can be changed in the future and c) a bit stupid as it adds a lot of hassle for no reason…)
@AhmadK @jocnnor Indeed I think this is not an ideal situation for any UI’s such as LL. The retrieval and formatting of the dates is a little hazardous for any of the dates from the Timer integration to convert to its liking.
If I was to provide my two cents: I would have all the date attributes to the Timer integration provided with a know format such as the Julian Format for the UI’s to access and use. And if needed have the same date attributes duplicated in a pretty format for its own use.
Sorry for bringing this topic back online but I have hit a new snag.
In this thread the Timer countdown process was identified as having an issue if the Timer was set for more than one day. Less an issue for me as long as the timer was still functioning.
I think I found a new problem that I need help with. If I set the Timer for two days or more, it will set itself for the time requested excluding the duration. Example, the timer was set for a duration of two day but the timer did not include the requested duration.
<template state sensor.climate_incubator_timer1_state=07 May, 11:26 - Active; friendly_name=Timer 1 state: , icon=mdi:timer, package=incubator @ 2020-05-07T11:26:35.530456-04:00>
Any suggestion would be grand.