Elk alarm ack rule?

[bucko]

If I have an active burg alarm then input my code, that stop the alarm. Fine
 
Then a second code input acknowledges the alarm and everything is reset and back to normal. Also fine.
 
I need to write a rule  that will turn on a phantom output AFTER the alarm has been acknowledged. I need this for my HA control.
 
I see where under Elk Whenever > Security Alarms> Burglar status I can choose "Becomes ready to arm" or NOT becomes ready to arm". Is this saying the alarm has been ack'd or it has not been ack'd?   If this is an ack state then I could easily use this to fire my output.
 
Anybody know this meaning????

 

[mikefamig]

You can write a rule that tests those conditions and voices a message when the condition is met. Then go through the steps of arming and disarming the system and listen for when it speaks that message.
 
Mike.

 

[bucko]

You can write a rule that tests those conditions and voices a message when the condition is met. Then go through the steps of arming and disarming the system and listen for when it speaks that message.
 
Mike.

This is about remote confirmation that an alarm event has been ack'd. I don't care about hearing anything. I need a rule that confirms my system has been disarmed from an alarm event (that part is fine) THEN I need a confirmation it has been ack'd and the system is back to normal.

 

[wuench]

I think you have the order backwards.   I think the first code acknowledges the alarm and the second code disarms it.   Also I don't  think ready to arm/not ready to arm are the right states, those are related to weather  all the zones are  in the ready state (i.e. not violated).   I looked and didn't see anything that stands out,  you'll probably just have to run some tests with the various events.   My best guess is When Disarmed is the state you want.   Maybe When Disarmed and Alarm Memory Exists?
 
http://cocoontech.com/forums/topic/5776-elk-m1-alarm-memory-workings/

 

[bucko]

I think you have the order backwards.   I think the first code acknowledges the alarm and the second code disarms it.   Also I don't  think ready to arm/not ready to arm are the right states, those are related to weather  all the zones are  in the ready state (i.e. not violated).   I looked and didn't see anything that stands out,  you'll probably just have to run some tests with the various events.   My best guess is When Disarmed is the state you want.   Maybe When Disarmed and Alarm Memory Exists?
 
http://cocoontech.com/forums/topic/5776-elk-m1-alarm-memory-workings/

On my M1 panel in alarm mode, the 1st code entry stops the alarm. The keypad then shows Burg Alarm and zone violated. Once I enter the code the 2nd time, keypad goes to Ready and time-like normal. Technically maybe 1st is called ack, however what I need is acknowledgement of the second code of some kind. 
 
I put in a call to Brad and see how he responds. Will post what he comes up with.

 

[TurboSam]

Bucko, what I think you want is a rule that says:
 
WHENEVER ANY ALARM, ANY AREA CUTS OFF
AND AREA XXX ARM STATE = DISARMED.
(or possibly in the reverse order)
 
I have to (respectfully) disagree with wuench since it is my experience that the first code entry does, in fact, disarm but the alarm still stays "in alarm."  My situation was that if only the first code was entered, the system would still be "in alarm" but disarmed, and then every time a window opened (i.e. violated) I would get notices that (another) violation had occurred.  Once I entered the code a second time, that stopped.
 
I will say that I am not positive this will work since the bulk of my notices re alarms, violations, etc come via CQC, so I have had to do a bit of reverse engineering to see what CQC is looking at (i.e. InAlarm) that results in the above behavior even if the CQC ArmMode is disarmed.  So, when the code has been entered twice, CQC knows that Elk is not "in alarm" which (I assume) is alarm is cut off and that ArmMode is Off (=disarmed).
 
As for mikefamiig's listen for messages suggestion, I think he was trying to suggest setting up test rules that simply have as result that the Elk lady says something (either a miscellaneous message or bogus alert).   I often do the same or set up a test text email to test a new rule. 
 
Then, as he said, arm, disarm with first code, acknowledge the alarm with second code, and list for the text (or check whatever dummy notice you sent).  Once you have it working, you can change the guts of the rule to do whatever you want it to (i.e. get the remote confirmation that the ack has been received.)  That is precisely what I do, but as noted, I get the email via CQC once the Elk Area_X_InAlarm status is goes from true to false and the ArmMode is off (disarmed).

 

[mikefamig]

This is about remote confirmation that an alarm event has been ack'd. I don't care about hearing anything. I need a rule that confirms my system has been disarmed from an alarm event (that part is fine) THEN I need a confirmation it has been ack'd and the system is back to normal.

 
The voice would be a trouble-shooting aid, not a solution to your problem.
 
 
You asked -
 
"I see where under Elk Whenever > Security Alarms> Burglar status I can choose "Becomes ready to arm" or NOT becomes ready to arm". Is this saying the alarm has been ack'd or it has not been ack'd?"
 
If you test the above Whenever clauses with a voice message and then manually go through an arming procedure you can tell if the Whenever is fired or not based on whether you hear the voice or not. And then do the same for disarming.
 
Mike.

 

[mikefamig]

As for mikefamiig's listen for messages suggestion, I think he was trying to suggest setting up test rules that simply have as result that the Elk lady says something (either a miscellaneous message or bogus alert).   I often do the same or set up a test text email to test a new rule.

 
Yes, just an audible to prove if and when a rule fires.
 
Mike.

 

[bucko]

I see that is a good suggestion about the voice for troubleshooting. That is helpful. Turbo Sam understands exactly what I am looking to do, and with both suggestions I should be able to work out a solution.
 
Thanks for all the help.
 
EDIT:   Brad at Elk also made another good suggestion I will share. The key is to use the alarm memory in rules. He suggested to test;
 
Whenever Any Alarm, Any Area Turns ON
                                Then Turn on a Phantom Output For Example 100  (not the one to be used by your HA controller)
                                {depending on the operation you may need to turn OFF the Phantom Output to your HA controller so that it sees the output change state in the rule below}
 
Whenever Every 15 Seconds
                And Output 100 State is ON {system has been in Alarm}
                And Alarm Memory, My Home (Area 1) is RESET {you’ve entered your code the second time to acknowledge the alarm therefore there shouldn’t be an Alarm Memory}
                                Then Turn ON Phantom Output xxx to your HA controller
                                Then Turn OFF Output 100
 
Nice work Brad. Should work nicely.

 

[mikefamig]

Alarm memory is new to me, thanks for sharing that.
 
Mike.

 

[mikefamig]

Did Brad tell you what the contents of alarm memory would be under different circumstances?
 
Mike.

 

[mikefamig]

I found this from Spanky on the topic. I think that Spanky is one of the M1 designers.
 
http://cocoontech.com/forums/topic/5776-elk-m1-alarm-memory-workings/