Can you add support for multiple modes?
example:
Mode #1 (time): day, evening, night
Mode #2 (presense): home, away, vacation
Mode #3 (other): enable, disable, arm, panic
So for say Cat Feeder or Sprinkler, i can set rules depending on Mode #1
for Lighting, i can use both Mode #1 and #2
and if need be, use Mode #3 do enable/disable all rules etc?
I don't understand your request. The hub can only be in one mode at a time. You can use Rule Machine to create rules that fire based on multiple modes.
Example, a Trigger:
Trigger Events: Mode becomes Day, Evening, Night
Action: Send Message Feed the Cat
etc.
Rule Machine also supports restrictions based on mode. So your enable/disable can be accomplished that way.
I believe he is asking for multiple 'Mode" global variables to exist, instead of just one.
I believe something similar can be done by creating 'compound modes'
For example:
Instead of just:
Day
Evening
Night
Away
One could create:
Day-Away
Day-Present
Evening-Away
Evening-Present
Night-Away
Night-Present
I am a firm believer in the KISS principle, so I choose to not overly complicate my modes. Of course, I am also not trying to fully automate my house either. I have been designing and developing real-time manufacturing control systems for 27 years now, and users always find new ways to break systems that we believed were fool-proof designs. Simpler is usually better! 
This is certainly NOT going to happen. Compound modes are a disaster from multiple perspectives. If that's what he's talking about, then a rethink of his approach is called for. Complexity in these systems is not needed nor advised.
Compound modes are a disaster from multiple perspectives.
How are compound modes problematic? Well, more specifically, how are they more problematic than what the hub does now, shoehorning multiple logical domains (time and presence) into a single variable? Having two state variables with clearly defined roles (time and presence) would be both conceptually and programmatically simpler to deal with in most cases.
This has been one of the (or at least my) ongoing issues with Hubitat's mode (and ST's before it): it's not terribly useful as it stands because it can only effectively describe one domain. Users frequently want the "mode" to describe multiple domains, like time and presence, and the default hub mode values encourage this. However, you'll quickly run into a wall when you still want the night time lights to come on or a sprinkler routine to run when no one's home. That problem leads to messy things like creating compound modes, which are more complex than having multiple state variables and also break any built-in mode-based functionality (since the mode values the hub understands aren't being used anymore).
Nothing today dictates what mode means. You can choose to use or not use Mode Manager as suits your situation. It reflects a common method of using modes.
To generalize a concept of "modes" into general purpose global variables that one could use in multiple ways, just as modes can be used in multiple ways, is not, in and of itself, an unreasonable idea. However, it is unwieldy for built-in apps to be be built around. There are numerous concepts inherent in the built-in apps that would become problematic, or at least much more complex: mode restrictions, rules based on modes, Mode Manager, Motion Lighting, Dashboards, Simple Lighting, etc. That's not to say that one couldn't dream up correspondingly more complex variants of all of these. But, that's a slippery slope and introduces significant complexity for most automations.
There is a principle here that striking a balance between ease of use, ease of explanation, ease of implementation, ease of support, vs generality of the abstraction model -- has merit. Some would prefer a fully generalized abstraction model that can do anything, to a simplified easy to use, though in some sense limited, abstraction model.
Perhaps there is a compromise position worth exploring: a location state variable that can be set and referenced from apps. This partially exists now, as an app can send and subscribe to location events. Some of these location events are 'built-in' (e.g. sunrise, sunset, mode) and have methods that access them (e.g. location.currentMode). What's missing for a generalized location state variable is the retention and access of current state, where location events could be the mechanism to set these.
What do you think?
Personally I would love to see this.. In the ST world I struggled to use mode to achieve multiple things like the other posters mentioned.. in the end I just wrote an app from scratch to do most of my automation and just used states to store "timemode" and "securitymode" etc.. so the ability to reference some location.state variables I'm sure would help some people..
Nothing dictates what it means, but the default mode values encourage users to setup automations based on the time of day and user presence. That makes sense -- those are two of the most useful properties for defining automations. It's maddening, then, when you immediately run into a wall, discovering that you can really only use the built in "mode" for one of those concepts, and you have to resort to coding for the other in every app individually.
Only having to respond to a single mode variable is certainly mechanically easier than dealing with multiple variables. However, that single mode variable is very limited in what it can represent, and trying to get it to represent multiple concepts (which even the default Hubitat config does) ends up creating significantly more complexity in other parts of the system.
The single variable doesn't really work particularly well for the built in apps, even for relatively simple use cases. If I setup lighting rules that I always want to run based on time-of-day (morning, evening, night), I can no longer use the 'away' mode. If I setup an alarm app that should be enabled when I'm away, then I'm going to break my lighting rules.
Some would prefer a fully generalized abstraction model that can do anything, to a simplified easy to use, though in some sense limited, abstraction model.
I think we differ on what counts as "easy to use". 
From my perspective, the current model is very difficult to use, although it may be easier to deal with in built-in applications. If I want to have some things respond to time, and some to presence, which the default mode values suggest is possible, I have to resort to compound modes or custom code, which is quite a pain.
Perhaps there is a compromise position worth exploring: a location state variable that can be set and referenced from apps.
Assuming 'location' == 'presence', that would work for me.
Another option would be to add support for arbitrary global state properties that any app could subscribe to (including RM rules). This wouldn't necessarily require any changes to the built-in mode-based apps (although it'd be nice if they supported at least time and location); those could still use the existing "mode" property. If users want to use "mode" they can, just like now, but they would also have the freedom to use other properties in external apps and rules.
This isn't true. I use Away with Motion Lighting, and RM. So I have light setting for Day, Evening, Night and Away (and others as well).
Most of the built-in apps do support both.
We are going to delve further into this subject. We have some ideas about how to do it. If we go down this path, Rule Machine would be extended to support it.
If I go away for a weekend vacation, no rules that work on a time-based mode are going to work because the mode is set to "away", and the mode can't represent both time-of-day and "away".
We may be operating on different core assumptions. I have a number of functions that I want to react to the time-of-day regardless of whether or not I'm home. If all of your time-of-day rules should stop when you're away, then the current system makes more sense.
Excellent, I look forward to seeing where this goes!
Nothing forces you to have them stop with Away. I'm missing something.
There is only one place that I am aware of where Away has any special significance, and that is in Mode Manager. But, Mode Manager is just an app that made that particular design choice. Other choices could have been made, that one was convenient for those of us that use the default modes.
And if you don't like that, just create MyAway, and use it instead of Away. Then there is nothing special about MyAway at all. Can be set by Mode Manager for presence, or time, or both.
It sounds to me, and I know I’d find it useful, if I could have a set of global variables outside of mode that I could use in RM or other Apps. Right now I use virtual switches as global Boolean, but it is kind of messy.
Just a thought.
Craig
If I have a rule that should change it's behavior when the mode is "day", "evening", etc., it will not behave properly if I've set the mode to "away" because, well, the mode is "away".
The problem is that there's only one "mode" variable and it can only be set to one value. If I want some rules that will respond to "away", and some rules that will respond to part-of-day, they can't all work all the time. If I set the mode to "away" and leave it there while I'm away, then my part-of-day rules will stop behaving properly because the mode isn't reflecting the time. If I want the mode to always representing the proper time, then my presence rules won't work.
That's what users end up doing now. It can work well enough, but it doesn't really help with the core problem of a single mode variable being too restrictive.
Say I have some rules that care about presence and some that care about the time of day, maybe one that does something in 'morning' and one that does something in 'evening'. Global modes seem like a convenient way to deal with that. Update some global modes, all the apps that care about the mode can respond.
If I have separate time and presence variables, then any presence-based rules only have to care whether the presence mode is set to 'away', and any time-based rules only have to care about whether the time mode is set to 'morning' or 'evening' (and any that care about both can look at both). Whatever sets the modes is also very simple; one function can toggle 'home' and 'away', and one just updates a time value.
However, if I have a single mode variable that I want to do double duty, now anything that uses the value has to parse different information out of it, and whatever updates it has be aware of all the types contained in the single state variable ('home-morning', 'away-morning', 'home-day', ...), or it has to be able to parse out just what it cares about (maybe the state variable is a serialized JSON value or something). In any case, it makes using the value much more difficult, and has the side effect of breaking built in functionality (like, Mode Manager isn't going to understand 'MyAway').
Of course, nothing says we have to use the mode for different types of things, but it just seems sensible to do so.
This is a good way to look at the issue. It's not that we necessarily need "mode" to be more complex, it's just that "mode" is the only global state variable we have, so extending its functionality seems like the natural thing to do.
So that's what we're looking at. Mode is just a single, arbitrary global variable, used in mostly arbitrary ways. Your example of needing more than one global variable is good. Then you could have multiple arbitrary ways to define things. I would see RM getting extended to support events and conditions on these global variables, and actions to set them, and probably restrictions based on their values also (just logically extending from mode to a generalized set).
We will get back about this as it develops.
Can I throw a spanner in the works.
With webCoRE you can define variables and associate them with modes.
You can set up what you want, to do what you want.
The permutations of things you can do are pretty extensive.
I've been reading this thread and cannot see what the big deal is because of what you can do.
Just my 2 pence worth.
I'm probably missing what you are trying to achieve but I'm also struggling to see the issue.
My interpretation is that Hub wide, there's the ONE global variable: Mode. Bruce is saying he can see the value of exposing more than one.. independent of what they get arbitrarily "assigned to."
That would benefit RM and WebCore in the sense that a RM rule can set a global Variable that WebCore reacts to. Today that interaction of Apps exists only via the ONE variable.
I think I'm over simplifying, but I hope I'm close to the mark.
This is not true. Apps can send and subscribe to location events.
sendLocationEvent(name: "MyEvents", value: "thisEvent")
.....
subscribe(location, "MyEvents", handler) or
subscribe(location, "MyEvents.thisEvent", handler)
This works now, and you can use it in apps. This is how an app can interact with HSM for example (how RM does). This allows apps to interact with each other arbitrarily. What is missing from this is being able to determine the current state of "MyEvents". This is what we are considering adding. Then you'd be able to fetch the current state like this:
if(location.MyEvents == "thisEvent") blah blah blah
What's missing is the instantiation of the inferred location variable that corresponds to the location events. You could sort of work around that meanwhile, by sending an event to the source of MyEvents that it subscribes to, causing it to send an event in response with the current value. Like this:
sendLocationEvent(name: "WhichEvent", value: null)
.......
subscribe(location, "WhichEvent", handler)
...
def handler(evt) {
sendLocationEvent(name: "MyEvents", value: "$currentEventName")
}
Everything about this sort of location event is arbitrary, the name and the event values. They have whatever meaning the apps involved ascribe to them.
It's worth pointing out that Mode is also a location event, except it does have the inferred variable instantiated.
setLocationMode("thisMode") sends a location event equivalent to
sendLocationEvent(name: "mode", value: "thisMode")
And the current value of "mode" can be had with location.mode
One subscribes to mode with
subscribe(location, "mode", handler) or
subscribe(location, "mode.thisMode", handler)
Am I missing something here?
This seems really complicated...
I use 4 modes
Morning, afternoon, evening, night
I have a virtual switch to signify home/away
So.. if it’s evening AND the switch is off..(I’m away) do something (or not)
I use Presence Central to group presence sensors to decide if we are at home or away.
Perhaps I’m oversimplifying the problem
Andy
Yes, they are looking for a more generalized capability, which is implicitly more complicated. There are other ways to do the same thing. But, this proposed new feature does not require the use of virtual devices as state holders.
Download the Hubitat app
