I have a question about enable/disable of groups using actions via reactor. When a group is re-enabled, will the logic conditions be re-evaluated? I have created a Virtual Switch to expose to Alexa, to control a ‘Cinema Mode’. When this is enabled, I want to disable the separate group on a different reactor so it doesnt eval, turn the light off. Then when I want to disable ‘Cinema Mode’ I want to re-enable the separate group and have it re-eval to see if the light should be turned back on based on other factors I have in there - ie, time of day, occupancy, etc.
Enabling or disabling a group causes a re-evaluation of the entire ReactorSensor.
That said, using group enable/disable in that way is really kind of ropey, IMO. It’s akin to unplugging your alarm clock when you don’t want to be woken up at 6am rather than just flipping the “alarm” mode to “off”. The preferred way is to add a condition to the group that you want to control to gate it.
One reason using enable/disable as logic can be troublesome is that you don’t know what state that group is in when you disable it, so you could disable it when it’s true, and that will not make it false or run its is FALSE activity, leading to potentially undesirable results.
2 Likes
That is exactly the info I was looking to get on this one. I was ‘thinking’ that maybe the enable/disable group simply paused and then reset the evaluation on just that portion of logic. Not the case.
I want my automation to be generic, so multiple logic group can control a particular light for example. So to keep things are generic as possible, going to test on my automation reactor sensor maintaining a control state for automated devices - ie, a variable that is exported and gets updated by the automation logic. The separate lighting control sensor for that particular room then has extra logic to only go true/false if that exported variable is a certain value.
Thinking this framework should work at least in my case. I didnt want to hard code logic into the separate lighting control sensor to check the group state of this particular automation sensor logic group, as it may be possible for other automation sensor logic to toggle the same light. So will see if I can get away with logic groups in the sensor modifying the variable, and having the lighting specific sensor for the room checking the variable.
Fun times.
Given that you can examine the state of other ReactorSensors and even specific groups in other ReactorSensors, you can probably conceive a structure for your logic that encapsulates details away from places where they’d be inconvenient or difficult to remember/support. Think about moving specific conditions out to their own ReactorSensors or groups. And especially, where “OR” is used to detect any of several conditions, consider that it may be a candidate for such repackaging.
An example: suppose you have some outdoor security lights that are normally on between sunset and sunrise. So you have a ReactorSensor that just uses a Sunrise/Sunset condition, and the “is TRUE” activity turns on the lights, and the “is FALSE” activity turns them off.
Now you’re inconvenienced in your home theater by some of the lights shining toward the windows while you’re watching a movie, so even with the shades down, there’s some unwelcome light leaking through. And as it happens, when you have guests sleeping in the guest bedroom, the lights tend to lighten the room too much and make it difficult to sleep.
A theater ReactorSensor may already tell you that the system is active and playing a movie, so that’s a win, but even if not, maybe it’s easy to just add a group that’s true when the system is on and the movie is playing. A guest mode virtual switch can be used to signal that guests are in the house overnight.
So you add a new ReactorSensor “Security Lights Disabled”, and it looks at the state of the theater ReactorSensor (or group within it), and that of the virtual switch. If either is true (A OR B), then the ReactorSensor is true/tripped.
It’s then a simple matter to just add a single condition in the outdoor lights ReactorSensor to check the state of the new “Security Lights Disabled” RS (“is FALSE” is the desired condition to allow the lights to be on). You’ve now added control of the lights by other RS’s, but not buried the specific logic elements in the light control.
Now, if you want the security lights to come on unconditionally at night when the alarm system goes into alarm, even if a movie is playing or a guest is present, you just add an AND condition to the “Security Lights Disabled” (e.g. “alarm system in alarm IS FALSE”).
How you structure the logic is entirely your choice, but I think Reactor gives you a lot of flexibility to make those choices. ReactorSensors are cheap. Make a ton of them. Go wild!