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

I assume your HSM arming has a delay given that your tests have the status "armingHome". I'm not accounting for that status in any of the code. Try replacing the alarmHandler function with this function. I don't have an HSM delay configured for myself, but in both the tests above that were red, they worked as anticipated for me.

def alarmHandler(evt) {
  // handles HSM events 
  // armedAway, armedHome, disarmed.
  
  if (!settings.enableHSM) {
    return
  }
  log.debug("Debug: in alarmHander for HSM event: value ${evt.value} state.alarmSystemStatus: ${state.alarmSystemStatus} state.isArming: ${state.isArming}")
  // deal with when you have just set hsmSetArm=disarm  
  // and received the event hsmStatus=disarmed 
  if ((state.alarmSystemStatus == "disarm") && (evt.value == "disarmed")){
	return
  }

  if (state.alarmSystemStatus == evt.value) {
    return
  }
  log.debug("Received HSM event: Value: ${evt.value} state.alarmSystemStatus: ${state.alarmSystemStatus} state.isArming: ${state.isArming}")
  state.alarmSystemStatus = evt.value
  if ((evt.value == "armedHome") || (evt.value == "armingHome")) {
    log.debug("Sending command to envisalink to /armStay")
    sendCommandPlugin('/armStay')
  }
  if (evt.value == "armedNight") {
    log.debug("Sending command to envisalink to /armStay")
    sendCommandPlugin('/armStay')
  }
  if ((evt.value == "armedAway") || (evt.value == "armingAway")) {
    log.debug("Sending command to envisalink to /armAway")
    sendCommandPlugin('/armAway')
  }
  if ((evt.value == "disarmed") || (evt.value == "allDisarmed")) {
    log.debug("Sending command to envisalink to /disarm")
    sendCommandPlugin('/disarm')
  }
}

Were you able to try my changes above?

I know this is a known "feature" of the HE-native envisalink-HSM integratoin but I wonder if anyone has looked at fixing it...

When you arm HSM Envisalink causes HSM to disarm and re-arm. It works fine but does make creating rules based on arming and disarming bit more complicated.

Screen Shot 2022-02-04 at 10.10.25 AM

Can’t say I’ve noticed it. I wonder if the changes I’ve proposed in the last few posts might fix this.

I will give it a try, After making a full and complete backup.

Are your suggested updates to the HE-native integration or the RPi/nodeproxy integration? I'm runing the former and can't seem to find those sections.

Oh. I didn’t catch you were referring to the HE native version. Sorry I didn’t read carefully - that would explain why I haven’t noticed it.

NP. I have it all working so not a big deal. Just requires additional logic on rules.

Brian, Sorry for the delay. (It took me awhile to discover I had a Rule that was interfering.) I implemented both your code changes and tested all the same scenarios as earlier, using a virtual button and then with a lock code - several times. They all worked well. :clap: I have no HSM Arm delays and the tile shows HSM Arms immediately. (One test included a fast arm/disarm (within 5 seconds) and that caused a rearm that did not repeat consistently , but this was not a real life test so not an issue.) At this point I have only tested it with Arm Stay/Arm Home, but I am running with your changes. If I notice anything out of the ordinary I will provide feedback. Thanks for taking the time.

1 Like

I finally got around to setting up a service to auto start the app in PI when the PI reboots.

Open nano and create a new service file

sudo nano /etc/systemd/system/Envisalink.service

Add the information below into it and save to create the new service

Description=Auto Start Node Proxy Script for Envisalink

Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
WorkingDirectory=/home/pi/smartthings-nodeproxy
ExecStart=node server.js
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Get the service ready to run and check the status of the service

sudo systemctl daemon-reload
sudo systemctl Enable Envisalink.service
sudo systemctl Start Envisalink.service
sudo systemctl Status Envisalink.service
journalctl -u Envisalink

There will no longer be a running terminal window but you can use these to check the status if you need to.

sudo systemctl Status Envisalink.service
journalctl -u Envisalink

2 Likes

Hi @brianwilson. I have been using the ST Node Proxy Russound RNET plugin for ST and just recently installed HE. Could you share what changes I would need to make to the app and driver codes to get to work in HE? Thanks!

I've only written integrations for the alarm, nothing for Russound RNET. That would require someone to re-write their ST code for Hubitat.

Gotcha. Didn't know if it were a few areas that simply needed updated for parity, but appreciate the reply.

Hey everyone, I am building a new house and planning to use hubitat, dsc, and envisalink for alarm and home automation.

I have a few quick question:

  1. Is it a good idea to use the hardwired motion and door sensors from dsc as trigger for automation?

  2. Does Hubitat see the motion status reliably without much lag? (ie: use dsc motion sensor to trigger lights to go on)

  3. Does the envisalink report sensor status if the alarm is disarmed?

  4. Am I able to arm away/arm home/disarm with Hubitat?

  5. Am I able to bypass certain zone when arming with Hubitat?

All your help are greatly appreciated!
Thanks!

Hi @user1293 and welcome to the community. While I am no expert, I have had my old (approx 14 year old) DSCPower864 panel updated with Envisalink in the last two years and integrated with Hubitat. In order to keep with my philosophy of a dedicated, reliable and UL certified purpose built security system for safety reasons, out of my 64 zones, all are hardwired for reliability with the exception of 5 - 6 zones (mailbox and some doors and shock sensors for wiring convenience reasons). Alarm functions are all handled by DSC, with Hubitat only using the sensors (motion etc) for home automation and other convenience functions (non-critical safety/security functions).

Motion response has been virtually instantaneous in most cases and its nice to not have to worry about having additional sensors (especially not battery powered ones that are dependent upon Z-Wave, WiFi or Zigbee, although many here have used Zigbee and Z-wave successfully). At any rate, for the most part, not having to worry about battery status is a plus, as well as too many additional “warts” on the wall and ceilings which affects the WAF. However, remember that Envisalink is quite “chatty” (it can be responsible for 45% or even more of the busy time use according to review of the HE app logs) and so the response can slow down if you have some very resource hungry apps/devices in addition (such as Ecobee thermostats linked to HE, or other devices with frequent polling rates). So YMMV.

Remember that whether you use your DSC sensors for HA or not, the important thing is that they will serve as stand alone security/safety sensors whether your hub goes down or not. If you sensors that are dependent upon the hub (OK for HA but not for security purposes IMHO), then if your hub goes down, so does your essential security/safety system. If you have already planned on using DSC with Envisalink and Hubitat, you can always try the wired sensors for HA purposes and if you find they are not responsive enough for you, to then add in some dedicated sensors for HA that link directly (and locally) with Hubitat (either Zigbee or Z-wave depending upon your preferences).

As I set up my DSC system from the get go myself (got all the programming manuals and equipment when you could purchase everything direct as a end user, now much of the info is “doled” out to distributors and professional installers and is less readily available to the end consumer) I learned the ins and outs of all the different program settings from the professional installer’s manual. Which brings me to your questions about if the sensors work when the system is unarmed. IIRC, there are about 30 or so different attributes as to how a given zone functions. IOW, various zones can be programmed depending on how you set the code for each zone to react differently whether the system is armed in stay or away mode, disarmed, etc, etc, etc. Depending upon the zone attribute settings, you have a tremendous number of options of how you can made each of these zones react when triggered. Due to the complexity, I use the DSC LCD alarm panels as they make programming the system much easier than trying to program it via a LED panel. These attributes or “characteristics” are programmed and set in the DSC panel, Envisalink only tells you if the zone is open or closed (and to answer your question, does so whether your panel is armed or disarmed).

You can use Hubitat to arm the system due to the integration via Envisalink. I use voice commands via Alexa to “arm the house in stay mode” or “arm the house in away mode”. I would not suggest using Hubitat to disarm the system or use voice control to disarm the system for obvious reasons, although it can be done.

I have not utilized Hubitat itself to bypass specific zones when arming. Again, I have the attributes set in DSC itself which allows it to bypass certain zones automatically if they are open or already breached at the time of arming, so I have not had a need to do this via Hubitat.

Ultimately, because of the amazing integration between DSC, Envisalink, Alexa and Hubitat, your ingenuity and imagination are basically your only limits on how you can integrate your system with regards to automation (e.g. setting off any motion sensors or door/window contacts can make verbal announcements to help you identify which sensors have been triggered, and can give verbal warnings and can trigger other deterrence measures such as turning on lights or sprinklers etc, and can vary the response depending upon whether the system is stay or away armed, not armed, time of day or Hubitat mode, day of the week, object recognition with your security camera system, etc and any combination thereof.

Things have come a long way since I started using X10 and Stargate automation over 30 years ago, lol (as well as having got a lot less expensive, versatile and capable too!).

I now have my security camera system (Camect for object recognition), DSC security panel with Envisalink, automation system via Hubitat, and voice control and announcements all linked with Hubitat in the middle controlling automation functions, and DSC running security/safety/fire/CO even if Hubitat goes offline (it is not recommended nor endorsed by the HE staff to rely on Hubitat for essential safety functions).

Anyway, welcome to the fun! Hope this helps a little.

I have a Vista 20p panel and Envisalink using the local HE implementation - no extra hardware. It works well.

I do use the Vista hardwired motion and door sensors for automation. Works fine, and plenty responsive. It does report sensor status when the system is disarmed. You can arm/disarm with HE though as @moh suggests you might want to be careful with disarm. You can also use RM to control the alarm, monitor alarm status, etc. You can also use it to integrate additional devices into your alarm system. For instance, I use Ring keypads in addition to the Honeywell keypad and I have additional siren devices on all the floors that are controlled by HE in response to an alarm. Again, the Vista system continues to operate independently without those extras, so I'm still maintaining a completely separate alarm system.

The one thing you should know is the Envisalink application that runs natively on HE is a bit of a beast. It's responsible for half of all my CPU usage. That's probably why a lot of folks run the rPI version. I find it easier just to leave it all on HE though at some point I will migrate it to a separate hub.

I also have a Vista 20P panel and Envisalink using the local HE implementation, but because it is so "chatty" I have Envisalink loaded on a dedicated C7 hub and link the 2 hubs using HubConnect. HubConnect allows synchronization of the HSM modes. Hub Mesh may also work but I have had no problems with HubConnect. It works great. I have had no problems in over a year.

All you “youngsters” with your new fangled Vista 20P’s, lol. I started with the DSC Power series about 35 years ago when I DIY’ed it for my office (it still works to this day). Since I was already familiar with it, and it lasted and continued to work, I self-installed one in my current house which I have been in for 22 years now. When Envisalink came out, it finally brought my system into the “internet age” and has kept it alive to this day.

To the OP @user1293 , the integration with HE works fantastic and has kept my ancient and (heretofore) rock solid system up-to-date. I trust you will find what you can do with the system pretty amazing and customizable to the extreme.

I did purchase another C7 during the Memorial Day sale (I currently run a C7). As @brad5 and @Sakman have mentioned, the Envisalink Integration is very “chatty” and uses around 50% of the busy time as I mentioned. I’m not sure whether to just keep my second C7 in reserve as a backup, or to use it like @Sakman to unload some of the CPU load. So far, even though I also run other cpu hungry integrations like Ecobee Suite, I have not really experienced any slow response as I have set up automatic hub reboots based on available free memory (mine set to 175,000kb). With this setting, my hub reboots about once every 7-12 days and I never notice any problems with responsiveness of my wired sensors when used for motion lighting etc.

I am still pondering how to use my second hub (another topic of course but somewhat related to this thread due to the OP’s question about responsiveness). I suspect @brad5 and @Sakman might suggest I just purchase a 3rd hub, LOL! I know many in the community suggest this (particularly the HE staff, JK!).

1 Like

Just pick up a used C5 for $50 or so. It’s all the same hardware/CPU.

This is a great app and it has been really reliable for me.

This would be a "nice to have" suggestion for this app;

I had a power outage it did not report it in any way. I guess that is a trouble condition, it would be good to report trouble conditions.