Rule 5.1 causing hub slowdown

[jeremy.akers]

I've been having issues with simple lighting triggers (based on motion) on my hub taking >2-3 minutes. I also noticed that the process of taking a backup takes like 15 minutes now.

I finally took some time to investigate and found a number of my apps have massive state sizes:

The worst offender here is a Rule Machine 5.1 rule with a state size of over 32,000! This is not a complicated rule:

I noticed further down the list a related rule called simple "Jeremy Office Fan" also has a substantial state size of nearly 9,800, and it shows "% of busy" over over 50%. This rule is a little more complex but it's not so complex that I would expect that sort of busy time:

I'm especially confused by the state size. What "state" is being saved/stored here? I know I can adjust the state history size for devices, but I'm not finding a way to edit that for Rule Machine rules/apps.

What is the best course of action to remedy this?

[FriedCheese2006]

Using changed is usually not a good idea unless it something simple like on/off, active/inactive, etc..

That aside, I think there's been acknowledgement with changed causing problems and the recommendation is inline with the best practice (until a fix is released of course). Modify changed to a threshold.

[jeremy.akers]

I'm not sure I'm following. What would I use in place of "changed" here that would still work for this rule?

[FriedCheese2006]

Temp > whatever bottom threshold. I would think you'd not want the fan on if the temp was below 66 or even higher. So, a simple change to

Trigger:
Temp > 66

[aaiyar]

@FriedCheese2006

Temp > whatever bottom threshold.

This is probably the best approach. The other option is to save the current value of the sensor to a numerical variable, and use a condition that exits the rule unless the new value is different from the current value by a reasonable delta. Say < -1.5 or > 1.5.

[jeremy.akers]

But this rule also turns the fan off. So if the fan was on, and the temperature dropped to <66, it wouldn't turn it off if I did it this way, right?

[jeremy.akers]

I also just realized this doesn't work for the other rule either. One rule just sets the numeric variables, so it really does need to run anytime they change.

If I want to capture the value of the sensor in a numeric variable: how else would I do that without having a rule set that variable anytime the sensor value changes?

[FriedCheese2006]

Well. You posted two rules.

For the off event in the second rule, just add a wait for expression line to turn the fan off once the temp drops back to your desired level.

IF(conditions) THEN
Turn on fan block
END-IF
Wait for event: temp is good
Off fan

[jeremy.akers]

You're talking about conditions now rather than triggers. Conditions and triggers are different. I already have this logic in the conditions...

Since both high and low temps are covered in the conditions, the trigger needs to fire on both high and low. It can't only fire when high.

I can't hard code a value in the trigger either. The actual conditional value is based on a thermostat setting.

[FriedCheese2006]

@jeremy.akers

You're talking about conditions now rather than triggers

I'm not sure what you mean. My recommendation to change the actions is to support changing the triggers. A wait for event is functionally the same as a trigger, it just doesn't require the rule as a whole to be triggered again (aside from being cancelled and reset if the rule triggers again). Meaning you don't need changed to catch the temp going back down to an acceptable level, the wait will handle that in the actions. So your trigger would catch the temp delta (which you can set as its own item instead of storing into variables) and you actions are there to turn the fan on to the appropriate speed, wait for the temp to come down, then turn off the fan.

[jeremy.akers]

I don't see "Wait for event" anywhere. What are your referring to when you say that?

[FriedCheese2006]

Here:

[FriedCheese2006]

Not sure if you got this figured out or not, but I had some time to mock this up. I think this single rule can replace both that you posted, does not use changed, and should still achieve what you're trying to do.

This is all under the assumption that you aren't using those variables in the first rule elsewhere.

The required expression does your check to make sure the thermostat is in 'cool' mode. The rule doesn't run unless it is.

The triggers will occur anytime the temp sensor is greater than 1° from your reference device or if motion goes active.

The actions will:

1. Evaluate whether the motion sensor is active first. If not, then the rule exits.
2. If it is active, then we see if the temp is greater than 2° over reference. If so, set the fan to medium-low.
3. If the temp is between 1 and 2 degrees higher, we set the fan to low instead.
4. Wait for the temp to come down in-line with the reference device, and turn the fan off.