[ST Edge] Honeywell / Ademco Vista Panel - Envisalink

Thank you for your work on here. Will this ST Edge version still allow the status of the alarm to be seen by other components of ST? For example, I realize that WebCoRE (may/will?) be phased out at some point, but the way I have it setup with the “man in the middle” old setup, WebCoRE can see, for example, when the alarm is in “alarm” mode then do actions based on this.

Here’s a snapshot showing you what WebCoRE is looking for to take action:

Screen Shot 2021-11-24 at 5.30.02 PM

Here’s what was added in the device handler to get WebCoRE to see this:

I don’t even know if the native routines in ST would be able to see this information and take action on it anyways.

1 Like

Great questions - they made me realize that automations off the main attribute for the partitions (alarm mode) weren’t working, but that’s now fixed. If you’ve already installed the driver then the update will be pushed out in the next 24 hours. If not, you should get the new version when you install.

The answer after that fix is yes to all of the above.

I don’t use WebCoRE, so I can’t say I’ve tested this all the way through, but the capabilities that this uses are visible in it:

In native automations, you can use any of the partition attributes as a condition:

and you can set the alarm or chime on the Then side of the routine:

The zone devices allow native automations based on any of their attributes:

and you can bypass multiple zones at the same time through scenes:

Yup. I can use that. It’ll be a day or two but I’ll add that in. My only worry is that the caching issue with custom capabilities might prevent it from showing as an option on the automation screens.

I see, so instead of it being called “dscpartition,” it looks like it is now called “alarmMode.” With that said, I see how you can select “alarmMode” in native automations, but I don’t see a way to provide it the specific thing you are looking for, in this case “alarm.” Alarm, in essence, is the alarm going into intrusion mode. The other thing I am wondering is, for example, a way to turn on a light after this happens (or activate some other device.)

That’s the next screen of options after the screenshots I posted. See below, and note that the little house icon on the top one means it runs local.

If you just want to dip your toes in, you can start setting this up without doing any permanent damage to the STNP setup. Just unplug your STNP server and then you’ll be able to start setting this up next to your existing STNP devices. If you decide you want to go back, delete the devices for this integration and plug your STNP server back in.

Great, thanks a bunch. I’ve read your instructions here on GitHub and one thing I’m wondering about (maybe I missed it,) but do I have to manually enter in each zone within the app? I did it the “old” way a long time ago and I remember having to manually type in each zone in a file and saving it.

1 Like

Yes. The settings screen on Partition 1 has fields where you list zone numbers, and the driver will create devices for any zones listed. Once they’re created, you can rename them and assign them to partition 2 if applicable. Anything can be renamed, so long as you don’t change the network ID (which I don’t think is an option right now anyways).

The STNP setup had a config file where all of the zones were listed. I had toyed with making a single driver that could do either direct connect or through STNP. That method would’ve allowed you to pull zone setup from the config file, but it got very complicated trying to manage both connections, especially once I started pulling some of the data that STNP didn’t support like battery and tamper.

Makes sense. Dreaming of course, but it would be nice to go into the config file, copy and somehow paste into the app… A question about keeping the old configuration, stopping the STNP service and trying your ST Edge version. If I have issues and want to go back to the STNP service for the time being, how will I be able to tell which devices were created from STNP and the ones from ST Edge?

If you look at the device list in the Groovy IDE, all of the devices for this will show as placeholder and will show a blank network ID. In the app, it should be obvious since the devices from this will have tamper/battery/bypass capabilities on detail view that don’t exist on the STNP devices.

Ok.

Thanks.

I just added the new integration devices yesterday and until I’m fully comfortable I’m keeping the “HW” at the beginning of their device names to more easily tell them apart for now.

@philh30 one minor thing i noticed, having 15 wired zones myself, is that i did enter “15” as the highest wired zone, but everything above 8 still was created as a wireless zone. just a small inconvenience, but thought you’d like to know.

1 Like

Thanks. Looks like a change I made after testing that part put the code to update it (and the zone close delay preference) behind an if statement that isn’t triggering. If you edit your alarm pin (can change it back after saving) it should trigger those two preferences to update. I’ll correct that when I’m home tonight.

expanding on the webCoRE integration, I’ll try to add some notes to help map previous capabilities and commands to the new ones, as well as list out the proper syntax to use for each. I did this before for STNP which can be found here:

capabilities
image

the STNP dscpartition has the following states: ready, notready, arming, armedstay, armedaway, armedinstant, armedmax, alarm, alarmcleared.
It seems to be most closely related to securitySystemStatus of the Edge Driver, but alarmMode also seems very close so I’m not sure. Main difference is that securitySystemStatus shows “disarmed” and alarmMode shows “Ready” and “Not Ready”

commands:

Edge Driver attribute values (not complete, just what I’ve seen or tested so far):

alarmMode:
seems to be proper words in Title Case with spaces in between. Does show up in IDE and app logs, but not in webCoRE event history for some reason.

Ready, Not Ready, Arming, Armed Stay, Armed Away,  (and presumably: Armed Instant, Armed Night, Armed Max)

securitySystemStatus:
seems to be snakeCase (no spaces, each word after the first has first letter capitalized). Oddly enough, what’s displayed in the app doesn’t exactly match what’s in the event log of the IDE, and i’m not seeing every state in my logs, but i do see the changes in webCoRE

armedStay, armedAway, disarmed.  (maybe also: armedInstant, armedMax if enabled)

bypassStatus:
snakeCase. changes frequently

ready, notReady, bypassed

chime:

chime, off

statusMessage:
The exact text sent to your panel. Can vary quite a bit, I won’t be as thorough here. Since it changes the most, you wont want to use this in any pistons.

****DISARMED**** Ready to Arm
FAULT [zone# and name]
ARMED ***STAY***
ARMED ***AWAY***
ARMED ***[STATE]*** MAY EXIT NOW [##]

power source:

battery, dc, mains, unknown

alarm:

both, off, siren, strobe
1 Like

alarmMode should be your best bet for partition status. It will flicker a lot between ready and notReady though. Interesting that you’re seeing it come through as Title Case - it should be snakeCase as the key (which should be what automations are based on) and Title Case as the value (pretty name displayed in the app). Could you check that your driver is dated 11/25? I corrected a bug that day where the Title Case was being posted as the key.

securitySystemStatus and alarm (as well as the armAway, armStay and disarm commands) are part of the stock capability securitySystem, which I included to allow easy integration of STHM->EVL (when STHM is armed/disarmed it automatically calls the arm/disarm command of any device with this capability).

  • The three commands (armAway, armStay and disarm) will only work if STHM integration is turned on. armAway and armStay also require a boolean parameter to be passed (oddity of how they designed the stock capability). This is possible in webCoRE but not through the native automations. Overall, I would stay away from using these commands and instead use setAlarmMode to arm/disarm.

  • securitySystemStatus should be limited to just disarm/armedAway/armedStay as options based on how the stock capability is defined (and I’ll check code tonight to make sure I’m not populating other statuses here).

  • alarm as an attribute on this capability is just a string, which isn’t being populated in a meaningful way. It’s interesting that those values are showing up as choices in webCoRE, since they’re associated with the alarm capability and not this particular attribute. Don’t use this one.

powerSource will only post as mains or battery. Ignore the other options.

1 Like

i’m only seeing alarmMode values in the app and IDE (and now in webcore), so those must’ve been prettified. i haven’t been looking in the cli tool, or at the code for the driver.

good to know about how securitySystemStatus is more related to the ST capability instead of the actual honeywell panel. also explains why it’s limited to just a few options.

for alarm, i probably mixed up capabilities and attributes when i was grabbing values.

i’ll work on testing and updating my pistons. glad that this works natively with STHM though, i can probably simplify some things due to that

looks like these are the details for using the armAway and armStay commands with the boolean. The boolean is related to “bypassAll” and is a required parameter.

if using setAlarmMode(…) is the preferred way to directly change the partition, what are the exact arguments/parameters for that?

edit: think i found the answer: disarm, armAway, armStay (and armInstant, armMax, armNight if enabled in settings)

1 Like

Those look correct

1 Like

that flickering will cause the piston to run each time if subscribed to alarmMode. if it can instead subscribe to securitySystemStatus, that’ll at least limit the piston to running only when we arm or disarm, which seems more efficient. is there a downside to this, other than it’s linked to the securitySystem capability instead of the partition’s capability? from what I can tell they stay linked pretty closely.

edit: i guess you lose the visibility to the Instant, Night and Max modes, but for the purposes of using webcore to keep the partition in sync with STHM those modes aren’t necessary anyway.

edit2: i’m realizing you’ve already mentioned a lot of these things I’m discussing earlier at i backread more thoroughly:

Security Mode should work fine on the If side of automations but is a but funky on the Then side (you’ll get a network error if you try to use the armAway or armStay functions). It does provide a native integration with STHM though where STHM status calls the Security Mode commands.

Shorter answer: use whichever better fits your purpose on If, but only Alarm Mode on Then

Events post to both alarmMode and securitySystem each time, so you should be fine. Note that armMax and armInstant map to armAway and armStay, respectively.

Also, armNight won’t show as a status at the moment in any capability. The command will arm the panel in that mode but it will show as armStay. I haven’t messed around with armNight to understand the purpose, and it can only be identified from the alpha display.

yeah that was the case with the STNP integration as well. i dont know if the EVL is specifically compatible with that mode.

in arm stay all interior zones like motion sensors are bypassed, in arm away no interior zones are bypassed, and in arm night you can set certain interior zones to be bypassed while leaving others active.

the way to make it arm night is just adding another 3 right after the 3 that follows your security code. (i also had a weird quirk once because the system code i was using began with a 3, and when i was testing my pistons it wound up sending codes twice in a row, so it received the initial 3 of my second code but interpreted it as the “night” mode 3 and put me into night mode inadvertently.

more details: Arm Stay vs Arm Night - Alarm Grid