Allow timer.change to exceed timer’s original duration

The timer.change service allows for the addition or subtraction of time on a currently running timer. This is helpful because the timer doesn’t have to be stopped or restarted.

Currently, when adding time to a timer, you cannot exceed the original duration (set when timer started).

I’d like to request that this limitation be removed or made configurable.

As simple use case is starting a one hour timer when turning on a fan. Sometimes I want to run longer than an hour, but most times an hour is fine. So ideally, I’d use a button to fire the timer.change service, adding 15 minute increments up to the desired duration.

—-

This is my first feature request. If I missed something or messed this up, please let me know.

—-

Thanks,
Doug

The intended functionality here will probably need to include live-updating the remaining attr on the timer, as it still doesn’t work to call timer.change with some amount less than the time elapsed, on an actively running timer, since timer.change appears (based on my testing) runs this “exceeded” check on the difference between duration vs remaining, which is generally 0 unless the timer gets paused.

Since pausing a timer is, I think, a pretty uncommon use-case, my vote is definitely for fixing the remaining attr along with the aforementioned feature request, so that it live-updates while the timer is running.

I agree, but allow me a comment.
Pausing a timer is not an uncommon use-case.

I use it on many automations. E.g. motion lights on shower, pause timer when having a bath

Thanks for adding your thoughts. I can’t speak to how common it is for other users, but I use timers extensively and pausing them is an important and commonly used feature at our house!

1 Like

For those that may have found this post while trying to change a timer past the original duration - I’ve discovered it can be achieved with the timer.change service.

You first have to decrease the timer by any amount, and then you can increase the timer past the original duration.

This is a workaround I use routinely now. I don’t know if it’s intentional. I found this unintentionally while testing if I could change a timer at all and saw I could decrease it first and then increase it past the original duration.

IMHO, I think removing the block in a flag on the helper or more generally just allow the user to set a timer past the duration with the service call intended to increase the duration under the scope of “the user knows what they’re doing”, would be useful

The workaround didn’t work.

I did try to decrease, say, 1 minute, and try to increase the timer again past the original duration and it still doesn’t allow me to.

Hmm, you’re right. It consistently works for me doing a subtraction, then addition, if I don’t exceed the original timer amount, even though me adding any time after subtraction is “exceeding it”.

I do have to subtract any amount of time before I can add to the timer as long as it’s under the superficial “original timer” value.

yes, which I believe it is actually a bug itself as you should be able to increase the time if it’s under original timer limit.

1 Like

It seems like a bug with how it works, becasue of the way you can subtract time, then add time up until the superficial time limit.

The feature got my +1 vote.

1 Like

I have been using the following work around to overcome the limitation. Basically start the timer with something very big, then substrate the timer to what you need. Then you have the flexibility to add further time later.

1 Like