Looking for some advise on a vent rule for laundry room. Looking to have vent come on 2 minutes after a vibration sensor triggers and turn off after 6 minutes of inactivity to get through cycles. The vibration sensor is sensitive enough to trigger when someone closes the door to the garage, or opens the appliance to remove clothes and I would like to ignore these events. My primary concern is it getting stuck on for whatever reason. Or switching ng on and off throughout the cycle. This is what I came up with but maybe someone has a better idea.
I find a power monitor the most reliable way to monitor the washer.
1 Like
@lewis.heidrick Your rule looks like it should work but another option would be a Wait for Expression before your On action. This should effectively filter out those shorter vibration events. You can then remove your On delay. Not sure this is a better idea, just a different option to consider.
Wait for Expression: Laundry Room Vibration Sensor active --> duration: 0:02:00
You could also apply this to the inactive condition and remove your Off delay and both Cancel Delay Actions.
1 Like
Power monitoring is just so chatty, I'd rather not have that traffic.
1 Like
@lewis.heidrick I think I would leave the Waits and On/Off inside the IF-THEN, otherwise the rule will be in an extended Wait state with a short vibration event. I don't think there's anything wrong with being in that state, it's just a subscription, but I'd prefer not to have it like that.
Yes, that's how I'd do it.
1 Like
Just in the interest of discussing Rule Theory(TM)...
I don't see how the two versions of the rule posted are different in this regard--this sensor attribute only has two states, "active" or "inactive," and it's going to be in one or the other no matter how long the real-world state lasts (or doesn't). Even with the IFs in the second rule, one of the "Waits" is always going to be created and waiting.
But if you have a personal preference for one way or the other, that's fine. 
(For comparison, my preference would probably be for the first: it's easier to write and slightly easier to process, since if you only trigger on "active," you don't need to check the state in the actions. In the real world, this shouldn't be an appreciable difference. I also gave up on vibration and went with power myself, but if you get the readings you need, either should work...)
I don't think "one of the "Waits" is always going to be created and waiting" is correct. In the first example without IF-THEN, a transient vibration event will start the rule. The first Wait action will run but since it's a transient event, and presumably less than 2 minutes, it'll keep waiting until the 2 minutes is met. This could be a long wait and additional transient events will only restart the Wait.
In the example with IF-THEN, a transient vibration event will start rule. The first Wait action will run but since it's a transient event, the rule will retrigger on inactivity. The ELSE condition will be satisfied and after 6 minutes of inactivity the Off command will be sent and the rule will be finished. I don't see this example having one of the Waits always waiting.
I'm sure there isn't any performance difference as the trigger is subscribe to the vibration sensor and "waiting" but I prefer a rule to run to completion and not be waiting in a Wait because of a transitional event. I appreciate your perspective so please let me know if I'm missing something here.
That is correct, and I missed that detail. But ... it's actually true for both rules:
After the "off" action runs, there will be no more wait in either version of the rule, at least not until the trigger event happens again and sets things in motion. (Again, I was only thinking of what happens if the sensor keeps switching between states, as might happen when the machine is in use.)
Oh, for sure, I didn't mean to impy there would be a real-world performance difference (but if you can just subscribe to "active" instead of subscribing to "changed" and then needing to check the state, it's less work for both you and the hub). I don't think I undersand how the "transitional event" behavior is different between the two, as the subscriptions and scheduled jobs created besides the trigger event would be about the same in either rule.
However, I actually just noticed a functional difference between these rules I hadn't noticed before: the first version will only turn the fan off it the rule previously turned it on beause the sensor was active for 2 or more minutes. The latter will turn it off after 6 minutes of inactivity in either case. The real-world difference probably doesn't matter, but this is the only functional difference in outcome I can see between the two versions.
The whole point of this OP was to create a rule that would filter out transient events that the vibration sensor is sensitive enough to pickup and trigger the rule i.e. the door to the garage closing. In the rule without the IF-THEN, the "vibration sensor active" for a duration of 2 minutes won't be met and the rule won't proceed to the On or any subsequent events and remains unfinished. There isn't going to be an Off action as the rule will be "stuck" in the Wait. I usually prefer the IF-THEN-less rule but in this instance, using a Wait with a duration, I prefer the IF-THEN option.
No, if it doesn't remain active for 2 minutes, then the state became inactive, so the wait (for a different state) was cancelled, and nothing will happen again until a trigger event fires.
EDIT: Actually, I see some possibility for confusion here and an assumption I'm making that "duration" works as I expect. This is testable and I'll confirm or deny later. 
At first this seemed like a good candidate for the Basic Rule app, but the app only has the duration option available for the inactive state. Might still be a good option for a backup to make sure your vent is shut off when you want it to be.
Your understanding of Wait for duration is not correct. The Wait isn't canceled by not remaining active for the duration. If the duration isn't met the Wait continue until the duration is met or the rule is retriggered. Here's an example with log to show this.
That's what I was beginning to think when I made that edit, and that was precisely the kind of test I intended to try. Thanks for going through all of that!
(That being said, in real life, I wouldn't really be worried about this difference--the wait doesn't keep the rule "running" as some fear; it just creates a subscription or a subscription and then a scheduled job, the former of which is more or less the same as a device event trigger, and then the rule will wake when it needs to do whatever thing...but the action-related effects are good to know in any case!)
1 Like
