Pause/Resume vs Restrictions

@bravenel @patrick, Other than the visual feedback in the GUI are there any functional differences between using the pause/resume feature to enable/disable an automation versus using a restriction within the rule?

For instance, is the rule still evaluated when it's paused just not acted upon? Or if a rule has a delayed/repeat action does pausing it also cancel this?

I realize some experimentation would answer this but just thought someone else might be interested in an official statement.

I know you're not asking for my response but I thought "Pause" is functionally equivalent to deleting the rule.

Resume is functionally equivalent to adding it back.

Clearly, the steps to restore a deleted rule are lengthy and that's the big motivation for asking for this feature, I believe.

If that's the case, is a rule evaluated when it is resumed? If so, that's a definite plus.

Pause is treated as a Restriction. If the rule is paused, nothing will happen while it is paused. This would effectively kill any repeating action, and kill any delayed action.

1 Like

Thanks, so does that mean a paused condition is automatically re-evaluated when it's resumed?

No, Restrictions have nothing to do with rule evaluation. They simply stop it from doing anything at all. Only conditions changing state causes a rule evaluation (or another rule action doing it).

Thanks again!

@bravenel

How does RM handle both resume and evaluate in the same rule? I have had mixed results trying to use both. I pause everything for large actions like my Movie Time routine or lux rule. But I have found after resuming it could take the full pending cancellation time (8minutes) before resetting correctly.

When I have tried both sometimes the rule never unpauses or doesn’t evaluate but does unpause.

As I said above, Pause and Resume have nothing to do with rule evaluation. Pause only stops the rule from doing anything at all, and Resume removes that restriction. They are not connected to the automations or rule evaluation at all.

If you have an automation that needs to do something when you "un-pause" it, then Pause and Resume are not the right mechanism. Instead you would want to do something involving Private Boolean, which can be part of a rule's conditions (e.g. Private Boolean is true, which would be evaluated when it changes state).

Thanks for the thorough explanation! It helped me modify some of my rules and actually allowed to to eliminate a couple of redundant ones!

@bravenel

I understand they don't have nothing to do with the rule's evaluation portion. I am asking in what order does the "Pending Cancellation" happen verses the "Evaluate these rules" in a specific rule itself. Meaning does one always get executed prior to the other?

Example:

  • Rule #1 true pauses light motion #1
  • Rule #1 false resumes light motion #1 and THEN executes the "Evaluate these Rules" which is set to light motion #1

OR is it

  • Rule #1 true pauses light motion #1
  • Rule #1 false executes the "Evaluate these Rules" which is set to light motion #1 and THEN executes the resume light motion #1

OR does it randomly pick evaluate and resume?

This is my question within RM itself.

Thanks!

I still don't understand what you mean about the relationship between pause and resume, when you say:

Pending cancellation is based on a timer. That timer is independent of everything else in the sense that when it expires, it's going to take whatever action was specified. Cancellation of that timer happens whenever the truth of the rule changes. The truth of the rule is determined every time any event happens to any of its conditions. Should such an evaluation caused by such an event result in the rule truth changing, the pending cancellation timer is canceled (why it is called "pending cancellation").

If a rule is paused, actions in other rules that act upon that rule will do nothing until it is resumed. The relative order of event execution within RM is such that Resume is happening after other actions on other rules. That could be changed, and perhaps it should be, so that Resume happens before other actions of that rule.

@bravenel

Ok I didn't have my coffee quite yet and I am on only 3 hours of sleep. My apologies.

I do not mean Pending Cancellation. Ugh! My bad. I meant Pausing/Resuming and Evaluating a rule within a rule construct. Which gets executed first in the RM logic of a rule. Pause/Resume or Evaluate? Does the scenario make more sense now?

Example:

  • Rule #1 true pauses light motion #1
  • Rule #1 false resumes light motion #1 and THEN executes the "Evaluate these Rules" which is set to light motion #1 to get the lights going again quickly

OR is it

  • Rule #1 true pauses light motion #1
  • Rule #1 false executes the "Evaluate these Rules" which is set to light motion #1 and THEN executes the resume light motion #1

OR does it randomly pick evaluate and resume?

Read the second paragraph in my post above, it answers your question.

Again my apologies...lack of coffee and sleep. It would be nice if the resume/pause was executed prior to evaluation as this would enable more flexibility with using the rule choices.

1 Like

Done. Next release.

Resume will come before other actions that act on other rules, and Pause will come last of those.

2 Likes