I need some help understanding what is happening with my rule machine code to trigger a dryer notification. Sometimes the global variable does not get reset and I don't know why. Is it the Wait for event, the timeout, or something else entirely? I'm using a Tuya Zigbee vibration sensor on the dryer. Thanks for your help.
Here is the rule:
Here is the log from the latest activity:
Is it possible you restarted your hub while the rule was running? If so that will stop the hub variable from being reset. My rule is basically the same as yours, but I use the private Boolean instead of a hub variable. Don't think you need the if statement as the only way the rule will trigger is if the sensor is active.
I have a rule that on a hub reset, sets all rules using the private Boolean method back to true
It looks like the acceleration sensor is flipping between active and inactive during the cycle causing the rule to get into a mess. I would reduce the 'stays that way time' in the trigger, and, like @terminal3 mentioned, get rid of the IF statement.
Also, I think the logic for your notification is wrong and you'll always end up getting it unless the time is between 7 am - 9 PM.
No, it happens randomly. Sometimes it works as expected and then other times the announcements stop and I check the hub variable and it did not get reset. I thought maybe the "Wait for event and stays that way for a minute" or the timeout of 1:30:00 may fail for some reason and then because the dryeractive variable is still true and can never re-trigger the rule.
That's a good point on the if statement. I've morphed this a bit over time. I don't use the local variable because I use the required expression to start this and didn't know how to do that any differently. I appreciate your help.
The notification occurs between 7AM and 9PM. The else and endif go with the first if statement.
The reason I wait so long to trigger a positive dryer active is because sometimes when the washer is spinning it will trigger the dryer sensor and give us a false notification. So I originally started out with 2 hub variables - dryeractive and washeractive. I intended to filter out the false notifications by setting different wait time if the washer was in use. I'm sure I'm making this more complicated than it has to be.
Not with the way it's written up. I know the indentations don't make it fully apparent, but logically, this is what you have:
IF
Dryer running stuff
IF(between times)
Notify
ELSE
Log
END-IF
The key point for stuff like this is to really narrow down the trigger to the bare minimum to get the rule going. Weeding out false-positives from the washer would definitely be a good start and maybe reducing the "stays" time for the trigger itself. Below is how I handle this, but with a power monitoring plug.
I have a similar rule for my washer with a power monitoring plug but had to use a vibration sensor for the dryer since it is 220V. I didn't realize you could use the Private Boolean before you actually get into the rule. I thought it got initialized every time the rule ran. I'll start streamlining to determine where the current hub variable is failing to get reset.
At a minimum, I would have thought the timeout value would eventually trigger the reset of the variable but that doesn't happen either. Maybe I'll try using the local variable and see if that makes a difference. I like the way your washer logic is. Thanks.
I ended up picking up an Aeotec heavy duty smart switch for the dryer to monitor it's power. I also have it in use in a rule so if the smoke detector goes off in there, it cuts power to dryer.
Yeah, I may do the same. The vibration sensor is not very reliable, in that it tends to reset at odd times with no details as to why. I have it set to high sensitivity and the light flashes in a decent pattern, but sometimes it acts strange.
Good catch, with the way it was indented I didn't even notice there was a 2nd IF in there.
The second IF is a simple condition so the ELSE isn't associated with it. The indent is correct though the ELSE will never be met since the trigger and IF are both active.
Good catch, no "THEN" after the IF condition.
When it fails to reset the hub variable, it seems like it exits the rule because the last log entry I get is " Wait Event: Dryer Sensor acceleration inactive".
Since the rule has " Wait Event: Dryer Sensor acceleration inactive and stays that way for: 0:01:00" I would think it would move on after a minute and reset the variable to "False". That part never happens. So I think it has something to do with the event, but I guess I don't really understand events.
Wouldn't the event it is waiting for happen at the time the sensor stays inactive for a minute instead of at the time the sensor goes inactive?
When a rule gets to a 'wait for event's it subscribes to the event type from the device at that moment. If the sensor is already inactive, then the rule wouldn't see the event unless the sensor goes active and then inactive again. The odds of that happening are pretty slim, but definitely possible.
That does make me think of a point. For your required expression, what are these set to?
They are both turned off, just like the image you presented.
Is the event when the sensor goes inactive or when the sensor goes inactive and stays inactive for a minute? It seems like event suggests only one time, so I never understood how an event could stay that way for a minute.
As Bruce posted recently:
A condition is about state, while an event is an instantaneous thing. A contact opening is an event, while a contact being open is a state. Only states can be in conditions.
So: Create the state as a Condition, in my case since I'm using power monitoring, mine is "Power level of Plug Washer is <10.0"
Then use in the rule /w a duration to provide the debounce:
I think you'll be happiest using power monitoring, once you suss out how your washer/dryer report power at the end of a cycle it is quite reliable.
The hub simply starts a timer once the event occurs. If the state doesn't change (e.g., another event that changes the state) before the timer expires, then "stays that way" is fulfilled.
I use a rule pretty much the same as what you had and it works great. Using a accelerometer can be problematic on some devices I imagine, but on our dryer it works great.
I think that is probably the best approach...wait for expression and set a duration. Let me see if that works more reliably than wait for event.
Ultimately I think the best approach is to use a power monitor like @FriedCheese2006 and @danabw suggested.
Thank you all for your help. I feel I've learned more and I have a plan forward. I appreciate all your contributions toward that!!!
Download the Hubitat app
