I just had my glass break detector go off, and I recently had my account reverted back so that the monitoring center always calls however they did not call or activate 2way. I am very irate that this had happened and if it had been a real emergency it would have been very bad. I need an explanation as to why this happened or I am switching providers.
Same thing happened to me tonight. My wife set off the alarm but they never called and they never sent anyone.
There are two separate concerns here:
Same thing happened to me tonight. My wife set off the alarm but they never called and they never sent anyone.
You have default rules in place, and in this event an operator accessed the account but a disarm signal came in before a call would be placed, and this was disregarded per that disarm abort signal that came in. For more info about disregard per abort, and options to change it, please read this post.
I recently had my account reverted back so that the monitoring center always calls however they did not call or activate 2way.
I do see record of this action plan change where your account was removed from disregard per abort. I also do not see a disregard per abort in your event history. What looks like occurred was possibly either a bug with the sms text chat that is enabled on your account, or operator error. The event ends with what appears to be an event delay request through the text chat window.
I’m sorry that you experienced this issue, and I am reaching out to the monitoring station tech team to determine what exactly happened. Will follow up with what I hear.
I’ve confirmed with our monitoring station that they actually had a one-off error on your account action plan that was caused when they changed it to a No Disregard Per Abort account. Apparently this caused a bug with the steps after the text sms chat.
They have identified the issue and I am told this is now resolved.
I apologize that this issue occurred. I’ve added a free month of monitoring to your subscription.
Let me know if you have any questions about the event.
I understand that there is a balance between being efficient and not dealing with a lot of false alarms and providing dependable security.
I have also had issue with my alarm going off and not being called by dispatch. It has happened a few times and i have also made all the switches in dispatch protocol to always call,
.On the last issue I had where I was questing dispatch response, I was told it could be my panel failing. I didn’t argue and spent a lot of money to switch panels. My point is, I, and most others are very concerned with dispatch reliability. To the point that they will spend money to ensure it. We don’t want to wait for an actual incident to “test” the reliability.
With that being said, would you consider auditing your system and the current changes and their impact? Approach it with an open mind and without bias (e.g. this should work for everyone). Make changes as needed and then communicate those changes to us.
Failing schedules at sunset is one thing, not having 110% confidence dispatch will be there when needed is another and right or wrong, there are some that feel there may be an opportunity for improvement.
Alright, thanks for your help. As long as it was a one time issue I will not be switching.
.On the last issue I had where I was questing dispatch response, I was told it could be my panel failing. I didn’t argue and spent a lot of money to switch panels. My point is, I, and most others are very concerned with dispatch reliability. To the point that they will spend money to ensure it. We don’t want to wait for an actual incident to “test” the reliability.
I appreciate your feedback, but please do not muddy the waters here, the issue you reported that prompted a suggestion to replace your panel was indeed caused by your panel.
Your panel reported activity to Alarm.com, confirmed from your cellular module, for zones and partitions that were not present on the panel. It sent completely errant signals when no actual alarm event occurred, immediately following a boot up. That is a failing of the panel. It appeared to be old or corrupted data.
In this user’s case, there was an error of the monitoring station action plan software caused by a change. The issues are very distinct.
Now, that said, the suggestion you are making is a good one. We have discussed in the past this very issue. Requesting to remove Disregard per Abort requires custom rules on an account. It is not as easily tested as say, adding a contact or changing a number.
The kind of testing you are referencing for a custom action plan change requires alarm signals from the panel, and an operator accessing the account in response.
I’ll bring this up with our team and the monitoring station and see if we can find a good solution for simulation of such an event, or just require alarm signals from the user as part of the change process.