Core: Timer - Remaining attribute is stale

[ejonesnospam]

Home Assistant release with the issue:

Last working Home Assistant release (if known):
Initial examination of timer attribute 'remaining', so no known version of working status

Operating environment (Hass.io/Docker/Windows/etc.):

Docker, raspberry pi 3

Integration:

Description of problem:

A countdown value is properly displayed to the user via the web interface, but the timer attribute 'remaining' is stale while a timer is 'active'. This impacts scripts or automations that examine the timer's current 'remaining' value. Timer attributes 'remaining' and 'duration' are only altered when a timer is started, stopped, paused, or finished. While this has no issue with 'duration', 'remaining' should be periodically updated to reflect the latest value that is also being displayed to the user on the web interface.

As a temporary action to force the 'remaining' value to be updated, the timer can be paused and restarted, and the remaining value will become accurate again. However, this action may delay the timer's expected completion time and is not ideal.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[elupus]

Time changing attributes are avoided in state machines. So to be honest, that attribute should probably be removed. You need to calculate remaining time based to target time and now.

[ejonesnospam]

Sure, that could be a new improvement, since only 'remaining' and 'duration' attributes are published. And, just replace 'remaining' with 'completion-time', which I assume would be a time in UTC?

Another alternative would be to update the 'remaining' attribute once per minute, typical of most sensors in home-assistant. Perhaps the "seconds" portion of value could even be eliminated for precision and clarity.

Overall, IMHO, it feels more complex to replace 'remaining' with 'completion-time'. When the timer enters a 'paused' state, the 'completion-time' value again becomes invalid, so another field must be examined, presumably 'duration'. Whereas, 'remaining' remains valid.

[elupus]

All state changes are stored in database, which generate IO. It both grows database, and cause wear on sdcards.

So we try to keep such things at a minimum.

[springstan]

Completely agree with @elupus statements and therefore would suggest you @ejonesnospam close this issue since the raised issue is by design. Thanks for understanding :)

[elupus]

Well I think it can be open. The remaining time should either be fixed or removed. It's not working now.

[springstan]

Oh yeah sure overlooked that sorry.

[ejonesnospam]

I do understand your perspective as an infrastructure developer, but I don't see how the issue has yet been resolved. "Remaining" attribute is still stale when timer is active.

Clearly, there are ways to improve or clarify the code. If this community doesn't see a value in pursuing this discussion or change, my issue is with the documentation, rather than the code.

[ejonesnospam]

I still request that "remaining" should at least be replaced by "completion-time", so an expected timer completion date and time could be calculated.

[Adminiuga]

Would it make sense for completion time to be a timestamp or as datetime?

[ejonesnospam]

If someone still feels this issue should be closed, we could just rename 'remaining' to 'remaining-time-occassionally-but-not-normally'. Thanks for your understanding :(-

[elupus]

31469 is probably related

[akasma74]

I want to add something to the picture.
In my automations I sometimes need to adjust (service timer.start with another duration) a running timer's duration because of user input. To do so I need to know when it was started for the last time (I don't pause them).
The problem is in the timer object I have no such data as last_changed does not reflect it and remaining is not updated. So every time I (re)start the timer I store current time in an input_datetime and use it in calculation of adjusted time when needed. A bit ugly but I have no choice (and yes, it adds to the impact on sdcard wear, much less than remaining though).
My point is that in theory the remaining attribute could be really useful and before removing it a comparable substitution should be provided.

Another point is that design of components should not be so tightly tied to internal structure's implementations - I mean, a proper timer component should be designed so it has all attributes and services required. The fact that it might have negative impact on sdcard should be mitigated on the db level, for example - have a db in memory and sync it with sdcard frome time to time.
When we deliberately limit component's functionality because of non-ideal infrastructure, that hinders everything.

[Adminiuga]

@akasma74 I hear you, but the bottom line: remaining attribute should not be in the states machine.
I suggest to open an architecture issue and explain your use case. Would something like extend_time with a positive/negative number work in your use case?

BTW, last_changed should be part of the state object which should be accessible from the templates, no?

[akasma74]

I suggest to open an architecture issue and explain your use case.

You mean it should be something like "what to replace the remaining attribute with"?
I think I can do that so others would add their bits to the discussion.

Would something like extend_time with a positive/negative number work in your use case?

I often need to adjust duration of an active timer as a reaction on user input. For example, the timer was started with duration=10 min. Then 2 cases are possible:

1. after 7 minutes user changes duration value in UI to 9 min. As the timer was started less than 9 minutes ago, I would change the duration (call timer.start with the remaining duration) so the timer runs for another (9-7)= 2 mins.
2. after 7 minutes user changes duration value in UI to 5 min. As the timer was started more than 5 minutes ago, I'd need to cancel it.

In both cases I need to know when the timer was restarted for the very last time but currently no such information is provided by the component.
For example, last_changed doesn't help as I often need to restart a timer before it expires so its last_changed is usually way in the past (holding last time when the timer was started) and therefore is useless in calculations.

[akasma74]

@Adminiuga @ejonesnospam @elupus @springstan can you have a look at our discussion regarding the meaning of remainingattribute?
maybe you have something to add?

[ejonesnospam]

My previous suggestion is still valid and I feel it also could be an indirect path for akasma74's use case. To completely fulfill akasma74 needs, I foresee that the timer's starting duration needs to be retained, such as in the timer properties.

-- Personally, I request that "remaining" be replaced by "completion-time", so an expected timer completion date and time could be calculated (such as in a script or automation)
-- This should resolve the concerns with the state machine values constantly changing, as this value only changes when the timer is started/paused/or stopped.

[akasma74]

My previous suggestion is still valid and I feel it also could be an indirect path for akasma74's use case. To completely fulfill akasma74 needs, I foresee that the timer's starting duration needs to be retained, such as in the timer properties.

-- Personally, I request that "remaining" be replaced by "completion-time", so an expected timer completion date and time could be calculated (such as in a script or automation)

don't you think this will do?

[ejonesnospam]

@akasma74 - Yes, it looks like we have similar usage needs and are headed down to same path. My only (disagreement) comment is that the current 'remaining' attribute is actually useful (to me only I guess), as an updated remaining value can be calculated by paused and starting the timer. As long as the replacement attribute(s) still allows an automation to calculate the remaining time, I won't have any concern with the code direction.

[Adminiuga]

The idea was for remainin attribute to be available only when timer is paused. So if you need to know remaining on a running timer then you would have to adjust your automation to use some calculations

[akasma74]

btw, this migth be related, could you guys take a look?

UPDATE: it's a different issue (related to th way LL calculates remaining time)

[ejonesnospam]

@Adminiuga - Requiring a state change (such as a timer commanded from active to pause), to obtain a static value? It's what I'm force to do currently, but I personally can't endorse that. Could the same not be accomplished using a timer service command, rather than forcing the timer state to change, and thereby not interfering with the timer's countdown continuity?

[Adminiuga]

Please check the thread. Nobody is enforcing you to stop timer to read a static value. Current implementation is broken and has to be changed.

[ejonesnospam]

I've checked this thread, that I created.

Nobody is enforcing you to stop timer to read a static value.

After you stated, "The idea was for remainin attribute to be available only when timer is paused", then to obtain the time remaining before active timer completion, you are proposing that a timer would need to be changed from active to paused. Am I not interpreting you correctly?

[akasma74]

@Adminiuga

if you need to know remaining on a running timer then you would have to adjust your automation to use some calculations

well.. I've just discovered that both remaining and duration are converted to strings when you access them as attributes.
it's fine as soon as duration is less that 24 hours but it will require some different parsing when we have days in there - pita.
I'm still waiting for a confirmation if HA timers are designed to handle durations of 24 hours or more.. but if the answer is Yes then it might not be so simple to do the calculations..

Looks like another vote towards replacing remaining with finishes_at: timestamp to me.

[magiva]

instead of this going on for a long time, why not add the finishes_at attribute whilst you decide whether or not to remove the defective remainder

[lindsaymarkward]

I'd like to add my support to this issue being addressed.
The problem is "disinformation". The remaining attribute appears to be a valid and useful thing, since it's there and implies it stores the remaining... especially since the default UI shows a value...
I spent far too long trying different versions of templates and asking on/searching forums/chat to find that the remaining attribute doesn't do as expected.
It seems the first and simplest fix should just be to remove it to avoid this sort of problem (which forum posts show has been present for a few years).

[ejonesnospam]

I'd would strongly disagree with the short-sighted idea of just removing the 'remaining' attribute. It is still of use, even with it's bugs. Also, to change/fix something twice, after waiting over 6 months since my initial issue create, seems like a bureaucratic waste of effort and attention. Why not just fix it once?

[Adminiuga]

PRs are welcome.
I think the consensus is to have target_timestamp while timer is running and time_remaining for paused timer.

[lindsaymarkward]

Sure. I'm happy for others who know better to decide, and I'm not advocating anything except helping people avoid misinformation.
How about a warning on the documentation for timer as a start? I can add this as a PR, but I suspect others might have clearer information than me to be able to do it better.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[lindsaymarkward]

It seems that this issue should be closed by the PR, not due to being stale.
It's not stale, it's in progress while #37519 progresses, isn't it?

[ejonesnospam]

This issue is still present in the current release. #37519 does NOT rectify the issues documented, instead just removes the 'remaining' attribute. I'm so disappointed that after more than 6 months of providing input on this issue, the attribute will just be removed. I am utterly disgusted at this process.

[Adminiuga]

https://www.youtube.com/watch?v=15HTd4Um1m4

[ejonesnospam]

https://tenor.com/view/eat-shit-gif-8729148

On August 28, 2020 6:57:40 AM PDT, Alexei Chetroi [e-mail] wrote:

https://www.youtube.com/watch?v=15HTd4Um1m4

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/home-assistant/core/issues/30062#issuecomment-682589862

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.