Thank you.. I will try it when I get back from holidays.. really glad you looked it over and figured it out.. it's a good driver and I definitely like the envisalink
1 Like
That worked! Thanks for your help and modification to the code.
1 Like
Redoing my whole network so I blew away my pi and restarting from scratch. I got the PI setup to talk to the Envisalink and the app in hubitat to talk to the PI. I can arm and disarm but I can't get the zones to automatically import. I don't want to have to go in and manually enter 64 zones. Any idea what could be preventing the discover zones toggle from working? It actually does import the default zones that come with the config.json on the PI but not the zones from the Envisalink.
Make sure the notify address is correct in the config.json.
The IP is correct. It can pull in the zones that are in the config.json but it's just not pulling the zones from the Envisalink.
I don't have to manually enter each zone in the config.json do I? I went ahead and added all them to the config.json manually and they added correctly. I don't remember having to do that last time though.
BTW if anyone happens to switch their network gear out and migrate to Unifi, you may notice the Envisalink controller stops responding. The simple fix (though I am not sure why) is to disable spanning tree protocol and link layer discovery protocol on the port to which the Envisalink is attached, Perhaps the extra connection time required for STP creates timeouts? Not sure but it definitely solved my issue.
Interesting. I have Unifi wireless and Edgerouter, but all other devices are netgear. The only issue I had was to restart the nodeproxy server if the envisalink goes down/reboots.
Yeah I'm 100% UniFi end to end... I'm using a Dream Machine Pro as a gateway and a USW-Pro-24-PoE as a distribution switch (with a couple access layer ports too). HE sits on an access switch 16-port USW-Lite-16-PoE (not on a PoE port of course), which is connected to the distribution switch. The Envisalink is directly connected to the distribution switch. Since there is nothing sharing the envisalink port I think disabling STP is probably safe.
If your access switches are netgear maybe they implement STP slightly differently?
I'm full unifi with a UDM pro, an aggregation pro and a 48 pro and use rapid spanning tree and lldp on everything without issue running all the latest EA updates..
You can run the server as a service so it starts back up if it reboots.
Odd. If I enable Spanning Tree / LLDP on the port to which my Envisalink controller is attached it definitely breaks communication with HE. My HE sits on a USW-Lite-16-Po access layer switch, which is in turn connected to USW-Pro-24-PoE distribution switch. The Envisalink hangs off the distribution switch.
HSM Integration STNP: HSM Disarm Does Not Disarm Alarm Panel During Alarm Panel Exit Delay
If the system is Armed with the Honeywell Vista keypad the Hubitat HSM Disarm command will not disarm the Vista Alarm Panel during the Panel exit delay. It works for other cases.
I had been an early adopter of @doug native code and it was working without an issue for me with a small number of motion and contact endpoints. Sorry to see how it ended. I then tried this STNP integration with the RPi3 and it has been solid. For me, this is a key and important integration. Thanks for the support. 
Background: While my philosophy is to separate control of the Alarm system from the Smarthome interface there are some advantages for the visually impaired along with:
- Having a lock with physical buttons *important ( Z-wave Weiser Smart Code 10; have 3 of these working perfectly).
- Using one code to both unlock and to disarm. Not having to enter a lock code and then an alarm code. (Programmed lock code to turn off alarm. Do not want to use proximity.)
- Virtual Arm & Disarm buttons on dashboard.
Normal operation in this case, has been arm with keypad, disarm with lock code. This was working well, until there was a need to re-enter the building during the Honeywell delayed exit countdown. The lock code did not work.
Changing timings in HSM did not have any effect since the HSM is armed after the Panel is armed. I tried several approaches such as arming the HSM when panel status contained ‘May Exit’ but this had problems.
a) Current work around - whenever I need to disarm the Vista alarm through the Hubitat HSM - I first Arm HSM and then immediately Disarm HSM. This is a bit of a duct tape solution, but it seems to be working for all cases. (My rules for buttons and locks are set to do this, but if using the HSM tile, it has to be armed then disarmed manually.)
b) You could wait outside for the Vista Alarm to arm then the HSM would arm. (It is cold here).
c) It would be better if the Honeywell_Security.groovy code could be modified to handle this case. I had a look at the code and could follow the logic, but currently I have enough knowledge and time to break it.
In the meantime, I hope this helps if anyone else has the same problem, or perhaps there is a more elegant work around.
(Running Hubitat C5, Honeywell Vista 15P, Envisalink EVL4, STNP in Docker on RPi3 (Docker on QNAP-NAS Container Station worked well too) all Z-wave devices. Also have another location with C7 Hub and Vista20P waiting for RPi).
Thank you for the extended info; it should make reviewing easier. I’ll try to carve out some time to look at this this week.
Not sure if you're comfortable updating my code to test, but if you can replace the function updateAlarmSystemStatus() with this code, I believe it will fix your issue. I'm not comfortable updating it for everyone quite yet, so I'm going to run with this version for a bit. If you can test it, I'd be curious if all your test cases work with this.
private updateAlarmSystemStatus(partitionstatus,alpha) {
if (!settings.enableHSM) {
return
}
if (alpha.contains("May Exit")) {
state.isArming = true
} else {
state.isArming = false
}
ifDebug("Debug: partitionstatus: ${partitionstatus} : state.isArming ${state.isArming} : state.alarmSystemStatus ${state.alarmSystemStatus}")
// handle if disarmed by HSM while still being armed via keypad.
if (state.alarmSystemStatus == "disarmed" && state.isArming == true) {
ifDebug("Was arming when recieved a disarm command from HSM.")
return
}
def lastAlarmSystemStatus = state.alarmSystemStatus
if ((partitionstatus == "armedstay" || partitionstatus == "armedinstant")) {
state.alarmSystemStatus = "armHome"
}
if ((partitionstatus == "armedaway" || partitionstatus == "armedmax")) {
state.alarmSystemStatus = "armAway"
}
if (partitionstatus == "ready") {
state.alarmSystemStatus = "disarm"
}
if (lastAlarmSystemStatus != state.alarmSystemStatus) {
ifDebug("Sending HSM Event to hsmSetArm: ${state.alarmSystemStatus} (partition status: ${partitionstatus})")
sendLocationEvent(name: "hsmSetArm", value: state.alarmSystemStatus)
}
}While I didn't get a chance to look at the code logic, I inserted it and just gave it a quick test.
(Just read my last post - a little long. Must be the social impacts of the pandemic.)
I thought the revision was on the right track when I saw the HSM tile alternating, but with new code the Honeywell keypad does not disarm the alarm during countdown regardless of initial arming. When armed with the keypad; disarming with the keypad during countdown gave a few different results. Usually it had no effect, a couple of times it disarmed and auto-rearmed, and sometimes after several disarms in succession it might disarm.
Also, thanks for your time supporting this (your Rpi Docker integration was a time saver!)
1 Like
Also here is my quick work around. Not pretty but adding an HSM Arm in the rule then an immediate HSM Disarm has been working.
1 Like
I assume your HSM arming has a delay given that your tests have the status "armingHome". I'm not accounting for that status in any of the code. Try replacing the alarmHandler function with this function. I don't have an HSM delay configured for myself, but in both the tests above that were red, they worked as anticipated for me.
def alarmHandler(evt) {
// handles HSM events
// armedAway, armedHome, disarmed.
if (!settings.enableHSM) {
return
}
log.debug("Debug: in alarmHander for HSM event: value ${evt.value} state.alarmSystemStatus: ${state.alarmSystemStatus} state.isArming: ${state.isArming}")
// deal with when you have just set hsmSetArm=disarm
// and received the event hsmStatus=disarmed
if ((state.alarmSystemStatus == "disarm") && (evt.value == "disarmed")){
return
}
if (state.alarmSystemStatus == evt.value) {
return
}
log.debug("Received HSM event: Value: ${evt.value} state.alarmSystemStatus: ${state.alarmSystemStatus} state.isArming: ${state.isArming}")
state.alarmSystemStatus = evt.value
if ((evt.value == "armedHome") || (evt.value == "armingHome")) {
log.debug("Sending command to envisalink to /armStay")
sendCommandPlugin('/armStay')
}
if (evt.value == "armedNight") {
log.debug("Sending command to envisalink to /armStay")
sendCommandPlugin('/armStay')
}
if ((evt.value == "armedAway") || (evt.value == "armingAway")) {
log.debug("Sending command to envisalink to /armAway")
sendCommandPlugin('/armAway')
}
if ((evt.value == "disarmed") || (evt.value == "allDisarmed")) {
log.debug("Sending command to envisalink to /disarm")
sendCommandPlugin('/disarm')
}
}Were you able to try my changes above?
I know this is a known "feature" of the HE-native envisalink-HSM integratoin but I wonder if anyone has looked at fixing it...
When you arm HSM Envisalink causes HSM to disarm and re-arm. It works fine but does make creating rules based on arming and disarming bit more complicated.
Can’t say I’ve noticed it. I wonder if the changes I’ve proposed in the last few posts might fix this.
