I have an old AC unit where the auto mode doesn't work so well. It just keep pumping out the cold air. So I thought to create a small rule (using Sensibo) to switch it to fan mode when the temp gets too cold and then back to cool mode when the temp rises back up above a threshold again.
It's switching to fan mode ok. The temp only gets updated every few minutes, so by the time it switches to fan mode it's the best part of a degree below the threshold so then it should operate for a few minutes on fan while the temp goes back up again until the wait triggers. But it seems like the "Wait" is not getting scheduled (I don't see it in the app settings page) and so it never switches back to cool mode again despite the temp going above the threshold again after a few minutes as planned.
Thoughts? The rule should sit at the Wait statement, right? Can't see the wood for the trees right now
I think I see whatās wrong. When the temp goes below 26.0, then your rule triggers. And every time it reports any temp that is still below 26.0, you get another trigger. I suspect you know that already, since I see you are using the private boolean to stop things from happening twice.
However, every time you get a trigger, any waits are canceled. Thatās not done by your rule, triggers always cancel waits. Suppose you get a reading of 25.7 and turn on the fan, and start your wait. Suppose the next reading is 25.9. That makes another trigger that cancels your wait.
You need to get the repeating triggers away from your main rule altogether, and that means using a second very small rule. You could still use the main ruleās private boolean, but it would be used in a different way.
The second rule should have a trigger of temp <26 and turn the main ruleās private boolean to true. Thatās all it does, and if it gets several triggers, it will keep trying to set the PB to true. But it is already true, so nothing changes.
Your main rule should be triggered by its own PB going true. And that is only going to happen once.
You should take out all other references to the private boolean in the main rule. Except, after the wait, at the very end of the rule, it should turn it private boolean to False, so the other rule can trigger it again in the future. Also, it appears that the first conditional statement in your rule is to cancel any waits and exits the rule when you get a trigger and the AC is turned off. In that part you should also set the PB back to false, so rule 2 can set another trigger later.
Ah! I learned something today. Thanks.
Yeah, I was thinking to employ another rule but wanted to try to achieve it in one. Will have to rethink it. Cheers.
I have noticed that if you send an On command to a switch that is already On, it also triggers as an On event. If Booleans behave the same way you might have to use Changed as the trigger and then test that it changed to On.
Yeah, I've switched it to use "changed" instead. I was trying to avoid that because it retriggers all the time with the temperature going up or down. Anyway, now it's working fine!
This depends on the driver but normally wouldn't happen: if the old and new values for the attribute are the same (so, in this case, if you'd see "switch: on" under "Current States" on the device page both before and after with no change between), then by default, Hubitat does not generate an event. A driver author can override this behavior (and it is common for many devices to do this in specific cases--e.g., if a button device sends a value for the "pushed" attribute, it's a button press and should generate an event even if the "new" button number is the same as the old one).
