Help understanding alarm event and central station procedure

Support
1

Today after opening an entry/exit door while the system was armed away, we failed to disarm at the panel quickly enough, resulting in an alarm. The disarm command and code were given via text chat. However, the central station still contacted us via two way voice on the panel, at which time the disregard request was given again; the password was not requested. About 1 second after disconnecting with the central station, the system alarmed again. We disarmed via the panel, with no further calls.

Why did the central station contact us despite having disarmed via chat, and why didn’t they request the password if their protocol is to call despite the chat response? Why did the system alarm again after speaking with the central station? Why wasn’t there another call from the central station after the second alarm event?

2

Happy to assist!

If the system is not disarmed quickly enough, central station operators will respond based on how the account is setup. As this was a burglary alarm event a Chat notification was sent first, followed by a 2-Way call request shortly after.

When both the ARM Chat feature and 2-Way Voice are enabled , they will both be used but there will be a delay on the 2-Way call to allow time for the Chat session to be accessed.

The disarm command and code were given via text chat. However, the central station still contacted us via two way voice

To clarify, the ARM Chat feature through central station does not disarm the system. It does allow you to cancel/verify an alarm event in progress.

Based on history, the Chat session was accessed before the 2-Way call, but the alarm event was not disregarded via Chat until the 2-Way call was underway.

More information on the ARM Chat feature can be found here.

why didn’t they request the password if their protocol is to call despite the chat response?

They typically should require a password when verifying/cancelling an alarm event through 2-Way voice or via call to a listed Premise number outside of the ARM Chat. I have reached out to the monitoring station to figure out what happened here and I will follow up with more information.

About 1 second after disconnecting with the central station, the system alarmed again. We disarmed via the panel, with no further calls…Why wasn’t there another call from the central station after the second alarm event?

The system was not disarmed initially, as the Chat feature does not disarm the panel. After the 2-Way call ended, the panel siren resumed (the siren turns off for the duration of the 2-way call). As this is one alarm event, a new 2-way call or chat session would not have been generated.

3

Thanks for the explanation.

The history shows both the entry door and motion detector alarmed. If an entry door opens, will a motion detector alarm immediately if triggered, or does that get delayed like the entry door even if the motion detector is programmed as immediate alarm during away arming? Did the motion trigger an alarm in this case only because the system wasn’t disarmed in time according to the entry door delay setting?

4

Motions programmed as Group 17 Away Instant Motion are Active only when armed to “Away”, and trips instantly when motion is detected, However, it does not trip if an entry/exit sensor is tripped first.

In this case the Door triggered the alarm. Since the motion was also triggered during the event, it was recorded into history as an alarm, which is why you see the Door then the Motion in activity.

5

I have more detail from the person who was present regarding the sequence of events:

-The entry door was opened
-Siren sounded because panel was not disarmed in time
-System was disarmed at panel by entering passcode, siren stopped
-The chat window was opened, and the abort was requested and accepted
-The 2 way call was initiated, the operator acknowledged receiving an abort request via chat and confirmed it was a false alarm, and terminated the call without asking for password
-After the call was terminated, the siren alarmed again and turn off after entering the passcode at then panel (for the second time)

Is the explanation here that the panel actually did not recognize the first disarm code entry, but the siren was just paused by initiation of the 2-way call (and was not stopped as a result of the system being disarmed)?

6

Is the explanation here that the panel actually did not recognize the first disarm code entry, but the siren was just paused by initiation of the 2-way call (and was not stopped as a result of the system being disarmed)?

Correct, based on history, the system was successfully disarmed after the 2-Way call. If the passcode was entered at the panel prior to that, it was entered incorrectly.

operator acknowledged receiving an abort request via chat and confirmed it was a false alarm, and terminated the call without asking for password

I have heard back from the monitoring station regarding this. The operator should have asked for the password even though the disregard was received through Chat. Typically an operator will ask for the passcode via 2-Way or Premise call during a burglary alarm instance.

7

Thanks for the foellowup