Re: question about burglar alarm dispute (San Francisco Bay Area)

[G. Morgan <no_em@xxxxxxxxxx>]

Frank Olson wrote:

>G. Morgan wrote:
>> Frank Olson wrote:
>>
>>> Just Looking wrote:
>>>
>>>>> Wasn't it you that threw a strop when you claimed a CS
>>>>> stopped signals from one of your accounts?
>>>> Not exactly. They called up the panel, removed the central station phone
>>>> number and the account number and that stopped the monitoring altogether.
>>>> They didn't notify anyone and they continued to bill for the account. The
>>>> "strop" came when that account had a break in.
>>> All of our accounts "test" daily.  We have a procedure in place for when
>>> we receive "fail to test" reports from the CS.  Apparently you don't
>>> either have such a procedure or receive fail to test reports (or both).
>>>  I'd suggest looking for another CS that will provide you with better
>>> service (in the latter instance).  If you *are* receiving fail to test
>>> reports, then I'd suggest it's time to amend your service procedures.
>>> This will avoid future embarrassment on your part.
>>>
>>> Now...  We just performed a test of a fire alarm system which happened
>>> to be monitored by another alarm company.  They failed to receive *any*
>>> signals.  No troubles, alarms or supervisories.  When I spoke with the
>>> operator I asked if they were receiving a daily or monthly test signal.
>>>  He said "yes, we are receiving a daily test signal".  I asked him
>>> specifically if those test signals were generated by the system or if
>>> someone at the station was manually entering them (some CS software will
>>> allow you to do this).  He sounded quite "miffed" when he responded:
>>> "These are signals generated by the communicator".  I called him back
>>> about ten minutes later to suggest he dispatch a technician to the site.
>>>  Apparently the phone lines had been disconnected and the panel hadn't
>>> been able to communicate since the second week of September, 2007 (I got
>>> that information from a copy of the Telus work order which was left on
>>> the site).  I would love to have been there the day the customer phoned
>>> the monitoring company to complain about being billed for a service they
>>> clearly hadn't been providing for over half a year.
>>
>>
>> When you got there you should have known immediately the panel wasn't
>> communicating then.  Wasn't there a Line1 & Line2 trouble and a FTC trouble?
>> If so, why did you attempt to send signals?
>
>The "can" holding the equipment is "blank".  There's no keypad.  There
>are two jacks but one doesn't even have a connection to the telephone
>block.  We were there performing a test on the fire alarm system after
>an upgrade (they added two pull stations and a bell).  I know damn well
>the "communicator" isn't ULC listed for fire monitoring.  It can only be
>described as a "trunk slammer" install, but the company involved is one
>of the biggest ULC listed stations in town (turned out to be an old DSC
>1500 with no keypad attached).  I wasn't there to "test" the
>communicator, but since the panel is "stickered" as being monitored we
>had to call the station to inform them that we would be sending signals
>(as the fire alarm needed to be tested).  Oh...  and by the way, if we
>find a non compliant communicator on a system we're verifying, the
>system is red flagged regardless.  The fact that they were obviously NOT
>receiving signals was just the "icing" on the cake.

I echo Roland's concern... A  -->DSC 1500<-- used as a commercial fire panel?
That is wrong in so many ways, the least of which it not being UL listed for
that purpose.  Wouldn't a missing keypad cause the panel to be in perpetual
trouble?

--

-G