@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.
Apparently, the issue is with specific model numbers.
@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.
Maybe so - what I remember reading is that some individual units for the contact sensors display the double reporting, while others don't.
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.
2 Likes
@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.
1 Like
Too funny! Way to go.
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).
I am unsure as to why it's setting to true for hours on end.
You're going to have to show the logs for the rule to demonstrate what you think is wrong with it.
Interesting, my Ecolink sensors have a "suppress duplicate contact events" setting seems to prevent this issue with mine.
Hey Hike20. Where is that suppress duplicate contact setting?
Which driver are you using for your Ecolink sensors. Contact or motion, BTW?
@bravenel -- So I tried this "busy" approach to fix a problem I'm having with my Driveway lights flashing on/off when a rule fires twice. Didn't work. The rule is firing SO QUICKLY in succession, that I'm seeing this in the log:
app:361 2019-09-19 09:11:40.460 info Action: Set Busy to true
app:361 2019-09-19 09:11:40.455 info Action: IF (Variable Busy(false) = true FALSE) Exit Rule (skipped)
app:361 2019-09-19 09:11:40.454 info Action: Set Busy to true
app:361 2019-09-19 09:11:40.448 info Action: IF (Variable Busy(false) = true FALSE) Exit Rule (skipped)
It is setting the variable to true at 9:11:40:454, then checking and finding it false at 9:11:40:455.
BTW -- the "motion active" that triggered this rule fired twice with a difference of 12ms. So I'm not quite getting "atomic" behavior for this variable. I'm on 2.1.4.121 BTW.
No time in 12 ms to do anything, so you are getting two instances of the rule running. Has nothing to do with atomic.
What device and what driver is causing this? This is a driver issue that needs to be addressed.
I've got two very different situations going on here, both firing rules more than once.
1 - "Arrive via Garage": I have two contact sensors on my garage doors (they are old Aeon door sensors using the Generic Zwave contact sensor driver). If either opens, and my interior lights are off, they trigger a 5 minute "wait for the laundry door to open" (same sensor here). If the door opens, the kitchen lights come on. I have the "busy" variable deboucing in there. This rule just triggered 2 times, and the "wait for the door to open" fired 4 times! The sensors here are on my upstairs hub, and the rule and light are on my downstairs hub (the HubConnect server, using Event sockets). The log for this rule firing is included below. Note: on the client hub, the logs show the Laundry door opening twice at that time, 1ms apart.
2 - Driveway motion (and a similar porch motion rule). These use EcoLink motion sensors using the Generic Z-wave motion sensor driver. They are fed into the Zone Motion Controller app, which turns the lights on or off with motion change. I have 2 sensors (garage, porch). They are fed into 2 separate Zones: both -> garage, porch -> porch (so the porch sensor is in both). When there is motion near the garage, the garage lights should come on. If there is motion at the porch, both garage and porch lights come on. The garage motion sensor and garage light are on my upstairs hub, the porch motion sensor and porch light are on the downstairs hub. The garage light rule runs on the upstairs hub (but references the porch motion sensor shared from the server -- that isn't being used in my tests). The porch light rule runs on the downstairs hub, referencing the garage light which is shared from the client.
I can remove the Zone stuff with the trade off of making the rules a bit more complex. But the kitchen light only uses contact sensors, and is having issues. The garage and porch lights only use motion, and are having issues also.
I'm happy to send you anything that might be helpful in terms of logs, config dumps, whatever. If you want to take this off the board you can email me directly.
I need to get this fixed because these are pretty much all my automations, they aren't working, and it is getting very frustrating.
Here are a couple of log snippets:
dev:1322019-09-19 10:34:25.826 infoKitchen - Pendant Lights switch is on
app:1702019-09-19 10:34:25.290 infoAction: Set Busy to false --> delayed: 0:00:02
app:1702019-09-19 10:34:25.284 infoAction: END-IF
app:1702019-09-19 10:34:25.270 infoAction: Set Busy to false --> delayed: 0:00:02
app:1702019-09-19 10:34:25.266 infoAction: Set Busy to false --> delayed: 0:00:02
app:1702019-09-19 10:34:25.261 infoAction: END-IF
app:1702019-09-19 10:34:25.249 infoAction: Set Busy to false --> delayed: 0:00:02
app:1702019-09-19 10:34:25.246 infoAction: END-IF
app:1702019-09-19 10:34:25.245 infoAction: END-IF
app:1702019-09-19 10:34:25.122 infoAction: IF (Laundry door open TRUE) On: Kitchen - Pendant Lights
app:1702019-09-19 10:34:25.117 infoAction: IF (Laundry door open TRUE) On: Kitchen - Pendant Lights
app:1702019-09-19 10:34:25.099 infoAction: IF (Laundry door open TRUE) On: Kitchen - Pendant Lights
app:1702019-09-19 10:34:25.086 infoAction: IF (Laundry door open TRUE) On: Kitchen - Pendant Lights
app:1702019-09-19 10:34:24.998 infoWait over: Laundry door contact open
app:1702019-09-19 10:34:24.905 infoWait over: Laundry door contact open
app:1702019-09-19 10:34:24.861 infoWait over: Laundry door contact open
app:1702019-09-19 10:34:24.859 infoWait over: Laundry door contact open
app:1702019-09-19 10:34:19.440 infoAction: Wait for events: Laundry door open --> timeout: 0:05:00
app:1702019-09-19 10:34:19.440 infoAction: Wait for events: Laundry door open --> timeout: 0:05:00
app:1702019-09-19 10:34:19.410 infoAction: IF (Kitchen Lights(off) is off(T) AND
Laundry door closed(T) [TRUE]) THEN
app:1702019-09-19 10:34:19.410 infoAction: IF (Kitchen Lights(off) is off(T) AND
Laundry door closed(T) [TRUE]) THEN
app:1702019-09-19 10:34:19.306 infoAction: Set Busy to true
app:1702019-09-19 10:34:19.301 infoAction: IF (Variable Busy(false) = true FALSE) Exit Rule (skipped)
app:1702019-09-19 10:34:19.290 infoAction: Set Busy to true
app:1702019-09-19 10:34:19.284 infoAction: IF (Variable Busy(false) = true FALSE) Exit Rule (skipped)
app:1702019-09-19 10:34:19.201 infoArrive via Garage Triggered
app:1702019-09-19 10:34:19.182 infoArrive via Garage: Garage door 1 contact open
app:1702019-09-19 10:34:19.173 infoArrive via Garage Triggered
app:1702019-09-19 10:34:19.161 infoArrive via Garage: Garage door 1 contact open
Could RM have a truly atomic option for a rule that says "Only run one instance of this rule at a time"? That would likely solve all my problems, and obviate the need for this attempted debouncing hack.
Why do you have to use two sensors, instead of one?
Sorry -- I was unclear here. I have two garage doors, one sensor on each. The rule triggers if either door opens.
