Hmm... Now it's not utilizing the transition
time value for color temperature or level. Same behavior in the Color driver.
I'm able to manually change the values within the driver code and get it to work, but setting them via the preferences doesn't stick.
Do you see the transitionTime variable in the state? Note, not colorTransitionTime
If you don't try changing the value in preferences then saving again.
Both are there. The transitionTime variable changes with setting the preferences, and the colortransitionTime doesn't change. Unfortunately the reported state is not reflected in the bulb, which appears to stay at the default 0.0 time.
It doesn't use the default transition time for SetLevel in any driver because it's using the one from the SetLevel command. But it's definitely using it for SetColorTemperature on the LIFX Color driver for me, but not, as you say, for the Day and Dusk driver.
This is very puzzling
Wait, I see what's happening. transitionTime is actually referring to the on/off time, not the duration it takes to change from level-to-level or color-to-color.
Nope, that's not it - there's a stray reference to colorTransitionTime in the Day to Dusk driver after the commented out block - if you change that to state.transitionTime. I probably missed it because of that commented code.
Let me know if that fixes it for you and I'll update the code in github tomorrow
Yep, that's it. Had to check the capitalization too. Let me buy you a beer, Rob...
I am watching this thread with interest and am massively impressed with how fast @rob has refined this set of apps / drivers.
Currently I'm using the latest version in conjunction with some scene setting wall switches for bedside lights - where this works really well. For the rest of the house I'm still using the HTTP driver so that groups turn on and off in sync.
@rob Is that something that may be solve-able on the roadmap at some point?
edit: I checked out how these guys do it: (GitHub - mclarkk/lifxlan: Python library for accessing LIFX devices locally using the official LIFX LAN protocol.) - it seems they use multithreaded commands for groups.. is that even possible on Hubitat?
As far as I know we don't have any explicit multithreading capability in Hubitat, but it may be possible to build the protocol message packets just once and then fire them one at a time from a group device to the various devices in the group. It should at least be fairly quick, if not as good as multihreaded.
I probably won't start on that until I've got the Multizone and Tile support working though.
But that Python library has given me some ideas, thanks.
Just feeding back an issue I encountered last night and offering advise to stop anyone else getting the same issue.
So last night I had to reboot home Wi-fi (mesh network on Linksys Velop) as Wi-fi was playing up. Didnāt think anything off it - usually no issues with a reboot and everything works well after.
I didnāt notice any issues until I went into 2 bedrooms with Lifx bulbs (I have 9 in total around the house).
When going into the rooms the lights didnāt come on which was strange.
I went into the Lifx app and tried switching lights on and off. No problems there. I then went into HE devices and tried switching the lights on. No response from the bulbs. Having a hunch, I went and did a device discovery of new devices. The 2 bulbs were discovered as new. The ānewā bulbs responded to on button but the old one still didnāt.
Bit of head scratching, I then looked at the device ID and was able to see the IP address was different between new and old. I went into the Lifx app to try finding the IP addresses of the bulbs but just couldnāt see the info anywhere.
I then tried changing device ID to the working IP on the bulbs not working (purely to save having to edit all the rules to point to the right new bulb). Saving the settings didnāt keep the new IP.
In the end, I went into every rule and changed the rules to point to the new bulbs and deleted the old bulbs. Everything working again.
Moral of the story - set your IPs for the Lifx bulbs to static. Lol and to help identify which bulb is which on your router, change your device device name at the same time which might help with future diagnosing of issues.
Fortunately for me I assumed IP reservations were needed as soon as I noticed the IP addresses were in the DNI. My Lifx bulbs were probably the only wifi smart devices I had that didn't already have them. Any integration that talks to devices locally (without a separate hub in between) I now assume needs reservations.
@kilowatts, you may want to edit your OP with this as a recommendation. Same for you github documentation @rob.
I started giving my bulbs static IPs a couple years ago, back when even the official app couldn't keep track of them. Since then I've given nearly everything connected to my router a static IP, for good measure.
I updated this app and now I am unable to set colors through my rules. Color temp works, changing brightness works, it just no longer sets the colors (blue, red, green, etc).
Did you update all the device drivers as well?
Yeah. I'm still paying around with it but I think it's actually a bug in rule machine. I got it to set color by adding a brightness value. With no brightness value, the rule now does nothing. This was changed in the most recent hubitat firmware.
Ah. I don't use colors for my LIFX bulbs in HE, just white temperatures, but I'll see if I can duplicate it. Which bulbs do you have? And is it a simple change from one color to another with no change in brightness?
I'll test the same thing with a lightify bulb later tonight and see if it has the same issue.
@rob, looks like it could be a bug in LIFXMasterApp.groovy
Currently, on lines 809-816 in the Hubitat editor (in Github viewer it's 807-814) there's the following piece of code:
private static Map<String, Number> getScaledColorMap(Map colorMap) {
[
hue : scaleUp100(colorMap.hue) as Integer,
saturation: scaleUp100(colorMap.saturation) as Integer,
brightness: scaleUp100(colorMap.level ?: colorMap.brightness) as Integer,
kelvin : colorMap.kelvin
]
}
This code errors out when there's no brightness value set in the rules engine when just changing color, like this:
Log error:
[dev:139](http://192.168.3.150/logs#dev139)2019-03-04 08:57:03.607 am [error](http://192.168.3.150/device/edit/139)java.lang.NullPointerException: Cannot get property 'commands' on null object on line 98 (setColor)
[app:44](http://192.168.3.150/logs#app44)2019-03-04 08:57:03.574 am [error](http://192.168.3.150/installedapp/configure/44)java.lang.NullPointerException: Cannot invoke method multiply() on null object on line 849 (deviceSetColor)
If you replace that piece of code with the following code, everything works, with and without brightness levels.
private static Map<String, Number> getScaledColorMap(Map colorMap) {
if (colorMap.level != null) {
[
hue : scaleUp100(colorMap.hue) as Integer,
saturation: scaleUp100(colorMap.saturation) as Integer,
brightness: scaleUp100(colorMap.level ?: colorMap.brightness) as Integer,
kelvin : colorMap.kelvin
]
} else {
[
hue : scaleUp100(colorMap.hue) as Integer,
saturation: scaleUp100(colorMap.saturation) as Integer,
kelvin : colorMap.kelvin
]
}
}
Admittedly, my modified code is probably sloppy, so use at your own risk. 
Lost control of all my lights today. I tried going into the Master App and discovering new devices, but nothing happened when I clicked those buttons. I attempted to remove the Discovery device and try again, but that didn't work. So I ended up having to uninstall and reinstall the master app, which I believe means I need to remove all the bulbs and start from scratch. Sorry I don't have any logs to help with diagnosis other than a whole buncha java.lang.IllegalArgumentException: null on line 122 (poll), long after the fact.. Not sure what happened... I do have all my lights set with static IPs.
There's already a note about that at the end of the README.md which is visible on github.
I'll probably add it to the Discovery page somewhere though.
Download the Hubitat app
