Error: Command timeout

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

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