I have rule that the private variable does not get back to the value I mention after a delay. I am puzzled about what is the mistake I wrote.
Here is the rule:
Sometimes, the Private Boolean remains at True which causes the whole rule to stop working until I manually set the variable back to false. It can work for a couple of hours, thus the intrinsic aspect of the bug makes me wonder if the delay is not well written.
Thank you in advance.
Are you trying to eliminate the double chime you posted about earlier? Are you seeing any errors in the logs for the time when the variable did not get set back to false? Look for any POP errors.
One thing you can do to try and avoid this is to schedule the delayed task before you set the PB to true. You'd be changing from an action of delay to a delayed action. So, your action can look like this, it would replace what is inside of your conditional statement:
Set PB to False delay 4 seconds
Set PB to true
Set the volume
Make the chime.
The difference is that delayed actions are all schedule at the beginning of the actions vs performing a rule continuation after the action of delay which is what you have currently. That should still set the rule PB to False even if there's a POP error.
Hi Ryan,
Yes, I am still trying to find a way that is more reliable to avoid double chime. Actually, even double notification (I have a similar issue with PushOver).
The log looks like that:
dev:202020-04-05 09:23:35.098 am infoAeotec Siren 6 - Chime stopped
dev:242020-04-05 09:23:32.141 am infoDining Room Motion Sensor: motion is inactive
dev:162020-04-05 09:23:31.837 am infoGarage Motion Sensor: motion is active
dev:162020-04-05 09:23:31.758 am infoGarage Motion Sensor: motion is active
dev:72020-04-05 09:23:29.962 am infoGarage Ceiling Light switch is on
dev:72020-04-05 09:23:29.941 am infoGarage Ceiling Light Button 1 pushed
dev:162020-04-05 09:23:24.296 am infoGarage Motion Sensor: motion is active
dev:202020-04-05 09:23:24.269 am infoAeotec Siren 6 - Chime playing '26. Gong'
dev:202020-04-05 09:23:23.488 am infoAeotec Siren 6 - Chime playing '26. Gong'
dev:322020-04-05 09:23:23.420 am infoIndoor Garage Door was closed
dev:162020-04-05 09:23:23.357 am infoGarage Motion Sensor: motion is active
dev:202020-04-05 09:23:23.268 am infoAeotec Siren 6 - Chime playing '26. Gong'
dev:162020-04-05 09:23:22.935 am infoGarage Motion Sensor: motion is active
dev:162020-04-05 09:23:22.830 am infoGarage Motion Sensor: motion is active
dev:202020-04-05 09:23:22.580 am infoAeotec Siren 6 - Chime playing '26. Gong'
app:22020-04-05 09:23:22.515 am infoTurn On Garage Ceiling Light when Garage Motion Sensor active Turn On
dev:162020-04-05 09:23:22.352 am infoGarage Motion Sensor: motion is active
dev:202020-04-05 09:23:22.134 am infoAeotec Siren 6 - Chime playing '26. Gong'
app:382020-04-05 09:23:19.001 am infoTurn On Garage Ceiling Light when Indoor Garage Door Opened Turn On
app:382020-04-05 09:23:18.991 am infoTurn On Garage Ceiling Light when Indoor Garage Door Opened Turn On
dev:322020-04-05 09:23:18.840 am infoIndoor Garage Door was opened
dev:322020-04-05 09:23:18.834 am infoIndoor Garage Door was opened
This is with the rule changed (from my understanding if your explanation):
I've tried the "denounce" from the other thread, but the only thing it was doing was to push in the future from few milliseconds the double chimes. I tried for a week with a lot of double, triple and more chimes.
For context, the double message thread here (How to eliminate double chime) was around the Zoos 4-in-1. The Zooz has a "suppress duplicate motion" and for the contact sensor was a home-made Debounce virtual device.
Now, I am using a generic z-wave contact sensor only on that rule. I'm trying to find a "universal" solution regardless of the device. The Zooz issue is fixed by not double opening the light, however, the chime remains an issue... a noisy issue 
Sometimes I can chime 5 times in a row if someone opens the door. I suspect this: "Garage Door was opened" is the issue.
For everyone information, I also tried:
Are the sensors contact or motion?
For that particular rule, it is a contact sensor (actually three). The brand is BeSense (https://www.amazon.com/gp/product/B073RV9VYC/). They are working well as fast as I know.
Well, I see multiple issues going on here. Your sensors are all reporting multiple times. Each 3 times actually. Which is not correct and the reason that you are getting multiple events occurring which is the reason your are getting multiple tones.
Do you have these joined securely or insecurely? What is your setting for Z-wave secure in your hub? What driver are these devices using?
Sounds like a fun or frustrating project for the day. I am going to set up a virtual sensor that I can activate and it will send multiple sendEvents. From there, I can set up rules to see if I can cause a action to occur only once. It may be possible, but it will probably be ugly.
PS - I do this a learning exercise. I am great with logic trees, but just learning Rule Machine (I was busy with other things).
Here is some log with the rule (any then a check on open):
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 10:58:03.107 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong'
[dev:23](http://10.0.0.191/logs/past#dev23)2020-04-05 10:58:02.934 am [info](http://10.0.0.191/device/edit/23)Alicia's Air Purifier power is 16.5W
[dev:23](http://10.0.0.191/logs/past#dev23)2020-04-05 10:58:02.902 am [info](http://10.0.0.191/device/edit/23)Alicia's Air Purifier power is 16.5W
[dev:23](http://10.0.0.191/logs/past#dev23)2020-04-05 10:58:02.827 am [info](http://10.0.0.191/device/edit/23)Alicia's Air Purifier power is 16.5W
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 10:58:02.728 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong'
[dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 10:58:02.694 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 10:58:02.627 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong'
[dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 10:58:02.614 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 10:58:02.533 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong'
[dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 10:58:02.454 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 10:58:01.960 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong'
[app:38](http://10.0.0.191/logs/past#app38)2020-04-05 10:57:59.477 am [info](http://10.0.0.191/installedapp/configure/38)Turn On Garage Ceiling Light when Indoor Garage Door Opened Turn On
[app:38](http://10.0.0.191/logs/past#app38)2020-04-05 10:57:59.468 am [info](http://10.0.0.191/installedapp/configure/38)Turn On Garage Ceiling Light when Indoor Garage Door Opened Turn On
[dev:32](http://10.0.0.191/logs/past#dev32)2020-04-05 10:57:59.366 am [info](http://10.0.0.191/device/edit/32)Indoor Garage Door was opened
[dev:32](http://10.0.0.191/logs/past#dev32)2020-04-05 10:57:59.359 am [info](http://10.0.0.191/device/edit/32)Indoor Garage Door was opened
I understand it should not report 3 times. Here is how it is mounted. The light on the device looks to flash once when I open the door. But, because it is not flushed, it could send more signals? Maybe! I'll see if I can improve the mounting.
Secure or not... good question. Here you got me. I have no clue. I'm pretty new with Z-Wave and I just followed the basic inclusion without anything else. The instruction was saying to press a button three times, I did, that's it. If you believe I need to do something, please provide me a link and I will follow up. Does it change something about secure or not in term of signaling an event?
The driver is "Generic Z-Wave Contact Sensor".
Very cool project indeed. Keep me updated!
Other logs:
[dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 11:04:52.947 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong' [dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 11:04:52.702 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong' [dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 11:04:52.482 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong' [dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 11:04:52.385 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong' [dev:20](http://10.0.0.191/logs/past#dev20)2020-04-05 11:04:51.961 am [info](http://10.0.0.191/device/edit/20)Aeotec Siren 6 - Chime playing '26. Gong' [dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 11:04:51.892 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active [dev:32](http://10.0.0.191/logs/past#dev32)2020-04-05 11:04:51.530 am [info](http://10.0.0.191/device/edit/32)Indoor Garage Door was closed [dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 11:04:50.986 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active [app:2](http://10.0.0.191/logs/past#app2)2020-04-05 11:04:50.676 am [info](http://10.0.0.191/installedapp/configure/2)Turn On Garage Ceiling Light when Garage Motion Sensor active Turn On [dev:16](http://10.0.0.191/logs/past#dev16)2020-04-05 11:04:50.612 am [info](http://10.0.0.191/device/edit/16)Garage Motion Sensor: motion is active [app:38](http://10.0.0.191/logs/past#app38)2020-04-05 11:04:48.376 am [info](http://10.0.0.191/installedapp/configure/38)Turn On Garage Ceiling Light when Indoor Garage Door Opened Turn On [app:38](http://10.0.0.191/logs/past#app38)2020-04-05 11:04:48.302 am [info](http://10.0.0.191/installedapp/configure/38)Turn On Garage Ceiling Light when Indoor Garage Door Opened Turn On [dev:32](http://10.0.0.191/logs/past#dev32)2020-04-05 11:04:48.199 am [info](http://10.0.0.191/device/edit/32)Indoor Garage Door was opened [dev:32](http://10.0.0.191/logs/past#dev32)2020-04-05 11:04:48.189 am [info](http://10.0.0.191/device/edit/32)Indoor Garage Door was opened
This time, 5 chimes for 3 doors opening.
I could understand that my device sends 3 signals hence 3 chimes, but the numbers do not correlate. 
What do you mean by flushed? You mean how it is mounted? Has nothing to do with it. This is a software issue. If it were a mounting issue we'd see open/close/open/close/open/close. Instead we see open/open/open.
Secure z-wave setting is in your z-wave setting panel in Hubitat.
It could. What other z-wave devices do you have? It appears that you are getting the signal from this device through multiple repeaters. Some of the signals are less than 8 ms apart. A contact sensor is not going to be able to repeat a signal that quickly.
What do you mean by flushed?
I forgot to attach the image here is how it is mounted:
It looks "bad" but it clearly is on the picture in "closed" and when open it goes to "open". I do not see the light on the device or the log going "close->open->close->open" when moving the door. It is always "open->close" or "close->open".
It could. What other z-wave devices do you have? It appears that you are getting the signal from this device through multiple repeaters. Some of the signals are less than 8 ms apart. A contact sensor is not going to be able to repeat a signal that quick.
That is very interesting. I didn't know about the possibility of multiple repeaters.
I have a list of +60 devices. I'll try to do a summary soon. All of them are z-wave and as far as I know z-wave plus.
You didn't answer my question about your z-wave secure setting. It is not a mounting problem.
I haven't answer because I can't find the answer. I suppose it is not, I did nothing to make it secure.
It is secure by default
Finished some testing. A virtual debouncer may be the way to go. My testing indicates that the events are so close together that it the Event has not changed and that private boolean has not been changed (not unexpected, but self-verified). To document the trivial:
A. Created a Virtual Alarm Drver
/* A virtual contact debouncer to eliminate multiple rule execution */ metadata { definition (name: "AA Virtual Alarm Driver",namespace: "me",author: "me" ) { capability "ContactSensor" command "opened" } } def opened() { log.info "Debouncer triggered" // You can play with the runIn to optimize your installation. runIn(1, startAlarm) } def startAlarm() { log.info "startAlarm Executed" sendEvent(name: "contact", value: "open") runIn(2, closed) } def closed() { log.info "Debouncer closed" sendEvent(name: "contact", value: "closed") }
B. Created a virtual device that is linked to this driver.
C. Created the two rules below (in the second, the log message
(Note the Log can be any action).
D. Set up my virtual contact sensor to send 5 open events as fast as possible. I also tried for 10 ms pause with same result.
dev:51752020-04-05 03:28:52.178 pm infoDebouncer closed
app:32912020-04-05 03:28:50.349 pm infoThe Siren Has Been Activated
dev:51752020-04-05 03:28:50.089 pm infostartAlarm Executed
dev:51752020-04-05 03:28:49.098 pm infoDebouncer triggered
dev:51752020-04-05 03:28:49.048 pm infoDebouncer triggered
dev:51752020-04-05 03:28:49.000 pm infoDebouncer triggered
dev:51752020-04-05 03:28:48.906 pm infoDebouncer triggered
dev:51752020-04-05 03:28:48.829 pm infoDebouncer triggered
dev:51102020-04-05 03:28:48.231 pm infoOpened, count = 5
dev:51102020-04-05 03:28:48.228 pm infoOpened, count = 4
dev:51102020-04-05 03:28:48.225 pm infoOpened, count = 3
Going from bottom, note the five open events sent to system. Followed by 5 triggered events caused by the Rule Machine, followed by a SINGLE Siren, then the debouncer closed. If I use 10 msec delay between events, I get only two triggers in the debouncer.
This runIn of 1 second is ok for a single device. May cause problems for multiple sensors (i.e., wife comes in front at same time as hubby comes in at garage. But...
I'll try again with the debouncer that I saw in this forum:
definition(
name: "Debounce contact",
namespace: "hubitat",
author: "Bruce Ravenel",
description: "Debounce double reporting contact sensor",
category: "Convenience",
iconUrl: "",
iconX2Url: "")
preferences {
page(name: "mainPage")
}
def mainPage() {
dynamicPage(name: "mainPage", title: " ", install: true, uninstall: true) {
section {
input "thisName", "text", title: "Name this debouncer; debounced contact device will have this name", submitOnChange: true
if(thisName) app.updateLabel("$thisName") else app.updateSetting("thisName", "Debounce contact")
input "contact", "capability.contactSensor", title: "Select Contact Sensor", submitOnChange: true, required: true
input "delayTime", "number", title: "Enter number of milliseconds to delay for debounce", submitOnChange: true, defaultValue: 1000
}
}
}
def installed() {
initialize()
}
def updated() {
unsubscribe()
unschedule()
initialize()
}
def initialize() {
def debounceDev = getChildDevice("debounceSwitch_${app.id}")
if(!debounceDev) debounceDev = addChildDevice("hubitat", "Virtual Contact Sensor", "debounceSwitch_${app.id}", null, [label: thisName, name: thisName])
subscribe(contact, "contact", handler)
}
def handler(evt) {
runInMillis(delayTime, debounced, [data: [o: evt.value]])
log.info "Contact $evt.device $evt.value, start delay of $delayTime milliseconds"
}
def debounced(data) {
log.info "Debounced contact $data.o"
def debounceDev = getChildDevice("debounceSwitch_${app.id}")
if(data.o == "open") debounceDev.open() else debounceDev.close()
}
My impression was that the chime was just delayed but I'll give it a shot again. The logic is similar to your test (runInMillis instead of runIn).
I have been using the Debounce and I would say it work ~29/30 now. Still sometime have mega repeating like 3-6 times. Not sure what cause this lag but overall satisfied with the Debounced solution.
Download the Hubitat app
