Hello, can someone give some input to whether this will do what I want?
Here is what I am trying to do.
- When the wash machine power goes up, I want to put the water heater into high demand mode.
- Once the power level goes down (to basically zero) , and after a period of time, switch back to Heat Pump mode.
I was trying to decide how to handle the delays. I am not positive this will give me what I want.
I don't want this to bounce back and forth between modes while power is active. It would be OK (and in fact desirable) for the delay timer to restart (prevent switching modes) if you do a couple loads within the delay period. I am hoping the the delay I put in there is in the right spot to do this.
Eventually I want to get to the point with this rule of changing modes per outdoor air temp or time of the year. Heat Pump Water Heaters work great in the Summer in Michigan, but can struggle in the Winter. I have been manually setting modes or just doing a simple weekday/weekend schedule but that isn't quite right sometimes.
Thanks
With some modifications, this should more or less do what you want, assuming the 2-hour delay (and power conditions) are sufficient for your needs. However, there are a couple of problems that would prevent it from working correctly at the moment. First, there's a structural problem: IF ... ELSE-IF ... END-IF is the correct way to build the construct you want, i.e., the ELSE-IF (or ELSE) goes between the IF and END-IF, the latter of which completely ends that IF block. (You can tell something is a little wrong here in any case since Rule Machine should be nice and indent things that go inside these blocks, but your second set of actions isn't indented--be suspicious if that's not there.)
Second, you have an issue with "cancel." What that flag does (which you've wisely set on your Delay) is make an action eligible to be cancelled, but you need a "Cancel Delayed Actions" action to actually make that cancellation happen. In your case, you want to cancel this delay when the power bumps above 10.0, so I'd put this action before (or after; I guess it won't matter in most cases) the RequestHighDemand() action in your IF. (In case you're curious: what you'll have happen without this cancellation is a bunch of RequestHeatPumpOnly() actions scheduled--or more specifically, scheduled executions of this rule that will resume at this step--every time the power drops to <= 1.0, no matter how many times it goes above 10.0 again.)
This is actually somewhat similar to the motion lighting example rule in the Rule 4.0 docs, except you're trigger isn't a motion sensor and your controlled devices aren't lights, but the idea is more or less the same. 
You may find other ideas in there if you haven't read them yet.
Hope this helps!
I missed that ENDIF. I added the second part after I thought about it for a while, and forgot to remove it after adding the ELSE statement.
Here is what I think you said to do. Like this?
Not quite. The delay probably needs to go back to where it was before--it will pause the script at that location and wait to execute the next item, which I assume you want to happen when the power drops below 1.0 so it doesn't turn the heat back to "pump only" right away. I guess it's up to you, depending on what you actually want to happen. (But right now, it actually won't do anything special: it waits two hours, then runs the delay cancellation which won't do anything at all since that action is only running since the delay itself just ran out of time.)
So move delay back, but leave cancel where it is OR move both of those?
No, do not move the delay and the cancel, just the delay back to where you had it. You almost always want them in different halves of an IF as I mentioned in my first post and as you can see in the example in the docs.
Thanks for the help, now I just need to let it run for a few days and see what happens.
Wish me luck! 
So I found out a few things, and made some changes. I wanted to document this for others, and so I remember what I did in the future.
To start with, the rule above worked, but worked too well. It spammed the Hubitat, and Rheem servers every time the washer changed modes and worse yet while agitating. It brought the hub to it's knees with the above rule, it was to the point where the I couldn't even access parts of the GUI. I had to slow down the rule somehow and make it only act once or maybe a couple times per cycle at most.
The power outlet, a Zooz Zen15 (works great by the way) was too sensitive to power changes. I ended up having to turn off all reporting except "Power Report Value Change" and I had to set that to a pretty high 100W threshold. That slowed things down a bunch, but I was still getting dozens of rule firings per wash load. Better, but I don't want to abuse the Rheem server and get kicked off there.
So I thought a bit, and wondered if I could have two rules. One would test if the plug was on or off, and use that output for the main rule. I ended up using private boolean to make this happen. Here are the final two rules that seem to do what I want.
1 Like
That's interesting. I was working on this as well this morning. I have a hot water circulation pump I'm doing a similar thing with. As for the triggers, I'm using my shower motion sensor, washing machine and dishwasher. I used a 15 minute timer to keep the circulation pump from slamming on and off.
