Hi all,
I'm looking for advice/suggestions on implementing limited SMS/text message alerts. I've used Panasonic IP cameras that have a delay feature after alerts, so that you can send a text message when there is motion detected, and then *not* send anymore text messages for some user-specified delay, like 5 minutes.
Ideally I'd like my system to send me a text message when there's motion detected, then keep recording/emailing/ftping (probably a separate filter), so that I only get 1 SMS per 5 minutes. That way if there were a series of "events" as ZM sees them, it might be someone walking across the room 20 times in a 2-minute period, but I would only get 1 SMS rather than 20.
I have been searching for ways to do this here in the forums but I'm not finding anything. Is anyone else doing this, or is there already a way to do this using clever filters that I'm not thinking of?
Send one alert every N minutes
The easiest way may be to use an external script to send the SMS's out (I use one in conjunction with the MercurySMS tool). The script could timestamp a file and simply check the age of this stamp prior to sending - if it's younger than 5 minutes then skip the SMS.
However, is your intent to avoid too many texts on grounds of cost? 'Hassle-factor'? It may be worth thinking about this from another perspective and deciding if there really is a problem to solve - if you're getting 20 alerts in two minutes then it may be worth looking at your settings to merge these into few alerts (i.e. lengthening the buffers). Another strategy might be to only send SMS alerts for motion over x seconds duration.
Mathew
However, is your intent to avoid too many texts on grounds of cost? 'Hassle-factor'? It may be worth thinking about this from another perspective and deciding if there really is a problem to solve - if you're getting 20 alerts in two minutes then it may be worth looking at your settings to merge these into few alerts (i.e. lengthening the buffers). Another strategy might be to only send SMS alerts for motion over x seconds duration.
Mathew
Thanks Mathew,
I've been thinking of using the Perl snippet in the Wiki to scan the database for events and do a one-time trigger. I've done code like that before for web site monitoring (SMS me when the database server goes down, but only once per 10 minutes so I don't get repeated text messages when all users keep trying to reload pages), so I can pretty much just drop it in and it should be fine. But I always prefer a solution that doesn't involve adding too many services when possible, because each time two systems have to interact you create room for errors, problems, and what-not. My goal is to keep the system very stable and simple. My thought was that maybe ZM kept a timestamp of when an SMS was sent, and could be configured to ignore future SMS alerts until some number of seconds had passed.
The issue is partly of cost and partly annoyance. I use SMS for critical business alerts, and the last thing I want is 200 text messages tying up my phone and data connection when something happens. You're right to question whether there is truly an issue to solve, but there's also the issue of failure or error. If I'm away and the system goes haywire, I could rack up tens of thousands of SMS messages in a very short time. I do have an SMS allowance but at $0.10 a message thereafter it would add up quickly. Not to mention it would probably crash my phone. Major cost and hassle factor. So I like to set reasonable limits on anything that can incur per-usage charges or cause unlimited activity on outside networks. I don't care as much if ZM fills up my hard drive, but if it starts sending out thousands of packets on Comcast's network I could find myself looking at a TOS violation. It's just a matter of peace of mind, really.
Thank you for the thoughts!
I've been thinking of using the Perl snippet in the Wiki to scan the database for events and do a one-time trigger. I've done code like that before for web site monitoring (SMS me when the database server goes down, but only once per 10 minutes so I don't get repeated text messages when all users keep trying to reload pages), so I can pretty much just drop it in and it should be fine. But I always prefer a solution that doesn't involve adding too many services when possible, because each time two systems have to interact you create room for errors, problems, and what-not. My goal is to keep the system very stable and simple. My thought was that maybe ZM kept a timestamp of when an SMS was sent, and could be configured to ignore future SMS alerts until some number of seconds had passed.
The issue is partly of cost and partly annoyance. I use SMS for critical business alerts, and the last thing I want is 200 text messages tying up my phone and data connection when something happens. You're right to question whether there is truly an issue to solve, but there's also the issue of failure or error. If I'm away and the system goes haywire, I could rack up tens of thousands of SMS messages in a very short time. I do have an SMS allowance but at $0.10 a message thereafter it would add up quickly. Not to mention it would probably crash my phone. Major cost and hassle factor. So I like to set reasonable limits on anything that can incur per-usage charges or cause unlimited activity on outside networks. I don't care as much if ZM fills up my hard drive, but if it starts sending out thousands of packets on Comcast's network I could find myself looking at a TOS violation. It's just a matter of peace of mind, really.
Thank you for the thoughts!