It doesn’t seem like there is much support for Elk M1. I’d like to explore creating a module for HomeAssistant. I’m much more of a hardware guy rather than a software professional, so let me know if anyone is interested in working on this with me.
My thoughts:
The ELK M1 has a defined serial protocol. Link to an older version of the spec:
It can be programmed to send updates over serial on events (i.e., door opening) or other changes (i.e., alarm triggered).
So it should be a simple matter to connect the serial output of the ELK M1 to the serial port of the Raspberry Pi. Then I’d just need to implement code to parse the received serial data from the M1 to figure out what they meant. That should be straightforward, I think…
But what I’m not sure about is how to translate these received serial events into Home Assistant states and variables and events. Does anyone know of something similar in Home Assistant that I could use as a starting point?
I’m a long time Elk installer and user. I’ve reached out to Elk for information on their Integration/Developer program. Hopefully we will be able to get API documentation which will enable us to integrate directly with the M1XEP.
I don’t have the M1XEP, but I don’t think I need it. The Elk communicates with the M1XEP over the serial port, and then converts that to Wifi traffic. I think the RPi can do most of what the M1XEP does.
I’ve got the M1 serial port connected to RPi using a USB-serial adapter, and I’m currently working on writing a parser to decode the commands. It was actually much easier than I was thinking. I’ll share my code if anyone is interested when I get things a little more cleaned up.
I’m an ISY user, so interfacing with the elk over the internet is something I’m already doing, but the ISY handles all the heavy lifting. I think what we’re trying to do here is create a native integration between Home Assistant and the Elk using the M1XEP IP gateway or a direct serial connection. From everything I’ve been told, you are correct in not needing the M1XEP, the only difference between connecting directly via Serial or via the M1XEP is just the connection pathway. The M1XEP is apparently just a glorified Serial over IP box…
I’ve received introductory guidance from Elk M1 on getting all this done and I’m willing to join the project to develop this. I’m an IT Generalist, Systems Administrator and SQL programmer but have committed to learning Python in order to further support my Home Automation hobby.
I just started using Home Assistant this past Saturday, so I don’t even know what language the integration would be written in…lol
you know what… I don’t see any privileged information in this e-mail…here it is
Thank you for your email and interest in creating your own Home Automation Software to interface with the ELK M1 System. If you understand “socket” programming and TCP/IP connections, it is a fairly simple process.
As you know, the M1 requires our M1XEP Ethernet Expander module to connect to a local network and the Internet. Look at the M1XEP as a simple "pass-through" device. Once you make a socket connection to it, your remote application can send and receive packets to/from the M1 using the M1's ASCII Protocol. These messages simply pass through the XEP to the M1 and vice-versa. The protocol is available for download from our web site http://www.elkproducts.com/m1_manuals_docs.html or see attached.
The M1 Software Developer’s Tool to calculate the Check Sums is also available http://www.elkproducts.com/Owner_support_tools.html
To demonstrate:
1) First, enable G35 - G40 in the M1, either through the keypad programming menus or using ElkRP. This causes the M1 to send ASCII messages for all status changes out its serial port to the XEP.
2) Connect the M1 to an XEP and connect the XEP to a LAN. Using ElkRP, set up the XEP's IP address, etc.
3) Open HyperTerminal and make a Winsock connection to the IP address of the XEP, on the non-secure port (2101).
4) You should see ASCII messages appear in the HyperTerminal window as things happen in the M1 (zones open, arm/disarm, etc.).
5) If you were to QUICKLY type an ASCII command, including CRC, and press enter, it would be sent through the XEP to the M1. Timing here is tricky, because you must type the whole command in-between receiving messages. A program could easily do it, though.
This demonstrates communication via a LAN. Communication via the Internet is similar. In that case, the XEP would be connected to a router which has a cable modem or DSL connection to the Internet. The router must be programmed to forward port 2101 from the Internet side to the XEP side. Then, any PC on the Internet can use HyperTerminal to connect to the router's IP address on port 2101.
HOWEVER: Since port 2101 is "non-secure," we do not recommend forwarding it on the Internet. You could do so temporarily just for testing and set-up, but it is not a permanent solution - it allows ANYONE to connect to your XEP and thus, your M1. Therefore, the XEP has a "secure" port - port 2601 by default. If you connect to this port, the XEP will negotiate a secure SSL/TLS connection with the remote connecting site. The remote site will need to accept the XEP's certificate. Then the XEP will prompt for a username and password (these are set up using ElkRP). If the remote site responds with the correct username and password, the connection is allowed and everything works from there on as described above, except that the data sent over the wire is now automatically encrypted. If you intend to write a program to do this, you will need to already know or learn about the SSL/TLS protocol and how to implement it in your chosen programming language. Helping you learn that is beyond the scope of what Elk Products can do.
OK, that’s good to know. So if I’m reading that correctly, the same command strings are used whether you are connecting via serial or ethernet. That’s helpful, as it means we just need to write one parser (which I’ve got up and running for the most common commands and responses).
I have created a pull request to the Elk github project to enable the generation of the python3 library. At some point when I get an Elk M1 I will use this to integrate with home-assistant.
This is a really cool project and im interested in checking it out as soon as I am able to try it.
It seems to me, to use a RP to interface with the ELK M1, a rs485 shield would be most optimal? something like https://www.sparkfun.com/products/13706
Instead of using rs232.
Then RP would appear like a keypad device to the ELK M1.
It would be faster and would support more than one RP connected to the ELK M1, if I understand the benefits of rs485 over rs232 correctly.
I went in and campaigned for your pull request, it’s since then been merged. There’s a special at my distributor, I can get you an M1G cheap, pm me if you’re interested.
This might be something to look into, but more complicated. You’d have to enroll the pi as a keypad into the Elk and that’s assuming elk even supports custom keypads. I’m not even sure it would be any faster in terms of integration
The Elk’s RS-485 interface, used to communicate to keypads, zone expansion modules and other extension modules is proprietary and not documented. In particular, the messages the zing around on the RS485 bus do not correspond to the messages on the serial interface (and which also appear on the Ethernet interface over a TCP connection).
I looked briefly at this, and the messages use 9 bit bytes which is not uncommon for RS485 buses; bytes with the 9th bit set are used to denote an address, and some UART devices can be configured to match on this and generate an interrupt or other attention signal.
There are also some timing constraints and even if you reverse engineer the routine message traffic, you’d also need to figure out the enrollment protocol and emulate some zone expander or other device.
I think the right way forward is using the API documentation for the serial messages. I wrote some code years ago in Lua to do just this, and it’s pretty straightforward. I’m new to Home Assistant, and the question would be as to how most effectively map the various messages (zone state, temperature measurements and other status updates) in a way that integrates well.
So I’ve actually started to hack on some code now, and my plan is to use MQTT as the interface to the Elk M1 system. I’m already using MQTT for a bunch of different sensor data, so that makes the most sense to me, at least, to get started. Probably some other clever interface within HASS to MQTT for alarms could be done, or minimally doing it “the hard way” by confiuring individual binary sensors on MQTT if necessary.
I have real work in the way, so no prediction on when something useful actually pops out.
