Dispatching on undefined signals
bad...@freedom.net
own systems, an interesting question came up:
What do you want your central station to do when it receives an unknown
alarm signal, say, "Alarm zone 23" on a system that only has 16 zones
defined in the central station database?
Personally, I say handle it as a burglar alarm signal (assuming it's not in
an expanded format that identifies it as a fire alarm). Better to rack up a
false alarm than to ignore a real one.
I quote part of my post and part of Alarminex's comments:
>In fact, if you think about it, a central station that insists on
>programming the panel for him actually has greater liability exposure
>because they undertook to perform a service. If he programs his own panel,
>all the central station would be doing is agreeing to dispatch on a signal,
>if by some chance it happens to receive one.
It's of no concern if the central doesn't receive a signal, it's if the
central
does receive a signal and it an improproper signal or doubtful signal, or
partial signal. For instance, unless I specify otherwise, one of my central
station will not dispatch or take action on an unidentifed code.
Robert L Bass
:
: What do you want your central station to do when it receives
: an unknown alarm signal, say, "Alarm zone 23" on a system
: that only has 16 zones defined in the central station database?
My usual instruction is for the central station to contact the premises first
and then the installer (in the case of a DIY, of course, the two are the same).
There are good and valid reasons for this approach, but the other suggested
response is just as valid. It's a judgment call you have to make.
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
:
Group Moderator
false alarm than to ignore a real one.
Known in a central station as "When in Doubt - Ship it Out"
Mike, Sr.
Alarm Services Inc.(NJ)
Group Moderator
http://www.AlarmServicesInc.Com
" The Only On-Line Alarm Store You Will Ever Need "
See the **NEW** Goofy WebSite (Bass Blown Electronics)
http://www.GoofysPlace.Com
Paul Rampelbergh
wrote:
>Better to rack up a false alarm than to ignore a real one.
>
>Known in a central station as "When in Doubt - Ship it Out"
>
>Mike, Sr. Alarm Clown Inc.
>" The Only On-Line Alarm Store You Will NEver Need "
You are right Mike.
With wireless alarm systems for instance you will have a lot of false
alarms when interference occur (if it is like you say detected).
Just upset everybody in the vicinity and keep police awake..
I like your theory Sr.
Paul
Thomas Gerchak
Robert L Bass <Rober...@home.com> wrote in message
news:_TPy7.109609$kK3.3...@news1.rdc1.fl.home.com...
> badenov wrote:
> :
> : What do you want your central station to do when it receives
> : an unknown alarm signal, say, "Alarm zone 23" on a system
> : that only has 16 zones defined in the central station database?
>
> My usual instruction is for the central station to contact the premises
first
> and then the installer (in the case of a DIY, of course, the two are the
same).
> There are good and valid reasons for this approach, but the other
suggested
> response is just as valid. It's a judgment call you have to make.
Hello, Robert. I do not mean to say that your particular approach is
"wrong", but I will say it does have a dangerous caution to it, or maybe
lack of caution. Hear me out, please.
I can see calling the prem. first. I really can. But calling the
installer? If the installer programmed the panel correctly, there should be
no undefined zones unless the CO made a data entry mistake. Now even if the
installer, half asleep at perhaps 3 AM, can photographically recall the
corresponding signal associated with the alarm, can you waste the time, risk
the total recall memory, and most importantly, bet the sub's life and
property on this installer's snap decision?
I am not picking on your post, but do wish to allow others to see another
point. What if the undefined zone was a silent panic button? Calling the
prem may not be such a great idea. In a fire, I would probably not answer
my phone if I were rushing toward my child's bedroom.. I, "Joe Customer",
have, and should have, much confidence that if my signal hit the CO, you
will act expeditiously. I would not think that in an emergency, I would
have to wait for a quick phone call from your CO for me answer and then
verify that I had a situation in progress.
I would be appalled if the CO took the time to find out the installer of my
system, try to contact the installer, get the installer's opinion on what
he 'might' have programmed wrong, or worse, what the installer's
'speculation' was on what the CO entered incorrectly. I, "Joe Customer",
would have a very bad feeling about this practice.
I, "Joe Customer", would expect my alarm monitoring company to act on the
side of safety on my behalf. The CO should convey to the Police that they
have received an undefined signal from the prem and just that. I would be
very disheartened to find out any delay was made.
I would expect the alarm company to pick up the bill, should it be a false
alarm. I would expect them to apologize and correct the mistake. The
above, should an error on the alarmco's part be found.
As an knowledgeable person from the industry, I do not outright call your
position wrong.
I will say that most airplane crashes are a result of a series of failures,
and not just one. Example: 1) Running low on fuel = Can still make the
destination. 2) Bad weather ahead = Can still fly around it. 3) Fuel too
low = Can make alternate airport on the other side of the mountain without
too much of a course diversion inconvenience. 4) Reality = Crash into
mountainside because low on fuel. The low fuel was not the actual cause of
the crash. The domino effect tends to catch up with bad decisions made in
succession.
So what if the undefined signal was a low battery? "The police woke my
whole family up!" I believe that in over 9 out of 10 times, the customer,
when properly briefed, will understand the situation, whether it be a false
alarm, or a false dispatch. Given the above scenarios, it is my belief that
the customer, later upon pondering the CO's situation, will have just that
one more ounce of respect for the decision to dispatch... A decision made
under extenuating circumstances can be forgiven 100 times more than lack of
action when it is truly needed.
I think every precaution should be made to prevent 'false' alarms; I see a
bad precedence being set when we 'speculate' real-time on 'when to', or 'not
to' dispatch.
Respectfully,
thomas
Robert L Bass
:
: Robert L Bass <Rober...@home.com> wrote in message
: news:_TPy7.109609$kK3.3...@news1.rdc1.fl.home.com...
: > badenov wrote:
: > :
: > : What do you want your central station to do when it receives
: > : an unknown alarm signal, say, "Alarm zone 23" on a system
: > : that only has 16 zones defined in the central station database?
: >
: > My usual instruction is for the central station to contact the premises
: first
: > and then the installer (in the case of a DIY, of course, the two are the
: same).
: > There are good and valid reasons for this approach, but the other
: suggested
: > response is just as valid. It's a judgment call you have to make.
:
: Hello, Robert. I do not mean to say that your particular approach is
: "wrong", but I will say it does have a dangerous caution to it, or maybe
: lack of caution. Hear me out, please.
:
: I can see calling the prem. first. I really can. But calling the
: installer? If the installer programmed the panel correctly,
: there should be no undefined zones unless the CO made a
: data entry mistake.
Perhaps we're not thinking of the same scenario. If the report was from zone 23
of a 16-zone system, I figure that there must be a misdirected signal here.
Bear in mind that I have used SIA and Contact ID exclusively since shortly after
the formats became available. I don't know about *every* system, but the ones
with which I am familiar can not generate a zone ID beyond their physical
boundaries. You may know of a system which can do so and, if that is the case,
we are in agreement.
: Now even if the installer, half asleep at perhaps 3 AM, can
: photographically recall the corresponding signal associated
: with the alarm, can you waste the time, risk the total recall
: memory, and most importantly, bet the sub's life and property
: on this installer's snap decision?
That's the point where I think we're on different tracks, Thomas. If the system
has a 16-zone limit and I get a report from zone 23 I am pretty sure the signal
is not from that premises. Something must be wrong -- say for example another
system has been mistakenly assigned to the same account number as my 16-zone
system. If that is the case, I don't want to send the PD to the 16-zone
location.
BTW, because of the possibility of exactly this happening, in our small central
station we recorded Caller ID data for every signal. If a signal seemed bogus
or bad data was being transmitted, the operator could look at the Caller ID
screen (on another terminal which ran my custom app 24/7) and see where the
signals were originating. Every once in a while that program saved us some
trouble.
: I am not picking on your post...
No problem, Thomas, I'm taking your comments at face value. I think I have a
good way but I'm willing to listen to your ideas, too.
: but do wish to allow others to see another
: point. What if the undefined zone was a silent panic button? Calling the
: prem may not be such a great idea. In a fire, I would probably not answer
: my phone if I were rushing toward my child's bedroom.. I, "Joe Customer",
: have, and should have, much confidence that if my signal hit the CO, you
: will act expeditiously. I would not think that in an emergency, I would
: have to wait for a quick phone call from your CO for me answer and then
: verify that I had a situation in progress.
Hmm. Multiple possibilities above. Here's where we agree. If the code is a
silent panic (regardless of zone), the PD are dispatched at once -- no call to
the premises. Fire alarm? Call the prem. If no answer by the third ring,
dispatch the FD. So far, no dispute.
: I would be appalled if the CO took the time to find out the installer
: of my system, try to contact the installer, get the installer's opinion
: on what he 'might' have programmed wrong, or worse, what the
: installer's 'speculation' was on what the CO entered incorrectly.
: I, "Joe Customer", would have a very bad feeling about this practice.
I think our difference at this point is small. If we are unsure whether the
signal is valid, you are right. We should commence the dispatch sequence
(calling order depends on condition reported and/or specific instructions for
that account) at once and worry about a programming glitch later. But, if I am
certain the signal is bogus because the particular system can't possibly report
what I have received, I think calls to the premises and the installer are a good
idea.
Just to be sure we understand each other though, if I had any doubts, I'd do it
your way.
: I, "Joe Customer", would expect my alarm monitoring company to
: act on the side of safety on my behalf.
Yep.
: The CO should convey to the Police that they have received an undefined
: signal from the prem and just that. I would be very disheartened to find
: out any delay was made.
That would probably suffice to CYOA, but it might not cause a police response.
Several of the police departments we dealt with would decline to respond to
anything but a specific emergency condition. The was even one department
(Glastonbury, if I recall correctly) that refused to respond to "panic" signals.
They would dispatch on a hold-up alarm, but for reasons never stated they had a
policy against accepting residential panics. I suspect it was due to the high
incidence of false panics, but no one would confirm that.
: I would expect the alarm company to pick up the bill, should it
: be a false alarm.
Most alarm companies I know of have specific wording in their contracts to the
effect that the customer pays any fines, charges or fees. I think Irv Fisher's
huge CMS uo in Canada pays the fines and perhaps other Canadian companies may be
doing the same. But all the US firms I know of refuse. Are you aware of
companies in your area that will pick up the tab if there's a fine?
: I would expect them to apologize and correct the mistake.
Yes, indeed.
: The above, should an error on the alarmco's part be found.
:
: As an knowledgeable person from the industry, I do not
: outright call your position wrong.
Professional courtesy appreciated. :*)
: I will say that most airplane crashes are a result of a series of failures,
: and not just one. Example: 1) Running low on fuel = Can still make the
: destination. 2) Bad weather ahead = Can still fly around it. 3) Fuel too
: low = Can make alternate airport on the other side of the mountain without
: too much of a course diversion inconvenience. 4) Reality = Crash into
: mountainside because low on fuel. The low fuel was not the actual cause of
: the crash. The domino effect tends to catch up with bad decisions made in
: succession.
That is 100% correct. Even in my own limited flying experience, the one time
when I really screwed up (a class charlie incursion) was not due to any one
major error. It was the combination of several small deviations from my
routine. First, I chose an alternate practicse area for some solo work -- this
was one of the areas students were advised to practise as it was fairly
unpopulated but there were several decent places to land in an emergency. Next,
after making dozens of steep turns, I neglected to reset my DG when I decided to
head back to my airport. Again, this wasn't a biggie. I knew the terrain and
could easily fly home by sight alone. I was only about 30 miles out at the
time. Flying the brand new C172, I decided to try out the GPS unit. Instead of
relying on my knowledge of the terrain, I opted to "fly the GPS" home. I dialed
up HFD and got a course. Then I proceeded to fly that course using the DG.
Oops!!! The DG was about 15-20º off because I had been doing steep turns. A
few minutes later I was looking at BDL, a busy class C field. Fortunate;y, I
wasn't anywhere near the active and I only got a verbal scolding from Approach.
OK, long tale to make short point. A series of small errors sure can lead to a
big problem.
: So what if the undefined signal was a low battery?
If we are talking about using a less specific format, such as 4/2, I can see
that. With CID or SIA the condition will be known so it shouldn't be a problem.
: --- snip stuff we agree on ---
Alarminex
>Subject: Dispatching on undefined signals
>From: bad...@freedom.net
>Date: Mon, 15 Oct 2001 19:56:48 -0700
In reality, centrals have no obligation to respond to signals not initially set
up in any monitored account. It seems more like the question here is ......
should they?
And why.
When an installation is complete ...... if you're not lazy or incompetent,
you'll test transmit every signal that the system is capable of sending. Yep,
every signal. Check it with a read-back from an operator at the central and
then get a fax verification. If you are confident that the system has been
programed correctly and feed back verifies it, then you may feel justified in
allowing your central to only respond to listed signals, if that is their
policy. If not, CYA and just leave instructions to respond to every signal.
>
>
Jim
Remove the Qzapp to email
Mark Leuck
> : Now even if the installer, half asleep at perhaps 3 AM, can
> : photographically recall the corresponding signal associated
> : with the alarm, can you waste the time, risk the total recall
> : memory, and most importantly, bet the sub's life and property
> : on this installer's snap decision?
>
> That's the point where I think we're on different tracks, Thomas. If the
system
> has a 16-zone limit and I get a report from zone 23 I am pretty sure the
signal
> is not from that premises. Something must be wrong -- say for example
another
> system has been mistakenly assigned to the same account number as my
16-zone
> system. If that is the case, I don't want to send the PD to the 16-zone
> location.
Yes but depending on how a central station is setup do you want to spend
perhaps 10 to 20 minutes tracing a call? I of dispatching in case a panel
was reprogrammed via service call back to 4/2 (it happens)
Or if a DIY'er screws up his programming (joke)
> BTW, because of the possibility of exactly this happening, in our small
central
> station we recorded Caller ID data for every signal. If a signal seemed
bogus
> or bad data was being transmitted, the operator could look at the Caller
ID
> screen (on another terminal which ran my custom app 24/7) and see where
the
> signals were originating. Every once in a while that program saved us
some
> trouble.
Not all central stations have immediate Caller ID, it does indeed come in
very handy when one has it
> : I would be appalled if the CO took the time to find out the installer
> : of my system, try to contact the installer, get the installer's opinion
> : on what he 'might' have programmed wrong, or worse, what the
> : installer's 'speculation' was on what the CO entered incorrectly.
> : I, "Joe Customer", would have a very bad feeling about this practice.
>
> I think our difference at this point is small. If we are unsure whether
the
> signal is valid, you are right. We should commence the dispatch sequence
> (calling order depends on condition reported and/or specific instructions
for
> that account) at once and worry about a programming glitch later. But, if
I am
> certain the signal is bogus because the particular system can't possibly
report
> what I have received, I think calls to the premises and the installer are
a good
> idea.
Even if you could get the installer online he's not going to remember what
he programmed in a location in the event of a mistake in programming
(otherwise it wouldn't be a mistake). The only purpose of calling however
would be to possibly set up a service call if that signal indeed came from
the panel
> : So what if the undefined signal was a low battery?
>
> If we are talking about using a less specific format, such as 4/2, I can
see
> that. With CID or SIA the condition will be known so it shouldn't be a
problem.
Not always, unfortunatly panels like Napco and Caddx will not auto-send SIA
or Contact ID by zone type, so if a tech misprogrammed the report code for
Zone 23 it it could come in undefined
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
news:20011017120359...@nso-fi.aol.com...
> In reality, centrals have no obligation to respond to signals not
initially set
> up in any monitored account. It seems more like the question here is
......
> should they?
> And why.
>
> When an installation is complete ...... if you're not lazy or incompetent,
> you'll test transmit every signal that the system is capable of sending.
Yep,
> every signal. Check it with a read-back from an operator at the central
and
> then get a fax verification. If you are confident that the system has been
> programed correctly and feed back verifies it, then you may feel justified
in
> allowing your central to only respond to listed signals, if that is their
> policy. If not, CYA and just leave instructions to respond to every
signal.
Mistakes are always possible even with the way you test signals (which BTW
is excellent)
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Wed, 17 Oct 2001 17:51:57 -0500
Gosh ...... golly! reeeeelyy!
I can honestly say ( in spite of the fact that I'm accused of being a liar
..... by a liar) that I've not received a ligitimate undefined code ( a
mistake in progarming ) in over 10 years. I guess there could be some out
there, but if there are, they haven't shown up yet.
Group Moderator
No problem, Thomas, I'm taking your comments at face value. I think I have a
good way but I'm willing to listen to your ideas, too
Mike Said:
I told you guys that this would happen. I tilt my hat to Mr Bass, (always with
caution),.
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> >Mistakes are always possible even with the way you test signals (which
BTW
> >is excellent)
> >
> >
>
> Gosh ...... golly! reeeeelyy!
>
> I can honestly say ( in spite of the fact that I'm accused of being a liar
> ..... by a liar) that I've not received a ligitimate undefined code ( a
> mistake in progarming ) in over 10 years. I guess there could be some out
> there, but if there are, they haven't shown up yet.
Not to beat a dead horse but did you ever try CID or SIA yet?
bad...@freedom.net
"Alarminex" <alar...@aol.comQzapp> wrote in message
>
> I can honestly say ( in spite of the fact that I'm accused of being a liar
> ..... by a liar) that I've not received a ligitimate undefined code ( a
> mistake in progarming ) in over 10 years. I guess there could be some out
> there, but if there are, they haven't shown up yet.
Well, if your systems don't cause false alarms, you'll probably never know
that you have a zone that is undefined in the central station
computer--until someone gets robbed.
Seriously, though, I've been in the business for a long time, and I test
systems every bit as thoroughly as you do. But unlike you, I have seen
mistakes happen, and I've made some myself. Here are two scenarios:
1. Data entry error by the central station. You think the zone is in the
computer, but it isn't. If you're super-thorough, you check the central
station records every time they change something to be sure they've done it
exactly the way you said. I'm not that super-thorough; I trust them to do
their jobs correctly and I don't double-check their every keystroke for
typos.
2. Additional protection. I will admit to making this mistake myself.
When you add a zone to an existing system, or take a zone that's currently a
BA zone and use it for something like temperature monitoring, you may (and
should) test it to the central station, and they will tell you they've
received an alarm on zone 12 or whatever. But maybe you figure you'll talk
to the data entry people at the end of the day, instead of right that
minute, so you can do all your data entry stuff on one phone call, And then
you forget. I've done it. Not very often, but I admit I've done it.
Mistakes do happen. I make them, and so do central stations. We're human.
That's why we have good contracts and good insurance, and that's why we need
good central station procedures to back us up when we screw up.
Mark Leuck
<bad...@freedom.net> wrote in message
news:tssrp25...@corp.supernews.com...
>
> 2. Additional protection. I will admit to making this mistake myself.
> When you add a zone to an existing system, or take a zone that's currently
a
> BA zone and use it for something like temperature monitoring, you may (and
> should) test it to the central station, and they will tell you they've
> received an alarm on zone 12 or whatever. But maybe you figure you'll
talk
> to the data entry people at the end of the day, instead of right that
> minute, so you can do all your data entry stuff on one phone call, And
then
> you forget. I've done it. Not very often, but I admit I've done it.
Same here, thats the nice thing about SIA or CID, even if the station
doesn't know what is on that zone they will get the correct signal and alarm
type (assuming the tech programmed that correctly)
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Thu, 18 Oct 2001 01:23:40 -0500
That's exactly right. If it's not programed right and thouroughly checked to
begin with, what's the difference which format you use?
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Thu, 18 Oct 2001 00:53:11 -0500
Nope!
Still looking for that opportunity. That is, ...... the job where I can take
the time, without the customer looming about, where I can send signals and see
what central is receiveing. I still have a problem with not being able to
verifiy that the signals are being sent for each zone. I still have a problem
with sending a code everytime the panel hiccoughs. And sending restores, in my
opinion is a waste. From what I understand, I don't have a choice what is sent.
I don't know if I like that.
As I say, at some point I'll find time to experiment to see what the
limitations/disadvantages are. I think the main advantages are to help the
inept installers and the centrals like it for their own advantages. I can't see
that it will help me with the way I want to send signals. With out further
information, the so called advantages are miniscule. I can only see that it
will deprive me of control of what gets sent and my ability to check on it.
Alarminex
>Subject: Re: Dispatching on undefined signals
>From: bad...@freedom.net
>Date: Wed, 17 Oct 2001 22:56:34 -0700
>
>
>"Alarminex" <alar...@aol.comQzapp> wrote in message
>news:20011018002938...@nso-mq.aol.com...
>
>>
>> I can honestly say ( in spite of the fact that I'm accused of being a liar
>> ..... by a liar) that I've not received a ligitimate undefined code ( a
>> mistake in progarming ) in over 10 years. I guess there could be some out
>> there, but if there are, they haven't shown up yet.
>
>
>Well, if your systems don't cause false alarms, you'll probably never know
>that you have a zone that is undefined in the central station
>computer--until someone gets robbed.
>
>Seriously, though, I've been in the business for a long time, and I test
>systems every bit as thoroughly as you do. But unlike you, I have seen
>mistakes happen, and I've made some myself. Here are two scenarios:
>
>1. Data entry error by the central station. You think the zone is in the
>computer, but it isn't. If you're super-thorough, you check the central
>station records every time they change something to be sure they've done it
>exactly the way you said. I'm not that super-thorough; I trust them to do
>their jobs correctly and I don't double-check their every keystroke for
>typos.
Here's my process.
Program the panel. Send all signals to central station. Keep track of the order
that the signals were sent to central. Call central. get a verbal read-back
and make sure the signals were received in the same order as sent.
When back at the office. Cental has faxed the report of the signals that were
sent during test. The field progaming form is faxed to the central station with
the customer information and all the info is entered into my computer program.
The information is entered into the Centrals data base and the print out is
returned to my office. This is proof read and compared with the information at
my office.
Could someone make a mistake? Yeah, sure. Hasn't happend in lots and lots of
years. Could there be some out there that haven't shown up yet? Yep, but, they
haven't shown up yet.
>
>2. Additional protection. I will admit to making this mistake myself.
>When you add a zone to an existing system, or take a zone that's currently a
>BA zone and use it for something like temperature monitoring, you may (and
>should) test it to the central station, and they will tell you they've
>received an alarm on zone 12 or whatever. But maybe you figure you'll talk
>to the data entry people at the end of the day, instead of right that
>minute, so you can do all your data entry stuff on one phone call, And then
>you forget. I've done it. Not very often, but I admit I've done it.
Every signal change is transmitted to central from the job site. If it's a
simple change, verbal instructions for the change is given to the central
operator at that time. The rest of the procedure, as above, is then followed.
>
>Mistakes do happen. I make them, and so do central stations. We're human.
>That's why we have good contracts and good insurance, and that's why we need
>good central station procedures to back us up when we screw up.
>
>
I'm confident enough in what I do to let undefined signals be sent to my office
only. Keep in mind, by the way, only I do the programing. If I had other people
doing it, my confidence would be much less and you could be sure that undefined
sig's would be dispached.
bad...@freedom.net
"Alarminex" <alar...@aol.comQzapp> wrote in message
> >
> >Not to beat a dead horse but did you ever try CID or SIA yet?
> >
>
> Nope!
>
> Still looking for that opportunity. That is, ...... the job where I can
take
> the time, without the customer looming about, where I can send signals and
see
> what central is receiveing. I still have a problem with not being able to
> verifiy that the signals are being sent for each zone. I still have a
problem
> with sending a code everytime the panel hiccoughs. And sending restores,
in my
> opinion is a waste. From what I understand, I don't have a choice what is
sent.
> I don't know if I like that.
> As I say, at some point I'll find time to experiment to see what the
> limitations/disadvantages are. I think the main advantages are to help the
> inept installers and the centrals like it for their own advantages. I
can't see
> that it will help me with the way I want to send signals. With out
further
> information, the so called advantages are miniscule. I can only see that
it
> will deprive me of control of what gets sent and my ability to check on
it.
I don't know what panels you use, but if you're doing Contact ID on Ademco
panels, the programming is mind-numbingly simple. You just tell the panel
to report in that format, and the panel takes care of the details. If you
don't want certain things reporting, like restores, you simply disable them.
Personally, I'm not paying my central station by the signal, so I really
don't care whether they get zone restore signals. Most of the time it may
not make any difference, but occasionally it's good information to have, for
example if you have zone trouble signals. Knowing the problem restored can
save you a service call.
Same thing with the additional reporting capabilities for things like "exit
error" and other "optional" codes. It's no skin off my nose if panels
report the extra signals, and besides, it means I can look at an activity
report from the central station and see in detail exactly what happened.
Sure, I could call up the panel and download the log, or view it at the
keypad on site, but why should I, when I can see it all in the central
station activity?
Also, depending on the automation system, many of the special Contact ID
codes are hard-coded into the software, meaning the central station doesn't
have to enter those codes when setting up an account. Less possibility for
data entry errors.
And in terms of checking signals, there's really no difference when using
Contact ID. If anything, the reports are clearer. And since you don't have
to specify all the report codes, there's much less chance of a programming
error. That's doubly true for things like integrated wireless systems,
where reporting trouble by zone is damn useful, but a nuisance to program by
hand in a non-CID format.
I don't know what you mean by "not being able to verify a signal is sent for
each zone." The whole point of Contact ID is that it does send a unique
signal for each zone.
In short, using "smart" formats makes your job easier not harder.
Robert L Bass
Contact ID is also pretty easy (though not infallible). You go to the zone
reporting page, highlight the zone in a list and hit +/- until you see the plain
English description (Burg, Fire, Panic, Aux, etc.) of the code you want to send.
I can set up Contact ID for a 96-zone system in about three minutes (I'm kind of
slow... Mark Leuck can probably do it in under 1 minute:)).
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
badenov wrote:
:
: I don't know what panels you use, but if you're doing Contact ID
:
:
Mark Leuck
"Robert L Bass" <Rober...@home.com> wrote in message
news:1aJz7.6311$06.3...@news1.rdc1.fl.home.com...
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> >Same here, thats the nice thing about SIA or CID, even if the station
> >doesn't know what is on that zone they will get the correct signal and
alarm
> >type (assuming the tech programmed that correctly)
> >
>
> That's exactly right. If it's not programed right and thouroughly checked
to
> begin with, what's the difference which format you use?
Much less of a chance in the case of the Napco Gemini series, all of the
troubles, restores, O/C's, panics auto send CID or SIA, and you havemaybe 8
or 10 choices for zone reporting (maybe 4 you'll ever need)
Compare that to maybe 50+ reporting codes (if its a big system) if using 4/2
Robert L Bass
Napco any more. Maybe it's because I've specialized in them for so many years.
Or perhaps I'm a savant. :*)
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
"Mark Leuck" <mle...@iadfw.net> wrote in message
news:B18E7D8E40028237.FA0B5263...@lp.airnews.net...
: Mark Leuck still has to check the book :)
: > :
: >
: >
:
:
Robert L Bass
anywhere near that many. But there are more ways to make a mistake using 4/2
and there's a higher probability of doing so using 4/2.
The other side of it is that CID and SIA give much more specific information
than 4/2 when you're doing a larger system. I realize that seems contradictory,
but that's because the advanced formats handle zone ID automatically. With 4/2
you have to enter each zone ID individually. If the system exceeds 16 zones,
4/2 is often inadequate.
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
"Mark Leuck" <mle...@iadfw.net> wrote in message
news:ADACA51DDD5BA873.F6EB4337...@lp.airnews.net...
:
: "Alarminex" <alar...@aol.comQzapp> wrote in message
:
:
Alarminex
>Subject: Re: Dispatching on undefined signals
>From: bad...@freedom.net
>Date: Thu, 18 Oct 2001 15:44:30 -0700
>
>
>
>I don't know what panels you use, but if you're doing Contact ID on Ademco
>panels, the programming is mind-numbingly simple. You just tell the panel
>to report in that format, and the panel takes care of the details. If you
>don't want certain things reporting, like restores, you simply disable them.
I don't use Ademco. The reasons are another thread.
>
>Personally, I'm not paying my central station by the signal, so I really
>don't care whether they get zone restore signals. Most of the time it may
>not make any difference, but occasionally it's good information to have, for
>example if you have zone trouble signals. Knowing the problem restored can
>save you a service call.
I don't think restore signals are important and I don't want to send them. It
clutters up my ability to be able to test the systems appropriately. If I want
to send a restore on any particular signal, I can program it to do that.
>
>Same thing with the additional reporting capabilities for things like "exit
>error" and other "optional" codes. It's no skin off my nose if panels
>report the extra signals, and besides, it means I can look at an activity
>report from the central station and see in detail exactly what happened.
I don't send exit error or other optional codes.
>Sure, I could call up the panel and download the log, or view it at the
>keypad on site, but why should I, when I can see it all in the central
>station activity?
If a problem occurs, the owner will be advised by the keypad as to what the
problem is. If, between the signals received by central and what the customer
remembers, we cannot determine what has taken place, I'll walk the customer
through the keypad logs, where they can view the log events for openings and
closings, alarms, system troubles and fire alarms. Takes two minutes on the
phone .... and thats if it's necessary at all. Other wise a log download will
be done.
To constantly barrage the central station with superfluous restore codes, on
the off chance that someday or maybe never, I may need to look at an activity
report to save five minutes, somehow doesn't make sense to me.
>
>Also, depending on the automation system, many of the special Contact ID
>codes are hard-coded into the software, meaning the central station doesn't
>have to enter those codes when setting up an account. Less possibility for
>data entry errors.
That's true, but, again, I check, double check and triple check what's been
entered. Could it still happen? Yeah, sure, but it hasn't.
>
>And in terms of checking signals, there's really no difference when using
>Contact ID. If anything, the reports are clearer. And since you don't have
>to specify all the report codes, there's much less chance of a programming
>error.
As I say, I haven't made a ( detected) error in over 10 years.
> That's doubly true for things like integrated wireless systems,
>where reporting trouble by zone is damn useful, but a nuisance to program by
>hand in a non-CID format.
Why would a wireless system be reporting trouble signals for each zone?
>
>I don't know what you mean by "not being able to verify a signal is sent for
>each zone." The whole point of Contact ID is that it does send a unique
>signal for each zone.
I'm sure it does, but when central station reports to me, that an alarm has
been activated and they received a 4/1 I know it's a zone 11. I have no idea
what they would report for a CID programed system. But since I've used 4/2
format for about 20 years, I don't have to think twice about how to program a
system or which zones have been tripped. It's easier to work with what I know,
inside out and backwards then it is to take the time to learn what CID will do.
I still think it was designed to take up the slack of incompetent installers
who couldn't program a six zone panel without making a mistake and it also
promotes not testing an entire panel. This thereby makes the centrals happy
because, even though there may be an incompetent installer, they know that all
the signals will be correct, reducing the possibility of a lawsuit.
>
>In short, using "smart" formats makes your job easier not harder.
>
>
As you can see, in my opinion, it's a dumb format and doesn't make me
comfortable in the process that I test my systems. Which, in brief, consists of
hanging my butt set on the phone lines and actually activating and listening to
each and every signal the panel is capable of sending. I get a verbal read back
from the operator. I obtain this copy of sent codes from the central and keep
it in the clients folder. Proof positive all the signals were sent.
I once installed a commercial fire panel that the central encouraged me to use
CID reporting. Attempting to use my procedure, I had to stop sending signals at
about 128, when I realized that I was hardly half way through the entire list
of almost totally useless signals that the thing was capable of sending.
I switched over to 4/2 format and programed it to send the essential zone
alarms and troubles, Bell circuit troubles , a common system trouble and
telephone line faults. Probably about 20 codes. Every thing else will cause a
common trouble signal to be sent and alarm history will tell me what it was.
Simple as that. Who in the hell needs a panel that will send almost 200 codes?
Information overload. Keep it simple as can be.
I may get a chance to try CID on a burg panel someday, but only if I've got the
free time to experiment. Other wise, I'll continue to do it the easy way (for
me) until I'm forced into it. I can program the 4/2 format codes for the zones
of a 45 zone system in about 15 seconds with the Napco panels. ( just did
this, by the way) It's faster to do then to program them for CID
It's just like the computer. People are always telling me to try a new program
to do this or that. I don't have the time to learn a new program. If
necessity requires me to do it in the future .... I will, otherwise ......
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> In article <tsumqin...@corp.supernews.com>, bad...@freedom.net
writes:
> >I don't know what you mean by "not being able to verify a signal is sent
for
> >each zone." The whole point of Contact ID is that it does send a unique
> >signal for each zone.
>
> I'm sure it does, but when central station reports to me, that an alarm
has
> been activated and they received a 4/1 I know it's a zone 11. I have no
idea
> what they would report for a CID programed system. But since I've used 4/2
> format for about 20 years, I don't have to think twice about how to
program a
> system or which zones have been tripped. It's easier to work with what I
know,
> inside out and backwards then it is to take the time to learn what CID
will do.
Whats to really learn?
> I still think it was designed to take up the slack of incompetent
installers
> who couldn't program a six zone panel without making a mistake and it also
> promotes not testing an entire panel. This thereby makes the centrals
happy
> because, even though there may be an incompetent installer, they know that
all
> the signals will be correct, reducing the possibility of a lawsuit.
I agreed with you on about everything in this message except this, besides
being much faster than 4/2 it does take the load off of an installer on
large jobs, unless you like programming 100 signals in 4/2 I'd just set the
panel for CID and be done with it
At one time cars were started with hand cranks, then in 1912 someone at GM
invented the electric started, within 3 years every car had an electric
started and no hand crank, fact is 4/2 is that hand starter..sure you CAN
start a car with a crank but the point is why do it when something is easier
to implement, harder to make a mistake and WAY faster than 4/2?
(I just saw that on the History channel about an hour ago btw)
> >In short, using "smart" formats makes your job easier not harder.
> >
>
> As you can see, in my opinion, it's a dumb format and doesn't make me
> comfortable in the process that I test my systems. Which, in brief,
consists of
> hanging my butt set on the phone lines and actually activating and
listening to
> each and every signal the panel is capable of sending. I get a verbal read
back
> from the operator. I obtain this copy of sent codes from the central and
keep
> it in the clients folder. Proof positive all the signals were sent.
No offense Jim but elsewhere in this message you state you don't know much
about CID or SIA, if so why accuse it of being a dumb format when you don't
know how it even works? if anything 4/2 is a dumb format, when SIA or CID
hits a receiver it gives far more information in far less time, 4/2 just
sends a signal that you give meaning later
> I once installed a commercial fire panel that the central encouraged me to
use
> CID reporting. Attempting to use my procedure, I had to stop sending
signals at
> about 128, when I realized that I was hardly half way through the entire
list
> of almost totally useless signals that the thing was capable of sending.
What was the panel? you don't have to send or use every report code,
consider it actually doing the same thing you do now except its automated on
the other end
> I switched over to 4/2 format and programed it to send the essential zone
> alarms and troubles, Bell circuit troubles , a common system trouble and
> telephone line faults. Probably about 20 codes.
Again you could have only used 20 codes with CID
> Every thing else will cause a
> common trouble signal to be sent and alarm history will tell me what it
was.
> Simple as that. Who in the hell needs a panel that will send almost 200
codes?
> Information overload. Keep it simple as can be.
Again, you didn't have to send 200 signals
> I may get a chance to try CID on a burg panel someday, but only if I've
got the
> free time to experiment.
Whats to learn? I have a feeling your thinking this takes some of the
control from your hands? If so that control could be better used in other
parts of the installations instead of report codes
> Other wise, I'll continue to do it the easy way (for
> me) until I'm forced into it. I can program the 4/2 format codes for the
zones
> of a 45 zone system in about 15 seconds with the Napco panels. ( just did
> this, by the way) It's faster to do then to program them for CID
I can't see this being the case at all, if anything it should take exactly
the same time because your doing almost exactly the same thing, in the case
of CID or SIA all you would have to do is program the report codes for the
zones and you don't even have to do that unless a zone is a fire or other
than burg zone, Napco defaults the zone report codes to send burg CID and
SIA
> It's just like the computer. People are always telling me to try a new
program
> to do this or that. I don't have the time to learn a new program. If
> necessity requires me to do it in the future .... I will, otherwise ......
Again, whats to learn? its a Napco panel and everything up from the lowly
XP-400 at most you have to learn a total of 8 possible report codes, here
I'll give you a quick lesson
For Zones use following report codes
1 = Fire
2 = Audible Panic
3 = Burg (default)
4 = Silent Panic
7 = Gas
8 = Heat
0 = Auxiliary Alarm
B = 24 hour Auxiliary Alarm
Now out of that list you may use for most installations 5 signals for the
zones, for everything else either zero out what you don't want and heck
leave in default what you do want (or put anything in as a report code since
it doesn't matter) and thats it, nothing else is needed except make the
format either a B (CID) or C (SIA) (I'm looking at a P816) No way can 4/2 be
as easy as that to program and you have a reporting format that sends 10
signals in less than 30 seconds which is about the same amount of time it
takes 4/2 to send 1. I have YET to meet a tech who's learned SIA or CID and
ever went back to 4/2 and I've taught hundreds if not thousands (yes RLB
thousands :)) how to do it
On the other end with CID your central station gets a fixed 3-digit code
which translates to
100 Medical
110 Fire
130 Burg
With SIA you get
BA 01 which means Burg Alarm Zone 1
FA 06 which means Fire Alarm Zone 6
(plus of course your zone descriptions)
My only complaints about the formats is with older designs like FBI or Caddx
Ranger panels where you do have to dig around to figure out what to enter,
however anything new from the Caddx NX, DSC PC1555/832, Napco, Ademco and
Linear it is FAR easier to use SIA or CID than it is for 4/2, ITI panels
don't even offer 4/2 anymore and I wish the others would follow suit quickly
bad...@freedom.net
"Alarminex" <alar...@aol.comQzapp> wrote in message
>
> I don't think restore signals are important and I don't want to send them.
It
> clutters up my ability to be able to test the systems appropriately. If I
want
> to send a restore on any particular signal, I can program it to do that.
Examples of situations where restore signals are important: lock-in holdup
buttons, low battery, AC fail, and any fire alarm zone.
>
> >Sure, I could call up the panel and download the log, or view it at the
> >keypad on site, but why should I, when I can see it all in the central
> >station activity?
>
> If a problem occurs, the owner will be advised by the keypad as to what
the
> problem is. If, between the signals received by central and what the
customer
> remembers, we cannot determine what has taken place, I'll walk the
customer
> through the keypad logs, where they can view the log events for openings
and
> closings, alarms, system troubles and fire alarms. Takes two minutes on
the
> phone .... and thats if it's necessary at all. Other wise a log download
will
> be done.
I wouldn't even try to have the typical customer view the log on the keypad
and read back the information to me. (I'm thinking of: 75 year old
homeowner, busy store owner, any place where the keypad isn't right next to
a phone, etc.) And besides, why should I expect them to do that? Taking
care of the alarm is my job, not theirs. If you use a "smart" format, you
have all the information right in front of you. No phone calls, no
downloads, no viewing logs on keypads--you already know what's going on
before you even start up your truck.
> Why would a wireless system be reporting trouble signals for each zone?
Low battery or missing transmitter conditions. Yes, it may be on the
keypad, but whenever possible, I like to know what the problem is before I
get to the job. Zone trouble signals are also very useful in
troubleshooting problems on zone expansion loops (Radionics popits, Ademco
RPMs, etc.)
>
> I'm sure it does, but when central station reports to me, that an alarm
has
> been activated and they received a 4/1 I know it's a zone 11. I have no
idea
> what they would report for a CID programed system.
Again, I don't use Napco, but on Ademco panels, when you use contact ID,
zone 11 reports as zone 11. You don't have to program the zone code.
>But since I've used 4/2
> format for about 20 years, I don't have to think twice about how to
program a
> system or which zones have been tripped. It's easier to work with what I
know,
> inside out and backwards then it is to take the time to learn what CID
will do.
One thing 4/2 is not at all good at is reporting openings and closings by
user, due to the limited number of individually identifiable user codes that
format can transmit.
> As you can see, in my opinion, it's a dumb format and doesn't make me
> comfortable in the process that I test my systems. Which, in brief,
consists of
> hanging my butt set on the phone lines and actually activating and
listening to
> each and every signal the panel is capable of sending. I get a verbal read
back
> from the operator. I obtain this copy of sent codes from the central and
keep
> it in the clients folder. Proof positive all the signals were sent.
The testing procedure is exactly the same regardless of the format you're
using. You arm the panel, trip the zones, and verify the signals.
Personally, I don't bother listening to the phone line unless I have reason
to believe there's a transmission problem: I can't interpret all those
tones in my head, so that's information I don't need.
>
> I once installed a commercial fire panel that the central encouraged me to
use
> CID reporting. Attempting to use my procedure, I had to stop sending
signals at
> about 128, when I realized that I was hardly half way through the entire
list
> of almost totally useless signals that the thing was capable of sending.
> I switched over to 4/2 format and programed it to send the essential zone
> alarms and troubles, Bell circuit troubles , a common system trouble and
> telephone line faults. Probably about 20 codes. Every thing else will
cause a
> common trouble signal to be sent and alarm history will tell me what it
was.
> Simple as that. Who in the hell needs a panel that will send almost 200
codes?
You don't need to transmit every possible signal the panel can transmit.
Obviously, you will want to transmit alarms from each zone and significant
trouble conditions, but just because the panel is capable of transmitting an
exit error message or a real-time clock reset message, I don't have to test
that. Odds are it will work fine, and if it fails to report, it's not a
critical loss.
I think you will find you sent in exactly the same number of test signals on
your commercial fire panel in 4/2 as you did in Contact ID. The only
difference is that a whole bunch of your signals were identical. In other
words, you say you programmed a lot of conditions to report a common trouble
signal--but in testing the system, you still had to create a trouble
condition on each zone.
Anyway, to each his own.
Robert L Bass
alarm and supervisory signals. These should all send restores in most cases.
There's another reason to use the more advanced signaling capabilities of CID
and SIA. I used to install fairly large residential systems -- sometimes. Many
of my DIY clients do them, too. When a system has over 32 zones, 4/2 is much
too limited as a reporting format. And when we approach capacity on a P9600 (96
zones) or a Caddx NetworX NX-8e system (192 zones), 4/2 is totally inadequate.
Of course if all you want to install is 2 door sensors and a motion detector,
the old-fashioned reporting formats may be OK.
badenov wrote:
:
: Examples of situations where restore signals are important:
: lock-in holdup buttons, low battery, AC fail, and any fire alarm
: zone.
:
: --- snip ---
:
: Anyway, to each his own.
That's for sure. :*)
Robert L Bass
of CID
and SIA. I used to install fairly large residential systems -- sometimes. "
Should have read "-- sometimes using the total capacity of the system."
One of these days I'll proof read a little more carefully before hitting [Send].
RLB
Mark Leuck
> Quite right, Badenov. Also, you might want to add Fire Trouble, *all*
sprinkler
> alarm and supervisory signals. These should all send restores in most
cases.
>
> There's another reason to use the more advanced signaling capabilities of
CID
> and SIA. I used to install fairly large residential systems -- sometimes.
Many
> of my DIY clients do them, too. When a system has over 32 zones, 4/2 is
much
> too limited as a reporting format. And when we approach capacity on a
P9600 (96
> zones) or a Caddx NetworX NX-8e system (192 zones), 4/2 is totally
inadequate.
> Of course if all you want to install is 2 door sensors and a motion
detector,
> the old-fashioned reporting formats may be OK.
Even for that small installation its never OK, the quicker the signal sends
the better
Robert L Bass
old-fashioned, slow format could get the job don. The newer, "smart" formats
are better and faster, but for the very smallest jobs, you could get away with
using the dumber 4/2 format. Given the choice, I can't conceive of a reason to
use it though.
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
Mark Leuck wrote:
:
: Robert L Bass wrote:
:
: > Of course if all you want to install is 2 door sensors and
Mark Leuck
still never use it unless the panel cannot do SIA or CID
"Robert L Bass" <Rober...@home.com> wrote in message
news:x_mA7.7468$Mn1.3...@news1.rdc1.fl.home.com...
Robert L Bass
"Mark Leuck" <mle...@iadfw.net> wrote in message
news:47C656632419A130.608AEBA7...@lp.airnews.net...
: 4/2 can always get the job done no matter the size of the system but I'd
: >
: >
:
:
Alarminex
>Subject: Re: Dispatching on undefined signals
>From: bad...@freedom.net
>Date: Sat, 20 Oct 2001 12:56:01 -0700
>
>
>"Alarminex" <alar...@aol.comQzapp> wrote in message
>news:20011020020521...@nso-mg.aol.com...
>
>>
>> I don't think restore signals are important and I don't want to send them.
>It
>> clutters up my ability to be able to test the systems appropriately. If I
>want
>> to send a restore on any particular signal, I can program it to do that.
>
>Examples of situations where restore signals are important: lock-in holdup
>buttons, low battery, AC fail, and any fire alarm zone.
>
Don't do much commercial anymore so holdup is not reqired.
I don't care of the low battery or AC fail or (residential) fire zones restore.
If any of these don't, the client is constantly being advised of the situation.
It's their responsibility to take action. Until they do, they constantly have
to reset the panel to arm it.
>
>>
>> >Sure, I could call up the panel and download the log, or view it at the
>> >keypad on site, but why should I, when I can see it all in the central
>> >station activity?
>>
>> If a problem occurs, the owner will be advised by the keypad as to what
>the
>> problem is. If, between the signals received by central and what the
>customer
>> remembers, we cannot determine what has taken place, I'll walk the
>customer
>> through the keypad logs, where they can view the log events for openings
>and
>> closings, alarms, system troubles and fire alarms. Takes two minutes on
>the
>> phone .... and thats if it's necessary at all. Other wise a log download
>will
>> be done.
>
>I wouldn't even try to have the typical customer view the log on the keypad
>and read back the information to me. (I'm thinking of: 75 year old
>homeowner, busy store owner, any place where the keypad isn't right next to
>a phone, etc.) And besides, why should I expect them to do that? Taking
>care of the alarm is my job, not theirs. If you use a "smart" format, you
>have all the information right in front of you. No phone calls, no
>downloads, no viewing logs on keypads--you already know what's going on
>before you even start up your truck.
Most of my customers could do what I instruct them to do over the phone.
If it were one of my older or busier customers, I'd download the log, if the
signals that came into central weren't enough of an indicator. I do expect
them to mind their own system. Taking care of the alarm system is their
job, until they can't.I have too many accounts to hand hold everyone of them.
When they do have a problem they don't understand or can't handle, then
they call me. I am advised of every alarm signal sent by every one of my
accounts. So I have a log of what signals, when and in what order they were
received. When they cannot handle the situation, or I see that trouble is
occuring,
by the signals I'm receiving ....Then ....it's my job. If they don't call me, I
call them.
4/2 format is smart enough at present and their are no complaints about
service,
from my clients.
>
>> Why would a wireless system be reporting trouble signals for each zone?
>
>Low battery or missing transmitter conditions. Yes, it may be on the
>keypad, but whenever possible, I like to know what the problem is before I
>get to the job.
When I get a call from my customer they say, the key pad is
saying ...etc, etc,etc. I know instantly whats wrong. I don't need that signal
going to central. As far as transmitter batteries, they all can change their
own
batteries. Or get a relative neighbor or friend to do it for them because they
usually don't want to afford to pay me to come and do it for them.
> Zone trouble signals are also very useful in
>troubleshooting problems on zone expansion loops (Radionics popits, Ademco
>RPMs, etc.)
I don't/wouldn't use those panels.
>
>>
>> I'm sure it does, but when central station reports to me, that an alarm
>has
>> been activated and they received a 4/1 I know it's a zone 11. I have no
>idea
>> what they would report for a CID programed system.
>
>Again, I don't use Napco, but on Ademco panels, when you use contact ID,
>zone 11 reports as zone 11. You don't have to program the zone code.
>
I don't program it special. I use **MY** default program with all of *** MY***
standard codes. I've been doing this for years and years. I think the biggest
system was a 64 zone panel and I've got it all worked out, formated, documented
and all I have to do is fill in the zone descriptions.
>>But since I've used 4/2
>> format for about 20 years, I don't have to think twice about how to
>program a
>> system or which zones have been tripped. It's easier to work with what I
>know,
>> inside out and backwards then it is to take the time to learn what CID
>will do.
>
>One thing 4/2 is not at all good at is reporting openings and closings by
>user, due to the limited number of individually identifiable user codes that
>format can transmit.
I don't ever have systems that require more then 4 - 6 users for opening a
closings.
>
>> As you can see, in my opinion, it's a dumb format and doesn't make me
>> comfortable in the process that I test my systems. Which, in brief,
>consists of
>> hanging my butt set on the phone lines and actually activating and
>listening to
>> each and every signal the panel is capable of sending. I get a verbal read
>back
>> from the operator. I obtain this copy of sent codes from the central and
>keep
>> it in the clients folder. Proof positive all the signals were sent.
>
>The testing procedure is exactly the same regardless of the format you're
>using. You arm the panel, trip the zones, and verify the signals.
>Personally, I don't bother listening to the phone line unless I have reason
>to believe there's a transmission problem: I can't interpret all those
>tones in my head, so that's information I don't need.
I do listen and I can interpret most 4/2 codes, close enough to know if it's
wrong or not. It helps me to know if I've sent a test code out of sequence.
lets me know if, in fact, a signal is being sent, rather then waiting to call
central and get a read back. If something is wrong, I can stop right there,
fix the problem, and then continue in sequence.
>
>>
>> I once installed a commercial fire panel that the central encouraged me to
>use
>> CID reporting. Attempting to use my procedure, I had to stop sending
>signals at
>> about 128, when I realized that I was hardly half way through the entire
>list
>> of almost totally useless signals that the thing was capable of sending.
>> I switched over to 4/2 format and programed it to send the essential zone
>> alarms and troubles, Bell circuit troubles , a common system trouble and
>> telephone line faults. Probably about 20 codes. Every thing else will
>cause a
>> common trouble signal to be sent and alarm history will tell me what it
>was.
>> Simple as that. Who in the hell needs a panel that will send almost 200
>codes?
>
>You don't need to transmit every possible signal the panel can transmit.
>Obviously, you will want to transmit alarms from each zone and significant
>trouble conditions, but just because the panel is capable of transmitting an
>exit error message or a real-time clock reset message, I don't have to test
>that.
But I do. If it's a code that the panel sends and an action is required to be
taken on it, then it needs to be transmitted.
> Odds are it will work fine, and if it fails to report, it's not a
>critical loss.
Those are odds I don't take. Thats why I want to test every code that I want
central
to take action on. If I don't want them to take action, then I don't want to
send the
code. If it sends a code that I don't want then central has an unidentified
code to
do what (?) with. And in addition to that, superfluous codes take up time,
space
and slow down the central station. And isn't that what CID is supposed to
elimiate
by being so fast? Sure, you can send 2 codes by the time 4/2 sends one code.
And that's supposed to be an advantage. But CID is sending restores for every
code. Disarming signals, and on and on and on ...... And the next *** REAL***
alarm signal from the next subscriber is just there, sitting in the cache,
waiting for
the next available screen.
>
>I think you will find you sent in exactly the same number of test signals on
>your commercial fire panel in 4/2 as you did in Contact ID. The only
>difference is that a whole bunch of your signals were identical. In other
>words, you say you programmed a lot of conditions to report a common trouble
>signal--but in testing the system, you still had to create a trouble
>condition on each zone.
No you're wrong on that. I don't mind sending a test trouble signal on each
zone and
and on bell, low battery etc, these are codes that I *do* want to know. But all
the others
....... nahhhh ... local annunciation is good enough.
What I did was, program the system so that zone troubles, bell troubles
system troubles all tripped the trouble relay which just sent one trouble
signal to
central. I don't care what kind of trouble it is. I'm going to have to go there
to fix
it anyway. I'll look at the log when I get there and fix it. I don't need to
know that
there was a ground fault or a earth ground fail, or restores or what ever other
ridiculous alerts the panel sends in CID. All I need to know is basic system
supervisory conditions. Everything else can show at the keypad. Anything that
doesn't report will cause the loud annoying warning beeps locally and will
cause
the end user to call me and I'll fix it when I get there.
>
>Anyway, to each his own.
Yeah I know. Could you e-mail Mark and tell him that?
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Sat, 20 Oct 2001 02:08:28 -0500
>
>
>"Alarminex" <alar...@aol.comQzapp> wrote in message
>news:20011020020521...@nso-mg.aol.com...
>
>> In article <tsumqin...@corp.supernews.com>, bad...@freedom.net
>writes:
>> >I don't know what you mean by "not being able to verify a signal is sent
>for
>> >each zone." The whole point of Contact ID is that it does send a unique
>> >signal for each zone.
>>
>> I'm sure it does, but when central station reports to me, that an alarm
>has
>> been activated and they received a 4/1 I know it's a zone 11. I have no
>idea
>> what they would report for a CID programed system. But since I've used 4/2
>> format for about 20 years, I don't have to think twice about how to
>program a
>> system or which zones have been tripped. It's easier to work with what I
>know,
>> inside out and backwards then it is to take the time to learn what CID
>will do.
>Whats to really learn?
I don't know. If I knew the details of how CID worked and reported, then I
wouldn't
think I have something to learn. But ........... I WILL know EVERYTHING about
it before I use it. Perhaps, in the process, I'll find out that there isn't
much to it .....
but only ** I ** can and will determine that.
>
>> I still think it was designed to take up the slack of incompetent
>installers
>> who couldn't program a six zone panel without making a mistake and it also
>> promotes not testing an entire panel. This thereby makes the centrals
>happy
>> because, even though there may be an incompetent installer, they know that
>all
>> the signals will be correct, reducing the possibility of a lawsuit.
>
>I agreed with you on about everything in this message except this, besides
>being much faster than 4/2 it does take the load off of an installer on
>large jobs, unless you like programming 100 signals in 4/2 I'd just set the
>panel for CID and be done with it
I don't do jobs that require 100 signals.
AAAAANNNNNND!
I wouldn't "just set the panel for CID and be done with it" until I find out
what the panel
is supposed to be sending and whether I like what it's sending. And whether I
will
comply with my signal test requirements. And whether it will take up too much
of
my time to figure out what it's sending and what it's *** supposed *** to be
sending.
And whether I want to take the time to find out **** what **** if any, the
differences
are and whether I *** like **** those differences or not. I am not likely to
take up using
CID or any other format on the say so of anyone but what *** MY *** conclusions
are.
>
>At one time cars were started with hand cranks, then in 1912 someone at GM
>invented the electric started, within 3 years every car had an electric
>started and no hand crank, fact is 4/2 is that hand starter..sure you CAN
>start a car with a crank but the point is why do it when something is easier
>to implement, harder to make a mistake and WAY faster than 4/2?
Well you want to use that analogy, lets carry it a little further
How many starters didn't work of caused people to not be able to start their
cars, and how many years was it before it was finally perfected. And for how
many years
were cars made so that they could be started *both* ways because the electric
starter
wasn't perfected? By the time cars were mfg'd with starters only, the electric
starter
was perfected. And how many people do you think ran out and bought a new car
because their old one didn't have an electric starter?
CID may be perfected, but I'm not going to use it until I have the time
to learn about it, what it does and doesn't do, and if it meets *** MY ***
requirements.
YOU, working with this every day, understand it and can say "just to be done
with it",
I don't. Therefore it'll wait till I have the time to look into it.
>
>(I just saw that on the History channel about an hour ago btw)
>
>> >In short, using "smart" formats makes your job easier not harder.
>> >
>>
>> As you can see, in my opinion, it's a dumb format and doesn't make me
>> comfortable in the process that I test my systems. Which, in brief,
>consists of
>> hanging my butt set on the phone lines and actually activating and
>listening to
>> each and every signal the panel is capable of sending. I get a verbal read
>back
>> from the operator. I obtain this copy of sent codes from the central and
>keep
>> it in the clients folder. Proof positive all the signals were sent.
>
>No offense Jim but elsewhere in this message you state you don't know much
>about CID or SIA, if so why accuse it of being a dumb format when you don't
>know how it even works? if anything 4/2 is a dumb format, when SIA or CID
>hits a receiver it gives far more information in far less time, 4/2 just
>sends a signal that you give meaning later.
At this point, it's "dumb" to me, since it's sending information that is
useless
and I don't have control over it. This is my impression from what I've heard
about it, and until I have the time to learn the details, it's useless and
meaningless
to me.
>
>> I once installed a commercial fire panel that the central encouraged me to
>use
>> CID reporting. Attempting to use my procedure, I had to stop sending
>signals at
>> about 128, when I realized that I was hardly half way through the entire
>list
>> of almost totally useless signals that the thing was capable of sending.
>
>What was the panel? you don't have to send or use every report code,
>consider it actually doing the same thing you do now except its automated on
>the other end
I was a Firelight panel, I don't remember which model. But, by the time I tried
to
figure out how to program the information I wanted it to transmit or not, .....
and
then test it to see if it was doing what I thought it should do, it was much
simpler
to program a few 4/2 signals and ***** "be done with it" *****.
>
>> I switched over to 4/2 format and programed it to send the essential zone
>> alarms and troubles, Bell circuit troubles , a common system trouble and
>> telephone line faults. Probably about 20 codes.
>
>Again you could have only used 20 codes with CID
Again, by the time I figured out how I might have been able to do that........
Yep ..... 4/2 in two minutes and done.
>
>> Every thing else will cause a
>> common trouble signal to be sent and alarm history will tell me what it
>was.
>> Simple as that. Who in the hell needs a panel that will send almost 200
>codes?
>> Information overload. Keep it simple as can be.
>
>Again, you didn't have to send 200 signals
Again, by the time I figured out ................
>
>> I may get a chance to try CID on a burg panel someday, but only if I've
>got the
>> free time to experiment.
>
>What's to learn? I have a feeling your thinking this takes some of the
>control from your hands? If so that control could be better used in other
>parts of the installations instead of report codes
Maybe so, but I doubt it. Again, if, some day If get around to finding the time
to learn how, what, when, where ......I'll let you know. Until then, 4/2 works
well, reliable, no problems, I know it like the back of my hand, and I don't
have to take any time to learn anything because what I have is working. When
I have to ..... or I can find the time ............ I'll do it. And I'll have a
better
understanding of it then most. But you can be absolutely sure it won't be
done "just to be done with it"
>
>> Other wise, I'll continue to do it the easy way (for
>> me) until I'm forced into it. I can program the 4/2 format codes for the
>zones
>> of a 45 zone system in about 15 seconds with the Napco panels. ( just did
>> this, by the way) It's faster to do then to program them for CID
>
>I can't see this being the case at all, if anything it should take exactly
>the same time because your doing almost exactly the same thing, in the case
>of CID or SIA all you would have to do is program the report codes for the
>zones and you don't even have to do that unless a zone is a fire or other
>than burg zone, Napco defaults the zone report codes to send burg CID and
>SIA
I don't accept the default program. I have my own default program. And that
includes all of the codes that I normally use. So, in fact, it's a lot easier
for
me to program 4/2. Save my default to a new account, make a few modifications
and done. Could I do the same in CID? Yep, someday ... not until I know all
about it.
>
>> It's just like the computer. People are always telling me to try a new
>program
>> to do this or that. I don't have the time to learn a new program. If
>> necessity requires me to do it in the future .... I will, otherwise ......
>
>Again, what's to learn? its a Napco panel and everything up from the lowly
>XP-400 at most you have to learn a total of 8 possible report codes, here
>I'll give you a quick lesson
>
>For Zones use following report codes
>1 = Fire
>2 = Audible Panic
>3 = Burg (default)
>4 = Silent Panic
>7 = Gas
>8 = Heat
>0 = Auxiliary Alarm
>B = 24 hour Auxiliary Alarm
>
>Now out of that list you may use for most installations 5 signals for the
>zones, for everything else either zero out what you don't want and heck
>leave in default what you do want (or put anything in as a report code since
>it doesn't matter) and thats it, nothing else is needed except make the
>format either a B (CID) or C (SIA) (I'm looking at a P816) No way can 4/2 be
>as easy as that to program and you have a reporting format that sends 10
>signals in less than 30 seconds which is about the same amount of time it
>takes 4/2 to send 1.
As of the last time we discussed this, my opinion still hasn't changed about
the amount of time it takes to send signals. Takes about 15 -20 seconds to send
a 4/2 signal. How much faster would CID be and what difference would it make?
Yep .......... none. Now .... if you talk about sending 10 or 20 signals,
granted, CID
would do it in a quarter of the time. But central is going to react to the
first code,
anyway. So don't tell me that CID is faster. In actual and practical
situations, the
time difference doesn't amount to anything. How much quicker do you think the
police or fire department will get there? We're talking about 5 seconds at the
most
compared to a half hour or more police response time. Time difference is no
issue.
>I have YET to meet a tech who's learned SIA or CID and
>ever went back to 4/2 and I've taught hundreds if not thousands (yes RLB
>thousands :)) how to do it.
>
>On the other end with CID your central station gets a fixed 3-digit code
>which translates to
>100 Medical
>110 Fire
>130 Burg
>
>With SIA you get
>BA 01 which means Burg Alarm Zone 1
>FA 06 which means Fire Alarm Zone 6
>(plus of course your zone descriptions)
What about low battery, AC loss, telco loss. Fail to communicate, dialer test,
program change, wireless supervision, wireless receiver failure, ..........
And stop sending the damn restores ........?
>My only complaints about the formats is with older designs like FBI or Caddx
>Ranger panels where you do have to dig around to figure out what to enter,
>however anything new from the Caddx NX, DSC PC1555/832, Napco, Ademco and
>Linear it is FAR easier to use SIA or CID than it is for 4/2, ITI panels
>don't even offer 4/2 anymore and I wish the others would follow suit quickly.
When they do, then I'll HAVE to use the damn electric starter, and then I'll
HAVE
to learn how to use it and what, exactly, it is doing.
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
>
> I don't know. If I knew the details of how CID worked and reported, then I
> wouldn't
> think I have something to learn. But ........... I WILL know EVERYTHING
about
> it before I use it. Perhaps, in the process, I'll find out that there
isn't
> much to it .....
> but only ** I ** can and will determine that.
True however the problem is you only get half the story out in the field,
the real learning of what hey do is at the central station, at least it was
for me
> >I agreed with you on about everything in this message except this,
besides
> >being much faster than 4/2 it does take the load off of an installer on
> >large jobs, unless you like programming 100 signals in 4/2 I'd just set
the
> >panel for CID and be done with it
>
> I don't do jobs that require 100 signals.
I thought that was your complaint about CID on that fire panel?
> AAAAANNNNNND!
> I wouldn't "just set the panel for CID and be done with it" until I find
out
> what the panel
> is supposed to be sending
Its listed in the book and your Central Station will send you a copy of your
panels reporting just like they normally do
> and whether I like what it's sending. And whether I
> will
> comply with my signal test requirements.
That shouldn't change at all
And whether it will take up too much
> of
> my time to figure out what it's sending and what it's *** supposed *** to
be
> sending.
The first one will, any panel after that it should be easy
> And whether I want to take the time to find out **** what **** if any,
the
> differences
> are and whether I *** like **** those differences or not. I am not likely
to
> take up using
> CID or any other format on the say so of anyone but what *** MY ***
conclusions
> are.
I'm not forcing you to do this Jim, please remember that :)
> >At one time cars were started with hand cranks, then in 1912 someone at
GM
> >invented the electric started, within 3 years every car had an electric
> >started and no hand crank, fact is 4/2 is that hand starter..sure you CAN
> >start a car with a crank but the point is why do it when something is
easier
> >to implement, harder to make a mistake and WAY faster than 4/2?
>
> Well you want to use that analogy, lets carry it a little further
> How many starters didn't work of caused people to not be able to start
their
> cars, and how many years was it before it was finally perfected.
Apparently not that long since every car had it 3 years later, btw the
reason someone invented the electric starter was because one of the head
honchos at GM was killed crank starting a car :)
> And for how many years
> were cars made so that they could be started *both* ways because the
electric
> starter
> wasn't perfected?
Bad example, CID and SIA have been "perfected" for a long time, no offense
to you Jim but I've talked to manufacturers and the ONLY reason several of
them even continue with 4/2 is because of some stubborn techs and central
stations who don't have receivers that can handle them, not because CID or
SIA aren't perfected. ITI and the Moose ZX300 before it was discontinued
wouldn't even do 4/2. If other companies follow your going to have to force
yourself to learn how that electric starter works quickly :)
By the time cars were mfg'd with starters only, the electric
> starter
> was perfected. And how many people do you think ran out and bought a new
car
> because their old one didn't have an electric starter?
Apparently a lot of them since the crank died quickly
> CID may be perfected, but I'm not going to use it until I have the time
> to learn about it, what it does and doesn't do, and if it meets *** MY ***
> requirements.
> YOU, working with this every day, understand it and can say "just to be
done
> with it",
> I don't. Therefore it'll wait till I have the time to look into it.
Again we agree, my "just be done with it" doesn't mean you can't learn more
about the formats, just that in my opinion reporting codes aren't anywhere
near as important as they used to be
> >No offense Jim but elsewhere in this message you state you don't know
much
> >about CID or SIA, if so why accuse it of being a dumb format when you
don't
> >know how it even works? if anything 4/2 is a dumb format, when SIA or CID
> >hits a receiver it gives far more information in far less time, 4/2 just
> >sends a signal that you give meaning later.
>
> At this point, it's "dumb" to me, since it's sending information that is
> useless
> and I don't have control over it. This is my impression from what I've
heard
> about it, and until I have the time to learn the details, it's useless and
> meaningless
> to me.
Odd opinion but I'll accept it
> >What was the panel? you don't have to send or use every report code,
> >consider it actually doing the same thing you do now except its automated
on
> >the other end
>
> I was a Firelight panel, I don't remember which model. But, by the time I
tried
> to
> figure out how to program the information I wanted it to transmit or not,
.....
> and
> then test it to see if it was doing what I thought it should do, it was
much
> simpler
> to program a few 4/2 signals and ***** "be done with it" *****.
I'm currently working on a Fire Lite 411UD Communicator program sheet, with
CID you can zero out what you don't want just like any other panel and it
auto reports for everything you do want
> >> I switched over to 4/2 format and programed it to send the essential
zone
> >> alarms and troubles, Bell circuit troubles , a common system trouble
and
> >> telephone line faults. Probably about 20 codes.
> >
> >Again you could have only used 20 codes with CID
>
> Again, by the time I figured out how I might have been able to do
that........
> Yep ..... 4/2 in two minutes and done.
Its almost exactly the same as you are programming now, if anything
different digits in Zone reporting
> >What's to learn? I have a feeling your thinking this takes some of the
> >control from your hands? If so that control could be better used in other
> >parts of the installations instead of report codes
>
>
> Maybe so, but I doubt it. Again, if, some day If get around to finding the
time
> to learn how, what, when, where ......I'll let you know. Until then, 4/2
works
> well, reliable, no problems, I know it like the back of my hand, and I
don't
> have to take any time to learn anything because what I have is working.
When
> I have to ..... or I can find the time ............ I'll do it. And I'll
have a
> better
> understanding of it then most. But you can be absolutely sure it won't be
> done "just to be done with it"
Fair enough, I do think you are missing out on what the new formats will do
and how they work
> As of the last time we discussed this, my opinion still hasn't changed
about
> the amount of time it takes to send signals. Takes about 15 -20 seconds to
send
>
> a 4/2 signal. How much faster would CID be and what difference would it
make?
Which 4/2 are you using? Express? Most of my examples are with 4/2 standard
reporting and they take FAR longer than 15 to 20 seconds
> Yep .......... none. Now .... if you talk about sending 10 or 20 signals,
> granted, CID
> would do it in a quarter of the time. But central is going to react to the
> first code anyway. So don't tell me that CID is faster. In actual and
practical
> situations,
True but with CID those 10 signals would be done in 30 seconds, with 4/2
those signals would still be sending while Central Station is calling,
granted 10 signals will be a rare occurance however even 2 or 3 signals
which are much more common could be a problem
> the time difference doesn't amount to anything. How much quicker do you
think the
> police or fire department will get there? We're talking about 5 seconds at
the
> most
> compared to a half hour or more police response time. Time difference is
no
> issue
In my opinion the quicker the signal the better, the police response isn't
something I can change, length of time and quality of signal the panel
reports as well as central station response times I can
.
> >On the other end with CID your central station gets a fixed 3-digit code
> >which translates to
> >100 Medical
> >110 Fire
> >130 Burg
> >
> >With SIA you get
> >BA 01 which means Burg Alarm Zone 1
> >FA 06 which means Fire Alarm Zone 6
> >(plus of course your zone descriptions)
>
> What about low battery, AC loss, telco loss. Fail to communicate, dialer
test,
> program change, wireless supervision, wireless receiver failure,
..........
> And stop sending the damn restores ........?
Its automatic, no matter what report code you put in any of those locations
it will send what it is supposed to send by the CID or SIA standard
If you put 11 as report code for AC loss it will send E301
If you put F4 as report code for AC loss it will send E301
If you put 01 as report code for AC loss it will send E301 (get the
picture?)
If you put 00 as report code for AC loss it wil not send
> When they do, then I'll HAVE to use the damn electric starter, and then
I'll
> HAVE
> to learn how to use it and what, exactly, it is doing.
My question then is why do you have to learn something until you have to?
Your customers may somehow benefit by you using the new report formats yet
you don't know since you are not forced to learn it? Its never too late to
learn Jim and I can pretty much guarentee that once you know it you won't go
back
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> I do listen and I can interpret most 4/2 codes, close enough to know if
it's
> wrong or not. It helps me to know if I've sent a test code out of
sequence.
> lets me know if, in fact, a signal is being sent, rather then waiting to
call
> central and get a read back. If something is wrong, I can stop right
there,
> fix the problem, and then continue in sequence.
If you mean interpret 4/2 listening on the buttset I can do that too, people
used to think I was nuts :)
> and slow down the central station. And isn't that what CID is supposed to
> elimiate
> by being so fast? Sure, you can send 2 codes by the time 4/2 sends one
code.
> And that's supposed to be an advantage. But CID is sending restores for
every
> code.
Not if you don't want it to
> Disarming signals
Not if you don't want it to, even if you did want them the time it takes is
virtually nil compared to 4/2
> and on and on and on
Not if you don't want it to and to and to, you give me a panel example and
I'll send you a program sheet setup for SIA or CID
> ...... And the next *** REAL***
> alarm signal from the next subscriber is just there, sitting in the cache,
> waiting for
> the next available screen.
I suppose that depends on the automation although I've yet to hear about a
central station complaining about too many CID or SIA signals at one time
unless its a runaway panel and the wierd thing is I've never seen a runaway
panel sending CID or SIA...no idea why
> Yeah I know. Could you e-mail Mark and tell him that?
Hehe, what was that for??
Robert L Bass
:
: > At one time cars were started with hand cranks, then in 1912
: Well you want to use that analogy, lets carry it a little further
: How many starters didn't work of caused people to not be
: Apparently not that long since every car had it 3 years later, btw
: > And for how many years
: > were cars made so that they could be started *both* ways because the
: electric
: > starter
: > wasn't perfected?
: Bad example, CID and SIA have been "perfected" for a long time,
: wouldn't even do 4/2. If other companies follow your
: By the time cars were mfg'd with starters only, the electric
: > starter
: > was perfected. And how many people do you think ran out and bought a new
: car
: > because their old one didn't have an electric starter?
:
: Apparently a lot of them since the crank died quickly
:
: > CID may be perfected, but I'm not going to use it until I
: > requirements.
: > YOU, working with this every day, understand it and can say "just to be
: > done with it", I don't. Therefore it'll wait... [with baited breath?]
: Again we agree, my "just be done with it" doesn't mean you can't
Alarminex
<Rober...@home.com> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Robert L Bass" <Rober...@home.com>
>Date: Sun, 21 Oct 2001 22:10:44 GMT
>
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_0008_01C15A5B.A7EEE6A0
>Content-Type: text/plain;
> charset="Windows-1252"
>Content-Transfer-Encoding: quoted-printable
>
Mind your own fucking business, asshole.
Maybe if you'd do that, you'd know how to send a properly formated post in
Usenet.
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Sun, 21 Oct 2001 15:14:29 -0500
>
>
>"Alarminex" <alar...@aol.comQzapp> wrote in message
>news:20011021140509...@nso-fi.aol.com...
>
>True however the problem is you only get half the story out in the field,
>the real learning of what hey do is at the central station, at least it was
>for me.
Yes, I know. I've been told by all my central stations how much it will benifit
them.
>
>>
>> I don't do jobs that require 100 signals.
>
>I thought that was your complaint about CID on that fire panel?
What I said/meant is that it was a small ( 10 zone, I think) panel and it was
going to send or had the potential to send 190 some odd codes. I didn't know
how to stop it from sending those codes I didn't want to send. I wasn't about
to sit down then, while the customer is waiting for his system to be turned on,
so he can get his CO, and learn all about a new panel, a new format, and how to
make it do what I wanted it to do. You tell me ...... why the hell would I ever
want to send :
Annunciator Fault code
Printer Fault code
485 Comm. Trouble Code
Upload download request code
Upload sucessfull code
Download successful code
Upload download Failed code.
Drill Code
Earth fault code
No battery code
A zone disable code by each and every zone.
and lots more about 80 if I remember right.
Now.......... consider all of the restore codes that get sent and then multiply
that
times 2. Because all of those signals above are only thoes categorized as being
sent on the "Primary" telephone line only! Secondary line signals have a
different code.
Gimmie a freakin break! All anyone needs to know is alarm/trouble/low
battery/AC power loss and in the case of fire, telco line loss. If I were doing
a 50 or 100 zone plus system ..... yeah maybe. But not 10 zones.
If there would have been a paragraph in the manual that said:
In the event you do not wish to send all CID signals, do this, this and this.
I would have done that. Tested that the panel was sending those signals and
have been satisfied. It didn't say that and I wasn't about to re-read the
manual nor take the time to try something that I was unsure of the results. I
resorted to something that I knew and it worked fine. I may have been just as
easy to do it with CID, but then wasn't the time attempt to discover, interpret
and experiment.
>
>> AAAAANNNNNND!
>> I wouldn't "just set the panel for CID and be done with it" until I find
>out
>> what the panel
>> is supposed to be sending
>
>Its listed in the book and your Central Station will send you a copy of your
>panels reporting just like they normally do.
Undoubtedly. I haven't the faintest idea if I'd understand what they were
sending me, and I'm not going to take the time to be instructed by an operator
at the time I'm sending in test signals on whether, what I am sending at that
particular time is correct or not. I want to know ahead of time, if, when I
send a particular signal to central what they are *supposed* to get. Not what
they *tell* me they are supposed to get.
>> and whether I like what it's sending. And whether I
>> will
>> comply with my signal test requirements.
>
>That shouldn't change at all
I doubt it too.
>
> And whether it will take up too much
>> of
>> my time to figure out what it's sending and what it's *** supposed *** to
>be
>> sending.
>
>The first one will, any panel after that it should be easy.
So, ........... someday, when I get the time, I'll try it.
>
>> And whether I want to take the time to find out **** what **** if any,
>the
>> differences
>> are and whether I *** like **** those differences or not. I am not likely
>to
>> take up using
>> CID or any other format on the say so of anyone but what *** MY ***
>conclusions
>> are.
>
>I'm not forcing you to do this Jim, please remember that :)
>
I'm quite aware of that. When I feel it's important enough to do and or I get
the impulse, or find it convenient to do .............. I'll do it. If some one
were to tell me that this would stop false alarms forever, I'd do it. Right
now, there is no compelling reason and no outstanding benefit to me to find the
time to learn something that has dubious or minimal benifits. Which is my
opinion at this point. It just aint that important.
>> >At one time cars were started with hand cranks, then in 1912 someone at
>GM
>> >invented the electric started, within 3 years every car had an electric
>> >started and no hand crank, fact is 4/2 is that hand starter..sure you CAN
>> >start a car with a crank but the point is why do it when something is
>easier
>> >to implement, harder to make a mistake and WAY faster than 4/2?
>>
>> Well you want to use that analogy, lets carry it a little further
>> How many starters didn't work of caused people to not be able to start
>their
>> cars, and how many years was it before it was finally perfected.
>
>Apparently not that long since every car had it 3 years later, btw the
>reason someone invented the electric starter was because one of the head
>honchos at GM was killed crank starting a car :)
That must have been an interesting "turn" of events.
>
>> And for how many years
>> were cars made so that they could be started *both* ways because the
>electric
>> starter
>> wasn't perfected?
>
>Bad example, CID and SIA have been "perfected" for a long time, no offense
>to you Jim but I've talked to manufacturers and the ONLY reason several of
>them even continue with 4/2 is because of some stubborn techs and central
>stations who don't have receivers that can handle them, not because CID or
>SIA aren't perfected. ITI and the Moose ZX300 before it was discontinued
>wouldn't even do 4/2.
Well, that may well be the case. Then people HAD to use 4/2. When that time
comes, ..............
> If other companies follow your going to have to force
>yourself to learn how that electric starter works quickly :)
As I say, then if I havta .... I havta.
>
> By the time cars were mfg'd with starters only, the electric
>> starter
>> was perfected. And how many people do you think ran out and bought a new
>car
>> because their old one didn't have an electric starter?
>
>Apparently a lot of them since the crank died quickly.
But they didn't go out and buy a new car just because it had an electric
starter.
Just remember, old cranks never die ..... they just get caught up in the
"revolution"
>> CID may be perfected, but I'm not going to use it until I have the time
>> to learn about it, what it does and doesn't do, and if it meets *** MY ***
>> requirements.
>> YOU, working with this every day, understand it and can say "just to be
>done
>> with it",
>> I don't. Therefore it'll wait till I have the time to look into it.
>
>Again we agree, my "just be done with it" doesn't mean you can't learn more
>about the formats, just that in my opinion reporting codes aren't anywhere
>near as important as they used to be
I don't know what that means.
>
>>
>> At this point, it's "dumb" to me, since it's sending information that is
>> useless
>> and I don't have control over it. This is my impression from what I've
>heard
>> about it, and until I have the time to learn the details, it's useless and
>> meaningless
>> to me.
>
>Odd opinion but I'll accept it.
I don't see what's so odd about not wanting to use something that I'm not
familiar with .... until I'm familiar with it. And not finding the time to get
familiar with it because it's not important to me at this time.
>
>> I was a Firelight panel, I don't remember which model. But, by the time I
>tried
>> to
>> figure out how to program the information I wanted it to transmit or not,
>.....
>> and
>> then test it to see if it was doing what I thought it should do, it was
>much
>> simpler
>> to program a few 4/2 signals and ***** "be done with it" *****.
>
>I'm currently working on a Fire Lite 411UD Communicator program sheet, with
>CID you can zero out what you don't want just like any other panel and it
>auto reports for everything you do want
>
>> Again, by the time I figured out how I might have been able to do
>that........
>> Yep ..... 4/2 in two minutes and done.
>
>Its almost exactly the same as you are programming now, if anything
>different digits in Zone reporting.
>
>>
>> Maybe so, but I doubt it. Again, if, some day If get around to finding the
>time
>> to learn how, what, when, where ......I'll let you know. Until then, 4/2
>works
>> well, reliable, no problems, I know it like the back of my hand, and I
>don't
>> have to take any time to learn anything because what I have is working.
>When
>> I have to ..... or I can find the time ............ I'll do it. And I'll
>have a
>> better
>> understanding of it then most. But you can be absolutely sure it won't be
>> done "just to be done with it"
>
>Fair enough, I do think you are missing out on what the new formats will do
>and how they work.
You haven't given me one overpowering reason to take the time to sit down and
study this. Granted it could take me 10 minutes or it could take me hours. I
don't have the time to waste, right now to try to discover how something works
that is not important enough.
>
>> As of the last time we discussed this, my opinion still hasn't changed
>about
>> the amount of time it takes to send signals. Takes about 15 -20 seconds to
>send
>>
>> a 4/2 signal. How much faster would CID be and what difference would it
>make?
>
>Which 4/2 are you using? Express? Most of my examples are with 4/2 standard
>reporting and they take FAR longer than 15 to 20 seconds.
Universal High speed.
>
>> Yep .......... none. Now .... if you talk about sending 10 or 20 signals,
>> granted, CID
>> would do it in a quarter of the time. But central is going to react to the
>> first code anyway. So don't tell me that CID is faster. In actual and
>practical
>> situations,
>
>True but with CID those 10 signals would be done in 30 seconds, with 4/2
>those signals would still be sending while Central Station is calling,
>granted 10 signals will be a rare occurance however even 2 or 3 signals
>which are much more common could be a problem
Not enough to worry about.
Look, ............ if it took five minutes to send one signal via 4/2 format
and you told me I could shorten that to 10 seconds, it'd be worth it for me to
investigate. Other wise ........ it's not significant. It's not important. It's
not critical. It's not even worth the calories I've taken to type this.
>
>> the time difference doesn't amount to anything. How much quicker do you
>think the
>> police or fire department will get there? We're talking about 5 seconds at
>the
>> most
>> compared to a half hour or more police response time. Time difference is
>no
>> issue
>
>In my opinion the quicker the signal the better, the police response isn't
>something I can change, length of time and quality of signal the panel
>reports as well as central station response times I can.
Quality of signal?????
Wow. *** That's *** a new one. Quality of signal ..... I'll have to remember
that. Does that mean it's more melodic? Surround sound? THX maybe? Five butt
sets with a sub-woofer?
I'd rather you do something to alleviate the rate of false alarms. See Irv
Fishers solutions. If Centrals were using his techniques and I was required to
use CID in order to accomplish that, I'd do it in a flash. Otherwise CID is
nothing more than a gradual change over to standardization of alarm signals.
Nothing wrong with that, by the way, but nothing compelling. When it happens,
it happens.
>.
>>
>> What about low battery, AC loss, telco loss. Fail to communicate, dialer
>test,
>> program change, wireless supervision, wireless receiver failure,
>..........
>> And stop sending the damn restores ........?
>
>Its automatic, no matter what report code you put in any of those locations
>it will send what it is supposed to send by the CID or SIA standard
>
>If you put 11 as report code for AC loss it will send E301
>If you put F4 as report code for AC loss it will send E301
>If you put 01 as report code for AC loss it will send E301 (get the
>picture?)
>If you put 00 as report code for AC loss it wil not send
I haven't the faintest idea what you are talking about.
>
>> When they do, then I'll HAVE to use the damn electric starter, and then
>I'll
>> HAVE
>> to learn how to use it and what, exactly, it is doing.
>
>My question then is why do you have to learn something until you have to?
Because my time is valuable and there is no overpowering or compelling benefit
to taking the undetermined amount of time to learn about CID. However it is
important to me to go to classes on structured wiring, Home automation and New
products from manufacturers. Follow up new products on the internet. Talk to
mfg's about their products. Experiment with new products. Comming up, I'll be
learning how to program a Caddx panel for a customer who's doing a full blown
home automation system and insists on using Caddx because he says it's more
compatable to the Stargate system. I'm checking into that. But, as you can see,
there are many, many more important and compelling things for me to do then
take the time to learn about a somewhat meaningless improvement in sending
alarm codes. Especially since, what I'm using now is working.
>Your customers may somehow benefit by you using the new report formats yet
>you don't know since you are not forced to learn it? Its never too late to
>learn Jim and I can pretty much guarentee that once you know it you won't go
>back
>
Your indulgence and pratronization is deeply appriciated but I have more
important things to do.
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
Yup, however what would you do if sending 4/2? I assume you zero out what
you don't want, you would do the same thing with Contact ID
> Gimmie a freakin break! All anyone needs to know is alarm/trouble/low
> battery/AC power loss and in the case of fire, telco line loss. If I were
doing
> a 50 or 100 zone plus system ..... yeah maybe. But not 10 zones.
Some of those signals may be required by the state? You'd know whats
required more than I on that one
> If there would have been a paragraph in the manual that said:
> In the event you do not wish to send all CID signals, do this, this and
this.
If its a Fire Lite panel I believe it does, I'll have to check
That depends on how they tell you I guess, if they say the raw output it
does get confusing
> Because my time is valuable and there is no overpowering or compelling
benefit
> to taking the undetermined amount of time to learn about CID. However it
is
> important to me to go to classes on structured wiring, Home automation and
New
> products from manufacturers. Follow up new products on the internet. Talk
to
> mfg's about their products. Experiment with new products. Comming up, I'll
be
> learning how to program a Caddx panel for a customer who's doing a full
blown
> home automation system and insists on using Caddx because he says it's
more
> compatable to the Stargate system. I'm checking into that. But, as you can
see,
> there are many, many more important and compelling things for me to do
then
> take the time to learn about a somewhat meaningless improvement in sending
> alarm codes. Especially since, what I'm using now is working.
No offense but you feel the need to learn all that yet not something (in my
opinion) something far more important like a reporting format?
> > >Your customers may somehow benefit by you using the new report formats
yet
> >you don't know since you are not forced to learn it? Its never too late
to
> >learn Jim and I can pretty much guarentee that once you know it you won't
go
> >back
> >
>
> Your indulgence and pratronization is deeply appriciated but I have more
> important things to do.
Heh, I guess
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Mon, 22 Oct 2001 17:54:20 -0500
>
>
> Because all of those signals above are only thoes categorized as
>being
>> sent on the "Primary" telephone line only! Secondary line signals have a
>> different code.
>
>Yup, however what would you do if sending 4/2? I assume you zero out what
>you don't want, you would do the same thing with Contact ID
>
No, I just program in what I want to send and leave the rest blank.
>> Gimmie a freakin break! All anyone needs to know is alarm/trouble/low
>> battery/AC power loss and in the case of fire, telco line loss. If I were
>doing
>> a 50 or 100 zone plus system ..... yeah maybe. But not 10 zones.
>
>Some of those signals may be required by the state? You'd know whats
>required more than I on that one
>
Alarm, trouble, AC power fail, Low battery. Line A fail, Line B fail.
>
>> If there would have been a paragraph in the manual that said:
>> In the event you do not wish to send all CID signals, do this, this and
>this.
>
>If its a Fire Lite panel I believe it does, I'll have to check
That's what I would have had to do and I didn't want to take the time to try to
deciper and test. And if wrong, deciper and test. etc, etc.
I want to know ahead of time, if, when I
>> send a particular signal to central what they are *supposed* to get. Not
>what they *tell* me they are supposed to get.
>
>That depends on how they tell you I guess, if they say the raw output it
>does get confusing
Thats, my point. I don't want it to be confusing. I will know more about it
then the operators. I'm not going to put the testing of my programing into the
hands of the interpretation of a central station operator just because I don't
know what the panel is Reeealy .... supposed to be sending. I want to know. I
will tell *them* what they're supposed to be getting ..... not the other way
around.
>
> But, as you can see,
>> there are many, many more important and compelling things for me to do then
>> take the time to learn about a somewhat meaningless improvement in sending
>> alarm codes. Especially since, what I'm using now is working.
>No offense but you feel the need to learn all that yet not something (in my
>opinion) something far more important like a reporting format?
Now you've got it by Jove! Because it's not important to me, I havent taken the
time to learn it. It is NOT far more important to me. What I'm using now has
worked and still works. No problems, no trouble, no mistakes, no
misinterpretation, no misunderstanding. There is no overwhelming reason for me
to learn about this right now. Other, more immediate things come first. It
aint broke .... it don't need fixin or changin. It may be *nice* but it's not
important. Like air conditioning. If you never had it, you don't miss it. Once
you have it, you wonder how you did without it. It can wait till it becomes
important or other things are not so important.
>>
>> Your indulgence and pratronization is deeply appriciated but I have more
>> important things to do.
>
>Heh, I guess
That was meant as sarcasm
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> In article
<08FBD41545114735.70BC1C1B...@lp.airnews.net>,
> "Mark Leuck" <mle...@iadfw.net> writes:
>
> >Subject: Re: Dispatching on undefined signals
> >From: "Mark Leuck" <mle...@iadfw.net>
> >Date: Mon, 22 Oct 2001 17:54:20 -0500
> >
> >
>
> > Because all of those signals above are only thoes categorized as
> >being
> >> sent on the "Primary" telephone line only! Secondary line signals have
a
> >> different code.
> >
> >Yup, however what would you do if sending 4/2? I assume you zero out what
> >you don't want, you would do the same thing with Contact ID
> >
>
> No, I just program in what I want to send and leave the rest blank.
Works the same for Contact ID except you don't have to program what you want
to send
Thats fairly easy then
Fair enough
> >>
> >> Your indulgence and pratronization is deeply appriciated but I have
more
> >> important things to do.
> >
> >Heh, I guess
>
>
> That was meant as sarcasm
I know
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Tue, 23 Oct 2001 00:08:21 -0500
>
>
>>
>> No, I just program in what I want to send and leave the rest blank.
>
>Works the same for Contact ID except you don't have to program what you want
>to send
>
But I don't know what it *will* send, so how do I know if what it's sending is
what it should be sending? Someday, when I have the time, I'll find out.
>> I want to know. I
>> will tell *them* what they're supposed to be getting ..... not the other
>way around.
>
>Thats fairly easy then
No doubt, it will be.
>
>> >
>> > But, as you can see,
>> >> there are many, many more important and compelling things for me to do
>then take the time to learn about a somewhat meaningless improvement in
>sending alarm codes. Especially since, what I'm using now is working.
>>
>>
>>No offense but you feel the need to learn all that yet not something (in my
>> >opinion) something far more important like a reporting format?
>>
>> Now you've got it by Jove! Because it's not important to me, I havent taken
the
>> time to learn it. It is NOT far more important to me. What I'm using now has
>> worked and still works. No problems, no trouble, no mistakes, no
>> misinterpretation, no misunderstanding. There is no overwhelming reason
>>for me to learn about this right now. Other, more immediate things come
first.
>>It aint broke .... it don't need fixin or changin. It may be *nice* but it's
not
>> important. Like air conditioning. If you never had it, you don't miss it.
>>Once you have it, you wonder how you did without it. It can wait till it
>>becomes important or other things are not so important.
>
>Fair enough
>
Whew!
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> In article
<87EBD219899FDA14.4594D971...@lp.airnews.net>,
> "Mark Leuck" <mle...@iadfw.net> writes:
>
> >Subject: Re: Dispatching on undefined signals
> >From: "Mark Leuck" <mle...@iadfw.net>
> >Date: Tue, 23 Oct 2001 00:08:21 -0500
> >
> >
> >>
> >> No, I just program in what I want to send and leave the rest blank.
> >
> >Works the same for Contact ID except you don't have to program what you
want
> >to send
> >
>
> But I don't know what it *will* send, so how do I know if what it's
sending is
> what it should be sending? Someday, when I have the time, I'll find out.
You will know what it sends since its in the book, any panel that sends SIA
or Contact ID has a listing
Contrary to popular belief I do know when to quit banging my head against
the wall :)
Jack Stevens
of years with no trouble until recently. My CS receiver's first handshake
(not the right one for SIA) is causing my panels to send signals even before
the handshake tone quits. Panels communicate properly with DSC's receiver,
same SurGaurd model, same defaults on the handshake tones. My CS has
"ordered new chips" which will supposedly solve the problem. ( Can't wait
for this one. )
The older installs seem to be working ok, but the new panels of the same
version don't report SIA properly with my CS receiver. Using contact ID,
everything is fine. DSC says no changes have been made within this
revision. (5010 v2)
--
Jack Stevens
alarman2000.NOSPAM.yahoo.com
remove NOSPAM. to reply
Mark Leuck wrote
Alarminex
"Mark Leuck" <mle...@iadfw.net> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Mark Leuck" <mle...@iadfw.net>
>Date: Tue, 23 Oct 2001 18:26:13 -0500
>
>
>> But I don't know what it *will* send, so how do I know if what it's
>sending is
>> what it should be sending? Someday, when I have the time, I'll find out.
>
>You will know what it sends since its in the book, any panel that sends SIA
>or Contact ID has a listing
I don't recall ever seeing a list of CID signals or for that matter, have I
ever seen a detailed written explanation of how CID works or what signals are
sent for what kind of activations or what the advantages and or disadvantages
are. All the information I've every received on the subject is partial,
incomplete, in nature and/or from unknowledgeable people, in the form of
hearsay.
I just briefly checked a Napco Gemini MA3200 installation and programing manual
and I didn't catch anything that looked like a list of CID **or** SIA signals.
Could be in there but mostly I see information about 4/2 and other similar
formats. CID and SIA seem to be mentioned in a ...... *by the way* it can do
*this* too .... manner but apparently assumes one knows what *** this*** does
and how it works.
>> Whew!
>
>Contrary to popular belief I do know when to quit banging my head against
>the wall :)
>
>
>
Hmmmmmm. Thought you had a learning disability.
Jack Stevens
Uh, no, I don't think it's Mark with the learning disability. :-/
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
> In article
<EF0665E192CB0311.248E597F...@lp.airnews.net>,
> "Mark Leuck" <mle...@iadfw.net> writes:
>
> >Subject: Re: Dispatching on undefined signals
> >From: "Mark Leuck" <mle...@iadfw.net>
> >Date: Tue, 23 Oct 2001 18:26:13 -0500
> >
> >
> >> But I don't know what it *will* send, so how do I know if what it's
> >sending is
> >> what it should be sending? Someday, when I have the time, I'll find
out.
> >
> >You will know what it sends since its in the book, any panel that sends
SIA
> >or Contact ID has a listing
>
> I don't recall ever seeing a list of CID signals or for that matter, have
I
> ever seen a detailed written explanation of how CID works or what signals
are
> sent for what kind of activations or what the advantages and or
disadvantages
> are. All the information I've every received on the subject is partial,
> incomplete, in nature and/or from unknowledgeable people, in the form of
> hearsay.
Lemme see what I can dig up, you are correct it doesn't seem to be listed on
Napco documentation which is odd
>
> I just briefly checked a Napco Gemini MA3200 installation and programing
manual
> and I didn't catch anything that looked like a list of CID **or** SIA
signals.
> Could be in there but mostly I see information about 4/2 and other similar
> formats. CID and SIA seem to be mentioned in a ...... *by the way* it can
do
> *this* too .... manner but apparently assumes one knows what *** this***
does
> and how it works.
>
>
> >> Whew!
> >
> >Contrary to popular belief I do know when to quit banging my head against
> >the wall :)
> >
> >
> >
>
> Hmmmmmm. Thought you had a learning disability.
Insipid clods usually can't tell they have learning disabilities :)
Robert L Bass
I have the Contact ID protocol in an MS Word document. It explains in detail
the complete transmission and includes a list of all CID codes as defined by
Ademco. I'll post it to my FAQ shortly. It's worth noting that the installer
does not need to understand all the intricate details of the code to implement
it. Most of the transmission is automatically generated by every CID enabled
panel and is automatically understood by the receiver. The installer only needs
to select which code will be sent.
The options for the panels that $%^#$ uses are as follows: "Fire, Panic, Burg,
Holdup, Gas Alarm, Heat Alarm, Auxiliary and 24 Hr Aux." Any installer who
can't decide between those options needs to find another profession. On Ademco
panels, the reporting options are somewhat more flexible. For example, you can
select various types of Burg signal: 24 Hr Burg, Instant Burg, Perimeter Burg,
Delay Burg, etc.
One some panels the transmission code is automatic. When you define the zone
type (Perimeter, Interior, 24-Hour, Entry Delay, etc.) the panel decides for you
what CID codes it will send. This is much easier for the installer. There's
really nothing special to learn. This is one of the reasons I like using CID.
It's almost impossible to get the code wrong once you decide on the format, no
matter what Central Station you use, the codes are the same. 4/2 can't hold a
candle to CID.
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
Mark Leuck wrote:
:
: Lemme see what I can dig up, you are correct it doesn't seem to be listed on
: Napco documentation which is odd...
Robert L Bass
codes for various events as defined by Ademco and standardized by SIA.
http://www.bass-home.com/faq/protocol_contactid.cfm
This FAQ page only lists the codes sent. The rest of the transmission -- Zone
ID, Partition (area) number, account number, etc. -- are automated so the
installer need not specify them. The panel takes care of that.
Regards,
Robert L Bass
=============================>
Bass Home Electronics
The Online DIY Alarm Store
http://www.Bass-Home.com
4883 Fallcrest Circle
Sarasota, FL 34233
877-722-8900 Sales & Tech Support
941-925-9747 voice (Florida)
941-926-9857 fax
Rober...@home.com
=============================>
"Robert L Bass" <Rober...@home.com> wrote in message
news:hvvB7.2292$G8.2...@news1.rdc1.fl.home.com...
: Mark,
:
:
Alarminex
<Rober...@home.com> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Robert L Bass" <Rober...@home.com>
>Date: Wed, 24 Oct 2001 09:05:17 GMT
>Mark,
>
>I have the Contact ID protocol in an MS Word document. It explains in detail
>the complete transmission and includes a list of all CID codes as defined by
>Ademco. I'll post it to my FAQ shortly. It's worth noting that the
>
First of all . Mind your own fucking business.
Second, maybe YOU don't want to know what your doing and don't want to tell
your customers what THEY are doing. But ** I ** want to know what it's all
about. I wont just blindly go ahead and use something that I haven't fully
investigated. Apparently you don't give a shit what you use or tell your
client to do.
When it becomes important to do ...... I'll do it but it wont be because of
anything that you have to say about it ...... You can be fucking sure of that,
twat face.
Fuck off!
Alarminex
<alarm...@yahoo.com> writes:
>Subject: Re: Dispatching on undefined signals
>From: "Jack Stevens" <alarm...@yahoo.com>
>Date: Wed, 24 Oct 2001 04:56:34 GMT
>
>> Hmmmmmm. Thought you had a learning disability.
>
>Uh, no, I don't think it's Mark with the learning disability. :-/
>--
You might try learning to butt out.
Jack Stevens
--
Jack Stevens
alarman2000.NOSPAM.yahoo.com
remove NOSPAM. to reply
"Alarminex" <alar...@aol.comQzapp> wrote in message
news:20011024130924...@nso-fo.aol.com...
Mark Leuck
"Alarminex" <alar...@aol.comQzapp> wrote in message
news:20011024130924...@nso-fo.aol.com...
of
> anything that you have to say about it ...... You can be fucking sure of
that,
> twat face.
>
>
Damn, I haven't heard anyone called a twat face in years! :)
Mark Leuck
"Robert L Bass" <Rober...@home.com> wrote in message
news:UzvB7.2293$G8.2...@news1.rdc1.fl.home.com...
Robert L Bass
"Mark Leuck" <mle...@iadfw.net> wrote in message
news:1C54138112B160EB.FBFEB689...@lp.airnews.net...
: Sorry for the binaries in the previous message
: > :
: >
: >
:
:
Robert L Bass
"Mark Leuck" <mle...@iadfw.net> wrote in message
news:606E3BC6643B9552.FED679CB...@lp.airnews.net...
:
: "Alarminex" <alar...@aol.comQzapp> wrote in message
:
:
: