Interrupt?

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.

2 Likes

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.

C

@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.

Why?

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.

2 Likes