MSR UI on a mobile browser

[gwp1]

@toggledbits Def not what I want but it's the direct path. "If after running Neutral the conditions don't match, run the correction."

[toggledbits]

@gwp1 said in Will Pulse work for retrying a ruleset if the device hasn't responded as expected:

Def not what I want but it's the direct path. "If after running Neutral the conditions don't match, run the correction."

I'm not sure what that means.

I think all you need to do is create an enclosing group, put all of the conditions/subgroups, including the Rule State condition, into it, and then move the pulse configuration to that upper enclosing group, removing it from the interior groups. The Rule State condition will then gate the pulse train.

[gwp1]

@toggledbits So this took a major rewrite, esp for the Neutral because you could be going from Heat to Neutral, from Cooling to Neutral, and back again. The goal here, now, is to have it so that something must go true and there are far more options to cover than triggering on something going false. This is what I've arrived at - a second+ set of eyes on my work would be appreciated.

I stared at it 'til I'm cross-eyed!

[toggledbits]

I'm thinking still not right. The group with the pulse output needs to be a wrapper group for EVERYTHING else, including the Rule State condition, to my way of looking at it.

[gwp1]

@toggledbits Like this:

What's the reasoning behind bumping that up one more level?

[toggledbits]

Yes, I think this is closer to what you really want. This keeps the pulses from firing unless the Rule State condition is also true, so that you can (again) use the limited count of pulses, because pulses won't be firing unless all of the conditions AND the rule state are all true. That is, pulses will only happen when the devices aren't set properly for "Neutral" (for a while) and Neutral is the active mode.

You also have to think about your "sustained for" timing. That is also done in the interior, meaning it is done irrespective of whether the Neutral mode is active or not, and that, too, is probably not what you want. The effect is that your correction will fire immediately if the Neutral conditions haven't been met for a while at the time the system is switched into Neutral mode. I imagine you actually want a delay there, since it probably takes a couple of seconds for the transition into Neutral mode to make the round trip through the cloud and devices and be reported back. You need to give it a chance to work/catch up. A simple fix there is to simply add a sustained for delay to the Rule State (is Neutral active) condition, so your logic overall becomes "if the mode has been Neutral for at least 300 seconds and the devices haven't been set properly for at least 300 seconds".

[gwp1]

@toggledbits HA, funny you bring that last part up because the sun has gone down so the system races thru Neutral to Heating as the temps drop quickly. I did notice the 300 seconds was being ignored, seemingly, and the correction fired on the heels of the change.

I did move the 300 seconds up to the next group level. Since UP and Down both are sub-groups within the larger group I thought it made sense to raise that a level - do correct me if I'm wrong here.

Looking into the tweak you noted in your response.

[toggledbits]

@gwp1 said in Will Pulse work for retrying a ruleset if the device hasn't responded as expected:

I thought it made sense to raise that a level - do correct me if I'm wrong here.

This is a good rule of thumb. Well done!

[gwp1]

@toggledbits QQ, all of these 300 second sustains... they're working concurrently, not consecutively, yes?

[toggledbits]

They can -- it depends on when their respective conditions get them rolling...

[gwp1]

@toggledbits Before heading off to sleep the house slips into "night" mode. One stat, the upstairs one, did not change to night temp so I came in to watch the correction happen.

It didn't. No sustained for timers rolling, nothing.

I moved the Sustained for 300s back down to the next group level, that of the Up and Down t-stat level and the sustained for timer showed up. #win

When I hit reset the rule state for Arm for Heating started its sustained for timer as expected. So did the timer for down which makes sense because it is the stat that didn't come along.

And then when the 300 seconds ran out... nothing. Nothing happened. Even the highest level pulse didn't... pulse.

Up is still wrong and nothing looks like it's running to correct it. I'm wondering if moving the pulse to the top-most level isn't working. I can't see why not - but I don't know why the sustained for timers didn't go at one level higher, either.

Update: those moves didn't help, when the timers ran out the AND Upstairs for at least 300 secs [or] bar blinked and... no reaction ran.

[toggledbits]

Stats is in AND mode, so both Upstairs and Downstairs need to be true at the same time. Is that intended?

[gwp1]

@toggledbits Wow, great catch. There's also another error in this one where statmode and setpoints should be AND, not OR. I think this got bolluxed when I started moving groups into groups into groups.

Quick review of the other rulesets and I see a couple more of these here and there including one that I was trying to test/troubleshoot just this morning.

Nice catch - appreciate it! Now I'll validate these work again and then, one by one, make the pulse and sustained for edits back up to higher levels.

[toggledbits]

Remember to give those status lines a good hard squiz. I still don't understand your logic completely, but when you said you expected pulses to be rolling, and the top interior group was not true while an interior group was true (and that was correct/expected, as you also pointed out), that was the clue to make me ask about the operation on the group. Follow your groups up from where they are as expected to where they are not, and check those operators!

[gwp1]

@toggledbits I'm marking this as solved because I watched a couple of the rulesets WIA this morning as the day's temps ramped up.

Thanks for your incite and guidance as always, sir!