Group concept as a weakness

💬 Lounge
1

This dialog could also be put under the Feedback instead of in Lounge, but I felt that ship has passed on this.

I have stumbled more than once on the whole concept of Groups. I feel that (prepares to be skewered) Hubitat implemented this poorly and is continuing to pay for that mistake.

First, understand I see a nuance difference between a set of equivalent devices that work together and a set of devices that make up a larger party.

EG; a bathroom light maybe made from a set of lightbulbs - all with the same features and values. But this set should quickly and easily be implemented as a Device with an equivalent device type that defines the values for its properties. The components of this device are children. In my mind this should be referred to as a device Team.

A case in point, I have a bathroom light that consists of 4 Sengled bulbs. But the parent device - in my mind is not group per se, but a team, of 4 bulbs working together. By limiting the parent device to inherit (and check) that all 4 children are RGBW bulbs, I can easily manage the parent to be exactly defined in it's properties of the Team without trouble.

A Group - can be devices of dissimilar items/devices. Switches and bulbs, etc. etc. etc.

Further - the 'groups and scenes' has changed since my implementation of Hubitat - Originally a group was a Dimmer I think, regardless of what it incorporated. Now we have 2-3 more group types but it is still messy and inaccurate.
I stumbled recently on a 'device' that was Group of 1 item. I do that to name the Group for ease of management in voice commands. Looking under Devices, I opened the group Device name (why are group devices listed under Devices anyway!) and could not find the value of 'Use Group devices to indicate if any Members are on?'. Frustrated I was preparing to rebuild the group, and saw that the parameter was there within Group setup but not visible under the device.
When you make a group you choose one of 3-4 group types so your dashboards can work etc. and it is only ever partially accurate since it inherits a limitation defined in the Group types as opposed to being accurate for the Parent device (Team as I like to call it).

Lastly, I feel I'm on to something here, as if you notice even the word choice of the Group parameter:
'Use Group devices to indicate if any Members are on?' calls it "Members" - a clear indication that the thought came to someone else's mind before my own. I see no other reference to "Members' anywhere else in my hubitat!

So, Groups, Scenes - sure. But I believe there should be Teams, defined as a parent device which consists of children of like devices working together at all times.

2

Isn't that sort of the idea behind the new "Rooms" paradigm? Note: I have not used "Rooms" yet so might be wrong about this.

Also liking or disliking the way HE presents "Groups" is a personal preference don't you think? For my use-case it works just fine so am okay with it. Could there be more features better presentation? Probably...

5 Likes
3

the thing with placing the devices as a child can be disputed by when a device goes into multiple groups. in that case, where would you put the device?

i do like your idea of showing all the devices in the group on the device's details though, that would be nice to see instead of having to go back to the apps screen

4

An interesting idea, but I am not sure if I understand the importance of distinguishing between "groups" and "teams"... I wonder if both of these could be accomplished with only groups by adding a few new features to groups.

Does this restriction mean that all children must have the same device type, or just the same capability list, or just some "important" capabilities in common?

e.g.

  • Could I create a team with 2 hue color bulbs and 2 sengled rgbw bulbs?
  • What about 2 Hue CT bulbs and 2 Hue Color bulbs (all support Color Temperature)?
1 Like
5

At some level you are talking about the "scenes" part of "groups and scenes".. which would allow such control... I know it's a bit of a stretch since the scene is "fixed" but it comes close.

I wonder what the use-case for this would be?

6

Simply put - No.
Rooms have no function - just spacial constructs.

7

Sure - specific devices can be allocated to multiple groups. One could use a single bulb of a multiple bulb physical fixture. but that's an exception- not a rule.
I have a kitchen table fixture with 3 bulbs. I have a kitchen sink fixture with 2 bulbs. I have a hallway fixture with 3 bulbs. a Bathroom fixture with 4 bulbs - even my garage fixture is a 3 bulb.
Does a Group hold the fort? sure. it's all we get from Hubitat. But it misses my point if we just want to maintain this construct.
What I'm trying poorly to describe is an appliance or a ... (trying not to use confusing nomenclature here) ... thing (lets go with Fixture). In all my cases - each Fixture is comprised of multiple identical smart items. In most cases it's bulbs. I use color temp bulbs in my Kitchen Sink. In my Bedroom fixture I have 3 RGBW bulbs. Yet in the 'Group' construct there is no 'Group RGB'. And as I described previously Group works well when I want to turn the Bed Lamp (CT bulb) on and the Bedroom Light (a 3 bulb RGBW) on. Group works - and is applicable, but I am trying to convey my belief that in real world applications a fixture is a 'team' or 'set' or package' of commonly identical smart devices. From these we can easily ascertain the appropriate properties that this team/set/package would need based on a poll of the individual children drivers. Anyways. I'm droning.

8

Blockquote
these could be accomplished with only groups by adding a few new features to groups.

I believe its true to argue Groups could be made to be a catchall - and I originally thought that's how it would evolve 2 yrs back but that's not what happened. On the other hand it's possible that by adding just a few more group types that cover the most common cases I could see the result ending well.
and regarding your thoughts about grouping non-identical items - my debate position is 'in what case does this really happen?' I've got 6 entities in my real world environment, and in none of them have I mixed and matched! Group works perfectly for those cases of dissimilar items.

...

9

My last bullet to support my position- I consider what community dev guys can take advantage of. When they have to consider groups they have to take into account all the variants of wierd group structures. Being able to know that the properties of a fixture - Parent - could really be beneficial downline!
I for one, think group items shouldn't be listed in 'devices'. But a Parent with Children, perfectly behave here. My chosen word of 'team' may cause angst, but the functional existence of it seems oddly lacking in my mind.

10

So apologies - I might not be following your line of thinking on this...

That has to be taken into account anyway - depending upon the nature of the device being manipulated - virtual/physical/parent-child etc.. In fact I would argue treating a "group" (and other virtual constructs) as a device is very important as you can treat it in code the same way as everything - a much simpler process.

Seems like adding a parent/child aspect to groups would be a very cool way of handling the members though. As an aside I think you can easily lookup the members anyway given the group device. I have no opinions on the UI displaying such itself - as the current setup works fine for me.

Note: I have dabbled in writing drivers/apps for HE so am familiar with the steps involved.

2 Likes
11

why not use a smart switch instead of smart bulbs? it sounds like that's the type of functionality you're looking for

2 Likes
12

The newer smart switches even have a smart bulb setting which disables the physical switching bit.. very handy if you have to go that route. I prefer switches over bulbs for the most part but there are certain places where bulbs work well like in lamps.

1 Like
13

OP presumably makes use of RGB and color temperature. Or perhaps the home wiring doesn’t easily support most smart switches, or it’s a rental.

But I agree this seems to be a very smart bulb-centric way of approaching the issue of groups :slight_smile:.

2 Likes
14

I automate the color temp to match time of day - not sure how (or why!) I'd do it with a switch but it's valid of course as a solve - but a later post hits it on the head - I'm a renter so modding the house switches is too deeply involved.