Tech question - interface between receiver and central station software

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.

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.

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

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.

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.

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.

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

You're most welcome.

If the Alarm Center Software you are talking about is from SIS you can expect to pay between 5k and 10k. We have been using it for about 20 years, "we started with the dos version". The DOS version was excellent, the windows version could use a little help.

James

James, which edition of SIS Alarm Centre do you use? We were looking at the Small Network Edition, which, from memory, allows for two computers connected to receivers, and up to 5 supporting computers in a network. We were also interested in the WebAccess module, to allow our techs to access the data directly without having to bother despatch at all for the status and test stuff.

I just got the latest prices from Patriot. Packages start at US $1200 for

500 clients, one workstation license. $3500 for two workstations, and up from there. For 1200 bucks, it's not really worthwhile writing your own software is it? Graeme McKenzie

I still have my copy of the dos version...I think I paid 2500 bucks for it originally...I took my small cs down years ago but kept the software and cables for some reason....yep it was very good for the money...so was the suppport.

| > 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 | >

as they repeatedly ask me for the | > configuration of our current system, number of clients, etc, etc, etc | > before they will give me pricing. Surely someone in the security | > industry would understand that I am not authorised to give out that | > kind of information. Duh! | >

| > 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. | >

| > If anybody has a good database schematic (ERD) for a simple alarm | > monitoring system I would really like to take a peek. 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! | >

| > 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! | > As you can see, my lack of experience in the security industry is going | > to make this a tough ride. | >

| > Anyway, thanks again for all the advice. | >

| > Rob. | >

| | |