[RELEASE] Envisalink App & Driver for Vista/Ademco/Honeywell Alarm via smartthings-nodeproxy

@brianwilson worked like a charm. Thx so much!

I keep getting "unknown exception occurred while saving App code". Can you help this newcomer install your Envisalink app & driver. Currently using EL4 on DSC

Need more info; are you installing the native code or the one that uses smartthings-nodeproxy? What does the warning say - any line numbers? Screenshot?

Used URLs below for code- integration v 0.53 & driver v.0.8.3 from your Feb '19 post on this subject

New App import functions but Save results in "unknown exception..." message

Brian- my fault- bad raw URL- working now. Thanks

1 Like

Finally got a chance to troubleshoot the one issue I've had for some time. This may just be inherent to how to the panel functions, but wanted to get y'alls thoughts..

With the system disarmed, the motion sensors update as they should when seeing motion. However, when in armed-STAY, the status reads as "null" in the Hubitat device. Which sort of makes sense because motion is allowed in this mode. However, I can tell the alarm system itself still understands there is indeed motion because it shows a fault momentarily. So i'm not sure where the null reading is coming, or how to correct it, if even possible.

This is important because i would like to use the alarm system's motion sensors as a nightlight trigger after the alarm is activated. Thanks!

Do I need a SmartThings hub for node-red to work? Just trying to figure out all the steps.

you don't need SmartThings, but you do need everything else in the Redloro instructions (envisalink, node server, those are the main things).

Assuming that's what you meant by the "node-red" comment

Gotcha, the envisalink 4 is coming in tomorrow and I have a raspberry pi I currently use for PI-Hole and vpn server I can use. I also have 2 other raspberry pi's if that isn't an option for whatever reason. Since @doug left it's pretty confusing with all the links pointing to different threads on what is actually needed and how to install.

@doug is the author of the hubitat app for the DSC alarm panel. This thread started by @brianwilson is for Honeywell/Vista/others. Just wanted to make sure you're aware - two different Hubitat apps.

That said, just study the original ST post. At least that's what I did, like 30 times. The steps (1-15) he lists in the post should be the same for both ST and Hubitat.

2 Likes

Thanks, I think I have it setup as far as I can until I get the Envisalink 4 installed tomorrow.

Great feedback guys - I have updated post #1 to reflect Option #1 (Native) and Option #2 (Redloro's smartthings-nodeproxy). I've also provided links to the ST thread as well as the native integration "refugees" thread.

If you have questions about the smartthings piece, please put them here.

hey @brianwilson, any thoughts on my issue a couple posts up? Do you see this same issue?

I'll have to check next week as not at a place where I can test this.

1 Like

Hi Brian,
New user here wanting to integrate my DSC/Envisalink 4 with Hubitat for HA . Basically just want to tap into the sensor states (no need to arm or disarm since I handle that through the EyesOn app, keypads or Alexa...Alexa only for arming of course). Just for clarity, for DSC do I need to go with Option #1 only, or can Option #2 also handle DSC at this time (or is Option #2 strictly for Honeywell/Ademco/Vista panels).

Sorry for the noob question but I am concerned that @Doug left Hubitat native integration due to “stability” reasons and since others have said your integration (using rpi) has been solid, I was hoping to use your solution with my DSC panel. It also helps that support and development continues for Option #2 as well.

Any comments on how well the native integration works and problems with it (specifically stability and lag time) in comparison to your solution?
Also, if Option #2 has a driver for DSC, what model rpi are you using to run Smartthings Nodeproxy?
Thank you so such for any help you can give a noob!

I honestly don't know if Option #2 would support DSC, but from glancing at this thread I'm going to guess no.

I don't want to speak for @doug, but I believe his beef was with the Hubitat platform and the (still plaguing many) issue about hub slowness. I don't think there were any huge concerns with this integration, however, I cannot speak for if this integration may have caused his device to experience the sluggishness that caused him to leave. I do know people who don't run this still have sluggish devices. I do know that the native integration uses telnet and that the Envisalink device is super-chatty with it's communication.

My biggest concern at this time is getting as much processing as possible off of the Hubitat device itself and leave it to handle zwave, zigbee devices, run a few custom (but not resource-intensive apps). I don't consider Option #2 to be resource intensive and run this on my primary hub today. The other apps I run are things that interface directly with local services (some running on docker where the docker image is handling the heavy lifting) (Neosmart, Honeywell Option #2, Camect, Raincloud, Garage Doors Controller (ripped out MyQ Lite and my system got MUCH more responsive!)). The thought is to keep as much stuff off of the Hubitat device itself, but still keep it local (on my LAN). I'm also in the middle of moving many of my Rule Machine rules to Node-red to further compartmentalize things as to not impact CPU/Memory of the hub. It boggles my mind why Hubitat is continuing to release new devices with no apparent performance/rule processing upgrades. If there was a "pro" box or docker option, I'd keep everything there.

I think @doug had similar issues and went to go use Home Assistant. I like Hubitat and am more comfortable in Groovy, so I'm staying here. It also meets WAF much more so than HA.

Welcome to the club, hopefully I helped and haven't scared you away :slight_smile:

Sorry I haven't had a chance to look at this. I'll turn on debug logging to see if I can figure out what is causing it. I don't get a lot of chances to "play with the alarm" being stuck at home with other people, but I'll see if I can work some test time in.

Brian,
Thanks so much for your quick and detailed response! It’s members like you and others on this forum that also made me gravitate towards Hubitat due to your support over other hubs. Are you aware of any other Hubitat integrations that interface with a DSC/Envisalink combo that are NOT native to Hubitat in order to minimize Hubitat overhead? I could not find anything but I am of course new to all this. I really appreciate your contributions and support.

Glad to do it. I would try Option #1. Worst case scenario, you get slow-downs and you dedicate a Hubitat hub to your "things that slow down your main hub". I have an extra device specifically for this things like this. It may not impact your hub.

Also looks like there is an ST integration with AlarmServer that might work if you want to off-load the heavy lifting to another system. No idea if this works, but there might be someone on the ST forum that would have more info. If it does work, the code in that driver doesn't seem too complex, so it might port over without too much trouble.

UPDATE: You might try option 2 with DSC. I see code in the envisalink driver that mentions DSC. No idea if it works.

I checked tonight and there are no updates coming from envisalink when armed stay and there are motion events. In order to get them in Hubitat, the node proxy would have to see them and forward, but they aren’t there. Sorry.

1 Like