Thanks to the flexibility of the HE System (
) it seems there are many ways to implement actions. As my RM items get more numerous I am beginning to wonder if triggers or conditions are more efficient/less system impact.
Anyone have any thoughts on this?
My understanding so far:
A Trigger is an event that you want to result in an action. E.g. if this light switches on then turn on this switch. I think some device events lend themselves more towards triggers like contact open or switch on.
A Rule is more about evaluating a set of attributes/modes together to make up complex (or simple) logic and then firing an action either when evaluation is either true or false. One thing I am not sure about is whether there is any scheduling behind these (so it checks every minute for example) or whether the subscription model suggests its a real time thing. I suspect the latter.
These 2 can then be combined so Trigger can evaluate a rule in a triggering rule..
Be interested to see what others think and whether I am getting to grips with RM. For me the penny dropped when I began to use rule truth. Having said that I have since moved all my motion lighting rules back to the Motion Lighting app as thats way more powerful than I first appreciated.
I'd like to see a simple way of having time based evaluations, such as contact sensor remains open for 10 mins. I cant see a quick way to do that, without creating virtual switches.
Mike, I think that's answered here Rule machine: contact sensor
*Edit - I see you actually posted on there so already aware - apologies
That is what I was thinking as well.
I can create a rule to test for door open/closed or have a trigger that tests for one or the other OR have a trigger rule that tests for both and then a rule that tests for open/closed. Which one should I be considering as a general rule for efficiency/stability/least resource intensive?
My thought was Triggers, Triggered Rules then Rules - of course it all depends on what you are doing.
Also will have to take a look at the Motion lighting app. Thanks!
That can be accomplished with a simple rule.
Condition: contact open
Define: contact open
Action for true: delay 10 minutes pending cancellation
+whatever you want to do
One word that @mike put in there was remains open.
I see that you mentioned pending cancellation, I couldn't find a way to use restrictions to do that reliably. Probably doing it wrong.
How I found to do this was to have another Trigger that says if the contact changes to close then cancel all actions for the first Trigger.
One consideration for rule vs. trigger: A rule that has a single condition has a trivial rule (i.e. that condition being true). Such a rule with only actions for true is effectively a trigger, and usually should just be a trigger instead of a rule, for simplicity.
There is a notable exception to this: If you need a delay that cancels upon truth change, that can only be done in a rule (not in a trigger or in a triggered rule).
Not sure this is what your are looking for but HSM has custom rule you can create for monitor contact sensors and other capabilities.
okay that's good to know thank you... I'm going to have to review my RM rules/triggers to see if I took that into account.
Pretty good example. I guess the rule segment continues to check that the contact sensor is open.
I still don't understand the rule part of the rules. 
I've accomplished everything from my large WebCoRE library using just triggers.
I can probably consolidate some if I start to trust the rules more.
I am trying to wrap my head around RM + the other HE system apps and when to use them. I feel a little discombobulated!
My infatuation with WC was/is everything in one place and I could see and modify the big picture and logic. However I realize this is more the programmer in me speaking than the user. For the end user it kinda does make sense to have different apps for different purposes when looking at function.
For me It gets tricky when you can create similar functionality different ways via the HE Native apps. I always want to optimize as much as possible but I don't feel I have a good understanding on how to do this properly. I also think having more ways to do something is a actually good thing - can provide different possibilities, workarounds etc.
It was really hard for me to leave WebCoRE as well.
In my mind it's still the perfect rule engine for the smart home at the moment.
Rule Machine is growing though.
It's gained some features similar to WebCore.
It would be nice if WebCoRE could be officially supported in a Hubitat optimized form that doesn't cause hub crashes...
An officially supported webcore would cut down on the number of questions asked....... Putting Bruce out of a job!
I'd like this also. Just a tad bit of work...
Good to hear it's not out of the question. I've liked Rule Machine since I found it on SmartThings. But WebCoRE reminds me of the applications I use at work. It's just how my brain is wired. Everyone is different.
I don't know about that less questions comment. I recall seeing a lot of "I need help with a piston X" questions being posted on that legacy hub system forum I used to use.
I like what RM offers, I feel like I can see all my options as I'm working, whereas with Core (I never switched to WC) you had to have a clear idea of how the rule worked before you started or you end up rewinding everything you did and starting over. I'm a big fan of APPs like Room Occupancy Manager, and wish HE supported a house model.
By that I want to define rooms and put things in it. So I can create rules assigned to a room and use house wide or room wide variables for lights, switches, and sensors. Wouldn't it be nice to write a rule to turn on a rooms lights on motion, by just making a rule by typing Turn on lights when there is motion. Where the localization of the rule is decided by where you create it. I feel like most of us doing home automation are in the IT or some engineering industry. I don't want to have to wait on Google, Amazon, or Facebook to make an interface for the masses.
Sorry if that's long winded or disjointed, I stopped somewhere in the middle to cook dinner.
Mike
This is on our roadmap. We agree with your idea.
In my mind it would be cool if it was more abstract. Like if you could define an advance group that was like a virtual device that could contain devices and other advanced groups. You could then create hierarchical things like a "room" -> "floor" -> "house" -> "property" or whatever you want. The actions/capabilities would reflect the collection of devices/groups contained therein.. and you could use them with other apps as needed.
I know this may be crazy talk so apologies!!
Download the Hubitat app
