Elk rules engine

[ddennerline]

The rules engine is most likely implemented using a type of "Ladder Logic." Elk's CPU is Motorola PIC processor (I don't have the model number right now). If you are interested in how Ladder Logic works, then www.ladder-logic.com seems to have a good description. From a programing standpoint, I suspect the rules are not continuously analyzed from top to bottom (this would be very expensive). Instead, the rules engine creates multiple timer/rules chains. Inputs and outputs are matched. The CPU probably provides multiple programmable timer interrupts. I have not reversed engineered the firmware, I am making educated guess. Since ElkM1 is an embedded CPU and Elk had forked firmware to support GE Wireless receiver to save 14KB, we are not talking about iterative rules engine. Again, just an educated guess.

 

[mikefamig]

As a side issue, Is Elk answering questions for home owners? The last time I called in, they said I had to call AO.

Their rule is that they don't support the end user directly. They do have a support forum online but the response there isn't great. I've had better results contacting them by email and they have helped me out.
 
Mike.

 

[mikefamig]

The rules engine is most likely implemented using a type of "Ladder Logic." Elk's CPU is Motorola PIC processor (I don't have the model number right now). If you are interested in how Ladder Logic works, then www.ladder-logic.com seems to have a good description. From a programing standpoint, I suspect the rules are not continuously analyzed from top to bottom (this would be very expensive). Instead, the rules engine creates multiple timer/rules chains. Inputs and outputs are matched. The CPU probably provides multiple programmable timer interrupts. I have not reversed engineered the firmware, I am making educated guess. Since ElkM1 is an embedded CPU and Elk had forked firmware to support GE Wireless receiver to save 14KB, we are not talking about iterative rules engine. Again, just an educated guess.

 
Big help!
 
I just studied the first page of the tutorial at ladder-logic.com and it was very informative. At the bottom of the page they explain what they call the continuous scan cycle which is the logical order of execution that I was looking for and it seems to agree with what I've experienced in programming the Elk.
 
 
The Continuous Scan Cycle
Step-1 Inputs are scanned and the input file is updated.
Step-2 Routines are scanned and the logic is executed referencing the input file.
Step-3 Program overhead including communications, diagnostics and maintenance are performed.
Step-4 Outputs are updated according to the logic executed above. The process starts again.
 
If you are correct then it appears that Elk rules are the equivalent of PLC rungs and are evaluated continuously from top to bottom as described above. As inputs change they affect their linked outputs. This seems to agree with my thinking in post #41 as to the order of execution but I'm still not clear on the timing of things when outputs create new inputs that again create new outputs and so on.
 
High level languages like ladder-logic are just a way of understanding and presenting logic that in the end always breaks down to IF THEN ELSE switching logic, another way of saying the same thing. I think that I'm beginning to understand better how to write rules to the Elk. This is almost making me want to take up some coding again just as a hobby.
 
Thanks, Mike.

 

[mikefamig]

As a side issue, Is Elk answering questions for home owners? The last time I called in, they said I had to call AO.

 
BTW I've dealt with Trey at AO support and he's sharp, was very helpful and a nice guy. He teaches an Elk certification course for AO.
 
http://www.automatedoutlet.com/Training/Elk/TRN-ELK-03-24-25-15-LEWISVILLE
 
Mike.

 

[Del91574]

Since ElkM1 is an embedded CPU and Elk had forked firmware to support GE Wireless receiver to save 14KB, we are not talking about iterative rules engine. Again, just an educated guess.

They never stopped supporting GE wireless protocol. They only stopped the support of the 548E that brought data in another port and via another means.I'd say it's more of a business decision than a space saving feature....why buy from another manufacturer when you can sell your own devices that run off the bus. If they were that hard up for space they'd kill off one of the protocols that it supports for an expander.
 
Coming from an installation standpoint, it's far easier to have RF driven off a data bus than requiring a completely set of wires.....I was putting in M1's even before they supported the Caddx/GE receiver, before the EZ8 and when there was a M1 and M1G.
 

 

[mikefamig]

I received a reply to my question from Elk with a link to a nice write-up on how rules work. It's not a document that I could find on their web site with my home-owner access but the link exists in their public forum so I can't see a problem with sharing it here. I do think that you will need to sign up as a member to get to the link but then if you're an Elk owner then you probably already are a member.
 
http://www.elkproducts.com/ForumRetrieve.aspx?ForumID=2829&TopicID=2107795&NoTemplate=False
 
d_dennerline - it does look a lot like what I read about PLC in your link to ladder logic.
 
Mike.

 

[RAL]

I received a reply to my question from Elk with a link to a nice write-up on how rules work. It's not a document that I could find on their web site with my home-owner access but the link exists in their public forum so I can't see a problem with sharing it here. I do think that you will need to sign up as a member to get to the link but then if you're an Elk owner then you probably already are a member.
 
http://www.elkproducts.com/ForumRetrieve.aspx?ForumID=2829&TopicID=2107795&NoTemplate=False

 
Thanks for posting this, Mike.
 
I went looking on Elk's web site to see if I could find the document without the direct link.  I looked under "M1 Manuals and Documentation" in the owners' area, and didn't see it there.  But then I noticed at the very bottom of the list on the left side, almost like a footnote, is a link that says "View M1 Tech Note Archive."  And lo and behold, that's where it is, along with a number of other tech notes.
 
http://www.elkproducts.com/m1_technotes.html

 

[mikefamig]

RAL
 
Thanks for the tip

 

[BaduFamily]

The most recent addition to the archive too - thanks!

 

[thing]

It would be nice to have a good rule debugging tool so you can figure out why rules don't work correctly or why rules just sometimes don't work at all.  It is frustrating trying to debug why rules are not executing correctly.  Besides user mistakes (or lack of knowledge of how the rules will actually execute) system bugs are super frustrating.  Like Whenever every 5 minutes only executes every 10 min. (I finally put a send e-mail in the rule and got messages every 10min not every 5 min).  Whenever every 1 hour would not fire at all.  But every 59 minutes seems to work.  Other odd results from rules as well where they don't seem to work but then after messing with them (rewriting them a different way) and re-sending them form RP then they do (or not at all ever).  Is this a function of the 5.3.x firmware?  5.3.8 talks about fixing time based rule execution but the examples above are with 5.3.8. 
 
Are there any rule debugging tools?

 

[mikefamig]

It would be nice to have a good rule debugging tool so you can figure out why rules don't work correctly or why rules just sometimes don't work at all.  It is frustrating trying to debug why rules are not executing correctly.  Besides user mistakes (or lack of knowledge of how the rules will actually execute) system bugs are super frustrating.  Like Whenever every 5 minutes only executes every 10 min. (I finally put a send e-mail in the rule and got messages every 10min not every 5 min).  Whenever every 1 hour would not fire at all.  But every 59 minutes seems to work.  Other odd results from rules as well where they don't seem to work but then after messing with them (rewriting them a different way) and re-sending them form RP then they do (or not at all ever).  Is this a function of the 5.3.x firmware?  5.3.8 talks about fixing time based rule execution but the examples above are with 5.3.8. 
 
Are there any rule debugging tools?

 
I don't know of any debugging tools but I do things similar to your sending an email. If I want to prove that a whenever condition was met I will follow it with a "then" to speak a sentence or beep the keypad or something similar.
 
I studied data processing in the 1980's and programmed proficiently in a dozen different languages from low level coding like "assembly language" and C language to high level languages like BASIC LANGUAGE and they were all procedural languages. After years away from doing any coding I recently  installed the ELK and was faced with the elk rules language and I miss IF THEN ELSE and GOTO commands. The whole point of this message thread is that the higher level the coding language the more necessary it becomes to understand the compilation or interpretation of your code. You really really need to know what a line of code is going to do before you write it.
 
As for system bugs I have found Elk to be very tight lipped about calling anything a bug. As an example: when I arm area2 in my system and there is any zone violated in area1 the elk will speak that area1 violation as it arms area2.
 
When I questioned Elk about this they replied [SIZE=11pt]"At this time this is the way the system is operating". rather than calling it a known problem or bug. [/SIZE]
 
[SIZE=11pt]Mike.[/SIZE]

 

[RAL]

As for system bugs I have found Elk to be very tight lipped about calling anything a bug. As an example: when I arm area2 in my system and there is any zone violated in area1 the elk will speak that area1 violation as it arms area2.
 
When I questioned Elk about this they replied [SIZE=11pt]"At this time this is the way the system is operating". rather than calling it a known problem or bug. [/SIZE]
 
[SIZE=11pt]Mike.[/SIZE]

 
 
When they didn't want to fix something that customers considered a bug, a company I used to work for called that "working as designed," without any admission that it had been designed correctly or incorrectly.

 

[mikefamig]

When I worked as a British Leyland mechanic and a transmission was leaking on a new car it was called normal seepage.

 

[mikefamig]

RAL
 
another term that comes to mind is "undocumented features"