I bought hubitat a few weeks before wink went the way they did. Great timing on my part. But now im learning how to do rules in rule machine, and in the middle of doing the 11 or so rules i have this webinar comes out, and everyone is now re-writing and learning the "new" way of doing rules.
So that is great and all, but im struggling a little between figuring out what works the way i have it, sometimes looking for a state change, or looking for multiple triggers, VS using a known state and waits.
What is the actual difference? when does the performance of the hub get impacted? i know we can't just say 14 rules and your screwed if you dont do it the new way, vs 13 rules the old way is fine. but is there a way to know what the impact is? Should i really be worried about the old vs new way if the rule i wrote is working?
If there is a larger impact that makes writing these the new way necessary it would be nice if we could find a way to make re-writing these rules easier to understand.
For example i have two rules working together. One that watches for change in a plug energy level and sets a boolean value. then one that looks for that boolean to change then does an action depending on what state it is in. this works 100 percent of the time, its fast its reliable. but it doesn't fall into the new method so is it wrong? how can i do this with the new method?
I think that there isn't a right answer to this question. What I've gone by is that I try to do what I can in simple automation platforms and saved the complex stuff for Rule machine. I've been ok with my rules. I don't have excessive logging turned on unless I'm troubleshooting. I think that if you have rules that are working and you're not experiencing issues with your hub, then leave them. I've left mine. Pay attention to something that's calling or polling continuously. That's where some problems will definitely arise. It might not be a bad idea to familiarize yourself with the new way and start conforming to the new way, and maybe I'll try to get some people to give me some examples of these ways and get something posted for everyone, including myself to reference.
I'll get on this by this evening.
I'd recommend turning logging on and seeing how often those rules run, especially the first rule. As currently described, the rule actions of the first rule will execute every time there is a change in power - rendering the frequency of execution entirely dependent on the "chattiness" of the smart plug used to evaluate power consumption. The load on the hub will also be higher if you have a chatty power plug (increased frequency of database writes when power changes, and an increased frequency of the rule running, presumably triggered by database reads).
If the rules are left with the same overall structure of the two rules described, I would consider restructuring the first such that it is executed only the first time that power was > 71 or < 69 (using rule booleans).
Also, in general, it is a good practice to end IF blocks with an END-IF.
Tagging @bertabcd1234 - he knows a lot more about RM than I do!
Edit:
Wanted to add this - in general, I would think that using *changed* is not going to be much of a performance hit for binary events (open/closed, active/inactive, wet/dry, on/off). It will be more of a performance hit when events have continuously variable values (level, temperature, humidity, power), and the trigger will run as frequently as the reporting device.
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?
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).
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.
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).
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.
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.
Oh yes, looking for "old way" and "new way" it should have been obvious to search for "kiss."
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.
