Yes, this is correct.
It is important to realize that conditions in Actions are not like Conditions in Rules. A condition in an action is evaluated when the action runs. It has no subscription to events, so its state changing doesn't cause anything.
Only Conditions in a Rule have subscriptions to events. Only events happening to these Conditions cause Rule evaluation, which in turn causes Actions for True or Actions for False to run.
In this case, this rule is going to be evaluated upon these events: Time becomes Sunset, Time becomes 23:50, and Mode changes. If it evaluates to true (time between and mode is Away), then it's going to run Actions for True. If it evaluates to false, the repetition started in Actions for True is going to stop (and Actions for False will run). So the repetition will begin when it becomes (or is) Away between Sunset and 23:50, and it will stop when Mode becomes other than Away or 23:50, whichever happens first.
Will the actions within the repetition still complete if it becomes false while a timer for one of the lights to turn off is counting down?
Light has turn on
Timer to turn off starts.
Rule becomes false.
Light should turn off. Will this happen?
Yes, as long as the delay does not have Cancel on Truth Change.
This is looking better all the time.
This is what i missed I didn't realize this and thought that as long as the main rule was in true or false (whatever the conditional action was in) this is what would now be followed. All good information
I'm beginning to grasp some concepts here (I think)
Logic behind a simple condition/action(true):
1-Condition to evaluate (let's assumed the "State" is False)
2-Wait for the "State" to become True (Truth Change)
3-Run the Action
4-Wait for the "State" to become False (Truth Change)
(Which means, do not re-execute the same Action over and over even though
the Condition(1) is still True)
5-Go back to 2
I think for you guys, "State" means "Private Boolean", but I prefer "State"
Am I getting somewhere?
Private Boolean is yet another thing entirely, and in and of itself has nothing to do with rule evaluation or truth, or truth state.
Private Boolean is a variable that can be true or false. It starts out true. Rules can set it, including the rule it belongs to. The rule it belongs to can test it as a Condition or Trigger Event, or in a conditional action. The rule it belongs to can use it as a Restriction, so that the rule can be disabled by it. It has many possible uses. However, it's value (true or false) has nothing to do with the Rule Truth of a rule (also true or false).
Ok, got it. Private Boolean is like a switch that can be tested almost everywhere. Good.
Is it changing value automatically under certain condition or must we change it ourselves.
BTW, @bravenel thanks for all your help. Really appreciated!!
It does not change automatically on its own (at least not in any way I know of).
It only changes when it is set by a rule. Any rule can have an action to set it, including the one it belongs to.
Bruce, If a rule sets it's own private boolean to false, would that mean it could pause forever until another different rule set it to true. I was thinking of using this for a problem I'm having, but was wondering how to set the private boolean of original rule to true. (Since I presume, that private boolean to false pauses/halts that rule from running).
You would have to set up a Restriction for Private Boolean to disable the rule.
One of my uses for it is this: I have a rule that I don't want to run except in a particular circumstance. It's conditions are such that it would run all of the time, mostly when it shouldn't. So, the other rule involved, the one that detects the special circumstance sets the PB of this rule to true and then causes it to be evaluated. The rule runs, and it is either true or false. If true, it sends me a message. For both true and false it sets its own PB to false. It has the restriction for PB.
See how that works?
Now, someone might ask, why don't I use a triggered rule instead. The answer is that the special circumstances do not fit a trigger, but are themselves the result of a rule evaluation. So when this rule goes true, it delays for a minute, then sets PB true for the first rule --> and then forces it to run.
Restrictions are tested before anything at all happens with Actions. If the rule is restricted it doesn't run. In this case, I need to prevent the first rule from running, and the easiest way to do that is by restricting it. Then I lift the restriction, and force it to run (Evaluate Rule in Actions).
I'm finding that RM3.0 is not resuming rules.
Those two rules have not come out of paused state twice in a row this morning. It coud very well be user error.
Edit: for clarification, those two rules are also RM3.0 rules. And I have another set of rules (RM2.5) where rules are being paused/resumed OK.
Resume doesn't make anything happen, except in the case of a rule that was repeating, in which case the repetition starts going again.
Pause and Resume simply restrict the rule completely, and then unrestrict it. This can be used like PB as I described above. But lifting a restriction is not an event for the rule.
Did you refresh the page? These pages and that indicator are not dynamic. Open the rule itself, see what it shows internally.
Yes, page refreshed. Both rules are paused.
Top of rule page, just now. Garage door shut 10 mins ago.
OK, I will investigate...