Migrating to reactor -- Need advise on overlapping reactor conditions

Good afternoon all,
Being at home for the foreseable future on COVID lockdown, I started playing around today with Reactor, moving some of my programming from Vera Scenes and PLEG. I’ve had some issues as of late with PLEG, just trying to get my head around some of the conditions, and I keep getting told to try Reactor. So, I am.

I’m trying to start simple before I move into my more logic intense PLEG conditions. What I’m starting with is my home blinds automation.

What I’ve set up so far is basically weekend and weekday routines to open and shut my window blinds. Very straight forward. It act’s upon House Mode, Weekday, and Sunrise/sunset conditions, and time of day for weekends (so I can sleep in).

In PLEG, I have some logic to control certain windows based upon the Helitrope app. I can do the same thing with Reactor, but what I’m trying to figure out is this. If the Reactor 1 conditions are true, I’m home, day/time conditions are correct, and then Reactor 2’s conditions become true, which alters the blind angle to reduce the sun coming directly into those windows, would the Reactors conflict? Will the first reactor see that the blind state has changed, and try and override the second?

Thanks for any advise.

1 Like

The answer is that whichever runs its activity last wins. The ReactorSensors do not know anything about each other (unless you teach them) or assume anything about what other ReactorSensors might do or not do. If that’s important to your logic, you need to build that into your logic. You can use “Group State” conditions to test the logic of other ReactorSensors. You can also just put all of the logic into a single ReactorSensor so it’s easier to follow.

Cool, that’s what I thought, but wanted to check.

I’m not sure I could move everything into one reactor sensor, because there are different conditions that need to be met for different blinds (actions/activities). If it’s possible to do that, then that would be fantastic.

In other words:

Conditions are XYZ, Actions for Devices A, B, & C occur
Conditions are LMN, Actions for Devices D and E occur

You can do all of the automations for your entire house in one ReactorSensor. It would be crazy to do that (unless you live in a one-room studio with two lights or something :slight_smile: ), but it’s possible. I have one ReactorSensor per room, to take care of everything that happens in that room. I have a couple more in a “Virtual Devices” room that takes care of house-wide things, and conditions that are shared among the rooms, like deciding when it’s a weekday or weekend morning, daytime, evening, and night (sleep) time. But do whatever makes sense to you.

How: each condition group has its own activities, anything you can do in a ReactorSensor, you can do inside a group in a ReactorSensor.

1 Like

^^^
FWIW, you can use PLEG actions in Reactor. Now need to completely rewrite your logic, just move it over as you see the need.

Thanks Patrick. I’ve been playing around with it this weekend and I’m finding it quite intuitive to learn. I realized that I don’t have to have an action for the top group, and I can create many sub groups that have actions associated with them.

Quick question, is it possible to reference a group with the same reactor sensor? I see I can reference other reactor sensors, but I’m unclear if I can reference those subgroups directly. In my instance, I’m trying to reference a group of OR conditions I have set up for Dark Sky weather conditions. Yes, I know Apple just bought Dark Sky and I’ll be SOL the end of 2021, but until another API comes around, I have to work with what I’ve got.

Understood. I do have a need, which is why I’m looking at migrating, and I do have the time to do so. The first group I migrated from PLEG went remarkably quickly, and I was able to do things I was having problems with in PLEG, such as schedules, which was hit or miss at best. Reactor made it incredibly simple, and I love the “between” condition, which is definitively missing from PLEG, and makes logic much more complex to write.

Yes! The first thing on the device menu when you choose “Group State” should be (this ReactorSensor). You should be able to choose your group then.

Thanks. Still learning :slight_smile:

I’ve managed to migrate probably 2/3 of my PLEG actions to Reactor. I’m amazed at how quickly I’m able to do it, considering how long it took me to program PLEG. Granted, the one’s I’ve started with are fairly simple. The harder ones lie ahead.

2 Likes

I skipped PLEG altogether, despite its zealous and outspoken following. I first discovered Reactor at the end of February this year, and it dramatically enhanced how I use my Vera.

Said goodbye to Scenes (ironically, the only Scene left is one I’d use in a pinch to reset Reactor, lol). Said hello to multiple complex workflows I’d have scarcely imagined trying before.

It pleases me to hear the migration is going smoothly, as I suspected it would. Easily in the Top Five “Power Plug-Ins for Vera”, Reactor is certainly feature-complete and, dare I say, a virtual controller-within-a-controller!

1 Like

Pretty much my experience. I simply couldn’t get my head round PLEG but that’s far more about me than the package.

I still have a couple of scenes they’re more for Alexa integration (which I adore)

C