I use a reactor to turn on a light with a motion sensor and turn it off 120 seconds later. I have three switches that can be used to prevent the reactor from becoming true, overrides. If the sequence has been triggered, I would like to be able to interrupt the delay and keep that light on, cancelling the 120 second delay shutting it off.

Is it possible to make it so certain conditions must remain true through the entire sequence for it to complete?
Maybe adding something like If at 120 seconds A,B,C are still true then off, or… starting another reactor for the off sequence.

Here’s what it looks like now.

To clarify a bit more – I think I understand – you want the light to be turned off at the end of the .TRUE activity group ONLY if the triggering conditions remain true at the end of the 120-second delay?

(I’m also assuming, then, you don’t care whether the inputs A, B, and C may have each or all gone FALSE during seconds 1 thru 119? Or must they remain TRUE through the entire delay period?)

If what @LibraSun has asked is true (that you want the delayed action to run only if the triggering conditions are still true at that point), then let me introduce you to contra-activities.

The “is FALSE” activity is the contra-activity for the “is TRUE” activity (and vice versa). If an activity (like your “is TRUE” activity) contains delayed actions, those actions will run when its condition group goes true. If the state of the condition group changes, the activity is not interrupted unless there are actions in the “is FALSE” activity. If there are actions there, the “is TRUE” activity is stopped and the “is FALSE” activity is run. The “is FALSE” activity can even contain just a comment (not really an action, but it’s something) and that is sufficient to stop the first activity.

TL;DR: Put a comment in your “is FALSE” activity and that will cause the completion of the “is TRUE” activity to be pre-empted/interrupted.


Yes Libra Sun has it correct. - Gone False at any time 1 through 119.

I don’t understand the implementation.

Just put a comment in the “is FALSE” activity. As long as the “is FALSE” activity has anything in it, it will cause the “is TRUE” activity to be stopped if the conditions don’t hold throughout the delay.

1 Like

Like this. (doesn’t work)

No, like this…

1 Like

Oh my…Patrick I’m having problems trying to understand exactly what you mean as well?
I just don’t see how the above is FALSE can do/not do anything without an Action?
what am I missing as well?

I can see it. The comment is an action, effectively.


@Catman is correct. Let me try and explain again how this trick works, and I will readily admit, it’s a bit crafty.

The idea is that the “is TRUE” and “is FALSE” are counter-activities. If the “is FALSE” activity needs to run, you don’t want the “is TRUE” activity getting in the way (or vice versa). You want a deterministic answer.


Let’s say we had an “is TRUE” activity that turned on a light at full brightness, then 60 seconds later turned the light to half brightness. And we have an “is FALSE” activity to turn the light off, when whatever condition originally turned the light on is no longer true. Unless the “is FALSE” activity stopped the “is TRUE” activity, it would be possible (perhaps even likely) that the “is FALSE” activity would run to turn off the light, yet the still-running, never-stopped “is TRUE” activity would then, when the delay expired, turn the light back on at reduced brightness (fulfilling its final instructions).

RULE: In order to avoid this scenario, whenever the “is TRUE” activity is run for a group, the “is FALSE” activity for the same group is stopped; and if the “is FALSE” activity needs to run the “is TRUE” activity is stopped. This prevents the two contra-activities from stomping on each other’s work.

EXCEPTION: But, if either activity is empty (contains no actions whatsoever), since there is no action that needs to run, the previously-running activity for the group is not stopped. That is, if “is TRUE” is running and the underlying conditions go false such that the “is FALSE” activity needs to run, but the “is FALSE” activity doesn’t really exist, then the “is TRUE” activity is left alone to complete its work.

So in @CapeCod’s case, he wants that “is TRUE” activity to stop, even though he has an empty “is FALSE” activity. The way to make that happen is simply to make his “is FALSE” activity not empty, and the easiest way to do that (without forcing some nonsense Device Action or other) is to simply put in a Comment. The comment’s presence is enough for the RS to determine that the “is FALSE” activity is not empty, and that will make it interrupt and stop the “is TRUE” activity when the condition(s) go false.

1 Like

Just going to roll with it on the logic.

Like this?

YES! That will do.

Interesting the status shows it like this.

No, that’s different. You also seem to have created a Comment in your conditions. Probably earlier in your attempt to figure out what I was saying. Remove that. You should only have the comment in the Activities tab, not the Conditions tab.

Right. It showed up with a fresh screen. Got it.

Just curious, Would it be possible to have nested reactors? The same way a scene can be included in a reactor, have the ability to add in another conditional statement. In this case, not only the conditions that turn the light on but the conditions that turn the light off.

That’s what groups are for.

Edit: speaking of which, why do you have an AND group whose only member is an OR group? The AND group ‘grpqhqxkfo’ isn’t adding anything to the logic as shown.

1 Like

I did a couple of them and had it perfect but was not able to duplicate the result. This was the closest I could get to the correct version and have it still work. It just got too weird with the drag and drop, like playing wacamole and I planned on going back to it.

Watching your #2 vid again on groups.

1 Like

That should be it.

1 Like

Yes. Now, you can put ALL of that into a group. Basically push it down a level. Once you do that, you can create other groups at the top level.

Each group has its own activities, so you can have each group (a) contain its own logic (including subgroups) and (b) run its own actions when true or false. That, in effect, makes every group a ReactorSensor within a ReactorSensor.

You can even use the state of other groups as conditions in another group. This is how you can isolate tests that are commonly repeated throughout your entire system, like is it morning, day, evening or night? Put that in one central ReactorSensor, and just have other groups in other ReactorSensors look at that ReactorSensor’s group for the current period, rather than computing it all over again. This keeps it in one place and consistent for the entire system.