[Reactor] Bug when sending MQTT boolean payloads

[gwp1]

@librasun That's where it lives. It's also the second action under the action to reset the stats. Yet what happens is, whilst the seven minutes is in progress and the action to reset the stats is waiting for a go command, the notification fires.

[toggledbits]

@gwp1 I feel like a grade school teacher having to write this, but... show your work.

[gwp1]

@toggledbits "But Mr. Kedron, I did it in my head!"

Concept is: other heating ruleset issues commands to Honeywell API to set heat at 68 upstairs, 65 downstairs. Sometimes this is ignored. As such, 'cause things happen, this ruleset essentially looks for the correct criteria to be UNMATCHED and, after waiting seven minutes, fires off the same command to Honeywell as well as notifying me.

The seven minutes is to:

• prevent a double hit on an API that already fumbled the first one

• if, for some reason, the status change is just late and the original command was accepted then the Triggers here will go unmatched and this ruleset ultimately expires without needing to fire

And yes, I do lie awake at night thinking up these convoluted scenarios because "food is a crutch, sleep is for wimps."

[toggledbits]

I'm not seeing a delay in your reaction. If there's no delay in your reaction, there won't be a delay between the actions. What am I missing?

[gwp1]

@toggledbits I had a delay in it originally and all that did was delay the notification even if the ruleset ended up not ultimately firing because conditions changed and the Set Reaction didn't need to be fired - ie, I still got the notification (albeit delayed) even if the ruleset was aborted because the Triggers no longer applied.

[toggledbits]

@gwp1 said in How do I: delay a notification to fire only if the ruleset actually fires:

even if the ruleset was aborted because the Triggers no longer applied.

That is correct behavior. You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

Documentation: Reaction Delays

[gwp1]

@toggledbits said in How do I: delay a notification to fire only if the ruleset actually fires:

You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

Wow, I never would have considered that, not in a million years. Thanks, Teach!

[toggledbits]

@gwp1 said in How do I: delay a notification to fire only if the ruleset actually fires:

Wow, I never would have considered that, not in a million years.

Well, there's a place you can go (and it's not here) that will tell you this and many similar secrets...

[gwp1]

@toggledbits I certainly hope you aren't pointing to the MANUAL! Next thing, you'll want me asking directions before embarking on an excursion from the house!

[gwp1]

@toggledbits said in [SOLVED] How do I: delay a notification to fire only if the ruleset actually fires:

You can get the reaction to stop if the rule resets by supplying a Reset Reaction. If the Reset Reaction is not empty, Reactor will abort the running Set Reaction. It can even contain just a comment (so not actually do anything); as long as it's not empty, Reactor will abort the delay and everything that follows it.

Documentation: Reaction Delays

This functionality has stopped working as of build 21331 (and the subsequent 21332) from my observations.

(Yes, I literally c/p'd your explanation into the Comment field so I'd know why I created that particular Reset Reaction.) The current behaviour is how one would expect it to respond if the Reset Reaction were empty. I don't have logs pulled yet, sleep for work tomorrow beckons but I wanted to put it on the proverbial radar. If this should be reported in Mantis I'm happy to do so, just may be a couple days what with Giving Tuesday this week.

[toggledbits]

I have a pretty short and definitive test for this, and it's working as expected. There have been no code changes in this area, so I'd be surprised to see a change in behavior.

[Alan_F]

I've re-read this thread a few times and still am confused by the whole thing. If I understand the images of the rule set, the notification should not be sent because this entire rule set doesn't become true unless one of the conditions is sustained for 420 seconds. That notification should never fire earlier than 420 seconds after one of the Thermostat.Setpoint <> XX is first detected. There is no issue of stopping a running rule set. This rule set isn't supposed to run unless the error state is sustained for 420 seconds. I have several rule sets that work just like this, and they work as expected. Nothing happens if the mis-matched conditions are corrected before the 'sustained for' time expires.

Light bulb moment: I think I just figured why this may be firing the notification when you don't want it to.

Existing conditions:
Downstairs set point is 62. it has been set to 62 for more than 420 seconds.
Downstairs mode is set to heat.
Armed for heating master rule set is true
House mode switches from 'away' to 'home'.

This rule set will fire immediately.

This would also occur if the Armed for heating master rule set changed to true, or if the downstairs thermostat mode changed to heat. As long as the thermostat has been set to something other than 65 or 68 for 420 seconds prior to those other conditions coming true, the 'delay' (really 'sustained for') is already met.

This either needs to be wrapped in an outer group with a 'sustained for 420 seconds' on the whole thing, or the house mode, armed for heating master, and thermostat mode conditions also need to be set to only go true when they are sustained for 420 seconds.

I'm not sure I understand your use case, but if it's possible for the set point to be other than 65/68 and one of those other conditions to then change, this could definitely be double-running your HVAC - Heating Day reaction. If, for example, you have a reduced set point when you're in away mode (or at night), and the HVAC - Heating Day reaction is supposed to fire when you come home (or switch to day mode), then this rule will fire at the same time, assuming you've been away more than 420 seconds (or in night mode more than 420 seconds) with the set points turned down.

If this really does involve an already-running reaction that needs to be stopped by a reset reaction, then I'm completely misunderstanding how the rules in the images you posted work.

[gwp1]

@alan_f The goal here is, for those times when Honeywell flakes on accepting the API post to change temps, this will monitor that and, if the expected setpoints aren't met for the specified conditions (ie, Heating at Home, Heating Away, etc.) then it will resend the commands to Honeywell. The reason for the 420 second delay is to allow the Honeywell API to "compose itself" since it's easily overrun and sending the course correction immediately will presumably result in no correction happening.

@toggledbits I'm at a bit of a loss, then. Nothing was touched with this ruleset since I added the Reset Reaction and it resolved this issue originally. What is the test you have for this and can I use it to spin up a temp rule and validate locally?

[toggledbits]

I think there's a misunderstanding here, and you need to review your logic and the state of devices in the detail panel for the rule, which shows the status of the condition targets and each condition as well as the running timers (when running).

A Reset reaction can only stop a running Set reaction. There is no delay in your Set reaction, so your Set reaction will run instantly and completely when the trigger conditions are met. There is no opportunity here, based on what I see from what is posted earlier, for the Reset reaction to intervene. That whole issue is moot as it applies to the rule and reaction shown.

The sustained for delay is self-cancelling. When the related condition is no longer met (i.e. result is false), the timer is cancelled. If this rule is setting, it is doing so because one of the two conditions is being met. A review of the detail panel and status will show this.

I"m getting the idea that you are not looking at the detail panel. Go look at it. Post it if the results aren't what you expect.

[Alan_F]

@gwp1 I think I correctly understood the use case then. The issue is that your rule set doesn't start counting the 420 seconds when the initial command is sent to the Honeywell API. The 420 seconds starts counting as soon as the setpoint is <> 65 (or 68). If you ever have the thermostats set to another value (when away, or night, or when not in heat mode) then the 'sustained for' will start counting and as soon as 420 seconds have passed, that element of the rule will go to true. You'll see it is green in the detail panel if you expand the rule set.

The thing I'm not clear on, but am making some assumptions about, is what triggers the initial call to the Honeywell API that this rule is designed to monitor/verify. Making the assumption that you turn down the thermostat at night with something like "HVAC - Heating NIGHT", and that heating is still armed and the thermostat mode is still set to heat at night, then 420 seconds after you go into night mode, every element of this rule set will be true except the Hubitat house mode rule. The rule set is primed to activate if that goes true.

So at night:

• Armed for heating is true
• (7 minutes after you enter night mode) Set point has been at some other value for more than 420 seconds
• Thermostat mode is set to heat
• But the rule set is NOT activated because the "AND house mode not in (night, vacation, away)" is not true

In the morning when the Hubitat mode switches from "night" to "day", this rule will go true immediately as all elements are now true.

• Armed for heating is true
• Set point has been at some other value for more than 420 seconds. It is still at the night value until the API reports the new daytime value
• Thermostat mode is set to heat
• House mode not in (night, vacation, away)" is true

If you add the 420 second 'sustained' to the other elements, then in the morning when the Hubitat mode switches to "day", this rule will NOT go true immediately

• Armed for heating has been true for at least 420 seconds
• Set point has been at some other value for at least 420 seconds
• Thermostat mode is set to heat for at least 420 seconds
• House mode not in (night, vacation, away)" has NOT been true for 420 seconds until 7 minutes after you switch to day mode.

As long as one of the other elements goes false within 7 minutes, the rule set will never activate. The expected behavior is that the "set point has been at some other value" will go false within 7 minutes. If that doesn't happen, the whole rule set will go true and the set actions will fire including re-running the other rule set and notifying you.

I still think this could be improved as I'm pretty sure this will only fire once. If the second attempt at setting the thermostat fails, this rule will remain set and there is nothing to cause it to un-set and then re-activate. That could be your desired behavior if you want to manually fix it when it fails the first time and avoid calling the rule every 7 minutes on repeated failures.

I dealt with a lot of the same issues setting up rules for my flaky Lennox thermostat. It's still in Node-Red and looks like this:

<img src="blob:chrome-untrusted://media-app/55d4404c-a480-4453-ae24-0e6410279a3b" alt="Screenshot 2021-11-29 11.34.25.png"/>

I'm not smart/experienced/brave enough to try to replicate that in MSR yet.