Conditional nesting

[Tarkus-NJ]

Hi Patrick,

I started playing around with the beta and I am trying to figure out the proper nesting structure. Basically I need to execute different activities based on the status of 4 virtual switches on a multiswitch (in my attached PNG I only show 2, AV1 and AV2 to save space in the example) but only if certain conditions are true.

Please see attached PNG for further info on what I am trying to accomplish.

Thanks,

John

[toggledbits]

Momentary puzzle/prompt/hint before we dig in more deeply. Consider, these facts about Reactor 3.0:

1) You can examine the state of another group in the current or another ReactorSensor by looking at the ReactorSensor's GroupStatus_xxx variable (where xxx is the group ID)*; 2) You can now run actions for any group created, not just the ReactorSensor's global "tripped" and "untripped" states. You can leave those empty, and just have activities attached to subgroups.

• I'll admit this is a pretty "raw" UI for the purpose, but I am still myself wrapping my head around the full breadth of this feature and how it could be applied, still trying to decide how to best present an interface to this capability. For the moment, this is the "raw" version.

[Tarkus-NJ]

Perhaps the groups and subgroups can have a check box or radio button for the option to run the associated activities only if the root of the sub groups is true.. In the scenario I posted Group AV1 has one activity and AV2 has a different activity so I can't use an activity attached to the global tripped group.

Notice that I have a separate group at the very bottom named Receiver Z2 On. I would like to have subgroups to that as well to run activities under the condition that my AV Receiver Zone 2 is powered on as well as conditions met based on the subgroups.

I understand that it is a work in progress and there are probably several different ways to approach things. I Actually think the UI is pretty nice. I know some people had concerns about things getting too small. I did not find that to be a problem .

[toggledbits]

OK. Here's more detail on how I would approach your problem in this new Reactor model.

First, I would create a group the root, which to help frame the concept, I'll call "Functions". Inside that group, I would place the AV1, AV2, Main Zone, Zone 2, and Receiver Z2 Standby groups, each containing their respective conditions.

Then, I would create another group in the root which I'll call "Operations". Inside that group, create whatever groups you need with the conditions you need activities for. In this group, you can refer to the status of the Functions groups, so this is there the implement the logic for the combinations of those groups.

Then, go to the Activities tab, and add actions for those subgroups of Operations that need them.

The global trip/untrip gets nothing in activities. It's ignored entirely, as are the results of the container groups Functions and Operations.

Do you see how this works? You can use groups now to break down the logic into functional components. You can do logic between these components/groups to assemble more complex logic. You can have activities on any component, or not.

[Tarkus-NJ]

Thanks Patrick,

Definitely put me on the right track. It's working! See attached to see what I ultimately came up with.

[toggledbits]

Looks good. I've just finished adding "Group State" as a condition type all to its own (issue #18). So on the next beta release, you'll have that. Same as what you're currently doing operationally, but a nicer UI and some protection from logic loops.

[BuxtonCalvin]

Hey Patrick, just wanted you to know I'm following along and if anything comes up I'll chime in.

[Tarkus-NJ]

BTW I the above example, in the Functions Group I removed Group AV Inputs since I suspected it was not necessary. It did not affect the functionality in any way.