[SOLVED] Will Pulse work for retrying a ruleset if the device hasn't responded as expected
-
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
