Trigger an action based on order of conditions?

[grossmat]

Apologies in advance if this is one of those easy, well documented questions. I've combed through the Help file and through the Forums and haven't quite found an answer.

I have a door that opens into a small hallway. I have a sensor on the door and a motion sensor in the hallway. I'm trying to make the event fire based on the order of the sensor's being tripped:

IF someone opens the door, THEN triggers motion, THEN turn on a series of lights. Conversely, if someone triggers motion, then opens the door, do nothing/non-event.

I setup the event as: IF the door sensor is open AND motion (and a time and device status are TRUE), then control the intended lights. That works fine but it doesn't take into account the order of the initial door/motion events. So the lights turn on regardless of the order since both conditions are met before the motion times out since it's a small hallway.

I've played with a virtual device so that: IF motion, turn off the virtual device and IF door, turn on the virtual device, then check if that virtual device is on or off as part of the conditions, but I can't seem to make it work predictably.

Is there a general practice that allows for the order in which the conditions are evaluated to force the behavior? I know you can drag-and-drop the order of items and presumably there's a reason that feature was added to help the event engine process the conditions in a desired order, but I can't seem to make that apply in this case. Due to the size of the hall, a timer I suppose could work if it was a second or two tops or perhaps even a counter, but before I keep making up permutations, I'm wondering if I'm simply missing something about the ordering of conditions...

Again, sorry if this is a super simple question and thanks to all of the real talented folks I see on these Forum pages who are willing to take the time to help the rest of us master HS3!

[sparkman]

I do something similar, but control a different set of lights depending on which side of the door motion is detected. My scenario is when someone comes from the garage into the mud/laundry room, then the light in the mud room comes on. If someone from the laundry room comes into the garage, then the light in the garage comes on. My events also include light sensors but may be adaptable to what you are trying to do.



Cheers
Al

[grossmat]

Thanks Al. I think I can do the same sort of test you're doing with the light sensor, but checking for open/motion on the secondary devices -- assuming the HS3 evaluation can happen fast enough before the second device has been triggered (would need to be within <2 seconds). I'll give that a try and definitely appreciate the feedback! BTW, just curious what the delayed device action is being used for? I'm assuming it's unrelated to the logic here but see you post often so guessing there's more to learn than meets the eye

Cheers, Matt

[sparkman]

Hi Matt,

Clearing the delayed device actions are to ensure there's no existing delayed device action that will turn off the light sooner than the 8 minutes. It's a way of extending the time-frame when the light is turned off. I have other events running that will do the same thing if additional motion is detected. The delayed actions are also cleared if the light is manually turned off. And yes, it's unrelated to the logic of turning the lights on to begin with.

Cheers
Al

[Uncle Michael]

IF someone opens the door, THEN triggers motion, THEN turn on a series of lights. Conversely, if someone triggers motion, then opens the door, do nothing/non-event.

Matt,
You may be able to do this with logic that's even simpler.

One event only. Turn on the lights if the door is opened and the motion sensor has not been tripped within the last 10 seconds, say.

That is, do you really need motion detection after the door is opened to know someone is going that way, or can you infer it from the lack of motion before the door is opened?

[grossmat]

Thanks Mike, makes sense. I'll give that a try. Simpler is more better for sure! Cheers, Matt