My DSC alarm has an Envisalink ethernet interface installed in it which currently allows me to control it very nicely as OpenHAB has a “binding” for it…
Having a similar “component” from Home Assistant would be a great first use case for me giving it a try… I only stumbled upon Home Assistant today 
I have motion sensors for the alarm in every room in the house and being able to tap into those and also control the alarm as a whole is a great feature.
+1 for a DSC (via Envisalink) component!!
This would open Home Assistant up to a much larger home automation community. I’ve use multiple HA platforms (HomeSeer, OpenHAB, Indigo), all having an interface to Envisalink. I’m not a developer, but thought I’d try porting the Envisalink plugin I’ve used for 3+ years… but found myself lost in learning Home Assistant and Python at the same time.
Maybe someone who knows Home Assistant could port this plugin. It’s written in Python for Indigo HA.
Envisalink Plugin
+1 for DSC/Envisalink. It is the only think making me hang on to my Vera system even though the plugin for Vera hasn’t been updated since 2014. It is also supported in OpenHAB so of course I tried that before being bogged down in configuration files.
I’m loving HA as it is pretty easy to get things working but DSC integration would be icing on the cake. Anyone keen to take up the challenge?
The actual issue with the integration of new devices is the lack of access to the hardware by people who are willing to do it. Of course, it’s possible to do some reverse engineering of an existing library but at the end you need the physical device to test your implementation.
Thanks for the prompt reply. Of course, understood. Is there a way I can allow you remote access to my hardware? Is that doable or of any benefit?
I’m currently contemplating buying either a DSC controller or a NX-8E (the latter of which is already supported by HA). I’d be happy to try writing software for the DSC if we go that route, but I’ve got zero experience with home security systems so I’m not sure how far I can get on my own.
Wow - this is very timely that people are asking about this. I have an EVL3 with a honeywell Vista20, and was just going to look into integrating with it (i’m a developer) in HA. I stumbled upon this because i was searching the forums trying to decide how to architect this integration.
There already exists a python project on github (HoneyAlarmServer) where this person has already essentially interpreted the low level TCP API of the EVL3 (TPI they call it), and exposed it as a REST webservice. A similar one exists for DSC (AlarmServer).
I’d like to do this integration- but it seems to me we have 3 options, and im struggling to decide which one to go with:
Rip out the raw TCP handling capabilities of these projects, put them into their own library, and use that directly in an alarm component.
modify these existing projects to work over MQTT instead, and we use the normal MQTT alarm component in HA
Implement a generic REST HA Alarm component, and use these 2 projects as-is.
Does anyone on the forums with more experience in HA have an opinion on the best way to do this? I’m leaning on option 2, as it would allow the alarm to actually raise an event within HA via MQTT, rather than do some sort of polling mechanism.
Hmm… I am curious…
Why not use VoIP that communicates with Asterisk and have Asterisk send MQTT commands?
https://groups.google.com/forum/#!topic/openhab/yWurUWdXKt0
I could do this with Elk M1 Gold, but I have never programmed MQTT before.
That was a great read- and I think it would be one way to handle this without writing any code (and if you haven’t bought any hardware to bolster the panels communication ability yet ). I think the reason we’d still want tighter software integration though would be that the envisilink evl3 reports on all the zone statuses, so you’re getting info even when the alarm isn’t triggered. It essentially mimics a keypad.
Hey Cinntax, I would go for option 1 or 2. Since you want to use zones as input (probably model them as binary sensors) option 2 will result in a lengthy config (one alarm mqtt, many binary sensor mqtts), option 1 probably the cleanest & most flexible.
I’m considering doing the same for my IDS panel, having all those inputs available would be great.
Thanks for the insight there- I also am not really a fan of adding extra services where not necessary either. So I’ve decided to make a go at option #1. I’ve cloned the honeywell version of the implementation, since it appears to be more complete/updated, but I’ll take the DSC logic as well once I can get the honeywell logic up and running (honeywell is what i have) The reason for the 2 sets of logic is because even though both panels run on the evl3, the protocol is different, but similar for each.
Great to see some traction, thank you very much. If I can assist with some testing on DSC/ELV3, let me know.
Sure- at this point i have a pretty well functional library for the Honeywell API at least (since i could test that). i have it stored at: https://github.com/Cinntax/pyenvisalink, on branch “migrate_asyncio”- i’ll have to merge back into master soon here. So i should now have some decent success with a HA component.
The library uses the asyncio libraries, which are now part of core python 3.4+. The idea is that this library will spin up a child thread that manages the communication with the evl, with fault handling,reconnections,etc. Whenever something interesting happens, a callback will occur, and the alarm component would then raise an event on the event bus.
If you want to help test on the DSC, that’d be awesome. Since I don’t have a DSC, it will be a little bit slow, but if we start with maybe implementing the login process, and then taking things one command at a time, we can get this going without too much hassle.
Ok getting closer- I have pushed my library to pypi (py envisilink). I am also in the middle of testing out my platform and binary sensor components (pretty cool). I should be ready for a PR within the next week or so I’m guessing. I still need to put together the alarm panel component and do some housecleaning (a LOT).
I’ve managed to integrate the envisalink with dsc alarm panels. You can test it out here:
https://github.com/srirams/home-assistant/tree/envisalink-dsc
Its a somewhat quick adaptation of the AlarmServer code but it exposes the dsc sensors as well as the partitions.
Cinntax: I can try to adapt the dsc code with your api (which, ultimately, would be a cleaner solution, I think), but the APIs seem to be quite different so I don’t know if the effort would be worth it.
Oh awesome- yeah i’ve pushed my latest up to https://github.com/Cinntax/home-assistant/tree/evl3 too (Sensor for the keypad/alarm panel to arm/disarm, and binary sensors for the zones).
Yeah I was kind of hoping we could get the DSC API integrated in with the external library too. I have at least taken a cursory look at the DSC API, and it does look like the commands themselves are quite different. I’m actually not worried about that, because i’ve properly abstracted that out. Even though the commands themselves are a bit different, I was thinking an abstraction could be made (send a command, alarm triggered, get zone timers, etc)- and the differences are hidden in the client for the DSC/Honeywell client files.
Yeah, looking at your code- it actually looks really familiar - it’s extremely helpful too BTW. The handle_line/format_event/send_command/handle_partition_state/etc. are pretty much 1 to 1 with what would need to be implemented in the pyenvisalink library. So while i think it would be probably too much to try to implement the ENTIRE DSC functionality, I think we can find a good happy medium. I also noticed when I was doing the HA components, that HA really doesn’t need the whole API anyway- I’m not even using the entire range of Honeywell functionality, much less the whole DSC functionality. So i’m encouraged by this! Mind if I take a crack at putting your client code into the pyenvisalink library? In terms of my HA components being PR ready, I have to handle connectivity/login failures, a small rework on the arm/disarm commands, and then formatting.
Looks like this:
Sure, that would be great! Let me know if I can help in any way.
There are some complications with arming (what do you do when you want to arm but the panel is not ready or there is a fault) that I’m not sure how best to handle.
I too have a Vista control panel but I can’t help but feeling I would be better off to rewire all the inputs (92% hardwired) to a raspberry and start over. I could have more inputs, finer resolution & more control for less than the cost of the adapter interfaces. Has anyone else done something like this?
Calvin
Sweet thanks- I’ve finally got the HA functionality basically ready for a PR- all that’s left is getting it to pass pylint (tedious, but simple).
In terms of handling an invalid state (like arming a panel that’s not ready)- I’m also not sure, as HA doesn’t really have a nice way of reporting such errors. So I suppose it’d be pretty easy to put that validation either in the library, or the component, there’s not much to do with it in HA.
With that, I’ve turned focus over a bit to the pyenvisalink library again. If you take a look here: https://github.com/Cinntax/pyenvisalink/tree/dsc/pyenvisalink , you’ll see I’ve added a dsc_client.py and dsc_envisalinkdefs.py files, as copies of my originals, and starting to substitute out your DSC version. I’ve found that panel arm/disarm/zonedump/keepalive is pretty easy. It really was 1 for 1. I also feel the login process will be slightly different but not difficult.
I fear that the rest of it may be more difficult to meet in the middle with the Honeywell version. I’ll pick it up again later in the week- or if you have any suggestions or want to take a stab, let me know!