[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Tech question - interface between receiver and central station software



> Hi there, hey thanks for all the tips and comments everybody. I am very
> "green" to all this as I have only been working in the security
> industry for a matter of months now, having spent the last 12 or so
> years in the computer industry. I understand basically what the
> templates are, such as Contact.ID, etc. They provide the interpretation
> for the data stream that comes from the receiver. Simple enough?

Basically, yes.  There are agreed codes for each condition.  If the receiver
sees a given code, it expects the condition to correspond to those listed in
the published format.  However, there are a number of popular formats and
variants on each of them.  You'll need to provide a means to set deviations
from the standard code in case a given panel or location is not fully
conformed to the standard.

> The pricing I mentioned, of $50,000 is just something I pulled out of a
> hat. In reality, I have been unable to obtain pricing for the product I
> was looking at, which is called Alarm Center

I'm unfamiliar with that product.  If their salesman isn't being helpful,
you should look elsewhere or, if you're up to it, write your own.  One word
of caution though -- central station automation software tends to get pretty
involved.  It's not for the feint of heart.

> Anyway, yes, I am slowly going to develop my own in-house system, so
> Robert L. Bass, your offer of assistance and advice is gratefully
> appreciated. I'm going to need all the help I can get. As for XML, I
> haven't even looked at that yet.

Advice is free.  Programming assistance isn't.  :^)

> If anybody has a good database schematic (ERD)
> for a simple alarm monitoring system I would
> really like to take a peek...

Other than myself, none of the regular participants here appears to have
much background in software development.  Even my experience is somewhat
limited.  I own part of a software firm but I'm not one of the coders.  I
mostly do help systems, UI design and sales.  Between them my partners have
over 60 years of SW development.

> I'm currently finding all kinds of pitfalls with
> the database design, and can see that my
> elementary knowledge of Normalisation (sorry,
> Normalization for the Americans amongst us)
> is going to be seriously put to the test on this
> project!

Every project is either a learning experience or boring.  This one's likely
to be a little of both.  If you start with a good relational platform,
develop a modular system that's flexible and easily modified, you'll spend
far less time redoing mistakes.

Some firms offer downloadable demos of their software.  It might be a good
idea for you to obtain several of these and familiarize yourself with what
others have done before you even start planning the project.  You'll get
ideas about useful functionality which you can plan for in your own system.

> For instance, putting the patrol and monitoring
> information together in the Client table was dumb,
> as it slowly dawned on me that you can have
> a client with monitoring but no patrol, or vice
> versa, and also either the patrol or the monitoring
> could be provided by a third party! Oops!

You might want to build collections of patrol service data, response
protocols, local and state authority lists, etc.  By linking these to
clients based on client location and reported conditions you can avoid a
great deal of repetitive (read: error prone) data entry.  This will also
allow you to quickly make changes to all client accounts within a
municipality when the PD of FD decides to change phone numbers or whatever.

The same applies to standardized procedures.  Create collections of
procedures (e.g., what kind of authority, responsible party, etc., to notify
in what order under a given condition).  Link to your keyholder and
responding authority tables through these rather than directly from each
client's account data.  This will allow you to rapidly implement changes to
all affected customers when some PD decides they want a keyholder or guard
service to respond before they dispatch.

There is much more to consider but hopefully this will start you thinking in
the right direction.

> As you can see, my lack of experience in
> the security industry is going to make this
> a tough ride.

Recognition of ignorance is a prerequisite to education.  :^)

> Anyway, thanks again for all the advice.

You're most welcome.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
2291 Pine View Circle
Sarasota · Florida · 34231
877-722-8900 Sales & Tech Support
http://www.bassburglaralarms.com
=============================>




alt.security.alarms Main Index | alt.security.alarms Thread Index | alt.security.alarms Home | Archives Home