Arming and Disarming Elk M1G with F key

[mikefamig]

Nice find, but unfortunately can't see how it would help me out.
 
Not trying to take away from your thread, but to add... especially if Spanky is lurking around
 
I did some testing and this is what I found:
 
To recap-
I have a 2nd area that is armed whenever area 1 is armed away and disarmed whenever area 1 is disarmed - accomplished only with rules.
 
When I arm away using the keypad quick arm or code entry the auth timer clock will continue to run after countdown.
When I arm away using the keyfob (it uses zones and rules) the auth timer clock will NOT run at all.
When I arm stay using the keypad quick arm the auth timer will NOT run at all - area 2 is not armed in stay mode.
 
The auth timer clock will only stop after hitting * on the keypad if using the keyfob to disarm, but will stop on it's own after a minute when disarming with a code on the keypad.
 
Luckily... since I'm not using any 'F' keys for arming/disarming it's not that much of an issue. I also verified that even though the auth timer is running, the system will still prompt for a user code when bringing up the system menu options on the keypad if I disarmed with the keyfob.
 
I have no idea why it behaves like this...
 
Again, not the same issue as you, but yet similar.

There is definitely some weirdness the way multiple areas interact. When I arm area 1, area 2 arms with it by a rule. When area 2 arms I hear the announcedment that it is armed away. Then I hear that the countdown is about to expire. Then I hear it announce an open zone in area 1. This only happens when I have a zone in area 1 open at the time of arming. I have talked to elk tech support about this and they replied that this is how the system works. Not an error and not a problem, it's just how it works. That's not right.
 
Mike.

 

[mikefamig]

OK here's something that I hope will can save someone some time and trouble. I have managed to find rules to quickly arm and disarm area2 using the F4 key on the keypad assigned to area1. It requires you to enter a user code so it is secure.
 
The problem that I had with the keypad getting stuck with the little timer clock icon in the upper left corner was resolved by adding the output 101 and output 102 timer delays. I don't know why the delay is necessary but it works. It looks like the rules were stepping on each other or something by firing at the same time.
 
 
Keypad 1 Settings:
Key activates event 16=non alarm
Illumination event 1176=Area2ArmState
Requires code = checked
single press = checked
 
 
 
ARM AND DISARM GARAGE WITH F4 KEY
 
27        WHENEVER  KEY F4 ON KEYPAD1 ACTIVATES
      AND Garage (Area 2) ARM STATE = ARMED
            THEN DISARM AREA(S) 2 IMMEDIATELY
            THEN TURN Output 101 ON FOR 4 SECS
 
28        WHENEVER  KEY F4 ON KEYPAD1 ACTIVATES
      AND Garage (Area 2) ARM STATE = DISARMED
      AND Output 101 STATE IS OFF
            THEN TURN Output 102 ON FOR 3 SECS
 
29        WHENEVER  Output 102 STATE IS TURNED OFF
            THEN ARM AREA(S) 2 TO AWAY IMMEDIATELY
 
Mike.

 

[video321]

Thanks for posting that Mike - I'll try that once I have a chance.

 

[video321]

Got around to tweaking my rules....
 
Adding a (1) sec. delay via phantom output does indeed work.
 
Thanks, Mike.

 

[mikefamig]

My pleasure, It's good to give something back to the group.
 
I wish that there was a publication that explained how the M1 executes rules. The timing of how and when rules are triggered is critical but is still a bit of a mystery to me. It appears to me now that it is possible for two rules to trigger at exactly the same time with one negating the other as opposed to them triggereing in sequence or some logical order.
 
I asked this question at the elk forum quite a while ago and got no reply so I think that I'll have to learn by trial and error.
 
Mike.

 

[mikefamig]

Got around to tweaking my rules....
 
Adding a (1) sec. delay via phantom output does indeed work.
 
Thanks, Mike.

 
I think that I  will reduce my delays to 1 second as you did, I just used large delays to be safe and to be sure that I separate the triggers.
 
Mike.

 

[sda]

I wish that there was a publication that explained how the M1 executes rules. The timing of how and when rules are triggered is critical but is still a bit of a mystery to me. It appears to me now that it is possible for two rules to trigger at exactly the same time with one negating the other as opposed to them triggereing in sequence or some logical order.

 
Elk rules are event oriented.  If you're used to sequential programming logic, it can take a bit of getting used to. 
 
As a simplification, think of the rule list as a program.  When a condition (zone/output/alarm/etc) changes the Elk executes the rule list program trying to find a match.  If a matched rule causes a condition change, the Elk re-executes the rule list program.  
 
Most if not all of the problems with rules are user misunderstanding or not thinking through all the cases.  Been there, done that.
 
Don't count on the rules being executed in any particular order.  That may be the case, but if you are relying on that then you're not thinking in event oriented programming. 
 
Be aware of rules making a condition change (output/alarm/etc) and side effects of the new condition.  Consider these two rules:
 
Whenever zone 1 is not secure
   then turn output 1 on for 5 seconds
Whenever zone 1 is not secure
   then turn output 1 off
 
Same "whenever" clause, conflicting "then" clauses.  Without knowing the internal logic, output 1 could be on for 5 seconds, on for an instant, or never on at all.   Even if you test something like this you can't be 100% certain they will be executed the same way every time.
 
In other words, don't paint yourself into a corner with ambiguous rules.
 
Whenever output 100 is turned on
  then turn output 100 off
Whenever output 100 is turned off
  then turn output 100 on

 

[mikefamig]

Elk rules are event oriented.  If you're used to sequential programming logic, it can take a bit of getting used to. 
 
As a simplification, think of the rule list as a program.  When a condition (zone/output/alarm/etc) changes the Elk executes the rule list program trying to find a match.  If a matched rule causes a condition change, the Elk re-executes the rule list program.  
 
Most if not all of the problems with rules are user misunderstanding or not thinking through all the cases.  Been there, done that.
 
Don't count on the rules being executed in any particular order.  That may be the case, but if you are relying on that then you're not thinking in event oriented programming. 

 
You said above that the rule list executes in order and then you said not to expect the rules to execute in order. I don't unerstand.
 

Be aware of rules making a condition change (output/alarm/etc) and side effects of the new condition.  Consider these two rules:
 
Whenever zone 1 is not secure
   then turn output 1 on for 5 seconds
Whenever zone 1 is not secure
   then turn output 1 off
 
Same "whenever" clause, conflicting "then" clauses.  Without knowing the internal logic, output 1 could be on for 5 seconds, on for an instant, or never on at all.   Even if you test something like this you can't be 100% certain they will be executed the same way every time.

 
The fact is that I do not know the internal logic and have no clue how the above rules will execute. How would you interpret them?
 
Mike.

 

[mikefamig]

I think that I understand what you mean by event oriented.
 
When an event occurs the rule list is read sequentially looking for a match.
When a match is found it causes another event to occur
Then the new event causes the rules list to be read from the top for a match.
 
This makes sense but the timing still eludes me. It seems to me that some rules cause events to occur concurrently. In the past I have written two rules to cuase the system to speak and only heard one of them execute. I concluded that the two rules executed at the same time and only one was heard because there is only one audio output channel. The system did not execute one and then execute the other afterwards in the sequence that the rules were written.
 
Mike.

 

[BaduFamily]

I don't think we're talking about a NDP engine in this little box.
 
I think there is an event engine, and something that scans the rule set looking for event matches.
 
I am not sure if for a given incoming event all the matching events are executed, nor am I sure if running rules are interrupted by new events ( leaving state ambigious. ) I think this is what SDA is describing when writing "don't count on the rules being executed in any particular order.'
 
I do think there is an internal event system which queues internally generated events, such as rules which result in announcement events. I often get a sequence of announcements for a chain of events, but as often the sequence of announcements may miss an event.  Sometimes there is no announcement but state has changed.
 
I do think some real developer documentation would be great. But it's probably not worth Elk's time and would only cause them more consumer grief.

 

[Del91574]

There is some priority/timing in the events as they are fired, that came from Elk themselves when I was talking to them years ago....if you program the rules, a rule that is "higher" on the list will fire before ones "lower" on the list.

That said, I've never seen or really had a case where the rules completely stepped on each other if basic standards are maintained when configuring the rules. Yes, there are quirks, but nothing that is mission critical failures.
 
That said, I chalk it up to a $300 panel/processor (higher end for a consumer panel) vs. a $3K commercial access panel that requires a server for programming and higher intelligence.

 

[mikefamig]

Here's a case where Spanky advises using a delay to prevent two rules from intefering with each other. He is separating two "whenevers" so that the F key event is no longer active or expired when the second whenever rule executes. Otherwise the second rule would revese the action of the first. It is what clued me into timing rules in the first place but doesn't explain much.
 
http://cocoontech.com/forums/topic/20888-elk-rule-to-armdisarm-area-with-function-key/?hl=%2Belk+%2Barm+%2Bdisarm+%2Bkey#entry170108
 
Mike.

 

[mikefamig]

It occurs to me after some thought that we have to consider the lifespan of an event. If for instance an F key is pressed it causes an event but how long does that event live? In other words...... if you have several rules that check whenever that f key is pressed then how many will execute before the f key event expires? How many seconds does an F key event live?
 
Mike.

 

[sda]

A) You said above that the rule list executes in order and then you said not to expect the rules to execute in order. I don't unerstand.
 
 
B) The fact is that I do not know the internal logic and have no clue how the above rules will execute. How would you interpret them?
 
Mike.

1.  I did?  I said "executes the rule list program".  Sequential is the most likely choice for the Elk, but I've worked on software where user instructions are loaded and processed internally in a non-sequential order. 
 
2. The "zone 1" example was to show bad programming practices - they result in opposite outcomes.   If those two rules were interspersed in a complex rule list, that would qualify as both "ambigous rules" and "not thinking through all the cases".

 

[mikefamig]

1.  I did?  I said "executes the rule list program".  Sequential is the most likely choice for the Elk, but I've worked on software where user instructions are loaded and processed internally in a non-sequential order. 
 
2. The "zone 1" example was to show bad programming practices - they result in opposite outcomes.   If those two rules were interspersed in a complex rule list, that would qualify as both "ambigous rules" and "not thinking through all the cases".

Well if they are not sequential and you can not expect them to be in any particular order then we are left to guessing.
 
Mike.