I've always wondered a bit about Modes and I want to share thoughts and hear what others think.
To me - Modes have always felt - wrong. Having a home / away mode seems logical. A boolean - makes sense.
Modes for times of day are periodic. so in a sense, at least to my mind, they are a different KIND of mode.
To my mind, having a Parent of Mode, then setting children of modes for different sets of modes would be the right way to approach them.
So -
Modes:
Periodic - Times of Day
Presence - Home/Away/Location (to cover reported locations from i360/owntracks etc)
Scene - Your custom Scenes (scenes feel better to me as a mode not a group)
etc.
etc.
I realize, 3 yrs in we're talking about a big boulder. Structural changes are painful and fraught with peril - but it just feels to me this could improve the basic functionality of my hub.
I'm out for the weekend - bowling two tourneys - so I expect a ton of flame but it will be an interesting read on Sunday night/Monday morn!
From your descriptions, it sounds like you're talking about Mode Manager, not "Modes" per se. Am I right?
Also, some automation enthusiasts further differentiate "Modes" with "Moods" (often controlled by a multi-button handler and Rules rather than the core UI), so they wind up having activities associated with, say, Home â–º PartyvsHome â–º Working, etc.
This has been covered many times before. I encourage you to make use of the search functionality of our community to see what other threads are on this topic:
I more or less agree, except to me, modes are largely time-of-day based and I utilize home/away in my automations in other ways. (So I guess the opposite.) As you can find from the discussions above, a common use of modes is to restrict or change automations based on mode (e.g., don't turn on lights with motion when away or in night mode, or change the thermostat set point when mode becomes away or not, etc.). Most apps have way some built-in to use modes, so that's an advantage they have over things you can also use, like hub variables or virtual devices that simulate a variable.
My main use of modes is probably modifying lighting automations based on current mode; many lights don't turn on with motion at all during the daytime, most do in the morning or evening, and only some do overnight (and usually at a dim level). But conflating presence and time never quite made sense to me, either. If someone comes in my house when I'm away in the evening, I guess I'd rather have the lights turn on and possibly scare them out. Ha. In any case, modes work better than strictly time, since I can turn on night mode whenever it is that I actually go to bed, and one of my modes ("cloudy") is based on outdoor lux so isn't consistent day to day. Plus, it's more convenient to be able to set mode once and have it affect all these apps, rather tha needing to edit something in each app individually if I change my mind about when I want something to happen.
Presence for me is a virtual "combined" sensor that I use a custom app to set based on multiple detection methods (for reliability). The biggest disadvantage here is that not all apps have a built-in way to use a presence sensor, but I really don't use it for much. For example, my thermostat is handled via rules and manual setpoit changes, not Thermostat Manager (when I leave, it gets turned down...and then if I'm cold when I get home, I'll just turn it up ). I don't use "Away" mode at all--which reminds me that I do see a source of confusion among new users of away mode vs. HSM status, but that's a different issue.
But, in any case, modes are a blank slate and they are only whatever you make of them. This is just what made the most sense for me.
@bobbyD Thank you for your comment. I do use search for more obscure things in case I might get lucky, but by and large since HE is a moving target and the documentation and support content isn't maintained and up to date - I don't go there. It's like watching a video for Drupal 7 when I'm using Drupal 9. Sure, I might get a clue, but it just leads to more angst.
To you, this is like seeing a re-run - you've seen all this comments before. My manager would say to me 'so clearly you're missing something' if a topic repeatedly comes up.
However, I understand this is solidified but as I mentioned in the title (and this is the lounge area or do I misunderstand it's function?) I wanted to hear thoughts about the original discussion. Maybe you missed that?
I don't look at the community as purely a knowledgebase - I look at it as a living thing, with fresh faces and new ideas (and rehash of old ones). In the section of Lounge its topics are for discussion. In the Feedback section, I think it's comments about users experiences that may get read by HE staff for possible product improvements. Am I in the wrong place?
No, just wanted to point out that you could find the actual original discussion and tons of opinions already expressed, if you wanted to learn more about modes.
What you're missing is that much of the design of the hub originated through an effort to be compatible with the circa 2017 SmartThings (ST) hub. ST had modes. They were ill-defined. In fact, they were simply a global object that had names, and one could set "the mode" to one of those names. Most of our early customers, as well as our founding team, all came from ST, so this made sense to just copy.
Suffice it to say that in the ST world modes caused confusion for some. Some of us found convenient ways to use them, and the concept of doing different things with lighting based on the mode started. Many ST users found this convenient. There was no Mode Manager app per se in ST, but there were other means of setting the mode at either some time or based on presence. When we started Hubitat, Mode Manager was created to deal with this task, as we did not implement the means used in ST (called Routines).
Prior to Hubitat, Rule Machine had Set Dimmer per Mode, and I had an early version of Motion Lighting that also implemented Dimmer per Mode functionality. My home uses Motion Lighting as the predominant automation, and this particular aspect of lighting appeals to me. The layering in of departure / arrival functionality works for its purpose. But, modes don't provide a complete solution to the problem, as you have pointed out. However, they do provide a reasonable solution to a very wide swath of use cases. I doubt any design will be a good fit for all use cases.
So, yeah, modes are an odd thing. In some ways Hub Variables provides the basis for a more consistent way of dealing with these types of global values. Again, there are just a wide variety of use cases to be considered and dealt with. We always assumed that some inventive user could create equivalent or better capabilities by writing a Groovy app that does things some other way.
Modes as implemented in Mode Manager, Rule Machine and Motion Lighting are just an arbitrary convention. That's one of the fun things about developing for Hubitat, being arbitrary. And, having provided the means for anyone to be equally arbitrary for themselves, we encourage bright people to learn how to write Groovy apps. It's not difficult, and all of the ingredients to do modes in some completely different way are available.
With multiple people in the household working odd times and various shifts, day and night did not even come close to describing when we might need certain things to happen. I have a few modes, and they combine presence and time of day. So I have home and day mode along with home and away mode. Then I have a night and away mode, and a night and home mode. Finally I have sleep mode when we are present and want no lights or announcements.
These modes mostly control lighting events that should or should not happen at various times of the day. But I also use them to alert me (via Alexa's snooping mode Guard) of glass breakage and fire events that may happen when I am away, but don't care to have active when home. Or for things like "laundry done" announcements that should happen when we are home, but not during away or sleep. There are other similar events, but that gives you a basic picture.
I think others have used modes for things like "housekeeper mode" where all lights turn on when a certain lock code is used.
The neat thing is you can make up any mode you want, or use modes however you want to. Or not at all. Hubitat gives us a choice of how to use them.
As you can find from the discussions above, a common use of modes is to restrict or change automations based on mode (e.g., don't turn on lights with motion when away or in night mode, or change the thermostat set point when mode becomes away or not, etc.). Most apps have way some built-in to use modes, so that's an advantage they have over things you can also use, like hub variables or virtual devices that simulate a variable.
). I don't use "Away" mode at all--which reminds me that I do see a source of confusion among new users of away mode vs. HSM status, but that's a different issue.
