Tech question - interface between receiver and central station software
bewareo...@gmail.com
believe) which goes to a receiver computer running software called
Telemate which shows basic information (client, zone/user, type etc).
>From there I assume it connects to one of our main central station PC's
running Patriot (www.patriot.co.nz)
I understand how to read the raw data e.g. from Contact ID panels, but
was just wondering how this was communicated to the central station PC,
probably by serial cable.
The reason I'm asking is I'm toying with the idea of writing a simple
monitoring app of my own. And the only thing I can't seem to find any
information on is how a program can communicate with, and receive info
from the receiver.
If anyone has any info or links, it would be gratefully received. Just
curious. :-)
Jim
I can't answer your question, but if you look in the back of some of
the trade magazines, someone is always advertising programs that will
allow a computer to act as a central station receiver. Other than that,
I'd say, those programs can't be very comprehensive and digital
receivers have been around for a long, long time and computers can do
lots and lots of stuff nowdays. If it were that easy to do, someone
would have done it already and central stations wouldn't be paying
thousands of dollars for new digital receivers.
Just and observation.
mckenzie
allows you to view incoming signals and set up the receiver and line cards.
You can also print out line statistics, etc via the report menu. If you
have the FE100 database version, you can do simple monitoring as well
(limited to 500 clients, I think).
The FE100 itself decodes the signals from the panels and simply sends the
data via the automation serial port to your PC (or server) runnig Patriot.
Most Fe100s have been set up to emulate the Ademco 685 receiveroutput, but
yopu can choose other protocols as well, such as Surgard.
Patriot then works out what the signals are, firstly by using the account
and port number to determine who the signal is from in the database, then
looking at the Types template for that client to see how to interpret the
message - open/close, burg, etc, depending on what format is being sent by
the panel.
The FE100 does the hard work of decoding and handshaking with the panel.
Telemate does not need to run at all, but we keep it on anyway - mainly as a
tool to check line stats and bad signals.
To set up your own app, you will need some sort aof database (Patriot
started with Clarion, now uses SQL) and a means of capturing the serial
data. there are many freeware and opensource data capture programs
available. We use a real old one called Winlog now and again just to test
comms and mimic the serial printer.
You would then need some sort of front end to allow you to interact with the
database so you can attend the various signals, set up some templates for
the various formats, etc. I have no doubt it is simple for someone to do (I
have no idea how to go about writing such a program), and that is how
Patriot and many other got started. Could be fun..
You can run two automation packages together on the same serial port from
the FE100, as a means of testing it.
www.fratech.com.au
www.inner-range.com.au
If you get yourself a password to the site, you can download the documents,
although it is just simple serial data capture in the end.
Good luck
Graeme McKenzie
<bewareo...@gmail.com> wrote in message
news:1120235359.7...@g43g2000cwa.googlegroups.com...
Andrew
That was incredibly interesting. Yeah, we run Telemate as a backup,
during the regular times when Patriot crashes. We are currently still
stuck on version 4 (clarion database) and are trying to get them to set
training times, so we can upgrade to version 5 with the sql database,
which will make things a lot faster and easier to run searches.
I knew how the templates etc work (may I say god bless Contact ID, and
boo to old panels that use 4+2 lol) but yeah it was just understanding
the serial connection, which you've answered in great detail.
Thanks :D
mckenzie
Everything is much better, although we upgraded our server soon after, so
performance increased anyway. The 'training' was an afternoon with one
Patriot guy, who asked us more question than we asked him. Sometimes the
best way to learn is to just do it.
Patriot are good to us, we have been using their software for about 5 years,
and they are very quick to issue updates when we request features.
Don't dis 4+2 totally, at least you know that the signal you get thru was
purposely programmed - even if it doesn't match the template. With CID,
there are a few manufacturers that use an odd code, that nobody has picked
up on, until it comes thru, in the middle of the night.
Best format would have to be IR Fast - everything comes thru in the same
english the tech programs in the Concept panel. Everytime they update
users, we don't have to - the new name comes thru automatically!
Worst format is Ademco fast - never understood it correctly - the template
works perfect, so we don't look into it too much. I tried to work it out
about 10 years ago, but then CID came along and we were sorted! have to
say, though - it is by far the fastest format I have seen, bar IR Fast.
Also it's the best format for the old Solution 8 panels - 4+2 sucks majorly
on them - very very slow reporting!
Where are you monitoring? We are in Wanganui, but cover the country, with
remote FE100 receivers on different PC ports.
Graeme McKenzie
"Andrew" <bewareo...@gmail.com> wrote in message
news:1120281078....@g49g2000cwa.googlegroups.com...
Andrew
training session. We're already using it because one PC here is a
remote terminal we monitor for another company, which uses V5.
The only reason I am not a 4+2 fan is because it's such a hassle to
program lol. We have a folder with information on the formats to help
operators program them up, once you do a couple it's not hard - but
Contact ID is just much more "plug and play" from a central station
point of view lol.
We have a few IRFast clients, very handy format. We tend to stick to
Contact ID, IRFast and 4+2 if needed on those older panels. However we
have had a few Cactus clients switch to us and have had to make
provisions to support the odd radionics format (I don't know much about
it).
We monitor from New Plymouth, Taranaki-wide, mostly local but a few
national. One of our biggest selling points is being local, having
people who know your area etc... Plus we have our own guards in New
Plymouth and Hawera, which avoids the ghastly dispatch centres of
ADT/Armourguard or Chubb.
We have one FE100 receiver, and a Silent Knight which we monitor for a
local medical alarm trust, as well as a standard RF receiver.
mckenzie
now that the 'free' contracts are ending. People are sick of long despatch
delays.
New Plymouth - very close indeed! I assume your RF receiver is the
Radionet. We've had one for a few years now, just setting up the CID version
this week, so hopefully selling a few more transmitters this year.
Cheers,
Graeme McKenzie
"Andrew" <bewareo...@gmail.com> wrote in message
news:1120313396.7...@g47g2000cwa.googlegroups.com...
Greene Security NZ
I'm new to this group, and came across your postings. Interestingly
enough, what you are talking about as a theoretical project, I am
attempting to do for real. Any advice or assistance I can get along the
way would really be appreciated.
I am connecting to an FBII Digital Receiver, model CP-220FB. We
currently use an old DOS-based piece of software as the automation
package. I am attempting to write my own automation software using
Microsoft Access as the front-end, and Microsoft Desktop Engine (the
cut-down version of SQL Server) as the back-end. I haven't as yet
gotten as far as the serial-port interface, but that will definitely be
happening in the not-too-distant future. We also have a SafeCom Radio
Receiver, which also outputs on the serial port, so I will be
interfacing with that as well.
I am a novice programmer, and can cut VBA and VB code, and have minimal
SQL knowledge. Most of my programming is done by way of plagiarism - a
snippet of code from here, a snippet from there.
I am doing this for the security monitoring company I work for, as a
pet project. They needed something better than the old DOS system, but
aren't prepared to pay the $50,000+ for a licence for professionally
written automation software. There is no set timeframe for completion.
I'll be keeping an eye on this thread, so if anyone wants to contribute
constructive advice (please don't tell me it can't be done!) I look
forward to hearing from you.
Robert Frittmann
Database Administrator
Max 351
it is simple to use and setup excellent 24 hour support, does everything the
more expensive packages do and dont charge extra license fees for additional
work stations.
"Greene Security NZ" <gs_new...@yahoo.co.nz> wrote in message
news:1120391135.0...@o13g2000cwo.googlegroups.com...
Robert L. Bass
"Greene Security NZ" <gs_new...@yahoo.co.nz> wrote in message
news:1120391135.0...@o13g2000cwo.googlegroups.com...
You may still want to consider using SQL instead of MS Access for its
security advantages. It doesn't take that long to master once you have a
handle on Access. If you're handy with XML you'll find it a lot easier to
set up the receiver, protocol, etc., than hard-coding in VB. You can
implement various formats using schemas much quicker and with far less
hassle than you can rewrite your code.
You can also edit account data and signal displays much easier in XML than
you can with VB. I'd use VB as the backbone and XML as the interface
between the app, the data and the receivers. Doing it this way you can more
easily create reusable, modular code than by hard-coding everything.
--
Regards,
Robert L Bass
=============================>
Bass Home Electronics
2291 Pine View Circle
Sarasota · Florida · 34231
877-722-8900 Sales & Tech Support
http://www.bassburglaralarms.com
=============================>
Andrew
It's definitely a do-able project. I will most likely never write the
program, the main problem was just understanding the flow of data from
receiver to computer. The rest is easy, matching against templates for
Contact ID, retrieving keyholder contacts and response plans from
database tables are relatively simple tasks with basic database
knowledge.
I sit at work in front of Patriot (versions 4 and 5) and think "I wish
they would change that, or do that differently" lol. Someone
recommended NTSW's software - which I personally don't like the looks
of, it seems very Windows 3.1ish.
I downloaded a demo of Microkey and another of A-Traq, both have nice
interfaces, I've also seen screenshots of Bold's Manitou which seems
very powerful. However I can only assume very high price tags on these
packages.
mckenzie
them an email, they are pretty good at modifying things if there is a good
reason. Have you made sure that your software is up to date? There have
been several updates within version 4 and 5. You should be looking for
updates every month.
Graeme McKenzie
"Andrew" <bewareo...@gmail.com> wrote in message
news:1120424331....@f14g2000cwb.googlegroups.com...
mckenzie
http://www.patriot.co.nz
Graeme McKenzie
"Greene Security NZ" <gs_new...@yahoo.co.nz> wrote in message
news:1120391135.0...@o13g2000cwo.googlegroups.com...
A-traq
also try A-traq. You can download a demonstration version and get it
running in any language within a couple of hours. Although it is one of
the newer softwares on the market, it is the only automation to be
tested by UL for managing 3,000,000 accounts and passed with success.
They have the capability of using all sorts of databases (SQL, Oracle,
etc) which gives flexibility. If you do want to see how good aftersales
support is you best log in to http://www.a-traq.com
Good luck.
Robert L. Bass
> interfaces, I've also seen screenshots of Bold's Manitou which seems
> very powerful. However I can only assume very high price tags on these
> packages.
There have been several threads on this subject in the past. One gentleman
has posted a horror story regarding the central station software he
purchased. You may want to do a Google search on the subject. I bought
BOLD quite a few years ago for my central station. Our operation was very
small but the automation system was first rate. Other than one problematic
release we had very good experience dealing with Bradley.
When I first bought the BOLD package the price was quite reasonable --
around $10,000 if I recall correctly. That included a PC (our first) and a
separate terminal. I have no idea what they charge now but I assume it's
several times what I paid.
If you ever decide to go ahead with the project and you need some help, let
me know. I own part of a software development firm with extensive
experience in machine communications. We've also developed software for the
alarm industry. Several thousand fire alarm dealers use downloading
software which we wrote for Edwards.
A-traq
is very low compared to rival products. You can add web modules such as
the Web User Module for users to log in to your web-site and
self-update personal details from as low as 750.00€'s. The Web
Technician Module, for field technicians to fill all information
through any type of portable internet access instrument (such as Pocket
PC's, etc.), cost around 1,950.00€'s. It is the only solution to
provide the complete automation for managing installations connected
with the central monitorign station.
I guess it is a must for CMS's with more than 2000 accounts. I
recommend that you go and download the demonstration version from
http://www.a-traq.com With prices as low as this it would be a waste of
time in going and developing a seperate software.
buco
min, hr or day from the cs to determind that all is well, could one of
these
programs capture the all is well signal from the control panel
Mark Leuck
"buco" <emu...@co.wake.nc.us> wrote in message
news:1120763573....@g14g2000cwa.googlegroups.com...
Daily yes, hour or minutes no although some are capable of hourly (Caddx for
one)
Okitoki
Yes indeed. Almost all monitoring stations do capture the test signal
sent. Most panels now use up-to hourly controls.
But if you have a more secure region that requires on-line telephone
control then you must use either radio networks (of which the initial
cost is expensive but the running cost is very low), GSM networks (of
which the initial cost is low but the running cost is high) and telecom
switchboard monitoring (of which as far as I recall is only valid in
A-traq).
The radio network can be used as a primary or backup to the telephone
system. This is ok with UL. The GSM is very similiar to the radio
network yet much expensive if chosen as a primary communication. The
best is using the telecoms software to monitor any phone problems. This
information is passed on directly to the monitoring station and all
costs a forwarded to the user rather than the monitoring station. This
is not mentioned in UL but is used quite frequently throughout Europe.
I hope this does give you some idea of how test signals are captured
and what the precautions can be.
Good-luck!
buco
Greene Security NZ
"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?
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
(http://www.securitysoftware.com) 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.
Robert L. Bass
> "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.
James
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
"Greene Security NZ" <gs_new...@yahoo.co.nz> wrote in message
news:1121087736....@g14g2000cwa.googlegroups.com...
Greene Security NZ
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.
mckenzie
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?
http://www.patriotsystems.com/pricing.asp
Graeme McKenzie
"Greene Security NZ" <gs_new...@yahoo.co.nz> wrote in message
news:1121087736....@g14g2000cwa.googlegroups.com...
Crash Gordon®
"James" <trish...@comcast.net> wrote in message news:376dnVpMAcQ...@comcast.com...