[SOLVED] Will Pulse work for retrying a ruleset if the device hasn't responded as expected
-
@toggledbits I guess first thing, am I correct in that the
pulserunning 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
0pulse. If I implement meteredpulsethen 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
pulseat0. If I meter thepulsethen they runXtimes and are done - and when the time comes for them to really run, they're spent already.If the
pulserunning isn't putting an unnecessary load on the system, then I'll set them to0and leave it be. So... are they?@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 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.
@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
triggeris when something is NOT a certain temp or HVAC mode. This results in it always being in atruestate as other rulesets are in effect.Different words:
When Heating or Cooling rulesets are controlling things, Neutral correction showstrue- because it is. This results inpulsealways running (or, if metered, running out of retries.) -
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.
-
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.
@toggledbits Def not what I want but it's the direct path. "If after running Neutral the conditions don't match, run the correction."
-
@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.
-
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.
@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
trueand there are far more options to cover than triggering on something goingfalse. 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!
-
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.
-
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.
-
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".
-
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".
@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
UPandDownboth 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.
*Hubitat C-7 2.4.1.151
*Proxmox VE v8, Beelink MiniPC 12GBs, SSD*HASS 2025.3.4
w/ ZST10-700 fw 7.18.3*Prod MSR in docker/portainer
MSR: latest-25082-3c348de6
MQTTController: 24257
ZWave Controller: 25082 -
@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
UPandDownboth 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.
@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 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!
@toggledbits QQ, all of these 300 second sustains... they're working concurrently, not consecutively, yes?
-
They can -- it depends on when their respective conditions get them rolling...
-
They can -- it depends on when their respective conditions get them rolling...
@toggledbits Before heading off to sleep the house slips into "night" mode. One stat, the
upstairsone, did not change to night temp so I came in to watch the correction happen.It didn't. No
sustained fortimers rolling, nothing.I moved the
Sustained for 300sback down to the next group level, that of theUpandDownt-stat level and thesustained fortimer showed up. #winWhen I hit
resettherule stateforArm for Heatingstarted itssustained fortimer as expected. So did the timer fordownwhich 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
pulsedidn't... pulse.
Upis still wrong and nothing looks like it's running to correct it. I'm wondering if moving thepulseto the top-most level isn't working. I can't see why not - but I don't know why thesustained fortimers 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... noreactionran. -
Statsis in AND mode, so both Upstairs and Downstairs need to be true at the same time. Is that intended? -
Statsis in AND mode, so both Upstairs and Downstairs need to be true at the same time. Is that intended?@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
pulseandsustained foredits back up to higher levels. -
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!
-
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!
@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!
-
G gwp1 referenced this topic on
