I have an analog doorbell and made this smart using an Aqara contact sensor and relay to trigger the contact. Everything is working fine and each time someone is ringing I get a notification on Telegram and some Alexa devices.
But from time to time “some” people are pushing the ring button multiple time. This results in spamming Telegram and Alexa will have a queue of notifications.
My idea is to limit the forwarding within this rule. If there are multiple events from the doorbell I want only forwarding this once to Telegram and Alexa within 10 seconds (or so).
Yes, I can create a helper item to check against.
But maybe there is another better solution to handle this?
OH is built around the concept of items, so many times an additional item is the smart way to handle things and even broadly used solutions to this kind of problem use a proxy item. For example, this rule template:
That said, there are many other ways to approach this as well, and “better” really depends on how you have already set it up and what you are comfortable scripting. Other options might be:
Have the notification rule start a persistent timer and check the status of that timer on each rule run
Store the current time in the sensor item metatdata at each rule run to check what the most recent notification time was
Use persistence to get the item history and access the most recent changed timestamp that way
I use UI-based rules so, far and away, the most streamlined option for me would be to have a proxy item with expire settings which gets turned on when the notification rule runs. Checking that proxy item state in the rule condition then eliminates any additional run of that rule until the expire has returned the proxy item to off.
I like all of @JustinG’s Idea but have an additional approach to consider.
Even though I’m the author of Debounce, I wouldn’t use it for this because we want the alert of the first event, not the last.
All three of Justin’s ideas are basically different implementations of the same thing (i.e. ignore all events after the first one for a time) and mine is no different. Generically, I would put a timestamp into the sharedCache after sending an alert. Then I’d add a condition script to block execution of the rule unless enough time has passed since the last alert was sent.
If I were using openhab-rules-tools (I’m the author, why wouldn’t I? ) I’d use the RateLimit. This basically does the timestamp keeping and checking for you. The code for the Script Action would look something like
var { rateLimit } = require('openhab_rules_tools');
var rl = cache.private.get('rateLimit', () => new rateLimit.RateLimit()); // pull it from cache or create a new one if there isn't one
var runMe = () => {
// code to send alert goes here
};
rl.run(runMe, 'PT10S');
RateLimit will ignore any calls to run that take place less than 10 seconds (in this case) of the last time it successfully ran. The second argument can be anything supported by time.toZDT().
