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