Elk rules engine
- Thread starter mikefamig
- Start date
drvnbysound
Senior Member
mikefamig said:
Me too
drvnbysound
Senior Member
As I mentioned earlier, I don't have any issue with the execution of any rules... so spending time trying to dissect an unknown issue is not something that I care to spend my time on. The value / time is just not there for me. If I were to run into an issue, tech support is a simple call or email away.
Putting on my computer systems designer hat for a moment, I'll say that any programmable system needs a well defined, documented architecture in order to be programmed properly by others. Without that documentation, you end up having to do it by trial and error. Sure, after a while, you'll learn enough to be able to write rules without too much stumbling around. But you don't really have a way to know what you don't know, and when that might come back to bite you.
It surprises me that for a system like the M1, that can be used for life and property protection, this documentation doesn't seem to exist.
Don't get me wrong - I like the M1, but it sure would be nice if they provided better documentation for it.
It surprises me that for a system like the M1, that can be used for life and property protection, this documentation doesn't seem to exist.
Don't get me wrong - I like the M1, but it sure would be nice if they provided better documentation for it.
drvnbysound
Senior Member
Here's ~90 minutes of instruction:
https://www.youtube.com/watch?v=LP7E3Lt8yFQ
https://www.youtube.com/watch?v=LP7E3Lt8yFQ
tmbrown97
Senior Member
I don't know the specific answers to your question from #3, but your post below about the execution of the F4 button does make a little sense to me. If rules are executed in order and your trigger is also a condition with multiple rules that follow the same trigger/condition logic, it makes sense that there'll be a collision.
If Garage is armed, disarm it
followed by:
If Garage is Disarmed, Arm it
If a single pass is made through the rules per trigger event, then one way or another either on arm or disarm you're going to cause double execution - depending on which one happens first. The way around this is the addition of a phantom trigger as you discovered... so it becomes
If Garage is Armed, turn on Out 100 for 1 second
If Garage is Disarmed, Turn on Out 101 for 1 second
When Out 100 Turns off, Disarm Garage
When Out 101 Turns Off, Arm Garage
It's extra rules of course but it's how you avoid the collisions.
I've done other rules where the order was very important because of how the M1 evaluates conditions - as far as I can tell it executes in order so if the criteria in one rule is affected by an action of the one above you can alter the results.
It would be nice to have better documentation; and back in the day, Spanky was a regular here and provided great information. However the company has been through some changes and we are where we are at least for the time being.
If Garage is armed, disarm it
followed by:
If Garage is Disarmed, Arm it
If a single pass is made through the rules per trigger event, then one way or another either on arm or disarm you're going to cause double execution - depending on which one happens first. The way around this is the addition of a phantom trigger as you discovered... so it becomes
If Garage is Armed, turn on Out 100 for 1 second
If Garage is Disarmed, Turn on Out 101 for 1 second
When Out 100 Turns off, Disarm Garage
When Out 101 Turns Off, Arm Garage
It's extra rules of course but it's how you avoid the collisions.
I've done other rules where the order was very important because of how the M1 evaluates conditions - as far as I can tell it executes in order so if the criteria in one rule is affected by an action of the one above you can alter the results.
It would be nice to have better documentation; and back in the day, Spanky was a regular here and provided great information. However the company has been through some changes and we are where we are at least for the time being.
ddennerline
Active Member
For the rule that you mentioned, I think it can be simplified using a counter . The counter would flip-flop back and forth. I have not tried this rule with alarm conditions, but it the concept is the same. A counter supports a 'toggle' operation. Based on counter, then do some action.
Code:
WHENEVER KitchenLight (Counter 2) CHANGES TO 1
THEN TURN FamilyRmCeiling [3 (A3)] OFF,
WHENEVER KitchenLight (Counter 2) CHANGES TO 0
THEN TURN FamilyRmCeiling [3 (A3)] ON,
WHENEVER Dinner Lights (Task 3) IS ACTIVATED
THEN TOGGLE KitchenLight (Counter 2)ddennerline
Active Member
I would be wonderful if Elk created a virtual ElkRP system emulator (similiar to Android emulator), so you could debug your rules by invoking different triggers. The biggest challenge with ElkRP is there are many different ways to formulate rules to do identical things. Unfortunately, when sometime works it’s too painful to try different constructs because ElkRP does not have official variable argument logging support (i.e., printf() debugging) .
d.dennerline said:
I've been using "and" verbs that cause the system to speak to give me audible cues that help me follow the execution of each rule. You can say something like turn the light on an dspeak the word ON. Then just remove those "ands" when you're done.
Mike.
Work2Play said:
OK then it has nothing to do with the lifespan of the event or how long the output is turned on as I suspected. It is turning out an output that causes a new event that causes another pass and then finally triggers the desired action. I did not understand it that way.
Mike.
drvnbysound
Senior Member
mikefamig said:
Ok, yeah... I thought that logic was apparent, but I guess not
My "concern" without a decent amount of testing is more related to a number of events that are triggered off the same WHATEVER statement. For example, if I have multiple rules that are triggered at Sunset and each has various AND statements. For S&G's, let's say the first one has multiple AND statements (front door secure, back door secure, whatever...), THEN does something. The execution of that is done QUICKLY, probably in milliseconds, maybe less... but it still takes time. So, what I am not sure of, is if the ~10 WHENEVER SUNSET rules get placed in a queue to execute, or is the rules engine simply running down the list... and at some point, it's no longer SUNSET, and is a rule possibly missed?
As I mentioned earlier, my other concern would be how well the execution of rules are handled when there are many WHENEVER Every 1 SECOND rules, that also take place at the same time as Sunset, or a door is opened, or whatever. If I have 15 WHENEVER Every 1 SECOND rules, and 10 WHENEVER Sunset rules programed, technically, all 25 of those need to be executed at the same time... How well that is handled, I have no idea.
That is the same with full blown access systems (though they're not rated for life safety applications, per se, but can be used as the head end for monitoring said equipment) and their operation is far more complex.RAL said:
I deal with Linel, Amag, P2000 and a few others....and their documentation is less than what comes with the M1. Hell, even after 5-10 days in class you still don't know how to do everything, let alone how some items are intermingled. Still have to break out paper to draw out the more complex actions and boolean operations.
Example:
https://www.youtube.com/watch?v=8DuLfj8Z_h8
A single panel is about $2K-5K+ the related peripherals, not including the server and software/license. If I can't get it with a product like that (and a few trainings that are upwards of $5-10K each and the certs) I can't see it happening on the sub $500 M1....what they could do, however, is provide SDK's that may provide some insight to 3rd parties.
drvnbysound said:
@drvnbysound - I appreciate the link to the Elk rules webinar. I watched that back when I initially bought my M1. It's great for getting started with understanding how to write rules, but it doesn't really get down into the nitty gritty details like we have been discussing here.
DELInstallations said:
@DEL - I understand your point. Overall Elk, does do a nice job on documenting the M1 with the printed manual plus the various webinars they make available. In this case, though, I don't think the information we're missing would be all that large an effort to produce. Probably just a few pages would cover it. Given how much effort they put into the rest of the documentation, it would probably be a modest task.
Sometimes, you just have to live with what there is, but it doesn't hurt to ask for improvements.
