NOTE: As of Oct 2022 this solution no longer works. Please use the Edge Driver instead.
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.
You can find the project here: GitHub - vadim-bach/EyezOn-SmartThings-Switch: Integrates SmartThings with EnvisaLink-enabled home security alarm system through the use of the Eyez-On server to enable automation for arming/disarming system.. I’m hoping you guys will benefit from it as much as I have. Enjoy and let me know what you think!
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.
@vadimb… Will this work with an Envisalink 4 connected to a Honeywell Vista-20P panel? Thanks for all your work in putting this together.
Yes it should, so long as you’re using EyezOn to arm/disarm it.
Thank you @vadimb, I’ve been waiting for this functionality for quite some time. I’ll give this a try as soon as I get home from work.
Great! Let me know how it goes, or if you run into any issues. Cheers!
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?
Also take a look at the logs and let me know if you’re seeing any errors there reported by the device handler.
Yep that is the one I used for Envisalink 3
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.
form method=“post” action=“https://www.eyez-on.com/EZMOBILE/index.php?mid=xxxxxx&action=s&did=xxxxxx&type=16&dmdben=f&rand=928182747”><input type=“hidden” name=“extaction” value=“armaway”
form method=“post” action=“https://www.eyez-on.com/EZMOBILE/index.php?mid=xxxxxxxxx&action=s&did=xxxxxx&type=16&dmdben=f&rand=928182747”><input type=“hidden” name=“extaction” value=“armstay”
I tried to DM you but I don’t have that option.
I’d need to also see the body of the request that gets sent (Network tab). Just make sure to obfuscate your PIN and account # as you’ve done above.
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?
It worked! I swear I have a V3…its actually a very old version purchased 1/2013.
Thanks for the help!
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.
Indeed! Look at “type” for his. It’s 16, where mine was 15, and yours at 18. Any idea what “type” means/does?
Not sure what the type is for, but evidently it doesn’t make much difference as far making the server process the commands sent to it.