You have a couple different options. If you’re using Hue Advanced (Connect) then there are buttons for each device to enable/disable circadian color and brightness. Also, changing the brightness or color in the device will automatically disable circadian adjustments until re-enabled. If you aren’t using Hue bulbs or don’t want to switch to Hue Advanced then you could either create a virtual switch or use a mode to disable Circadian Daylight for one or more lights. For example, if your wife sets lights in one particular room and you want Circadian Daylight to be disabled temporarily on only those lights, you would remove those lights from your regular Circadian Daylight child instance and add them to a second child instance and select a virtual switch to disable Circadian Daylight. You could even use something like CoRE or your own SmartApp to automatically set the desired brightness on those lights, so that turning on the virtual switch sets the brightness and disables Circadian Daylight all in one shot.
Thanks for the tips @claytonjn. I tried installing the Hue Advanced, but it wouldn’t install, some kind of unknown error. I keep meaning to check out the logs, while I’m installing it, but haven’t got round to doing that yet. Will try again tonight.
If you’re still getting an error feel free to post in the Hue Advanced thread and I can help troubleshoot.
Got it installed. However, when I change the brightness either with a hue dimmer, or in the ST app, it doesn’t disable the circadian routine. Still shows as on in the ST app
RE: Hue Dimmer - this is by design. I thought a long time about this behavior, and I decided that I only wanted Circadian color/brightness to be disabled if the color/brightness is overridden inside the device itself so that the user can see that it was disabled. I didn’t want a SmartApp or other external app changing Circadian Daylight behavior with no feedback to the user. If enough people want this behavior changed I may reconsider, but I think there are better solutions.
RE: ST app - when you say that the ST app isn’t disabling Circadian color/brightness, what do you mean exactly? Are you going into the light itself and changing the brightness level or color? If not, the response is the same as the Hue dimmer. If you are going into the device itself and changing color/brightness and it’s not setting Circadian color/brightness off then I need to investigate further.
I recently tried setting a specific time for both Sunrise and Sunset but it doesn’t seem to work.
For example, to test I set my Sunset times to 10pm when it was around 5pm (after sunset) and the bulbs didn’t change color temp but stayed 2700k (my set min temp). Am I misunderstanding how this setting works? Shouldn’t the color temp change to cooler white since Sunset is now set to 10pm?
Thanks for your time.
I just tested in my setup and it worked perfectly. Can you provide a screenshot of the settings in the IDE under My Locations>smartapps>Circadian Daylight Coordinator
Also, does the colorTemperature state variable change when you adjust the sunrise/sunset times?
HI Clayton,
I’m getting grief from the Wife now. lol
She’ll dim the lights to feed, using Alexa, or her phone, or the hue dimmer, and then the Circadian Rhythm will switch them back on again at whatever it wants them to be.
I’ve even added a virtual switch in ST that switches off the circadian state, and added it to IFTTT routines, and HomeKit Scenes, but sometimes still she just changes the light percentage 
Could the code change be as simple as:
- Get current actual light state
- Compare current actual light state to current circadian light state
- If they match, then set new circadian light state
- If they don’t match, then switch off circadian rhythm.
Or is that a pipe-dream?
Log entry from IDE:
Sunrise time set, no color temperature change:
02a4073f-a4f5-4e91-9f85-74d8721f2972 4:37:46 PM: debug initialize() with settings: [ctMax:6000, lSunriseTime:2017-01-09T06:01:10.000-0800, lSunriseOffset:0, updatePush:false, ctMin:2700, updateNotifications:false, lZip:95112, lSunsetOffset:0]
Sunset time set, color temperature change:
02a4073f-a4f5-4e91-9f85-74d8721f2972 4:36:56 PM: debug Color Temperature set to 5319 02a4073f-a4f5-4e91-9f85-74d8721f2972 4:36:56 PM: debug initialize() with settings: [ctMax:6000, lSunriseOffset:0, lSunsetTime:2017-01-09T17:31:49.000-0800, updatePush:false, ctMin:2700, updateNotifications:false, lZip:95112, lSunsetOffset:0]
Both Sunset and Sunrise set, no color temperature change:
02a4073f-a4f5-4e91-9f85-74d8721f2972 4:37:22 PM: debug initialize() with settings: [ctMax:6000, lSunriseTime:2017-01-09T06:01:10.000-0800, lSunriseOffset:0, lSunsetTime:2017-01-09T17:31:49.000-0800, updatePush:false, ctMin:2700, updateNotifications:false, lZip:95112, lSunsetOffset:0]
No color temperature change when I have sunrise time set no matter what I tried.
When I hit the action button for the CR SmartApp, after I set the sunrise time, the bulbs go to 2700k, my lowest setting, regardless of the actual time.
Hi @claytonjn thanks for this, playing round with it at the moment and read all of the above. I have 2 questions if you may:
- “Sleep Mode”. Is this a mode i have to create in ST or something/somewhere else?
2). Re Sunrise/Sunset Offset. Id like to use this as I’m finding it starts too early in the morning and too late in the evening. I saw above you mention the code looks for HH:MM, have you tested this? Also is there anyway to add ± to the offset?
Cheers
@NOITAIDAR, unfortunately that wouldn’t work. Circadian Daylight can only adjust bulbs that are turned on. Unfortunately there is no consistency in device handlers in regards to lights - some devices can be adjusted while turned off, while others turn on when adjusting the color temperature and/or brightness. Because Circadian Daylight can only adjust bulbs that are already on, it is pretty much guaranteed that the actual light state when they are turned on will not correlate with the current Circadian Daylight states. If I turn off a light at noon it might be at 6500k, so when it is turned on again after sunset it will come on at 6500k but should be immediately set to 2700k.
Your best bet really is to control the lights only through SmartThings. Keep the Hue app as a backup for if/when SmartThings is having issues, but control lights through SmartThings whenever possible. You should be able to come up with solutions that are just as easy for her but will result in direct SmartThings control. If she wants to use Alexa, you could just create a virtual switch, accessible in Alexa, then when turned on would disable CD for relevant lights and set them to the desired level. If she wants to use her phone, she could simply use the SmarThings app rather than the Hue app. She could just turn on the same virtual switch (if she has an Android phone you can use Sharp Tools to create a home screen shortcut to activate it), or you could create a mode she could activate (modes can be activated through a widget on Android), or she could just go into the light directly through SmartThings and adjust it, which will disable CD automatically if you are using Hue Advanced (Connect). The only real solution in regards to using the Hue Dimmer, honestly, is don’t. Like I said, the only real solution is to have full control through SmartThings. Using the Hue Dimmer to control lights outside of SmarThings is going to basically make it impossible to ever use anything like Circadian Daylight. The only real solution is to use a dimmer paired with SmartThings, and program SmartThings to dim your Hue lights. There will be slightly more latency though, and it obviously won’t work with SmartThings hiccups.
Honestly, in my house, I have any automatic lights (motion activated, timed, etc) set with Circadian color temperature and dimming. I have any lights with physical controls (dimmer switches in the wall) only set with Circadian color temperature adjustments. For lights on physical switches, there is no “natural” way to override automatic dimming, short or installing a physical button adjacent to the dimmer to toggle automatic dimming.
I tried every one of those situations and everything is working for me. Are you still on the development branch?
When you pulled those logs, at 4:30pm ish, was that before or after sunset where there? Also, were there more lines with Color Temperature set to … that you didn’t include, or was the one line that you included the only one produced?
This is a SmartThings mode that you would enable when you want Sleep Mode activated. By default, SmartThings has 3 modes: Home, Away, Night
Yes, HH:MM should work. You can use -HH:MM for negative. No + is required for positive.
Thanks @claytonjn. Just to be clear do i need to create a mode called “Sleep” or just use the Night one? Also for the offset there is no way to input a + or - as its just a numerical key pad with no toggle for ± either. In a HH:MM format as there is no : i guess it would just be 0030 for half an hour?
Hmm, are you using iOS or Android? I get a full keyboard for HH:MM input, and I’m generating the inputs with code copied from official ST SmartApps, so it’s probably something ST should be aware of.
On the main branch.
About 30 mins before sunset when I tested.
Those log entries are the only ones that was present during my testing in the Live Logging.
iOS. Strange indeed? For times unto an hour it might not matter as when i enter 0015 it saves it as 15 so it may work, just no ±. Also re sleep mode do i need to set anything in the smart app for this to take effect? I have the 1% on for sleep mode and tested now in Night and also created one called Sleep but no joy? Edit: I do have min %age as 20% would this stop it working? Edit Edit: I just saw the mode config for sleep lights, doh!
That is very strange, every time you see an initialize log entry you should see a color temperature set log entry. It seems like it’s not fully executing the code. Can you try replacing lines 212-214 with the following, then capture those same logs again (including the new warnings you should see)
def sunriseTime = sunriseAndSunset.sunrise.getTime()
log.warn "sunriseTime: ${sunriseTime}"
def sunsetTime = sunriseAndSunset.sunset.getTime()
log.warn "sunsetTime: ${sunsetTime}"
def dayLength = sunsetTime - sunriseTime
log.warn "dayLength: ${dayLength}"Hmm, do you have a third party keyboard?
Regarding Sleep Modes, when SmartThings is in whichever modes are selected as Sleep Modes Circadian Daylight will be in sleep mode. The name of the mode(s) is irrelevant. (I use the default night mode)
EDIT: @AdamC doh! You should be on the development branch to use the offset. That’s why it’s not letting you enter properly, I haven’t gotten any one to confirm it’s working so I haven’t pushed that code to the stable branch yet (the offset in the stable branch is NOT working). I tested it myself but I don’t like pushing changes to stable until they’ve been tested by at least one other person. You can either switch to the development branch or you can wait until the offset fix gets pushed to stable. Sorry!
Thanks for the detailed response, Clayton.
I think I have a way around it that works for our setup…
I’ve set up a CoRE rule that if the light goes below 40%, switch off the mode that enables the coordinator, Since my setup only manages the dynamic brightness between 40 and 100%, it’s assumed that anything below 40% is a manual change.
It looks like the Hue Advanced does runEvery5Minutes(doDeviceSync), which is what will get the change back from the physical lights in to SmartThings. What I’m wondering though is if the Circadian Coordinator does a doDeviceSync or initialise, to get the current state of lights before it tries to push out any changes. ( it must do, right? because it knows when a light is switched off?)
Cheers,
Adam