Hacking M1G rules: externally sending rules to the M1G

cmidgley

New Member
Anybody have any success in externally (via M1XEP ethernet) sending new rules to the M1G, similar to how you would use ElkRP2 for updating rules? 
 
My use case is that I have a complex series of rules that change on a regular basis.  I have a program I use that makes defining my requirements really easy, and it outputs all the rules necessary for the M1G to do it's magic.  However, I'm still left with the tedious task of manually entering those rules.  I was hoping to send those new rules directly to the M1G from my program.
 
So far I've tried:
- Looking at the serial protocol documentation for M1G, but no mention of managing the rules
- Opening the ElkAccts2.mdb file directly (Access in Office 365, as well as direct via ODBC) but get a permissions error that I've failed to figure out how to get around.  Perhaps need a much older version of Access?
- Examining the export file format, but it is a long CSV file with tons of numbers and not obvious how to work with it
 
I've not yet attempted to monitor the serial connection between the XEP and M1G to see if I can "reverse engineer" the ElkRP2 protocol - but I guess that's an option, but would likely be more work than it's worth.
 
Any hints on how to break through on any of the above, or other ideas to do it?  Or is this a dead-end with the M1G?
 
Thanks!
 
Chris
 
upstatemike said:
Can you do a backup of the M1G, edit the resulting file somehow, and then restore it?
 
No luck there, the format is a massive CSV file with tons of numbers that make little sense.
 
I also tried copy/paste, but ElkRP2 doesn't use the real clipboard, so it's not there.
 
Anyone by chance figure out how to open the database file in Access (or some other tool)?   Or attempted to reverse engineer the protocol - or at least looked at it to see if it is unencrypted and similar to the serial protocol?
 
In case anyone else tries to do this, I found one way that seems to work.  The file format used for exporting/importing rules isn't too hard to figure out.  It's basically sequence of 8 numbers (decimal, all 8-bit numbers).  For a new rule, the first four are the "whenever" and the second four are the "then" (when you have a single whenever/then).  If you have AND clauses, then the second four digits indicate that, and the next set of eight have the next "whenever" rule to AND.  The following sets of eight numbers are the "then" rules.
 
The first number is the type of rule, and the following three numbers are specific to the rule.  One of the harder things to figure out is the ID of the object - for example, the zone number, or the output number.  In some rules, that number is simple - 1 for output 1, 8 for output 8.  In other cases it is offset by some value, such as by 136 (I forget the exact numbers used right now, so that's just an example) - so zone 1 might be 137, and zone 8 might be 144.  The other parameters, generally, are aspects of the rule (like is the "turns on" vs. "turns off" of a "whenever Out 1 turns on" type rule.
 
The PITA problem is that when new rules are created into a file, you have to manually go to ElkRP2, select the old rules and delete them, then import the new ones.  Not too bad, compared to doing it by hand!
 
Also worth noting, I looked at the non-encrypted IP traffic during an ElkRP2 programming session.  It wasn't obvious, but it looked like when the rules were being sent that it was a binary representation of the above format.  But that would take a lot more effort to figure out. 
 
I'm not exactly sure what "a complex series of rules that change on a regular basis" means, but if you have a discreet set of changing rules (e.g. Set A, Set B, etc) as opposed to an ever and always changing set with no constancy to any particular set, maybe you could set up Set A as one ElkRP account and Set B as another separate ElkPR account (and so on) and then have your program load (or tell you what account to load) into Elk RP depending on the rules it needs/generates. 
 
I do something similar with on ElkPR account that has the rules I use most of the time, and a separate account I load for extended vacations.
 
I guess it depends on the frequency/consistency of your rules (and changes) and whether your program could auto load one account vs another into Elk.
 
Good luck.
 
What's the use case of the "complex set of ever changing rules"?  Do the rules actually change or is that there is a large group of rules?
Certainly tieing in with a full automation controller would help.
I like keeping the security system simple, doing it's security thing.
Yes, the ELK can do more, but it quickly finds limitations.
 
DavidL said:
What's the use case of the "complex set of ever changing rules"?  Do the rules actually change or is that there is a large group of rules?
Certainly tieing in with a full automation controller would help.
I like keeping the security system simple, doing it's security thing.
Yes, the ELK can do more, but it quickly finds limitations.
 
I agree with focusing the Elk on security.  I use other devices (raspberry pi & isy994) to offboard any non-critical functionality.  But anything that is deemed critical - safety of life related, is always in the Elk.
 
The application is on a boat, where the device is managing 3 bilge pumps, 7 bilge compartments, 2 engines, and general security - alerting on minor conditions (day time only, occasional alerts), major conditions (24x7 voice and keypad repeating the condition continuously with timed mute) and directly management of the pumps (emergency removal of water).
 
The Elk has a great, but limited, rules system.  Some things that seem simple turn into a lot of rules.   One example of this is being able to alert the crew of the vessel that multiple conditions have occurred simultaneously (timed) via voice and keypad messages.  To do this, the best way I've found is to set up a counter to walk thru all possible conditions, have a rule (actually two) for each condition to determine if that condition is currently occurring, and if it is, trigger a voice announcement and a keypad message (with appropriate delay) otherwise increment the counter and test the next condition.  Other rules that become complex are managing the pumps themselves, where you need to "debounce" the switch (don't turn on pumps due to sloshing in the bilge), monitor how long and how often they run, and set/clear a output to reflect the current condition (clear, low water, high water, excessive pump run time) so that the alerting loop can alert on the condition.  
 
This is 100% possible to do by hand (and I have for my tests), and does not change often once perfected.  But it is highly repetitive and error prone to program those rules (for example, monitoring one of those bilges is around 10 separate rules), so I was hoping to write a "template rule set" for those areas and generate (aka, compile) the rules.  This would make it much easier to expand and perfect, as right now I find I often have to update/rewrite many rules on a simple change because of the inter-related functionality of the rules.  The result is constant debugging problems because of silly rules errors, leading me to become very nervous editing the rules.  Instead, if I edit the base template and generate the rules, my human error side of the rules management goes away, and I'm freed up to focus and innovate on the true value.
 
So sorry, I misspoke with "ever changing" - I really meant highly repetitive and when updating requires manually reentering a ton of rules (which I usually make mistakes doing).
 
Though I do wonder if an Elk template rules generator has a market...?
 
Back
Top