Which DTH are you using? Just as a test, change the exit delay to 59 and watch Live Logging. Does it still show errors?
Iām thinking probably the hub is not bound to a location, causing the location var to be null and thus resulting in the NPE.
@segarm can you validate/verify if the hub is attached to a particular Location in your app?
Yup, exactly. I just saw that in your Github code. Iām betting thatās it.
Thatās your code 
1 Like
Well donāt forget to give credit back you yourself as well, you did all the heavy lifting and effort!
Lol I meant your line of code.
1 Like
Thank you @vadimb & @johnconstantelo for helping me setup an automation (with my SmartThings Ver-2 Hub)!
Yes, my hub was not bound to a location. I added it to a location in my SmartThings app - now I donāt see errors in āLive Loggingā but it still isnāt arming my EyezOn security.
Please see an image about it from SmartThingās āLive Loggingā
How are you arming it? Leave live logging up and turn it On (via the new appās UI). What does live logging show?
Also, do a Refresh and what does live logging show? To do a Refresh, press/hold the on/off button and pull down. When you do that you will see the refresh icon, so when you see that let go and it will refresh, like this:
And then Live Logging should show these messages:
Thanks for the information, @johnconstantelo and @vadimb! My apologies for the delayed reply.
Attached is what I haveā¦
-
Device list shown in my ST App
-
Eyes-On Stay - Cloud device
-
ST automation routine
-
Live Logging showing details when STAutomationRoutine ran at 3:30PM. The log shows the System status is āunknownā but my Vista20P security was āReadyā for arm.
-
Live Logging showing details when I āRefreshedā the Eyes-On Stay device at 4:42PM in my ST app.
Hello @johnconstantelo & @vadimbā¦
Please ignore some information you see in my previous post (#89). I apparently had a custom partition name in my Eyes-On account - thatās why the ARM sequence couldnāt find the current status of my Vista-20P.
After updating the custom partition name (in the switch), the arm sequence is correctly identifying the status but itās still not arming my system that is āready to armā. Please see the attached log.
I now have 59secs exit delay in my switch but I know my exit delay is much longer than that in my Vista-20P panel. Could that be the reason?
Now that you got past the initial problem I suggest you try the other device handler code. Iām betting that the variant you installed now is not the correct one for your system.
Also do make sure that you set the delay in the app to line up with what you configured in your system. Itās not essential for making the alarm arm/disarm but is important if you want the app to automatically refresh with the up to date status.
Hello @vadimbā¦
I switched the Device Handler to version-02 from version-01, and changed the delay settings to 120-secs in the switch (please note; my Vista-20Pās exit delay is 90-secs) - I still see the same information in the logs and my system does not arm 
Please see the attached log.
Welp, my problems persist. The system always seems to arm fine. Sometimes the system successfully disarms when I manually execute the āDisarmā routine (that just turns the switch off). Sometimes it doesnāt work when I run manually. But, it NEVER disarms when I run the Disarm routine according to a schedule. You can see this morning, the system tried to turn the alarm switch off 4 times ā 6 AM, 6:03, 6:05 and 6:30 (all on schedules I set for multiple tries) ā but when I woke up at 7 the system was still armed.
Also, while the system is supposed to arm at 1 AM, and always arms fine manually, I have noticed in my New App history a couple times where the switch didnāt get set to āonā until 2 or 3 hours after the routine ran (and I was already asleep)ā¦perhaps thatās what is happening with my disarmāitās just taking a long time to work through the internet, and Iām waking and disarming before the auto-sent command executes?
Any thoughts are appreciated! Also, Iām feeling dumb, but Iām having trouble with āLive Loggingā in the IDE ā I just get a message that looks like what Segra posted in Post 78 which never updatesā¦
Thanks!
I can arm and disarm my alarm via the eyezon app. I can also turn on and off lights via the smartthings app but I receive the following error regardless of which device handler I use.
āA Network or server error occurred. Try again laterā
Log:
Determined system status to be Unknown at 09-23-20 8:17 PM
Received request to disarm system. Mode: Away
Still having the problem: arms fine, but wonāt disarm with a scheduled routine. But, manually running the routine disarms. I know this sounds like I have a problem with my schedule, but I promise I donāt ā all other things in that routine switch on or off as appropriate, but not the Alarm Switch.
It must be a problem somewhere with the ST app then. Itās running the exact same handler code in both cases so I canāt think of anything that would be wrong with the device handler itself if it works in the case of manual activation. Did you try to edit your automation (thatās not working) and replace the Alarm Switch with another one of your devices and seeing if that one works?
In the new SmartThings app, is there a way to sync up/link the SmartThings Home Monitor security status with the DSC/Envisalink arm mode? That is, the ability to control the arm status of the DSC/Envisalink alarm with the SHM panel?
I recall I was able to get this linked up in the SmartThings Classic app (I canāt remember how I did it though, it may have been the original DSC/Envisalink integration.
Yes via an Automation. Hereās a screenshot of an automation for when my alarm panel turns On which then sets STHM to Armed (stay):
Hereās an example of the opposite behavior:
Thanks for this! It is working for the most part but I do sometimes get a āserver errorā message within the STHM widget when I was testing the routines by tapping on arm (stay) and disarmed. It seems a bit unstable. I guess this will do until something better comes along later.