I’ve been looking for quite some time to implement a “Days Countdown” sensor for my daughter that has a medical device requiring a change every 6 days. I know I could create a google calendar entry each time but sometimes the device can fail and a new one is needed before the 6 days are up.
I’ve searched through and gone through quite a few posts where people have used python scripts to create these where they all count down to a date.
What I would like to do is create a script that counts down 6 days and then stays at 0 until I hit a reset button whereby it goes back to 6 days and repeats from there.
It may be worthwhile to note that on the last day i would like it to show hours and minutes.
I would really appreciate every ones help with this.
The only thing I can think of is to use a timer and an input boolean. I’m not sure if the timer can extend out to 6 days, but if it does it might just do the trick.
Then add an automation so that when you turn the input boolean on, it triggers the timer to start its countdown, and then another automation so that when the timer finishes, it triggers the input boolean to turn off.
You could even extend the finishing automation with some notifications, and if you are an iOS user (not sure about other platforms), you can have the automation push an actionable notification with a button to turn on the input boolean to restart the timer.
In theroy this should work. I use a similar thing for my Zigbee2mqtt network to enable device joining.
I would use an input_number to record {{ as_timestamp(now()) }} whenever you want to “start” the count down. (Use an automation that is triggered by something in the frontend, that then records this value.) Then I’d have a template sensor that displayed {{ [6*24*60*60 - (as_timestamp(now()) - states('input_number.count_down')|float), 0]|max }}, formatted as either days, or hours & minutes, depending if it’s current value is more or less than a day. Let me know if you think this might work, and if you need help implementing it. The nice thing is it takes only an automation to start it, then the rest is done in a template sensor – no need for other automations or scripts.
BTW, I think this might work better than using a timer, since I’m not really sure what happens with timers when HA is not running (i.e., if it goes down temporarily, or across restarts.) This technique just records the start time in an input_number (which is restored across restarts), and stays valid effectively forever.
FWIW, one might be tempted to use an input_datetime. But I’ve found it has a fatal flaw (which, I suppose, I’ve never done anything about.) Anyway, if you want to save both a date and a time, those are separate parameters. And given the way templating works, they will be calculated separately. So, if you’re using now() in both, then they will actually grab two different times, which, if they just happen to occur right before and after midnight…
Anyway, using as_timestamp to turn a datetime into a Unix Epoch time stamp, and saving it into an input_number, is not only easier, it also avoids that (admittedly remote) potential race condition.