I’ll jump on just about anyone’s bandwagon. But you and Jason Bottjen (@JasonJoel ) have insights and suggestions that often impart wisdom to me.
1 Like
Is the difference between "rooms" and "tags" just sematics? Can't I create a room called "XYZ" tag, and a tag called "Living Room?"
Just wondering why it matters if we refer to them as rooms or tags, as long as we can use them as we wish. In that case calling them "Rooms" could be easier for less techie/more basic users to understand/use them.
(Backing up and putting on my cardboard King Arthur armor to receive my schooling.) 
4 Likes
At the moment, because they are meant for rooms, each device can only be in one room. The tag idea is about being able to apply more than one category or grouping per device
3 Likes
Ok, so just need a bit more flexibility...
[quote="Inge_Jones, post:17, topic:91753"]
I'd prefer a truly flexible tagging system where tags can be used as primary and secondary sort and collapse indices.
[/quote] 
[quote="Inge_Jones, post:19, topic:91753"]
Yes anyway I was already agreeing with Jason's in my first post in the thread, which sounds more instinctive to me than your OP that builds on the existing system.
[/quote]
???????
Perhaps I preferred to go and poor another beer.... 
But seriously.... I was wanting to have it both ways, being involved / contributing to the conversation and standing at a distance, allowing others to drive the conversation.
Personally I like the idea of both fixed concepts such as Rooms or Zones, as well as more flexible setups like tags. I have personally developed unrelated systems that employ both optional and fixed labels such as these and I think there is a place for both here.
1 Like
Well there is one benefit to keeping the Rooms system alongside the suggested tag system. The Android Hubitat app presents a nice auto-generated dashboard of devices presented in Room layout which once or twice I have used when for some reason the dash I usually use is playing up.
1 Like
Exactly the reason a known tag is useful.... in my opinion
As much as the concept of tags makes sense to me, the use case is still important. Filtering based on capability or function is useful, but is the only use case the devices page? Or are there others? Not a criticism, just wanting to ask the obvious questions.
In my use case, the tags themselves would be useful in organizing my wide array of devices in the device page for easier identification for a variety of reasons including 1) just more logical organization in general, and 2) easier look up of device when trying to look up events logs for trouble shooting. With multiple tags, we could also consolidate devices according to various attributes as well, such as battery powered devices, PIRS devices, Temp sensors etc without having to do this alphanumerically as I currently have to do (and alphanumeric device names only allow one level filtering whereas multiple tags would allow for multi-level filtering).
The other main desired feature would be to allow inclusion of a device in multiple “rooms” (essentially by various “tags”) such that they can be functionally grouped much like what is already available in Alexa. Way back when I exchanged my X10 type devices (I know, I know) for WiFi (I am relatively new to Hubitat but not to home automation) and prior to Hubitat, I found that Alexa’s ability to have devices listed in multiple rooms (or groups if you wish to call them that) was very helpful in simplifying Alexa routines. I would think that the same would be true in HE when making Rules.
As I still have (I know this is sacrilege in these parts, lol) a number of cloud dependent WiFi devices accessed through Alexa incorporated with Hubitat, I find that in many cases it is easier (for me, YMMV) to have those devices organized in the Alexa app when organized in various Alexa “rooms” when a device must be listed in multiple rooms or groups. Again, I would think this would be nice in Hubitat as well.
Anyway, this is only IMHO and I could be missing some other factors and use cases that may be more obvious to others.
1 Like
Sync Rooms with devices over Hub Mesh.
Frustrating that I created rooms on the "Host" hub and they don't show up anywhere else!
3 Likes
I'd like to see rooms be a basis for some default automations. The first post eluded to this. If there's a switch and motion sensor in a room, there should be a simple toggle in the room view to enable motion lighting. If enabled a few drop downs could appear to allow options like timeouts and such. The app/programing model works well enough for us current users, but an easier, intuitive way to automate needs to be found for the rest of world users.
Making rooms another tag would be a waste of potential. That said, I'd like to see the tag system implemented as filters that persist when you navigate away from the device or app pages.
2 Likes
Wracking my brains, but I can't come up with any other benefit of treating tagging by room any different from any other categorisation. Mind you, a device shouldn't need tagging by capability. To my database-loving mind it would or should be an unnecessary duplication of data, with a potential for getting out of sync and therefore inaccurate.
I see a future for a filter feature with Filter by... (or Collapse by?) then dropdown with Capability, Custom Tag, Device Type (ie driver) etc. Then depending which one you choose the next dropdown is populated by a list of your custom tags, the known capabilities and so on.
Can I deviate slightly here to say I'd really also like to sort on Name not just Label.
2 Likes
Quite like the idea of a 'custom sort', the results of which would be saved.
This 'saved search' result could be selectable via dropdown, and able to be referenced by rules/webcore etc.
Eg
All devices
Devices with temperature
Select a few here - > save as "temperature low floor"
Back
Select a few here - > save as "temperature mid floor"
Etc
But to be fair, my only reason for this would be be quickly reference locate a device. Which I don't need to do very often at all.
1 Like
I don't care if they are rooms or tags, what id like to see is the ability to use them as a selection in Dashboards, or RM or anywhere you can select multiple devices, as you can using Groups.
4 Likes
I'd like to use something like this "saved search" for defining the devices linked to a dashboard, a device group, motion lighting zone or perhaps even a scene. In terms of traceability if the search results was a child app, then you could still see where the device was being used and follow the trail to the other apps that make use of the device list that comes from the search app.
Much like people wanting to reference Rooms in a similar way, this would also allow for quicker and potentially an easier setup for the end user. Put things in the right spot or tag them in the right way and they are automatically part of automations and other parts of the system.
1 Like
I also wanted to have devices in multiple rooms, but for a slightly different reason. In my case, I mostly use homebridge to interact with the devices via iOS home app. In that case, I actually needed each physical "device" to appear multiple times within Hubitat so I could place them in different rooms on iOS.
To solve this (and some other problems I was trying to address), I ended up writing a "universal" driver in which the "parent" code contains code for most types of devices (switches, dimmers, sensors, etc.), but wasn't used for device control itself. Instead, you can add multiple "child" devices which provide control. In the multi-room case, you could add multiple "child" devices of the same type so they can be placed in multiple rooms. If you are interested in giving it a try, see link below and not step 3(b) in the instructions. Instructions are "mostly" done.
In your case, you could create multiple "child" devices for your lighting and place them in different rooms. Thus, the same physical device appears in multiple habitat rooms
As a bit of caution, since the "control" is done via the child devices, this driver would require you to rewrite rules to make use of it.
Had a bit of a rethink. Actually Rooms isn't the same as Tags. Rooms is a group-by key, whereas tags is a list. You can't group or collapse by tags, because an entity might end up with more than one group to be in. In order to make the Rooms concept have a wider scope, we'd have to be able to add our own keys. So I have changed my mind, I am happy for tags to be added, but not for Room to become just one of many tags. Might be nice to eventually have one or two spare custom keys, for us to use as we wish.
Yeah, I had additional "room-like" tags in my head as well, but if it's just arbitrary string tags then there is no grouping or category aspect to that. For example, tagging a device as "battery-operated", verses a user being able to create a "battery" tag (type) and assign a device a value of CR2032 under a battery tag.
I prefer the second of these options, which I think is one part of what you are also advocating for @Inge_Jones, essentially allowing users to setup an equivalent to a Room selector like we already have. I'd add in an option to configure the "tag" as either single or multi-select, to cater for other suggestions of, for example, devices being part of more than one zone / room.
Additionally, filter by capability (read from driver not user-tagged) and other properties that can be read from existing data.
Wrt your single or multi-select, wouldn't that be more complicated to implement and use than having Tags as an extra feature? So I'd say 2 custom keys PLUS freeform tags list
And let us select which custom key to group by on the built in device dashboard in the phone app.
