True, but it is the reason I started using CoCoHue app. I feel this is the killer app for this app. I actually still have the bundled hue app configured, but I hope to migrate just to this since it is such a huge time saver.
1 Like
I think so! I'll try something for the next release.
And I don't think it's odd to have all your lights on Hue. I have almost all of mine on Hue. It's a lot better at lighting than Hubitat alone, and I like almost everything about the way those lights behave better than ones directly connected. Exceptions are usually locations with just one bulb where Hubitat won't overwhelm a bunch of bulbs with commands (seems to be problematic for many, including me when I tried them directly paired) and my need for Hue scenes isn't really there. Anyway, I wrote my own integration since lighting is very important to me, Hue is my preferred system(for the lights themselves only, not automation--it's too basic there), and I wanted some things the stock integration lacked.
I didn't say it was odd...it just doesn't seem like the statistical norm for most users on Hubitat. I could be wrong but that's the impression that I get from reading the forum.
lighting is very important to me, Hue is my preferred system(for the lights themselves only, not automation--it's too basic there), and I wanted some things the stock integration lacked.
I agree with this. The HUE\Lutron\Hubitat (dimmer button controller\CoCoHue) is a really great combo. If you use Hue, Lutron, and Hubitat where they are each strong it is really the best of lighting automation available.
One thing I have just noticed with the CoCoHue app is that when I add new zones in the Hue iOS app (now that zones are out of beta) I do not see them listed in the groups section of the CoCoHue app. Previously I added a bunch of zones as groups and it worked great. Did Hue break this, or is this intentional that CoCoHue does not treat a zone as a room? Considering rooms and zones are essentially both groups I would think they would both be listed under groups.
I am currently on latest version of everything (Hue-3.34.0\CoCoHue-1.18c\Hubitat-2.1.8.115).
Also, if I weigh in on the ability to turn off a scene, from a practical standpoint I would say that either a scene should be presented with a single "Activate" button that pre-stages the scene and turns on the group of lights the scene is for, or if it is presented with on/off buttons, then the "On" should work like I just described for "Activate", and "Off" should turn off the lights and leave the scene staged. I think this because I do not like to see a button that does not do anything which is how the "Off" button is now. If the "Off" remains and does not do anything it requires me to remember that. Which is not difficult when you are working with a single device you just setup, but more challenging in a year when you have 50 on\off devices in a list. Hopefully this makes sense.
This is the same functionality I had recommended.
This should work--both rooms and zones are exposed as groups via the API. Have you clicked the "Refresh" button (in the app, not your browser) on the groups page? CoCoHue may be dealing with an old cache if you recently added new groups (same with lights or scenes, by the way).
Hubitat's device model allows for push() (which would basically be what you say about "Activate"), which I implement. It seems there was a desire for on() to work for this purpose as well. Implementing on(), which I did, also requires implementing off(), though as you note, off() does nothing at the moment. For group scenes (this probably includes any scene a current Hue user would use--it's basically anything the v3 Hue app lets you create, a scene assigned to a room/zone...but old-time Hue users might have some that aren't), it would be possible to make turning off the scene device turn off the group. However, this gets tricky because without a parent/child relationship between the group and scene (something I got feedback against above), there is no way to ensure that the group device actually exists. There's no reason it couldn't just give the Hue API the group number and turn it off without involving a device on the Hubitat side, but then if there is a Hubitat device, it won't get updated without polling. And then, of course, there's the issue of what to do if it's not a group scene at all (does anyone still use those?).
There's also the idea above to allow user-configurable actions for off(), à la Lutron. This would be more work to implement but would address the above problems by making it the user's responsibility to choose what happens and only allow possibilities CoCoHue can actually do. I might do that eventually. In the meantime, I'll experiment with some other ideas (turning off the group directly via the Hue API and then updating the group device if it exists, maybe? but then lights that are members of the group, too...).
Another alternative is for me to just remove on() and off() from the scene device entirely, leaving only pushed(). This is now what I wish I would have done from the start. 
PS - It sounds like you're using Dimmer Button Controller. With that, you don't need this functionality at all. Choose the group device for the dim/brighten and off actions (and the on actions, if you prefer). Use scenes from that room/zone for the "on" scenes. There's no way to turn off a CoCoHue scene with Dimmer Button Controller, nor is there a need to when set up in this way.
PPS - By "leave staged," do you just mean that if you turn the bulb off and then back on, it will go back to its previous settings? So standard, soft on/off Hue behavior? Just wanted to make sure I'm not missing anything big here...
This should work--both rooms and zones are exposed as groups via the API. Have you clicked the "Refresh" button (in the app, not your browser) on the groups page? CoCoHue may be dealing with an old cache if you recently added new groups (same with lights or scenes, by the way).
This did eventually work. Must have been a cache issue. I did refresh 4-5 times over ten minutes and nothing. Waited several hours and tried again, and the new zones were there.
Hubitat's device model allows for
push()(which would basically be what you say about "Activate"), which I implement. It seems there was a desire foron()to work for this purpose as well. Implementingon(), which I did, also requires implementingoff(), though as you note,off()does nothing at the moment. For group scenes (this probably includes any scene a current Hue user would use--it's basically anything the v3 Hue app lets you create, a scene assigned to a room/zone...but old-time Hue users might have some that aren't), it would be possible to make turning off the scene device turn off the group.
I'm OK with either the pushed strategy, or saying I need to use v3 scenes applied to a room/zone. But I understand if there are old time users that the v3 solution does not work for.
PS - It sounds like you're using Dimmer Button Controller. With that, you don't need this functionality at all. Choose the group device for the dim/brighten and off actions (and the on actions, if you prefer). Use scenes from that room/zone for the "on" scenes. There's no way to turn off a CoCoHue scene with Dimmer Button Controller, nor is there a need to when set up in this way.
Yah, no issues using the DBC. That works so well with this plugin. I run into issues when I mirror the Hubitat devices in another automation application via MakerAPI. There the OFF button is presented in the device actions.
PPS - By "leave staged," do you just mean that if you turn the bulb off and then back on, it will go back to its previous settings? So standard, soft on/off Hue behavior? Just wanted to make sure I'm not missing anything big here...
Yes exactly. I only mention this because it is also possible and maybe desirable in some situations to set it to a default vanilla scene on turning off. That way if someone simply turns on the group it comes on in an expected way instead of whatever crazy colors the kids were playing with the day before. This mostly does not apply to me since the picos are setting specific CoCoHue scenes when used. If I used on/off on the picos with DBC, then it might apply--but I really like the CoCoHue scenes with DBC.
Just one more thing. Everything works, and if you changed nothing then this still works great for me. Everything I am suggesting is just in the spirit of refinement for some somewhat minor things that are easy to work around.
Great integration, so much better than stock hue.
I made a change to ABC to support CoCoHue Scene rotation. I paired that up to a Pico and use the 3rd button to cycle through hue scenes while button 1 is on, 5 is off and 2/4 are dim up and down. Best thing since sliced break IMO.
The PR is up on ABC github.
Keep up the great work.
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:
- Scene "off" support: for group scenes--most scenes created from Hue app--will turn off associated group (more notes below for others)
- CT (Hue White Ambiance and similar) and Dimmable (Hue White and similar) bulb drivers added, as above
- RGBW bulbs in xy mode are now parsed according to their CT value (and reported as CT mode; previous behavior reported RGB mode but ignored the inaccurate hue/saturation values so was not as useful). In the long run, some sort of xy-to-hs conversion would probably be best, but I played around with a couple conversions and wasn't able to find anything reliable here
Changes:
- As noted above, the
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:- for GroupScenes (most native Hue scenes): turn off the associated group, using the Hubitat device if available, otherwise directly via the Hue API
- for LightScenes (v1 Hue scenes and some third-party apps): turn off all associated lights, one by one, using the Hubitat device(s) if available, otherwise directly via the Hue API. As before, LightScenes are not available to select by default. The option to not hide them has been moved to "Bridge Options" on the main page, not the Scene Selection page. I would discourage you from doing this unless you need to, hence the move.
- if for some reason CoCoHue can't detect the scene type (Hue only documents LightScene and GroupScene, so this should really cover everything),
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.
1 Like
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!
2 Likes
@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.
1 Like
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!
1 Like
