Moving MSR from a QNAP container to RP 5 - some issues

[Matteburk]

@toggledbits I did have modes in constraints from beginning but then when rule 2 is SET lights turn on in bathroom for 0.5seconds and then off.
as this pics show
Rule 2 is set

and at same time
Rule 1

[toggledbits]

OK. I think I see a bug in the handling of the constraints. I'm still verifying, so sit tight for the moment...

[toggledbits]

Confirmed bug, and fixed for today's build 21087.

After you update (later today when published), go back to using Constraints for the mode filter. As long as the two rules continue to have constraints that don't overlap, the two rules should not interfere with one-another.

[Matteburk]

Ok Great news, 1 more bug deleted! Great fast work P!

[LibraSun]

I don't know if this is germaine to the discussion, but I would feel bad if I did not at least mention that early on in my adaptation of MSR, I found that Rules that included constraints would often not execute according to plan. Whereupon I moved all of the Constraints up into Trigger Conditions and things settled down. I hope that was just an outlier and not indicative of a bug that has now reared its ugly head.

[Matteburk]

@librasun that is what I have done in this case. but still didn't work anyway...... lets hope this update sort it up...

[toggledbits]

"it didn't work" isn't an actionable description, but I would have expected your particular rules to work when not using constraints, as the problem with re-running the reset reaction was specific to the use of constraints. So today's change is unlikely to alter that behavior, whatever it was.

[LibraSun]

@toggledbits I'm inclined to say "YES!" to the need for more elucidation and illustration on the subject of "Constraints" in the MSR Manual. Alas, the "Triggers and Constraints" page (/docs/Triggers-and-Constraints/) -- aside from its title -- currently does not mention Constraints at all.

If I were explaining the concept to someone else, who never used MSR, I'd likely go with, "The Constraints section is intended for additional, often sustained conditions which must also (still) be true when all of the Triggers go true, in order for the Set Reaction to execute. In that sense, they could all just as well appear in the Triggers section."

"So why do Constraints even exist?" they would then ask.

The litmus test I use to differentiate Constraint-type from Trigger-type conditions – and it's more aesthetic than practical, one might argue – is to ask, "How quickly or often does this condition normally change?"

I place the slower-moving conditions (time of day, date, House Mode, sunset, Armed status, weather, battery level, etc.) into Constraints; everything else (power status, counts, dimming level, scenes/remotes, virtual switches, Tripped status, etc.) into Triggers.

How closely does all this jibe with your working philosophy?

ANALOGIES

In MIDI music, "Triggers" are like Note-On and Note-Off events, while "Constraints" function more like Volume and Filters. You can play all the notes you want, but unless Volume is set above 0, there won't be any sound.

In the game of Frogger, "Triggers" are the jumps between lanes and fast-moving cars, while "Constraints" are the floating logs and landing spots. The frog can run around in traffic all day, but unless a log comes along with an open spot, he will never progress any further.

[toggledbits]

I think the difference is this: is the condition something that should cause action if it changes, or is a condition used to allow or prevent action that may be caused by another condition (or conditions). The former are triggers. The latter are constraints.

"Motion sensor trips" is a trigger (to turn the light on). "Only at night" is a constraint.The changing of the motion sensor trip state causes action. The changing of day or night isn't relevant, but whether it is day or night at the moment the motion sensor changes state is.

[LibraSun]

Thanks for the added clarity. I plan to refactor some of my Rules accordingly.