That's why I liked MyTimeOut - it showed the countdown. But it did't work after a Hubitat NR update.
@putch - would you consider adding this in a future revision?
Thanks!
@putch, Another think I liked in MyTimeOut is that the second output was the countdown. Much more useful than this one. I put the countdown in my dashboard. Maybe consider that as the default output in #2 unless a value was entered in the configuration.
Obviously that would have to be a new 3rd output if he were to add that, otherwise it would break existing uses.
But, it wouldn't be hard to do - once there is a timer for updating the time remaining, whether it is status line only or shoved out a 3rd output isn't really a lot of work either way. The work is all in setting up the timer and doing the math.
The trick with timers is how often to update them. Personally I don't think it should be every second, but for it to be useful on a dashboards or with short delay timers it would likely have to be...
I disagree - it would output the countdown only if no parameter is indicated for the 2nd payload.
While technically doable, that is very against node-red programming standards and norms. They always suggest using a separate output for different functions, and not overloading multiple functions on a single output.
Not saying that guidance is always followed, but still....
1 Like
I was considering adding an additional status below the node indicating at what time it would expire. It seems there is a lot of interest in actually showing counting down though. I agree with @JasonJoel - if you have a 7 hour timer, do you necessarily want it to update every second? I mean, that would be the easiest route, but is it the best one?
Is updating every minute better? But then you transition to every second once you get below a certain threshold? If so, where is that threshold?
1 Like
How about every minute until the counter gets below 2 minutes.
2 Likes
I think something like that would work great.
I don't have a strong opinion on when it should shift from minute to second updates. 2 minutes, 1 minute, 5 minutes - whenever is fine with me.
1 Like
If you're taking votes, this suggestion gets mine ....
I've got to say, now that delay (and delay units) are configurable, really the only other thing I could ask for is a countdown display.
Then it would be the ultimate stoptimer.
1 Like
I've got it pretty much good to go I think. Regarding the 3rd output, the countdown, are you thinking it would just be something like:
"2 hours 5 minutes"
"2 hours 4 minutes"
...
"1 hour"
"59 minutes"
...
"1 minute"
"59 seconds"
...
"0 seconds"
??
1 Like
I would think you would do the status text and output the same. A string of "hh:mm:ss", since those are all of the time unit options. But that is just one man's opinion.
E.g.
15 sec: 00:00:15
5 minute: 00:05:00
10 min 3 sec: 00:10:30
7 hours 30 min: 07:30:00
etc
IMO, not really necessary to have a third output for countdown. Just show the countdown in the status line.
I have it all done and ready to go. A 3rd output with the countdown. User selectable rate of output (None, Every Second, Every Minute-with the last minute by the second), added back milliseconds (it was broken by accident when I forked-although I don't personally know that's I'd rely on it for that level of precision).
The only problem is the I can't publish it - I keep getting an error. I've reached out to npmjs staff for help.
[update: published. should be in pallette managers soon enough]
2 Likes
Nice! I'll look forward to testing it out. Thanks for your time on this - I know I will get a lot of use out of, so really appreciate it.
EDIT: @putch Updated and tested. Working perfectly - tested msg.units, msg.delay, and status options.
Love the countdown timer - thank you.
Wanted to check back in with you to say I just tweaked my NR initialization sequence using "do-red".
The grey arrow nodes connected to the "do" node are simply NOOP nodes that do nothing other than make the sequence look a bit better.. Basically on deploy set initNodeRed Global var to true (and an MQTT topic as well for extra maybe useless goodness) then step through the do-red tasklist calling a link node then pausing a random amount of time before going on to the next one.
Of course there are a million other ways to do this maybe even more efficiently but thought this was kind of fun and nifty illustration of a "tasklist" process..
Note: initNodeRed global is used to prevent or allow different things from processing during initialization. Also I know that the link nodes could potentially exceed the init sequence time but that can always be adjusted via the delay node or an extra delay at the end.
Got the new version installed. Works great. One minor fix I'd like to suggest. When the timer is stopped, change the third output to stop. Here's a flow where I use the third output:
And the dashboard:
I'm sorry, i don't see the name of the new timer node anywhere in posts in the past month+ (this thread is officially hard to track any specific topic)
Stoptimer-varidelay
1 Like
