I’m beginning to agree - only problem is if I fork out a lot for a new Honeywell Alarm I can;t take it with me when I go …
One item of note to those who haven’t bought a panel yet- just a note that, between Honeywell and dsc, in terms of operability with the envisalink devices- dsc does a better job. There is an inherent limitation with the Honeywell boards where they don’t report zone closures immediately like they do for zone openings/trips. For closures, we have to rely on the “last tripped time” to determine if a zone closed or not, and it’s not ideal (enough to keep your house secure at least though). With dsc panels on the other hand, the whole api that the envisalink devices provides is more complete, and has a greater “richness” to the info it exposed. I’m using Honeywell because the house came with it, but dsc is a better choice in panel from what I’ve seen. Not sure if there are other reasons Honeywell may be better than dsc…
2 Likes
Thanks - good information 
Then I will go with the DSC. Thanks for letting me know!
Plus, when it comes to IoT, my data belongs to me and not in the cloud. And IoT companies never thought about security and privacy when it comes to data breaches.
Even if a Radio Thermostat CT80 is not a learning thermostat, it’s still way better than Nest. Actually, Home Assistant could function as a learning thermostat for controlling CT80. Plus, if the Internet goes down, the CT80 still works with Home Assistant. However, I’m not going to go off-topic here
I think Home Assistant is perfect, but still got ways to go, what with implementing support for Insteon PLM.
Quick question guys. I have a DSC PC1832 alarm system setup but yet to buy the envisalink card.
ALL of my sensors are wireless back to the alarm system. Will I still be able to see all the zones etc in HA?
You should be able to once you add all the wired and wireless zones to your YAmL config file.
I don’t have DSC and Envisalink, so it’s the least I can help.
envisalink (and verisure) is why i got myself a pi and Home-Assistant. Tried it, working great with dsc. Thank you and all contributors for making this happen.
I have one request for envisalink. Is it possible to do an ignore/drop list for various unwanted codes. Code 510 is really annoying because it’s sent every time motion-detector or door-magnet is triggered and in developertools/devinfo gets flooded with no handler/callback.
Great work Cinntax! Works like a charm. Now taking the time to figure out how best to use all this new functionality. Thanks for all your work. One question you mentioned an error earlier in the thread about 673, 841 and 510 event handlers. Are you working on a fix? What are those events?
Thanks everyone- I’m glad it’s working well for everyone. In terms of those errors- right now we’re taking action on roughly 80% of the dsc api… Those events you mention have to do with updating the “error leds” of the dsc. I could see implementing that in the future- most likely updating the sensor with that information- but needed to get that first release out.
1 Like
Does anyone have a pic of what this looks like on HA? 
Cinntax - error info would be really useful let me know if I can be of any help.
So anyone can help me how do setup automation like when I arm the system turn on the IP camera and when I disarm then turn off the camera? I have Wink hub and switches to turn on/off camera. I am new to HA so please help me. Thanks a lot.
So there may be another way to do this, but you could probably use an automation- like so:
automation:
trigger:
platform: state
entity_id: alarm_control_panel.panel
state: 'armed_away'
action:
service: homeassistant.turn_on
entity_id:
- switch.ip_cameraPerfect, I will try this and come back to report it how it goes, thanks a lot.
I got it working and I am very much happy with it. Thanks a lot for good work, appreciate it.
Only improvement I wish is to remove those warning/information “No handler defined in config for …” and
“No handler configured for evl command…” from the log to keep it clear to find real error easily.
One more time appreciate your work and thanks a lot.
Sure- yeah seems like that’s the most common issue at the moment (pretty happy that THAT is the issue ). I’ll see what I can do to turn those down in the near future.
In terms of handling more of the DSC API (like the status LED’s)- it actually looks like I have variables for them already in my sensor component. On the honeywell side of things I do have a callback for general “non alarm/non state change” events, so I could probably handle some of these other events in there to give some more data.
As was recommended earlier, I could technical represent those status LEDs as binary sensors, but thought it’d be confusing since we’re already using binary sensors for the zones. Does anyone care if we split that out? Or is it sufficient just to represent the DSC status LEDs as an attribute of the existing sensor?
I sugest that you do it the way you seem fit best. This is what i seen so far not handled i logs.
510 Keypad LED State
511 Keypad LED FLASH state
673 Partition is Busy
700 User Closing
840 Trouble LED ON
841 Trouble LED OFF
Latest DSC API is 1.07 from June 1st, 2016, if you need it it’s on eyes-on forum Link to post
Let me know if can help more
Cinntax. I agree with Yada - whatever works best for you and ease of coding. I think it would probably look cooler if the error codes were separate from binary sensors but to be honest Home Assistant is so configurable in terms of the grouping and layout it doesn’t really matter.