[OBSOLETE] Honeywell / Ademco Vista 20P Integration

SmartApps & Automations Community Created SmartApps
, , , ,
1253

Really need some help here. I’ve had this running for quite some time and it is by far my favorite SmartApp. However, it does not work properly when the CHIME function is enabled on my Vista and I really need to turn CHIME back on (wife says so).

Does anyone have this working and integration with SHM enabled while also having CHIME turned on??

With CHIME enabled, the SHM integration stops working. I can post the strange message in the STNP tomorrow when I can enable CHIME without making noise and waking the baby.

I’d love some help if this is an easy fix, or I’d be happy to fund someone to figure this out and provide a solution.

1254

The error I get in STNP when I have CHIME enabled is this:
“Error: ignoring invalid data format from Envisalink: 01, 1C28, 08, 00, House CHIME, Rdy to Arm”

Can someone please help with this?

1255

I don’t use this integration with my Envisalink, so I wish I could help, but as a workaround do you have any Alexa devices? We use those to chime whenever a door or window opens, like our panel does. My wife eventually got use to it, and we’ve never turned on chime again on the panel. Downside would be the dependency on the cloud…

1 Like
1256

That comma in the alpha string on your keypad looks like it’s the culprit. As a quick and dirty fix, try changing line 276 of envisalink.js from:

if (map.length != 5 || data.indexOf('%') != -1) {

To:

if (map.length < 5 || data.indexOf('%') != -1) {
1 Like
1257

I have had this issue with several doors. I have re-opened them to try to get the status to update. Only noticed this the past few days.

I used PM2 to run this on my raspberry pi, so o can’t look at the logs anymore to see what might be going on.

Maybe related to network traffic issues as I you have to go to envisalink and back then to smartthings?

Not sure…but I def have the same issue.

1258

i like this integration, but there’s a lot of potential failure points and no failure notifications when something stops working. you just have to notice it yourself.

to troubleshoot your own issue, you’ll probably have to start isolating the variables.

first, check your panel. Any trouble codes? That can prevent zone status updates.

then check the Eyezon site or app. Does it receive your zone updates? if so, good. if not, check the EVL device by entering the IP of it and logging in.

if that’s working fine, check any logs you might have from PM2. if none, then try stopping the process and restarting it. might help to run it from the shell for now so you can see the outputs.

1259

Dude, you’re a genius! That actually fixed it and I am ecstatic!! Love this SmartApp and now I can enjoy it and have my Chime too. Thank you for taking the time to help me out!! Let me know if there’s anything I can do to repay your kindness.

1 Like
1260

I found a solution that will let you know via SMS if STNP is not able to communicate with the ST hub (instead of you happening to notice your sensor statuses are incorrect).
If you are familiar with AWS , there’s a Cloud Formation stack available that runs a lambda function triggered by an HTTP request. The lambda function sends a notification to a SNS queue which you can subscribe your mobile phone number for SMS alerts. On your STNP server.js code, just add a few lines to make an HTTPS call to your AWS endpoint when it encounters an error. Make sure you build logic around it to call the endpoint only once, otherwise you will get bombarded by texts every few seconds STNP is unable to connect.

1261

Anyone having an issue with ST not receiving the information from the server? The “Honeywell Security” devices are seeing the device status properly, but when I do live logging, I’m not seeing the activity reaching ST. The reason I know there is an issue is I have a sensor programmed into WebCoRE and nothing was happening. WebCoRE can see the devices, but it’s not seeing activity, which makes sense based on the live log on ST. Just started doing this within the last day. Tried a re-boot of both ST and the server, still doesn’t solve it.

1262

Same here. Just checked and there is indeed no activity recorded on live login. When I look at the motion device itself on the ST server, it does report the status (active or inactive) accurately.

1263

I can get the Honeywell Security device to see everything, but that’s it. I looked at the older logs, it looks like it last reported around 9 AM Pacific this morning. No modifications before this and I’ve been running this for years…

1264

The device handlers don’t have any code in them to post anything to live logging, and almost all of the log lines in the smartapp are commented out. Unless you’ve added log lines to the code yourself, I wouldn’t expect to see anything show up in live logging.

When you say that the Honeywell Security device is working, do you mean the partition device in the ST app? Are the individual sensor devices showing status properly in the ST app?

1265

The Honeywell Security “thing” that’s listed in the things list. Yes, individual sensors are showing the current status in the ST app (e.g., if a window is open, I can see that status).

Update:

Philh30: You are indeed correct about the live logging. The problem has been found. It has to do with me bypassing a zone. For whatever reason, bypassing a zone disables using this integration with ST’s and WebCoRE. Now that I think of it, I’ve seen this happen in the past. Once the zone was un-bypassed, the integration worked again.

1266

What happens if someone turn on switch 2 or switch 3 in ST App? Wouldn’t it go in an infinite loop?

1267

I’ve redone those pistons in WebCORE and use only one now. Basically, I use WebCORE primarily for communication between the panel and the virtual switches in ST App. I have Automation in the new ST App to manage the virtual switches and the STHM.

I’ve attached copy of that new piston below. So far, so good.

image
image1178×1160 57.4 KB

1269

How to configure NEW SmartThings App and Integrate with SmartThings Home Monitor

Update the Handler in SmartThings:

  • Login to your SmartThings account and go to My Device Handlers
  • Click and open Honeywell Partition
  • Add the following lines in the definition:
    attribute “dscpartition”, “String”
    attribute “panelStatus”, “String”
  • After you add it should look like this.
  • image
  • You are done on the handler.

SmartThings App:
Create 2 virtual Switches in SmartThings and update webcore to give it access to the switches and your Honeywell Keypad.
I named my switches the following. I will refer to them later on for mapping.

  • Switch ArmStay
  • Switch ArmAway

WebCore:

  • Go to https://dashboard.webcore.co/

  • Click New Piston and “Restore a piston using a backup code”

  • Use the following backup code m2wf
    image

  • Click the Devices and update them accordingly.
    Switch 2 --> Switch ArmStay
    Switch3 --> Switch ArmAway
    Keypad1 --> Your Keypad

Considerations:
You cannot Arm/Disarm using the SmarThings Home Monitor. You will have to use the switches you created but STHM will be updated to reflect the status of your Alarm Panel.

This is my setup and it could be yours with or without modification.
Thanks @Francosino for starting the Piston.

1270

I’ve been having some issues with SmartThings not updating the status of a sensor properly, or rather it sees them stuck in an open state, when they are in fact closed. Actuating them again sometimes reset them, but it’s not long before they get seen as stuck again.

It’s been happening mostly with my doors, but I’ve also seen it happen with some windows and even a motion sensor. I confirm that the EVL or Vista is not seeing these in a perpetual open state, so the problem must be with SmartThings not getting the message.

I am seeing a lot of “[stnp] Notify error: Error: connect ETIMEDOUT 192.168.1.21:39500” in my past logs and the console if I run it within there. Not sure if that has anything to do with my issue.

I just tried restarting my stnp service and will try to reset my sensors back to normal and see if this happens again, but it’s been quite annoying

edit:
i restarted STNP, verified it was running, then tried opening my door. it showed as opened right away in ST and on my panel keypad, and then i closed it which is reflected in this log, and in my panel, but ST still shows it as opened.

[2020-05-21T16:26:34.026Z] [stnp] SmartThings Node Proxy listening at http://:::8080
[2020-05-21T16:26:34.059Z] [stnp] Loaded plugin: envisalink
[2020-05-21T16:26:34.066Z] [evl3] Connected to Envisalink at 192.168.1.40:4025
[2020-05-21T16:26:42.308Z] [evl3] {"type":"partition","partition":1,"state":"ready","alpha":"****DISARMED****  Ready to Arm"}
[2020-05-21T16:27:53.718Z] [stnp] ::ffff:192.168.1.53 GET /favicon.ico
[2020-05-21T16:27:53.720Z] [stnp] Authentication error
[2020-05-21T16:28:09.805Z] [evl3] {"type":"zone","partition":1,"zone":5,"state":"open"}
[2020-05-21T16:28:09.808Z] [evl3] {"type":"partition","partition":1,"state":"notready","alpha":"FAULT 05        GARAGE DOOR"}
[2020-05-21T16:28:12.868Z] [evl3] {"type":"zone","partition":1,"zone":"5","state":"closed"}
[2020-05-21T16:28:12.870Z] [evl3] {"type":"partition","partition":1,"state":"ready","alpha":"****DISARMED****  Ready to Arm"}
[2020-05-21T16:28:49.560Z] [stnp] Notify error: Error: connect ETIMEDOUT 192.168.1.21:39500
[2020-05-21T16:30:17.077Z] [stnp] Notify error: Error: connect ETIMEDOUT 192.168.1.21:39500
[2020-05-21T16:30:20.117Z] [stnp] Notify error: Error: connect ETIMEDOUT 192.168.1.21:39500
[2020-05-21T16:30:20.118Z] [stnp] Notify error: Error: connect ETIMEDOUT 192.168.1.21:39500
1271

Your work on this piston showed that my earlier version was missing the part for direct panel input to turn off the virtual switches off when disarming. I have modified my piston accordingly and that addressed the issue. Thank you.

1272

i’m getting the same timeout errors… seems to be a problem with the hub if you ask me.

1273

Are only a few having the timeout error problem.