I made a quick fork of this app to better fit my needs:
I prefer to have a predictable wake up / settle down schedule, to better keep my circadian rhythm throughout the year. Don't know if that's how it's supposed to go, but I'd rather have a static brightening phase and dimming phase.
Thus, I added brightenStart, brightenEnd, dimStart, dimEnd to the settings, and am attempting to use those to give me that constant effect. i.e. start brightening the lights at 6:00am until reaching full brightness / CT at 8:00am, then keep full brightness / CT until 8:00pm, when it will start dimming until 10:00pm.
This is the first afternoon I'm using it, and so far (since the current time is between brightenEnd and dimStart) the lights are set to my coldCT override, and max brightness. I'll have to see how it behaves once dimStart time rolls around, but hopefully it'll do what I'm looking for.
Nice!! I'm going to push out this next version of the primary fork (tomorrow is still my goal).
I'd love to add those to the next version. Do you have a start/end CT setting, too? I was writing a separate app (Simple Sunrise) for this, but it could be a good integration here, too
Sure, no problem. I was actually thinking about adding two sets of times, one for brightness and one for CT, but just went with the simple route so far of having one morning time range and one evening time range.
The only thing I'm mildly concerned about with my version of code is, what else is the sunrise / sunset time being used for? I think I see something in the scheduleTurnOn() function that is using sunriseTime.time for scheduling? As far as I'd like, I'd just get rid of sunrise/sunset and have it completely dictated by my brighten / dim time ranges.
One tiny code fix from your original version I found was in the getSunsetTime() function, you'd had def sunriseTime in there from copy/pasting the getSunriseTime() function, but then used the proper variable sunsetTime later in the function. A simple oversight!
I'm getting an error when I put my zip code in for the Zip override. Here is what the error shows:
[app:1292](http://192.168.86.5/logs#app1292)2019-05-10 06:18:26.949 pm [error](http://192.168.86.5/installedapp/configure/1292)java.lang.NullPointerException: Cannot get property 'zipCodeOverride' on null object on line 124 (updated)
In 0.72, zip code has an incorrect data type. I’ve fixed it, but I then realized that ZipCode Override doesn’t exist on a system level, so I’ve temporarily removed it from 0.73.
Staff is aware it’s missing, and I’m sure we’ll quietly see it appear in a future software update. When that happens, I’ll add the feature back in
Been busy here outdoors today, since tomorrow is supposed to rain. I’ll get to releasing the next version tomorrow
I’d been using F.lux (until Apple replaced it with their built-in CT thingy) since 2011 or 2012... back then there wasn’t any Hue support, but I think they’ve since added it into their product, too.
Every time I see another product or piece of software pop up that does this, I feel so happy. It’s such a small change, but it can make a big difference.
What I really want is a way to do a pure chromatic red/black display, though
0.80 is released Release notes are in the first post.
As always, let me know about any bugs you find. A few features didn't make the cut (see the header in the app code), but there's a lot of added functionality.
In my fork, I just added support for configurable refresh interval, as I wasn't sure how the iter / iterRate piece worked. Also on the scheduling portion, I made the seconds portion of the cron string a random number up to 60 so if multiple instances of Circadian Daylight are installed, they can run at some number of seconds offset from each other, to reduce the load on the hub. Not that it's impossible for them to be scheduled to run simultaneously, just reduces the chance of that.
And also added a check to see if there are any color temp changing bulbs in the settings, before running my getGraduatedCT() function call, as that would be pointless to run if there aren't any bulbs that would benefit from it.
I’ll take a look I love the features you’ve added. Not sure how necessary randomization I’d CRON is, but I agree, doesn’t seem like it could hurt to do that!
Maybe someone can test this - I'm still having the problem with sunset overrides. The bulbs change to coldCT after the sunset override time has passed. For instance, if the current time is 10pm, and the sunset override is set to 9pm, the bulb will turn on at coldCT. Using LIFX Day+Dusk, although I had previously confirmed this with Hues also.
