Hi there! Thank you for this very useful App!
I was wondering if it is possible to create a custom fade for an Scene for a Group of lights (that I already configured in Hue app and discovered via CoCoHue)?
I have managed to run the push on/off buttons for an scene, but transitioning or fading from current state to said scene over $X amount of time seems a bit tricky. Any tips on this?
If you know how to do it via the Hue API, I could add something like that. 
I'm not sure if the transitiontime attribute works when recalling a scene on a group, though I could test that. You'd have to configure that on Hubitat, but if it works, that would at least be something. The API docs say you can set transitiontime when creating a scene (which I assume would automatically apply when recalling it), but the only example I see is for LightScenes and not GroupScenes, and I don't think the native Hue app does this (it doesn't support LightScenes anymore).
Otherwise some things that look like scenes are really schedules and rules in the Hue API (often coupled with scenes) that I'm not using at the moment, nor am I aware of similar Hue integrations that utilize these in any way, either.
I think you're right. I just took a look at the API and transitiontime it's only used to create an scene, but it's not a param to use in recall .
I guess the only option for this use case would be to store such scene into a temp one in CoCoHue with the new transitiontime in order to call it... Seems suboptimal IMO :-\
Update: version 1.9 released! These changes include updates to the Bridge child app, the RGBW bulb driver, the group driver, as well as totally new drivers you'll find in the repo for CT and Dimmable (white) bulbs...so update pretty much everything besides the parent app and Bridge driver (and grab the new ones, technically optional if you have no such devices) if you want to.
New features:
Changes:
off() command on a scene is no longer non-functional. This should only affect you if you depended on this for other purposes. Specifically, it will:
off() will not do anything as before; as mentioned above, this isn't really something Hue supports on scenes, so the above are just best guesses as to what you'd want if you turned off a scene. I recommend turning off lights or groups directly to be certain.Wow--that is a lot of updates. I just implemented all of them. One question comes to mind, if I have a group that is made up of CT or dimmable bulbs, will the group only have the controls that match the capabilities of the bulb, or will it have the full rgb controls?
No, the group will have all the RGBW controls. If you don't want this and aren't intimidated by minor code edits, I think commenting out the capability "Color Control" (eliminates setHue, setSaturation, and setColor--so this would be for CT-only groups) or capability "Color Temperature" (eliminates setColorTemperature, so do alone for RGB-only bulbs like the first-gen/non-Plus Lightstrip or in combination with the previous edit for dimmable-only bulbs, in which case removing attribute "colorName" might also be good, and capability "LightEffects" and attribute "effect"` can be removed for anything that doesn't support color) would do about everything you want. That's a lot of typing but not quite as hard as I made it sound.
I've considered offering additional group drivers along these lines myself, but I don't see the Hue API providing much information about group "type," so the only way I can think of to do this (in a way that makes it useful with an automatically selected driver) would be to guess based on the bulbs it contains (and hope the user knows to change it afterwards if room/group members change). I could also just not do it and let the user decide after the fact. For comparison, Hubitat's stock integration I started out modeling does the same thing I do: RGBW controls for all groups.
If you do have rooms/groups that are not color or CT capable, I'll eventually update the driver to do this automatically, but using the "full" group driver I'd just go to the device page and do a random "set color" and "set color temperature" so all the device attributes get populated with something.
When trying to link my bridge, I am putting in the IP address for the bridge, it tells me it is linked, but then I get the following message...
Bridge Not Linked
There was a problem authorizing or linking your Hue Bridge. Please start over and try again.
I've tried completely uninstalling the app and trying again, rebooted both the Hubitat and the Hue bridge multiple times, and I've even tried changing the IP address of the Hue hub.
HELP!?!?!
You pushed the button on the Hue bridge?
I did press the button on the Hue Bridge. As soon as I posted that I knew that detail missing would be the first question asked. 
Somehow the bridge device got installed, but something much have not gone right. I removed the bridge device and tried again and it worked! All good now!
@bertabcd1234, great work on this app!
As my Hue collection grows I keep coming back and taking a look at this. I see Labs was mentioned awhile ago and I would like to add another vote for this feature! Being able to turn the Lab on/off would be a game changer!
If someone figures out how they work, I'll consider it. Ones I've looked at look like a conglomeration of various parts of the API like Rules, Schedules, and Scenes, and it's mostly things that they're experimenting with implementing as "real" features (or not) down the line--I remember an early Lab testing multi-taps for scene cycling, something that made its way to the later Hue Dimmer product, for example. Not very friendly for accessing via third-party apps, but probably possible for individual Labs features if anyone figures out how to access them easily.
Well, after lots of Googling it seems Labs that have a 'virtual switch' can be accessed via Resourcelinks and then Sensors. This blog has gotten my attention!
Been poking at this all morning. 
I got the Labs to show up, selectable and device is created. The problem I'm still having is that the device doesn't control the Lab. 
I've tried using the CoCoHue RGBW Bulb and the CoCoHue On/Off Plug drivers. No errors in log.
Could the 'creatEventsFromMap but map command empty' be some kind of hint?
EDIT: Okay... I KNOW that's the problem, lol. Going to make a new driver! Wish me luck.
I'll keep poking at it!
@bertabcd1234, looks like the on/off plug driver would need to be modified or another driver created to make this work. I think it needs to receive a state instead of an on/off.
ie: /api/'your-user-name'/sensors/'sensorid'/state status:=1
You can take a look at the code changes here.
Thanks!
OK, so I just experimented with adding one Hue Lab to my Bridge, the "Candlelight Romance" lab. It did indeed add an entry to ResouceLinks named what I expected based on my name in Hue Labs, and under its links array there does indeed seem to be a sensor entry whose ID matches something under Sensors, and it looks like PUTting a {"status": 1} to /api/<username>/sensors/<id>/state works to start that effect (or {"status": 0} to turn it off). However, I'm not sure this is consistent between different Hue Labs formulas, and I'm not sure what it does if you choose "real" device like a Hue Tap to activate the scene (I chose a virtual device, the webpage control panel).
I'll definitely play around with some of these a bit more, and thanks for figuring out how they are implemented! I'm still a bit hesitant to go too far down this path because I'm not aware of any Labs that actually document how they are done (this is just what I saw for this one), and many of these just seem like Philips' playground where some become actual features later that are much better documented, but for at least a subset of these there does appear to be some way to make them able to be activated from CoCoHue.
CoCoHue has been working great but I'm getting a strange error periodically in my logs:
org.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 151 (parseLightStates)
Any thoughts?
That looks like a Hubitat database error, my understanding of which is that it may be the result of database corruption (not related to a particular app). You can find some threads here if you search for similar errors (e.g., this one). A soft reset (download a backup locally first) is usually a pretty safe option that might help if you feel comfortable trying that.
If you’re using HubConnect it could be an orphaned device, or a device that you changed the name of which is why it can’t find device name.
I appreciate the responses. I'll run through the soft reset procedure this evening when I have physical access to the hub.
I'm not using Hub Connect but I recently added a number of additional bulbs to my Hue Bridge. I also noticed that when I'm in the "Manage Groups" portion of the Bridge Instance Child App setup I seem to have some strange entries that populate. Is the app pulling this info from the Hubitat DB or from the Hue Bridge? Is it possible there are orphaned entries in Hue?
CoCoHue is just pulling that from the Hue Bridge. Casual Googling suggests that these names may have been created by Hue Labs formulas you've tried in the past: "custom group for $lights" - Configuration - Home Assistant Community (I've been trying to tell people how mysterious these are )
Normally what you'll see under "Groups" are Rooms and Zones you've configured in the latest version of the Hue app. Third-party apps may let you do different things here (as apparently does Hue Labs), so I can't vouch for the typical behavior there.
EDIT: fixed my link
Download the Hubitat app
