Posts: 40,483
Threads: 491
Joined: Aug 2002
It seems to provide pretty much the same features. They both support up to 8 areas (DSC calls them partitions but they are still areas in CQC Security Speak.)
The Elk offers a lot more zones, up to 208 I think, while the DSC maxes out at 64. Though on the Elk motion detection is done via zones a well, so both security and motion zones have to come out of that count, whereas the DSC is all security zones and motion would have to be done via something else.
The Elk offers a few more arming modes, but the ones the DSC offers are probably the one's you'd almost always use.
In terms of the more esoteric stuff, I couldn't say, or in terms of the more prosaic stuff like how straightforward is it to use and such.
The control protocol on the Elk is much more straightforward, but the DSC protocol will work.
Dean Roddey
Explorans limites defectum
Posts: 2,339
Threads: 104
Joined: Apr 2009
07-18-2014, 09:38 AM
(This post was last modified: 07-18-2014, 09:55 AM by batwater.)
dgage,
With regard to the current DSC driver, all of the capabilities of the panel are exposed in the driver. So for example, wireless devices provide a battery fault indicator when a battery starts getting low. All zone events are reported to the driver and can be used to trigger automation activities.
Not sure what else you might like to know. I cannot compare contrast to the other systems as I've not owned them. It would be fair to say that the DSC is an alarm system and only an alarm system whereas the ELK is an alarm system that is also automation capable and the HAI is an automation system that is also alarm system capable. I believe all are industry certified for fire/security.
-Ben
Posts: 310
Threads: 12
Joined: Feb 2013
Thanks very much Dean for the overview!
Posts: 2,339
Threads: 104
Joined: Apr 2009
dgage Wrote:Thanks very much Dean for the overview!
Opps, my response after Dean's was directed to you not daddyd
Posts: 310
Threads: 12
Joined: Feb 2013
batwater Wrote:Opps, my response after Dean's was directed to you not daddyd
Wondered about that. Thanks. I knew about the DSC not having the built-in automation, I just wanted to make sure the DSC security interface was as robust as it hasn't been around as long as Elk/HAI. I could see picking up a DSC just for security but I still think I'm leaning towards the Elk in case I wanted to have some more mission critical automation such as water leak detection to turn off the water supply. Of course, I've been thinking about upgrading my security system for over a year and it just hasn't been a priority yet. But there has been more discussion about DSC lately and I figured Dean's post was a perfect opportunity to ask about it.
Posts: 40,483
Threads: 491
Joined: Aug 2002
Since I'm sort of brain locked on the DSC I went to work on the Brultech GEM driver today. It was also a bit of a confusion for a while but I've got the guts of it working now and probably can finish it off tomorrow, then get back to the DSC if there's any info forthcoming to help me make some progress.
Dean Roddey
Explorans limites defectum
Posts: 40,483
Threads: 491
Joined: Aug 2002
I got a first cut of the Brultech GEM driver to Ron to test on. If he blesses it I'll put it into the next drop.
Dean Roddey
Explorans limites defectum
Posts: 2,339
Threads: 104
Joined: Apr 2009
dgage Wrote:Wondered about that. Thanks. I knew about the DSC not having the built-in automation, I just wanted to make sure the DSC security interface was as robust as it hasn't been around as long as Elk/HAI. I could see picking up a DSC just for security but I still think I'm leaning towards the Elk in case I wanted to have some more mission critical automation such as water leak detection to turn off the water supply. Of course, I've been thinking about upgrading my security system for over a year and it just hasn't been a priority yet. But there has been more discussion about DSC lately and I figured Dean's post was a perfect opportunity to ask about it.
DSC can also handle water leak, gas, and temperature but you are correct, the Power Series, what this driver is written for, is specific only to alarm, not automation.
Posts: 40,483
Threads: 491
Joined: Aug 2002
I did a documentation update today on the external web site stuff. I got the rest of the well documented device classes done, added more drivers that were missing or not updated to reflect their supporting V2 mode, and got some corrections in that Mark had made. Oh, and updated the CML socket classes docs to reflect the new realities of 4.5.5 and beyond.
Dean Roddey
Explorans limites defectum
Posts: 40,483
Threads: 491
Joined: Aug 2002
07-22-2014, 06:07 PM
(This post was last modified: 07-22-2014, 06:11 PM by Dean Roddey.)
I REALLY needed a break from driver stuff today, but wanted to do something that would make the remote driver writing/debugging process better since I'm going to be doing a lot of it for a while. So I added a simple chat capability to the remote port server. When doing remote serial port drivers, the person with the device already has to run the report port server and forward a port so that I can connect, so it's fairly easy to piggy back on that connection and provide chat capabilities.
That'll significantly streamline the process when I need to get information from the other side or get the other person to try something. E-mail is ok but not as convenient as a live chat type thing.
I got all the basics of it done today and it's chatting back and forth. I'll do some testing and refining and get a new drop out tomorrow since I also have other fixes that will make this next 4.5.7 drop and other one that folks can safely take up.
It's not instant fast, because it's using the ORB and that is strictly client/server. So the client (driver IDE) has to poll the server for msgs from the remote port server side, and I didn't want to do that too fast. So it just checks every five seconds, but that's fast enough for this purpose. I would have just used a socket, but that would have required another port being forwarded and I didn't want to complicate things. It's not like the messages have to fly back and forth instantly for it to fulfill its purpose.
I also updated it to accept a security key, but haven't implemented it yet. I'll probably do that tomorrow also. That'll be used to encrypt the communications. The person on the port server side can enter some arbitrary key and send it to me separately via e-mail. I can enter that on this side and it will be used to encrypt the information between the two sides, making it a lot more security, both from eavesdropping and also from someone port scanning and by some very rare coincidence knowing what he found.
Dean Roddey
Explorans limites defectum
