ELK idea

signal15

Senior Member
I would really love to see an embedded machine running some form of unix (please, NOT windows) in the next iteration of the M1. I know to get UL listing, there are some pretty strict requirements as to how the system can operate. But if it was a daughtercard type of thing where all of the automation rules/tasks/logic was farmed off to it, then you wouldn't have to worry so much about the UL listing stuff because all of the alarm/security logic could still be handled in the purpose-built hardware.

This would enable a few different things:
  • The ability to load high quality, custom voice clips. There are places on the net that will do custom voice work for a fairly nominal charge.
  • Real-time text to speech, no more predefined library of words
  • Automation logic that could be written by the user in Python, Ruby, or Perl
  • SIP Client for joining the ELK to a VoIP system or directly to a provider like Vonage (no more archaic analog lines) :)
  • The ability to pull information from the internet and announce or act on it (announce weather, choose not to turn the sprinklers on if rain is forecasted, close security shutters during a hurricane warning, directly monitor real-time gas and electricity rates and heat the house with the cheaper option in areas where this fluctuates)
  • The ability to pull information from other devices on the local network (Brultech/TED5000, VoIP systems)
  • The ability to send messages to or control other devices on the network that require commands more complex than an ASCII string
  • The ability to provide an XML feed for easy data aggregation for status screens
  • The ability to provide a SOAP or RESTful interface for 3rd parties to integrate with the system extremely easily
  • The existing serial port ASCII control/messaging could still be there, but TCP/UDP listeners could be written that would provide more flexibility (non-ascii data, parsing capability)
  • IPSec VPN client for remote installations that I did not want to expose directly to the internet, which should never be done anyway
  • Certificate based authentication
  • Integration with a radius server for centralized administration of user credentials, or integration with a two-factor authentication system (like RSA SecurID, Entrust, SafeWord, TripleSEC, WikiD, etc)
  • The ability to directly connect and utilize USB based devices (direct integration with RFXCOM!!! With the capability to parse and act on data received!)
  • Possible voice recognition utilizing the two-way listen-in interface. "Computer. lights, living room, 50%". "Computer. Tea. Earl Grey, hot."
  • IP encapsulation/decapsulation for RS485 to increase the range of the bus or extend it to another location across a network or the internet.
  • Elimination of the ethernet expander.
  • Enough processing power and storage to run a sexy AJAXy interface not only for monitoring and control, but also for programming (elimination of ElkRP)
  • Configurable custom dashboards, with the ability to embed streams from IP cameras directly
  • Scheduled backups to a remote server, or encrypted and sent via email
  • ELK App Store??

You can buy an Intel D945GCLF2 Mini-ITX board with a dual core Atom processor on it for about $60 retail. That is more than enough power to do text-to-speech and voice recognition. Flash memory is dirt cheap. It could even be an addon to the existing M1, but you wouldn't have nearly as tight integration. Hardware pricing-wise, it's actually cheaper than the ethernet expander and provides more functionality.

Essentially, this is everything that HomeSeer or CQC give you. But it would be much more tightly integrated with the ELK, so you'd have a single voice announcement system, a single place for automation rules, VoIP integration directly with the ELK, etc. Plus, one of those Atom boards would fit right in a security panel cabinet instead of having to find a spot for a desktop or server. Get the basics in place, and unleash the customers on it to do the really cool things with it.
 
What is the benefit of bundling this with a security/automation platform like the M1? Are their ASCII interface improvements you would like to facilitate communication with another platform(PC, ARM, microcontroller, etc). It would add complexity to a system that is primarily security and basic automation, inflate the cost and limit your options for partnerships and expandability. Why not let the M1 do what it does best, and then pair it with whatever other system you require?
 
Now that I think about it, you're right, it could still do all of these things if it was a generic system that wasn't integrated. But it would be a huge selling point for ELK. And being able to do all of your programming through a web interface to the unit instead of running separate software would be awesome. Having something that was purpose built to integrate is a lot better than something that feels duct-taped together.

Right now, I'm trying to decide if I have enough time to order up a $60 Mini-ITX setup and start doing stuff with it.
 
I would not necessarily want to vote for a programmable daughter card. I deal with my fair share of computer problems during the day time, and I really don’t want to play around with it at home.

In addition, there are a very small select group of enthusiasts that probably would opt for doing this. If the HA technology doesn’t get to a Ron Popeil set it and forget it level, then it will remain a niche technology. Explaining the value proposition to my friends and parents elicits a, “that’s neat!†But if you start explaining how all the HA/Security stuff works, their eyes start to glaze over. When I explain how much time (and money) I spent getting the whole thing working, the gee-wiz excitement starts to fade quickly.

It would be nice if Elk would Open Source some of the XSP lighting module’s source code – similar to how OpenSource routers (DD-WRT) facilitate modifications and custom modules. It may also be nice if Elk created programmable replacement using a high level scripting language for Magic Module with an API that allows bi-directional access to ElkRP through the RS-485 bus. In some of the hobby board forums, there were some nice descriptions of how weather and daily schedules (information appliances) were integrated into Elk. At this time Elk seems to be the only manufacturer of RS-485 bus modules.

In my opinion, Elk needs to create a more formal vendor/alliance ecosystem – similar to Z-wave. The web site http://www.elkproducts.com/products/m1/m1partners.htm does have a decent listing of all partners, but it does not provide potential owners any use cases, level of capability (protocol conformance), cost, or ways that each partner can make your life less of hassle.

If you want to integrate RFID/proximity detection into your system, you have to buy Elk XSP, a RF-ID receiver, and program the whole thing. Why can’t I buy a package from single vendor, plug it in, and have it start opening/closing garage door out-of-the box.

I personally feel like this HA technology is stuck back in the DOS era where if you understood how to guess which IRQ would make a device work right the first time, you were considered some sort of wizard.
 
Back
Top