[OBSOLETE] Honeywell / Ademco Vista 20P Integration

Glad to hear it’s all working…

If the Alexa integration depends on switches, etc then you should either be able to modify the existing Honeywell Partition device type to support a switch or just create a separate device type that implements the switch.

PSA: @got_toys found a bug with the Honeywell Partition device type where the Instant Arm and Chime functions weren’t working properly. Uploaded the fix to the device type in github; feel free to pull the latest from here:
https://raw.githubusercontent.com/redloro/smartthings/master/devicetypes/redloro-smartthings/honeywell-partition.src/honeywell-partition.groovy

Fixed!! Thank you!

Has anyone also noticed that when state.alarmSystemStatus = “away” fires, if ST detects presence within the location SHM actually goes into Armed(Home) instead not Armed(Away) ?

I’m testing adding a delay in setting SHM into AWAY… otherwise the Alarm panel is counting down giving 60 seconds to vacate but SHM is immediately activated, not giving time to vacate. I’m testing using the method runIn().

section(“Smart Home Monitor - Arm Away Delay”) {
input “smhDelay”, “text”, title: “Delay In Seconds”, description: “Delay Smart Home Monitor is Armed by Panel Arm”, required: false, defaultValue: 60
}

runIn(smhDelay, state.alarmSystemStatus = “away”)

I think the delay will fix both conditions noted above.

@azbutz, I just ran a test using SHM and 3 of the 4 people with presence at my home are showing “present.” I then tested your theory about setting alarm to “Away” while there ST detects presence and my house still armed “Away.”

Also, I was having an issue with Vacate; however, this is something that I corrected with programming to the alarm keypad itself. I just tested my alarm last night to be sure I had time to vacate; as well, had time to enter home from “Entry” doors that allowed myself time to turn off alarm.

I have the 6060 alarm keypads and I used *34 Exit Delay, *35 Entry Delay; as well, you have to be sure to set up *56 for Zone Programming to set the “Zone” type to 09 for Smoke, 03 for Open/Close and 01 for Entry Doors, this may help you:

Don’t know if this is exactly what your looking for, but hope this helps you; It did me!

1 Like

@azbutz, just curious, based on your user id, do you live in AZ?

I’m in North Peoria.

In my case I had some SHM sensors that are not part of my Honeywell Visa 20p system. My wife out of habit would set the alarm (also 6060 panel), to away (panel counts down 60 seconds), but SHM sets immediately. She would exit via the garage which has some ST sensors. Since SHM armed immediately it was already armed, she would trigger ST SHM.

I’m not sure why my arm(away) gots to arm(home) when I’m home. I’m testing using presence to automatically arm and disarm the Honeywell.

@azbutz That is weird? I am only using my hard wired sensors to do the same.

I am in Phoenix, just bordering the Peoria, Glendale boarder…Basically 67th and Happy Valley :slight_smile:

So we must live pretty close to one another. I have other sensor as well connected to my ST’s hub, but I choice for the moment not to include them in the SHM portion, just my hardwired sensors.

I have the same issue, just noticed last night, that when I set SHM, it also sets the alarm where there is no delay i.e. 30 seconds that allows one to un-arm the panel. What I did was remove my garage entry door from the SHM, so we can walk thru the door and disarm the panel. I have yet to test, but I think this will resolve my issue. I used to have my garage doors managed thru Cox with Zigbee Garage Door Contacts; however once I removed the Cox Solution, I lost that ability. I wanted to add my garage doors back on the system, but Im thinking that I will have to add wireless contacts thru the alarm panel to resolve this issue and not add it to SHM.

If you use these thru SHM, I am not sure how to remedy adding the ability to provide a “delay” so you have time to disarm the panel. If someone can figure this out, it would save both you and me a lot of trouble with figuring out “alternative” solutions.

@redloro any ideas?

Actually really close… I’m 83rd and Happy Valley.

@azbutz you do live close!

Just for info…Generally a glass break detector is programmed into a security system as a perimeter instant zone type. By programming it this way, whenever you arm the system in either the “Stay Mode” or the 'Away Mode" the alarm will sound immediately when it trips.Sometimes I setup the glass break detector as a audible panic zone type, so if it trips it will sounds the siren even if the the system is in the off mode.On my system, the main floor I program the two glass breaks detector for perimeter instant. The one in the basement is programmed as a audible panic.

It seems HomeBridge integration doesn’t accept capability “Alarm” yet (from what I can tell). The custom device handlers for contact and motion work, but the Honeywell Partition device handler capabilities doesn’t with HomeBridge.

So, my contact and motion sensors off the Honeywell show up in HomeKit, but not the alarm panel controls. There is a HomeBridge-Envisakit plugin… and it does present a alarm panel in HomeKit. I had some challenges with it, and prefer this @redloro implementation. The way the @redloro implementation works subscribing to events on the EVL, it consumes the only TPI interface session available, and I’ve had to remove the HomeBridge-Envisakit plugin. It would be nice to have the alarm panel in homekit.

Anyone know how to get this to work?

@got_toys @azbutz did some research today and apparently the instant arm issue with SHM has been causing members some grief for some time… there are workarounds available but they’re just that… hacks to the SHM. Check these out:

Have any of you tried this:

I was wondering, how come the by pass option is not included? Is it because it’s difficult to define the zones for exclusion? Anyhow, on a different note, running the forever start option is not effective for me on the raspberry pi 3. It seems the server.js file doesn’t get restarted after the computer restart or the case of a power failure. I am now using pm2 (http://devo.ps/blog/goodbye-node-forever-hello-pm2/) to solve this. What’s your take on this?

@Joe_D No bypass option cause I didn’t need it, but it can be added if anyone wants to roll up their sleeves :slight_smile: I’ll see if I get some time to add it in.

The forever script is just something that worked for me and could work for others, but the reality is that there are dozens of these scripts that daemonize a node app… so if pm2 works for you then great! Users of STNP typically have to use other scripts on RPi and Windows, so glad you found one that works for you.

Thanks for clarifying. I have no programming knowledge, I only know how to google. I wasn’t sure if what I was doing had any effect on the STNP process as a whole. I’m glad you clear that up.

I kept having issues where i would arm in SHM but there is a window or something open so the system is “notready” so SHM keeps the armed(stay) but the system cant arm because its “notready” so SHM is armed but the alarm isnt.
so i changed Line 233
from
if (partitionstatus == "ready") {

to

   if (partitionstatus == "ready" || partitionstatus == "notready") {

and on line 201 i added

  if (state.partitionstatus == "notready") {
    sendLocationEvent(name: "alarmSystemStatus", value: "off")
    return

now if you select arm(stay) on SHM and the alarm cant arm it just bumps SHM back to disarmed

This actually doesn’t work, partitionstatus is null inside this method.

Any thoughts on how to solve the inital problem or how to pass the partition status into this method?
i will admit i’m running on little sleep and i’m probably overlooking something insignificant

  if (state.partitionstatus == "notready") {
    sendLocationEvent(name: "alarmSystemStatus", value: "off")
    return

Hey @Big_Webstas… interesting problem. Not sure why this is happening tho. IIRC anytime I try to arm the system through SHM, if there is a window open, etc SHM will throw up a message and say something along the lines of “Are you sure you want to arm even though this is open…”

Regarding partitionstatus being null in updateAlarmSystemStatus(); this method will only work when the partition status has changed at the actual panel… it’s used when the panel wants to notify SHM that something has changed.

I think you’re on the right track but this may need a little tweaking… referring to the current code in GitHub for method alarmHandler() and updateAlarmSystemStatus;

def alarmHandler(evt) {
  if (!settings.enableSHM) {
    return
  }
  
  if (state.alarmSystemStatus == evt.value) {
    return
  }
  
  state.alarmSystemStatus = evt.value
  if (evt.value == "stay") {
    sendCommand('/plugins/envisalink/armStay')
  }
  if (evt.value == "away") {
    sendCommand('/plugins/envisalink/armAway')
  }
  if (evt.value == "off") {
    sendCommand('/plugins/envisalink/disarm')
  }
}

private updateAlarmSystemStatus(partitionstatus) {
  if (!settings.enableSHM) {
    return
  }
  
  def lastAlarmSystemStatus = state.alarmSystemStatus
  if (partitionstatus == "armedstay" || partitionstatus == "armedinstant") {
    state.alarmSystemStatus = "stay"
  }
  if (partitionstatus == "armedaway" || partitionstatus == "armedmax") {
    state.alarmSystemStatus = "away"
  }
  if (partitionstatus == "ready") {
    state.alarmSystemStatus = "off"
  }

  if (lastAlarmSystemStatus != state.alarmSystemStatus) {
    sendLocationEvent(name: "alarmSystemStatus", value: state.alarmSystemStatus)
  }
}

You may want to change to:

def alarmHandler(evt) {
  if (!settings.enableSHM) {
    return
  }
  
  if (state.alarmSystemStatus == evt.value ||
      state.alarmSystemStatus == "notready") {
    return
  }
  
  state.alarmSystemStatus = evt.value
  if (evt.value == "stay") {
    sendCommand('/plugins/envisalink/armStay')
  }
  if (evt.value == "away") {
    sendCommand('/plugins/envisalink/armAway')
  }
  if (evt.value == "off") {
    sendCommand('/plugins/envisalink/disarm')
  }
}

private updateAlarmSystemStatus(partitionstatus) {
  if (!settings.enableSHM) {
    return
  }
  
  def lastAlarmSystemStatus = state.alarmSystemStatus
  if (partitionstatus == "armedstay" || partitionstatus == "armedinstant") {
    state.alarmSystemStatus = "stay"
  }
  if (partitionstatus == "armedaway" || partitionstatus == "armedmax") {
    state.alarmSystemStatus = "away"
  }
  if (partitionstatus == "notready") {
    state.alarmSystemStatus = "notready"
  }
  if (partitionstatus == "ready") {
    state.alarmSystemStatus = "off"
  }

  def systemStatus = (state.alarmSystemStatus == "notready") ? "off" : state.alarmSystemStatus
  if (lastAlarmSystemStatus != systemStatus) {
    sendLocationEvent(name: "alarmSystemStatus", value: systemStatus)
  }
}

Give it a shot and let me know…

Pardon my lack of experience – I’m new to all of this. This integration looks like exactly what I’m looking for. I think that I have everything setup properly but keep getting the following in my log file when I try to run:

SmartThings Node Proxy listening at http://:::8088
Loaded plugin: envisalink
Connected to Envisalink at 192.168.1.109:4025
Envisalink connection closed.
timers.js:327
throw new TypeError(‘“callback” argument must be a function’);
^

TypeError: “callback” argument must be a function
at exports.setTimeout (timers.js:327:11)
at Socket. (/Users/home/smartthings-master/smartthings-nodeproxy/plugins/envisalink.js:147:7)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at TCP._handle.close [as _onclose] (net.js:498:12)
error: Forever detected script exited with code: 1

Any ideas on what I’m doing wrong?
Thanks!!