Since RM 4.0 is a change in how to build rules, I thought I would start a threat so we could help each other make our rules better. Here's one to start.
I have a rule which turns some lights on when it's overcast or when it's evening. I also don't want it to run until after 9:00 in the morning. It runs as it should and that's great. When I first created it, my logs would get a lot of entries since the rule would fire even though the lights were already on. Following one of Bruce's example's, I included the Private Boolean so it wouldn't continue to run when it was already true. This worked and it didn't fire after it became true.
The glitch is that while it's false, it's filling up the logs. Any ideas how to slow that down?
Sometimes posting something makes you think about it a little differently. I modified the rule slightly and put a restriction to only allow it to run between 9:00 AM and 10:30 PM (that's when the house moves to "night" mode). So far the logging has stopped.
@dan.t That is a pretty cool trick. I like that better than using restrictions and will change it now.
What I have done is defined some virtual switches that turn on and off at certain Lux levels. I have 6 of them.
I then use the virtual switch being on or off in my rules as one of the conditions.
For me this serves 2 purposes.
My lighting rules are not re-evaluated every time Lux value changes, only the virtual switch rule is evaluated.
Secondly if I change the Lux level to turn the virtual switches on and off or change the device that measures Lux values, I only have one rule to change not several.
I'm sure this could help with your issue but maybe not.
Just an idea for you to think about.
While I was recreating the rule to include the "ELSE IF Scene" it dawned on me that the the restriction of only running between 9:00 AM and 10:30 should be a condition (doh). So now I've rewritten the rule. I was so focused on not having the lights come on when I was sleeping in that it blinded me (bad pun intended) to the obvious. Go figure.
I have a question about terminology for @bravenel . And I've chundered up the other thread, so I'll give this one a go.
With Rule 4, I notice that evaluate rule is no longer available. I presume that run rule actually evaluates the RM4 rule (as if it was triggered), since there is no "true" side to auto action.
@bravenel After I changed the rule above, I cloned it to cover other parts of my house. When I did, the Private Boolean didn't stay as "This Rule." They pointed to the original rule. Is this by design?
No, Rule Rule Actions runs its actions. Note that Run Rule Actions is effectively the same as triggering it, since triggering it causes its actions to run.
Yes, references to rules are based on the app id of the referenced rule. These don't change. You can even change the name of the referenced rule (on its own app page), and the reference stays intact.
That's kind of odd though in a rule clone. If you clone a rule, and the original had a reference to itself.... Shouldn't the cloned rule also reference itself instead of the original?
It makes sense that non-self references would remain the same in the cloned, though.
I get that isn't how it works today. Just thinking out loud how I think it should work.
Meh, you have to modify a cloned rule, and this is just something that has to be modified. I've been gradually changing how self reference rule actions (PB, et al) work, so this may change in the future.
another stupid question, how do I check presence state? I only see "changed" for any presence device. I basically want to have (if presence.present then do A else do B)
Probably not. They certainly offer two different ways of thinking about automations. There are some Rules in particular (Rule-3.0 meaning of Rule) that are hard to do in 4.0 but relatively easy in 3.0.
Your opinion matters. This is one reason that 3.0 is still available.
What I'm finding is that different people think in different ways. For some people, the form of RM-3 is very confusing, and they have a hard time getting it. Yet, they get RM-4 very easily. The opposite is undoubtedly going to be true also.
When you add more choices to an app, it introduces confusion about which one to use. But, you might be right. I'll think about it.
I definitely fall under the category of "different" And while I did find RM 4.0 confusing at first, I think it had to do with the fact that I opted to convert most of my existing rules and attempt to combine them when possible. When building a new rule, especially a complex one, RM 4 is definitely more powerful!
When I first started using smartthings I found it super easy to work with, until I wanted something more than just a way to automatically turn on/off a light with motion.
This brought me to WebCore, which was infinitely more powerful, but far more challenging to fully understand at first.
Rule Manager 2.x was a step back requiring multiple rules to achieve anything close to what I had become accustomed to.
Rule Manager 3.x was a step forward in flexibility and RM 4.x is just the icing on the cake! I'm currently at the point where I don't miss WebCore anymore, my automations are just the way I like them.
For those that hate the change, I think a 24-hour test drive is too short, get to know it a little longer, I bet it will grow on you.
And while I did find RM 4.0 confusing at first, I think it had to do with the fact that I opted to convert most of my existing rules and attempt to combine them when possible. When building a new rule, especially a complex one, RM 4 is definitely more powerful!
