I would recommend doing that via a virtual switch and a rule. When the virtual switch is turned on, the scene would be triggered and when off, the group would turn off.
Some people don't want the lights in a room to go off after a scene is done, they might transition directly to another scene. If this was done, you wouldn't be able to transition from one scene to another and come back to the original because the scene device would still be on.
Honestly, I'm thinking about making a v2 where I make a few breaking changes, including making GroupScenes child devices of the group device they are associated with (this would include any scene most people have created recently since it's all the v3 Hue app will do; third-party apps or anyone who still uses v1 scenes may have LightScenes that are not associated with groups, just bulbs, and I think I'd still make those "standalone"). Then, users could have the option to turn the parent device--i.e., the group--off when the scene is turned off. I'm really not sure what people want to happen here since the Hue app doesn't support turning off scenes, either, but this seems close enough...
I could sort of already make that happen, but other changes I'm thinking of include making bulbs/lights child devices of their group/room, too. CoCoHue already handles "syncing" states between the two without polling if you have those options enabled, but I think this would allow it to do it more efficiently with less searching. The only thing I'm not sure how to handle then would be beta "zones" from Hue that could be subsets of rooms or (I think) include bulbs from multiple rooms...
In any case, sounds like there may be workarounds above for just the particular thing you are looking for. I'd recommend turning off the bulbs or groups yourself somehow, like that.
Great suggestion and totally understand your point about the difference behavior various users expect from their use of scenes. For me, I have a number of scenes specified in the Hue app for various rooms that are generally tied to modes. For example, during the Day, the lights are a little brighter and the temperature is set differently than the evening and night respectively. Movie mode is also very different. I like being able to reference these through both hubitat and also through the native Hue App, Homekit/Siri, and Google Voice/Alexa with direct communication.
For motion lighting based on modes, it is just a lot of extra steps that seem like they could be reduced with some kind of link between scenes and the groups of lights to turn things off without having to create and keep track of a ton of virtual switches per room/scene/mode.
Okay....but what happens when you go directly from one scene to another? Do you want the lights to turn off in between?
That would be ideal! Looking forward to that as a possibility.
No, though in that case simply turning on another scene wouldn't necessarily trigger the existing scene to turn off, would it? In the case of Motion lighting based on Mode, I am fine with the lights all turning off when motion stops. If a scene were turned on and then the mode changed while the lights were still on, I would hope the new scene could be activated without the lights first going off. Not sure if what I am trying to explain, makes sense?
Only on the edit device page. Child devices still appear alphabetically in all other listings. Personally, I would not want this type of structure. I don't use Hue Groups or Scene so I don't sync them over. So, I would have to in the future? I just want the lights.
I don't think this needs to be a problem. Turning one scene device on wouldn't turn another off (unless you do it yourself or someone convinces me to make it this way, which I don't think I would). Repeated "on" commands in a row to the same scene device would still be tolerated, so there is also no reason to turn it off if you don't want to.
(The whole thing with scenes being on/off switches is a bit messy since, of course, Hue doesn't really expose them that way, but having a device you can turn "on" instead of just being a button you can "push" seems to line up better with the way a lot of people want to use it. I'm not sure I'd have done this in the first place myself.)
Efficient code-wise, not (necessarily) for users. It would need to look only at the child devices of that group device, not all child devices from the CoCoHue bridge app, which should be faster.
Hubitat's integration can handle just lights if anyone only wants that. 
I'd certainly also leave v1 of my app available as-is should anyone want to keep using that (I probably wouldn't update it anymore, but I'm pretty sure Hubitat has only touched theirs once since it was, too, so 
).
However, I certainly understand this feeling. I do use rooms (and now zones) on the Hue side but don't use all of them in Hubitat. And again, users of older Hue app versions or third-party apps may have plain lights that are not associated with groups, so I'd probably still need a way to handle that.
Anyway, I'm not really married to this idea; it's just something I was thinking about recently that might help with a few things.
But via a dashboard or a virtual assistant a switch cannot receive multiple on commands. It first has to go off. This is why I recommend the button capability instead. That is momentary and stateless. This method of leaving all the scenes "on" will result in the user only ever being able to trigger scenes from the edit device page. Also, they would have no idea what scene was currently active.
We've discussed that at length. It just seems that forcing syncing of groups when you don't need them creates unnecessary overhead.
On a Dashboard, I'd recommend the Button template instead (the on/off state isn't really useful anyway, and it avoids this problem). For voice assistants, that is not my experience. I was able to turn "on" a virtual switch multiple times in a row using GH on my friend's hub just now (not at home to test my own with Alexa). I'd also recommend that users with a v2 Hue Bridge consider the native GH/Alexa integration instead of putting Hubitat in the middle.
Definitely something I'll consider; I guess that may make it worse (not that I think any way is "bad") for people with a lot of rooms, though really, the app gets app the data anyway and just stops processing it if it discovers it doesn't need that part.
Thanks for giving me some things to consider if I ever play around with these ideas. Again, just some things I've been thinking about and not necessarily something I'll do.
The scene device you've created has both? That is even more confusing.
It all depends on how it is implemented in the driver. You will not get duplicate events when commanding an on switch on unless you have declared "isStatChange: true" in the driver.
Google's integration is Cloud Based, not local.
I've foked the repo...I won't bother you with my suggestions any more. Thanks for your help.
If it were up to me, I'd only make it a button and not a switch at all, but making it a switch makes it usable in more apps (and makes it usable via voice assistants if anyone is using this to get around the upcoming loss of cloud services on the v1 Bridge), and it's the only way I've actually seen devices like this used "in the wild."
Luckily, the driver is mine, so this is not a problem. 
Events aren't really the issue, just whether on() can get called multiple times in a row regardless of current state. Whether the driver or platform actually create a new event as a result is a different issue.
Not a bother at all! I appreciate the feedback and ideas to consider, but if you have specific needs, this may be a good idea. It's why I wrote this for myself in the first place instead of using Hubitat's. Good luck!
You could make the switch auto-off after a couple seconds that that would make it stateless as well.
Again, not from a dashboard.
I don't understand why you have to keep the switch on if you aren't going to do anything when it is turned off. So, they're just all going to be on all the time? That doesn't make any sense to me. Not doing that makes it usable by more than just voice assistants. Do you have a reason you want all the scene switches on all the time? is there some functionality that i'm not udnerstanding?
I would think that you'd want it to be as useful as possible to the most people. I mean, you chose to take the time to release it. I can't discern why you want it that way.
Sorry for the confusion--I was thinking about the future. Right now there is no reason (and I can see why auto-off may make it more useful; that would be an easy add). If I add something where turning off the scene device "means" something (like turning off the group to which it belongs if it's a GroupScene), then this would matter, and that's what I was thinking about.
This confuses me even more. Because if you have two scenes for a group, and both are on, turning off one would turn off the group but the other scene would still be on. I don't understand the concept of turning off a scene in the hue context. Maybe because you can't turn off scenes in the Hue app. But it seems that if you are going to be able to turn off scenes, why do you need groups then?
Scenes as switches are tricky no matter what you do. My thinking is that scenes as children of groups would allow turning off the scene device to turn off the group device and thereby do something (as mentioned above). Turning off the group device could also turn off a child scenes. Activating a different child scene could also turn off other child scenes. (If everything is exposed to and only manipulated from Hubitat, this should keep them reasonably in sync, though I'm still not sure I'd really recommend depending on the switch state of a scene.)
The hypothetical auto-off feature could still be implemented either way (though that would, in a way somewhat opposite to a problem discussed earlier, cause issues if you want to turn the scene off from a dashboard, something I probably would not do in favor of just using the group).
Like you, I don't really like the idea of "turning off" a scene (it certainly means nothing to Hue). I'm just trying to find ways to reasonably accomplish what some people have asked for. For GroupScenes, however, there does seem to be a reasonable enough path. (Really there is for LightScenes too; it shows associated bulbs and those could be turned off. It's just that the user can change those at any time and there's no guarantee that the last information Hubitat got about it was correct, and polling scenes seems a bit wasteful...)
I'm not sure if you mean truly turning something off (like the group) or just auto-off on the scene device. I'll respond to both scenarios so you don't need to bother replying to this already-long discussion if that is the only reason. For truly turning something off, having the group means that there is a parent device that could be turned off instead, conferring several advantages: already knowing the device to turn iff is more efficient than searching for a matching device, having a parent device means the group device would actually be there (no way to force the user to add the standalone group device otherwise), and the user has a clear way to see which device would actually get turned off. If you just mean auto-off, there is no inherent need for groups, which is why this could be easily added to the existing version (as well as this hypothetical future version; the ideas are not incompatible).
Again, this isn't necessarily something I will do, just something I'm thinking of. I will probably play around with my ideas at some point and see how they work in the real world, and if not disastrous post a version others can experiment with too to see if/how they like it. Otherwise, nothing is happening to v1.
If you change to a parent child relationship now, you would also have to re-install all your devices. Don't know if that will play into your decision as well. But all your devices are going to need new device-IDs to associate themselves with the parent and therefore would have to be created new. You'd basically have ot uninstall and start over to move to a parent/child relationship.
All things I am aware of and why I called them "breaking changes" (all still hypothetical for anyone coming into this conversation late). FWIW, I'd also take this chance to get rid of the parent app, which doesn't add anything at this point except being a sort of "container" for the child apps, of which most people have only one.
I think you have a RadioRA 2 system. The RadioRA 2 Toggle Control/Room Monitoring Button keypad programming is Lutron's way of adding 'off' functionality to a scene. I think it works well for its intended purpose. My in-laws just had a HWQS system installed and their integrator did most scenes in this manner.
In Hubitat I'd like to see anything called a scene have configurable 'off' functionality. IMO those options should include 1) nothing, 2) all devices off, 3) previous state, 4) arbitrary user-defined setting
Yeah...but Hubitat scenes don't even have that level of configuration yet.
No, I'm pretty sure we're talking about Hue, not Lutron.
Download the Hubitat app
