I haven't used a private boolean before, will it survive multiple instances or do you need to use a global variable for that?
It should does.
1 Like
Here's a similar rule that I use to send notifications via TTS that makes use of a Private Boolean to prevent repeat messages.
I've never had repeat messages
One difference between your rule and mine is that I explicitly test if the private boolean is True.
I would actually restructure your rule thusly:
Make the trigger "If driveway sensor is OPEN"
Leave the trigger as is
The actions should be something like:
IF (Driveway sensor is closed) THEN
Exit Rule
ELSE-IF (IF Private Boolean is TRUE) THEN
Set Private Boolean False
Notify Mark ....
Set Private Boolean True --> delayed: 0:05:00
END-IF
1 Like
One of the challenges of my situation is that the sensor doesn't respect open versus closed. Every time the mighty mule fires, the sensor toggles N times. Sometimes N is an odd number and sometimes N is an even number. So, sometimes it stops on closed and sometimes it stops on open. Dunno. And I suppose I don't care because any sensor events mean a car is on the driveway. Which is why my trigger was "Driver Sensor Changed".
So @aaiyar I don't think I can use your suggestion as is, can I?
Any idea why my rule wouldn't work? Any idea why the log shows the apparent discrepancy? . Grasping for anything at this point....
The triggers are happening faster than Rule Machine executes. What sensor do you have the Mighty Mule connected to?
Try this contact debouncer App.
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()
}
1 Like
Jon, thank you, I'll definitely give this a try when I get back home end of the week. With that said, I'm still keen to understand my rule doesn't work.
Wow, really, that's an intriguing theory! Here's what confuses me about it... See how the rule sets PB to false at 5:28:50.937? That's exactly as designed. Setting PB to false is the way my rule indicates that the initial notification has occurred so don't notify on other sensor events for the next five minutes.
Despite this, at 5:28:51.302 (a bit less than half a second later without any other intervening changes to the value of PB), the next firing of the rule evaluates the value of PB as NOT False. Which results in a duplicate notification.
How could this possibly be? Do you see the apparent contradiction?
I use the Ecolink contact sensors because they have external contacts for this purpose.
I suspect that this is because variables take time to be persisted to the database, your events are coming in fast so it's likely that when the subsequent instances of the rule fire, the variable hasn't yet been persisted. This means that the next instance of the rule reads the old value.
I don't use RM myself, but base this on similar issues I've seen when writing drivers that try to prevent duplicate messages.
You might be able to test this theory by logging the value of the variable at the top of the rule (so that you can see the current value that that instance of the rule sees when it executes).
My first thought is that it's the sensor reporting too fast issue. I had that with contact sensors and used Bruce's app and have not had any issues since. I'd set the rule to 5000 msec and then you can get rid of the delay in the rule itself.
Really interesting ideas guys. I'll give these ideas a try this weekend. Really appreciate the help!
I used the contact debouncer App, and can't get the debounced virtual device to fire with the length set at 500ms. The physical sensor is quadruple/quintuple firing every time, 8-10 times per day as I would expect. The virtual contact opened and closed one time the last couple days.
Couple theories
- the app description says "Debounce double reporting...." My sensor is burst firing more than two times -- would that mess with the app somehow?
- the way the physical contact sensor is setup with the Mighty Mule, there is no Open or Close, just a random number of events alternating between open and close. Where she stops, nobody knows!
Any ideas? I left a message with support a couple days ago. No word back yet.
The debounce app wonāt work if if the mighty mule fires an odd number of times. Youāll miss the transition altogether, I believe. For example, a rapid open, closed, open would be debounced to just open.
Another option is to use a Local Boolean Variable instead of a Private Boolean. If I recall correctly, Bruce mentioned in another thread the RM Local Variables are the quickest to respond. I am not sure that this would even be quick enough. Might be worth a try, though.
For shits & giggles, can you try decreasing the sensitivity on the Mighty Mule potentiometer?
Maybe you could try a more indirect trigger using a virtual switch. Use two simple rules, with no conditional statements needed.
Rule 1
Trigger: Driveway sensor ON ##or Closed or whatever it does when it is activated
Action:
Turn virtual switch ON ##no conditional statements here, just do it.
Rule 2
Trigger: Virtual switch on
Action:
Send pushover message ##no conditional statements here, just do it.
Delay 5 minutes
Turn virtual switch OFF
No matter how many times the mighty mule thing triggers, the virtual switch can only turn on once. Once it is on it canāt be turned on again until it is off. So there should only be one trigger going to rule 2, until the virtual switch gets turned off.
I think this should work, should be easy to try it.
7 Likes
Guys, I really appreciate all the ideas. I tried messing with the potentiometer, no joy. I was about to swap out the private boolean for a local variable when I saw @geroose's idea. The clouds immediately parted to reveal rainbows and butterflies. Brilliant and simple solution. All solved. Thank you thank you thank you!
4 Likes
You'll see in that earlier debounce thread that I'm also trying to stop a Mighty Mule from stuttering ...to no avail. Here's a dirty fix;
"Alert,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, vehicle in driveway'"
I get 1 to 3 "Alerts" then the "vehicle in driveway." Sounds OK, and nowhere near as annoying as the previous stuttering.
