Elk rules engine

M

mikefamig

Senior Member
I am trying one more time to get some info on how the Elk rules engine executes rules. I have inquired at the Elk tech forum with no reply and here and have gotten no help yet. Is it possible that there is no one here who understands the system? Is this a taboo topic? Proprietary information?
 
I am including a link to an old message thread and you can find my post  #16 near the end of the thread.
 
http://cocoontech.com/forums/topic/4561-elk-rule-engine-question/page-2
 
Any interest?
 
Mike.
 
There are plenty of people around who have a pretty good grasp of the how the M1 handles rules - but I think your question might be a lost - what specifically do you want to know about how it processes rules?
 
Work2Play said:
There are plenty of people around who have a pretty good grasp of the how the M1 handles rules - but I think your question might be a lost - what specifically do you want to know about how it processes rules?
Click to expand...
 
I've been learning myself by trial and error and have some understanding but I would like to know what exactly happens when an "event" occurs. 
 
As I understand it the rules list is read from top to bottom and each "whenever is evaluated to see if it involves that event. But then that same rule can trigger another event at which time the rules list is evaluated from top to bottom again and this keeps happening as events occur.
 
What I don't understand is how long an event lives. You may have noticed that a "whenever" rule is triggered by an event but an "and" condition is triggered by an existing state. So when a door opens an event occurs but at some point that event becomes an existing state of "door open".
 
To sumit up I am confused about the lifespan of an event and the order and timing of execution. For example if you have several rules checking for sensor1 to open will they all trigger? I have found that if I put a timer in a rule to stall execution for a number of seconds that the rules do not all execute.
 
Mike.
 
mikefamig said:
I've been learning myself by trial and error and have some understanding but I would like to know what exactly happens when an "event" occurs. 
 
As I understand it the rules list is read from top to bottom and each "whenever is evaluated to see if it involves that event. But then that same rule can trigger another event at which time the rules list is evaluated from top to bottom again and this keeps happening as events occur.
 
What I don't understand is how long an event lives. You may have noticed that a "whenever" rule is triggered by an event but an "and" condition is triggered by an existing state. So when a door opens an event occurs but at some point that event becomes an existing state of "door open".
 
To sumit up I am confused about the lifespan of an event and the order and timing of execution. For example if you have several rules checking for sensor1 to open will they all trigger? I have found that if I put a timer in a rule to stall execution for a number of seconds that the rules do not all execute.
Click to expand...
 
 
Another way to put it is whether the M1 takes a snapshot of the state of all inputs and outputs when the initial event occurs, and uses the data for a single pass through the rules list.   If something changes during execution of the rules list, then that would trigger the execution of another pass, with a new, updated snapshot.
 
I don't know whether that's the way it works or not.  Some things make me think that there is no snapshot at all, and thus the conditions one rule sees could be different from those another rule sees.  That would allow a very brief input change (say 50ms) to be missed completely, depending on where it happens during execution of the rules.
 
This is an important piece of information, but not documented anywhere that I have seen.  It's all anecdotal.
 
RAL said:
I don't know whether that's the way it works or not.  Some things make me think that there is no snapshot at all, and thus the conditions one rule sees could be different from those another rule sees.  That would allow a very brief input change (say 50ms) to be missed completely, depending on where it happens during execution of the rules.
Click to expand...
 
This is the way that I'm thinking right now.
 
I never had a good grasp on this either.  Spent a lot of trial and error when I was writing my rules years ago until I got the hang of it (and have since forgotten it).  Coming up on the 10 year mark and I don't think I have added any rules in years other than re-enabling things now and then when HS crashed etc.
 
That being said the ELK has been by far the most reliable piece of HA equipment I have.  The only runner up is the UDI ISY which works very well and is reliable but I occasionally see a hiccup.
 
Some people are starting to say the M1 is dated and I guess I cant argue that.  But its rock sold performance means a lot and blows away a lot of true HA products. 
 
Digger
 
Nobody seems to have a good grasp on this and I'm surprised, it seems that it should be common knowledge to a professional  installer . It really isn't necessary to know if you are only going to have a few rules but I am up to 30 rules and it is becoming harder to coordinate them all without a good understanding of how the rules are executed. I don't like guessing and spending hours of trial and error and I'm surprised that this isn't documented.
 
Mike.
 
I just checked and I currently have 65 rules; I have no issue with the rules engine, except when I make dumb coding decisions of my own.
 
Having said that, I have taken courses on C, C++, and am currently learning Python... so I'm not a beginner when it comes to software/code either.
 
drvnbysound said:
I just checked and I currently have 65 rules; I have no issue with the rules engine, except when I make dumb coding decisions of my own.
 
Having said that, I have taken courses on C, C++, and am currently learning Python... so I'm not a beginner when it comes to software/code either.
Click to expand...
 
If you don't know how and when the rules are executed then you are doing some guessing.With your programming skills I would think that  you could explain this to me. Please answer for me the question that I posed in post #3.
 
Mike
 
Without knowing how their code is written it's almost impossible to know exactly how those situations are handled. Having said that, I'd have to look, but I don't know if I have multiple rules that trigger of the same Whenever statement (I checked, see more below).
 
My mention about coding above was really to say that I am very careful with how I program rules. As I've mentioned in other threads, I have NO rules that check ever X duration (seconds, minutes, or hours). I haven't found a case where I absolutely need that done, and I have concern of exactly what you're discussing in this thread (e.g. what happens when sunset and every X second occur at the same time). I purposely try to avoid those scenarios.
 
I just checked, and of the ~65 rules, I have 2 pairs that trigger off the same WHENEVER; Sunset and a motion becoming not secure.
 
I don't have any issue with any of those firing, but I looked a little deeper for the SUNSET ones. Of the sunset based rules one simply sets a counter, and the other sends messages to turn on some outdoor lights. Neither of them have AND statements attached. The counter of the first, is actually used as a trigger to end up turning on an outlet.
 
If I ran into a case where I was having an with the second rule firing, I'd simply set a phantom output at the end of the first, and trigger the second rule - which is pretty much what I'm doing above anyway. Since I don't have any AND statements in either line, technically I could just combine the THEN statements into a single rule - one was programmed in 11/2012 and the other 5/2014, and I'll admit that I didn't bother to look through the rules to see if I already had a WHENEVER sunset rule before I created the second.
 
drvnbysound said:
Without knowing how their code is written it's almost impossible to know exactly how those situations are handled. Having said that, I'd have to look, but I don't know if I have multiple rules that trigger of the same Whenever statement (I checked, see more below).
 
My mention about coding above was really to say that I am very careful with how I program rules. As I've mentioned in other threads, I have NO rules that check ever X duration (seconds, minutes, or hours). I haven't found a case where I absolutely need that done, and I have concern of exactly what you're discussing in this thread (e.g. what happens when sunset and every X second occur at the same time). I purposely try to avoid those scenarios.
 
I just checked, and of the ~65 rules, I have 2 pairs that trigger off the same WHENEVER; Sunset and a motion becoming not secure.
 
I don't have any issue with any of those firing, but I looked a little deeper for the SUNSET ones. Of the sunset based rules one simply sets a counter, and the other sends messages to turn on some outdoor lights. Neither of them have AND statements attached. The counter of the first, is actually used as a trigger to end up turning on an outlet.
 
If I ran into a case where I was having an with the second rule firing, I'd simply set a phantom output at the end of the first, and trigger the second rule - which is pretty much what I'm doing above anyway. Since I don't have any AND statements in either line, technically I could just combine the THEN statements into a single rule - one was programmed in 11/2012 and the other 5/2014, and I'll admit that I didn't bother to look through the rules to see if I already had a WHENEVER sunset rule before I created the second.
Click to expand...
 
I agree that with careful thought and planning we can USUALLY get to a desired end but I also think that to unlock the true potential of rules you should understand how they are executed. The following rules do not work without the use of the phantom outputs to pause execution suggesting that timing of execution is critical.
 
Consider the following:
 
ARM AND DISARM GARAGE WITH F4 KEY

 28 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
 29 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
 30 WHENEVER  Output 102 STATE IS TURNED OFF
            THEN ARM AREA(S) 2 TO AWAY IMMEDIATELY
 
Inquiring minds want to know.
 
Mike.
 
 
drvnbysound said:
Without knowing how their code is written it's almost impossible to know exactly how those situations are handled.scenarios.
Click to expand...
 
This is my point exactly and I believe that there are people at Elk that can look at my example rules using the F4 key and tell me exactly how the rules are executed and why the pauses are necessary. Why isn't this documented information? Why are we left to guess?
 
Mike.

 
 
mikefamig said:
Nobody seems to have a good grasp on this and I'm surprised, it seems that it should be common knowledge to a professional  installer . It really isn't necessary to know if you are only going to have a few rules but I am up to 30 rules and it is becoming harder to coordinate them all without a good understanding of how the rules are executed. I don't like guessing and spending hours of trial and error and I'm surprised that this isn't documented.
 
Mike.
Click to expand...
I don't lose sleep over it with accounts in upwards/over 100 rules. I've got better things to worry about and usually there's a more robust back end to the M1 that takes the real heavy lifting out of the equation.....then again I deal with enterprise access control hardware and servers, so syntax and logic usually is trivial on the M1 compared to that. Once you get the basics of how to construct the rule and what works and what doesn't it's really not that bad. Maybe I just don't have the items that require a global system check or time delay like you.
 
DELInstallations said:
I don't lose sleep over it with accounts in upwards/over 100 rules. I've got better things to worry about and usually there's a more robust back end to the M1 that takes the real heavy lifting out of the equation.....then again I deal with enterprise access control hardware and servers, so syntax and logic usually is trivial on the M1 compared to that. Once you get the basics of how to construct the rule and what works and what doesn't it's really not that bad. Maybe I just don't have the items that require a global system check or time delay like you.
Click to expand...
 
Yeah no big deal. I spent most of the 80's as a programmer and computer data processing was my college major so I guess it's my nature to want to know how it works. I feel that I could spend less time with trial and error if I had a better understanding.
 
Mike.
 
I'm with DEL as well here... I don't need to know about the inner workings of the rules engine and don't get bogged down with said details. That's the job of the hobbyist and tinkerer ;)
 
You must log in or register to reply here.

Similar threads

J
Elk M1G and Z-wave - how (current availability)?
Replies
4
Views
158
Ira
I
R
Advice in Designing new Elk System
2 3
Replies
37
Views
2K
rmf
R
T
Problem with Elk Counters when using as a countdown timer
Replies
11
Views
2K
wmahvd
W
CT Droid
  • Locked
The end of an era for me
Replies
0
Views
4K
CT Droid
CT Droid
upstatemike
Need help with Elk M1 Rules
Replies
9
Views
588
upstatemike
upstatemike
Back
Top