"Best" way to put together set of cascading rules

I have three different air purifiers. Some of the logic for when they are on or off is shared and some is individual. The following shows the logic for one of the purifiers. The only difference between each purifier is the way the top switch is determined. Here it is by time, For purifier two it is when a switch in a specific room is on, for purifier three it is when any of a set of switches in yet another room is on.

Currently I've separated the rules based on triggers. One rule is purifier-specific and triggered by the top switch. On is mode-specific. One is AQI specific. One is Virtual switch specific. This works well, but means that each rule has to have all the logic in it so, that when I change the logic for the top switch, I have to change it in each of the other rules.

I'm thinking of making the rules purifier-specific, with each purifier making the decision based upon all the inputs. However, this seems to be wasteful, as each of the rules would have triggers that duplicate other rule's triggers. Is there some way, for example, to aggregate information from virtual switch and AQI/Mode decisions, and present them to the purifier rule as a changed value? That is, when Virtual Switch OR AQI&&Mode!=Away changes, trigger the purifier rule and present it the result of that OR?

How do you simplify this for best maintainability and efficiency?

I use a variable in these instances. Have a 'status' variable to set the purifier state. Then create different rules that can update the status.

Probably more direct ways to do this. I like having only one rule that controls a device. It makes updating rules or swapping out devices simpler.

Assuming that the same trigger turns them off, if I was to implement this, I think I would have 4 rules:
Rule 1:
All but the first trigger
All air purifiers

Rule 2:
The first trigger
Air Purifier 1

Rule 3:
The second trigger
Air Purifier 2

Rule 4:
The third trigger
Air Purifier 3

But there's currently no way to trigger a rule based on a variable change. I think that's coming soon.

The problem with this comes when, for example, rule 4 goes to "off" but rule 1 is still "on". The result should be "on". But having completely independent rules doesn't allow for that.

1 Like

Not the variable directly, but the connector works just fine.

Yea, I can see that it could be an issue. I can think of two options off-hand. 1. Use a Global Variable or Connector Variable to determine if it should be on or 2. Combine everything to a single rule, but that might be a complexe rule…

Out of curiosity, what triggers them to turn off? Individual triggers, or one for all?

See, that's the challenge. The logic diagram shows that the fan should be on if any of the three inputs are on, off if all are off. So, it must redo the "OR" when things change, rather than just switching off. I've done some more thinking and I'm going to use global variable, which, in the next update, can be used as a trigger.

To give you an idea, here's the code that will handle the inputs that don't vary among different purifiers, where Manual purifiers on is a global variable:

Triggers
Manual air purifiers on turns *changed*
 OR
AQI reports airQualityIndex *changed*
 OR
Mode becomes *changed*

Run
IF (Manual air purifiers on is on OR
  ( AQI airQualityIndex >= 3.0 AND
     NOT Mode is Away
  )) THEN
       Set Purifier Manual On Switch to true
ELSE
       Set Purifier Manual On Switch to false
END-IF
1 Like

RM 5.0 Predicate conditions may also help simplify some of the rules, particularly the mode condition. If the rule only runs when MODE is NOT AWAY, then use that as a predicate condition. You just have to consider that the predicate means the rule will only run when the condition is true at the trigger. A change in the predicate during execution or as a condition of the trigger will not trigger the rule.

I have a set of rules that automatically locks my doors on a timer when unlocked. During the day, the timer is 30 minutes, but at night or when away, 10 minutes. There are two rule sets, (day and night/evening/away). The predicate determines which set is executed. Mode=Day is the predicate for the day set, mode is Night/Evening/Away is the predicate for the other set. A separate rule set automatically changes the mode based on sunrise/sunset times (I set evening 30 minutes before until 30 mins after sunset).

1 Like

OK, here's how I'm doing it so far. Since hub variable changes can't be used as triggers (yet), you'll see that some of the rules end up running other rules--they run the rules that should trigger when a hub variable changes. The first two rules are used by all the purifiers. The last two have to be replicated for each purifier, but you'll see that they're pretty simple. This exercise also showed me I had lots of errors in my old setup, because the old setup was too complicated to follow.

Hub variables are highlighted in yellow.

Rule 1: Should all the purifiers be on? I have a virtual switch Air purifiers on that, if I turn on on the dashboard, I want all purifiers on. Otherwise, I want them on if the air is polluted and we're home.


Rule 2: Turn off all fans if there's smoke in the house.

Rule 3: Should the office purifier be on? Note this rule would have different triggers for each of the other purifiers, so each has its own custom rule.

Rule 4 (titled Purifier Office): If Rule 1 or Rule 3 is true, on. If all are false, off. However, if there's a fire, off anyway. This rule is nearly identical for each of the other purifiers. They just take a different "auto on" variable, and control a different outlet.

The hub variables can be used as triggers if you set a connector (virtual switch). You do that from the hub variables settings page. The switch tracks the state of the hub variable, and the switch can then be used as a trigger. From what I've read, this is merely streamlined in the next update to where you don't need the connector.

By what you describe this should help simplify your logic flow now without the additional rule sets.

1 Like

I could be wrong but can this be handled with a state machine? I recall once seeing a state machine app someone wrote.

Is this what ou are thinking of?

Yes - I was wondering if that could be used in the OP's scenario.

1 Like