I have my dishwasher on a Kasa KP115 power monitoring plug. I only just installed it a couple of days ago. I want to be notified if the power stays below 3W for more than a minute, but only if the power had previously been over 5W.
My first thought was this is perfect for the new predicate conditions since they are for tracking when something moves from one state to another state, but in this case as soon as the power drops below 5W, the predicate condition becomes false and so the trigger would never happen.
So now I'm thinking I need two hub variables to track the state; dishIdle and dishRunning. I started to look into that, but it seems like you can't use a hub variable as any type of trigger. I see that the private boolean can be used as a trigger, but I was hoping to not need that because I've had issues with PB in the past and I don't like how you can't initialize them.
It seems like this should be easy to do... so maybe I'm just overthinking things.
How were you trying PB? I do them in their own rule, and then call on the state of the PB rule to trigger the actual automation rule. It theoretically can be done in one rule, but it is so much easier to tune when you are just dealing with a simple PB rule and not having to play with the automation part of things. I can post a PB rule that works for me if you want me to.
But yea, this seems like it should be a good case for predicates. It is almost like you need the reverse logic somehow.
The one instance where I use PB now is to change the behavior of the lights brightness in the bathroom. There's a motion sensor under my toddlers bed, so if he gets out of bed it sets the PB of another rule to true. If the PB is true when motion is detected, instead of doing it's normal thing it just dims the light really low like a nightlight. There are also some LED strips under furniture in his room that come on really dim and this keeps them on until he goes back to bed, then the PB becomes false and goes back to normal behavior.
I've had instances though where somehow the PB didn't go back to false and I get messages from my wife telling me the bathroom light isn't working. I plan on replacing those two rules with a single rule using a predicate condition.
I have a "washing machine done" rule that does basically the same thing as this, and you don't really need a predicate condition or variables to make it happen. This does assume that you're OK with nothing happening if the power becomes 4 W while you're waiting for it to remain under 3 W for the specified time, but I think you could work around that with a bit more work if it's important for your use case (I just haven't given that any thought yet ).
Trigger event:Power > 5
Actions to run:
Wait for event: Power < 3
Wait for event: elapsed time --> 0:01:00
(do things here)
This rule exploits an often-overlooked feature of "waits" in that they are cancelled any time a rule retriggers--so any actions here after your first two (what I have in parentheses above) will only be reached if the power goes below 3 W and doesn't rise above your trigger threshold for the remaining minute (so again, I'm technically ignoring the 4 W case...not sure how important that is for you; it's not at all for my purposes, and these different thresholds--which I also use in my rule--are very much intentional in my case).
There definitely are more complicated ways you can make this work with a "changed" trigger, conditional actions, and cancelable delays...but I wouldn't start there if you don't need to.
I haven't played around with the new "duration" thing in Rule 5.0 yet, but that actually looks like a cleaner way of doing what I wrote (which would work verbatim in Rule 4.x: two separate waits)--and I think takes care of the "4W problem" I mentioned. Looks like it should work! (Assuming the feature works how I assume...)
).
