Old way Vs new way. is it worth re-writing this or other rules?

So i think you touched on the thing that confuses me the most here. When and how the rule is evaluated.

So i am picturing a conveyor belt with green apples on it. as they flow past you, you are looking for red apples that dont belong. you dont act or touch any of the green but you see them all. when you do see a red apple you pull it off the conveyor belt. You only react when you see a "change" a different color apple. but you have to look at all the apples to know one was different.

So i picture that in rule machine as well. Every time the power level changes the system knows and when it changes a certain way it reacts. What i dont functionally understand is why that is different than defining a specific number =>71. the system still has to look at every power reading to know it his 71 watts.

I really need help with this mental hurdle here. i think its what is blocking me from understanding it. the system is always looking at everything to figure out how and when to act,

Edit: so to improve the boolean rule i would add two triggers one trigger being =>71 and the other trigger =<69?

1 Like

Truly appreciate it

Why have an app subscribe to all events, when it doesn't need all of them?

If these were my rules, I would leave the second rule as is, and change the first rule to have two triggers (power > 71 or power < 69). I would structure the rule actions to be something like this:

IF (power > 71 AND rule boolean TRUE) then
   Set Rule Boolean False
   Do whatever is needed to run the second rule
ELSE-IF (power < 69 AND rule boolean FALSE) then
   Set Rule Boolean True
   Do whatever is needed to run the second rule
END-IF

At the very least, this prevents the rule actions from running multiple times for sequential power changes in the same direction (i.e. 71.1, 71.2 etc) and also prevents the rule from running for power changes that are of no interest (>69 but <71).

1 Like

This is one improvement that I think Hubitat RM should make to make things easier on new users.

I should be able to set a rule that says:
Trigger: Plug Power Usage > 71
Action: Set virtual-switch_PS4 = On

Hubitat should be able to determine "I have a request to monitor the current power usage value, therefor the real trigger is "On Power Change, IF > 71". Pretty sure ST abstracts it in this way, and it's a much less "technical" way to setup rules.

lll give it a shot. i still dont truly understand the impact. i wish i could watch the memory of the hubitat or something and see definitive differences.

2 Likes

Here's what I recommend. Leave the rules as they are, but turn on logging. See how frequently the rules actions execute.

Then change the first rule and see how often the execute. If there's a dramatic decrease, that's a good thing.

I'll repeat something else that you may have missed. My suggested changes matter more only if your power reporting device reports frequently. It is no of lower consequence if it reports once in 10 minutes, or only for changes of 10% (i.e. increase from 71 to >= 78.1, but not an increase to 71.1).

I agree. Although, to be fair, this is the purpose of using conditional statements like the example above.

this plug seems to report back often. i wish i could supress any logging of watts below 10 watts. it would make the plug a lot more quiet.

Does the driver let you set the "Meter Reporting Interval" and/or "Meter Reporting Threshold"?

Untitled

not on this one. its the v1 iris. if i ever get around to updating it i will get something that i can do that with.

Then I'd definitely recommend doing the test (by turning on logging) to see how often the first rule runs with the original v/s the suggested rule.

Also, keep this is mind for devices that report frequently - the more of them you have the more "load" you create for the hub (in terms of database writes). And the radio in question (zigbee or z-wave) is kept engaged for a longer time.

To further your analogy to illustrate that monitoring thresholds (if your energy monitoring device could do it) would be like ..

Get a kid to watch the conveyor belt while you take a nap in the corner. Tell him if a red apple comes by, to throw it at your head. Otherwise, leave you alone. In other words, offload the majority of the "watching" to the device if possible.

3 Likes

Agreed. In addition to app-trigerring benefits, this also has the equally important advantage of decreasing unnecessary chattiness and thereby frees up the radio ...

Sorry to go a bit sideways on the topic but I've been hearing about "the new way" in a few posts lately - what did I miss? My search fu hasn't been finding anything helpful.

Thanks

search hubitat kiss

there are a few threads on it.

Oh yes, looking for "old way" and "new way" it should have been obvious to search for "kiss." :joy:

For most rules and users it probably isn't worth rewriting everything. Every event still has to be handled by the hub an extra if statement or two isn't going to break things. However, very chatty devices and overly complex rules could be an issue. It is good information for going forward. If you revisit a rule for some reason then it might be a good time to refactor it if you are concerned.

1 Like

Lol thanks for the input

IMHO, this has to be one of the "Best questions asked so far!"
and
some of 'The Best' answers I've read too.

Well done @april.brandt @aaiyar @jercloud @HAL9000

1 Like

Mental hurdle question in #4:

In your conveyor example, your example should be something like comparing apple ripeness, which would compare more closely to your power example (namely because power reports often): "Is the previous apple more or less ripe than the previous one?" ... this would be the equivalent to "changed". So, basically every time an apple goes by, the ripeness has changed. So, the answer to your first question is almost always "yes", meaning you then have another decision to make: Is it too ripe ... or not ripe enough. So, every time an apple goes by, you're making 2-3 decisions (Changed? Too ripe? Not Ripe enough?)

The other option is to simply look at the apples and make the ripeness decision straight away: Too ripe? Applesauce. Not ripe enough? Apple juice. In this scenario, you're only making 1-2 decisions per apple.

Now, in terms of Hubitat, there is a not insignificant chance that these comparisons have differing impact on the system, though it would be challenging to compare this, since we are not given any hub performance data to work with. So, we can assume they're identical system impact wise, but I'd assume the triggers are more efficient, if anything.

Kindof like having loops: a "For ii = 1 to 1,000,000 ... Next ii" is generally more efficient than "Do ... ii += 1 ... While ii >= 1,000,000". They're doing the same thing, but one is doing more stuff.

I'm not sure about the CPU impact, but anything that "does" something will generally be a large computational hit, versus something that simply "thinks" something. So, your changed rule will, every time wattage is over 71W, keep setting BOOLEAN back to TRUE even though it's already true. It might be prudent to put in a "If PS2 > 71W AND BOOLEAN = FALSE THEN" to eliminate re-setting the boolean. Now, in terms of a variable, probably not a big deal. But if that were a light bulb, setting it to "on" when it's already "on" would not be a good idea.

Also, why the 2W gap?

The 2w gap is the difference between the PS4 being on and playing or being on but I'm rest mode downloading updates or something. So Even though it's using power I don't want the automation to run.

1 Like