Conceptually something like this should work.
Edit: %value% is a pre-defined variable which contains the value of the trigger event. There is also %device%, %date% and %time%
Reading this may help
1 Like
The rule @jabecker provided is using virtual switches to keep track of the previous mode. @JNS is using variables either should work for what your trying to do.
Okay, I tried the switch route and here is what I have so far. It still doesn't work. When I said that I can't figure it out, I meant that using Rule Machine to write rules is not intuitive. I will catch on but I come from Smartthings and Iris before that. Those systems are/were pretty intuitive.
In order for the rule to work this way the ELSE-IF would need to be ELSE-IF (Mode is Day AND Switch Away is ON). You wouldn't need the IF (Switch Away is off) in this case.
I think it would be easier with a local variable but that is just personal preference. Either way will work. There are multiple ways to do almost everything. You just need to find out what makes sense to you and run with it.
What @JNS said and you should have an endif at the end of it to close the whole if statement.
2 Likes
There should actually be two 
Not if he gets rid of the if Switch Away which shouldn't be needed.
1 Like
Can't argue with that.
It definitely takes some getting used to the RM interface especially when your trying to add a section in the middle of a complex rule and have to keep finding where the next line needs to go since it won't keep inserting in the middle.
The reason I think it's easier to use a variable here is twofold.
-
You don't need to create/manage the virtual switch
-
You will need to manipulate the virtual switch whenever the mode changes from Away. If you fail/forget to do that in another rule this rule will not work properly. If Mode goes from Away to Night for example and you don't have a rule to catch that.
If you were to capture the previous Mode in a Global variable, I used a Local variable in my example, you could use that in other rules as well.
Here is what I have so far. Still doesn't work and it is not turning the switch on and off or unlocking the door. At least I am learning. I have to run out for a while so any more attempts at this will be later tonight.
The ELSE-IF needs to check if Switch Away is ON not OFF. You would then turn the switch OFF after you check to see if it's already ON.
1 Like
One problem you might find with your rule is that you turn Switch Away off, and then have an IF statement to check to see if it's off. That IF will always be true. You probably want ti check to see if it's ON rather than OFF, and then set it off after the IF. I think you want something more like this. You should also get in the habit of always closing your IFs with END-IFs. If there are no statements following, the END-IFs aren't strictly needed. But they keep things neat and tidy and make the rule easier to read. If anything outside of the condition follows an IF, then you absolutely need the END-IF for the rule to execute correctly.
Trigger:
Mode becomes *changed*
Actions:
IF Mode is Away THEN
On: Switch Away
ELSE-IF Mode is Day THEN
If Switch Away is On THEN
Unlock Deadbolt Mudroom Door
Off: Switch Away
END-IF
END-IF
On the virtual switch vs variable debate... I use virtual switches because I've found that they're handy to use in other rules or apps. For example, I can use a routine in Alexa to trigger a mode (i.e. "Alexa good night"), I can use an Away switch in Mode Manager to trigger a mode, or in Motion Lighting to keep a light on/off even if there's motion. I can also refer to them in other rules. You can use local variables only in the rule they are a part of, and that works fine if you don't need the information that switch carries anywhere else. There are global variables in RM also that can be used in multiple rules. Global variables cannot be used outside of RM. And, they may slow your rule down because, as I understand it, they have to call the parent RM app rather than staying local within the rule.
Of course, this is just my preference. There are many ways to skin this cat, and any of them will work fine. It just depends on what your use case is.
I used to have one gigantic rule that did absolutely everything anytime a mode changed. It was very complex and long, and editing it was not only a real hassle, it was really slow. I broke it up into one rule for each mode, and that's worked great. But for a relatively simple rule like this one, you should be fine including more than one mode, like I did in the first example I posted above.
1 Like
My intention was not to start a debate, just offering alternatives. All of your points are valid.
To quote myself
2 Likes
I didn't think you were starting a debate. Sorry, poor wording on my part. I just thought I'd offer a slightly different perspective.
As I said:
Your points, of course, are also valid.
Peace. 
1 Like
Did I mention that there are a great many ways to use Rule Machine to accomplish any given task? 
4 Likes
If your modes are already changing based on presence why not just create a rule to unlock your lock based on presence as well? Something as simple as this should work:
For your alarm status lights you could do something like this:
Like Bruce says there are many ways to accomplish any given task.
1 Like
I think this is one of the "problems" with Hubitat. There are so many ways to do almost anything you want . . . people get lost just trying to figure out which to use. The more experienced users love this "problem". 
1 Like
This looks like it might be the simplest solution. I am going to try these. Thanks.
Thanks for everyone's help. I am off and running now. Turns out most of the rules that I wrote would have worked if I had used the correct trigger or tested them with the trigger that they were written for. I was using mode changes for the rules and then arming the alarm that corresponded with the mode. As we all know modes turn the alarm on not the other way around. Once I had that straight, I was able to duplicate all of the rules that I had previously used on other systems.
6 Likes
