[ST Edge] DSC Security System / Envisalink Driver (2021)

The ActionTiles issue is capabilities, not categories. ActionTiles doesn’t currently support custom capabilities, and I don’t think it supports all of the stock capabilities either. I’m also pretty sure it doesn’t support multiple components. This is really an issue that their team needs to deal with on their end, and they’ve posted a few times with questions that indicate they’re working on transitioning to the new API.

If you put a stock switch capability on your partition device as was requested, then ActionTiles would be able to toggle that switch. It still wouldn’t be able to handle the custom capabilities since those just aren’t supported. Of course, if you put a stock switch on your partition device then Alexa and Google will also see it and be able to control it, which is probably a security concern for some of the people using your integration.

The other option is virtual switches, either created outside the driver and linked via routines or created/managed by the driver. I prefer that solution since it gives users the choice of which arm/disarm commands they expose to Alexa/Google.

I extracted what I believe to be the relevant parts of the log. I armed panel 2 with the “Arm Stay” button of the Panel in the App:
2022-02-22T14:27:35.381650418+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.dscstayswitch”,“component_id”:“main”,“state”:{“value”:“on”},“attribute_id”:“switch”}
2022-02-22T14:27:35.393115918+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.partitionStatus”,“component_id”:“main”,“state”:{“value”:“Arming stay”},“attribute_id”:“partStatus”}
2022-02-22T14:27:35.412353793+00:00 DEBUG Envisalink 2.1 TX > 0312C6
2022-02-22T14:27:35.435850793+00:00 DEBUG Envisalink 2.1 DSC P2 Panel device thread event handled
2022-02-22T14:27:35.440376127+00:00 TRACE Envisalink 2.1 Received event with handler LAN client handler
2022-02-22T14:27:35.443509293+00:00 DEBUG Envisalink 2.1 RAW DATA RECEIVED: 50003129
2022-02-22T14:27:35.447096252+00:00 INFO Envisalink 2.1 RX < 500 - 031 - Command Acknowledge
2022-02-22T14:27:36.392298043+00:00 TRACE Envisalink 2.1 Received event with handler LAN client handler
2022-02-22T14:27:36.395624710+00:00 DEBUG Envisalink 2.1 RAW DATA RECEIVED: 6562D3
2022-02-22T14:27:36.398690377+00:00 INFO Envisalink 2.1 RX < 656 - 2 - Partition DSC P2 Panel Exit Delay in Progress
2022-02-22T14:27:36.403285877+00:00 INFO Envisalink 2.1 {type: partition, name: DSC P2 Panel, value: 2, status: exitdelay}
2022-02-22T14:27:36.428630460+00:00 DEBUG Envisalink 2.1 Processing Partition #2 exitdelay (Exit delay): priorstatus=Ready
2022-02-22T14:27:36.432157335+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.partitionStatus”,“component_id”:“main”,“state”:{“value”:“Exit delay”},“attribute_id”:“partStatus”}

2022-02-22T14:28:21.318849128+00:00 TRACE Envisalink 2.1 Received event with handler LAN client handler

2022-02-22T14:28:21.321954991+00:00 DEBUG Envisalink 2.1 RAW DATA RECEIVED: 65220FF

2022-02-22T14:28:21.325653516+00:00 INFO Envisalink 2.1 RX < 652 - 20 - Partition DSC P2 Panel Armed Mode Away

2022-02-22T14:28:21.336517997+00:00 INFO Envisalink 2.1 {type: partition, name: DSC P2 Panel, value: 2, status: away}

2022-02-22T14:28:21.343668837+00:00 DEBUG Envisalink 2.1 Processing Partition #2 away (Armed-away): priorstatus=Armed

2022-02-22T14:28:21.347232762+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.dscdashswitch”,“component_id”:“main”,“state”:{“value”:“on”},“attribute_id”:“switch”}

2022-02-22T14:28:21.372619604+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.dscawayswitch”,“component_id”:“main”,“state”:{“value”:“on”},“attribute_id”:“switch”}

2022-02-22T14:28:21.388392964+00:00 INFO Envisalink 2.1 <Device: 668195fd-5f70-474d-a92c-5eb3439e029d (DSC Exterior Panel)> emitting event: {“capability_id”:“partyvoice23922.partitionStatus”,“component_id”:“main”,“state”:{“value”:“Armed-away”},“attribute_id”:“partStatus”}

Regarding the webCore issue. I have recreated the command in the piston and realized that “setPartitionCommand” is no longer available in webCore:

Any ideas why the command is no longer available?
I tried setPartitionStatus but that doesn’t work if I use commands such as armstay and disarm.

Thanks for posting the log. Indeed, it shows that when you are sending an arm STAY command to your DSC, that the DSC is coming back with a change to armed AWAY mode. The software is doing what it is supposed to do and sending the right command (0312). There must be something configured on your DSC that is causing it to only arm in AWAY mode.

Are you able to arm STAY mode from the Envisalink app or from the DSC keypad?

Regarding webcore, I haven’t been able to reproduce the problem you are seeing. I have tried creating a Piston with both a primary and secondary panel and the setPartitionCommand is available and is working for me.

I’m really sorry you are having these problems. So far it’s not clear what the solution is.

I’ve not thought of checking if it arms correctly via Envisalink. It used to work fine, but I had some work done to the panel some months ago, so it could be that stuff got messed up.

Any idea why the setPartitionCommand is not available? Is there an alternative method to arm/disarm the panels? (Arming/Disarming via webCore is the main reason why I integrate my alarm with Smartthings and without that ability I’m stuffed.)

Congrats @TAustin and the community members who helped make this possible. I thought I was stuck with a dead-end, failing Napco wired/wireless/ST wireless hybrid system, but with this latest Edge driver I feel like DSC+EVL4 has matured to be a real path forward for me. Keep up the great work!! I hope to join your community Edge team soon as I can buy and bench-stage a new system.

If anyone has any advice on upgrading to or buying DSC, I’d love to talk about it. DM me. Seems like alarmsystemstore.com is a good DIY source? They have awesome training videos. I installed my own Napco 25+ years ago. I used @ogiewon 's awesome ST Anything DTH with an ESP32 board wired to a Napco Wireless keyfob to create an ST/presence controlled arm/disarm/panic for my old hardwired Napco as a bridge until I could get something better. (That was a fun 8 month project, and it works about 98% of time time, but will work 0% of the time when ST abandons Groovy – Bronx cheer). The Napco keypads had a 4-zone wired controller, at least the DSCs have 1 zone so I could just combine whatever zones I have to the keypad now into it (it was much easier than home running extra quad cable, especially for the door sensors right next to the keypads). Really excited about starting this project. Thanks in advance!

Not sure if I should go 2-way or 1-way wireless to the DSC and use their sensors where I currently have Napco wireless, or just put all wireless contacts/sensors through ST, and have STHM or ST automations open a dry contact to the DSC or something (perhaps an EV Edge driver panic?) to signal a break in.

I presume this issue is unique to your second partition, so maybe they programmed it uniquely for some reason.

This one is still a mystery. I think what I would do is try to start from a clean slate as far as webcore is concerned. Remove all your DSC-related devices from its list of included SmartThings devices. Remove references from any existing pistons or even delete the pistons if you can. Then start over by first adding just one partition panel device to webCore and create a new piston to send it a command and see if you get any further. If deleting your existing pistons would cause too much rework, try just creating a NEW piston and seeing if the setPartitionCommand is available. This has got to be some kind of out-of-synch situation between SmartThings and webcore.

Another thought: I don’t know what version webCore you are using, but I just saw a notice that there is a new one available. You might try upgrading.

Webcore is not the only way to arm/disarm panels. In fact it’s kind of the outdated way. You can use Automation routines (easiest) or Rules to do so as well. I know you’ve got a lot of time and effort invested in your webcore pistons, but it may be time to look at what you can get migrated away and onto the newer methods.

I moved to the new driver. I may have been seeing this prior but didn’t notice it. I am seeing two events logged for every 1 event. Is: when a door opens I see see two door open events. Any ideas?

You do not have any Stay/Away motion detector zones. You only have entry and perimeter sensor zones, and there is no functional difference between stay and away arming for those types.

Most panel models will let you arm Stay still, there just won’t be any difference in how it works VS Away. The DSC panel however it looks like will always override stay mode and will not arm stay if there are no sensors using sensor group 5, 6, or 9.

It’s a bit of a catch 22 with the DSC Powerseries panel. Looks like to arm with no delay, you need motion detector zones.

If you have an unused wired zone, one option would be to just wire a resistor across a zone terminal and common input, and program it as a motion detector.

This is one way from DSC-EV4 to ST/STHM, as a contact closure type device so the alarm in DSC is logged in STHM? Or, is it just driving a siren device directly?

Is there any “soft” way to have ST trigger a DSC alarm, without, say, some kind of external relay device?

I understand where you’re coming from, but does this imply an investment in proprietary DSC wireless sensors, etc. rather than ones that work with ST/STHM/any hub type system?

I think you meant to direct this comment to @949BFN.

Thanks for the insight.

This is a way to trigger the siren connected to the DSC, from the SmartThings mobile app or automations by using one of the PGM commands that can be sent to the DSC. The DSC board itself has to be jumpered/wired to enable this capability. I have a link somewhere to where someone explained out this could be done, if you are are interested. I believe this only triggers the siren, but doesn’t necessarily put the security system into an alarm state. I don’t know of any other “soft” way to intentionally trigger the DSC alarm.

Not sure how to answer this. I just don’t know of a standard way right now to more closely integrate the two systems. DSC has been around for decades, but STHM is still evolving.

I removed both panels from the webCore device list and renamed the Panels in the Smartthings app. I then re-added one of the panels. I didn’t help, unfortunately. The setPartitionCommand is still not available in webCore:

Edit:
I removed all devices and panels to uninstall the driver. Reinstalled the driver and only added the primary partition, enabling only a few zones.
Next, I added the Panel as a device to webCore.
Still, no luck. I’m on the latest version of webCore (v.0.3.114).

I uninstalled 2.1 once again and re-installed the driver from your test channel and:

What I noticed is that with driver 2.1, the Panels are available under Group 1, Alarms and sirens when adding devices to webCore.
With the test driver, the Panels show up under Group 2 > refreshable devices.

I will do some tests to see if adding the refresh capability back to the device makes a difference. Thanks for pointing that out.

Just so I’m clear, you are having this issue with both the primary and secondary panels, correct?

Quick update: I’ve tried a couple things here, but have not been able to solve this. I just posted for help on the webCoRE community boards, so fingers crossed someone there might have an idea of what the problem is.

Yes, both panels show the same issue.
Hope you’ll be able to find a solution.

This does not trigger the alarm state. This toggles the PGM pin which turns on/off a siren, or whatever else is on this pin.

There are two PGM on 1832 and four PGM on 1864. This is an OR logic state with the alarm state.

The PGM pin could be used to disable a door lock for instance…

When i asked T to add this, it was just as someone guessed, to expand smartthings to use that PGM for a secondary alarm setup or anything in between…

@TAustin My system was working great on the beta version. I decided to go ahead and remove all the devices and the old driver and upgrade to 2.1. However, it will not install correctly. I’ve attached a log. The panel appears, but this is all I can do. When I attempt to add a device in the panel settings (ie. zone 1 = contact), nothing appears in the log. I seem to remember from my prior successful installation that there was a good bit of log output for each device added. The panel otherwise remains completely unresponsive, no matter what settings I change.

I assumed this was somehow related to the ST caching issues and the old driver, but I have now waited > 24 hours and cleared the cache in my app with no improvement.

DeviceLifecycleDispatcher: evlDriver
  default_handlers:
    doConfigure:
    added:
    infoChanged:
    init:
    driverSwitched:
    removed:
  child_dispatchers:

2022-02-26T03:04:21.854881450+00:00 TRACE Envisalink 2.1  Setup driver evlDriver with Capability handlers:
CapabilityCommandDispatcher: evlDriver
  default_handlers:
    partyvoice23922.dscstayswitch:
      setSwitch
    partyvoice23922.partitioncommand2:
      setPartitionCommand
    partyvoice23922.dscselectswitch2:
      setSelection
    alarm:
      both
      siren
      off
      strobe
    partyvoice23922.dscawayswitch:
      setSwitch
    partyvoice23922.zonebypass:
      setZoneBypass
    securitySystem:
      armAway
      armStay
      disarm
    partyvoice23922.dscdashswitch:
      setSwitch
  child_dispatchers:

2022-02-26T03:04:21.858118033+00:00 INFO Envisalink 2.1  v2.1 Driver Started: supporting EyezOn EnvisaLink 2DS/3/4
2022-02-26T03:04:21.864073158+00:00 DEBUG Envisalink 2.1  Number of devices assigned to this driver:    0
2022-02-26T03:04:21.874466367+00:00 TRACE Envisalink 2.1  Received event with handler environment_info
2022-02-26T03:04:21.878461617+00:00 TRACE Envisalink 2.1  Received event with handler environment_info
2022-02-26T03:04:21.881764117+00:00 DEBUG Envisalink 2.1  Z-Wave hub node ID environment changed.
2022-02-26T03:04:21.885877033+00:00 TRACE Envisalink 2.1  Received event with handler discovery
2022-02-26T03:04:21.892643617+00:00 INFO Envisalink 2.1  Creating Primary DSC Panel Device
2022-02-26T03:04:21.896404992+00:00 INFO Envisalink 2.1  Creating Partition #1 Panel (DSC:P1): 'DSC Primary Panel'
2022-02-26T03:04:21.904695700+00:00 DEBUG Envisalink 2.1  Exiting Discovery
2022-02-26T03:04:21.907872367+00:00 DEBUG Envisalink 2.1  discovery device thread event handled
2022-02-26T03:04:27.656821536+00:00 TRACE Envisalink 2.1  Received event with handler discovery

I’m holding out on moving away from the beta until this all clears. Thanks to everyone for the testing.

1 Like

From the log it looks like the panel device never got properly created. Are you 100% certain that you had deleted all previous devices (including panel(s)) + uninstalled the driver? When a device cannot be created, it’s sometimes because there is already one existing.

I just installed from scratch from the channel just to make sure I didn’t get a similar problem, but it was OK for me.

Since the panel device did not appear to get properly initialized, the best course of action is to delete whatever you see in your mobile app, and uninstall the driver. Just to be safe, at this point, if you can, reboot your hub. Then after you’ve given it a minute or two to restart, try reinstalling the driver again.

The log is very useful so if you can capture the startup during the Add device / Scan nearby, that would be helpful.