I have a quick question about Mode Manager. If I change away to Away-Day and add an Away-Night. Will Mode Manager restriction for away still work? I am worry that the (not when mode is Away) won't work anymore.
I have the same concern, and more than like it won’t work because Away-Day is not “Away”.
This app seems extremely limited and assumed a single chain of automated modes.
I still want modes to be hierarchical. There should be top-level modes like Morning, Day, Evening, Night, etc, and then child modes like Home, Away, etc. Then there should also be activity level modes such as Bath Time, Dinner, Asleep.
That way, the hub could be in multiple modes (or phases, modes and activities). I’m still trying to figure the best implementation of seasonal phases, since that is also largely ignored by hubs.
You’ll probably need to move your mode management over to RM to sequentially follow the appropriate chain.
1 Like
It should work. Changing "away" to another name will remove "away" mode from the system completely so you will never be able to be in "Away" mode anymore.
You can test your automation by changing the time to a couple of minutes from your actual time.
I guess I am asking for the mode manager to let me specify the away mode to use for the restriction. I guess I can use RM to the same thing.
Mode Manager is not designed with this in mind. It is designed for a simple linear set of modes. Once you go beyond that, you are superimposing a logic on modes that is not easy to manage, and certainly not doable with a simple app like Mode Manager. As there is no single agreed-upon method of superimposing additional logic on modes, it really isn't possible to extend the app to support it. Modes are very arbitrary. The only mode with special meaning for this app is Away, in that it prevents time-based activation of other modes. Given that you can name modes anything you want, having a single pre-determined mode that carries that significance does not impinge on any design of modes.
I would suggest that once Mode Manager feels like it's constraining your approach to modes, it's time to move beyond it. Either write your own app, or simply use Rule Machine to conjure up whatever logic you want. Mode Manager is no more than a shortcut way of handling the most common garden variety of mode treatment.
3 Likes
Understandable. Thanks for the explanation, Bruce.
Can you create new modes or change the current modes?
I really just would like a away, home or night/sleep mode.
I only need modes to be based on presence. If someone is home then home. If no one is home then away. If we trigger night mode (several ways to do that) then night
These of course would reference armed/away, armed/home, and disarmed.
I know some people like different options for day or night but I’ve always preferred just using times like sunset/sunrise in my automations.
Maybe I’m missing something and need to rethink. I’m more than willing to accept that.
You can add modes and edit modes on the Location page. Mode Manager works off your list of modes.
How do I set RM Rules based on these mode changes? For example, I want to have different behaviors for Away to Day vs. Away to Evening.
I tried this but I never get a text message.
That should work fine, unless you hit the SMS limit for that day of 10 messages.
Definitely not the SMS limit since the Goodbye rule I setup works fine sending SMS when I tested it after discovering this Welcome Home rule did not work.
I did some more testing and here's what I'm seeing:
I have 3 simple rules:
Goodbye
- Trigger: Mode becomes Away
- Action: Send SMS
- Restriction: None
Welcome home
- Trigger: Mode becomes Day
- Action: Send SMS
- Restriction: Only when mode is Away
Welcome home evening
- Trigger: Mode becomes Evening
- Action: Send SMS
- Restriction: Only when mode is Away
When Mode changes to Away all three rules get checked as seen in the logs. However, when Mode changes to Day/Evening only the Goodbye rule gets checked.
I think there may be a bug in the Mode restriction since that's the only difference I can see here.
Oh, I missed what you were trying to do. That won't work. Here is what happens: The mode changes to Day and fires the rule. It checks the restriction, which says only when Away. The restriction fails because the mode is now Day, so nothing happens. The other rule will fail for the same reason.
So Restrictions won't work for your use case. If you are wanting different behavior for when mode becomes Day (or Evening) based on it having been Away before, versus say Night before, then you will need to add some logic to do that. For example, in your Goodbye routine you could set the Private Boolean of the Welcome Home rule to false (it starts out True). Then, you use a triggered rule for Welcome Home instead of a trigger, like this:
Trigger Event: Mode becomes Day
Condition: Private Boolean is true
True actions: whatever you do for when it becomes Day but not from Away; set Private Boolean to true.
Fasle actions: what you want for Day after Away; set Private Boolean to true.
So in both cases, you are gong to reset Private Boolean to true. But it only gets set to false by your Goodbye routine. This way, that rule knows whether it became Day after Away or not. Evening would work the same way.
2 Likes
That worked perfectly.
Thanks!
Thanks for the explanation here. I am new but have some CS experience and even after playing with the hub for just the weekend I was able to glean that AWAY mode appears extremely limited.
Basically my problem is that I want to have two sets of lights A and B, one of which is controlled by time-based modes (say A is exterior lights), and another that is controlled by presence (say B is interior lights). I would like that control to be independent, because having exterior lights not change when I'm away would be a dead giveaway to rob the place.
The problem is that if A are triggered by modes, the status of A will never change when the mode is AWAY. The fact that it disables all the other ones from operating pretty much makes all the time-based modes extremely limited.
The only solution I can tell from this thread (and others) is to code/rule around it, but since the thread is 18 months old I figured I'd ask if this has changed or how people are getting around it. It seems that AWAY mode should be an independent mode from the time-based modes and that most people would want to use it that way.
Thanks!
This is not the problem you are making it out to be. Just don't use mode to control the lights that are supposed to be on in Away mode.
I've never heard anyone say this before, or suggest that AWAY should be independent from time. It doesn't make sense. Use AWAY mode for things that you don't want to happen when you're not home. Use times for things that need to happen irrespective of being home or not.
So, just to give you an idea, this is how I have my modes (AWAY and HOME) setup.
These are the modes that I have setup. I have home and away versions of each mode.
In Mode Manager, I have it switch modes based upon time and presence:
Then, for lights that I want to control via mode changes, I have RM rules to control that:
Using this system, I haven't had to touch pretty much any of my lights which need to be changed based upon mode. For all my other rules, it's a trival thing to put in an IF statement to check the mode and adjust accordingly. For instance, every room in my house is controlled via motion. So, for each of those rules, I either put an IF statement in checking that the mode is in one of the HOME modes OR I use the "Set Level By Mode" command and just specify the modes that I want the lights on or off in.
It looks more complicated than it really is and honestly, I've not seen a mode system in any of the smart home controllers (and I've used most of them that are out there) to date that is as powerful as the Hubitat system is.
Hey, thanks for explaining your set up to me. I ended up abandoning the away function in mode manager entirely because I wanted some "back from away" behaviors such as turning on a few lights regardless of time of day within 15 minutes of me coming home. Also it was quite difficult to implement all of it in mode manager as behaviors there were only triggered upon a mode change and couldn't be told to "be as you were" after doing something special. I ended up coding all of that in an "Away Rule" as well as "Day/Evening/Night" Rules, with the Away Rule triggered by a virtual switch that is controlled by Google Assistant.
I still use mode manager to rotate through the time of day modes, but have the rules check for the mode before deciding whether to run or not. This came in particularly handy in terms of coding cleanliness when I have:
if (restoring normal behavior = true)
Run Day Rule, Evening Rule, Night Rule
//where ideally only one rule would run to completion based on the mode.
I thought about putting in a geo-fence as a presence monitor but there are occasional follow-home robberies in my area so I figured I'd better use a voice trigger instead of having everything automatically open and unlock.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
