DynamicGroupController and attributes

[therealdb]

I'm on vacation and finally moving a couple of scenes from Vera luup to MSR. So far, so good, even if I'll need more time to practice.

One thing that I'm actually doing is to run a dehumidifier with this logic:

• run between 7 and 23 only
• and if the temperature is below 10 C and humidity is >= 70

This is the easy part. The other thing I do is to run the dehum for 2 hours and then wait 4 hours before running it again. I'm too newbie to this and can't figure it out how to properly build this condition, without messing or overcomplicating things.

Any hint is appreciated Thanks.

[toggledbits]

@therealdb I find the easiest way to do runs of fixed cycles is to use "pulse" output mode with a repeat. You can do that on an individual condition, but most often I seem to have several conditions at work, so I'll put the pulse output on a group that contains the other conditions. You set the pulse for the length of time that you want a run, and when you choose "repeat" it will ask for the break length (time between pulses). These are in seconds, so your 2h-on-4h-off example would be a pulse of 7200 seconds with a break of 14400 seconds.

[gwp1]

@toggledbits When using pulse does it do a re-eval of the triggers to see if the reaction should be run again or will it simply rerun the reaction again?

[therealdb]

@toggledbits that seems to do the trick. thanks for the help!

I'll probably have more questions in the coming days, since I'm slowly moving all the logic not involving too much code to MSR.
If I may suggest something for newcomers, blueprints could be a great start. I'm sure it's in your roadmap anyway.

[toggledbits]

@gwp1 said in MSR: run for two hours based on a condition, then wait 4 hours after the reset evaluating again:

@toggledbits When using pulse does it do a re-eval of the triggers to see if the reaction should be run again or will it simply rerun the reaction again?

Well, in a manner of speaking. You're thinking about it backwards, I think. It doesn't need to re-evaluate conditions at the pulse time because the condition state is always up to date, being updated when events within them occur. But I think it works as you would expect: as long as the underlying condition is true, the pulses continue; when the condition is no longer true, no more pulses.

Whether the reactions run depends on the other logic involved, but if we take the simplest case with the only condition in the rule being a repeating pulsed condition, then the rule will set at the start of the pulse (and run the Set reaction), reset at the end of the pulse (and run the Reset reaction), and repeat those reactions for each pulse.

Ref: https://reactor.toggledbits.com/docs/Condition-Options/#output-control-options