So I have a rule that turns on my bathroom heat cube in the early morning if the bathroom temp < 81F (and some other conditions) and when it turns the heat cube on it is supposed to wait 3h30m and turn the heat cube off. This rule had been working for a week, but the past few days, it is not turning the heat cube off again.
I have deleted the rule and recreated it from scratch but it's still not turning off at 3h30m. I tested it to turn off at 3m and that worked just fine.
Now I'm wondering if the predicate becomes false (temp is NOT < 81F), does the wait part not work? I thought that once the rule fired, it should complete regardless but this is the only thing I can think of that might be stopping the rule from running.
Does anybody have an idea, please?
I suspect the issue is with your trigger events. Every time they trigger, they will cancel the wait, so it will only get turned off at 10am unless your predicate condition stops the trigger at one of 5:30 or 6:30am.
1 Like
Agree - it would appear that by your trigger events, the heat cube will only turn off at 10 am (the last trigger). Also I would simplify your predicate conditions, remove the time between 4:30 and 8 am predicate as it is covered by your trigger events.
It would appear that your rules here have 3 times to check and turn on your cube according to the predicate conditions. If they are true, then the last check (6:30) will ultimately be the timer base, and the cube will turn off at 1000.
Instead you could write a separate rule with a trigger (CUBE ON) to turn it off with a delay of 3:30. This would turn off the cube anytime it comes on, no matter how it is turned on, after 3:30. Then take the wait and off out of this rule. This would effectively ensure the cube is not on for longer than 3:30, which is what I think you want to do.
I checked your thought that the predicate (FALSE) was subsequently not canceling the wait with a simple rule and a predicate switch. The wait executes as it should even when the predicate becomes false as long as it (the predicate) was true initially to trigger the rule.
1 Like
Rule Machine is capable of generating some very complex rules, but the more complex the rules, the greater the chances that it won't work as intended. Create a logic diagram (sometimes known as a decision tree) and try to map out the variable and states and see if thing work as desired. Simplify the rules whenever possible. You might even find that breaking down a complex rule into several simpler rules might help.
You might also be able to simplify matters by using a virtual device. For example, I take it that you want to turn the heater on in the bathroom only on weekdays, when you are home and the HVAC system is in cooling mode. You could combine these conditions into a single virtual device.
I was confused by your time of day triggers. That may be what is causing the rule to fail. For example, if it is 4:30 am and the temperature is below 81F, the heater should turn on and stay on for 3:30. However, when the time reaches 5:30 am, if the temperature is now over 81F, the rule might not know what to do.
The first thing I would try is pick a single time to activate the rule and remove the other two alternatives. That might be all that is needed.
Also I am not certain why you included the 4:30am - 8:00 am predicate condition in the rule. I do not believe it serves any useful purpose. If the heater turns on at 6:30 am, it should stay on for 3:30 or until 10:00 am, even though the time is after 8:00 am. If you do not want the heater to stay on after 8:00 am, you need to set a trigger event to turn it off at 8:00., even if the wait timer has not expired.
You could do this the way you are trying if you use Delay instead of Wait for elapsed time. A Delay won't be cancelled by the subsequent triggers events, and those actions will happen 3:30 later, provided the Predicate is true.
1 Like
We sometimes have brief power interruptions here, of just a few seconds. I have the Hubitat and networking equipment on an UPS. But the Sylvania Smart+ switch won't fail back to previous state. So I put in some additional triggers (4:30, 5:30, 6:30) so at least there's a chance to warm the bathroom should the power be glitchy.
This is where the previous digital timer seems to be better. Even if the power is interrupted, it resumes the previous state.
Anyway, thanks for the responses. I'll clearly have to play with this a bit to find what makes the most sense.
2 Likes
If I'm looking at the same plug, it appears the Smart+ switch is wifi. This is where a z-wave plug may be a better option.
I have used many different z-wave plugs, mainly through looking on Amazon for inexpensive options. One of the best I have is the ZOOZ Zen25 double plug. Currently unavailable, but you can get it off ebay.
When you check the manual, there are advanced parameter settings which allow you configure most anything, including power loss recovery options.
I use the auto-turn-on timer as a remote reset for my network modem and hubitat - I turn it off remotely, and it will automatically turn back on after 1 minute. This is why I chose the zen25, it was one of the few plugs (including other ZOOZ plugs) that had the auto-on option. Many/(most?) z-wave plugs, however, have the power state restore option, including this one.
To set the advanced parameters, download/install the Basic Z-Wave Tool device driver from GitHub:
Then you can change the device type to the tool, use the tool to change the advanced parameter according to the manual, then change the device back to the normal device type.
My Sylvania Smart+ is a Zigbee device. Can advanced setting be done with Zigbee as well?
No idea - I don't have experience with Zigbee devices. However you can mix both types with Hubitat as long as your hub is not too far from where you want the device (you don't require a 'hop'). If it is a bit further, you would just have to add an additional device or two in the middle.
@bravenel
So if I'm already running actions that are doing either "delay" or "wait" and the predicate suddenly becomes FALSE the block of actions just stops executing?
I understand the rule won't be triggered again when the predicates go FALSE, but it seems strange that something already in the execution phase would just stop.
Is there some way to have the current actions complete all the way through even if the predicate becomes FALSE?
I misstated above. Yes, the predicate only stops triggering.
1 Like
