Right, but they should. I've asked before, but apparently it's not high on the list. There's no reason for a 3rd party program to limit itself to Hubitat scene conventions.
The point was that the lighting automation company with the deepest experience has scene off programming.
But they also don't have groups. And their scenes are not like Hue scenes. If you have a RadioRA scene controller, when turning a scene off, you're actually setting it so that no scene is in effect which has the result of turning the lights off. You're not really turning the scene off. Otherwise, when you went from one scene to the next, the lights would go off first, and they don't.
Not sure why having the option to have configurable scene 'off' functionality as bill.d suggested would be a bad thing. You could have it default to nothing, but having additional options would sure be helpful for a number of the reasons referenced previously.
Actually you can already do a couple of the options....either turn the devices off or ignore it. That's already an option for built in scenes. The other options presented I don't feel are very practical. If you wanted another user-defined state, then instead of turning off the scene, turn on another one. And return to previous state? What if the scene goes "off" by just changing the settings away from what the scene includes? There are too many permutations there.
if you wanted that, you could get it by a capture restore.
I appreciate the ideas. I will consider ways to implement this and play around with some things when I have time, probably a setting you can configure the app when adding the scene device or manage after the fact (I'm not sure this would be possible on the device page itself from the driver for technical reasons, though I know that might be a more obvious place for some people). This would address most of the reasons that I was otherwise considering creating scene devices as child devices of group devices. The tradeoff (which I'm more than fine with...) is that now it's your job to say what happens, not mine to do my best to figure it out. 
I don't think the "restore previous states" option from Lutron is very practical in a mixed-device system like Hubitat (but if you do, you could as suggested, capture and restore in a rule yourself), but the others like "group/zone off" or "specific lights off" would be do-able in some form, and they could also continue to do nothing at all as they do currently.
Version 1.8b released
I have pushed out a small update to v1.8, v1.8b, that I think fixes the issue with bulbs in CT mode getting a spurious, RGB-style color name set on the first refresh (for most people within the first minute) after changing to CT mode.
RGBW bulb and Group drivers are the only files updated.
These v2 changes sound like good ideas to me. It seems like it would streamline the management of Hue devices even more. TBH I get the most utility using groups, zones, and scenes now. I would like to add some more notification type automation in the future which would require individual bulb devices. So your idea of linking groups (or zones) to the scenes that control them, and making individual bulbs child devices would be great from an implementation\organization standpoint. At the moment though my most looked forward to feature is the CT and white bulb drivers to simplify those devices. Having all the RGB cruft on those devices seems like a great opportunity to streamline further. Thanks for making this wonderful app, which I found through your Dimmer button controller app.
Are all of your lights connected to Hue?
I just pushed another minor update to the RGBW bulb and Group drivers (v1.8c). The fix I introduced in v1.8b was a bit too aggressive and stopped color temperature events (and maybe all color events, but I know CT was affected) from getting created immediately on a manual change, instead having to wait until the next poll for the correct value to be reflected in the attribute/current states.
Honestly, my intent was just to make it easier for the app/driver to know what lights "belong" to what groups so that when one is changed, the app will have an easy way of knowing what other devices may be affected (to change their states immediately without polling). It's what I already do for lights and groups without the parent/child relationship, but I don't do anything like this with scenes because they are more difficult, and this was one way I could think of to make it easier. The intent was not to make it easier for users (but hopefully not harder).
Hubitat has hinted that they've internally tested room/group or similar organization (no guarantee if or when they will release this). This sounds like what you'd really want for this problem (though the parent/child device relationship is one way that devices, at least in the device list, may appear a bit more organized as a side effect of that relationship).
Yes. It is really why I like this app so much. All the scenes are created in the Hue app by family members. I can then use those with this app, dimmer button controller, the lutron app, and some pico remotes to add their favorite scenes to scene selection on the picos.
This was very time consuming with the default hue app.
Then that makes a lot of sense. But you have to realize though, your use-case is a little unique. I would say that the vast majority of Hubitat users do not have 100% of their lights set up connected to a Hue Bridge. So, if only 50% of your lights are through Hue, Hue scenes or groups are a lot less important.
Any chance you can add an all lights device switch? I would like to be able to turn all lights on and off, and I don't want to have to remember to edit a group when I add\remove lights.
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.
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.
Download the Hubitat app
