[RELEASE] Honeywell / Ademco Vista 20P Integration

+1 same here

I’m using this piston in conjunction with the 6 recommended automations using 3 virtual switches.

Keypad 1 = Honeywell Partition
Switch 2 = Arm Stay
Switch 1 = Arm Away
Switch 5 = Disarm!

edit: scroll down for updated pistons

It seems to work, though when I look in the logs i see a few event triggers i wasnt expecting (that end up cancelling due to already being in that state). curious if this is a good solution or if anyone has a better piston

edit: i got a false alarm in the middle of the night, caused by my motion sensor that shouldn’t even be active at that time, so i need to do more testing before this is ready for prime time, as well as make the changes @nathancu mentioned below

1 Like

Id definitely split it into two unique pistons (and in fact in my system it is two) it becomes way simpler. Currently you have to add a bunch of defensive logic to prevent racing in recursive calls. Break it into one piston reacting to switches and one piston reacting to state changes on your alarmserver status.

Breaking it into two pistons allows you to basically ‘have trigger - do thing’ without any defensive code because thd piston wont be recursive. The v switch throws, do something, you dont have to check if its already been done because if its already there and you do it again you dont care. Doing it again wont hurt.


I got the buttons back in the Partition Tile last night. However, like @ruinertt none of them appear to operate anything other than just spinning for now.

I had been hoping for those buttons to be accessible in the Automations in conjonction with the STHM. However, @philh30 already pointed out that it won’t be the case. Doesn’t that kind of defeat the purpose of using those buttons since we still have to use virtual switches to relate to the STHM?

Using a piston in WebCore to bridge “dscpartition” and STHM has been an okay work around for me so far.

ST staff are looking into the buttons. I haven’t gotten a response yet on what they have/haven’t found though. I’m having other issues with custom capability development that lead me to believe they don’t have them back to working like they (briefly) used to yet. I’m not able to create new ones that work, so I’m at a stopping point for now.

@Francosino Good point. It might not be necessary in your set up. I’m going to have virtual switches for my Vista no matter what for ActionTiles integration. If I bother to set up the security part of STHM, I’ll probably set up a separate set of virtual switches to drive those modes. When my wife looks in the ST app, she wants to see all the alarm stuff together though, so I at least have a reason to get it working. And sometimes my current virtual switches get out of sync, so I like having a toggle in the DTH itself.

1 Like

while playing around with my webcore piston, i wanted to figure out what options I had for capabilities

i made a piston to log changes to:

  • ⌂dscpartition
  • ⌂panelStatus
  • ⌂alarmState
  • ⌂$status

(I did keep the “attribute “panelStatus”, “String”” and added it to the DTH that @philh30 made)

Options for ⌂dscpartition: armedstay, armedaway, ready, notready
Options for ⌂alarmState: ready, notready, alarm
Options for ⌂panelStatus is anything the alpha keypad displays, passes to the Envisalink, and what gets logged in STNP. The formatting of which is:

FAULT [Z#] [zone name]
****DISARMED**** Ready to Arm
ARMED ***STAY***May Exit Now 59
***NIGHT-STAY***May Exit Now 59
DISARM SYSTEM or alarm occurs
ALARM [Z#] [zone name] 

so when using webcore, you could subscribe to more specific events based on the panel or alarm status, and know which value to put in the piston condition.

edit: i also see now while looking at the DTH, that dscpartition has all of these options, even though some didn’t log to webcore with my system: “ready”, “notready”, “arming”, “armedstay”, “armedaway”, “armedinstant”, “armedmax”, “alarmcleared”, “alarm”

i also found while reading those logs, why my alarm went off last night.
when i used my honeywell keypad to turn on Arm Stay, i noticed that it counted down about 2-3 seconds, then restarted in Night Stay mode. in that mode, my indoor motion detector on the lower floor are active, and was triggered by my dog.

as for how it got into Night Stay? still figuring that out. as far as i know, i dont have any pistons or automations that should tell my Vista 20P to activate Night Stay. The only thing new that could do that is the piston I shared above that uses the armStay() command.

my current setup is a mess though. i need to migrate and eliminate the SHM variable, since the Honeywell Security linked with SHM is the only other thing that could pass along a command.

Figured out the night stay business. Due to the piston configuration, the Honeywell was receiving multiple Arm Stay commands in a row. Since those commands through the EVL basically are just your PIN + a number on the keypad, it was sending a bunch of digits in a row. ArmStay is [PIN]+3. Night Stay is [PIN]+3+3. My PIN begins with a 3, so it read the first digit of the second command as the second 3 on the Night Stay command.

So I either need to change my PIN, or I need enough logic in my piston to not send multiple identical commands in a row.

How do you guys have your pistons set up?

Would you mind posting your modified DH, please? I was looking my current DH and it did have this:

This allowed me to do exactly what you described above within WebCoRE, which is great.

Just to be clear, should I hit the “Migrate this location now” button in the classic app before updating the DH or update the DH prior? Also, should I shut down STNP prior to switching the DH or does that not matter?

Any order. Migrating doesn’t touch this directly, so it doesn’t matter. After migrating, you can still use Classic for devices and smartapps.

Migrating converts SHM, Routines, and Locks to the new app schema, then deletes them from the old app. If you use any of that, document what you have so you can check after to see if it’s all still set up right. Once you migrate, you’ll no longer be able to use those features in Classic.

:+1: I don’t really use any of the above - For the most part, I mainly use WebCoRE, so as long as that works with the new DH, cool.

Add Life360 in classic if you ever plan to use it and haven’t done so already. Can’t install it after migrating

Not likely I’ll use it, but thank you :slight_smile:

I just set this up again and it’s been a while since I did this but I’m not seeing the Honeywell partition device after following the instructions.

Are we supposed to add a new device using that DTH? The sensors all showed up without having to manually add them. I don’t see in the original post where it says to add any devices after importing the groovy code for the DTH’s. The partition device isn’t showing on the classic or the new app. I’m talking about the device that shows the alarm status and has arm/disarm buttons. I can add it manually but it doesn’t do anything like display updated status of zones or arm/disarm/chime.


No, you cannot add a new device (discovery) using the new DTH from phil. If you want to use the discovery feature, you will need to use redloro’s smartapp and DTH’s. With that said, Samsung has jacked up the back-end yet again and phil’s DTH isn’t working. Most custom capabilities aren’t working from what I’m reading. Samsung has really made this conversion to the new app a dumpster fire.

I used redloro’s smartapp and DTH’s. How does the partition device get added? Do you have to use the “Discover Zones” option? I didn’t add the contact and motion sensors so I think those showed up when I did the initial discovery. I’m missing a step somewhere.

By default the partition device is called Honeywell Security. It’s the device that has the disarm/arm/chime buttons. It should have been added during discovery at the same time as all the zones.

Thanks. I will do another discovery.

This is what the Honeywell security device looks like after it is discovered. Just says alarm type with a crossed out cloud and a button that says standby.

Is that using the redloro device handler for the partition? Or have you added my handler and then swapped the device to it?