[ST Edge] Honeywell / Ademco Vista Panel - Envisalink

The format should be:

smartthings edge:drivers:logcat --hub-address=

Make your selection when the prompt pops up.

1 Like

That worked thx…appreciate you breaking that down for this big ole dummy:)

Ran the log and it appears I am getting a bad password:

2022-10-26T14:35:04.346262192+00:00 INFO Honeywell-Ademco Envisalink Attempting to reconnect to EnvisaLink
2022-10-26T14:35:04.444868067+00:00 INFO Honeywell-Ademco Envisalink Re-connected to Envisalink
2022-10-26T14:35:04.450750108+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.457480983+00:00 TRACE Honeywell-Ademco Envisalink Received event with handler _resync
2022-10-26T14:35:04.468380067+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.472039108+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.475923358+00:00 TRACE Honeywell-Ademco Envisalink RX < Login:
2022-10-26T14:35:04.478886567+00:00 INFO Honeywell-Ademco Envisalink Received login password request; sending password
2022-10-26T14:35:04.481792692+00:00 TRACE Honeywell-Ademco Envisalink TX > **********

2022-10-26T14:35:04.492500817+00:00 TRACE Honeywell-Ademco Envisalink RX < FAILED
2022-10-26T14:35:04.495480608+00:00 ERROR Honeywell-Ademco Envisalink Envisalink login failed - incorrect password
2022-10-26T14:35:04.502779400+00:00 DEBUG Honeywell-Ademco Envisalink Receive status = closed
2022-10-26T14:35:04.505750317+00:00 ERROR Honeywell-Ademco Envisalink Socket Receive Error occured: closed
2022-10-26T14:35:04.508709733+00:00 WARN Honeywell-Ademco Envisalink Envisalink has disconnected
2022-10-26T14:35:04.643103983+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:19.656274443+00:00 INFO Honeywell-Ademco Envisalink Attempting to reconnect to EnvisaLink
2022-10-26T14:35:19.744471318+00:00 INFO Honeywell-Ademco Envisalink Re-connected to Envisalink

This is a bit odd considering that same password I currently use to connect to Envisalink website to log into my account successfully?

1 Like

It’s not the website password. It’s the password you use for the local Envisalink interface that comes up if you type (or whatever the Envisalink’s local IP is) into a browser. I believe default password is user.

Oh ok…this time I did leave the default as “user” just to try and it appears to be working. One thing I noticed is that I do not have “Arm Max” as a virtual switch under the No room assigned category. The only ones I see are HW Switch armStay|1 and HW Switch armInstant|1?

I believe I would need the Arm Max as a switch that way I can create a “routine” to automatically turn on / off at a certain time like I did before. We always use Arm Max at bedtime…am I missing something?

The virtual switches are only necessary for third party integrations like Alexa/Google. You can create native ST routines for arming/disarming using the partition device - no virtual switches required.

You do need to make sure that that arm mode is enabled for it to show as an option. Go into settings on Partition 1 and make sure the Display 'Arm Max' mode option is turned on.

If you do want the virtual switch for that mode, it needs to be enabled for display as noted above. If it’s still not showing up, try toggling the Add Virtual Switches option to trigger it to try to add them again.

Looks like the remaining virtual switches finally showed up on the “No Room Assigned” screen. I like having all of them anyway in case I want to arm / disarm using Alexa.

Everything appears to be up and stable now that I got the password issue straightened out. Thx everyone for your assistance and sorry I was such a “newb” during the t-shooting process:)


No worries! We were all once newbies with all this!

1 Like

This integration works EXTREMELY WELL. I’ve been able to use it to replay my Honeywell Tuxedo automation with SmartThings.

I originally tried to do this with Konnected - which worked - but required wiring as well as did everything through ‘the cloud’. This allows Smartthings to locally get status from Envisalink.

I’ve encountered two small ‘glitches’ in the course of unwiring the Konnected and updating to Envisalink.

1.) I had to turn off the alarm panel. Smartthings ceased to work with the Envisalink until I rebooted the Smartthings hub

2.) Similarly for some reason I found a sensor out-of-synch and rebooted Envisalink. Smartthings again ceased to work until the Smartthings hub was rebooted.

These were minor issues, easily fixed by the reboot. Not being driver savvy I’m not sure if something could be done by in the driver ( @philh30 ) or if that’s just part of the Smartthings architecture that is a limitation.

Regardless - it’s an AMAZINGLY WONDERFUL thing. Love it!


I moved to this device driver from redlore’s. Had to reboot hub and toggle “add zones” several times to detect all 37 sensors. Seems like the highest wired zone is for which are not battery powered devices. Or perhaps how many devices to search for.

@jonj I’m glad it’s working out for you! I’ll take a look at the reconnect logic to see what can be improved. For now, a workaround to try to force an attempt to reconnect is to change the Envisalink IP address in the settings menu, then change it back to the correct value.

I’ve seen other developers have trouble when creating too many devices at once. I didn’t run into that myself, but it’s been a while since I set up my own alarm system. It might be best to just list a few zones at a time for creation.

This is correct. Any zone # above what’s set as the highest wired zone is assumed to be a battery powered sensor and assigned to a profile that includes the battery capability. The profile can always be swapped later though through the zone’s settings menu.

Just as a data point…this usually seems to happen when the system is armed. “This” being the zone shows “open” even though it is closed and, hence, the controlled device stays on.

The other night it happened, the zone was stuck ‘open’ again even though closed. I changed the IP address to toggle things on/offline and it had no change. The closed zone still showed opened - and controlled fan on. However I toggled the system out of STAY mode into DISARMED. The zone status IMMEDIATELY changed and became normal (closed) and the controlled fan went off.

So toggling from armed to disarmed seems to correct it.

Does that give you any clues? Curious, eh?

One other experiment. I armed the system. Turned up the temperature which triggered the zone from closed to open. The driver did NOT report it open, it remained closed. Ditto if it was open when I put the system into armed state.

So it seems that the contact sensors aren’t getting updated properly if the system is in armed/stay at least.

Hope that helps!

You’re running into some of the limitations of the data that the Vista provides to the Envisalink. The Vista wasn’t designed to support home automation, and the data that the Envisalink gets is limited to what you see on one of the custom alpha keypads. I can rant at length about how challenging the data is, but the two things that are primarily impacting you:

  • When the Vista is armed in stay mode, interior zones are treated as if they were bypassed. The Vista stops reporting whether they’re faulted.

  • The Vista never actually reports when a faulted zone clears. The only data that the Envisalink (and therefore this driver) gets is what you see on a custom alpha keypad - a continuously cycling list of the currently faulted zones. The driver has to infer when a zone has cleared, either by seeing enough keypad updates come through without another report that the zone is open or by seeing that the partition has been reported as disarmed with no faults.

So, in your case, the zone is reported as faulted prior to arming. Once the system is armed, there’s no data to indicate whether or not the zone has been cleared. Absent any data, the driver leaves the zone in whatever status it was in.

Something I’ve done with my own system that could help in your case is that I’ve moved all of my interior zones to partition 2. That way, they’re still actively reporting status when I arm stay partition 1 since 2 is still disarmed. Partition 2 also has its own queue for faulted zones, so an added bonus is that zones clear quicker and more accurately on both partitions than they would if they were combined. The one challenge with this setup is if you’re wanting to arm both partitions and have the siren sound for both - I have big dogs that trip my interiors all the time so that’s not something I’ve bothered to figure out.

By the ways, changing IP address is only a workaround if you have ST disconnected from Envisalink and it isn’t reconnecting. For a zone out of sync, restore the partition to disarmed/ready, and then if the zone still shows open swipe down on the device in the ST app and it should clear the fault.

Thanks so very much for explaining that. It makes sense from a system point of view to minimize overhead and not track ‘interior’ stuff if you’re monitoring for threats. But, as you say, in the context of a home automation system, not so much.

I’m going to look at moving those things to Partition 2. That seems reasonable. I’ve only got two of them and it should be easy to experiment without me melting down the system or the monitoring company. (grin)

I’m using zone type 23 - non-reporting zone. So I guess it treats that as ‘interior’ when armed and doesn’t actively report status.

I also was wondering if programming a custom zone may work too. Will have to look at that option. The custom zone option has 10 entries. It would be nice if the standard zone types showed how they would be represented as ‘custom zones’ to use as a template to tweak.

Again, thanks very much for explaining that! Makes perfect sense.


1 Like

I don’t think that a custom zone type would get you around this limitation, though I’ve never experimented with them. I used the term “interior” since that’s what applies in my set up, but to be more exact I think that when the system arms it stops reporting on anything that won’t sound the alarm. I could be wrong though!

The only other drawback I can think to mention with partition 2 is that each keypad has to be assigned to a partition (though you can swap between) and will only display faults related to that partition. Maybe not something you care about though depending on how you’re using those zones.


Your suggestion worked well so far. (nothing blew up!)

The steps were:

1.) On the VISTA 20P - Enter programming mode +800
2.) *56 to enter zone programming
3.) Access zones and change from partition 1 to 2
4.) Select a keypad address, in my case I used 20, and change it to Partition 2 using the *19x menu
5.) *99 to exit alarm programming
6.) Login locally to Envisalink and use the keypad address (20) to report partition 2

In Smartthings Android interface
7.) Delete the sensors that I moved to Partition 2
8.) Access the Panel and SETTINGS of Panel to enable Partition 2
9.) Make sure “automatically add zones” in SETTINGS of Panel is enabled
10.) Toggle the IP address of PANEL to something junk, wait for it to go offline, then toggle it back to refresh everything

At that point, the new sensors should appear. Rename them, add them to routines.

Finally, login to TOTALCONNECT and RESYNCH PANEL since zones have changed!

A lot of small steps that really weren’t too bad.

Just wanted to document the above for others who may want to try this.

Again, thanks so very much!
Jon D.

1 Like

Be sure to go into settings in the app for each of those zones and change the Partition option to 2. The driver uses that setting in the logic to determine when zones should be considered clear.