[Reactor] Bug when sending MQTT boolean payloads

[RogerO]

Hello,
Trying to convert my Reactor scripts to MSR. Couldn't get the import to work so gave up on that. Anyway, curious on how to work with the following example.

Have a motion sensor on my back porch. Very simple logic:
The Reactor activities are as follows:
.

In MSR, how do you tie activities to sub conditions like I have with the last action in activities.
In this case I was to trigger BlueIris to trigger regardless of the time of day, but only want the light to come on at night. Do I need multiple Rule Sets?

Thanks,
Roger

[LibraSun]

I believe the answer you seek lies within the new-ish "Group" feature in Reactions. (There is no section covering this yet in Docs, at least when I looked under "Creating Automations" > "Reactions").

I'm sorry not to have the time to type out a complete example for you, but I know the Forum contains several use cases involving "Group Constraints".

[RogerO]

I did not find anything in the forum under those keywords. Do you have a link or 2?

[LibraSun]

I had looked for links earlier and found none that were illustrative of setting up Group Constraints, but generally speaking, I can suggest:

In your Rule, within your Set Reaction, add a "Group Constraint" (which will look and behave like it's own "section"). Add one or more Conditions, such as your "Is Night" timeframe, and then add the thing(s) you want that group to do when true.

Do all this again, adding a Group Constraint to the Set Reaction which contains your "Porch Sensor Tripped" logic, along with actions you want it to take when that logic is true.

In this way, you wind up with a Rule that runs under the appropriate AND logic it always did, but internally forks to run one (or both) subsets of functions depending on their truth.

Of course, since my basic example happens to repeat your SET conditions within the Group Constraints sections, they will kinda automatically be TRUE every time the Rule fires, so both constraints' actions will always fire. Up to you to decide which logic you really want internally.

[toggledbits]

Using Group Constraints is one way. The other way is to make Porch Sensor Tripped its own rule with its own reaction (the HTTP Request), and then create an additional rule Back Porch Motion that uses a "Rule State" condition to test Porch Sensor Tripped and the entity condition to check the back porch switch.

[LibraSun]

The way that Patrick is suggesting I believe is the more versatile and manageable approach.

[RogerO]

Went with Patrick's suggested approach. I do like the old reactor a bit better for this instance. Less clutter. Sure there was a technical reason to do it this way. Guess I can create multiple rule sets to group them by.