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

["Just Looking" <nospam@xxxxxxxxxx>]

A DSC 1500 used for monitoring a fire panel? That is simply criminal. Find
the tech that did it and get a rope, assemble the firing squad or bring on
the guillotine.

"Frank Olson" <use_the_email_links@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:HOCEj.100186$pM4.31969@xxxxxxxxxxxx
> 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.