Thanks, that makes sense. It does seem like having a "minimum capability" driver makes just as much sense as a "maximal capability driver" -- or perhaps having one each for dimmer-only, bulb-only, and switch-only since groups are already trifurcated that way. Ah well.
Next step was going to be going the virtual switch route, good suggestion. Appreciate the response!
This is just a virtual child device that communicates directly with the Group you created. Suppose you were to edit that Group and add a different type of device to it? You wouldn't want to then have the existing child device be incapable of commanding the Group. It having extra capabilities costs nothing.
Yah I hear you. I think the only "cost" is that the group can falsely appear to have a superset of functionality when exposed via the UI. So on my Google Homes and in the Apple Home app, the lights show up as cyan and 20% level (or whatever, it seems to be random) when they're really just on/off. But I also recognize that those UIs aren't the core use cases, so not a big deal!
Yep, but it is necessary. We don't have dynamic capabilities, ones that come and go depending on what happens. So, since Group may need all of those commands and attributes, they have to be there.
Even worse is that my fan shows up as a color light bulb in Google Home. And in Home you can assign different device types to switches, but since this is a bulb and not a switch I lose that capability.
I worked around the issue by using the Community Google Home application, but it would be nice if a switch just showed up as a switch. I wouldn't mind if I had to specify a device type when the group was created and forever be limited to those capabilities.
I'll look at this possibility.
This should work. Also, it will allow fixing existing groups by simply changing the driver used. There will be two new drivers: Group Dimmer and Group Switch. These would both work with any collection of devices in a group, but obviously only allow the control of a dimmer or switch.
Actually, what I said just above is wrong. These two new drivers will allow any type of control, they simply won't advertise the capabilities. So it's the best of both worlds. If you want a switch to show up in Google Home (or elsewhere), you can choose the switch option. That Group could still have color devices in it, and other apps could still set the virtual device with color commands.
These three drivers, the existing one and the two new ones would be identical but for their published capabilities.
This feature and drivers will be in the next release.
Thanks for this. This will make integration with things like Homebridge less confusing for non-techie family members.
Great news, thank you so much!
Very cool solution, awesome!
The way this works for GH is based on device attributes. So if you start with a bulb driver, and change it to a switch driver, you'll still have a bulb -- because attributes once set do not go away. The other direction will be fine. If you start with a switch driver, you can change that to a bulb driver and it would work; you might have to send a color command to the device to get those attributes set.
At any rate, the app will offer the choice between bulb, dimmer and switch when you first set it up.
That's great and will add some nice options. If you're doing work with Groups to make them more functional it would be nice if you could separate them from Scenes in the UI.
Groups are working as intended. You'll see color, level, temp settings for all groups. If mixing CT and RGB bulbs you would probably only use the switch and dimmer capabilities. Color commands would be ignored by the CT bulbs; and if your color bulbs are RGB (not RGBW/W) but support CT than CT commands will give you strange results. If grouping switches, only use the switch capability.
This is discussed elsewhere in these forums. If HE limited group capabilities to only shared device attributes someone would be asking for it to expose them all. The onus is on us to keep things straight.
Maybe the 'Mirror Me' app would serve your case of switch groups better? If I were going to mirror two switches, I'd probably make a virtual switch called "Group: Switch - xx1 xx2", make it the Master and then slave xx1 and xx2 to it.
Download the Hubitat app
