Common RM patterns

[Jim_UK]

Since joining HE some months back I have dipped my toe into RM several times and more recently had some success with using the local boolean to control the rules and get slightly more complex. The documentation is great at explaining the individual features but they are still quite hard to bolt together and understand how one feature will impact another. Could we as a community identify a set of 6-12 common patterns used to perform different tasks to help new-comers understand how to set up these up with the appropriate features.

What made WC so powerful was the ability to replicate the pistons based on the unique ids. In the absence of that could we use these common patterns to help users get started? I appreciate the the number of permutations of the rules/triggers is infinite, but could we loosely qualify what our rules are doing based on these 6-12 patterns.

For my part I have mostly trivial examples:
SIMPLE RULE - simple automation subscribed to certain devices that have true and false actions. There are no dependencies on other rules.
SIMPLE TRIGGER - A trigger will cause an action. No dependancies.
TRIGGER PAIR WITH PRVATE BOOLEAN - A pair of rules that are triggered by an event and use private boolean to control the flow of events. The primary rule will set its own private boolean to false to prevent refire and the second rule will enable it again after a period of time,
...further example of when to use RULE TRUTH....

I am sure there are more examples out there, I would like an example of how to use RM for motion lighting as I could never get that working. If we can get agreement on what the basic patterns are it would be pretty easy to trun it into a useful resource.

What do you think? This is not a new idea as saw recently where people have asked for this sort of thing, But after several months of HE I for one am still slightly intimidated by RM and all its features and still need help.

[jrfarrar]

This sounds like a great idea. The complexities of RM are not intuitive for "blocking together" I think some basic example would be fantastic. I think what might be harder is the nomenclature. A bunch of screen shots with rule truths are not easy to follow or understand. There must be a better way at visualizing what's going on. Maybe some kind of flow chart?

[pgiesenhagen]

I agree - probably because beyond basics in RM I have no idea what some of the fields do or their effect on things. I'm sure they make sense to those who are discussing every field all the time, but for us new to hubitat its a bit overwhelming.

Oddly once something is explained by example then it makes sense and can roll that knowledge into many other places.

Community is extremely helpful - but searching for solutions can really bog down on the little things that make huge differences.

[drew]

Great Idea, as a newb I have not delved into using the private Boolean yet and this would help. Still trying to retrain my brain. I came from Vera so I did not use WC and pistons, I was using a system called Pleg. Pleg was a LUA based tool and had the ability to use the time stamp of last true or last false for triggers and conditions, came in very handy.

The other thing that was handy was the ability to create status reports that showed the time stamps of last true and false for triggers and conditions along with the logic of the rules. This made troubleshooting much easier.

[csteele]

Booleans are simple yet lead to complex opportunities.

Boolean is a logic term for 2 states: True/ false; On / off; Up / down; etc. In Hubitat, the "True / False" words are used. Private means there's one Boolean available to EACH and every Rule, and it can only be "used" by that one Rule. Any/all rules can set or reset (make True or make False) any other Rule's boolean.

But only the "owning rule" can make use of the state. Booleans are initialized as TRUE. When you reboot, all the booleans become True. That means sometimes you'll want to invert your thinking about the state.

You can "cross connect" rules via their booleans... "If you set mine, I'll reset yours."

Ok, so there are booleans, you know you can set and reset them BUT nothing happens if you do !! You have to ALSO say what to do with them.

Every Rule has a native use of the boolean...

You'll see it's disabled, and yet it's current state is the default initialized state of [True]
If you enable it and do nothing else, nothing extra happens The boolean is True, meaning the Rule is Enabled.. well it's that way anyway. Obviously if you cause that boolean to become False, that rule never runs again.

This is why RM is considered "Legos" - each rule is a building block. Maybe one block is all you need. But if you need more, then the features such as boolean are the "notches" that allow them to become interlocked.

You can test your Rule's Boolean as a condition or within the Rule. A Rule can set/reset it's own boolean or another Rule's.

That's the menu for all the building block options. Building complex rule SETS is via items in that menu.

It's certainly not my expectation that a "dump" of my mind's assembly of these features is transferred easily to another's... but I've built reasonably complicated Rules.

[drew]

I think I'm connecting the dots now. Are these statements correct?

So the boolean is a enable / disable, but will not force a rule with triggers or conditions to be true and run unless the triggers or conditions of the rule are also true?

I could create a rule with only actions and no triggers or conditions and setting boolean true would force it to fire and I would then have it set itself to false as one of the actions?

[csteele]

hmmm...

"So the boolean is a enable / disable" <-- can be.. it's just ONE of the uses for boolean, the rest of your sentence is true.

"create a rule with only actions and no triggers or conditions and setting boolean true would force it to fire and I would then have it set itself to false as one of the actions?" <-- there's a better way, but you're getting the idea.. use "Run Actions of these rules " instead for that particular case. Same menu, different tool.

[Jim_UK]

Hi csteele, I get what the Private Boolean is and how it can be implemented, but I think whats needed is to de-mystify it. To do this we need some common reasons to use it. Its the why use private boolean not really what it does (although that certainly helps).

So in my example 'TRIGGER PAIR WITH PRVATE BOOLEAN' that I mentioned above, I have a number of triggers/events that are combined using ORs so there can be many instances of the same rule firing at once if multiple events fire. So I wanted the first rule to execute the action to win and the others to hit the false boolean, so the first instance sets the private boolean to false. The actions that wins gets to tell Alexa to speak a message. If they all fire at once I get a very garbled mess of messages. So my pattern here could be said to be a 'TRIGGER PAIR WITH PRIVATE BOOLEAN TO CONTROL RACE CONDITION'.

Can you say what different ways you have used the RM blocks to achieve different things. There is also Rule Truth, when would I use this, its not so much what it is and how it works but when would I use it? Maybe I am barking up wrong tree here , but just seems to me like there must be some common patterns of usage that we can describe.

[destructure00]

For any of you who have used webcore, I've found that private Boolean is a great way to duplicate "execute on piston/condition state change only" or latching type logic.

I.e. I want the actions to execute only the first time the rule becomes true, then use some other condition to reset.

One of my use cases for this is when we go to bed, I pre-set a handful of dimmers to a low level so if they are turned on at night they go to 1% instead of 100%. Then the first time (and only the first time) they are turned on the next morning, I have them go to 100%.

Another use case is that I want to get a notification when the hot tub temp exceeds 99 degrees. Creating a rule or trigger for temp > 99 results in a notification every time the temp sensor updates. I use the private Boolean to prevent the subsequent notifications.

[Jim_UK]

This sounds like PATTERN 4: TRIGGER PAIR, ACTION ON FIRST STATE CHANGE ONLY, RESET AFTER EXTENDED PERIOD.

I am beginning to appreciate the weight of what Jrfarrar said earlier 'I think what might be harder is the nomenclature'. This is subtly different to what I was attempting to do in PATTERN 3.

So far I have:
1. SIMPLE RULE - simple automation subscribed to certain devices that have true and false actions. There are no dependencies on other rules.
2. SIMPLE TRIGGER - A trigger will cause an action. No dependancies.
3. TRIGGER PAIR, ACTION ON FIRST STATE CHANGE ONLY, RESET PRIVATE BOOLEAN AFTER SHORT PERIOD TO AVOID RACE CONDITION - with a number of triggers/events that are combined using ORs there can be many instances of the same rule firing at once. So we want the first rule to executing the action to win and the others to hit the false boolean, So the first instance sets the private boolean to false. The actions that wins gets to tell Alexa to speak a message. If they all fire at once I get a very garbled mess of messages.
4. TRIGGER PAIR, ACTION ON FIRST STATE CHANGE ONLY, RESET AFTER EXTENDED PERIOD TO ENABLE DAILY CONTROLS - When we go to bed, I pre-set a handful of dimmers to a low level so if they are turned on at night they go to 1% instead of 100%. Then the first time (and only the first time) they are turned on the next morning, I have them go to 100%.

I work on the wording as we go, please comment.