I have the color tunable white under cabinet lights. I may be able to test some of this stuff over the coming weekend.
Yes they are but sometimes they drop off I just use them because they are a better option then the hue light switches in my op
I have two Lightify A19 CT bulbs that I'll try out in the next few days. One of them drops on a weekly basis. If this fixes this problem I'll totally owe year a beverage of your choice.
I'm not sure Hubitat's docs say anything aside from that the type, as with SmartThings, must be "NUMBER", which itself isn't super-clear. SmartThings' capability docs do say about "NUMBER" that "Device Handlers contain the implementation of what kind of number object is actually returned," so if Hubitat matches that behavior (I suppose that's the best we can do without hearing from staff or unless I'm missing something in the docs?), I guess a "decimal" (double?) would actually be OK.
That being said, I have yet to see a Hubitat stock driver that returns anything other than an integer here. Some examples where I've seen this come into play:
- with Lutron where levels down to 0.01 are allowed (dim as possible but not off), Hubitat doesn't report it as such (it ideally should report it as 1%, but I think a bug might have kept reporting it as 0% for some time and possible still to this day; the only solution I've seen staff propose was 1%, not 0.01%).
- Hue allows levels from 1 to 65535, and Hubitat still rounds these (for reporting; you can set it to any number with or without a decimal point between 0-100 without problem) to 1-100%. This is also what I chose to do in my custom Hue integration, but I was careful to make sure the conversion functions were consistent with each other when converting to or from Bridge values so, for example, a
setLevelfor some Hubitat-scaled value when get interpreted as the same when the Hue-scaled value was parsed later. - for Zigbee RGBW bulbs, which accept levels through 255, Hubitat still rounds it to an integer for both setting and getting the value (see their driver here: HubitatPublic/examples/drivers/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub)
All of this seems too much like coincidence for me to differ from in my own work, but I don't see anything technically wrong with it. 
(And you certainly gain some resolution in this regard by including it.)
1 Like
Okay, cool! I’d be interested to see what the device type ID is. I can walk you through that if you have time No pressure, though!
Interesting. I’ll see if I can do anything with them, but I get the feeling there’s not a ton I can do. Pairing them directly to the Lightify hub would let you control anything paired to that, though, and you could use that as a trigger. Not sure if it would solve the drop off issue.
Awesome! If you wouldn’t mind tossing an ID over for those—I can add the tunable white driver there’s a line I can guide you to uncomment in the parse section of the app. It would be cool if the gateway integration would fix your issue!
The one I'm testing is RGB tunable white and the colour temperature works. I'm also about to buy some tunable white only ones, but was intends to avoid osram but it might be possible again with this 
.
O yeah and poll throws a error in the logs.
1 Like
I should probably add poll as a method 
If you mean the Zigbee ID, here : 841826000005006B. If it's some other number just tell me where to find it.
Thanks for all of your work on this. I just donated some money :-).
If you uncomment line 293 and give me the results from a CT bulb, it should have all I need
Oh my gosh. Thank you! That’s incredibly generous of you.
1 Like
Ok. I'll take a look. 
1 Like
I am so pumped to try this out over the weekend. Thanks Adam!
I'm excited to get your thoughts on it!
I've just pushed out an update for everyone else---it fixes the string bug, and will only create new devices when you go into the app and hit save.
Also --- the new update supports importurl, so you'll just be able to hit import on the drivers and apps. (I haven't updated the bulbs, yet)
3 Likes
My Halo style BR30 RGBW bulbs are not behaving. They keep going unreachable from app. Control from Hubitat is equally spotty. It takes multiple tries to turn on/off lights they turn on then go back off and vice versa.
I then also get these crazy phantom devices that control nothing.
I'm going to leave it until tomorrow and see if my hub mesh and the Lightify controller start playing nice.
1 Like
From the Lightify app?
Have you downloaded the latest version of the app? I’ve semi-fixed this bug by only adding devices from when you hit save in the app.
When you call whole numbers it set them correct but if you wait or refresh the page then the number will change back to a long string oddly?
Noticed something that will be needed in the device aswell, in order to work with the hubitat apps you will need in the current state.
- colorMode : RGB
- colorName : Incandescent
I know the colorMode IS need not sure if the colorName is a must though 
. I believe there is a example driver in the hubitat GitHub that might help with this 
Another thing to note (not sure if this is the same over the pond?), Is that over here our lamps can't do pre staging so to set the Kelvin or colour from a OFF doesn't work. But hubitats apps expect that all lamps do work. So the driver then needs to handle that and always send a ON if OFF then short delay (200 ms) before sending the colour.
Yeah, from the app. Maybe my problematic lights are just broke. Though they did work for weeks sometimes months without a glitch on HE. They're being super fussy right now.
The Lightify gateway has a shorter range than HE from what I’m seeing, so if you’re using the lights without repeaters, try to keep the Lightify gateway close to them.
Also, You may be on the same channel as HE. I don’t see a way to tell what channel the gateway is using.
