I have hacked my doorbell/intercom to send a notification when it is rung. However, the hack is triggered by talking on the intercom as well, so I would like to send one notification and then wait 3 minutes.
var Timer tDoorBell = null
//Send a notification if the Door Bell is rung
rule "Front Gate Door Bell Rung"
when
Item Door_Bell changed to OPEN
then
if (Door_Bell_Notification.state == ON) {
sendNotification("email@address.com", "Door Bell has been rung")
sendMail("email@address.com", "Someone at the front door", "Door Camera", "http://cameraurl")
postUpdate(Door_Bell_Notification, OFF)
tDoorBell = createTimer(now.plusMinutes(3)) [|
postUpdate(Door_Bell_Notification, ON)
]
}
end
What currently happens is that if I talk on the intercom, it triggers multiple times, which is correct, but I get multiple notification and emails, which shouldn’t happen. The Door_Bell_Notification item does switch off and then on again in 3 minutes, but it seems the rule is switching it off the first time the rule runs, and then it is being ignored and running again anyway.
Or, the rule is running again anyway before the Notification flag is switched OFF by the previous rule. By default, Openhab allows multiple copies of rules running to serve multiple triggers.
Moving your postUpdate to the beginning may help, but may not be enough depending how fast the triggers come in (audio frequency I’m guessing?)
Else you will have to look into reentrant locking.
Conditioning your input signal to reduce triggers could be as simple as adding a capacitor and resistor, but a bit outside scope here.
The advice to have Timer check/set null is good, else you will get multiple postUpdate ON to confuse the issue.
Thanks. I’m guessing because I’m using a multimeter to check, but the outdoor unit (OU) and the indoor unit (IU) are connected by only two wires. It seems the IU supplies a little voltage to run the OU. When the bell is rung, the voltage is also used to transmit audio from the IU to the OU, and the bell sound is heard outside. Running the speaker on the OU takes power, and the voltage drops measurably on the IU. If you are talking on the intercom, loud noises and speaking loudly drops the voltage more than speaking softly, so I am getting false positives through my hack.
So my hack is to monitor the voltage, and if it drops below a certain level, then send an MQTT alert.
I am running OpenHAB on a Mac mini, so I don’t think processing power for the rules is an issue, and the alerts from myopenhab come through very fast, so it seems like everything is able to keep up.
What I tested now, was to trigger the rule (ring the bell), wait 10 seconds, and do it again. And both alerts came through. So I don’t think it’s a timing issue.
What sequence of events do you see in your log? Sprinkle some logInfo into the if block and timer block. I guess there is something else involved with Door_Bell_Notification, else the rule would not even run the first time (state not being ON initially)
There have been reports suggesting rule editing in OH2 can result in ‘ghost’ rules hanging around
Powerful host makes reentrancy issues more likely, but your 10-second test suggests that’s not what is going on here. Putting your “lockout” action at the front remains a good idea.
Simplifying and doing away with the extra Item, using the existence of the Timer itself as the lock indicator, as suggested by Markus is also a good plan. But what you have should work.
