Vadim,
I have been communicating with John Constantelos about using the virtual arm away switch I created which interfaces with my Vista 20P/Eyezon Card. FYI, exit delay is set on my panel to 45 seconds. Both ST virtual switches are set to 55 seconds. When I hit the arm away virtual switch, the system arms away and then shortly after changes to arm stay. The only way to have it stay in arm away is to open an exit door after I execute the arm away switch. If I do that it remains in arm away. Below is the live logging from a test I ran this morning.
John doesnât know what is going on and he suggested I touch base with you. I can arm away and disarm and such fine with EyezOn app without opening door so not sure why the virtual switch to arm away doesnât keep system in arm away mode.
Would you have any ideas?
Thanks
Mike Morehouse
That is certainly some extremely bizarre behavior I havenât heard of. Some points of clarification, to start:
âWhen I hit the arm away virtual switch, the system arms away and then shortly after changes to arm stayâ - how do you know that the system originally armed in away mode (as opposed to stay mode)? Is this based on some indicator in your homeâs security panel, or in Eyez On website? or are you inferring it strictly based on the state of those virtual switches?
Have you tried to arm-away the system manually through the Eyez On website? Do you get similar behavior there?
Vadim, thanks for the reply. Now Iâm confused. I got out of range of my home motion sensor by the panel and using the eyezon app armed it away. The panel started chiming and chimed for 45 seconds (exit delay time) and when it stopped the panel showed arm STAY! but the app showed an event at 2:21PM âAway Arming by User Code 2â and at 2:22 showed âStay Armedâ! Is it possible that my panel is set NOT to allow ARM AWAY unless an exit door is opened after arming is executed? When we have been away and used the app to arm away I would see it arm away and likely not look at the app event screen long enough to see it flip to arm stay! Mike
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.
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
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.
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)
@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!
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âŠ
@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!
