Where do you want to sort them? In the devices page?
Yes, The device list. Currently the name column has both name and label but only sorts on label. IMHO name would make more sense, if we can only sort on one, then we can prepend anything to the name to sort them as we wish, while leaving labels looking like normal friendly words. Having Name in its own column would also do it, but require more UI work.
2 Likes
For starters, I'd just like the room images on the Rooms page be bigger.
The default makes them nearly invisible:
Changing the CSS from position: absolute and the height: width: to 100 makes it better:
The images are already scaled to 250x250, but that does appear to be too big for the amount of text:
2 Likes
So that turning on the Dining Room lights turns on Dining Room lights plus the lights common to Dining Room and Kitchen, and so turning off Dining Room lights turns off Dining Room lights plus lights common to Dining Room and Kitchen, similar for Kitchen on/off. We have it working with Alexa, which allows devices to be in multiple rooms simultaneously.
Similar for Downstairs lights, Upstairs lights, etc.
The whole hierarchical / multiple membership aspect needs some form of discussion and implementation, whether itās rooms , categories, groups or just tags. HE is in early days of any useful adoption of such groupings with non overlapping rooms and I appreciate why time is being taken to evolve this further. Itās not straight forward.
This I think will always be a complex and poorly defined concept, proven by no other software providing an ideal solution. I donāt think itās worth thrashing about all the permutations.
I personally would like rooms to not support sub rooms ,as now and categories added like heating, lighting and implemented the same with no sub categories. Areas might have multiple rooms eg ground floor but are essentially a collection of rooms. Rooms should support multiple categories and categories should support multiple rooms. Groups if implemented are a collection of devices or categories.
So for useful functionality and sorting I think a device should be assignable to one room and to one category but should be able to be a member of several groups for control.
Alternatively, or as something useable given itās tough to model , opt to just allow multiple tags per entity which are totally freeform and can be parents containing child tags which could be rooms , categories, devices etc. (in practice these actually are just more tags). Essentially just allow hierarchical tags in any format and we as a user utilise them as we wish. The fact that āactionsā applied to a tag might not be appropriate for all tag members is up to us to sort out and should just be skipped if non actionable. Donāt attempt a tag status. If thereās a way to protect against users creating tag loops, ie sub tags that are also parent tags then great but if we break things this way then itās our own negligence.
Just as an aside because MQTT topics are pseudo hierarchical by judicious use of wildcarding and nodeRED you can implement all these concepts already..
Viewing categories like just āall thermostatsā with status within HE would be really nice I think though.
Oh, for sure there are a ton of options... the trick is to try and not offer all of them in this manner. There will always be room for custom applications and rules engines like RM. An interface like the one I tried to describe would only work for some. But it would serve as a gentler stepping off point than full RM or writing a Groovy App. I imagine that motion lighting toggle would need three or four option to be useful. Even then it may not be enough, maybe some sort of skill level setting; Beginner, Advanced, and Elevated. Higher the user sets the skill level, the more customizations.
To @sburke781 point, please don't take this as a demand or expectation. When someone poses a question with no obvious answer it always sets my mind spinning. I'm just sharing the direction I would explore if it were I making a home automation platform.
Ya'll haven't disappointed me yet; I don't suspect you ever will.
1 Like
If this were true, then why after fulfilling user requests did Motion Lighting end up with 38 options? You are forgetting a key principal: "Your use case is not my use case".
4 Likes
To be fair, I think that about 27 of those options were for me... 
But totally true, I've seen so many use-cases here that I never would have thought of on my own, and many that I think are interesting and even elegant, but that I have no use for. We have as many perspectives as points on a compass... 
2 Likes
Agree with KISS. But simple is not always usable. Look at Alexa. Managing devices is a total PITA. But at least it's simple, I guess. At least in Hubitat's list one can type to filter.
Also, my semi-regular request to separate Groups from Scenes. As they're different and putting them together is potentially confusing. And Hubitat has another device grouping app, Zone Motion Controllers.
1 Like
The part I think that is getting lost in my proposed concept of rooms, is that I'm only proposing an interface change with a few apps applied as defaults. A rooms-based interface would look like a dashboard with a collapsible side bar menu. That menu would display (depending on) available devices the same app options you'd find in the apps we use today. If you had just a switch and a motion sensor there isn't much you can do in motion lighting. A handful of options would cover it. More items - reveal more options.
Rooms in ST was just a quick dashboard that I only used to find a device quickly. Rooms in HE is the same with a messier presentation, it's no quicker than the device list for me, when looking for a device. Continue evolving it as a second device page?
I see a lot of value in single click automations (defaults). They won't work for everyone, maybe no one. But it would be a system that anyone could try and say they elevated their home in a day. The trick is giving them a path forward that doesn't require navigating hundreds of dropdown menus and basic programing.
What I proposed would not be simple, may not work. It's the direction I would look if I were trying to make a platform with broader appeal to new users.
So is what you are suggesting simply links to useful apps for a room based on the devices included, and the list of devices available when you open the app limited to those from that room? So not so much that automations would be generated as such, just that users are given what are essentially suggestions for apps they may used and a smaller list of devices to contend with inside the app? Or were you also requesting that the motion lighting rule could at least the pre-populated with a common starting point, allowing the user to simply tweak it to suit their needs, rather than needing to start from scratch each time?
If I can throw another analogy into the mix, an Ice Berg seems appropriate. I think discussions of what may seem even high level details at this point may not be as relevant, more so down the track as things evolve.
Regardless of the answer to the question in my last post, I think it's probably worth leaving this as an indication to Bruce and the team that people are interested in seeing Rooms used in some way in driving automations as well as driving features of the system that may be relevant. I'll acknowledge I'm having it both ways by continuing the conversation with last post Bruce commented originally to you that they would like to move in that direction as well, but they want to take it slow, which I can now appreciate from my exchange with @thebearmay on even the concept of syncing Rooms over Hub Mesh, my tip of the ice berg request.
On the other hand, though, we also can't let perfection be the enemy of progress either - or we will never get anything.
Right now I have almost zero flexibility in device sorting and filtering. I can sort devices by device label.... or.... device label. Well, device type too I guess, which I do sometimes.
It isn't critical, there is still search - which I use judiciously. It is just annoying not being able to view my devices in ways that make sense to me (without building a zillion dashboards or having very curated device naming schemes which.... are basically a form of TAGS in terms of how many of us have to implement the naming schemes...).
3 Likes
@sburke781 , I was suggesting the apps be presented as needed based on the items assigned to a given room. Instead of having an Apps list, you'd have option presented in the [properties/configuration/setup] [screen/bar/menu] or whatever they need to be called. Open the properties of a device in a room and you get a state machine specifically for that room and device.
Example: Open a switch, the state machine would show the switch and anything that it can interact. So lights, mode, thermostat, whatever happens to be in the room. Items that aren't Boolean would have a further config screen. A hook for executing traditional apps could fit in there somewhere. (I am making this up as I o after all)
It would only be as complicated as the devices in the room.
Of course to make it easy for users I'm making it harder for the developers. Might not be possible but it sounds cool in my head. I doubt I've shared enough of what I envisioned to effectively communicate everything besides how difficult it would be to build.
Thanks for posing the question.
You should check out Room Lighting. It incorporates the use of Rooms to automatically create an automation based on the devices in a room. It makes reasonable guesses as to what such an automation should be, and makes it easy to adjust those guesses to suit the actual need.
2 Likes
Sometimes it is nice to reflect on a simpler time where ideas abound.... rather than criticisms for having reacted to our requests....
But I'm happy to not promote too much reflection that we let topics like this linger longer than they should, if this is marked for closure I would understand.... more recent critiques of where the platform is at are probably more relevant....
