Rule Machine - Get peer assistance here with setting up rules

rulemachinelogic

(Jason "The Enabler" as deemed so by @Smart) #940

@Marc_Tremblay

Did this work the way you wanted it to?


(Jay M) #941

Sorry for late reply. Been extremely busy

Since your Motion is inside try this
Condional trigger: contact open
Condition: Motion inactive
Rule: Motion inactive true
true: Delay 4 sec cancel
trigger alarm
False: leave blank

Place the contact you are having issue with as trigger.

Place the motion detector as the condition
the delay is for the delay in this system.

does this make sense.


(ocpd+adhd+alz+md+hfa+fms+lol=me :)) #942

I have a question about what’s possible…

I created a group of virtual/simulated switches to mirror my SmartThings system’s ‘Modes’ (i.e. when the system is in ‘Away’ Mode, turn On the Away Mode virtual switch, and turn off all of the other Mode virtual switches.

Now, I want to create a rule (or set of rules) that will manage this set of virtual switches for me.
Is it possible to do all of this within a single, complex rule, or with something like this, would there need to be a separate rule for each one of the Mode virtual switches?


(Jason "The Enabler" as deemed so by @Smart) #943

I did the exact same thing. After you using yours in rules to change modes manually?

I have a pretty complex setup in RM with my modes. I can upload it here if you want.


(ocpd+adhd+alz+md+hfa+fms+lol=me :)) #944

Yes. I’m not sure whether or not it will apply directly to where I’m at in my process, but anything that can act as a guide for future refernece, please do post.

For the short-term, I mainly want to know this…In your setup, do you have a single rule to turn all of your Mode switches on or off, or do you have a separate one for each Mode?


(Jason "The Enabler" as deemed so by @Smart) #945

Ok, this is what I have…

I made my virtual switches “virtual momentary button tile”. This way when they are pressed they turn themselves off and it’s one less thing for the next rule to worry about doing.

I have a separate rule for each. Except for my day/Weekend Day. That’s in one rule.

Ice kept the mode controlling rules very basic. They only set the mode and send a notification. I cheated a routine rule to handle any other actions that occur at the mode change.

I did this for stability and reliability… And it’s been almost 100%.

This is the spreadsheet I use to keep track of all of my automations.

The only problems I’ve had with this setup occurred in the last two days. When the house changed to night mode, it would not send the notification and it would not display that it was in night mode… But it actually was. All of my night mode only automations we’re working. I sent a ticket to support and they said it is a bug.

I deleted and rebuilt the rule last night, we will see if that fixed it tonight.

But that is the only problem I’ve had with mode changes since I set this up.

Edit:
I tried to do the complex rules at first, but they didn’t always work with the platform issues.
But with the modes, it’s pretty much one or two modes per rule.


List of Tasks for Devices?
(Jason "The Enabler" as deemed so by @Smart) #946

Continued from other thread…

@twodaend. Take a look at this spreadsheet of how I set up my rules. My automations have been pretty rock solid even through the meltdown.

Use this as an example for ideas on how to build your system.


#947

@twodaend

I would start off and keep things simple with the rules. It might get repetitive but I think that’s okay. After you start to get a handle on all the various options available, you can start to think how to combine some of the rules together. Just my two cents.


(ocpd+adhd+alz+md+hfa+fms+lol=me :)) #948

[quote=“bamarayne, post:945, topic:29577, full:true”]
Ok, this is what I have…

I made my virtual switches “virtual momentary button tile”. This way when they are pressed they turn themselves off and it’s one less thing for the next rule to worry about doing…[/quote]

So, in this case, there is never really a stored state of Modes in your virtual switches, right?
If that is the case, I’m thinking I still want to have my vswitches for this be normal, on/off switches so that the state of the Mode is always reflected in the switches.

Is there a specific reason (well, other than the fact that ST is not stable enough to count on anything right now…I know…we’re all waiting and hoping for it to mature, etc, and I am being patient…so, not a dig on ST, but just the facts of the moment) why you think it would be better to use momentaries instead of on/off switches?

Thanks again. I think I recall you posting this one other time, but I still haven’t actually gone there and started in on it on my side yet. I think it’s getting to the point where I probably should. I mean, I do have some notes and stuff, but doing it up like this makes a lot of sense. So, thanks again! :slight_smile:


(Paul) #949

Air Conditioners (especially large systems) are most efficient when they run for long periods of time. Assuming you don’t have any pets or sensitive house plants to worry about, the most efficient option is to turn your system off when you leave, and turn it back on when you arrive home.

If it takes a long time to cool your house when you return home during the summer, the best thing to do is start cooling the house when you leave work. There are lots of ways to automate this, or you can just remember to turn on the A/C with the Ecobee app.


(Jason "The Enabler" as deemed so by @Smart) #950

I went with momentary buttons because the action only occurred at the beginning of the mode. I algae used triggers and conditional triggers in my mode changes. At the next mode change I didn’t have to worry about turning off the other switch to disable the rule.

For example - using switches.
You are in day mode, that switch is on. You go to evening mode automatically, so that rule must now turn on the evening mode switch AND turn off the day switch.

Example using buttons -
You are in day mode. The button is normally of. The evening button is pressed by the rule for mode change. That is the only action it dies. It does not have to turn off the day mode switch.

Here is where that really matters…

You are in day mode, using a switch. You want to manually go into away mode. So, you turn on the away mode switch. Normally evening comes after day, so the evening rule is programmed to turn off the day mode switch. But your away mode switch isn’t. Now you have two switches active that conflict.

Out, you have to program every rule to turn off every switch, even if the switch is already off. More actions, more clutter, more chance for screw ups.

Using the buttons, nothing had to be programmed to turn off.


(ocpd+adhd+alz+md+hfa+fms+lol=me :)) #951

[quote=“bamarayne, post:950, topic:29577, full:true”]
I went with momentary buttons because the action only occurred at the beginning of the mode. I algae used triggers and conditional triggers in my mode changes. At the next mode change I didn’t have to worry about turning off the other switch to disable the rule…[/quote]

I’m sure you’re right about this, and I’m just needing to go through my own learning process (and will likely end up where you’re at), but…

If the whole reason I’m doing this is to help ensure that my Mode is actually in the state that I want it in, then it seems like the added coding up rules to do all of this is worth it (granted, the current system instability may be an issue here with having so many different kinds of things needing to fire all the time).

Are the only ‘drawbacks’ like this?..

  1. lots more rules and actions in the rules to do it with switches than with buttons
  2. more things needing to fire in the context of the current ST system instability could bring more trouble than help

Is there anything else that I missed as major drawbacks or pitfalls of using switches instead of buttons?
Not to say those two aren’t enough to make me change my methodology, but just wanting to make sure I have the whole picture you’re offering before I proceed. :slight_smile:


(Kavvy) #952

I’m pretty sure the Ecobee is smart to the point where I have a target temp AT at a target time. So I typically get home by X, my schedule for ecobee is temp Y by time z. Z being a time before I could arrive, and ecobee calculates temp and time, to ensure it kicks on early enough to meet time and temp.

Maybe I just need to revisit my rules.


(Jason "The Enabler" as deemed so by @Smart) #953

1 - if you keep your mode changes and routines separate you will use the same amount of rules either way. If you combine them, you will have less rules, but much more complex rules.

2 - I programmed my modes like this back in Dec or Jan, before the meltdown. (Which, according to yesterday’s announcement, is where we are back to. I understand the system is now as it basically was in Jan. We will see.) I had originally combined ine into large complex rules. I found that I was randomly missing actions sometimes, kind of like only part of the routine completed. Which is exactly what it was. It was exceeding the app run time limit and being dumped by the server before completion. A lot of the time, it was the mode change itself that got dumped.

After setting it up this way, I have had no problems. I don’t even check my modes anymore because it’s been so solid… And that’s with the last month’s fiasco.

My advice, do what works for you. Every setup is unique and special. What works for me, may not work for you and vice versa? So, experiment, learn, and come up with what’s best for you.

When you look at the spreadsheet you will see the automations for my master suite. Somewhere around 20 rules for that space. But, it’s like it is because my wife and I like things entirely different. So, it has to have built in controls, overrides, and ease of manipulation. So, I built it that way. It could be done in half that if my wife would just like what I like the way I like it! Lol


(Fast, Good, Cheap...pick two.) #954

I do a spreasheet as well.

Once you get everything organized you can see overlap and places where you can possibly consolidate rules.

As with @bamarayne findings, there have been times where I’ve combined rules and triggers and didn’t seem to get the execution that I did with separate rules / triggers, but I can’t say I’m 100 positive it wasn’t some sort of system issue going on at the same time that made me think it was due to my combining rules.

Initially I had a hell of a time with Rule Machine…going back and forth between it and Smart Lighting…because I thought I wasn’t doing something right with Rule Machine. As it turns out I was experiencing platform issues all along.

Case and point why Bruce yanked the plug on his unprecedented support.

Anyway, I got off track there. I am still experimenting with multiple small singular rules vs. more complex fewer rules. It may be a YMMV thing.


(ocpd+adhd+alz+md+hfa+fms+lol=me :)) #955

[quote=“bamarayne, post:953, topic:29577, full:true”]
1 - if you keep your mode changes and routines separate you will use the same amount of rules either way. If you combine them, you will have less rules, but much more complex rules.

2 - I programmed my modes like this back in Dec or Jan, before the meltdown. (Which, according to yesterday’s announcement, is where we are back to. I understand the system is now as it basically was in Jan. We will see.) I had originally combined ine into large complex rules. I found that I was randomly missing actions sometimes, kind of like only part of the routine completed. Which is exactly what it was. It was exceeding the app run time limit and being dumped by the server before completion. A lot of the time, it was the mode change itself that got dumped…[/quote]

OK, so…I get the part about the differences between whether to use fewer more complex rules or more simpler rules. That’s not my question here now.

What I meant to ask was this…

As far as you see it (acknowledging that I agree that we may each find ways that work better for us; here I’m just trying to see if I understand your take on the difference between using switches or buttons), are the following two things the only things that seem problematic (or in some way, potentially problematic) with me using on/off switches as opposed to momentary buttons?

  1. lots more rules and actions in the rules to do it with switches than with buttons
  2. more things needing to fire in the context of the current ST system instability could bring more trouble than help

Is that it, or are there other issues to think about in the context of whether to use on/off switches -vs- momentary buttons?


(Jason "The Enabler" as deemed so by @Smart) #956

Ok, I’m sorry, I thought you wanted me to explain my thought process…

Yes, I see, and have seen, both of those as potential problematic scenarios.


(Ed) #957

@bamarayne

Thanks for the spreadsheet. This looks great. I’m trying to follow the logic and used the bathroom as an example. I tried creating my own, but something is not right.



(Jason "The Enabler" as deemed so by @Smart) #958

@twodaend

Master Bath Lights:

  • the Actions for True and Actions for False are exactly the same. Change the Actions for False to making the Master Bath Lights - Night rule True.

Master Bath Lights - Night:

  • Actions for False - Remove the Delay by 30 seconds and choose
    Pending Off: Bathroom Light: 30 seconds:Cancellable

Note - Turn off the enable/disable with private boolean option until you get the rules working. I’m not sure this will work when using the private boolen as the on/off for the rule. I’ve actually never done it that way as I choose to use a virtual switch or physical switch for my disable.


(Ed) #959

Thanks @bamarayne. Sticking with the bathroom example, I see you are using an Override switch. Could I ask, what physical switches you are using? I know how to create VS and I guess I could use that to disable but not sure how to do it with a physical switch. I’m using the physical GE toggle switches (12727 & 12729).

Side Note: Although I like them, trying to get 2 of them to fit in a 2 gang box is giving me a headache. My switch boxes have a mud ring around them making the width a bit too small especially the corners.