Trying to get a better understanding of some of the logic.
First, it's rare to have multiple instances of a rule running at the same time, but you could if you have multiple triggers that fire close together (one reason to keep things as simply as you can). I'm not sure if that's what you mean or if you mean, say, a trigger fires while you're waiting on a delay in a rule that had (likely recently) been run. In the former case, behavior is less predictable, and it's something I'd avoid if possible. The latter is an easy, defined case: "Exit Rule" stops executing actions for that particular instance. If you have, say, a delay hanging around, it will still be there. It does not cancel anything, just stops future actions from running that time around. "Cancel Delayed Actions" will cancel any previously scheduled delayed action that is still pending. The rule only has one state and "bank" of pending jobs shared among all executions of the rule (which isn't really "running" during a delay, just sort of sleeping and scheduled to wake again at that specific time). Concurrent access among truly multiple concurrent instances would, again, be a less predictable outcome here and likely poor rule design.
Thanks - I'm going to have to read that a couple more time for my monkey brain to understand.
Let me also give you an example. Focused really on only the first IF statement. I'm trying to create rule for my closet light. I'd like to somehow add something that keeps the light on if there was motion again so I considered adding a conditional statement that says if Closet Outlet active occurs again (during the delay to turn it off), keep it on for another 40 seconds. My concern is that if that did happen, the rule itself would be triggered again which would lead to confusing results.
First of all, is Closet Outlet a motion sensor or is it the outlet controlling your lights? Because this is very, VERY confusing. Let me see if I understand what you are trying to do. You are trying to have the light turn on if there is motion in the closet or if the closet door is open but turn turn the lights off when there is no motion and the close is closed? Is that what you're trying to accomplish?
Is it possible for you to be in the closet with the door closed? If not, then why are you using a motion sensor? If yes, then why are you using the contact sensor?
To answer your first question, you don't need to worry about it. The app is going to to take care of all of that. Don't think of the app running in multiple instances. Think of the rule running only a single time. if you try to wrap your head around how Rule Machine performs a wait or a delay, if you don't understand how it is coded, you are just going to give yourself a headache. But I will say this, while your app is in a Wait or Delay, it isn't actually running. An app will typically stay active and processing in memory for less than a second. And if you get into really, REALLY long rules it might be a second or two. But it's not going to be more than that. It's a waste to have the app active in memory for event a 10 second wait when the rule itself processes in only a few hundred milliseconds. So, in the very, VERY rare case where you have multiple iterations of the rule running simultaneously, you are going to get a POP error and nothing is going to run correctly.
Sorry - Its an outlet that has LED strips connected to it thats powered by switch that I actually put in there (which is a motion sensor switch). I'm not good about actually closing my closet doors so I'd like my lights to turn on with motion.
Thanks for the info. So given that, should I be able to put in a wait for event - motion into a rule triggered by the same thing and not worry about the results?
You didn't answer my question.....so let me ask it again.
What are you trying to accomplish? You want the rule to turn the lights on if motion is active or the door is open and to turn the lights off if there isn't motion? Then why are you bothering to use the contact sensor at all? Presemably, when you open the door there is also motion, correct? it seems that if your are going to use the motion sensor as the trigger, then use the motion sensor and ditch the contact sensor. All of these waits and delay are just mucking everything up. You aren't going to get it to work so just make it simpler.
- turn on if theres motion or the doors open.
- turn off if there hasn't been motion for 40 seconds (or so) or if the doors closed.
You seem a little irked. Hope I'm not getting on your nerves too much. Obviously not my intention. I do indeed want to do very specific things with this system. The rule is actually working pretty much fine right now. I'm just asking questions to demonstrate an example of my original question and potentially fine tune it.
OK, so for this rule, you can probably ignore anything I said about instances that are truly running concurrently. During your delays (and waits, timeouts, etc.), the rule is "sleeping" as both of us have now mentioned. Any "Cancel Delayed Actions" anywhere will cancel all previously scheduled delayed actions. However, any trigger matching will also restart the rules from the beginning and effectively cancel any "Wait" action you have. To be honest, I didn't think through all of the logic in your rule to see if that might matter here since I'm a bit confused as to what devices are what (do you have some sort of combination switch/motion sensor, or did you just name a motion sensor the same thing as a switch? ... you may have answered this above as I was typing). But this all applies regardless.
But: if all you want to do is turn a light on and off with motion and contact sensors, the Motion Lighting app can handle this, with the caveat that light turns off immediately when the contact sensor is closed (no delay). This is a lot easier to set up that Rule Machine. If the delay is a problem, you can trick Motion Lighting (or any app, including Rule Machine) into thinking the contact sensor is a motion sensor using a tiny custom app staff have provided. That may make things easier to matter which method you use. Learning RM is certainly fine, but easy, small options are my preference when possible. Good luck either way!
The issue is that if you make things overly complicated, the whole system begins to run slower and slower and slower.
But yes, there is a much, MUCH easier way to accomplish what you are trying to do. You have one rule that turns the light on/off via the contact sensor and one that turns it off by motion being inactive. Very simple rules. In the motion rule, in the conditional action you also include the lights state of being on, you can avoid unnecessary off commands being sent to the light. There is no reason to interlace them with each other because you don't need the functionality to interact. Then you don't have to worry about wait or canceling them.
its a combo switch/motion sensor
Thanks. Those 2 facts you laid out are useful.
Thanks. Yes, I see and that actually occurred to me when I was summarizing what I wanted my rule to do for you. I'm pretty new to this stuff and not a programmer so I appreciate the fact that I'm not being efficient yet.
Anyway, all of this has been helpful.
I do something similar but in my case I want the light to stay on if the door is closed:
The if condition looks a bit backwards but by using the NOT open it keeps the motion sensor from overriding the contact sensor. For your case I would think something like this:
IF (motion sensor active OR contact sensor open) THEN
This way if either the door opens or motion is detected then the light will come on. If the door closes or the motions sensor times out it will turn off the light.
The only catch may be in the timing. How long does the motion sensor stay active? For example, Iris sensors are 30 seconds and EcoLink are 4 minutes. If you are OK with the time delay of the motion sensor then you don't have to do anything else.
But that is not what the OP wants. They want the contact sensor closing to override the motion snesor. So, if the sensor is closed the lights should turn off. If you are going to do it with one rule, you would have to do it light this:
IF (Contact Closed) THEN
Light Off
ELSE IF (Motion active or Contact Open THEN
Cancel Delayed Actions
Light on
ELSE IF (motion inactive) THEN
Delay by X seconds
Light off
END-IF
That trigger by either device changing states, should get you what you want.
That's exactly what I suggested does. The only question is if the normal duration on the motion senor is OK for their delay. Let me put the whole logic of what I suggested:
Triggers:
contact *changed*
motion *changed*
IF (contact OPEN OR motion ACTIVE) THEN
Turn on light
ELSE
Turn off light
END-IF
So, door is closed and the light is off. When the door opens the contact sensor opens and the light turns on. About the same time the motion sensor triggers and the light turns on - doesn't matter as it is already on.
Assuming the motion sensor resets after 30 seconds.
Somebody rummages around in the closet for two minutes. Light stays on as the motion sensor is still seeing the activity.
They close the door and the light turns off (contact). 30 seconds later the motion sensor times out and turns off the light. Since it is already off there is no chnage.
Or they walk away and leave the door open. The light turns off after thirty seconds (motion).
Now, if the motion sensor reset is more than 30 seconds and this is a problem you can add the delay and cancel. However, even if it were ten minutes it shouldn't be an issue. The lights will turn off regardless when the door is closed. If you leave the door open and walk away the longest it will be on is the duration of the motion reset.
No....the motion sensor is still active...so light will stay on in your rule, which is not what the OP wants. Motion sensors have a timeout. They don't change instantly when motion stops.
Conditional actions do not = triggering actions. They are the current state of the device.
Ah right, I was thinking it was a simple logic invert but not in this case. I normally don't use rule machine like this. My more interesting automations are done as apps because I found RM to be a bit unwieldy for larger projects.
You can't do this special case with another app. But the rule I showed will work with no waits necessary.
Why can't I write my own app to do this?
You can write your own app...i meant you couldn't do this with Motion Lighting or simple lighting.
You can write your own app but can't use Rule Machine? I find that a little hard to believe.
I would not consider this a large project.
Where did I say I can't use RM? I said I find it unwieldy for larger projects.
This is what I love about Ryan780. He (or she), without a bunch of extraneous chatter, comes up with the simplest, most elegant and logical solution to what is often confusing to us wannabe programmers. Bravo!