ya works for me too.. dont think it is a bug you need to turn on logging on the zooz and the rule and see what energy reports are coming in or go through your events.. these washers and devices jump around quite a bit.. that is why you need to fine tune the rule.
Well, I beg to differ... Look at the logs below after I turned them on for the Rule. The bottom section was from when things worked as expected. The top section, not so much... My washer was on a timed-delay start, and it power usage was fluctuating between 4-5 watts consistently. It never dropped below the 3 watts that I initially had as the target. I even changed the target to 2 watts, but the rule still sent a false notification.
I am using an IoTaWatt power monitoring system, that I have reporting power values back to Hubitat every 30 seconds. I verified that the power reported via the device never dropped below 4 watts, yet we had about 6 false alarm over the course of an hour or two. I can't explain why @bertabcd1234's rule is not 100% reliable in this case, other than some sort of a bug. I know with 100% certainty that the power never dropped below 4 watts... Here is the rule I was using...
That's the app which diesbt always show all info. You need to look at the device events. It also could be an issue with that device handler. Have you looked at the events maybe the device handler is not reporting all.events like it it dropped to 0 for a brief instant.
I did monitor the device events, which is why I stated I was 100% confident the power level NEVER dropped below 4 watts. Unfortunately, those event have already been purged from the system, otherwise I would have included them. I wrote the driver, and it has worked perfectly for years. My RM Laundry rule never throws a false alarm, and it is set up to use the exact same power level conditions.
Here you go... Please help explain what is going on. I have recreated the issue from yesterday. As you can see, the power level reported by the device driver never drops below 4 watts, yet this 'new style' rule has already falsely notified at least twice in a very short timeframe. I would love for anyone to help explain what might be going on.
So, I thought maybe the problem could be in my driver, as I was not casting the 'value' to a float before calling sendEvent(). So, I made that change, but the problem persists.
I am all out of options... seems like a RM bug to me, but it could be something else, I suppose. @bertabcd1234 - any ideas?
Seems like it but it is almost looking to.me like it timed out. Did you have the wait with a time out at one pt. And changed it.
It looks to me like the retrigggering is not cancelling the existing wait statements
Nope. The only changes I have made to the rule is to lower the first wait condition from 3.0 to 2.0 yesterday. I also tried using <= today, with no change.
Maybe I'll try to recreate the rule to see if that makes a difference. I may have cloned the Washer Rule from the Dryer Rule, but I can't recall which one I created first. Worth a shot...
No, but one difference I can think of is that I made mine in Rule 4.0, whereas if you're making a new one today you'd be in Rule 4.1. There aren't supposed to be any changes besides "Wait for condition" being removed and replaced with "Wait for conditions," but we're not using either here, and I'm not aware of anything else... 
I could try re-creating mine in 4.1 to see if some behavior changed. I definitely can't think of any theoretical reason why the rule wouldn't work since it is written consistent with the (albeit poorly) documented behavior of "Wait...," but I suppose using a "Cancel Delayed Actions" plus a cancelable delay instead of the "Wait for event: elapsed time" would help if it's that particular part that's causing a problem here. But I can't really tell from the logs.
1 Like
ya just checked mine is in 4.1.. the fact that the wait code was touched at all may indicate something.
Hmm, so probably not a 4.0 vs. 4.1 difference, then (not too surprising, but it's all I could think of). I recall that we're both using a ZEN15 for this, so it's possible there's something about the way other drivers report these values (e.g., if they're not a numeric type on at least some occasions or may otherwise fail to match the trigger for some reason, even when they should?), but it looks like @ogiewon also tried something that would have addressed that, so I really don't know.
I suppose adding a "manual" log action to spit out the evaluation (true/false) of an evaluation, which you'd probably have to assign to a boolean variable to access in this way, like "plug power >= 4.0" or "plug power < 2.0," might at least provide some clues as to what may or may not be matching--not that it would illuminate much other than that.
Well, I recreated the rule, and it now works correctly. I am guessing that the rule was cloned and that process may have caused the strange behavior.
It has been running for 20 minutes with no false alarms.
and here successfully announced the cycle as being complete.
3 Likes
Hi guys, I thought I would further improve this notification by adding a contact sensor to the washer -- pester me until someone takes the laundry out and acknowledge when it's been taken out.
However, I am struggling to implement it -- almost certainly due to my poor rule-writing skills. I can get both rules to send me the reminders every 5 min, but I cannot get the 'Laundry was taken out' bit to work.
Could someone help pretty please..?
@bertabcd1234's rule:
@ogiewon's rule:
1 Like
Close! The biggest problem is that your actions will get stuck in that repeat with no way to get out. You need to have some way to stop the notification that is "accessible" from within your repeat. I often refer people to this post, which has several examples of how to do exactly this, for good information:
But none of those apply 100% to your situation since you're waiting for an event and not a condition. If you normally leave the door open when the machine isn't in use (or trust yourself to have it open for more than 5 minutes--in the example above, or whatever your repeat interval is in general), then one of those examples should work. However, if you truly want to just wait for the event, I'm thinking you'll have to try something like this instead, which would replace all of your actions starting with the "Repeat every..." line and continuing to the end of your rule in my example or almost the same in the other rule except you'd need to keep that END-IF. This assumes the existence of a local (or global) boolean variable called "doorOpen," which you'd also have to create. Also, set it to false at some point early in your rule actions, e.g., when the machine starts:
IF (NOT doorOpen is true) Repeat every 0:05:00 (stopable)
Cancel Wait* (see note)
Set doorOpen to false
Notify: "Take the laundry out!"
Wait for event: CS - Washer open
Set doorOpen to true
END-REP
Notify: "Laundry was taken out."
However, I just checked and "Cancel Wait" seems to have been removed in Rule 4.1, or at least I can no longer find it (but can in 4.0). This is somewhat understandable, as the action was often overused in the past: any trigger event firing will cancel a wait. But we aren't triggering here, just repeating, which I don't believe will cancel this wait--but it should be of minimal importance anyway since it's just getting recreated shortly afterwards, anyway (I'm just not sure how it will handle the edge case of you opening the door right when the repeat starts over but before it really gets to this action--likely just a split second).
Or, if you don't really need the event, a condition (as in the examples) would work, too, with a bit less work. 
1 Like
Thanks so much @bertabcd1234! Brilliant stuff. The bit that I was missing is my (mis-)understanding about the sequence of how the rule is being 'loaded' / read. Basically it won't move on from the repeat loop until the loop itself provides a way of getting out of it.
I have now tweaked my rule as following, but will probably test it tomorrow (when there is more laundry to do...). Today with me trying to fix this rule, this was probably the first time that my wife thought this 'geeky pointless time-wasting smart-homing' was actually productive -- I cleared the laundry basket in no time!
EDIT: I guess I don’t need that first ‘set to false’ line in the repeat loop as the Boolean is already false given it passed the if statement condition.
That looks good to me! (With the one change you could make being the one you just mentioned.) I should warn that it's completely un-tested by me, but I think it should work... 
2 Likes
So I've made a couple of further tweaks to the rule:
-
Added a condition that skips the first repeat notification, inspired by the post that you linked @bertabcd1234. So now I have two different messages for when the laundry is done initially and then reminder 5min after (rather than 2x messages about laundry done + reminder to take out).
-
Moved the final notification inside the repeat loop, at the end. When it was at the end but outside the loop, I would have to wait 5min for the new repetition to kick in, skip the loop due to the positive DoorOpen boolean, and only then get to the final message. Now, I think it should ping me a notification the moment I open the washer door without the 5min delay.
This rule writing is very addictive.
Thanks again!
More than one notification on stuff like this has very low waf in our house.
Hi all, I haven't been on the forum for a while now -- after my initial Hubitat setup I just let it run without any issues -- what a joy!
However, recently my 'washer is done' rule broke -- I've tried tweaking different things, re-write the rule in the latest Rule Machine 5.1, etc. but nothing seems to be working. It breaks after I open the washer's door -- before you ask, the contact sensor works as expected correctly reporting open/closed door. Below is my rule and the log -- what am I missing?? What does this error mean?
Also note, that the trigger value has been lowered for testing purposes -- so that it's triggered only when the power is on. Normally, it is set at 30.
Any pointers would be much appreciated -- TIA!
