@vadimb Thx for adding the “Max” and “Instant/Night” modes to the code. Just to make sure I am understanding correctly on what I would need to do to get them added is create two new devices for each new variable (Eyez-On Max and Eyez-On Instant) and then copy account ID, device ID, etc from the Eyez-On portal into the fields. Then I also need to copy the new code into the text field?
Complete instructions are in the README on GitHub.
You’d have to start by going to the SmartThings IDE and replacing the current code for the device handler with the new code I provided. Once saved and published you’d see the new settings show up for any swithces you created up to this point. You can now choose the new modes for those; also make sure to populate the new “code variant” field in the settings as well. Alternatively you can just delete those switches and create new ones from scratch following exact instructions in the README.
@vadimb, I updated and published the device handler code in IDE, and added two new virtual switches (Max/Instant). Also updated the variant field properties for all 5 switches (Stay/Away/Night/Max/Instant). For me, variant 1 always worked.
I’m able to arm the system properly into the new Max and Instant modes, but I’m unable to unarm the system using the same ST virtual switches. I’m getting “A Network or server error occurred. Try again later” error message from the mobile app. I tried toggling to variant 2 in the switch properties, but that had no change, and it seems like I can’t arm the system using variant 2. I’ve gone back to variant 1 on all my switch properties, but im not able to unarm the system in any mode using the mobile ST app.
I’m not sure what the issue is… I will say that in the past, not sure if this helps, but the switch status is not always reflected properly. For example, if the system is actually armed in away mode, the switch might show “Off” as the status instead of “On”. I never really cared about this, as I had geofencing parameters enabled to arm into and out of away mode (or night armed via on demand voice assistant), and scheduling programming to unarm, and everything works/worked reliably.
hmmmm…
maybe @Tech_East can chime in with some user testing?
Ye I’m thinking it’s probably related to that switch status issue you described. I haven’t had much time to look into it but I’ve been mostly treating it as low priority given the whole purpose of the switch was to enable integration with automations - not via manual toggling. I know there was a bug in SmartThings for the longest time related to the refreshing of the state, I don’t know if it ever got fixed.
Did you try to test disarm functionality via a routine (instead of manually toggling it)? It should work that way (I’m running this same updated code myself now).
Yes, I just tried to unarm via a ST automation, and its not working. I can arm via a scene however.
Just to be clear is the disarm broken only for the new modes or it’s not working for you for Stay/Away switches also?
I just tested all of the modes, it is just the Instant and Max modes that are giving me a server error. I went back and re copied the code into IDE, rechecked my mac ID/device number, account number, etc…Logged out of IDE, logged out of the mobile app, rebooted phone, I can’t figure out what is wrong with the disarm function for Max and Instant. I would like to help figure this out as I should probably use Instant instead of Night in the evening, and Max for vacations.
Ok so the other modes are disarming fine…that’s good to know. unfortunately I won’t be able to reproduce the error on my end as I don’t have the instant/max modes but it sounds to me like the server request might be somehow different for those when disarming. Can you go through the same process as before and send me the browser logs specifically coming out of hitting that disarm button when system is in one of those two modes?
Ok, here is for Armed Instant. lets just focus on this one? I’m able to arm into Instant, just not able to disarm This is:
- Clicking “My home”
- Clicking disarm
- executing PIN input
Image Removed**
OK I think I know what’s going on. I assumed the status would show up as “Instant Armed” whereas it ends up being “Armed Zero Entry Delay”. I updated the code, give it another go. If it works, please throw me the same screenshot (left hand side namely) but for Max mode.
I updated my IDE code to your revised code, and disarm now works for the Instant arming button in ST. Here is the XHR code for disarming Max (looks like its also “Armed zero entry delay”:
Image Revoved**
Let me know when the revision for disarming the Max mode is updated, and I’ll copy/paste it into IDE and test it out. Thanks so much for all of this!
Updated. .
I think you nailed it @vadimb . I was able to successfully arm and disarm Max from the ST mobile app, and confirmed arm/disarm status in Eyez-On and on my Honeywell keypads.
I’m running the Instant arm in my daily PM bedtime and AM Alexa routine, and that worked successfully last night and this AM. Think we can say its all good, I’ll post back if there are any noted issues. Thanks so much @vadimb, this really makes the Honeywell alarm systems MUCH easier to self monitor and ties them into smartthings and voice assistant routines.
For all coming across this post, you need the Envisalink Eyez-on EVL-4 module added to your alarm system, and a custom device handler in your Smartthings IDE. Please take the time to read the github README instructions for the device handler code to add this functionality. You’ll need to copy and publish the device handler code into your Smartthings IDE and create and program the virtual Envisalink “switches” in your Smartthings properly per the instructions. Once you’ve done that, the skies the limit as far as automating your alarm system. You can geofence your alarm to arm/disarm automatically, set up routines/scenes using your voice assistant, and pretty much set up whatever scheduling and/or other automations you’d like in Smartthings to control your alarm system.
2 Likes
Vadim, nice work. I had been using redloro’s solution but all went bust when I moved from classic app to new app. I did have one glitch as I did not enter the device MAC address alpha characters in upper case. Who would have thought (ok, you did say it was case sensitive). The delay in status update is also a bit confusing, but once you get outside initial testing, I can’t see it’s worth doing differently, just might be useful to point it out for initial testing purposes. Would be great to see it tied into the ST home monitor, but can live without.
One more twist. I got an external monitoring service sometime after getting the envisalink and they had me use connect2go.com which looks like a white label of the eyezon site. I can still log in to the eyezon site, but it doesn’t show any devices, whereas connect2go shows it. Oddly though, everything still seems to work, and looking at the code I can see you use the eyezon site, so not sure what’s going on on the back end but it works so not going to ask too many questions.
Thanks Martin.
So the status thing is definitely non-ideal but unfortunately SmartThings is annoying as hell to work with and seems to be in a persistent half-broken state. Those status updates used to work at some point but seem very unreliable, for one reason or another. I haven’t had time to dive deep to figure out what’s going on. Good suggestion around adding it to the home monitor. If/when I have bandwidth to work on it I might give it a go.
As for connect2go i’m not sure what they’re doing on their end but for this code I’m just using the exact same APIs that trigger when you go to arm/disarm the system via the EyezOn website/app, as you already pointed out.
Hi Vadim. Regarding connect2go.com, I changed the device handler to use that URL and instead of EZMOBILE for the path, just used “/m/” since that’s what I see as the remote portal link generated. Then set up the switch in the same way you indicate. I’m not very familiar with the developer tools and saw what someone else posted and I don’t see that easily in my Chrome dev tools. As I mentioned above, it looks like connect2go is just a white label of the eyezon website, so I was hoping it would use the same commands. If it’s not the same, then I won’t pursue further. I’m wondering if the below copy paste from the dev tools POST even helps you to determine that:
Request URL: https://www.myconnect2go.com/sec_details.php
Request Method: POST
Status Code: 200 OK
Remote Address: 67.207.159.154:443
Referrer Policy: strict-origin-when-cross-origin
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 12404
Content-Type: text/html; charset=UTF-8
Date: Sun, 29 Aug 2021 20:47:47 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive: timeout=5, max=100
Pragma: no-cache
Server: Apache/2.4.10 (Debian)
Vary: Accept-Encoding
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: keep-alive
Content-Length: 69
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=mgradr4it078s1tnla8veoj7u4
Host: www.myconnect2go.com
Origin: https://www.myconnect2go.com
Referer: https://www.myconnect2go.com/sec_details.php
sec-ch-ua: “Chromium”;v=“92”, " Not A;Brand";v=“99”, “Google Chrome”;v=“92”
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
pin: xxxx
did: xxxx
mypartition: 1
action: harm_stay
submit: Enter
Looks like they have their backend set up in PHP and I see they use cookie session management for authorization of requests (may want to not include the session cookie in public posts - kindo a bad idea). But because of this there’s not really an easy way to automate the integration as I’ve done with EyezOn directly because you’d need to get SmartThings to authorize on your behalf. So certainly more involved than just firing a request to a publically accessible URL with a password. So in that regard the way they’re doing it (which is not overly correct or secure) is also what allowed me to write this handler in the first place.
— Vadim
| MartinNYC Martin P
August 29 |
- | - |
Hi Vadim. Regarding connect2go.com, I changed the device handler to use that URL and instead of EZMOBILE for the path, just used “/m/” since that’s what I see as the remote portal link generated. Then set up the switch in the same way you indicate. I’m not very familiar with the developer tools and saw what someone else posted and I don’t see that easily in my Chrome dev tools. As I mentioned above, it looks like connect2go is just a white label of the eyezon website, so I was hoping it would use the same commands. If it’s not the same, then I won’t pursue further. I’m wondering if the below copy paste from the dev tools POST even helps you to determine that:
Request URL: https://www.myconnect2go.com/sec_details.php
Request Method: POST
Status Code: 200 OK
Remote Address: 67.207.159.154:443
Referrer Policy: strict-origin-when-cross-origin
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 12404
Content-Type: text/html; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive: timeout=5, max=100
Pragma: no-cache
Server: Apache/2.4.10 (Debian)
Vary: Accept-Encoding
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: keep-alive
Content-Length: 69
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=mgradr4it078s1tnla8veoj7u4
Host: www.myconnect2go.com
Origin: https://www.myconnect2go.com
Referer: https://www.myconnect2go.com/sec_details.php
sec-ch-ua: “Chromium”;v=“92”, " Not A;Brand";v=“99”, “Google Chrome”;v=“92”
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
pin: xxxx
did: xxxx
mypartition: 1
action: harm_stay
submit: Enter
Hello DSC/Envisalink owners. Wanted to let you know that soon a new option will be available to you to have your DSC/Envisalink integration running 100% locally on the SmartThings hub via the new Edge platform. No more need for cloud connections or running code on a Raspberry Pi. I am developing a driver for SmartThings Edge that will connect locally directly to an Envisalink and create SmartThings devices for each of your zones and partition panels. Let me know if this interests you, as I’ll be looking for some early testers soon. You’ll need to get up to speed on SmartThings Edge first.
3 Likes
Vadim - Thanks. So I guess my initial assumption about connect2go being a white label of eyez-on is not correct. Although the UI looks exactly the same, obviously they are doing things a bit differently on the back-end, potentially more securely, from your comment. So seems I won’t be able to leverage your work. Thanks for the comment about the session cookie too…obviously exposing the limits of my knowledge here! M
I’m interested as I was using Redloro’s JSON server until it broke on the new app and can’t use Vadim’s solution. I will start reading up on ST Edge.
1 Like