Vadim, I think that is it. Looking at my manual (a friend programmed my system for me as he used to install them), function *84 says “if enabled (I think he has it enabled), the system will automatically change AWAY mode to STAY mode if the entry/exit door IS not opened and closed within the exit delay time after a user arms in AWAY mode from a wired keypad (non RF device)”. Does this make sense to you? Mike
Yes. Sounds like it has absolutely nothing to do with Eyez On, and even less so with this SmartThings handler. It actually makes sense though (I’m pretty sure my system defaults to the exact same behavior) - it’s done so that if you don’t actually exit the house it doesn’t go all hay-wire on you as soon as it detects motion in the house; so it’s “smart” like that.
I changed the Vista default to none and tried the virtual switch agaian and it stayed armed away! Thanks
Hi Newbie here, just just to recap… If I want to see all the zone switches from a vista20 in smartthings then I got to run the Alarm server . Also will this work for wireless door sensors, motion sensors attached to the vista20.
ultimately I would just like to have zwave lights go on when a wireless vista20 sensor is tripped. Currently I just have a smartthings device, and running homebridge . And ordered a Envisalink v4
what’s the easyiest way to achieve this
I don’t know anything about Alarm Server so can’t comment on that but as per my understanding it does give you a lot of options, as well as being able to see all your switches in SmartThings.
The purpose of this device handler is to provide a very light, eays-to-follow process to setup integration between SmartThings and EyezOn without requiring any additional hardware devices (e.g. Rasberry Pi). However it is limited to only being able to arm/disarm system automatically in SmartThings via routines, etc.
So based on your use case you’d probably need to go the Alarm Server route.
@jobs_k Vadim hit it on the nose.
The solution in this thread is lightweight - for security mode sync - but doies not pull through the sensors. If you want the sensors pulled through into SmartThings using an EVL3/4 device then you need to use one of the AlarmServer Implementations.
Both builds are currently being updated by the community to be functional - and have working DTHs for both the panel and the typical sensor devices. (Motion / Smoke / Contact)
If you have a DSC - use the Xero / RTorchia build here: DSC → EVL-3(4) → Alarmserver → Smartthings - Wiki / Projects & Stories - SmartThings Community
If you have a Honeywell alarm use the Redloro build [RELEASE] Honeywell / Ademco Vista 20P Integration - SmartApps & Automations / Community Created SmartApps - SmartThings Community
@vadimb , first off, thank you for writing such an amazing piece of code, I’ve been using it for some time and it has worked wonders for our household, being able to have our vista15p system arm/unarm seamlessly based on our smartthings modes/geolocation, and also arming our system at night via voice assistant routines. It has run quite reliable to the point where we trust it with our security.
My question is…Is it possible to add a virtual smartthings switch using your code that would allow me to arm my system with the Honeywell “Night” mode (Honeywell calls it “Night-Stay” or just “Night”) the way your code currently arms into the Arm-Stay mode? If so, how do I do that?
I have been adding security sensors/zones to the quite basic Honeywell security installation from the builder, and I have added a motion sensor zone in an area that I would like active when the system is armed after bedtime. This required me to add this particular zone to a zone list that can activate the zone during home occupancy, but I need to use the Honeywell “Night” arming mode to activate that zone properly at night when we are home. Right now with they way the code is set up, I don’t think I can arm into the “Night” mode the way I had been enjoying your code to arm the system into Arm-Stay (unless I’m mistaken, or not seeing how to modify the virtual switch properties).
Thanks in advance. I REALLY hope this is possible!
Thanks for the feedback and praise.
Unfortunately I don’t know anything about the Honeywell system so cannot offer much advice on the matter. Unless I’m misunderstanding something, that system is entirely separate and unrelated at all to your Vista15p (and EyezOn portal)? If so then this code obviously wouldn’t work because it’s been written to communicate with the EyezOn server specifically. If Honeywell has its own backend then you’d need to write your own custom handler specific for that, which can get much more involved since EyezOn system doesn’t really use any authentication and is extremely “dumb” so it’s easy to send commands to; might not be the case with Honeywell though.
Did you try to search around the forum to see if anyone has specifically integrated with Honeywell? At the very least I’d imagine they have some hooks built in that’d allow you to communicate with the system via API (sorta like the Raspberry Pi-based solution some are using with EnvisaLink).
@vadimb , Ok, maybe I should have skipped all that Honeywell detail, they are simply the brand that makes the common Vista panels that the majority of EyezOn users have. I was just trying to give some background to explain why someone might want to utilize an EyezOn arming mode other than “Stay” and “Away”. Let me rephrase:
Is it possible to utilize your device handler so that I can arm my system utilizing the EyezOn “Night” mode?
I’m no coder, but when I scanned the custom device handler you wrote, it seems that it might be possible to copy/modify what you have written, so that when someone like me creates the virtual EyezOn alarm switch in smartthings, there would be an option for the EyezOn “Night” mode in the radial button list when you are populating the switch settings (in addition to “Stay” and “Away”).
If so, it would definitely add functionality to the device handler code you have written. Again, I’m the farthest thing from a coder, so I have no idea how much additional work/time this involves! Here are the typical EyezOn arming modes:
I have no interest in adding any additional functionality or complexity trying to bridge home security sensors into Smartthings, or learning raspberry pi, or adding additional hardware. I just want the security system to arm/unarm based on geolocation, and having the convenience of security system arming control via voice assistant, easy security system scheduling, all of which your software coding has created the bridges for and provided. Again, thanks for the work you put into this DH, for years I’ve lamented not having any easy bridge between “old school” alarm systems and home automation, and you have created that at least for ST users!
Thanks for clarifying this all makes sense now! Yes you’re correct it should be a pretty easy change that I can make. I’m not entirely sure what “Night” does or how it’s different from the “Stay Arm” mode though. What would help me if you can pop open this URL on your computer, open the Dev Tools (or Chrome equivalent), open the “Network” tab there, and hit that Night button on the Arm screen. You can PM me the HTTP request that goes to the server and I can just grab that and update the handler code to add that functionality. You can PM me for any clarification if you need for how to do all this.
That is good to hear, that I’m not asking for a herculean modification!! I only know how the “Night” mode differs, now that I’ve spent a bunch of time in the minutiae of Honeywell zone programming! If you would have asked me a few days ago, I’d have no idea! Ultimately it does not matter for coding (I think), as I believe EyezOn is just telling the alarm system to arm in that particular mode, the alarm panel itself determines how things operate differently, as far as the different arming modes.
One suggestion I might make, is that if its just a matter of copying/modifying your existing code, maybe just cover each arming mode in my EyezOn screenshot? These are the common arming modes available to the majority of all Honeywell based alarm panels, which I would think would cover the majority of users benefiting from your code. So if someone out there using your DH likes to use the “Max” or “Instant” arming modes for whatever reason, they could add that virtual button to their ST. I will leave that entirely up to you, as the coder. On the contrary, I would think adding the “Night” mode only, might also cover the majority of users.
I will follow your directions and I might need a PM walkthough…let me give it a try. Thanks SO MUCH for being open to this idea.
@vadimb Just to piggyback on some of the praise I’ve read throughout this thread, I again wanted to say thanks to you and whoever else was involved for creating this EnvisaLink / SmartThings integration. Truly an awesome piece of code! I read through some of the thread and saw the one guy that had trouble with the account ID where it would put a capital letter in the box on the phone app. So I had to copy and paste mine via the IDE website page and it pasted properly (even though it still shows as a capital on the phone app). Anyway getting past that, I was curious if I may be able to request one addt’l arm request (similar to what @hevykevy420 suggested) and that is the “Max” functionality. I am really enjoying both the “Stay” and “Away” functions although at night we use “Max” exclusively. In our particular case, could be how our alarm system is set up but I am not quite sure, when we use “Stay” it only alarms our doors or entry ways and does not set the motion sensors. The motion sensors only arm if we use “Max” which is why it would be beneficial.
My apologies for asking about a ridiculous request when you’ve already done so much…
Thanks again for all your hard work and effort!
@vadimb , if it helps, I am happy to help you with what you need and/or test your draft code for the remaining Honeywell arming settings (Max and Instant), at your convenience of course. These additional arming settings either arm sensors that are not armed in the other modes, or remove the entry/exit delays (if you are on vacation, you’d want to consider one of these modes, so as not to provide an intruder with an entry delay to either damage/deactivate the alarm system, or have free range for a short time before the sounders activate). Some folks use these arming modes at night if you are not expecting anyone to potentially arrive (and you are diligent about unarming upon wake up, or have a scheduled AM deactivation).
@hevykevy420 Good explanation of why to use the different alarm settings! You hit the nail right on the head with the removal entry / exit delays as well.
Sure this should be relatively easy to add in. @hevykevy420 if you have access to those other modes and can PM me the same screenshot of the request to server as you’ve done with night mode that should be sufficient for me to be able to make the code change.
PMed XMR for Max and Instant arming modes. LMK if you need anything else @vadimb . If you send me the draft code again like last time, I’ll test both new modes on my honeywell panel to make sure its all good. TIA
Thanks Kevin. @Tech_East code is ready to go at the Github link. One note though - I collapsed both variants into a single code for easier maintainability now and added a new setting “Code Variant” to toggle between the two. Take a look at the comment on the README related to the new “Code Variant” setting. Happy testing!
@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.
maybe @Tech_East can chime in with some user testing?