My use case is for my walk out basement. I have a motion sensor downstairs in the basement and contact sensor on the basement door that leads downstairs. I want the light to turn on when I open the door and then turn off if there is no motion after a few minutes. I also want the light to turn on if motion activates (say I enter from the backyard), and again, turn off if there is no motion after a few minutes.
Having the trigger turn on the light and evaluate the motion rule seems to work. When I open the door, but donāt go down the stairs, the light still turns off after a 3 minutes.
There's a difference between a trigger and a condition. A trigger pushes an event once when a state changes. A condition is continually evaluated. The difference between saying "door IS open", and "door CHANGES TO open".
I have a case like this leading into my basement. If one of the two basement doors is open, light comes on. There are two motion sensors to detect motion on the steps. It's possible to open one of the doors and not trip either of the motion sensors. If I close the door, the light will still go off because it's evaluating the condition of the motion sensor, not waiting for a trigger.
(You'll notice this rule is written "backwards" intentionally)
This is pretty much what was suggested earlier. The reason this did not work for @jrau272 was because he wanted the light to turn off even if he never closed the door after himself. In the scenario above, the door being left open would cause the rule to always evaluate to false and never execute the True rule. This was why I suggested 2 rules. A triggered rule for the door that then evaluates a standard rule for the motion.
Your description of the use case didn't include this detail. If you open the door and never trip the motion sensor, there has to be some other logic that turns the light off after 3 minutes.
No, this is not true. A condition is evaluated when there is a change of state of any of the conditions -- not continuously. Rules are entirely event driven. While an event other than a particular condition may cause the evaluation, when that happens it will examine each of the conditions, and the rule, to determine rule-truth. If rule-truth has changed, the appropriate actions happen.
So it only does the action if the truth has changed. I thought that if I forced the evaluation of a rule it would simply execute the corresponding action.
Let me know if I'm understanding this correctly
Rule A is currently evaluated to False
Rule B forces an evaluation of Rule A
Rule A is still evaluated to False
Are you saying that the False action for Rule A will not be executed because there wasn't a change in rule-truth?
Yes, if you run a rule from another one, it does not pay attention to truth change. It just runs the rule.
So that is the solution to the 3 minutes lights off from opening the door but not going in. That trigger needs one more action: Evaluate the motion rule, assuming the false part has a 3 minute delayed off. Should motion happen in the interim, the lights stay off until motion stops.
If you just turn the lights off in 3 minutes after the door opens, it would ignore motion,.
Not really, it's more like a condition -- that is the rule has to evaluate to true or false, and have changed state.
But, a triggered rule is similar to running a rule from another rule, in that the rule part ignores truth change. It just evaluates when the trigger fires.
Each of these variants have their place in building automations.
Rule Machine is like Lego blocks, while webCoRE is like Master of the Universe. You can do anything with either, but it takes a different thought process for each. For Rule Machine, you break things down to their primitive elements and build up from there, using multiple rules as needed.
One thing that shows up frequently is the need to separate on logic from off logic. Sometimes they go together into one rule, but not always. By definition, if in one rule then the off logic is a mirror image of the on logic -- it's the on logic negated. Like if X then do true stuff, and if NOT X do false stuff. But lots of automations are nice and symmetric like that. So you separate the two halves.
Thanks for taking the time to educate us tonight Bruce. My brain hurts, but I learned a few things tonight. I feel like I watched Inception on a loop and it's time to rest this weary mind.
I have my contact sensor open trigger turn on the light and evaluate the motion sensor rule. So as long as no one is triggering the motion in the basement, the light turns off after 3 minutes.
To the point of the lego analogy: what about creating a folder or directory system to organize rules? Right now its like having all my webCoRE if/then statements from every piston in a big list instead of organized into pistons. My app list is getting pretty unruly.
I think it might help people transition more easily from webCoRE and reinforce your lego analogy. Iāve been trying to create a 1:1 rule for every piston and this clearly isnāt how rule machine was designed. Having organizational directories might make that easier to grok.
Lol...I know exactly how you feel. I started writing mini apps with a parent child structure so I could keep a few of them organized. The rules I haven't got to yet, or just aren't worth the effort, I started organizing them with a prefix to help....it's the only way I able to find my rules easily.
A big stumbling block for me to migrate pistons to (multiple) rules is the use of variables to pass parameters. I use just a few global variables in webCoRE because I usually don't need to pass parameters between pistons (since each piston can be quite complex). But I use local variables extensively within a piston. If I try to implement a complex piston in RM, then I believe I'm likely to use multiple rules for the same task; that's fine, but now I need a way to pass parameters between rules, e.g. some type of "global variable".
AFAIK, the only way to do this is with virtual switches or, perhaps, Private Boolean. Either is quite limited, basically ON or OFF. I preface this comment with "AFAIK", because I think there must be a better way, of which I am unaware. How do y'all do this?
LOL. Hey, don't you remember all the legos in the box?
Seriously though, I understand your point. I have a large system, and have worked my way through this 'keep it organized' bit. I've got a lot of apps. Long ago I learned that using a naming convention helps a lot. Also, use Simple Lighting, Motion Lighting and Mode Lighting where they make sense, instead of making everything a rule.
There is a way to do this: Use Private Boolean, and the Restriction called Disable with Private Boolean. With that, other rules can pause / resume a rule. This capability will soon be extended to Button Controller as well, so that you can use a button to pause / resume a rule. Finally, there is a manual way to do with a mode restriction. Create a mode that you don't otherwise use for anything in your system. Then, open the rule you want to disable, put a restriction in for it to only run in that extra mode -- done. Later, remove the restriction.
I was envisioning a little pause button. Until then I'll use Sergeant Boolean. 
