NOTE: As of Oct 2022 this solution no longer works. Please use the Edge Driver instead.
Hey guys!
I created a SmartThings device handler that integrates nicely with EnvisaLink/Eyez-On and allows you to automate the arming/disarming of your DSC home alarm system via SmartThings routines, Alexa, etc. It’s super easy/quick to setup and doesn’t require any additional hardware beyond your EnvisaLink and SmartThings hub. I’ve been test driving it myself for several months now and it’s been working wonderfully.
Note: The status updating doesn’t work reliably (hadn’t had time to dive deep to figure out why) so keep in mind that it will not accurately reflect the arm/disarm status. This handler is exclusively made to enable creation of automatons around the EyezOn system. For up-to-date system status you’d still want to go to EyezOn.
I can’t seem to get this to work. I triple checked the device and account id’s just to be sure they are working but I get nothing. It looks like it runs but nothing happens. I am using Envisalink 3 with a DSC panel and I use eyezon to control the alarm. Anything else I should try?
No Errors that I can see on the device. Here are the logs from the hub when I try and arm it in stay mode (away is the same)
11:33:14 PM: info Determined system status to be Ready at 03-28-20 11:33 PM
11:33:11 PM: info Operation armstay successfully submitted, now waiting for system exit/disarm delay (1 sec) for confirmation…
11:33:11PM: info Received request to perform operation: armstay
11:33:11PM: info Determined system status to be Ready at 03-28-20
11:33:11PM: info Received request to arm system. Mode: Stay
11:33:11 PM: info Received request to arm system. Mode: Stay
Here are the device logs:
[2020-03-28 11:33:14.982 PM CDT 55 minutes ago ]DEVICE switch off Eyez-On Stay switch is off
[2020-03-28 11:33:11.667 PM CDT 55 minutes ago ] DEVICE switch exiting Eyez-On Stay switch is exiting
[2020-03-28 11:33:11.652 PM CDT 55 minutes ago ]DEVICE alarmActivity 03-28-20 11:33 PM Eyez-On Stay alarm activity is 03-28-20 11:33 PM
I wonder if different minor versions of the hardware will result in yet other param values being used in the call to the server.
I’m not sure how tech-savvy you are but I’ll copy over the same instructions I sent out to John earlier to try to diagnose the source of the problem and get code that fixes it. Let me know if this makes sense to you:
“It’d really help if you can see the POST command that gets sent to the Eyez-On server when you use it to arm the system successfully (via the link). Would you be able to capture that? You can do so by pasting the URL into your browser and then opening the browser’s dev console and going to Network tab. When you hit on “Arm” button on the Eyez-on Website you should see a POST request to the server appear there. I’m wondering whether there’s any discrepancy between that and the request that my device handler is putting out (in terms of parameters in the call).”
Thanks for the help! I can do that for sure…see below. I put XXXX in place of the account id and device id. It looks like the rand= changes each time I press the arm button (I had to remove some of the HTML tags as this was interpreting the tags and displaying HTML even after using the xmp tag to display the HTML.
Actually I noticed it says “extaction = armaway/armstay” above. This very much looks like the request sent by my EnvisaLink (v4). Can you try the v4 code just for the heck of it?
Oh wow that’s great that it works! But this also means that the variation me and John seen is not actually related to V3 vs V4 but based on something else instead altogether.