Quick question. I have Envisalink for DSC integration installed, and linked to HSM.
When I click arm home from the HSM tile on the dashboard it arms the alarm like it should.
If I click from the dashboard to disarm, everything disams as it should.
However if someone disarms the alarm from hey keypad to let the dog out, the alarm disarms, but the HSM still monitors the doors and then flags an intrusion and responds accordingly. DO I need a seperate triggered rule to disarm HSM when the envisalink is disarmed, or is something not working correctly?
Assuming you are using my Envisalink Integration app and Connection Driver?
What version of the app and driver are you currently running?
In 0.15.0 I extended HSM integration to two way. When my keypad is used to disarm, HSM now disarms.
Turn on the debug variable and see if you can see anything in the logs.
What version of Envisalink do you have? What keypad and what controller board on your DSC?
Enabled debug and see nothing for disarming the keypad. The device for keypad shows the event from armed to disarmed to ready, but nothing in the logs for HSM or Envisalink integration show anything.
As for the DSC im running PC1616 and an Eyez-On Envisalink EVL-4CG IP Security Interface Module
If the HSM subscription is active, each time you use the keypad you should get HSM Alert: [event] in the logs.
If debugging is enabled (via the variable in the code, not the switch in the app which doesn't work presently) you will get more detail after the logged event above. If you do not see these logs, then the app is not subscribed to the HSM events. If that is the case, click the Initialize button in the Device properties for your envisalink connection device, see if that does the trick.
This is the block of code that handles the events from HSM
def statusHandler(evt) {
log.info "HSM Alert: $evt.value"
if (getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Exit Delay in Progress"
&& getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Entry Delay in Progress")
{
if (evt.value && state.enableHSM)
{
ifDebug("HSM is enabled")
switch(evt.value){
case "armedAway":
ifDebug("Sending Arm Away")
if (getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Armed")
{
getChildDevice(state.EnvisalinkDNI).ArmAway()
}
break
case "armedHome":
ifDebug("Sending Arm Home")
if (getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Armed")
{
getChildDevice(state.EnvisalinkDNI).ArmHome()
}
break
case "armedNight":
ifDebug("Sending Arm Home")
if (getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Armed")
{
getChildDevice(state.EnvisalinkDNI).ArmHome()
}
break
case "disarmed":
ifDebug("Sending Disarm")
if (getChildDevice(state.EnvisalinkDNI).currentValue("Status") != "Ready")
{
getChildDevice(state.EnvisalinkDNI).Disarm()
}
break
}
}
}
}
Sorry no, I was having issues with HSM Syncing to the Envisalink integration. However I got around this issue by disabling HSM and creating some virtual switches and using the switches option within the Envisalink application.
Yep, on latest version. I haven't done a deap dive troubleshooting yet. Hopefully I'll figure it out. Although honestly using virtual switches is working for my needs... basically needed a way for Hubitat to signal alarm state for doing things with my thermostats.
Thanks for the heads up on development. You've done a great thing here.
Wow. This is a bummer. There was a lot of great info in that thread not to mention links to other resources. Is @brianwilson 's latest integration the same thing?
I completely get where @doug is coming from. I hope his exit is a wakeup call for the Hubitat folks. I’ve linked to my clone of his code in my thread above. I can’t support it as I’m not using it, but will gladly accept PR’s and attempt to help folks with issues.
The code that was in my master branch was said to be throwing exceptions and causing slow downs. I don't recommend using anything after the Vista branch was merged into master. If you continue use of this software it's at your own risk and be sure to adhere to the license.
For the record, I have no issue with developers pulling access to their code or no longer supporting something, but to delete an entire thread with all the surrounding information and conversations that inevitably get discussed is just not right. The wealth of information in these forums is of great value to the community as a whole and the discussions should remain. Go ahead and lock the thread and disable links but don't delete it when others have participated.
