I have a rule dealing with Intrusion Delays. I would rather have my lights come on during the intrusion delay than when the alarm goes off. So, what I am trying to do is to capture and restore them. I had this working in separate rules using a scene and PB but it was cumbersome so I moved it into one rule using a wait. The only problem is, that if you disarm the system or cancel the alert, the wait never occurs. It never continues on to the restore portion of the rule.
Now, it does work when I wait for the condition of Disarmed. But that isn't really what I want because if the system stays in alarms for more than 20 minutes I automatically cancel the alert. But in that case, I don't want to disarm the system, just cancel the alert.
@bravenel I am seeing that the subscription to the event doesn't go away. is this a product of creating the rule before the bug fix in 2.1.1.122? Should I wipe it and try it fresh?
As far as I can tell, Wait for Event and Wait for Condition both work as expected wrt HSM status.
Subscription to location events for Wait are handled in a different way. These cannot be unsubscribed as this would unsubscribe all location events, an undesirable outcome. Instead another mechanism is used to deal with location events that should not be responded to because the wait is not active. Again, as far as I can tell, this mechanism works correctly.
What do you need from me to show that they are not? When you have a HSM event going alerts canceled, the wait never finishes. Like the first screenshot i have above. You've been able to get them to work correctly?
When I try it, whether I cancel the HSM alert or disarm an alerting HSM, I get the cancel event, and the wait finishes. When I set it up to delay the cancel action, like you did, so that the wait starts first as it must -- that works as expected.
All I can suggest is that you walk through this to isolate parts of it, and look at the event logs.
Okay, I'll try from scratch. Maybe something got screwed up before that isn't correcting itself after the bug fix for events. I'll report back.
Okay @bravenel, I have tried with a brand new simple rule. And this does not work.
The light never goes back down to 20%. Ever. Can you tell me what I am doing wrong? You can create a rule just like that and it works fine? When the system is in intrusion home delay, the light goes to 100%. When I disable intrusion, the light stays at 100%. You said that alert cancel is the first part of disarm.
Also, can you cancel alerts during an intrusion delay? When I do that, it seems to lock up everything and it gets stuck in intrusion delay until i disarm.
UPDATE:
Actually, i think the problem is with HSM and the delayed-intrusion-home. If I wait for the system to go into full alert, the rule works fine. I can either cancel alerts or disarm the system and it works perfectly. The problem is when the system is in delayed-intrusion-home. In that state, I cannot cancel alerts and i don't get the cancel event when I disarm. I'm not sure that canceling alerts during delayed intrusion home is working quite right.
It isn't alerting yet in this situation, so there is no alert to cancel. DELAYED means just that. It won't alert until the delay is over. So of course there is no cancel event either, and canceling in meaningless. You can disarm during this period. That's the whole point of the delay, to give you the time to disarm before it alerts.
Then why is there a big cancel button the screen when the delay-intrusion-home is triggered?
If there is no alert to cancel, then why do I have a button saying "Cancel Alerts". Can you see my confusion now?
Ah, there is a UI bug. The Cancel Alerts button should not be there when the alert is pending.
That makes SOOO much more sense now!! I thought I was goin crazy(er). Thanks Bruce!
This will be fixed in the next release...
1 Like
