So at this point we don’t know if we’ll be able to use this with the new app? Maybe Redloro knows a way to get this to work with the new app.
Is it possible to add a keep a live ping between EVL and the node server. I updated the firmware on my EVL, as a result I had to restart my EVL as it wasn’t receiving anything from the EVL. Log were blank…
@redloro (I’ll tag him for this reply)
I haven’t seen him in this thread for a hot minute. Hopefully he can come back and let is into what we can and can’t do. That might mean that we need to invest (something like Konnected?) into other methods to make our alarm systems work with the new app.
Hey everyone! Been watching the discussions on this thread for a while… just been too busy to take a look at the new app and figure out a solution. And half hoping someone would propose something that would just work. I’m actually working on an update to tie this into the Ring Alarm system, so that you can continue to use your Honeywell panel + sensors + Smartthings but extend with Ring. Should have more info in the next couple weeks.
Thanks for the update. Unfortunately, the classic app is going to be going away. There isn’t much we can do about it. It’s either jump on-board or move on with another solution. Hopefully we can figure something out.
Below is the part of the announcement that pertains directly to transitioning DTHs like this one to the new app. It says that there’s new functionality coming that will allow us to define what the user interface for a custom capability should look like in the new app. Until that happens, porting this to the new app will mean settling for something that does less in a messier package. The best thing to do right now is to continue waiting until we see what custom capabilities can do. I’d note that there are plenty of other DTHs in the same boat as this one.
In the meantime, what’s possible with minimal effort is creating virtual switches for each of the alarm modes and tying them to the partition with a smartapp or webcore. Here’s my setup. It works, but it’s not as useful as having a working partition device:
I went ahead and made (6) automations (3 when you press the virtual buttons arm stay/away/disarm and 3 when you press the same buttons on the STHM):
- arm stay, arm away, and disarm (pushing any of the three virtual buttons will arm/disarm the alarm and change the status of STHM)
- STHM stay, STHM away, and STHM disarm (pushing any of those three buttons on the STHM will enact the proper virtual switch above and change them accordingly which will arm/disarm as well).
Thanks! Appreciate all your hard work.
I did the same and it works well. I did use Webcore to use the virtual switches to arm/disarm the Honeywell system. This seemed to work better than using automations. I did use automations for the STHM stay, away and disarm buttons that now enact the virtual switches.
This scheme has all the functionality I need. I do use Webcore to arm/disarm the system based on presence sensors and this still works. I did delete all the rules and assocations I had in SHM in the Classic app. I then held my breath and deleted SHM in the Classic app…and lo and behold the world did not end.
@Sakman, I’ve got the duplicate routines (and scenes - although the scenes can be replicated in the routine to be honest) created in the New App already, but not sure if I want to fully pull the trigger just yet. I’m getting there, but I know that in some instances if you delete the contents of the Classic App you can’t get certain things back.
** update ** Screw it, I went all in. I deleted my routines in the Classic App and then deleted the app. All seems to be working in the new app, but I’ll give it time to see if my new routines/scenes fail the logic arguments. I will be curious to see how the presence plays out as well with my phone.
I’m still having issues with nodejs not being able to talk to SmartThings. I have to reboot the hub about every 2 weeks.
hey, know I’m probably jumping into the wrong thread, but wanted to make sure I used an active one. I have followed all the steps (I think) to add my Vista panel to Smartthings using the Envisalink4, and my node server is definately working, I can see all events through the cmd panel. My app appears in smartthings, but my devices do not. I have checked all my ports, ip addresses, and various other programming. Any idea on the best place to start looking? I’m sure it’s something stupid, but I am terrible at programming and am sure I just did one really stupid thing. Is port 8080 more likely to work than 8088? does the config file set the password for the smartthing node, or do I have to match it to something I have configured previously? Any ideas are greatly appreciated. Willing to share any code or screenshots necessary
Do you have discover zones checked? Your config file will set a few things:
“authCode”: “xxxxxxx”, (node proxy auth code)
“address”: “xx.xx.xx.xx”, (internal envisalink ip address)
“password”: “xxxx”, (envisalink password - typically default here)
“securityCode”: “xxxx”, (security code for your alarm system)
I didn’t think I would find my answer here in this thread, but I’m sure glad that I decided to poke my head into here!
I’ve been struggling with re-configuring my AD2Pi implementation with SmartThings for the past 2 months or so. It was first setup a couple years ago, recently did an upgrade to v3 SmartThings app and likely through my ignorance messed up some things and decided to restart the whole process: re-image Pi, new setup of dth, etc. For the longest time couldn’t figure out why the ST app wouldn’t see the live changes but the webapp had no problems. Left the mess for about 2 weeks and out of the blue, everything was live again. Although all the sensors were all being read into ST now, the actual “panel” device is just blank with no controls.
The answer I found from this thread that clarifies my confusion is what Phil mentioned above regarding the new app only being able to handle a user interface that matches a predefined capability or set of capabilities, which may work for zone devices, but not the partition device full of buttons.
As I was reading through this thread, I was contemplating switching to this integration because there seems to be much better support over here.
I’ve also not really come across much in terms of the AD2Pi hardware in this thread, it mostly talks about the envisilink and the AD2USB. Is there something about the AD2Pi that would not allow this integration? I would be running this on an original Pi B+, so it’s quite a few years old now, would that be a problem?
i’m new to this party, I just configured this setup this week and I am having the same problem with the honeywell security smart app not not offering me a choice to select the smartthings hub. Has anyone figured out a work around for this?
You will probably have to set up the Honeywell integration in the Classic app. Once this is done, if you want to use the new app, you can setup virtual switches to arm/disarm the system as described in the posts above.
Thanks a million!! that worked!
So this solution works for contact, motion and smoke sensors. What about other sensors like CO, water leak, glassbreak, etc? Do they just get treated like one of those 3, or am i not able to use them in ST?
You should be able to add any other sensors connected to your Vista as one of those three. I have a glass break that shows up in ST as a contact sensor. It reports its state as open/closed, which can then be used in automations.
It’s also possible to copy and edit the existing device handlers to make them report something more rational for the sensor. So I could make the glass break sensor report something like “ok” and “glass broken”. But overall in ST (especially with the new app) it’s better to stick with the standard capabilities. There are capabilities for water leak and carbon monoxide, so if you changed the DTHs to use those capabilities they would work fine. There isn’t one for glass break, so sticking with contact sensor is probably best.
The AD2Pi might work with this. I haven’t seen anyone post about trying it though. If the AD2Pi connects as a serial device to the Pi (I’m pretty sure it does) and uses the same protocol as the AD2USB (no idea), then it might work for you. I doubt the age of your Pi would be an issue.