I have a Ecolink contact sensor on my door. When my door opens I can get anywhere from 1 to 3 Contact Open signals within 3/4 of a second.
The problem is that I will then get the corresponding number of rules run and since they run concurrently I am getting multiple notifications for the door opening. I could live with multiple notifications. But the real issue is that I am using another rule to turn on a light. As a result of multiple triggers and the rule running multiple times concurrently, the Zooz switch thus gets up to three On requests within such a short time period that it indicates that is on, but the internal "relay" stays stuck off. I have tried this with a GE switch and and Leviton and get the same results.
Using conditional statements and Private Boolean I tried to stop multiple sessions of the rule running, but before the Private Boolean state can be changed, (first action after the conditional statement), the second occurance of the rule has already been triggered and is running.
@lightingdan Don't be offended but I assume you have the unit on the door frame and the magnet on the door? You would be surprised how many do it wrong. Also how close is the magnet. I have found with ecolink that if you don't get the magnet within an 1/8" to 3/16" of the unit when closed it will be unstable. I have moved the magnet as little as 1/4" away from the unit and the LED flashed.
No offence. The unit is on the door frame and the magnet is on the door. I am just over 1/4" away from the unit. The LED is definitely only flashing once when the door opens, but I am getting mulitple signals in 1/10 of a second or less.
Example of the log. I have moved the PB set to be right after the conditional statement with no effect. In this example I am getting two door open signals within 75/100 of a second. The first instance of the rule runs and the PB is set at 12.240. The second instance of the rule has its conditional statement evaluated at 12.414 and at that point the PB state still has not changed. Just not sure how to deal with things that are evaluated in the hundreds of seconds.
@aaiyar After reading the thread you mentioned it doesn't appear that they fixed this. Unless I misread it. Did a fix come in 2.1.4? I have never had my ecolinks do this.
@aaiyar I have the model mentioned in the thread which are the DWZWAVE2.5-ECO. So I am wondering which model they are referring to. Could it be a particular dated production run that had a problem? Just curious.
I would suggest using a Local Variable instead of Private Boolean to do the debounce. This is most likely to avoid multiple instances of the rule running.
The reason that PB isn't working for you is that it doesn't use Atomic State. However, Local Variables do. So this variation of what you're doing may work. That timing you are showing is wicked fast for the bounce.
@bravenel I did as you suggested Bruce, but it doesn't appear to help. Still getting multiple concurrent rules running. Being a crazy ex industrial control software guy, I decided to go for the hail mary pass and just try something. I changed drivers for my Ecolink sensor from the Generic Z wave Contact Sensor to the Fibaro Door/Window Sensor 2.
Viola. Problem is solved. There are no more multiple events from the sensor and it is working just fine. Single open and single close trigger for each open and close of the door. Tested now 35 times without a multiple event. Just a snippet of the test below.
Not sure if using this driver will have an impact on anything else, but it is working for what I want it to do right now.
Thanks for this example Bruce. I'm not sure what atomic state actually is....but using local variables has (in my limited testing) worked on one of my rules. Previously I was using PB's to try to stop the debounce, but this example works well.
I have been using a debounce for a week or so. 3 times in the last 3 days, the rule below has had an error - it sets the local variable to true, and stays that way for hours on end, until I manually reset it. Is it an error in the RM, or an error in this rule. It should only stay true for 3 seconds. That part of the rule is pretty simple. (There are a few delayed cancels in there, which was my previous attempt to get the debouce to work).
