Can someone explain for me how to use Reset reaction in MSR without disturbing other rules.
-
I have a strong suspicion that both of your rules are running simultaneously because they are reacting to very (overly?) similar conditions. That is, when the light is increasing from Off to 100%, it passes 20% and may thereby trigger Rule 1.
You could include a Restriction on that Condition such that the dimming level "Must be sustained for at least 4 seconds" or so. -
I have a strong suspicion that both of your rules are running simultaneously because they are reacting to very (overly?) similar conditions. That is, when the light is increasing from Off to 100%, it passes 20% and may thereby trigger Rule 1.
You could include a Restriction on that Condition such that the dimming level "Must be sustained for at least 4 seconds" or so.@librasun said in Can someone explain for me how to use Reset reaction in MSR without disturbing other rules.:
when the light is increasing from Off to 100%, it passes 20% and may thereby trigger Rule 1
Yeah, but Rule 1 doesn't say that. Rule one seems to be triggered exclusively by the motion sensors, and as posted (screen shot) potentially by a change in mode if a motion sensor is active at the same time (moving the mode check to Constraints solves this).
I would not expect the RESET reaction to run in this case, but I'm also not watching the state of these rules. This might a case where putting both of these rules into the Scope and watching their state interact with each other would be educational. If anything is triggering rule 1, that would be obvious there (also looking just in the status view for the rule at a changing timestamp). But I don't see why the reset would run for rule 1, and I'm off to do some code review and see if I can back into reason...
-
@crille said in Can someone explain for me how to use Reset reaction in MSR without disturbing other rules.:
o, but it will prevent the Reaction to run, thus the Reset Reaction?
THAT is true, so we need to be careful how we phrase it, because your other statement is incorrect and misleading, and would give other readers the wrong idea. But you are correct in the last: if the SET reaction does not run, neither can the RESET, because RESET will only follow SET (once the basic state of the rules has been established).
@toggledbits Yes, you are correct. My goal in my head was to make the Constraints condition FALSE to prevent the SET Reaction.
-
@librasun said in Can someone explain for me how to use Reset reaction in MSR without disturbing other rules.:
when the light is increasing from Off to 100%, it passes 20% and may thereby trigger Rule 1
Yeah, but Rule 1 doesn't say that. Rule one seems to be triggered exclusively by the motion sensors, and as posted (screen shot) potentially by a change in mode if a motion sensor is active at the same time (moving the mode check to Constraints solves this).
I would not expect the RESET reaction to run in this case, but I'm also not watching the state of these rules. This might a case where putting both of these rules into the Scope and watching their state interact with each other would be educational. If anything is triggering rule 1, that would be obvious there (also looking just in the status view for the rule at a changing timestamp). But I don't see why the reset would run for rule 1, and I'm off to do some code review and see if I can back into reason...
@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
-
OK. I think I see a bug in the handling of the constraints. I'm still verifying, so sit tight for the moment...
-
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.
-
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.
-
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.
-
"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.
-
@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. -
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.
-
T toggledbits locked this topic on
