Yea all that works for me when the alarm is not armed. However, when the alarm is armed and the main entry door is opened, the contact sensor device for that door does not change state during the entry delay, so it cannot trigger a light.
In the old days I had an X10 integration with my Vista alarm and my favorite feature was when I returned to a dark armed house, the alarm would turn on the entry light as soon the front door was opened, while the entry delay was active. Similarly, when the alarm actually sounded, I could turn on all X10 lights in and around the house.
I can’t replicate either of these behaviors right now, though the hints from @philh30 seem promising.
If you don’t have webCoRE, you can go here to learn about it and install it. https://wiki.webcore.co/
Once it’s installed, you can create a “piston” for it, which is basically a rule that you can custom program. It would look something like this:
You would then add the “then” section, which means if your alarm goes into alarm status, do the following…(whatever you want to happen after the this).
Once you integrate all of your devices into webCoRE, it really starts to open up what you can do. webCoRE acts as a conduit between different systems (e.g., Smartthings, Redloro’s Vista 20P Integration, etc.) and makes things actionable between these different devices/systems that don’t natively speak with each other.
That sounds like a communication error. I’d guess it’s a problem between SmartThings and STNP, but it could also be the STNP to Envisalink communication (checking the STNP logs would confirm whether it’s still communicating properly with the Envisalink).
I’d suggest power cycling the ST hub and STNP as a first step. Otherwise… Have you changed anything recently (e.g. new router, firewall settings on the STNP server)? Do the ST hub, STNP, and Envisalink all still have the same IP addresses that you used when you set everything up?
I’m getting the same “socket hang up” error now, wondering if it might be related to the newest firmware upgrade? Nothing else has changed in my system recently. Tried rebooting my EVL3 and the Raspberry PI that runs my node server but no luck …
Same here. Started happening on 6/27, same day as the firmware updated on my ST hub. I haven’t touched this stuff in over a year. Now to try to figure it out all over again.
One thing I noticed … the sensors that were probably open when the firmware updated are still showing as open (even when they’re not) and all other sensors are showing as closed no matter their actual status … @redloro any ideas?
I ended up removing and adding the app back, and everything is fine now. Perhaps uncheck “discover zones” and reenter your passwords.
PIA, had to remove all zone automations, routines, WebCore, security…
It should populate within WebCoRE. Not sure why you’re not seeing it.
I had a similar thing happen with sensors getting “stuck” in their positions. I rebooted ST and restarted the proxy server and everything synched back up. I’ve seen this happen before.
Sorry all, I’m a little thick-headed. How does adding the Honeywell device to CoRE fix the “socket hangup” issue that is preventing the device from updating in ST? Thanks in advance.
