It doesn't matter, when the alarm comes in the have to dispatch, it is not the central stations job to research signals as they come in before responding, that is for the installing company to do
You have no clue what my firm does
Again you assume they will automatically look at the prefix and know it's Garwood, I'm sure you have memorized every single area code in the country and would know what location they originate from. They and every other central station including the one you use won't
No daily test signals show that a panel is communicating, when you receive an alarm signal you don't stop the dispatch, go through alarm history, note what phone number the last test signal came from before you dispatch, instead you dispatch then ask questions later
Then again maybe there are other reasons why you no longer own a central station
Gee thats what we have been saying all along, welcome aboard!
One line card eh?
That works, maybe, if you are monitoring a handful of alarm systems from your garage. But matching up account numbers and Caller ID info is a complete non-starter for a large central station. There are just too many things that can go wrong. It would be irresponsible not to dispatch because of a Caller ID - account number mismatch.
I'd also point out that in many cases, you would be talking about ANI rather than Caller ID, if the central station is using 800 numbers for its receivers. ANI data is not transmitted in the same way as Caller ID data, further complicating the matching process.
Consider the following scenarios which could affect ANI/Caller ID info after a system is installed:
You want to generate service calls when you have a data mismatch or no data on a timer test? Who pays for that?
You can think up more scenarios for yourself. The key question is this:
What does a central station do if it receives a signal with no ANI/Caller ID info, or a mismatch between the account number and the info that is on file?
Answer: treat it as an alarm, and dispatch on it. They may call the premises first, but they were going to do that anyway, even if the info had matched. They would be negligent if they ignored the signal due to an ANI mismatch, because so many other things besides a phantom transmitter could cause that.
At best, it's a maintenance issue, but the signal is going to be handled as an alarm anyway, ANI doesn't really do any good in terms of false alarm reduction.
Incidentally, there is one other possible explanation for this phantom signal that I don't believe anyone has mentioned. Many receiver line cards transmit multiple handshakes, and receive signals in several different formats, including old pulse formats. Old pulse format dialers used to transmit bogus signals on occasion, or perhaps I should say the receivers would misinterpret that string of beeps. So, even if account 246 is programmed as a Contact ID account, a different transmitter sending pulse format could send in a signal on that same account number by mistake. A close analysis of the signals received near the time of the one in question might shed some light on this, but it's too late now.
- badenov
Since you work for a similar central station it's not surprising you would defend the ineptitude of the CS in question. I never said they should research anything before dispatching. I said they should have been recording and comparing Caller ID from the start. I also said they should have been receiving daily test signals. If this had been done the OP's problem would not have arisen.
From what ex-clients of yours indicate, apparently you do as little as possible.
I assume no such thing. Clearly the OP's central station did nothing of the kind, else the OP would not have had a problem.
If the CS and the "professional" installer were any good at all they would have been notified by the CS automation software the moment the offending panel was connected. Needless to say, they failed. Was this one of your accounts? Is that why you're defensive about the "professionally" programmed panel?
Uh, no, Leuck. There are things called computers in a modern central station. Properly configured CS automation software would have seen the problem and alerted the CS operator long before this became a problem.
Won't what?
No, Leuck. That's not what I said and you know it. The correct procedure is for the CS to receive daily test signals from each account. When the account is created one of the data items entered is the phone number of the alarm control panel. Each time a test or other signal comes in the CS automation software compares the Caller ID to the phone number on file. Done right, this would have alerted the CS when the panel sent a test that something was awry.
As you already know, I sold it during my divorce. What you may not know is that I'm glad of both. Though the alarm company and the CS business brought in a nice, steady revenue stream, they also required my constant attendance. Vacations were rare and necessarily short. Running an online alarm dealership, I make a better living and have the freedom to travel extensively.
Yep. One card (2 lines in hunting) handled tests and O/C signals. Another card (2 lines in hunting) handled alarms. The 2nd alarm line "rolled over" to the test lines in case we ever had an overload. Such signals were extremely rare since we were never large.
Snicker all you like. I'm certain I made a better living running my own small business than you ever will working in the office of a large, national firm. I do better still online. This evening after putting in about 6 hours online, I drove to Clearwater to buy fishing tackle for a scheduled trip to the Amazon. What'd you do, ride your bicycle?
O wouldn't know. Do you work from your garage?
It's amazing how long you've been in the business and yet you have no idea how CS automation software functions.
We've already seen what goes wrong when alarm companies are too cheap to bother comparing Caller ID data. The fact is that the *only* reason most CS' dpn't bother is they don't want the added cost of more phone lines, line cards, etc. If the alarms only send emergency signals they generate far less CS traffic and more accounts can be assigned to a given line. Doing it right costs the central station a little more -- a few cents per account per month. It's a tiny fraction of the revenue that a large CS can generate but most are too greedy to part even with that small amount. The result is that problems like the OP's are fairly common.
It is even more irresponsible not to even check the Caller ID nor to run daily tests. Doing so ensures that more of these problems will arise. Doing it right would cost a few extra cents a month but that would have alerted the CS *before* the alarm came in. Keep explaining why it's so "responsible" of the CS to cheap out on service. It's amusing.
It makes no difference. The data is availabvle in real time and computers running standard CS automation software can easily solve the problem. The real issue is cost saving vs. customer service. Feel free to continue arguing against responsible service.
Upon receipt of the next test signal, CS contacts the alarm company to notify them of the change. The alarm company, in turn, contacts the client to let verify the reason for the loss of ICLID data. Client may decide to reinstate the feature. If he does not, the CS can edit the account so the CSA software looks for the "blocked data" signal. The client is made aware of the reduced level of security. If he keeps it that way he is explicitly accepting the situation.
That night the test signal comes in with the "wrong" Caller ID. A call to the client produces updated information which is entered into the account file. Fringe benefit: The customer notices how carefully the alarm company is watching out for his security. He won't soon switch providers. In places where people think about such things this is considered a win/win situation.
This affects nothing. Once the proper number is entered into the account there will be a match.
Yep. That happens. If the system gets unreadable data the CSA software will flag it. It's a snap to differentiate between garbled data and clean data from another phone number. I've written software to do this. I discussed it at length here some years ago. My app ran on the THEOS OS which Bradley used way back then. I wrote it because at the time BOLD didn't offer ICLID processing. TTBOMK, the feature is now standard.
Wrong. If the data on a test signal indicates a change, it should only generate a phone call or two. The customer is already paying too much for lousy service with most of these large, national CS' anyway. When you get a changed phone number you make a phone call. If that's going to break your bank you belong in a different business.
Your imagination is already prolific enough, thanks.
alarm companies begin to give responsible service?]
The answer is this: Not until police departments stop responding to calls, thereby rendering their services unsalable. From the discussion here it is apparent that too many alarm companies would rather come up with excuses than properly service their customers.
account number and the info that is on file?
That depends on whether the account is configured to expect ICLID data. If so and the signal is a test, make a phone call to determine why the number has changed. If it's an alarm signal, why wasn't the system already checked when the daily test came in with the same wrong data or without any data?
You're missing half of the story. You need ICLID data
*and* daily tests to be able to spot these problems before an alarm comes in. It's not enough just to monitor Caller ID. You need to do both.It will alert you to a moved panel. It will alert you to a premises that has been sold or rented without your knowledge. It will alert you to an improperly programmed panel elsewhere sending on a previously assigned line / account. All of these things can indeed help you to reduce false dispatches.
Not only that. Doing it right will earn you major points with your existing customers. It will also give you an almost immediate opportunity to introduce your company to a new purchaser of a home you've been protecting. That will give you the opportunity to sign on a new account rather than piss off the new homeowner when he sets it off (they invariably do) trying to figure out how to use it.
Think about that for a few minutes. Do you see what's wrong? :^)
If they were recording Caller ID they could have called the number, spoken to the person whose system sent the signal and resolved it in less time than it took you to type a 3-digit account number for a system using Contact ID.
You don't have enough facts on this to know if they were inept or not
See? You don't know but then I have no doubt you will quickly make something up
It is not up to them, they received a signal and they dispatched, it's what they are paid to do
No the CS dispatched when they received the signal, if the installation company was notified it would have been after the dispatch, so far the OP has said nothing about the installation company
I was thinking it was more one of your guys myself
No the properly configured CS automation software would tell the CS operator that an account received a signal from a given phone number, you fail to understand that their job is to then dispatch first and if there is a problem research later
Just a comment guys......please don't forget that Mr. BAss's "properly configured CS automation software" was a Rolodex with pretty colored separators for Fire and Burg.
Norm Mugford
I choose Polesoft Lockspam to fight spam, and you?
I am still trying to find it on eBay. I've been looking for years. No luck yet.
Let's see. They don't bother monitoring Caller ID and they don't do daily tests. That's enough. They're inept. Oh, while we're on the subject, does Monitronics do daily tests on all residential systems and open/close on all commercial ones?
That depends on the central station. You work for Monitronics and apparently spend your days programming alarms for them. Do you configure all those systems for daily test? If not, what is your excuse?
A *responsible* central station would care enough to make sure all accounts are properly programmed. One very effective way to minimize the chances of a situation like this arising is to offer daily test and Caller ID monitoring as part of one's basic services. Not doing this as a matter of routine practice is indicative of a rather cavalier attitude about the security of one's clients. This of course brings us back to the previous question. Does your employer offer daily test and Caller ID (or ANA) monitoring at no additional charge to encourage installing dealers to make use of the features? If not, what is your excuse?
If they had done the job properly in the first place the situation would have been far less likely to have come about. It's a matter of actually protecting your clients, as opposed to covering your own arse. Your comment about liability indicates you're far more concerned about the latter than the former.
You're confusing me with Olson.
tests. That's enough. They're inept.
Hardly, daily tests do nothing but show the account sent in a test signal once a day, it would do nothing in this instance, the original poster mentioned they did not show the Caller ID on his signal, there is no mention they did not handle Caller ID in general
BTW I don't recall the OP saying his system wasn't set for daily tests
Oh, while we're
and open/close on all commercial ones?
If the dealer sets it up as such yes, how about your garage central station? Did you have Caller ID?
I do not spend my days programming alarms for them, I have never spent my days programming alarm systems. Again you do not know what I do for them
No, a responsible central station monitors installations by alarm companies, it is up to them to make sure the accounts are properly programmed
No, daily tests and Caller ID do nothing to show a panel is properly programmed
I have no idea what they charge dealers for monitoring, I'm pretty sure they do but why don't you call and ask?
You conveniently miss the issue here which was what the responsibility of the central station is and that responsibility is to dispatch when they received the signal, you seem to alternate between time-consuming research without dispatching and in a recent message dispatching like the rest of us have been saying, so which is it?
I'll put my money on his continuing to "alternate". I figure the chemo's got him so wacked out he really doesn't remember what he said the day before yesterday. And we both know he doesn't "read well".
Do you even read some of what YOU say sometimes? Do you not think what you just said here is pretty sick and pathetic stuff?
I'll try to explain this in terms you can understand. If *all* systems were set for daily test and if the CS bothered to compare Caller ID data from incoming signals with the telephone number on file for the panel, the first time the errant system was powered up it would have sent a signal with the OP's account number and the errant system's Caller ID. This should have resulted in calls to (1) the location that is supposed to have that account number and; (2) the telephone number from which the errant signal originated.
The CS (if they cared enough to verify these things) would have notified the OP's installer AND the location that was incorrectly programmed. This would have happened the moment the first daily test came in -- not when the false alarm came in.
So the answer is no. OK, that removes all doubt as to their ineptitude. Thanks for the clarification.
I never had a CS in my garage. That was where I kept inventory for installations. As I already said, we did Caller ID monitoring plus daily tests on all residential installations. All commercial accounts were programmed for open & close reporting. These were part of our basic service.
Bullshit!
So that's your excuse? Everything is the fault of the alarm companies. Not offering needed services as a standard feature saves your employer a few dollars a month so it's OK if things like the OP's disaster go on unchecked.
The fact that you don't understand it doesn't make it not so.
Bullshit! With all the programming you've previously claimed to do, you certainly know that Monitronics doesn't offer daily test as part of their basic service.
Yup!
AFAIK there isn't a single CS that accepts signals on an 800 line that "offers" daily tests without charging extra for the service. This includes the CS you illegally sold contracts for at one time. ISTR they even charged $50.00 per signal for those accounts that had canceled service but were still transmitting...
And after not receiving a response with call (1) as the OP said, they will dispatch and the call (2) will come after they dispatch assuming someone at the other number even answers.
Either way they did what they were supposed to do Caller ID or not
Which was not mentioned in the OP's initial post so neither of us know what happened there
It does not matter, they received a signal on the OP's account number and they dispatched, daily test signal or not
You assume too much as usual, some dealers do and some don't
And again you do not know what I do nor did you know what I did for them in the past but feel free to do the usual and make stuff up
In this case yes it is the fault of either an errant DIY'er fumbling through your instructions or another alarm company, apparently you aren't familiar with how contract monitoring works
If memory serves me correctly, the "central station" was in his bedroom, not his garage. Otherwise, he might have slept through an incoming signal.
A-HAH!
Now we know why he got a divorce!
He spent his nights checking caller ID's.!!!!!!!!
Hmm. I'm trying to decide if you are actually so stupid that you don't understand or if you are simply pretending not to know what I said.
Once again. Properly handled, the CS and/or the alarm company would have found and remedied the problem long before there was an alarm signal.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.