Learning Elk rules language

[mikefamig]

I've been trying to do some pretty simple stuff with elk rules and the language is not intuitive. I want to arm two areas which proved to be very easy to do. I just made a rule that whenever area 1 is armed away then arm area 2 away and it works fine.
 
The problem is getting the voice to announce that the two have been armed and announce them in proper sequence. If there is no "then announce" clause after arming the two areas the system will automatically announce only the last area that was armed. If I add "then announce" the automatic voice  announcement goes away and the voice announces the area in the "then announce". If I add a second "then announce" then things get really weird with one or the other working but not both.
 
My point is that the "then announce" does not work as I expected it to. You can't just simply string a series of "then announce" one after another and expect them to work. Why is this? What am I doing wrong?
 
Mike.

 

[Del91574]

I'd set the areas to follow a phantom output and then have the X announce follow that ouput to build the inherent delay off the top of my head.

 

[mikefamig]

I'd set the areas to follow a phantom output and then have the X announce follow that ouput to build the inherent delay off the top of my head.

Hey DEL you seem to have adopted me here, so thanks for all the info.
 
So are you saying that a delay is necessary? Are the announcements stepping on each other and need to be timed?
 
Mike.

 

[mikefamig]

I'd set the areas to follow a phantom output and then have the X announce follow that ouput to build the inherent delay off the top of my head.

 
The phantom output for 10 seconds worked like a charm and a nice neat solution at that.
 
Mike.

 

[mikefamig]

BTW - I took your advise and bought some screw terminal recessed window sensors and am very happy with them. I still have one soldered joint between the resistor and cable but the end result is much less work and much neater connection.
 
Mike.

 

[tmbrown97]

Outputs really do become your friend with the M1 - using them you can cascade events and set the sequences to create the necessary delays.  You can also have fun with counters, etc.  Once you get the hang of it, you can find ways to accomplish quite a bit with it.

 

[mikefamig]

Outputs really do become your friend with the M1 - using them you can cascade events and set the sequences to create the necessary delays.  You can also have fun with counters, etc.  Once you get the hang of it, you can find ways to accomplish quite a bit with it.

I tried setting a counter to ten and decreasing it by 1 each second but I did something wrong because it didn't work. I'll have to do some reading and learn to use them. I studied business data processing in college and have programmed in several programming languages but there is no manual that I know of that describes the Elk rules language. Does one exist?
 
Mike.

 

[BraveSirRobbin]

For Elk M1 Registered Owners (General Rules Examples)
 
For Counters

 

[RAL]

there is no manual that I know of that describes the Elk rules language. Does one exist?

 
 
You may find the list in this previous post helpful.

 

[mikefamig]

I think that there are cases where the use of the word "whenever" confuses me a little and counters are a good example.
 
You can - set a counter to 10.
Then - decrease it by 1 each second
then - whenever the counter is equal to zero do a task.
 
My problem is that the counter was equal to zero before I set it to 10 and for all of the time except for that 10 second window that I created. .In other words, what is the order of execution for rules? This doesn't seem to be not a procedural programming language. If you read those three steps in order they make sense but what happens after that? When is the next time that they will execute?
 
I'm thinking that "whenever" the counter = 0 really means "whenever" the counter changes state to 0 from some other value?
 
Mike.

 

[drvnbysound]

Whenever is executed on the state change - literally. WHEN the door becomes not secure, not IF it's already open.
 
WHEN: this happens... at the moment in time that event occurs...
 
WHEN my front door becomes not secure, AND it's dark outside, THEN my foyer light turns on. So, as soon as I open the door, the light turns on. However, I can immediately, turn the light off and it will stay off - even if I leave the door open. Because the rule executes upon the door opening. Beside the point: I have to add a counter and some other logic to this rule, because if I'm getting groceries and my son is asleep, the light turns on every instant the door is open and keeps trying to turn the light on - and I keep hitting the switch to manually turn it back off.

 

[mikefamig]

Whenever is executed on the state change - literally. WHEN the door becomes not secure, not IF it's already open.
 
WHEN: this happens... at the moment in time that event occurs...
 
WHEN my front door becomes not secure, AND it's dark outside, THEN my foyer light turns on. So, as soon as I open the door, the light turns on. However, I can immediately, turn the light off and it will stay off - even if I leave the door open. Because the rule executes upon the door opening. Beside the point: I have to add a counter and some other logic to this rule, because if I'm getting groceries and my son is asleep, the light turns on every instant the door is open and keeps trying to turn the light on - and I keep hitting the switch to manually turn it back off.

 
 
OK so it IS a change of state that triggers the whenever statement. So the act of setting the counter to 10 (in this example) has to be qualified by a "whenever" ie whenever a zone becomes triggered.
 
That helps, I;ll have to experiment with it when I have some time later.
 
Mike.

 

[tmbrown97]

With counters there are two main ways I think of - Whenever X happens AND counter = 0, THEN; otherwise "Whenever Counter changes to 0 do ______".  I've used that to keep track of door openings and alternating between 2-3 actions, or counting each door that opens and knowing when they're all closed. 
 
That's a good explanation above; I've seen people on here get confused before with the order = Whenever Time = 9:00PM AND Alarm is Away is very different from Whenever Alarm Is Away and Time is 9:00PM; the first will fire at 9:00PM if the alarm is armed away - no other time; the 2nd one will only fire if you arm the alarm Away at exactly 9:00PM; no other time.