I am really not happy with our monitoring right now…we had a false alarm (perimeter door opened) at 7:33am this morning that we immediately disarmed. I did not receive a call, so I assumed that it was disarmed quick enough that it didn’t trigger a response from monitoring.
14 minutes later, I got a call from monitoring stating that since 2-way communication failed, they dispatched police.
I was never contacted through 2-way communication, and if I remember correctly, there is a bug with 2-way and Verizon and it doesn’t even work.
She said she cancelled dispatch, but we just received a visit from the police, which will cost us $216.00 now. So on top of everything, they didn’t even cancel the dispatch.
So how do I fix this? I paid too much money to have a partially working system. Please let me know what I can do to get this system working the way it should. Do I need a different cell sled?
And why did it take 14 minutes from the alarm before I was contacted? That seems like an awfully long time, had the alarm been valid.
Also, who can I speak to about covering the cost of the dispatch, as I was never given an opportunity to cancel it before police were dispatched.
So I am going to address these sequentially here. First:
I did not receive a call, so I assumed that it was disarmed quick enough that it didn’t trigger a response from monitoring.
Both Two Way Voice and the Premise phone number were attempted. There was no response on Two Way or the premise phone. I’ll have to dig in with the panel history to determine the Two Way failure cause.
The order in which calls are placed and the numbers dialed prior to police dispatch are controllable by Surety users at any time in the Surety System Manager.
You can adjust when police dispatch would normally occur by moving cell contacts prior to the dispatch line. The standard order you currently have set is Two Way, Premise, Dispatch, Cell Contacts.
And why did it take 14 minutes from the alarm before I was contacted? That seems like an awfully long time, had the alarm been valid.
The time between the first alarm signal hitting the monitoring station and the follow up call placed to your cell phone was 10:34. the bulk of that time (roughly 9 minutes) was the dispatch call to the local police. Unfortunately this time will depend on the call processing time of the local jurisdiction.
Between the Zone type 4 bug and the 2-way communication bug, I’m wondering if I should switch to a Qolsys system. I really don’t have much confidence in my 2Gig system anymore.
I had a false alarm nearly 7 months (Feb 17) ago and had the same 2-way communication error and also resulted in a police dispatch, which th were able to cancel in time. But if 2-way communication is not working on a wide-spread basis, why is Dispatch still using that as the primary method of contact and then immediately dispatching police? It seems to me that their procedures should be updated since 2-way communication does not work for 2Gig customers.
Please let me know what you find and where I can submit a police invoice for reimbursement when I receive it.
She said she cancelled dispatch, but we just received a visit from the police, which will cost us $216.00 now. So on top of everything, they didn’t even cancel the dispatch.
Operators did call the police to cancel dispatch immediately after speaking to you, unfortunately it looks like there was another long-ish wait to get hold of police dispatchers (roughly 11 minutes) and the police were unable to cancel by the time officers were on scene.
I did not receive a call to the premise phone. We all were home at the time, and our home phone never rang.
I have a recording where operators get the answering machine in response to the call, I can’t say why you wouldn’t get the phone ringing locally. Do you know how quickly the answering machine is set to pick up calls?
In any case, it would be advisable to change your call order so cell contacts are also placed prior to dispatch.
I’ll look into the Two Way Voice error to determine the potential cause. The general Two Way Voice issues you are referencing never affected all calls and should not have affected this one (the issue was recently patched).
I can confirm that two cell contacts are now set up to be called prior to dispatch.
Yes, I am investigating the Two Way Voice call and I am speaking to the monitoring team. I’ll follow up here shortly with what I find out to address the other questions!
Not a problem at all, happy to help! Thank you for your patience as we look into this for you.
BTW, regarding the Voicemail, the standard procedure is to generally not leave messages on premise phone answering machines. Due to landline answering machines often playing the recorded message audibly as they are recorded this is avoided.
That makes sense. Can you tell me what phone number would show up on caller ID when they call? Is it the number that ends in 6101? I’m also going to check into my telephone provider to see why those calls aren’t ringing my landline or showing up in the online call history. Thank you!
The timestamp for that Premise call where they got the machine is 07:34:57 btw.
FYI, it looks like this system was disarmed pretty quickly after the alarm. We actually have an upcoming update to service procedures planned that will change the way this works going forward. Right now, a password confirmation of false alarm is required to disregard, but we will be updating the procedure to by default disregard and not dispatch if an abort signal (disarm at the panel) is received. This will help avoid some false alarm instances like this.
An announcement will be sent out via email to all users regarding this.
Confirming with the monitoring team but it looks like the potential issue which was resolved by a software update had to be rolled back due to an unforeseen bug interaction. It looks like it was rolled back prior to this event.
Based on what I see in ADC it looks like you may have experienced the Two Way error we’ve been investigating.
The good news is that the overall fix is being reapplied in a week or so after the bug issue is resolved, at which time this two way problem should no longer occur.
We will need some specific additional details about this event. I’ll send a private message your way.