Need help with a simple rule

Rule Machine®
#1

I have just moved about 200 devices over from Smartthings and the Rule Machine is frustrating me to no end. I just need to set up a few rules that were very intuitive in Smartthings. Here is what I want to do. I have Hubitat set to go into away mode and lock all doors upon departure based on presence. I am trying to build a simple rule that Unlocks a certain door when the system goes from Away mode to Day mode. It seems like it should be easy but nothing that I have tried works. What I am looking for are rules that look like this:

If in Away mode and changes to Day mode Unlock Mudroom door.

I also want a rule that looks like this

If in Night mode and changes to Day mode turn off Hue Bloom and Hue LED Strip.

Please help, I am extremely frustrated over my inability to generate such simple rules.

#2

First of all, welcome to this community!

The modes like Day, Night and Away etc. works like a single global variable and can be used both as a condition and as a trigger. Now I do not know how you are altering between these modes, but I would suggest to use the built-in app called Mode Manager. You can have a look at Hubitats official Youtube channel here with suggestions how to set it up: YouTube

In your examples you are choosing to use turning on Day mode as a trigger and that would be fine, but the issue at hand is that you also would like to have different actions depending on the previous state and it's here when it becomes tricky. You could probably store the previous state as a local variable within the rule itself or with a virtual switch, but I think that it will be to overcomplicate the rule... or maybe rules.

My suggestion would therefore be to create on rule for unlocking the door when arriving, and a second rule when the mode changes from Night to Day when you are present.

1 Like
#3

I do something similar — do something if the mode changes only if it was a particular mode before — using virtual switches. You'd maybe need two switches: one for away and one for night. Something like this might get you started.

Trigger:
  Mode *changed*

Actions:
  IF Mode is Away THEN
    On: Away Switch
  ELSE-IF Mode is Night THEN
    On: Night Switch
  ELSE-IF Mode is Day THEN
    If Away Switch is On THEN
      Unlock Mudroom door
      Off: Away Switch
    ELSE-IF Night Switch is On THEN
      Off: Hue Bloom, Hue LED Strip
      Off: Night Switch
    END-IF
  END-IF
2 Likes
#4

Thanks Carl. I am changing the mode with presence. All of that is working. Honestly, I just can't figure out how to write the rule in rules machine. I have read the documentation but it still isn't clear how to get the rule. I am about ready to try Sharptools but would prefer to stay away from a cloud solution.

#5

Rule Machine has so many caveats and flexibility you have to be more specific than "i can't figure it out"

Is it the trigger you are having issues with? Actions? Conditions? Can you post a screen shot of what you have so far?

Also to note, Mode Manager might be too simplified for what you want want to accomplish since you can't reference what was the mode if Mode Manager makes the change

#6

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%

image
image.png769×502 32 KB

Reading this may help


1 Like
#7

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.

#8

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.

Capture

#9

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.

#10

What @JNS said and you should have an endif at the end of it to close the whole if statement.

2 Likes
#11

There should actually be two :grinning:

#12

:slightly_smiling_face:Not if he gets rid of the if Switch Away which shouldn't be needed.

1 Like
#13

Can't argue with that.

#14

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.

Rule Machine 'insert action before' perpetually
#15

The reason I think it's easier to use a variable here is twofold.

  1. You don't need to create/manage the virtual switch

  2. 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.

#16

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.

Capture

#17

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
#18

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
#19

My intention was not to start a debate, just offering alternatives. All of your points are valid.

To quote myself

2 Likes
#20

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. :v:

1 Like

Download the Hubitat app