Advice reqeusted to migrate MSR from Bare Metal to Container

[toggledbits]

Seems like you're on the right track. Repeating commands when states aren't what they are supposed to be is definitely one application for pulsed output, and I use it that way myself (like you, I have devices controlled by hit-and-miss cloud APIs). I also use it on my router's power switch -- if the Internet is down for more than a certain period, it begins power cycling the router at intervals to attempt recovery.

On your "Down" group, if the conditions have the same "sustained for" timing, then the timing could be done on the group rather than individual conditions within it -- makes things a little tidier to maintain in the long run.

Looks good to me!

[gwp1]

@toggledbits I thought about putting that at the group level but then wondered if it would require both to trigger so I went more granular.

[gwp1]

@toggledbits I'm admitting to some confusion. Shouldn't I see the Upstairs trigger that's showing "65", which is "<>60", blinking green and showing the count-up timer showing how much of the 300 secs are remaining?

The trigger is true, 65 is not 60 and, as such, should fire off the 300 second period where it waits for that condition to change. If it doesn't, then the Reaction should run and, if that fails, the Pulse kicks in to refire the Reaction a couple three times.

What am I missing?

[toggledbits]

It depends and when and how you are doing this. After doing a lot of editing, and in particular where you may be saving along the way as you make changes, things can get into states that they would not be in once the logic edits are finished and all the timing options are applied. That's why there's a "reset" button for the rule... to clear out all the state and start it fresh. Recommended.

[gwp1]

@toggledbits I think i figured it out AND something else to boot.

So to the ask above, I happened to catch it running this morning. I'm used to basing on "if the thing should be true but it's false" in my trigger AND doing so at the individual condition level (vs group which you recommended I try - and I have.) Setting at the group level means the status timer shows in the group bar, not at the individual condition level like I was used to.

Now on to something I did notice that is, in reality, the reason it appears like this isn't working...

My scenario:
Multiple HVAC rulesets per mode, ie Heat sans Night, Heat at Night, Neutral, Cooling sans Night, Cooling at Night. Three Arm For rulesets drive which one should be sending to the Honeywell API based on outdoor temps from the wx station. Works like a champ.

The course correction rulesets, however, don't turn on and off - they're constantly looking to see if the conditions are met or not, even if that mode isn't the active one. Example, the Neutral correction ruleset is still "running" even if the house is actually in Heating sans Night.

The pulse is to provide back-up to the initial correction because sometimes Honeywell just isn't ready yet when the correction first runs. Works brilliantly... except, I've noticed that the pulse is just continuing to run if I leave it at 0 (as expected, unmetered retries). I can set it to a count, that's fine - but the count runs out due to running even when that mode isn't active creating a scenario wherein there are no more pulses/retries when that mode IS active.

THIS is why it appears not to be working - it's run itself out even when not on active duty, if you will.

This is the Neutral correction ruleset. Right now the house is in Heating sans Night because Arm For Heating is active, Arm For Neutral and Arm For Cooling are not. You'll see the conditions set to true are correct, the temps are not 58 - obviously, because the heat is set to 68 downstairs, 65 upstairs. However, this is making the correction ruleset run unnecessarily which, if my thinking is right, means it's wasting CPU/memory/etc. and may be hitting the API (though I've seen no burst of green around the ruleset to show me it is running.)

Make sense?

[toggledbits]

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

Make sense?

Not a bit. Sorry. What am I look at/for?

[gwp1]

@toggledbits I guess first thing, am I correct in that the pulse running on the rulesets is wasting system resources if those rulesets aren't "eligible" for running?

Trying to think how to rephrase this... ALL of the correction rulesets are running all the time if I implement 0 pulse. If I implement metered pulse then they run themselves out and when they're needed they're already done.

These are the Arm For rulesets:

Only one "runs" at a time, obviously, triggering one of these rulesets:

If, due to the aforemented API hit-or-miss sometimes, one of these runs but doesn't get accepted by the API then the appropriate correction runs:

My issue seems to be that all of the corrections are running all of the time if I enable pulse at 0. If I meter the pulse then they run X times and are done - and when the time comes for them to really run, they're spent already.

If the pulse running isn't putting an unnecessary load on the system, then I'll set them to 0 and leave it be. So... are they?

[toggledbits]

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

I guess first thing, am I correct in that the pulse running on the rulesets is wasting system resources if those rulesets aren't "eligible" for running?

No. That's not the case. Unless the underlying condition is true, no pulse train is running. Nothing is happening. I come from the days of room-filling million-dollar computers with 256K (yes, K) of RAM. I don't like wasted cycles.

What is true is that whatever the state of the current pulse may be when it is active is not changed by you editing the rules/condition options at the same time. It is not until the current pulse expires that your new pulse rules will take effect. So if you have a condition that is active right now in the middle of a 120 second pulse, and you edit the timing down to 15 seconds, that 120 second pulse is going to finish; it will not be cut short, it will not stop. When it finishes, the next pulse after will be on your new timing. Likewise, if it's timing a break and the underlying condition is still true, the break timing will finish.

This is why I say, you have to reset the rule after editing it. Your earlier screen shot clearly shows a condition where you edited in the middle of a 120 second pulse break, going from 0 repeats back to 3, and the 120 second pulse break timer is still running. The rule reset function is provided for exactly this circumstance -- to dump existing states and timers. If you don't do the reset, you're going to see really confusing results as Reactor finishes what it was doing before it starts to follow your new instructions.

And if the pulse is "running all the time" then there is a true state on your logic to make it do that. It does not run otherwise.

[gwp1]

@toggledbits The first sentence I can totally wrap my head around

The last sentence is what's driving this. If you look at the correction ruleset you'll see it's kinda backward from normal in that the trigger is when something is NOT a certain temp or HVAC mode. This results in it always being in a true state as other rulesets are in effect.

Different words:
When Heating or Cooling rulesets are controlling things, Neutral correction shows true - because it is. This results in pulse always running (or, if metered, running out of retries.)

[toggledbits]

I see what you're getting at. That's simply a problem with your condition structure. The inner groups can't know how any enclosing groups are going to interpret their output, so of course the pulses run, as well they should -- you've told them to. If that's not what you want, a slight restructure of your logic fixes that.

[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...