Simple Lighting rule understanding

[jrfarrar]

With my push to try to use the "Simplest" method available for my automations I went to look to reduce a lot of RM rules that maybe could be done with built in apps. I have what I think is a simple rule. I have a door underneath my deck. It has a light outside of it. The door has a contact sensor and the light is on a zwave wall switch. The RM rule (2 of them) turns on the light if the time is between sunset and sunrise if the door is opened. The second rule turns off the light after 5 minutes.

This seems simple enough to do in Simple Lighting. Here is the rule.

Question. In RM the "Restrictions" were pretty hard restrictions. Meaning that if I open that door 2 minutes before sunrise. The light will not go off in 5 minutes. In fact it will stay on until the next time that door is opened after sunset. Is my understanding correct? If so then this probably still needs to stay in two RM rules?

[bravenel]

@jrfarrar

Is my understanding correct?

Yes, Restrictions are "hard", as you put it.

[destructure00]

You should be able to accomplish this in a single rule. Here's one that I have set up very similar to what you are asking.

[bertabcd1234]

I had to re-read to be sure, but the original poster meant "rule" in the sense of "Simple Lighting child app," where child apps of this category (Simple Lighting, Motion Lighting, etc.) are sometimes loosely also called "rules." It's certainly possible with one in RM, but there was some discussion in another thread about the amount of overhead that imposes for simple tasks like this compared to purpose-built apps.

BTW, I've never used "Cancel Timed Actions" as set up in your rule, but I'm assuming it cancels all delays, even those without "cancelable" selected? Most of the time such rules would be set up with "Cancel Delayed Actions" instead, then the "cancelable" flag enabled on the delay--but since you don't have any other timed actions (or periodic triggers) in your rule, this would be equivalent...just good to know that this is what it actually does since I've never used it that way before.

[jrfarrar]

@bertabcd1234

original poster meant "rule" in the sense of "Simple Lighting child app," where child apps of this category (Simple Lighting, Motion Lighting, etc.) are sometimes loosely also called "rules.

Correct, I was referring to a Simple Lighting child app. Was attempting to just see if I could move some of my RM rules into built in child apps to simplify.

Other than Motion lighting, of which I've moved ALMOST all of my lighting rules related to motion to...I'm not having luck moving my other rules out of RM.

I don't have a NEED to do this, I was sort of a pet project.

Thanks for the replies.

[jrfarrar]

@destructure00

@bertabcd1234

BTW, I've never used "Cancel Timed Actions" as set up in your rule, but I'm assuming it cancels all delays, even those without "cancelable" selected? Most of the time such rules would be set up with "Cancel Delayed Actions" instead, then the "cancelable" flag enabled on the delay--but since you don't have any other timed actions (or periodic triggers) in your rule, this would be equivalent...just good to know that this is what it actually does since I've never used it that way before.

Curious about this too. How has this been working? Seems like a VERY simple and effective way to do this.

[destructure00]

I think that's what it does?? That's how I've been using it anyway, seems to work fine.

Maybe @bravenel can clarify for us

[bravenel]

The UI explains it:

[destructure00]

RTFM of course, why didn't I think of that?

[bravenel]

Huh, not RTFM, just use the app!

[bertabcd1234]

Honestly, I still find the "manual"/app a bit unclear on this: we have "Cancel Delayed Actions" versus "[cancel] all Delayed Actions," and while the latter is definitely a strong hint that you don't need to mark "cancelable" on the Delay, nothing in the former insists that you need to except R-ing TFM or seeing enough examples to know what you're doing, and people who know that you need to do that may be rightly cautious as to whether the former will do the same without setting this flag (obviously delayed actions are not the only target of this broad action).

I'm not saying there's a good solution to this--just pointing out my thought process and caution. I couldn't find this in the documentation anywhere for Rule Machine or Rule 4.0, so it might be a nice addition. I'm not sure if it was documented for older versions, but when I point people to the 4.0 docs I don't like to also make them take a history lesson if they don't need to. I barely expect most people to read them anyway. Haha.

Of course, now that I can edit the docs wiki, maybe I should just do this myself ... and add in the missing screenshots or links to them while I'm at it.

[bravenel]

Sorry for my slowness in keeping the documentation updated.

Here's the explanation:

In the ordinary course of creating rules, there are delays that you want to be able to cancel. The primary example of this is a delay to turn off some lights after motion goes inactive. You want to be able to cancel this sort of delay if the motion sensor goes active again before the timer runs out.

At the same time, there are other delays, quite possibly in the same rule as a cancelable delay, that you do not want to cancel when the motion sensor goes on or off. For example, something else may want to be activated or deactivated at some specific time later no matter what, or the rule may end with a Wait for Event at some future time (another way to do a delay using a specific time instead of a duration).

For these reasons, there is the option to make any delay cancelable -- or not, and there is the corresponding action to cancel those cancelable delays.

There is a problem here with the overloading of words. The action called Cancel Rule Timers was originally intended to be used as an inter-rule mechanism. This is so that a Periodic, or a dimmer Fade, or a Repeat, that otherwise would keep on going can be stopped. This action used to be called Stop Rule Actions. However, some people took that name to mean that it would stop all rule actions, something it doesn't do. What to do about naming? All of the things that are "canceled" or "stopped" by this action involve timers, i.e., future scheduled events. What this action does is wipe out all future scheduled events for the target rule. The target rule can be **This Rule**.

With something that wipes out every pending scheduled future event for a rule, Stop Rule Timers can clearly be used for lots of things, whether the app author intended that or not. It states clearly what it will stop in the UI. Frankly, it's a bit of an overkill way to deal with scheduled actions or delays. But, so is Cancel Delayed Actions, since it cancels all cancelable delays. Some have requested a more nuanced ability to cancel specific things. Oh my, but the complexity of this could just go on and on, until no one could figure out what any of it means or how it works!

Please do lend your help on the documents wiki!