Elk M1 serial and ethernet interface

[yzf600]

I'm going to purchase an Elk M1 (8EZ or Gold) soon. Being an electrical engineer and wanting custom features, I want to develop my own ethernet -> serial interface for it. I have already developed a custom interface board solution that can talk on a RS485 bus or on a RS232 bus.

I see the RS232 interface to the Elk is well documented. What I'm wondering is what traffic is occurring on the "Data-Bus" (which is a RS485 bus I believe). Are the same ASCII commands on the RS232 interface also sent onto the Data-Bus? If they aren't exactly the same commands, are they close?

You may be wondering why go to all the trouble of re-inventing the wheel. Well, one feature I want is for the Elk to monitor my garage doors (I have 2). I want to be able to leave the house in my car and have the choice of:

1) press a single button on a remote and close all open garage doors and arm the Elk.
2) press a single button on a remote and close the open garage door(s) without arming the Elk.

Upon returning home, I want to press one button to open the door. This one button would be smart and know if it needs to disarm the alarm before opening the door.

I currently plan on having a micro-controller (an atmel avr32 ngw100 development board) interface between the Elk and a custom 8 button wireless remote. The initial plan is to have some zones on the Elk as arm/disarm zones that the micro controller interfaces to. Other possible and preferred alternatives to this would be for the ngw100 to talk directly to the Elk on the Data-Bus or talk directly via the Rs232 port.

I also might want to develop an ZigBee wireless home automation interface. The ngw100 board could serve an an ZigBee (Xbee) coordinator. I'd like to develop my own light/appliance "modules" as xbee routers/end devices. Heck, I may even develop my own xbee window sensors and skip using current wireless sensor technology. I'm tired of waiting for the industry to roll out a real ZigBee solution. And I don't like Zwave.

Another benefit of my custom board, would be for me to code up my own IP based features. Something like the ngw100 grabbing video frames from IP cameras around the house and emailing the images to me so I can understand why the alarm triggered. Why pay $12 a month when I can do the same job myself for free?

 

[mustangcoupe]

You may be wondering why go to all the trouble of re-inventing the wheel. Well, one feature I want is for the Elk to monitor my garage doors (I have 2). I want to be able to leave the house in my car and have the choice of:

1) press a single button on a remote and close all open garage doors and arm the Elk.
2) press a single button on a remote and close the open garage door(s) without arming the Elk.

Upon returning home, I want to press one button to open the door. This one button would be smart and know if it needs to disarm the alarm before opening the door.

This has been discussed around here a few times. and the question that always comed up is .... "Do you really want one point of failure of your system?" If someone gets their hands on your remote your alarm is usless along with your physical soloution (Lock and Key)

If your answer is still Yes I beleive the elk can still do what you want by monitoring the zones attached to the garage doors and using a elk wireless receiver and remote. No need to spin your own custom soloution.

 

[yzf600]

This has been discussed around here a few times. and the question that always comed up is .... "Do you really want one point of failure of your system?" If someone gets their hands on your remote your alarm is usless along with your physical soloution (Lock and Key)

With my wireless solution, each remote has a unique address/key. Every remote has to be authorized to work in the system. If the remote is stolen or lost, I can just remove it from the authorized list.

 

[paulw11]

With my wireless solution, each remote has a unique address/key. Every remote has to be authorized to work in the system. If the remote is stolen or lost, I can just remove it from the authorized list.

Keyfobs that are used with the Elk wireless receiver also have a unique ID. They need to be learned into a zone on the wireless receiver can be deleted if lost, they only have 4 buttons however (An extra "button" is available by pressing two buttons simultaneously).

I use logic similar to that which you have described using the rules in the M1. I have the remote triggers for my garage door openers connected to relays on the M1. When the door button is pressed a rule in the M1 triggers the relay for a second and disarms the alarm if it is armed.

As for the RS-485 bus, the data on the bus is encrypted and not documented. The same data that is available on the serial port (and which is documented as you mentioned) is also available via a TCP/IP port when the ethernet interface is connected. You can use this port to monitor zones and control the M1 by sending commands.

Paul

 

[mustangcoupe]

With my wireless solution, each remote has a unique address/key. Every remote has to be authorized to work in the system. If the remote is stolen or lost, I can just remove it from the authorized list.

This is just trusting that you know as soon as a keyfob or remote is lost. (wife, kids, ect...)

 

[Spanky]

yzf600,

You certainly can make a RS-232 interface to control the EZ8 or M1. An example is the ELKRM program that uses the RS232 ASCII protocol. We have a program that runs on a PC called the M1SDK.exe which makes building ASCII strings easier.

You can also simplify the ASCII commands by writing Rule Tasks in the M1 that can do multiple things from a single ASCII Task trigger command sent into the RS232 Port.

Everything you mentioned in your post can be handled in the M1 Rules and triggered from a RF keyfob or ASCII command.

Direct connection to the RS485 data is bus is not an option at this stage because it is not an open protocol for security reasons.

A Zigbee interface could be very interesting.


Have fun!

 

[sharby]

I'm going to purchase an Elk M1 (8EZ or Gold) soon. Being an electrical engineer and wanting custom features, I want to develop my own ethernet -> serial interface for it. I have already developed a custom interface board solution that can talk on a RS485 bus or on a RS232 bus.

I see the RS232 interface to the Elk is well documented. What I'm wondering is what traffic is occurring on the "Data-Bus" (which is a RS485 bus I believe). Are the same ASCII commands on the RS232 interface also sent onto the Data-Bus? If they aren't exactly the same commands, are they close?

You may be wondering why go to all the trouble of re-inventing the wheel. Well, one feature I want is for the Elk to monitor my garage doors (I have 2). I want to be able to leave the house in my car and have the choice of:

1) press a single button on a remote and close all open garage doors and arm the Elk.
2) press a single button on a remote and close the open garage door(s) without arming the Elk.

Upon returning home, I want to press one button to open the door. This one button would be smart and know if it needs to disarm the alarm before opening the door.

I currently plan on having a micro-controller (an atmel avr32 ngw100 development board) interface between the Elk and a custom 8 button wireless remote. The initial plan is to have some zones on the Elk as arm/disarm zones that the micro controller interfaces to. Other possible and preferred alternatives to this would be for the ngw100 to talk directly to the Elk on the Data-Bus or talk directly via the Rs232 port.

I also might want to develop an ZigBee wireless home automation interface. The ngw100 board could serve an an ZigBee (Xbee) coordinator. I'd like to develop my own light/appliance "modules" as xbee routers/end devices. Heck, I may even develop my own xbee window sensors and skip using current wireless sensor technology. I'm tired of waiting for the industry to roll out a real ZigBee solution. And I don't like Zwave.

Another benefit of my custom board, would be for me to code up my own IP based features. Something like the ngw100 grabbing video frames from IP cameras around the house and emailing the images to me so I can understand why the alarm triggered. Why pay $12 a month when I can do the same job myself for free?

You can also use PowerHome to interface ELK and do exactly what you're looking to do. I use a long range RF receiver (UPB-572) to perform multiple functions. I use a sequence of button presses that have to be exact in order to open/close garage doors.


-=*Sharby*=-

 

[Lagerhead]

I currently plan on having a micro-controller (an atmel avr32 ngw100 development board) interface

Does this NGW100 have Perl on it? Is a C compiler available? What exactly is the development environment?

 

[yzf600]

I currently plan on having a micro-controller (an atmel avr32 ngw100 development board) interface

Does this NGW100 have Perl on it? Is a C compiler available? What exactly is the development environment?

You can install micro perl on it. I'm going to install python on it instead and learn that language for my task. Doing these things requires you to re-compile the entire linux package for the ngw100 from scratch. While this may sound daunting (it did for me at 1st), there is a reasonable amount of community support for this board. Check under the wiki and forums for avr32 and avr32 linux. There is also a site dedicated to the software part of the board.

There are several development environments, some for linux and some for windows. I'm personally using the linux cross compile gcc environment.

Project status:

I've got Python installed on the ngw100. I can send email out from the ngw100 via a python script and my gmail account. I also have the pyserial module installed. This will allow me to easily communicate to my elk panel via rs232.

Next steps are to actually buy my Elk M18EZ and related components. I also need to buy and assemble the remote control daughter board for the ngw100.

 

[heffneil]

I don't know about the Elk but I have an Omnipro and I know you can get a wireless controller. Get a similar device to arm your alarm and then write a program that when it is armed close the garage doors which are a set of relays if the zone is not secure. Maybe I missed something but that is how I would do it with the Omni and I think that is pretty easy. Am I missing something or is it my lack of Elk knowledge that makes it more complex?

Thanks!

Neil

 

[Spanky]

The M1XRF2G or M1XRF1N Wireless receiver gives you full access to all the GE wireless transmitters including multi button keyfobs. You can write rules to do things with the received transmitter data or place the M1 in to special mode to send the transmitter data out the RS232 serial port.

The sky is the limit!!

Cocoontecher's little known feature in latest M1 software upgrade:

RF received data sent to RS-232 serial port 0 mode:

From the M1's keypad enter installer programming, go to Globals G44, right arrow, enter 55555 into the a: field, press ***.
Every transmitter transmission received will be sent out the RS-232 serial port in this form:

A2-Z21-A29B68-Lb0-B0-L11-L20-R0-Tp1-Tb0-M1-CrB0

A2 = address of receiver on the RS-485 keypad data bus
Z21 = zone number of transmitter enrolled in M1
A29B68 = Serial number of transmitter
LB0 = battery in transmitter is OK, LB1 = battery in transmitter is low
B0 = button data from transmitter, usage will vary according to type of transmitter
L11 = hardwire loop 1 is violated, L10 = OK, usage will vary according to type of transmitter
L20 = hardwire loop 2 is OK, usage will vary according to type of transmitter
R0 = Reed switch in tranmitter is closed, usage will vary according to type of transmitter
Tp1 = tamper switch is violated, usage will vary according to type of transmitter
Tb0 = test button is OK, usage will vary according to type of transmitter
M1 = Manufacturer of transmitter = GE, M2 = manufacturer of transmitter is Ness Security
CrB0 = CRC byte of data received at RF receiver. This is verified by the M1 when the RF data is received by it.


You can view the data with HyperTerminal or the M1SDK program connected to the RS-232 bus or the data coming out of the M1XEP Ethernet connection.

If the M1 is powered down or reset the RF data will stop until the procedure above is repeated.



Have fun!

 

[Photon]

What is the M1XRF1N mentioned above?

 

[gatchel]

At first I thought "It's ELks own wireless version".

Now I realize it may be a "slip"...


What is the M1XRF1N?

Inquiring minds want to know, and maybe want to spend money!

 

[Spanky]

The ELK M1XRF1N is an RF receiver for the Ness Security transmitters. It has not been released in the US yet!

 

[123]

...
Every transmitter transmission received will be sent out the RS-232 serial port in this form:
A2-Z21-A29B68-Lb0-B0-L11-L20-R0-Tp1-Tb0-M1-CrB0
...

Spanky,

The message format doesn't follow the documented version (in ASCII Protocol, Rev 1.66). It lacks the initial two-digit string-length, two-character Message/Sub-Message identifier and it uses hyphens to delimit the data fields. Is this a new command format or was the example simplified for readability?

I guess the same can be said for the AMX command you mentioned in another post:
AMXB<-SDKClass=SecuritySystem><-Make=ELK><-Model=M1><-Revision=5.1.5>

No length, three-character command, no checksum.


BTW, I found several potential errors in the ASCII Protocol manual (rev 1.66) that I posted in the M1 Dealer forum. I'm awaiting a reply; for the benefit of Cocooners here they are:

RE: Manual Revision 1.66

Page 15: Alarm By Zone Request
The Zone Definition list indicates:
Carbon Monoxide='A'
Emergency Alarm='B'
Freeze Alarm='D'
Gas Alarm='E'
I think everything after 'Emergency Alarm' is incorrect because it skips 'C'. The Zone Definition list is repeated on page 41 for the ZD command and shows 'C' is assigned to 'Freeze Alarm' and not 'D'.

Is this a documentation error or does the AZ command operate with a different Zone Definition list?

Page 25: Keypad KeyChange Update
The Key Table list indicates:
LEFT KEY = 25
F6 Key = 26
F5 Key = 27
I haven't confirmed it but is it possible that the F5 and F6 keys are transposed? Whereas FK1 - FK4 are listed in increasing numerical order, FK5 and FK6 are not.

Page 5: "DK - Display KP LCD Data"
The "DK" command is listed but not documented in the manual. However, it sounds like another command "Display Text on LCD Screen (dm)". Is this a typo or a new (undocumented) feature?


I'm happy to see that rev 1.66 corrected the terminology used to describe a zone's state (page 16). In pre-1.66 manuals, the description made no sense to me and I refused to use it in my M1 driver (i.e. open/short/EOL is not the zone's Logical state)! The incorrect terminology was adopted by another vendor's ELK M1 Driver (although with hesitation, I'm sure). I was planning to report it to ELK and then discovered it was corrected in rev 1.66. There are a few more "oddities" in the manual ...