[Release] [App] Circadian Daylight (v0.80) (Port)


#1

I've ported Circadian Daylight over from SmartThings and added some features. It's one of my most-used apps.

LOTS of new options and settings. Here are the big changes:

  • Added brightness-per-mode
  • Added CT-per-mode
  • Added Min/Max brightness
  • Removed zip-code from settings, but fixed its implementation. **This isn't implemented on a system-wide level, yet. Staff is aware. When it's added, I'll add it back ** :slight_smile:
  • Added disable brightness changes when manually pressed
  • Added disable when switch off option
  • Added LogDebug I'm still organizing this and LogDescriptionText
  • Added DescriptionText. I'm still organizing this LogDebug
  • Updated settings language
  • Removed 'sleep modes' since they were confusing. You will need to recreate this with manual overrides if you used them. Campfire was 2700k, Moonlight was 6000k. Brightness was 1%.
  • Began reworking settings
  • Added custom fade-in/fade-out periods, thanks to Jeff Byrom (@talz13)

Copy this link and import directly to your Hubitat Apps page.

Or, see the GitHub file below:

Original Post

To use it, install both the Circadian Daylight app, and the Circadian Daylight Coordinator app. [11-27/2018: Both links have been updated to point to the newest version].

The original SmartThings thread can be found here:
Circadian Daylight: SmartThings + Smart Bulbs - Community Created SmartApps - SmartThings Community

Edit: the original version of the app works well, too. Use this version while the other is being fixed, as it seems to not suffer from a lot of the issues ClaytonJR's version does.

smartapp-circadian-daylight/circadian-daylight.groovy at master · adamkempenich/smartapp-circadian-daylight · GitHub

It should just install and work. If it doesn't, let me know :slight_smile:


Can Hubitat create a circadian-lighting schedule for smart color bulbs so switches can be used like normal?
Auto rising light
Best implementation of controlling multiple lights?
Simulate Sunrise
#2

App is locking up my hub.


#3

Oh no!!

I’m really sorry to hear that. I’ve been running it on two hubs, and haven’t had any issues, so I didn’t expect there to be any devastating issues.

May I ask: what other apps/custom drivers do you have running coincidingly? I’d love to get to the bottom of this for you.


#4

I'll give this a whirl in the next few days. I'm using an older single app ver of this by KristopherKubicki in which I simply replaced all the physicalgraphs. It's been working fine but I think the later versions have a lot more options.


#5

Cool! I was running that version for a while, but there were some features that I’d been missing. I can’t remember if it was the {disable on switch} options, or the custom sunset time options.

Back up your hub, first, and let me know if there are any issues :slight_smile:


#6

I had the same issue with the hub locking up. It seems to be a problem with setting the app to send an alert. When that option is turned on it seems to have problems. I deleted the app and then recreated the app without activating the push notification. It seems to not lock the hub up now.

The logs showed this when I had the push notification turned on:

app:2442018-11-22 07:44:50.709 am errorgroovy.lang.MissingMethodException: No signature of method: app154289046416592447436.input() is applicable for argument types: (java.util.LinkedHashMap, java.lang.String, java.lang.String, app154289046416592447436$_updatePreferences_closure6$_closure19$_closure20) values: [[title:Send notifications to], recipients, contact, app154289046416592447436$_updatePreferences_closure6$_closure19$_closure20@4d206d6e]
Possible solutions: inspect(), wait(), run(), run(), any(), find() on line 137 (updatePreferences)

#7

You're talking about the git update push right ? I didn't enable it this time and it seems to be ok now.


#8

Yep, It seems to work fine when it is left disabled.


#9

That part of the code should be removed then.


#10

I’ll remove it in the next few days. We are in the middle of our move right now :slight_smile: Ill get to it as soon as I can.


#11

I’m getting this error

2018-11-24 08:42:55.698 am errorjava.lang.NullPointerException: Cannot invoke method containsKey() on null object on line 337 (bulbsHandler)

It just sets my CT to 2000. I turned on oauth for both apps. The lights are connected to a hue hub.


#12

Nevermind, I deleted the app and reinstalled and everything seems to be working now.


#13

Amidst my move, I've updated the app and removed the update section. If I make any changes to the app... I'll note them in the first post of this thread.

Let me know if there's anything else wrong with it :cowboy_hat_face:

Edit: You only need to update the Circadian Daylight Coordinator.. The link for this file is also updated in the original post.

Another edit: Thank you all for your help debugging and solving the issue with the GitHub updates!


#14

@adamkempenich - How would you advise handling bulbs with different CT ranges? For instance, I have 2 Hue bulbs and 1 LIFX day/dusk bulb in my bedroom. The Hue bulbs have a range of 2000-6500, and the LIFX Day/Dusk bulb has a range of 1500-4000. When I was using the previous app I was running two separate instances with the different ranges modified in the app code, in order to utilize the full range of each bulb. The new version is a parent/child configuration and it looks like the CT range is defined globally.


#15

That’s something I’ve put some thought into. I’ll either need to rewrite the app, or allow for separate instances.

I will need some time to become more familiar with how this version works, and then modify the code. I might only get to it after the holidays, unfortunately.


#16

So, it doesn't seem to send the CT to Hue bulbs while they're off. Meaning a bulb must wait 15 minutes while ON before it changes (or at least until the clock strikes on the quarter hour). Previous versions would immediately adjust the CT to whatever Circadian as soon as the bulb is turned on. What is the intended behavior here?


#17

Ideally, it would cache the commands for devices that turn on with settings changes (like z-wave dimmers), or send the commands directly for devices that don’t (Hue Lights, etc...)

I haven’t experienced the behavior you described, since I didn’t know there was a branch of CD where t was different (I’ve alwaus used this version, so I’ll install the other branch and experience it).

I’ll test it and see what is better in that version—and then add those features. Then, we will have an even better version of CD than there was on SmartThings, even :slight_smile:


#18

Even bettah :tada:

Here's the one ive been using, well before claytonjn took it over:

https://raw.githubusercontent.com/KristopherKubicki/smartapp-circadian-daylight/master/smartapps/kristopherkubicki/circadian-daylight.src/circadian-daylight.groovy

It doesn't have any offset or dynamic brightness, and you have to set the CT range in the code itself. But it does shift to the correct temperature immediately upon turning the light on if it has deviated. Actually, if the bulb is capable of receiving prestage color, it will turn on with the exact CT. Unfortunately Hue doesn't have that capability, so it changes ~1s after.


#19

Thanks! I’ll dig around in there. That helps a ton.


#20

Does this work directly on HE, or is there some adjustment to be made?