DSC Server = REST + Envisalink + DSC

Devices & Integrations
1

I’ve begun developing an alternative to the python-based “Alarm Server” which I’m calling “DSC Server”. DSC Server will enable much simpler integration of DSC alarm systems with the SmartThings hub.

DSC Server will run on standard Windows hardware as either a simple Windows application or as an installed Windows service and will expose a REST API for integration with SmartThings. It will support arming and disarming, partition status, zone status, as well as contact, motion, smoke and CO sensors, and will support automatic sensor device creation within SmartThings.

Given my newness to the SmartThings side of this integration project, I’m looking to partner with community members on the development of the SmartThings LAN connected device types/smart app needed to make this successful.

If interested, either in using the completed integration, or in contributing to this integration project, please reach out via reply or PM.

1 Like
2

I would be super interested in using the completed software. In about 8 months I should have a new house built with a dsc system in it and I would love to integrate it easily with smartthings. Ideally, it would be written in something that I can throw on a synology nas, or my linux box in the basement and just forget about it (even better would be if it just ran on the smartthings hub, but that appears to be a pipe dream)

Thanks in advance.

3

I’m interested in cooperating on this project in principle. However, my requirements are that the ST-to-DSC bridge would work with IT-100 (serial interface) in addition to Envisalink and would run on a headless Linux box. I’m reasonably comfortable with both Python and Groovy and have done a few SmartThings projects: https://github.com/statusbits/smartthings/

4

zombiehoffa -

Just went through a similar process - new home construction with DSC wired system installed. Spent some time early on breaking out the 4 zones configured by the installer into more discrete zones - giving me greater flexibility for home automation. Installer took the easy route and configured all doors on a single zone - argh.

My background is in the Windows world, and so won’t be of much help to your Linux aspiration, but I’ll keep you posted on progress.

Good luck with your house build.

5

geko -

Given my background in the Windows world, Linux is a foreign concept to me. I’d be happy to share my experiences with you though.

6

It’s pretty easy to make something run on linux, you just need to write it in a cross platform programming language like python or java, or use C# that is compatible with mono. I was digging around a bit more to try and wrap my brain around what will be required to get this to work. Correct me if I’m wrong, but the only reason this won’t work on the hub is that the stuff smart things has exposed to developers isn’t powerful enough to be made to talk to the web api of the envisalink right?

7

zombiehoffa -

The Envisalink API is a much more low-level API as compared to typical web API’s. Although it is TCP-based, communication is via writing/reading directly to/from TCP sockets, not HTTP. Socket programming is considerably more complex. Given my limited knowledge of Groovy and my beginners knowledge of SmarThings development, I’m probably not the best one to comment on feasibility in this area.

8

@mbegala: What language are you planning to use? C# or C++? If you write the bridge in Python or NodeJS, it would be easily portable to Linux. Keep in mind that being a part of security system, it is critical that the bridge would be immune to power outage. If you plan to use Windows PC you’ll need a pretty big UPS.

9

Waiting for this to happen…

10

Just curious if you’ve seen this?

11

Anything you guys come up with I’m on board. I have a slower than molasses laptop with python ready to attach to my Envisalink but was really waiting for a simpler AIO solution if possible.

12

emilm -

Thank you for the link. I had not seen that project, and will have a look at it.

13

geko -

Thanks for the input. Development is being done in C#. Your post raises a good question about intended use of such an integration.

I can envision several use cases; ability to arm and disarm the system from within SmartThings, ability to be alerted to intrusions (in lieu of an alarm monitoring service), and exposing existing wired alarm sensors (door and window contacts, motion, smoke and CO) as SmartThings devices from which to trigger events.

A Windows platform certainly has its advantages and disadvantages. For me, it’s where my development background and experience is. Implementation details aside, I can see this evolving into a cloud-based offering that does not require dedicated in-house server/PC infrastructure.

Lot’s of work still to be done before thinking that far into the future.

14

Just curious if you’ve seen this?
GitHub - obycode/DSCAlarmSmartThings: DSC Alarm interface to SmartThings

It’s a nice project, no doubt, but…

  • DSC Alarm System
  • IT-100 interface
  • Arduino MEGA
  • Arduino RS232 shield
  • Arduino SmartThings shield

That’s a pretty thick “sandwich” just to get to the ST hub. :smile:
I’m thinking more along the lines of:

[DSC] <=> [IT-100] <=> [Serial Bridge] <=> {ST Cloud}

or

[DSC] <=> [Envisalink3] <=> [Ethernet Bridge] <=> {ST Cloud}

I.e. only 3 layers instead of 6 and bypassing ST hub. This is pretty much how DSC Alarm Server integration works now, but it’s kind of a kludge because it wasn’t designed specifically for ST and it does not support IT-100 serial interface. I prefer serial over Envisalink because it does not expose your alarm panel to hacking from the LAN (Envisalink LAN-side security is pretty weak).

A bridge can be either written in Python and run on an old laptop (takes care of the power outage) or it could be done as an embedded WiFi module and powered from the alarm itself.

Anyone interested in pursuing this project?

15

My primary interested in the ‘thick’ sandwich is to eliminate the laptop dependency. There is no right/wrong way of doing this - but, since I am a programer Newbie; I don’t have the ability of doing this on my own. So, I am just watching and learning.

I now have everything except the IT-100 - - so, I should be able to give this a try soon.

16

geko -

Agree, these are two valid options.

Just out of curiosity, what do you see as the security risks with Envisalink? Envisalink’s TCP connection, which the DSC Server talks to, is only exposed on the home owners LAN. Are the concerns with someone hacking into the home owners LAN, and then gaining access to Envisalink’s TCP connection? Appreciate the insight.

17

Beginning to consider designs for the SmartThings device types and SmartApp. Questions, comments and suggestions are greatly appreciated.

Over the next day or two I’ll be posting the REST API design for comments and suggestions as well.

Questions to Ponder:

  • How critical is the notion of a security alarm partition? How prevalent are multi-partition residential alarm configurations?
  • Is categorizing each zone as contact, motion, smoke or carbon monoxide a valid approach? Are alarm systems configured such that a given zone will mix these sensor types?
  • Is it valid to leverage smokeDetector and carbonMonoxideDetector capabilities even though the “tested” state may not be applicable in an alarm system?
  • In my current prototype of DSC Server and my SmartApp, I’m using UPnP SSDP M-SEARCH for discovery. Is there a more appropriate way to discover a DSC Server?
  • Other things to consider?

Device Types

Security System

 - capability: securitySystem
 - attribute: state  — ["trouble", "ready", "not ready", "armed away", "armed stay"]
 - command: disarm()
 - command: armAway()
 - command: armStay()

Security Contact Zone

 - capability: contactSensor
 - attribute: contact  — ["open", "closed"]
 - command: none

Security Motion Zone

 - capability: motionSensor
 - attribute: motion  — ["active", "inactive"]
 - command: none

Security Smoke Zone

 - capability: smokeDetector
 - attribute: smoke  — ["tested", "detected", "clear"]
 - command: none

Security Carbon Monoxide Zone

 - capability: carbonMonoxideDetector
 - attribute: carbonMonoxide  — ["tested", "detected", "clear"]
 - command: none

SmartApp

DSC (Connect)

  • Ability to discover DSC Server on home owner’s LAN
  • Ability to request system, partition and zone configuration from DSC Server
  • Ability to select zones to be instantiated as SmartThings things
  • Ability to create SmartThings things for each selected zone
18

Problem is, you cannot define custom capabilities. I’ve requested an “Alarm Panel” capability some time ago, but got no response:

So, you’ve got to work with what’s currently defined. You can add your custom attributes and commands, of course.

19

geko -

Any luck getting custom device capabilities to work as per http://docs.smartthings.com/en/latest/introduction/what-can-developers-do/capability-taxonomy.html? Although not part of the standard taxonomy, would this work for the purpose of self published devices?

Excerpt:

Custom Capabilities
If you are integrating or building a device that requires a capability that isn’t listed here, no problem! You can add a custom capability to the platform yourself, and we will then look for common threads across new custom capabilities in order to determine which ones should be made part of the standard taxonomy.

20

I think I tried and got an exception. I’ll double-check.

With regards to your questions, here’s my 2c:

  • How critical is the notion of a security alarm partition? How prevalent are multi-partition residential alarm configurations?

I don’t think its typically used, unless you have a three-story mansion :smile:

  • Is categorizing each zone as contact, motion, smoke or carbon monoxide a valid approach? Are alarm systems configured such that a given zone will mix these sensor types?

One sensor per zone is fine, or multiple sensors of the same type (e.g. two bedroom windows). Mixing different types is not good because of different arming conditions. E.g. smoke/CO sensor should always be armed.

  • Is it valid to leverage smokeDetector and carbonMonoxideDetector capabilities even though the “tested” state may not be applicable in an alarm system?

Yes, it’s best to stick with pre-defined capabilities where possible rather than creating new ones.

  • In my current prototype of DSC Server and my SmartApp, I’m using UPnP SSDP M-SEARCH for discovery. Is there a more appropriate way to discover a DSC Server?

You have tree choices: SSDP, Bonjour and manual IP entry.

  • Other things to consider?
  • Ability to report zone ready/not ready status
  • Ability to bypass zones
  • The Alarm Panel device should also expose ‘alarm’ capability to allow any existing SmartApp to trigger panic alarm.
  • The alarm smart app should allow arming/disarming by changing home Mode (see my SmartAlarm app). This allows automatic arming/disarming by executing Hello Home actions.
1 Like