Maybe just adding a “Pause” button next to the “Play” button, or making it a toggle between the two. I guess I shouldn’t keep my iris’ on it ultimately, but there are times I want the color, and times I would like the auto dimming. Is there a way to make them dim, but stay on whatever color they were set to? Seems clunky to have to change a mode to watch tv or whatever you do that you want the colors.
BTW, thanks so much for making this app. Definitely an awesome program. Better than anything I could do, so take my critiques with a grain of salt.
@kenobob I totally agree. So, basically a global option to honor circadian lighting in 2 modes. This could either be based on the users local sunrise/sunset times , or another option to force a lighting temperature schedule in, for example, countries far north in order to simulate “normal” lighting.
I’m based in Sweden where we have long dark winters, and summers when the sun never sets. See where I’m getting with this?
The play button is a platform implementation. I (actually, Kristopher) basically just added a flag in the code to enable it. No one has any control of adding different buttons there except for ST.
That being said:
There are currently two ways that you can “pause” CD - mode, or switch(s). So if you select modes, CD will be “paused” in any modes that you haven’t selected. If you select switch(s), CD will be “paused” if any of the selected switch(s) are in the ON state. You can install multiple instances of CD, so you can have different settings for different lights.
I have a pretty big plan for CD, which should make usability and convenience much improved. I’m working on a custom implementation of Hue (connect), which will include special buttons for enabling/disabling CD per device, right on your device page. I’m trying to get this done as soon as possible, but I still have a fair amount of work to do at home to finish up getting my heat going again (I’m basically re-doing the entire heating system), so I can’t provide an ETA.
Thanks for the good work you’ve done so far. When you get a chance, please look into the issue where bulbs that have been turned off are turned back on because of CD. I haven’t looked at your programming but is it possible to query the bulb status and only set the color if query replies that the light is on? For now I’ve had to disable CD because sometimes it would take me 3 tries before I finally got my lights to turn off. It was a daily occurrence. Not sure what I’m doing that it happens so often to me but not others since I haven’t seen others complain about it.
@dom89, this used to happen to me too, so I know how frustrating it is. In fact, I would have been happy if it only took three tries - when it was happening to me, I would sometimes have to fight with it for 10 minutes, turning on/off 20+ times. One of the major changes Kristopher made a while back seemed to fix it for me, but obviously there’s still more tweaking that needs to be done. The first thing CD does is actually check if the bulb state is on, so if you’re turning on/off bulbs within SmartThings CD should know the proper bulb state and there shouldn’t be an issue. I’m suspecting that there’s some sort of replication delay, and the server CD is looking at for bulb state is delayed from the server that’s getting the bulb state update initially. This could be why it only effects some users. Regardless, I have a change in mind that I hope will fix the issue and make CD more reliable and lightweight, but it’s a fairly major change and I haven’t yet had time to work on it. Hopefully soon!
Everyone: I found some pretty stupid copy/paste errors, and cleaned up some unneeded code. This was all related to my soon-to-be-released CD integrated Hue (connect) service manager, so it shouldn’t have affected functionality for anyone, but I recommend everyone update to the latest version in GitHub and let me know any positive/negative changes you notice.
Just a thought in case this is possible or you have not thought of it: create a configurable setting whether in the code or from the app that allows the user to specify how often CD checks for the bulb status. I could set a longer time frame so that it decreases that the server could possibly not have updated the bulb status. I would be okay with waiting longer for CD to apply the temperature.
Update: as a way to stop CD from turning on the lights right after I turn them off, I created virtual switch and use that switch as a way to disable CD. So I created a rule so that if any of the lights are on, the virtual switch is off and if any of the lights are off, the virtual switch is on. So far I have only had it fail once so I think this is a nice work around.
A different issue I am having now has to do with brightness. If I remember correctly you had previously said that CD does not change brightness unless night time mode is enabled or if constant brightness was overridden. I have a hue white as a dimmer and a hue bloom as a color changing bulb set to 30% but the next time CD updates the bulb status, they are set to 100%. In that same smartapp, I have a light strip plus set up as a color changing bulb that does not have its brightness affect as is expected. Not sure if this is a bug or if brightness is handled differently between each bulb classification. Hope you’re having progress with your heating.
I’m going to have to try to make an active effort to visit this thread periodically, because for some reason it just does not want to notify me of replies. Anyways…
@dom89, can you do me a favor and log into the IDE, select My Locations, scroll down and select List SmartApps, then find the Circadian Daylight install your having issues with, click on it, and post a screenshot? Also, if you don’t mind setting up your lights in SmartThings again, I would higly suggest trying my Hue Advanced (Connect) in the next post.
I created this directly from the stock Hue (Connect), but added many additional features including a lot of functionality specifically for Circadian Daylight. I won’t include all of the features I added, but I do want to elaborate on why Hue Advanced (Connect) will work much better with Circadian Daylight.
Dynamic Brightness and Dynamic Color toggles: These are added right on the device page and allow you to manually turn on and off specific Circadian Daylight features on a per-device basis. In addition, the features are automatically disabled when making a change from the device page, and the Circadian Daylight feature status is updated to display its state. Not only that, but the Circadian Daylight features can be enabled/disabled for each device using custom commands from other SmartApps (i.e. Rule Machine).
Colormode: Colormode is a very important aspect of the Hue API which is not included in the stock Hue (Connect). When checking the status of a Hue bulb, they always report values for hue, saturation, XY, and color temperature. Each respective value only changes if the color was changed with that specific method. So, for example, if you set a bulb’s color temperature to 2700k it will report a ct of 2700. If you then use the color picker to change the bulb to red, the hue and saturation values will change, but ct will still report 2700. The Hue API includes colormode to inform how the bulb was set last. So in the previous example, when the color temperature is first set the colormode would be set to CT, but after setting the color to red the colormode would be HS. Circadian Daylight is already programmed to look at colormode and knows to ignore the reported color temperature if it’s set to anything other than CT.
I want to stress that using Hue Advanced (Connect) is not a requirement of using Circadian Daylignt and Circadian Daylight will continue to work with non-Hue bulbs, but your experiance with Circadian Daylight should be much improved with Hue Advanced (Connect).
@claytonjn I will do that. Is it possible to use your hue advance connect while having the original connected as well? Can I just remove some bulbs from the original and add it to yours? I will give this try in about a week as I’m not going to be around this week.
To be honest, I haven’t tried or looked into using multiple connects. All community connects say that you can only use one, so I always took that as true.
When I get a chance I’ll look into it more. The actual adding and control of devices shouldn’t interfere, the only problem I can think of is a conflict when you first authorize the connect with the bridge by pressing the button on the bridge. I don’t know if each connect is seen by the bridge as a separate app, or if they’re all seen as the same. Hopefully I can get a definitive answer for you before you’re ready to try.
You can’t add a second Connect and the error makes total sense:
`grails.validation.ValidationException: Validation Error(s) occurred during save():
Field error in object ‘physicalgraph.device.Device’ on field ‘deviceNetworkId’: rejected value [xxx]; codes [physicalgraph.device.Device.deviceNetworkId.unique.error.physicalgraph.device.Device.deviceNetworkId,physicalgraph.device.Device.deviceNetworkId.unique.error.deviceNetworkId,physicalgraph.device.Device.deviceNetworkId.unique.error.java.lang.String,physicalgraph.device.Device.deviceNetworkId.unique.error,device.deviceNetworkId.unique.error.physicalgraph.device.Device.deviceNetworkId,device.deviceNetworkId.unique.error.deviceNetworkId,device.deviceNetworkId.unique.error.java.lang.String,device.deviceNetworkId.unique.error,physicalgraph.device.Device.deviceNetworkId.unique.physicalgraph.device.Device.deviceNetworkId,physicalgraph.device.Device.deviceNetworkId.unique.deviceNetworkId,physicalgraph.device.Device.deviceNetworkId.unique.java.lang.String,physicalgraph.device.Device.deviceNetworkId.unique,device.deviceNetworkId.unique.physicalgraph.device.Device.deviceNetworkId,device.deviceNetworkId.unique.deviceNetworkId,device.deviceNetworkId.unique.java.lang.String,device.deviceNetworkId.unique,unique.physicalgraph.device.Device.deviceNetworkId,unique.deviceNetworkId,unique.java.lang.String,unique]; arguments [deviceNetworkId,class physicalgraph.device.Device,xxx]; default message [{0} must be unique]`
New to the SmartThings platform and still learning.
If I hit the “play” button it adjusts the color temperature perfectly but never runs automatically. What do I need to do to make this run automatically?
I’ve tried to update the scheduler for this app by going into My Hub section of IDE and clicking the “update” link for this app but does not help.
Are there some steps I need to take to make this app run automatically?
Go into the IDE and go to locations>list SmartApps, then click on the Circadian Daylight SmartApp. It should show a pending scheduled event, and previously run events. Uploading a screenshot of that is probably the best way to start debugging.
I also ran Live Logging for a bit and I never saw Circadian show up at any point. Not when the subscribed devices status changed or when the scheduled time arrived. Is that normal?
Well…I’m pretty well stumped then. The play button calls the exact same thing as the scheduled job, which shows as successfully running consistently (although the execution time seems fast). In that same SmartApp screen, does it list subscriptions for all of the devices you selected?
Ok thanks. I’ll keep investigating. It’s probably something with my setup since I’ve been experimenting with lots and lots of custom SmartApps since I’ve installed SmartThings.
One question, does this SmartApp run all day/night or just for the “sleep mode” that’s been selected in the settings?
If you have selected any modes under “Set for specific mode(s)” then it will only run under those modes, otherwise it will run all day. The sleep mode just exhibits different behavior then non sleep mode(s).
