Let me know if it happens again. We should try to get some driver logs to see what may be causing it.
@7522
Hi - If you are still around, I could use some clarification on your post from September:
I’m looking at making some updates and would like to see if I can address your need.
If you use the *9 command from a DSC panel, the device partition status field will in fact show “instantstay”. This isn’t currently listed as a selectable value for automations, but I can address that.
My point of view is that Armed-Stay is the accurate status of the system, regardless of what kind of arm-stay you do - either using *9 from the DSC panel, long-pressing the Stay button on the DSC panel, selecting “Arm-Instant” from the SmartThings device partition command button, or pressing the “Arm Stay” button on the device Controls screen.
I’m not really clear what you mean when you say:
I was also thinking it could be possible to add a field that would indicate the most recent kind of arm/disarm, since I also want to display a user name based on the alarm code (a request from another user). I don’t know if that would address what you are looking for, or if I just added the instantarm state to the list of selectable partition status attributes in automation creation.
I am not super panicked about it. This is the first time this has happened since implementing this driver months ago. Maybe just a one off.
Same here since 2 days ago according to logs. I noticed it only this morning.
Rebooted everything but still no go 
The Alarm Panel DSC shows status Ready but sensors do not update.
Automations do not work.
UPDATE:
It started to work again … weird
I just received my Envisalink. Can I be an early tester?
1 Like
I have the same problem. Alarm panel shows ready but in SmartThings the sensors are frozen. It happened last night for about an hour then it worked. This morning it happened again but now it is no longer working. Rebooted all devices and nothing. Any ideas???
Peter, don’t know what fixed it, I just randomly plaid with it, rebooting the hub, and the card itself and then it started to work again .
Might fixed too but I do not know why.
Let’s hope it will stay that way 
Hi- you are welcome to use the current driver on my test channel. I am working on a new version I hope to make available by end of the month.
1 Like
Just a note to say thank you for all your work. Spent some time creating a fork to support my ElkM1 based on your good work. Reading your solution was invaluable and made it possible for a Smartthings Edge & LUA newbie to butcher something together that works well for the ELK. It also gave me an appreciation for how hard it must be to support all the disparate implementations as you do here.
Thank you so much for sharing your work and time!
Great to hear and thank you!
Todd,
Is it possible to make the alarm system driver a parent/child with all the zones as children?
For me that would put me well under the 200 device limit.
If smartthings was stable I could remove 3 virtual devices of my 203 devices if I had to onboard a problem device or update firmware, but not something I want to do daily or weekly, as on 48.3 I always have 5-9 Zigbee devices offline, and not practical for a person with even more devices than I have.
Has something changed? My understanding was that child devices still count towards the total number of devices, and therefore the total device limit.
I was lead to believe that changed with edge, my device count, both physical and virtual devices count matches your API browser -1, as it seems to include the hub. Which also matches the app’s count of my devices. If I added my multi-components devices children it would be significantly higher.
Maybe @nayelyz could comment on this?
Child devices count as devices if the have there own device tiles.
If they are just multi-component devices with no child device tiles they won’t be counted.
ANNOUNCING VERSION 3 OF THE DSC/ENVISALINK DRIVER
I’m pleased to make available the next iteration of this driver that includes several enhancements as requested by the community, as well as some fixes to known issues.
This is a NEW driver and therefore will not automatically replace your existing driver. This is so YOU have control over when to upgrade, since it will be disruptive to your existing setups. For example, when you are ready to move to the new driver, you will be required to create all new panel and zone devices. This will in turn require you to redo any automations you have.
Your existing V2 driver will continue to run normally and I’ll not even remove it from the channel for a few months. So you can decide when you are ready to move to the V3 driver.
Version 3 Enhancements
- Clean-up of known annoyances in V2 driver (field labels, button issues, etc.)
- Ability to initiate PGM1, PGM2, PGM3, PGM4 commands from automations
- Fixes to instant arm commands
- Partition status distinction between regular armed and instant-armed states (@7522)
- Know who in the household last armed/disarmed the system
- addition of last-armed user field in panel device; user names are configured in new device Setting option
- Enhanced trouble condition information
- addition of trouble type field in panel device to specifically indicate Battery, Bell, AC Power Lost, etc. trouble conditions
- Improved notification and recovery of Envisalink connection loss
- addition of periodic Envisalink connection monitoring: poll frequency in minutes can be configured in primary panel device settings; if Envisalink connection found not to be active, then all devices will be set to offline status and partition status set to ‘Offline’, enabling automation triggers.
Additional information is available in the driver README file on github.
A special thank-you goes out to @BobR for his ideas on enhancements and willingness to test the driver out before I released it.
Installation
Before proceeding, you will need to delete any existing V2 panel and zone devices, and remove the V2 driver.
You can install the V3 driver from my shared projects channel. Enroll your hub if not already, and choose to install the “Envisalink 3.0” driver.
For the remaining steps please refer to the README instructions.
If you follow my instructions carefully you should be back up and running within a matter of minutes (not including re-creating any automations you need).
4 Likes
My DSC system with EVL3 worked perfectly with your Edge Driver for a while. Unfortunately, a lightning took out most of my network items includes EVL3.
Just replaced it with EVL4 today and it’s running fine with EyeZ. However, I couldn’t make it work with my ST with your Edge Driver 2.1. Tried to uninstall Ver 2.1 and install ver3 instead but it says “Cannot uninstall because the driver is in use”. Can you kindly point me to the right direction: (1) what I need to do to make it work again with the current V2 driver, or (2) how can I move to ver3?
Thank you very much for making this available and taking time to help me. Have a great day!
That’s a major bummer!
Usually if you can’t UNinstall a driver because it is “in use”, it is because you haven’t deleted all of its associated devices. Make sure you first delete any and all panel and zone devices first. You can use Samsung account or API Browser+ to check for any devices assigned to that driver if you’re not finding them with the SmartThings mobile app.
But to answer your questions:
Hard to say what the problem is without seeing some driver logs, but are you sure you have the right password to the EVL4? The default is ‘user’, and don’t get this confused with the eyes-on password, which is something different. Also, since you had to re-do your network, be sure that the SmartThings hub and EVL4 are on the same subnet and that you have the right IP address configured.
I’d refer you to my post above and/or the README file.
Happy to answer any other questions or diagnose this further with you if needed. You may need to get the SmartThings CLI so you can get driver logs if you aren’t able to get things working.
1 Like
Many thanks for the quick response. It came back with your help!
As I mentioned, most of my network devices are gone. The UniFi router (USG) and all switches are gone, the new Eero mesh network gives out DHCP for my ST Hub. I did remember to configure the new EVL4 with old IP and did not realize I need change the IP for the Hub as well. As soon as I changed the Hub IP, it comes back! I can check the logs from CLI as well.
However, it seems there is some issues. For example, the Front Door shows offline on my ST app but actually changes its status when I open/close it. It shows normal on EyezOn as well.
If you are okay and have time, I will msg you instead of posting here for more details.
Thanks again for the kind help! Really appreciate.