Future Direction of ELK M1 Integration into Modern Applications

I have a question about possible future capabilities of the Elk M1 as far as allowing integration with Third Party Developer applications.     I would like to develop an application which would run on a separate server or “cloud” which would take as input a trigger from the M1.    It appears that the current capabilities of the M1 are to send an email (which is limited to 10 separate emails) or text out a serial port.
 
Assuming the M1 has the M1XEP is it possible to send a different type of external trigger from the M1G system?    An ideal scenario would be a URL open.    So for example if a zone changes state the M1XEP opens a URL http://X.Y.B.C/myapp/resourcePath?queryParameters&key=OpenDoor
 
This would allow limitless possibilities for integrating the M1 into modern web based servers such as IFTTT.com that offer REST Apis
 
Another way to think of it would be, I would like to write a python application that will listen for status changes from the M1.   I do know that I could log into the M1XEP and listen to the serial stream.    This seems to be limited since it would disrupt local uses controlling the M1 from eK M1 iPhone application.    
 
Bottom line, can anyone comment on if/when/how Elk plans on allow integration into modern development platforms?    Imagine having the ability to use IFTTT.com with your Elk system and you can start to appreciate what could be possible.   
 
Thanks

Most here do not want to rely on a cloud service, especially for security related applications.

Yes,   I agree.   I do not want to impact the ELK at all due to security concerns.  
 
Let me be a bit more specific.     I would like to have a Python application running on a server local to the Elk in the same house (it could be in the cloud such as AWS..not really relevant).     I need a way for the elk to send a notification of events over TCP/IP to the python application.    Right now the Elk can kick out an email which is very limiting.    I would like to have it hit a REST API via HTTPS instead.    I am not considering of having the ability of any external app to control the ELK at all.   The communication would be one way from the ELK outbound.   
 
Once the application is built it could run locally or in the "cloud" on Amazon etc.    That is really outside of my question however.    It really boils down to what is the best way to receive notifications from the ELK over TCP/IP???   Logging into the M1EXP is a very insecure way to do it if I don't want to control the ELK but instead just receive a trigger to an external application.     
 
Here is a use case.    Send a message from the ELK outbound when the system enters an ARM state.    The receiving Python app would then be able to perform other things such as possibly play a message out a local Sonos system...   The python application would have no ability to control the state of the ELK system.    Having the ELK kick out a REST URL request would accomplish this goal.
 
The above use case would not impact the security of the ELK system at all.   To your point, I know that there are python libraries for the ELK which can login to the M1EXP and receive status updates.   But I don't want this since this is giving security control of the ELK system to that python application.   Not good from a security point of view.
 
Logging into the M1XEP is also not great since it won't allow for multiple logins.   If I have an app watching the local M1XEP serial stream no one can control it from eKeypad for example.    
 
Being able to kick out a HTTP request from the ELK would be a very desirable and secure way of receiving telemetry from a system such as Elk and would allow the ELK to speak to other apps support REST APIs.   I am not proposing having a REST API on the ELK.  

One other related question.   I know the M1XEP runs Linux.   Does anyone know how I can ssh into the XEP and get root access on it?    If I can do this I should be able to accomplish the above with a simple BASH shell script on the XEP.

You can write an elk client or driver in Python if you choose. There's one out there in Perl already.

FWIW, you might consider acquiring an ISY994 from Universal Devices.  By adding the Network module and the Elk Integration module, you could "listen" for any Elk event (e.g. zone violated) and have the ISY994 react.  You can host web servers on the ISY994 and they in turn could notify your cloud applications of the event that has taken place.  The ISY994 has many other features you might find useful as well. 

cipherwar said:

One other related question.   I know the M1XEP runs Linux.   Does anyone know how I can ssh into the XEP and get root access on it?    If I can do this I should be able to accomplish the above with a simple BASH shell script on the XEP.

Click to expand...

M1XEP runs Linux? Hmm, I'm not so sure of that. As I recall that the device is an XPort type device (the XPort is a 186 running applications that can be compiled in Turbo C).
 
Now having said that, running a Pi or a Beagle Board Black with Linux would work quite well. From there your imagination is the limit. I'll be playing with my Linux box and node.js (Javascript and Elkington). So far I've got my Irrigation controller working and I'm starting on an HA engine based on node.js. Later I'll get to the Elkington stuff (of course someone else wrote it already).
 
Right now there is Misterhouse (Perl) and Pytomation (Python) that might make good starting points for your project.

Thanks for all of the feedback.   I am going to check out the Elkington node.js project as it seems to have potential.   However, all of these interfaces still concern me due to the original point about security.   All of these seem to leverage logging into the M1XEP module.   Once something is logged into the module it has full control over the system which isn't great from a security point of view if all you want is to receive info *from* the ELK system.    I really wish the Elk would have the ability to send out a TCP/IP message (maybe even a SYSLOG message but ideally a HTTP GET) based on a trigger in the ELK system.    Future expansion module maybe???
 
I think the Elk folks lurk here occasionally.   Maybe they are listening.    Seems like this ability could jump start some 3rd party integration with ELK while maintaining the integrity of the system. 

Couldn't you split the serial port and connect it to your favorite embedded linux device for passive monitoring and do whatever you need that way?

The protocol is open; as az1324 implied - just replace the XEP with something more powerful via RS232, or connect over TCP/IP like all the existing control applications that talk to the Elk, like Elve, HomeSeer, ISY, (CQC?), Premise - it's been successful for all them - and they all allow for more advanced control.  You may not have to reinvent the wheel - one of these already developed apps might even do the trick; but if not, you may want to see how they work to begin with.

cipherwar I've been thinking about your thread for a while.

If you really don't want to attach to the M1's serial/TCP/IP port there may be a more tedious and convoluted route.

You could expand your M1's outputs and multiplex them into a microcontroller's ( arduino, beagle, pi ) pins.
( you would have to watch the levels etc )

The microcontroler would review pin state and continue on as you describe.

the M1 rules would probably be hideously baroque. But your microcontroller would not be 'logging into' the M1.

Or, IIRC, doesn't a user code have to be entered even when accessing the M1 or doing anything over the XEP? Sure it can monitor state changes, but at some point all the apps that access it seem to require a user code; so create one that doesn't allow the user to make any changes such as arming or disarming.