@bravenel
I have a bit of a weird one. I created a 3.0 rule that has a wait for HSM cancel in it. And it worked perfectly when I canceled the intrusion alert, either before the alarm went off or after. But if I disarmed the system during the intrusion, the wait did not recognize the cancel and the actions after it did not take place. I tried a simple trigger with the alarm cancel and that recognized the disarm as a cancel. For some reason, during the wait, that is not occurring. Let me know if you want me to post screenshots of the rule's properties page.
Suggest that you look at all of the relevant events and logs. The answer is there.
You said before that the first thing that "Disarm" does is cancel any active alerts. Is that not true?
From the code, very first line of disarm:
def disarm(all) {
cancelAlerts()
.....
}
And elsewhere:
def cancelAlerts() {
.....
sendLocationEvent(name: "hsmAlert", value: "cancel", descriptionText: "hsmEvent")
.....
}
Look at app events, logs and subscriptions.
I think I found the problem.
In order to clean up the alert (so it doesn't go on forever) I have the first action in the rule. But in order to cancel that if I disarm or cancel the alert early, I have the last action. Well, I think that was stopping the restoration of the other devices. So, i put the delay in before the stop and everything seems to be working now.
On a side note, it would be nice if we could have actions within HSM for intrusion-delay as well as the existing triggers for intrusion. That's the purpose of this rule. Just a thought. Thanks for your help.
