Rule Machine - Migration from ST/WebCORE help

Ah, apologies for the confusion.

Hope @JHoke isn't still left in the dark about this.

1 Like

Btw, you can Capture the state of a light now. I'm not sure this was an option when he posed the question but it is an option now.

Does it work for dimmers as well?

The option is under Control Switches but I'm pretty sure it captures all the attributes including level.

Use two Simple Lighting rules. One for motion with the turn off after motion inactive. The other for the contact with no turn off part.

1 Like

Just reading this topic now. It looks like you guys are over-thinking this. I'd be glad to help.

Pose the use case: I can show you the simplest way to do it. Often RM is not the simplest way -- it depends on the use case.

Motion Lighting, Mode Lighting and Simple Lighting were all added to deal with common lighting situations, where while it could be done with RM, it would take multiple rules/triggers to do it. So sometimes in more complex situations there may be multiple 'rules' to use, but not necessarily RM rules.

Very likely the case here :slight_smile:
But for my knowledge ...in the scenario @jrau272 described initially...and assuming that motion may not occur after the contact sensor is open....how would you accomplish this?

this seems to work.

@bravenel does it matter if its two rule machine rules vs two simple lighting rules? is one faster or more efficient than the other? or is it just easier setup?

thanks for the assist everyone

1 Like

If that's the use case, and it's to be taken literally, then, as I said above, two Simple Lighting rules (or an RM rule and a trigger).

First rule deals with the motion part. Turn on when motion active, turn off x minutes after motion inactive. Simple Lighting can do this, or an RM rule like this:

Condition: motion active
Rule: motion active
Action for true: turn on light
Action for false: turn off light after x minutes pending cancellation.

Each of those methods will have the same result (as Simple Lighting implements the cancellation logic). The cancellation logic means the light remains on until motion has been inactive for x minutes, but additional motion before x minutes keeps the light on.

The contact part is super simple: Just turn on the the light when the contact opens. Period. There is no off part at all (at least as he wrote the use case above). Again, Simple Lighting would do it, or an RM trigger.

If he didn't state the totality of the use case (e.g. wrt the contact closing, etc.) then the solution would change. The use case must be stated accurately to get the right answer.

My approach is always to use the simplest app that works. So, in your case, I'd use Simple Lighting for both rules. But it doesn't really make much difference. RM is a much larger app, so in theory it eats more CPU time and RAM to run it, but we are way undertaxing the CPU anyway, so it's not a big deal. More a personal preference thing than anything else.

When it starts to matter is when you layer in other complexities. Motion Lighting has a lot of features for more complex lighting triggered by motion (like able to disable it with a button, disable it for certain periods, re-enable it at some time, etc.).

1 Like

I have all my closets set up with Simple Lighting. Door Opens, light comes on. Door closes, light off.

The rest is in RM. I haven't checked out Motion Lighting yet.

Agreed but hypothetically, assuming that the contact sensor opening may not be followed by motion...how would you ensure that the light will shut off after inactivity. I ask ONLY to learn how you would handle this scenario and increase my proficiency with RM.

edit: Sorry, misread

Oh duh, right. But wouldn't it stay on if the motion sensor didn't detect you? I'm getting a little silly with my line of questioning I know, because the chances of it not detecting you at all are so slim, that if it did, you should get a different motion sensor! :joy:

I'm just asking to make sure I understand the logic :grin:

No problem...its the exact reason I was asking Bruce the questions above...all in the name of learning sir.

When the contact sensor opens:

  1. The light will turn on
  2. The first rule will be evaluated....to false which
  3. Should start the timer to turn off after 3 minutes

At least that's my theory :smiley:

1 Like

I moved all my Motion Lighting, Smart Lighting and even Room Manager automations to RM and I've been forced to learn a lot....but there's still so much more to learn. Every time I read another of these RM threads I learn at least one new thing or a different way to approach the problem.

For instance, I just learned from @bravenel that it's better to use Motion Lighting etc, rather than RM for these types of rules. It makes sense now that I think about it but my rationale was the opposite before reading his post above.

1 Like

If there is no activity, there won't be an inactive event sent. So the light would stay on.

Not a silly question at all. Suppose the contact sensor is on the door to the bathroom. You open the door but don't go in. The light goes on and stays on. There never would be any motion events.

That's why accurately framing the use case is essential.

1 Like

Yes. Hopefully we'll have some consolidated documentation of these great bits of knowledge at some point. I never really thought about the CPU or RAM usage either because we've been told there's so much capacity available that I never even considered factoring that in. But it makes sense in the long term to optimize efficiency as the hub capacity is consumed more and more by app and drivers.

I tried to refine a RM rule to get just what I wanted in my hallway and it worked, but then I instead used a simple lighting rule and it was perfect with less than a minute of configuring! :rofl:

1 Like

Which brings up the question: What is the purpose of the contact sensor? What is the scenario where it is important to turn the light on with it? If the light is turned on with the contact sensor, what events are going to turn the light off later??

1 Like

Indeed!