Can a single rule be run concurrently?

Okay...so what's the problem then?!? You can't just repeat the same words and expect me to understand you the second time you say it! Like, oh, i didn't understand it the first time i read it but now that you've typed it again.....

Are you trying to get the 5 min delay to reset so that it only happens once? Because if you have separate rules and triggers with independent delays, and you trigger it twice, the actions are going to happen twice. So, if you have one trigger that happens at time zero and has a delay of 5 minutes and it happens again at time 2mins. The actions will take place at 5 minutes and 7 minutes. Are you saying that you only want the action to happen at 7 minutes? Maybe if you were more descriptive about 2 things: what is current state (what are you seeing) vs what do you want to happen. And a simple breakdown, rather than a summary, would be helpful. And not what you are putting in your rule but what you want to happen out here in the real world.

Sorry man, not sure how I can be more clear. My two requirements are:

  • Lights turn on when: a door is opened, lock unlocked, someone comes home.
  • Lights revert back to previous state 5 minutes after: the last door is closed, or lock unlocked, or someone comes home.

The problem I'm having with the set of rules in my original post is the Action is getting run more than once concurrently resulting in the 2nd run capturing the state of the lights set in the first run so when the Restore happens the lights don't restore to their original state.

I believe using the private boolean as a mutex and a global boolean to track if the lights should be captured will resolve the problem. I'm working on those updates now and will post a solution once I've verified it.

Okay, let me see if I can be more clear. What I am looking for is not a summary of what you want to happen but an example. So, look at the following:

Time 0: I arrive home, lights turn on.
Time 1min: I unlock the front door
Time 2min: I open the front door.

Now, do you want the lights to turn off at 5 mins, 6 mins and 7 mins or ONLY at 7 minutes.

Example 1:
T0: I arrive home, lights turn on.
T1: I unlock the front door
T2: I open the front door.
T8: I close the front door.
T13: lights off

Example 2:
T0: I arrive home, lights turn on.
T1: I unlock the front door
T2: I open the front door.
T3: I close the front door.
T4: Wife arrives home
T9: lights off

Example 3:
T0: I unlock the front door, lights turn on.
T5: lights off

5 minute after the last trigger (arrival, unlock) or condition (all doors closed) lights turn off.

Oi ... now I'm seeing completely unexpected behavior from this action, my conditionals are being run even though they eval to FALSE.

Action:

Logs:

The logs show both conditions eval FALSE yet both lights are getting set to 100% (they are dev 129 & 142)

LMAO....you couldn't just answer the question that I asked could you?

Now, your rules also have capture in them. Are you trying to return these lights to a previous state? Or just always turn them off if they were on previously? Because the restore part is going to open a whole other ball of wax that makes things immensely more complicated. But I will walk through that as well.

Main triggered rule:
Put in here all of your events you want to trigger off of: Arriving home, unlocking, door opening
Condition/rule: I assume you only want this to happen at night, so put that in as your condition and rule within the triggered rule.

Actions for true:

  1. STOP all actions for THIS rule.
  2. Run ACTION A (see below)
  3. Set lights how you want them.
  4. Delay actions for 5 minutes.
  5. Turn on Scene activator.
  6. Set PB true for ACTION A.

ACTION A:
ENABLE PB RESTRICTION

  1. Capture the scene you will create below (by turning on the capture device).
  2. Set PB False for THIS rule.

Scene:
Create a scene with the devices you are going to affect with turning them on or brightening them.

This will do the following:
When the trigger event happens the first time it will capture the current state of the lights. But this will only happen the first time because of the PB RESTRICTION in the Action. You do NOT have to use a conditional action.
Then, it will brighten the lights or turn them on...whatever.
It will then wait 5 minutes.
If another event happens within that 5 minutes, it will reset the delay because of the stop actions for THIS rule at the top.
After the last delay, it will reset the lights to what they were previously and will reset the PB of the capture back to true so that you can capture them again the next time.

If you remove the capture, you can remove the action and the scene and make things a LOT simpler.

1 Like

My 3rd post with the screenshots shows the capture. My first reply to use explicitly says "capture devices". My flow in post 9 shows the capture. You keep accusing me of not answering or reading and I'm not sure you have actually carefully read any of my posts.

It appears the root cause of this whole thread is conditional logic in the rules is being run no matter what the condition evaluates to.

Did you even bother to look at what I posted?!? I am trying to help you!!!!

Not true. That is not your problem. Your problem is canceling your delayed actions of turning the lights off.

Did you look at those logs? They clearly show a conditional evaluating to FALSE and still running the THEN side of the condition. Are you saying this is expected behavior that a condition evaluates to FALSE but its action still runs?

Again....did you even bother to look at the solution I posted? It doesn't rely on conditional actions. So, what's the problem? Plus, conditional actions do work. I have several of them and they work just fine. Will you please look at the solution that I posted?

You also have a stop actions for this rule in the middle of your rule. why is that?

Sure, I acknowledge that your solution looks like it should meet what I'm trying to do.

That is unrelated to the demonstration of unexpected behavior with conditions. Just because they work for you (and they have for me in other rules) doesn't mean I didn't run into a bug right?

The Stop is to clear existing delays, just like the stop in your example. Does the ordering of that stop matter other than it needs to come before the new delays?

I'll be honest, your actions are completely confusing and I can't follow them at all. You are checking a variable and then right after checking it you are setting it true and then below you are setting it false. You don't need to have the stop actions 3 times. You only need it at the top.

When you use a delayed action vs an action of delay, all of that gets scheduled at the beginning of the rule. So, i don't think it is going to work they way you want with putting a delay attached to each action versus having an action of delay. The second stop you have is going to cause the lights to never turn off.

For example, with your rule, the first actions the hub is going to take is to stop all actions and schedule the variable change and the restore of the lights. Then it will capture the lights, then it will brighten the lights. Then your second stop will cancel the GV change and the restore of the lights, causing those actions to never take place no matter how many times the trigger runs.

[BUG] Simple Conditions always executing for the bug report on simple conditionals not guarding their actions.

But that isn't your problem of why the lights aren't turning off. You are canceling them turning off with your second stop actions.

To circle back to my original post. My rules were working as expected and the linked bug broke them :frowning:

1 Like

No, your second stop is going to cancel your previously scheduled delayed actions.

image

The two actions you have that i'm pointing to with the red arrows will be canceled by the stop i'm pointing to with the blue arrow. Delayed actions get scheduled at the beginning of the rule, not in the order you put them in the action. There have been many, MANY discussion about this.

Some Intense dialogue but helpful none the less!! :facepunch: