I really like the idea of modes however the mode manager as it exists today I believe works well for two main use cases. Modes for the overall system or home automation for relatively small spaces or houses. I have for some time really wished that I could have the mode manager as we know today but add to that individual mode groups that can change their own modes independently of the āsystem modeā to effect individual rooms, spaces, or use cases. For example, I might be entertaining and I want to change how the kitchen automation works based on the kitchen area mode which I change. At the same time maybe the kids decide to watch a movie and that space is controlled by the entertainment area mode. I could imagine that these group modes could be changed automatically by the changing of the system mode but then also be changed independently. I have considered try to write this as an app however I think it could be better integrated into rules and other apps if done by the platform owner. I know this might could be done by using a bunch of virtual switches but there is a reason why we have the mode manager instead of just being told to use a bunch of virtual switches. Itās easier to conceptualize and manage and integrate throughput the system. I really think this could be a really powerful feature to really expand the capabilities and make it easier to do automation.
Try and think out how that would be expressed in a "Room Mode" Manager app that would control this. I cannot think up a simple way to do this -- you'd need to have RM like rules so that each person could individually implement what makes sense for them. If you can't express it other than "I can imagine" without writing out more details, it isn't likely to become a feature.
The good news is that we have RM to do this, and the ability to have virtual switches (or other control levers). Thus, you can built out what you want today.
I have a bunch of virtual switches I use to disable various automations. E.g., when we set up a projector to display on the wall in the Front Hall (with a cathedral ceiling) to watch a movie on an effective 12' screen. When that happens, I want to turn off the automation that turn on the lights in that space when we walk through. I just ask Alexa to "turn on Front Hall Manual Control".
I've got a Group called "Manual Control" that ties together the various different virtual switches I have, so I can turn them all on at the same time. If I set the Mode to "Disabled", it turns on "Manual Control".
All those rules make it work for me. But I bet none of my use cases would map to other people's use cases in a way that would make this an easy to understand feature.
I feel when writing a good feature request/idea one should not be so specific to lead the implementation in a way that allows it to be rejected out of hand. Instead provide enough information to show its value but let the implementers room to innovate and work. Heck maybe this idea sparks in their heads a new way of thinking about things and they are likeā¦ yeah maybe not quite do it that way but we can approach it from this angle.
With that said the main advantage I see of group modes is that you have an enumerated set of values of which only one can be active at any time. This is distinctly different from say virtual switches. I suppose you could write rules to do similar things. Modes ensure only one is active at anytime for the group is straightforward and makes logical sense especially when looking at implementing decision trees or behaviors in rules. Itās easy to know what the setting is set to for say a room or area. Can be easily changed from tiles. Rules and behaviors in rules may easily become group mode aware just as they are currently. Instead of listening or querying the system mode you listen or query a specific group mode.
So yeah. I can imagine this feature. It makes a lot of sense and I think itās a natural step forward in extending current behavior. Will Hubitat agree? I donāt know but if I didnāt put it forward I would never know.
Conceptually, this could be done with a virtual button.
The idea is to set the room mode that overwrites the location mode. Rules that are processed using modes do so based on the event of the mode changing. So, it's point in time triggered.
Using a virtual button provides the same function and gives you more options than a binary switch. Configuration would be the same. You'd set each button to correlate to a "room mode" and set up your rules (Rule Machine, Room Lighting, etc.) to react based on which button is pressed.
I think the real feature request here, of there is one, would be to expand the "vary with time period" option in Room Lighting to accept other inputs.
I slightly disagree with this statement. It provides similar functionality but some of modes power are in what can easily be done in rules or applications in a straightforward manner such as below.
Setting up seven virtual buttons just to do something like that? And then have to go and maintain the if statements? Can it be done? Yes. Is it as easy and user friendly? I don't think so. I'm not saying it all boils down to the example above. It's just that an example that shows one aspect of how modes can make things easier and cleaner. It's also why I think them being expanded further than their current manifestation clearly makes sense to me.
I'm glad that virtual buttons work for many people but just because there is a way doesn't mean there can't be a cleaner more straightforward solution. I mean Room lightning replaced several different apps that exist[ed]. I see this in a similar vein. ĀÆ_(ć)_/ĀÆ
That's a fair point and what I think I was trying to get at with:
Basically, anywhere that modes are used, add in additional options. But then I imagine that will get messy with trying to deconflict between location modes and whatever more granular option you wish to define.
