So, is the thought to use one or more ‘global’ variables that could be accessed by more than one app at the same time
That would be a brilliant idea!
Andy
In effect yes. Mode is the only such variable right now. By adding the instantiation of arbitrary location events (i.e., storing the value in the database for later retrieval), then there would be an unlimited number of such variables. The only thing sort of odd about them would be that one sets the value by sending a location event. But that actually makes a lot of sense, because some other app that references the variable would probably be interested in the fact that its value changed.
2 Likes
sorry, i should have been more clear.
what i really need is global variables and i thought mode would be a great place for it.
Mode is a global variable, the only one. We are planning to add global variables beyond mode, as described above.
1 Like
thank you 
@bravenel can i request in mode-manager "set mode based on time of day" while not away. i would like it to set mode at time of day on certain days only if a presence sensor is there. I sometime work at home so when the mode goes to home in the morning when my wife gets up, if i'm still at home past another time i put the house into work at home mode. I currently do this with WC but if it was in mode manager i could remove that piston.
edit: this could also have a restriction on for other stuff IE I would like home mode to happen at 8am mon-friday unless a holiday switch is on when i want it to be at 8:30 like it does on sat and sun
I don't understand what you're saying. The only time that setting mode based on time of day does not work is during Away mode. You wouldn't ordinarily be in Away mode if there is a presence sensor there.
In any event, if you need a more subtle or special mode set logic, you can use a rule in Rule Machine to do it.
yes this is correct and what i am after but this just works when anyone is at home (so the mode isn't in away) what I meant was to be able to say go to a mode only if a particular sensor is at home.
So house is in a mode other than "away" because people are there, then at a particular time on a particular day if presence sensor A is present go to mode X if they not there do nothing.
You should be able to set this logic up in a rule or a triggered rule. Periodic could give you a trigger event for "particular time on particular day", and the conditions to test would be mode is any mode except Away and presence sensor A present. Action for true, set the mode to X.
@bravenel i think i have found a bug with it and i think i also know what it is. When i try setting this up it seems to stall and you need to refresh your browser to get it working again. But as soon as i click this page again the same thing happens.
I think its to do with the @ as it only happens on this mode.
when you click it then try to exit or save it it won't do anything
I suspect that @ is a special character that you cannot use in a mode name. We recently changed some things to allow a bunch of special characters, and most likely that is not one of them. Just change to something other than @.
This is great news. I've been bashing my head around trying to figure out a solution using modes for what I need. I like Andy's suggestion of using switches in the interim, but that's only a boolean value. I'm used to being able to set [arbitrary] global variables with the usual data types; string, interger, boolean, etc.
The transition from the Fibaro HC2 to HE (pretty much bypassing ST too so don't even have that experience) is a challenging one. But I can see the long term benefits even if my short term plans are a challenge.
I'm hoping much of my use cases for global variables have disappeared with improved presence capabilities (setting counts in and out of rooms from motion sensors to see if anyone was in the room before lights out... ball ache!), but I guess time will tell.
@bravenel Any update on multiple globals / multiple modes (mostly just distinct time and presence modes)? Mode Manager keeps making me think how handy it would be to change modes based on time and presence, but it doesn't really work very well with the current single-variable solution (at least I can't think of many situations where I'd want to essentially disable anything that depended on time-of-day modes whenever I left the house).
Look at 'Presence Central'
If you use this in conjunction with my virtual switch idea then you can do all sorts of things with modes and how your apps run etc.
One of the things I do is use a virtual switch called 'All Speakers' (obvious what that is for)
I use PC to switch that off when we all leave - If anyone is at home then it's on
I base all my spoken messages on this switch being on... if it is off then they say nothing
Simples! 
Andy
1 Like
There is always a temptation to make modes into something more than they are. Huge complexity lurks in this, automation complexity. Modes could quickly become multi-dimensional, taking into account HSM arming state, presence conditions, time conditions, weather conditions, etc.
A good general principle to keep in mind as you design your automations is the KISS principle. This works much better and is more reliable than complexity. With complexity, if any little thing is off, the whole complex mess becomes unhinged, and WAF goes down the tube.
3 Likes
Yeah, I'm currently using a rule and 'rule truth' for presence, and I've used a virtual switch in the past. It's simple enough, but I just can't get around the feeling that this core feature of Hubitat, Modes, would be the most elegant solution for this kind of thing.
I completely agree with you, I just think we disagree on what counts as "simple". 
I mean, using only a single variable to handle time and presence is simpler for the case where you're fine with your time-based rules stopping when you leave the house. However, that's not the general case, and I'd be surprised if it's even the most common case. If you want to use modes to manage time-based things and presence based things, you end up dealing with significantly more complexity than you'd have with separate time-of-day and presence variables (you end up with Day, Day-Away, etc., and you have to deal with all of those distinct values in your rules). This extends even to the built in apps; consider that Mode Manager's "return from away" logic is only necessary because it has to shoehorn time and presence into a single variable.
I'm not advocating for a generalized global variable system. Really, time and presence seem like a fine core set of properties for the hub to work with. The built in Mode system would just be more flexible and generally useful, while remaining just as simple to work with (and simpler to code for) if those two properties were separated instead of managed by a single variable.
1 Like
Wouldn't this be the best solution?
It would be, yes, but I feel like there's been resistance to that idea, so I'm trying to scope my goals.
This is exactly the problem right now, and what would be solved by keeping mode variables scoped to a single domain. As you say, different rules care about different things, like HSM arming state, or presence, or time-of-day. If those concepts are managed using single-purpose variables, it's very easy for apps and rules to pay attention to only the modes that they care about. When those concepts are combined into a single variable, then every app or rule that wants to respond to them has to understand every possible value that the single mode variable might take (away-day-hsmArmed, away-day-hsmDisarmed, etc.). This is obviously not scalable.
The current Mode system sidesteps some of this complexity by forcing the mode variable to itself be in either a time-based or a presence-based mode. That does keep rules and code relatively simple by scoping the possible values of the mode variable, but it's conceptually more complex than simply having separate time and presence variables would be, and it also requires that the mode system give up some functionality (it can't represent away-day vs away-night without significant effort on the user's part, and a lost of functionality in built-in apps like Mode Manager).
There is no "Mode system". Mode is simply a global string variable. What you do with it is up to you.
Mode Manager creates something of a system using that variable, but that is simply to help people out who have the simple uses for Modes (like myself). Mode Restrictions in apps offer a simple means to restrict an app, but don't dictate anything about what modes are or how they are used. Other than Mode Manager, modes can pretty much be anything you want them to be.
Having said that, having only one such global string variable is quite limiting. We have spent considerable time and effort on this subject, and may provide something in the future to extend it.
True. <Gets off soapbox>
