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.
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.
Interesting thread. I as about to start a new one that would have run this same course.
I was going to ask for a separate global setting akin to Mode called Mood. The Moods could be used to determine things like Party (self explanatory), Friendly (Guests present), Empty (Away), Quiet (mute).
As I use Mode to delineate Morning, Day, Evening, and Night I'd like another global setting for behavioral based rules.
I look forward to this future global variable you speak of.
While not as elegant as an additional global variable, you could use a Virtual Dimmer as a way of doing this. You would need to keep a lookup table handy to know that a Dim Level of 1 = Party, 2=Friendly, 3=Empty, and 4=Mute. And, you would still have another 96 values available! Logic based on Dim Levels is already available, so you could implement this today if you wanted to.
That is clever, but would be a pain to implement widely. I don't want to have to look up each mood number when making a rule or adding a feature.
I'll stick with the hodge-podge of duplicate rules based on virtual switches until the global variable update. At least with the virtual switches they have friendly names. But I like your line of thinking.
Hmm, so my outdoor lights won't go on in the evening if we are away? I guess I'm just now realizing this. In my scenario thats obviously what is wanted/intended. I'm using Simple Lighting and have it turn on the outside lights when mode changes to evening and off when it changes back. I looked at using time to turn them on instead, but then they cant be turned off with the mode change to night. So now I have two SL rules one to turn them on and one off avoiding the Away mode all together.
Hi There! Dunno if this is the right thread for this question but I'm new to Hubitat and I'm trying to migrate most of my smartapps from ST. I've been facing several incompatibilities with what appeared to be bat habits in my coding and hubitat environment, so far. But now, I'm perplex since it appears a simple request into a list of modes doesn't seem to work:
I have this:
def currMode = location.currentMode
boolean inRegularModes = currMode in modes
While current mode is "Day" and "modes" returns " [Day, Evening, Night]", the test "inRegularModes" returns false... I'm sure this is another obvious thing I'm not seeing and maybe I should think of getting some sleep... Let me know if you see what's going on here because It's one of those times when you spend hours on things that always end up being a type somewhere...
Thanks in advance.
Thank you for your answer. For some reason it seems to be working now... dunno what I did. It was due to something in my code because I noticed it worked in any other app code... But I don't remember doing anything beside changing all "in" by .find{it == currMode} then went back to "in" (after I saw from a test in a different app that it had to work) and now it works... Mystery.
I'm also interested in if there were any updates to this (maybe that weren't captured in this thread?) I would imagine the option to add global variables could be handy for those who choose to add them.
I think it's only natural for folks to want dual or multiple concurrent modes. The fact that you can add multiple custom modes, combined with the fact that you can set these modes based on different kinds of triggers, e.g. time of day, presence, etc. makes for a natural logical leap that you should be able to have a state that is in multiple concurrent modes.
I don't see why this is problematic programmatically. A simple object called "current modes" can serve as a container where modes can be added such as in a list object. Later the contents of said list object can be used in comparisons (e.g. if modes.away in "current modes" then etc. etc. etc.)
I would like to add my vote for this Feature Request.
I was looking for the same thing but, a global variable was all I really needed. I use the Simple State Machine app to manage what actions to take when multiple modes I in effect.
I use the built in modes for time of day and a global for each room to track the mood of that room, normal, movie, party, and cleaning. I've never implemented the 'Away' mode, this is working pretty well for me.
Logic based on Dim Levels is already available, so you could implement this today if you wanted to.
