timer: timer.start doesn't restart the timer if already running

[jackwilsdon]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version): 0.62.0

Python release (python3 --version): Python 3.6.3

Component/platform: timer

Description of problem: The timer does not restart if timer.start is called on a running timer.

Expected: The timer restarts.

Problem-relevant configuration.yaml entries and steps to reproduce:

frontend:

homeassistant:
  name: Home

http:

script:
  start_timer:
    alias: Start Timer
    sequence:
      - service: timer.start
        entity_id: timer.timer
  pause_timer:
    alias: Pause Timer
    sequence:
      - service: timer.pause
        entity_id: timer.timer
  cancel_timer:
    alias: Cancel Timer
    sequence:
      - service: timer.cancel
        entity_id: timer.timer
  finish_timer:
    alias: Finish Timer
    sequence:
      - service: timer.finish
        entity_id: timer.timer

timer:
  timer:
    duration: '00:01:00'

1. Start the timer
2. Wait a few seconds
3. Press the start button again
4. Observe that the timer hasn't restarted

Additional info:

I've done some investigation into this, and it seems to be due to the fact that the timer's state isn't changing, so HASS is discarding any changes made to the timer(?).

The logic to adjust the end time also isn't quite right.

This patch fixes the logic and also fixes the restart, however updating the state twice doesn't seem like the right way to do it.

index 84d2d3f34..b441e2380 100644
--- a/homeassistant/components/timer/__init__.py
+++ b/homeassistant/components/timer/__init__.py
@@ -249,17 +249,20 @@ class Timer(Entity):
         # pylint: disable=redefined-outer-name
         start = dt_util.utcnow()
         if self._remaining and newduration is None:
-            self._end = start + self._remaining
+            self._remaining = self._duration
         else:
             if newduration:
                 self._duration = newduration
                 self._remaining = newduration
             else:
                 self._remaining = self._duration
-            self._end = start + self._duration
+        self._end = start + self._duration
         self._listener = async_track_point_in_utc_time(self._hass,
                                                        self.async_finished,
                                                        self._end)
+        self._state = STATUS_PAUSED
+        yield from self.async_update_ha_state()
+        self._state = STATUS_ACTIVE
         yield from self.async_update_ha_state()

[fabaff]

Hmm, starting a running timer again sounds like a reset service. It's a bit like calling pause on a paused timer to restart it.

For manual interactions by a human it might be clear what happens but using service calls which have different outcome depending on a state in automation rules will become cumbersome. You need pretty much to track the state because a second start will reset the timer and not start it again with the current remaining time.

[jackwilsdon]

Ah I didn't think of the repercussion of the fix I suggested - you can't resume a paused timer! A timer.restart service may be better in this case.

[point-4ward]

Don't know whether this is 'working around a bug' or just 'working with what we've got', but this is how I've handled it from the perspective of having a slider in the ui that you can drag to set the timer. Dragging it again sets the timer again, dragging it to zero cancels it...

https://github.com/mf-social/Home-Assistant/blob/master/packages/virtual_devices/timer.yaml

Hope it helps.

[toggledbits]

Plus one. This is a change in behavior from prior versions, and the documentation clearly states that the timer.start service "Starts or restarts a timer with the provided duration."

[rbflurry]

I have an automation that starts an already started timer with a new time and it seems to work correctly. Am I missing something?

603 - door opens triggers automation to turn on light and start timer for 10 minutes
603 - light comes on
610 - door opens again and triggers automation to start timer for 10 minutes
620 - timer ends automation fires to turn off the light.

[toggledbits]

Mine did too, up until 0.62, then no.

[droopanu]

I just noticed the same behavior.
A timer.start on a running timer used to restart the timer from the initial or specified duration, just like the documentation specifies.
Now, a timer start on a running timer does not do anything, unless a duration different from the initial one is specified.
A workaround would be to add a random number of seconds to the desired duration everytime timer.start is called.

[toggledbits]

Now at 0.65.6 and this is still an issue. To recap, the documentation states that timer.start on a running timer restarts the timer (optionally with a new duration if specified). Current behavior is that the timer does not restart, whether a duration is specified or not. And in fact, I can get a timer that shows a duration and is in running state, but never decrements and never finishes. Please fix this core, fundamental component.

[rbflurry]

This is still working correctly for me. Every time the back door opens or closes an automation sets the timer to 10 minutes. The timer should end 10 minutes after the last time the door opened or closed.

[joshbish]

I also thought this wasn't working because the timer on the front end doesn't visually reset. However, I've noticed that even after the timer ends on the front end, it appears that it actually did reset because my trigger doesn't occur until later, when I'm expecting it to.

[taanczos]

Any news with this issue?

[toggledbits]

Sorry, just got back from vacation. Will test ASAP

[toggledbits]

OK. I am currently running 0.73. In this version, sending timer.start to a running timer does the following:

1. With no "duration" specified, the timer continues from where it is, it does not restart from the last or default (originally configured on the timer) duration.
2. When specifying a duration in the timer.start action that is longer than the current remaining time, the duration is ignored. That is, with 57m:30s remaining on the timer, sending timer.start with a duration of 01:00:00, the timer continues counting from 00:57:30, it does not reset to 01:00:00.
3. When specifying a duration shorter than the current remaining time on the timer, the duration resets down to the specified duration--if 00:57:30 is remaining on the timer, and the timer.start action is sent with a duration of 00:30:00, the timer starts counting down from 30 minutes.
4. After test Added simple process state monitor source. #3, if I specify a longer duration, I get a longer duration than remaining but shorter than specified (with about 20-ish minutes remaining, specifying a duration of 1 hour gave me 50 minutes on the timer). I feel like I'm in the twilight zone.

I am on 0.73, and this version does not have the @jackwilsdon changes. I'll make them in-situ and retest. Let me know if you have any additional instructions.