Sorry, i'm trying to copy your rule from the Jan 11 post. I see that %start_time% is set to current time, which was 12:40 at the time of your screenshot. Are you talking about setting the local variable on this page? What do i enter so it's just a null for the current time in the rule?
what you have will work fine. each time the rule runs it updates the start_time variable, so that will changes throughout the day.
the primary purpose of that variable is so that if the rule is activated at a time other than the trigger times it will calculate the time remaining and count down correctly. the primary time this would happen would be if the hub freezes and has to be rebooted. if the hub reboots cleanly, then it will actually continue the rule where it left off, so I have another rule that cleans things up a bit just in case the hub crashes:
that just makes sure that the rule is running, but that there arenāt multiple instances. its a redundancy i created after being frustrated a few times.
tl:dr:
the screenshot you posted will work fine. it will update the start_time variable each time the rule is triggered. you could put any value in there initially.
Oh ok, when i manually triggered, the current time updated in the rule. I'm going to implement your reboot now. Thanks!
@jrau272, love the way you set up your apps to manage CT. Thanks for the inspiration. I have largely replicated your logic--tip of the cap. Two things I did differently fwiw.....
- I took the middle-of-the-night logic that resets CT down to 2700K out of your rule #2 and put it in rule #1 since that runs once every night. Just simplifies the main app a little.
- The bigger change I made is, rather than changing CT over time, I change a virtual dimmer over time (from 0 to 100 in the morning, then fade back down 100 to 0 in the afternoon). This way, your rule #2 doesn't have to care about multiple kelvin variants of the different bulbs, if you have them. I then used @adamkempenich's great Percent to CT App to convert the 0-100 dimmer to CT in kelvin for each bulb. To my thinking, it kept the layers of logic separate. And I believe (??? let's see if works) this way I won't have to embed CT management into any of my lighting automation. The main disadvantage of this approach, which I didn't realize until I did it, is that dimmer-fade can only be done in intervals of 60 seconds max, whereas the CT-fade can be done over a longer interval. Not sure I care since once per minute still isn't a significant load on the hub.
Eh, at the end of the day, to each his own. Just thought I'd share back my approach because I benefited so much by your logic. Props man. My two rules are below if helpful.
EDIT: Night one and I learned an important lesson--if you want to "pre-stage" the color temp of a bulb (i.e., set the bulbs color temp without turning it on), you have to go into the device details screen and set your bulb default to allow prestaging of color. If you don't, then your bulb will automatically power on as soon as you set the color temp.
1 Like
Awesome, this is way better than my colorTemp hackjob. Looking forward to getting a finer gradient out of these lights. 
Nice! Iām glad others are getting some use out of this.
Soooooooooooo you're saying I shouldn't click "Run Actions" a bunch of times.
Haha - as long as you click update rule first you should be ok. Otherwise it will just accelerate and youāll have counted all the way down way ahead of time.
