[OBSOLETE] Honeywell / Ademco Vista 20P Integration

@blambert512 welcome and glad to hear you’re interested in getting this up. Not sure what this could be but we should be able to figure out pretty easy… couple of questions:

  • What OS are you running STNP?
  • What is the output when you type node -v from the command line?
  • Can you confirm that you did the following?
  • installed node from: https://nodejs.org/en/download/
  • downloaded all smartthings-nodeproxy files from github
  • did a node -install
  • moved only envisalink.js into the plugins directory?
  • Can you share your config.json file via pm?

Thanks!

Thank You! You have already solved my problem. I had a node version installed from another site. I uninstalled it and installed as you noted in your message and now everything is working great.
Thank You, thank you, thank you – this is great.

Great code you have written here. I bought an EnvisaLink 4 just to use this so thank you very much in advance! I think I may be having the same issue that Brett_Weeden had or similar. I believe my Node Proxy, running on a Raspberry Pi 3 on Raspbian, is communicating with the EVL 4. When I run “node server.js”, I am getting the following:

pi@raspi:~/smartthings-nodeproxy $ node -v
v0.10.29
pi@raspi:~/smartthings-nodeproxy $ npm -v
3.10.9
pi@raspi:~/smartthings-nodeproxy $ node server.js
SmartThings Node Proxy listening at http://0.0.0.0:8080
Loaded plugin: envisalink
Connected to Envisalink at 10.0.1.41:4025
{“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED CHIME Ready to Arm”}

If I open my front and back door, they are logged by node. However, when I navigate to the http://0.0.0.0:8080/ url in a browser, I get the following reported from node:

127.0.0.1 GET /favicon.ico
Authentication error

In the browser, it says:

{“status”:“SmartThings Node Proxy running”}

I have added the Envisalink.js file to the newly created Plugins folder and tried multiple versions of my config.json file. I have attempted to discover the zones via the proxy as well as configuring them manually. No change in the above behavior. I also have installed the app with added Device Handlers just to see what would happen, but no dice. I have also rebooted my SmartThings Hub several times. Any insight you have would be greatly appreciated.

Here is the last version of my config.json with passwords blocked out.

{
“port”: 8080,
“authCode”: “*********”,

“envisalink”: {
“address”: “10.0.1.41”,
“port”: “4025”,
“password”: “**",
“securityCode”: "
”,

"panelConfig": {
  "type": "discover",
  "partitions": [
    {"partition": 1, "name": "Security Panel"}
  ],
  "zones": [
    {"zone": 1, "type": "smoke", "name": "Smoke Detector"},
    {"zone": 2, "type": "contact", "name": "Front Door"},
    {"zone": 3, "type": "contact", "name": "Back Door"},
    {"zone": 4, "type": "contact", "name": "Kitchen Door"},
    {"zone": 5, "type": "contact", "name": "Kitchen Window"}
  ]
},
"installerCode": "****"

},

“notify”: {
“address”: “10.0.1.33”,
“port”: “39500”
}
}

@awadswor thanks for reaching out and appreciate your excitement to get this working…

Here are some suggestions to help you… please try and report back.

  1. Stop the SmartThings Node Proxy service.
  2. Replace your config.json with the one included below.
  3. Start SmartThings Node Proxy.
  4. Walk around the house, open doors, etc and make sure that the status/updates are showing in the log file/console.
  5. Delete all your devices that you may have manually added… these need to get added automatically by the SmartApp
  6. Go to your SmartApp and configure… send me a screen shot of the SmartApp configuration screen.
  7. Hit Done/Save
  8. Check the SmarThings Node Proxy log file/console… you should see something that says Completed panel discovery… if you see this message go to step 9… if you do not, then something is messed up with the SmartApp configuration.
  9. Count to 30… now go to your Devices tab and pull down/refresh… you should see all your devices/sensors… if you don’t something is still not right… reach out to us on the forum!
{
    "port": 8080,
    "authCode": "*********",
    "envisalink": {
        "address": "10.0.1.41",
        "port": "4025",
        "password": "******",
        "securityCode": "****",
        "panelConfig": {
            "type": "discover",
            "partitions": [
                {
                    "partition": 1,
                    "name": "Security Panel"
                }
            ],
            "zones": [
                {
                    "zone": 1,
                    "type": "smoke",
                    "name": "Smoke Detector"
                },
                {
                    "zone": 2,
                    "type": "contact",
                    "name": "Front Door"
                },
                {
                    "zone": 3,
                    "type": "contact",
                    "name": "Back Door"
                },
                {
                    "zone": 4,
                    "type": "contact",
                    "name": "Kitchen Door"
                },
                {
                    "zone": 5,
                    "type": "contact",
                    "name": "Kitchen Window"
                }
            ]
        }
    },
    "notify": {
        "address": "10.0.1.33",
        "port": "39500"
    }
}

Oh and btw… the good news is that this shows that your SmartThings Node Proxy is configured correctly to talk to the EVL… I suspect there’s an issue with the config of the SmartApp. Let me know…

Thanks for getting back to me so quickly. I switched out to your config.json and restarted node. It is registering sensors from the EVL 4. FYI - the IP of the EVL 4 has changed so I updated that everywhere as well.

pi@raspi:~/smartthings-nodeproxy $ node server.js
SmartThings Node Proxy listening at http://0.0.0.0:8080
Loaded plugin: envisalink
Connected to Envisalink at 10.0.1.44:4025
{“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED CHIME Ready to Arm”}
{“type”:“zone”,“partition”:1,“zone”:2,“state”:“open”}
{“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 02 BACK DOOR”}
{“type”:“zone”,“partition”:1,“zone”:2,“state”:“closed”}
{“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED CHIME Ready to Arm”}
{“type”:“zone”,“partition”:1,“zone”:4,“state”:“open”}
{“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 04 FRONT DOOR”}
{“type”:“zone”,“partition”:1,“zone”:4,“state”:“closed”}
{“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED CHIME Ready to Arm”}

I didn’t manually add any devices in SmartThings so there are none to remove unless you meant to remove them from the config.json and I misunderstood. I do not see the message “Completed panel discovery” in the console. Here is the configuration of my SmartApp.

I can only post one image per post since I am new so here is the other half of the configuration.

Trying to get this working on my Synology NAS and am getting this error:

[code]SmartThings Node Proxy listening at http://:::8080
/volume1/Downloads/scripts/Smartthings_Node_Proxy/plugins/envisalink.js:5

^

SyntaxError: Unexpected token <
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.Module._extensions…js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
at /volume1/Downloads/scripts/Smartthings_Node_Proxy/server.js:83:35
at Array.forEach (native)
at /volume1/Downloads/scripts/Smartthings_Node_Proxy/server.js:81:6
[/code]

Any ideas? Thanks for all of the work on this.

@awadswor did you mean to leave “Proxy Address” set to 0.0.0.0?? Cause that would be your problem… you need to set that to the address of the RPi where you are running SmartThings Node Proxy. I guess for clarity it should read “SmartThings Node Proxy Address”.

So set that and hit done and let us know what happens…

@thedude130 How did you pull envisalink.js from GitHub? It looks like you may have copied down an HTML doc containing the plugin source and not the actual source file.

Make sure that the envisalink.js file looks just like this one:
https://raw.githubusercontent.com/redloro/smartthings/master/smartthings-nodeproxy/avail_plugins/envisalink.js

Yep, that was it. I was just coming back to post that I was good to go but you beat me to it. Thank you for this again!

That was it. Lack of sleep I think. Got everything running now it it looks great! Now I just need to figure out how to make sure the server starts automatically with my NAS. Thanks again!

Now I have a new issue. When a contact sensor is opened, it won’t show closed again in the Smartthings app until all faults are restored. For example:

Scenario 1: Open only back door, app shows only back door open. Close it, and the app shows closed. This is normal.
Scenario 2. Open back door and front door. App shows both open. Close back door, both still show open (not normal). Close both doors, both show closed.

Everything works normally at the Eyez-on site and at the alarm keypad. Any ideas? Here’s a log for scenario 2:

2016-10-31T17:06:06-0500 {"type":"zone","partition":1,"zone":3,"state":"open"}
{"type":"partition","partition":1,"state":"notready","alpha":"FAULT 03 BACK   DOOR"}
2016-10-31T17:06:07-0500 {"type":"zone","partition":1,"zone":18,"state":"open"}
2016-10-31T17:06:07-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 18 KITCHENMOTION"}
2016-10-31T17:06:09-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 03 BACK   DOOR"}
2016-10-31T17:06:10-0500 {"type":"zone","partition":1,"zone":17,"state":"open"}
{"type":"partition","partition":1,"state":"notready","alpha":"FAULT 17 LIVING ROOM MOTION"}
2016-10-31T17:06:12-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 03 BACK   DOOR"}
2016-10-31T17:06:18-0500 {"type":"zone","partition":1,"zone":1,"state":"open"}
{"type":"partition","partition":1,"state":"notready","alpha":"FAULT 01 FRONT  DOOR"}
2016-10-31T17:06:21-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 03 BACK   DOOR"}
2016-10-31T17:06:25-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 01 FRONT  DOOR"}
2016-10-31T17:06:29-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 03 BACK   DOOR"}
2016-10-31T17:06:33-0500 {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 01 FRONT  DOOR"}
2016-10-31T17:06:46-0500 {"type":"zone","partition":1,"zone":1,"state":"closed"}
{"type":"zone","partition":1,"zone":3,"state":"closed"}
{"type":"zone","partition":1,"zone":17,"state":"closed"}
{"type":"zone","partition":1,"zone":18,"state":"closed"}
{"type":"partition","partition":1,"state":"ready","alpha":"****DISARMED****  Ready to Arm"}

Yep… this is a known issue and a huge problem with the Honeywell panels… they don’t accurately report zone close events if there is a system fault or other open zone. But… since you’re not the first to report this and I’m not one to give up, I’ve updated the envisalink plugin to handle zone close events as accurately as possible and even added a polling mechanism as backup.

Basically I’ve added three checks (in order of detection speed) to make sure that we detect closed zones…

  1. If a zone is no longer flagged in the alarm keypad, we assume the zone is closed.
  2. If a zone is marked closed in a zone state change event, we assume the zone is closed. Note that these events are random at best and are not accurate.
  3. Poll every 30 seconds and determine if there are any zones that have been closed that we did not catch with #1 or #2.

Pretty sure this will resolve all issues related to zones staying open… I’m testing these fixes over the next day or so to make sure it works before pushing to GitHub. I’ll drop an update when the code is ready to download.

Thanks.

@redloro Interesting post. I started on different thread then I found yours. After two day’s I see this is the one with activity. Without having to read the whole thing Using existing Home Security System (Honeywell, Vista, etc) Sensors with Smartthings here is my post …

Let me set the stage for few more questions …
About a month ago I updated my Honeywell alarm to cell technology. I was discontinuing my land line, so I upgraded my panel to one that would work with 3G. I am in good with the dealer who monitors the alarm. He was straight up about the limitations on Tuxedo. I was more interested in security than HA, well till I started playing with HA, I really like it. Also it can be kind of addictive. Current my biggest hole is Tuxedo does not support multi-channel devices. Of course it would be nice if it supported IP devices and Echo, but Tuxedo has some voice commands. My installer suggested to turn voice commands off till the next update. He gave me a smoking deal on the controller, thermostat, and garage door interface. I have added several light devices.

Now we have purchased a new house, that was built about a year ago and is on the market because the owers were transferred. It is a clean slate, no smart devices, including thermostat, and no alarm.

Still I would like a monitored alarm, but would like a more HA mature controller.
My 30,000 foot understanding, The EnvisaLink looks like another alarm control panel to the Honeywell alarms. Basicly using a PI as bridge between EnvisaLink and smarthings.
Correct?
My second, maybe should have been first, question… Am I in the right place?

Welcome @penright… That is correct… per the diagram in the first post under FAQ the Envisalink attaches to the Honeywell alarm and IP-enables it… that’s all. The RPi (or other device) running SmartThings Node Proxy acts as a bridge between the Envisalink and SmartThings.

I recently had the weirdest error, I don’t know if anyone else experienced it. Everything works fine then I noticed that my sensors are not polling from smartthings for over a day. Then I checked if I can still arm and disarm from SHM and it still works. However none of my sensors are registering if they are close or open. Then I checked the security panel under Things and that is also not registering if it is “ready to arm, arm, or fault”. The crazy thing is if I hit arm or disarm it still works. Then I checked the logs and evl4 is working properly with the proxy and reporting if zones are breach. So I concluded that it had something to do with the smart app. I removed the app and reinstalled it and to my dismay nothing show up. I freaked out a little bit, and after an hour of tinkering with it I went to sleep. This morning when I reinstalled the app again, everything came back to normal. I’m still clueless to what the heck happened.

Not sure… I’ve seen where the hub gets into a weird state and stops processing inbound notifications… and what I’ve done before is actually power-cycle the hub to get things back to normal. Maybe waiting had the same effect?

Hey lemme know if you want some help QA’ing your new zone close fix, I’m excited to help :slight_smile:

Thanks @Big_Webstas… it’s ready. You can download the latest here: https://raw.githubusercontent.com/redloro/smartthings/master/smartthings-nodeproxy/avail_plugins/envisalink.js

Please give it a go and let me know what you find. To install, follow these steps:

  1. Stop SmartThings Node Proxy
  2. Replace plugins/envisalink.js with the new one
  3. Start SmartThings Node Proxy

NOTE: Due to known limitations with the Honeywell panels, the EVL tries its best to determine when a zone is closed when the panel is in fault mode, but the reporting is not accurate nor always correct. If you have many zones open, you may see a zone temporarily report closed, but then switch back to open. In general it works really well and you may never run into a false positive… just keep this in mind as you build out your HA routines.