[SOLVED] Conflicting Set Reaction Groups Appear to Fire Simultaneously in Single Rule Evaluation

[LibraSun]

I'm curious what you mean by "reload". Are you editing the Rule, then clicking SAVE and then EXIT? And then clicking EDIT again?

Also, any chance you are still on version 0.1-21128 or earlier and created the second Group Constrain by clicking "Clone" on the first one?

I've never witnessed edits "undo" themselves as I believe you are describing. If the problem persists, definitely file a PR on the Mantis bug tracker system, or message @toggledbits here.

[Matteburk]

ahh, correct wort is Reset , the yellow botton. I save and then go back and reset the rule. I fwill ix a PR for P

[Matteburk]

@librasun I am on latest 30

[toggledbits]

I need more detail on the PR you opened. I cannot reproduce your report. When you open a PR, particularly for a UI bug, please document every step you are taking to reproduce the bug.

[Matteburk]

@toggledbits When reproducing it I think I found out that I have been misunderstanding how u use groups in set reactions.... I think msr puts the entity actions on the bottom because on the first group I have no data. I thought I could have a group with an OR and then 2 subgroups with AND that executes entity actions. But it is 3 groups in the picture and not one group with 2 subgroups.... ?

[LibraSun]

Since this is my first time seeing or even contemplating nested Group Constraints (neat idea!), I've got to ask @toggledbits this fundamental question about the pacing of Action execution:

With this setup in Set Reaction...
SET REACTION ONE

[Group Outer] [AND]
No conditions
  [Group Inner] [AND]
    Condition == TRUE
      Delay=3
      Action A
  [end Group Inner]
Action B
[end Group Outer]

...will MSR perform Action B immediately when Group Inner goes TRUE - thereby triggering Group Outer to TRUE (correct? even though Group Outer has no overt Conditions of its own?) - followed by Action A happening 3 seconds later? Or will MSR attempt to finish executing all of Group Inner's steps first, such that Action A completes followed immediately by Action B?

I strongly suspect the answer is the first of these alternatives. And that if the user intended the second scenario, they should place Action B as the final step inside of Group Inner.

[toggledbits]

Subgroups are always processed inline, so assuming the inner group's constraints were met, the delay + A would run first, then B.

[LibraSun]

Very helpful to know, and glad I asked! Thanks.

[toggledbits]

By the way, you can observe this on the Status tab as well, as the outer reaction group would show "waiting" status while the inner group was running its delay and action A.

[LibraSun]

Funny you should recommend that (though I honestly hadn't tried while fiddling with inner/outer Groups), because that's my normal MO...but I recently noticed that the Status simply wasn't updating in realtime (or at all, sometimes) for one particular simple test Rule.

That rule Sets whenever a light changes dimming level, with these expressions defined:

dim := getEntity (vera>device_110).attributes.dimming.level #works fine, updates in Status whenever Dim level changes
levels = push(levels,dim,5) #does NOT update visibly in Status ... I have to switch to different Rule Set, or collapse/re-expand Rule

I also notice that with each run cycle, the push never pushes just one new value; it always pushes 2, often 3 of the same value (though I believe a minimum of two per cycle is to be expected?). This makes it tricky for me to calculate what the effective change was to Dim since the last cycle. levels[4]-levels[3] kept equaling 0, as did levels[4]-levels[2] in Status. Kind of thing that drives me batty, esp. knowing that it's me not MSR.

[toggledbits]

I'm talking about the Status top-level, not Rule status.