Why is the Elk M1 so popular?

[Dean Roddey]

Yup, no single solution. Sorry Dean! Just ones that use quality integration with agreed upon connections.Not unlike what integrators have been doing for years.
Just now with software AND hardware.

Hardware is always involved in automation, so clearly one must have some sort of hardware/software combination. But that is just a necessity that cannot be avoided, and even then one would attempt to use as few separate pieces as possible. I doubt anyone would argue that, instead of an Elk, you should buy a bunch of different boards and try to tie them all together.

On each side of that necessary hardware/software divide, one would generally seek to reduce the number of separate components. This is a pretty proven means of increasing system reliability, and very importantly, in reducing the 'political' issues of figuring out who is wrong when something goes wrong.

 

[TonyNo]

BSR's last post reminded me of a product I was going to mention.

I just discussed the box with the manufacturer. There are Windows XP Embedded and CE flavors. Not HA-specific, but industrial, and has a lot of potential. I am told that there are versions with a great price point.

I just edited out names, links, and price points to not upset anyone. Maybe this post is useless now?

 

[upstatemike]

If Dean wanted he could get a nice looking box like HomeLogic or MControl uses, Change his software to work on XP Embedded and then it would look more like a Hardware Automation Controller then a Software based Controller on a computer. This is the same thing Homeseer is doing with the Pro-100.

I have to say I agree with Dean's philosophy on system design and I feel he has put a lot of thought into his product and HA in general. I also have to say that I agree that a PC should be the ideal platform for a Home Automation system but I am still struggling to find a platform that does what I have now and what I will want to do going forward. I think the reason I am not on CQC or PowerHome or Homeseer or ECS or MainLobby as my primary automation platform today is because none of them do what I need. I suspect no HA program will ever be written to exactly replace a hardware controller because it would have to have the following characteristics that are philosophically unacceptable to software developers:

1- The system would need to be a Home Automation program. NOT a web server, NOT a media server, NOT a structured progrmming environment for script writers, but a true software representation of a Programmable Logic Controller with a home automation focus. It would need to manage communications between devices and the complex logic used to control them and that is all.

2- The system would need to support a large number of devices and support them DIRECTLY. The problem with connecting a bunch of different subsystems together is that the limitations of each subsystem becomes a limitation of the overall autmation setup. If, for example, you depend on an ELK panel to provide your interface to RCS thermostats, you will only be able to access those thermostat features that are supported by the ELK firmware. If ELK decides they don't want to report manual changes to thermostat setpoints in their firmware then that information is forever unavailable to the PC controller.
A true PC based automation system must support the direct attachment of most devices to PC ports without depending on the business priorities of any other company. This means those RCS thermostats go on a USB to RS-485 converter and feed DIRECTLY into the PC. Likewise with relay boards, lighting interfaces, etc.

3- The system would need a robust GUI for configuring attached devices and generating most rules/events/code. The GUI must directly manage the configuration of devices so you don't have to quit the HA system to run a separate configuration program every time you need to "enroll" a device or otherwise change it. No ElkRP, C-MAX, WinEVM, etc. Scripting will aways be needed for special situations but the bulk of coding should be menu driven to simplify frequent changes and rapid implementation of new ideas. SCRIPTING SHOULD BE THE EXCEPTON, NOT THE RULE! There should be a near zero learning curve for hardware setup and basic code generation!

4- The variety of hardware supported should be large and should cover all major HA areas. Most PC HA controllers don't bother to support a phone interface but if inexpensive Digium cards are available for PC phone system like Asterisk, why can't they be supported for phone functions in an HA server? Why aren't there more RS-485 devices connected directly to the serial ports of HA servers? Things like RCS LED keypads or some kind of relay board or I/O board. (No, I am not talking about a Global Cache type interface where you pay hundreds of dollars for a couple of relays or inputs. I'm talking something priced like the ELK 16 port expansion modules only directly attached through an RS-485 adapter on a PC serial port.) Support for things like weather stations or Slimservers or serial connected DVD players should all be attached to the PC ports and directly supported by the HA system GUI.

Until PC based controllers start to emulate more of the features of hardware Programmable Logic Controllers, they are never going to be able to replace hardware based HA systems. This is why I have not been able to convert to a PC based system yet. I wonder if it will ever be possible.

 

[Dean Roddey]

1- The system would need to be a Home Automation program. NOT a web server, NOT a media server, NOT a structured progrmming environment for script writers, but a true software representation of a Programmable Logic Controller with a home automation focus. It would need to manage communications between devices and the complex logic used to control them and that is all.

I guess one answer to that is that any product that doesn't do those things would be doomed, because it couldn't compete.

2- The system would need to support a large number of devices and support them DIRECTLY. The problem with connecting a bunch of different subsystems together is that the limitations of each subsystem becomes a limitation of the overall autmation setup.

Support for a large number of devices is a massive task. It can really only be done if the vendors of the devices provide the support themselves. This is one of the biggest advantages that companies like Microsoft and Crestron have, which gives them almost monopoloy power. The vendors of equipment support for those monopoly systems themselves, when the vendors of other automation systems must provide the support on their own. So it's really a rigged game in some ways on that front.

However, we do try to support as much as we can. We are coming up on 100 devices/applications, all directly controlled.

Things like RCS LED keypads or some kind of relay board or I/O board. (No, I am not talking about a Global Cache type interface where you pay hundreds of dollars for a couple of relays or inputs.

We now support an 8/16 digital input/contact closure PCI board. But they aren't terribly cheap, because they are mostly designed for the industrial automation world, where price is less of an issue.

 

[ronaldbeal]

I am new to Home automation, however I am a professional concert lighting technician.
My career involves installing, maintaining, programming and operating the large automated lighting (and sometimes video) rigs you see at rock concerts, theaters,and live television "events".

What I see missing from the HA landscape is any sort of unified networking protocol and device model. In the current environment, it seems almost every mfg has their own set of protocols and hardware. The few somewhat open protocols are still tied to NDA's, and other corperate contracts. About the only "standard" networking seems to be serial ports, and even then, every device has it's own language. No wonder there isn't much growth in embeded hardware controllers. The effort just to make one talk to all the different mfg's can be overwhelming. It seems the reason PC's see lots of use as HA controllers is they DO have a standard set of hardware and limited OS's to tailor software and other bits to.

What I think is needed is a standard HA networking protocal and device model. Let me explain: (and these are just examples off the top of my head, so don't get to wrapped up in small details!)

First: an open backbone networking protocol. This can't be tied down by lots of contracts and NDA's Those seem to often kill 3rd party involvement. Concert lighting has gone through those growing pains several times in the last 20 years. Every time technology advances to the point where new tech outgrows old networks, the sucessor has always been the one most "open" even when there were "technically" better systems.

I suspect at the present time an Ethernet based protocol with 802.11xx support would be best placed to take advantage of exsisting commodity networking hardware (and even embedded web servers.)
The protocol would (at the least) need to support some standard method of discovery, device assignment and routing table information, basic device I/O, media controls and transport, GUI transport, and mfg exclusive messages (for updating firmware and the like.)

Nodes on the network could be protocol bridges (such as X-10, Z-wave, Insteon, etc,) device interfaces (such as to an M1, or Stargate), or usable devices (such as a network enabled audio server, etc...) Protocol bridges would need to keep some sort of "patch" table. since their native (x-10, Z-wave) devices wouldn't be network aware.

If you have read this far, you may be wondering WTF this has to do with the discussion at hand.
First, it would allow "best of breed" products from different mfg's to be tied together, with much more positive results, and less effort. Each mfg. no longer has to make their devices talk with EVERY other device they want it to talk to. As long as they make it conform to the standard device model, it can talk to evrey other device on the network by default.

Second, it would allow a much broader spectrum to pick and choose from in developing whole systems. Nodes can be small very specific task products, or full fledged home theater PC's, Do you want your "events" controlled by PC software or an embedded PLC? either one won't change the rest of your hardware and network configuration. It will allow HA tasks to be performed by a large aggregate of small task specific embedded processors, or monolithic control systems (embeded or PC)

Here is my example:
We'll call the protocol "Super Powerful Automation Network Kontrol" (SPANK)
We get a house with a bunch of Insteon switches. Add a SPANK to insteon bridge. The bridge is "aware" of the Insteon devices attached to it, and assigns each Insteon device a SPANK device number(We'll use 1-12 in this example). Next we get a SPANK enabled ELK security panel. Instead of having to do the tedious insteon setup, just tell the ELK to talk to SPANK devices 1-12.
If you decide to later change to z-wave, just assign your new z-wave switches to the same SPANK addresses, no need to even touch the ELK, all programming should still work (assuming similar function switches.)

Next lets add a Russound audio server that is SPANK enabled. Want to have it play a song when you turn the living room lights on? Just have it start playing when it sees SPANK device 1 send an "on" command. At this point we haven't even needed any "if/then/else" logic. Need a new voice annunciator? get one from a different mfg, and it will still work with the ELK, (or Stargate for that matter.)

Want a GUI? just add a SPANK enabled GUI server... outputs graphics, and I/O's SPANK commands. OR use a PC as your audio server, PLC, and GUI server. Just as possible and easy to set up as the discreet components (as long as your firewall is set properly ;-)

Will I ever see this system in my lifetime? Not looking promising for the next few years. Mfg's have to undo their recto-cranial inversions. Develop an open home networking protocol, build devices that support it, and let others use it as well. Everyone wins.

Sorry for the long rant, just my frustration as a beginner in the HA field.
RB

 

[Dean Roddey]

Though I'm certainly all for a good common protocol that would be more widely used, I don't see it as quite as big a problem as it might seem. Products like ours exist to integrate various devices under the control of a single system, which then provides a standardized interface to each device. It would be helpful to have fewer protocols to deal with, but the real problem is seldom the protocol used.

Instead it's the fact that the device was not well designed to be automated, and the actual needs of an automation system were not considered at all. This causes the bulk of the grief and the bulk of the inability to provide a slick and robust integration of all these devices. If more devices were well designed in terms of external control, that would do us more good than having all the existing badly designed interfaces using a single protocol.

Unless every device that you want to be interoperable reacts the same way, then just trying to hide them behind a simple abstraction won't really help. If one device powers on immediately, and another refuses to talk for 10 seconds after power on, you cannot hide those types of differences without significant compromises. If this one accepts WAV and WMV and that only only accepts MPG3, then you cannot easily replace one with another. So this type of all dancing system requires a lot more than just a single protocol.

 

[Mark S.]

SPANK me!

 

[Digger]

Should we recruit "Spanky" for this?

 

[upstatemike]

Here is my example:
We'll call the protocol "Super Powerful Automation Network Kontrol" (SPANK)

Not as sexy but what if we call it xAP/xPL?

 

[Dean Roddey]

xAP/xPL is a particular type of protocol, which wouldn't be appropriate for a general purpose backbone. It's an event notification protocol really. It wouldn't be appropriate for any sort of high throughput requirements.

 

[ronaldbeal]

I agree that lack of a common protocol is not a big problem, however I think it can be a good solution.

>>" If more devices were well designed in terms of external control, that would do us more good than having all the existing badly designed interfaces using a single protocol."

What would be better "external control"? serial ports, analog I/O, a keypad? The problem still lies with so many different "external controls" that practically every form of inter-device communication has to be built from scratch. Thats a lot of R&d and coding time spent re-inventing the wheel everytime there is a new product or manufacturer.

I agree up to a point, however, I think having a unified protocol to build towards will force mfg's to improve their interface, at least to a minimum level.

>>"Unless every device that you want to be interoperable reacts the same way, then just trying to hide them behind a simple abstraction won't really help."

Sure, it's not perfect. There would be some speedbumps, but a lot of these could be overcome with a little bit of planning, and it's still fewer speedbumps and more flexibility than the present model.

>>" If this one accepts WAV and WMV and that only only accepts MPG3, then you cannot easily replace one with another. So this type of all dancing system requires a lot more than just a single protocol."

Yes and no... No one is going to replace a light switch with a DVD player.
Just as I'm not going to try to replace my HVAC thermostat with a sprinkler control, or an x-10 motion sensor, I'm not going to replace a WMA player with a MPEG player and expect sane results. But I COULD replace my brand "X" WMA player with a Brand"Y" or Brand "Z" WMA player and get a lot more consistent results. Sure brand "Y" may have a 10 second delay and Brand "Z" may have a different audio curve, but if the brand "Z" mfg can make a WMA player that can interface with Elk, Stargate, Ocelot, Homeseer, CQC, Mainlobby...etc..., all out of the box, instead of having to develop a new interface for each HA control system, everyone wins.
Professional installers get a larger base of equipment to draw from, with less of a learning curve, DIYers get more choice, and thus better competition, and the mfg's don't have to devote so much time reinventing the wheel again. (unless they plan to compete with Goodyear and Bridgestone ;-)

Respectfully,
RB

 

[upstatemike]

...I'm not going to try to replace my HVAC thermostat with a sprinkler control...

I guess I'm always the odd man out... I recently replaced all my thermostats with sprinkler controls.

 

[Dean Roddey]

What would be better "external control"? serial ports, analog I/O, a keypad? The problem still lies with so many different "external controls" that practically every form of inter-device communication has to be built from scratch. Thats a lot of R&d and coding time spent re-inventing the wheel everytime there is a new product or manufacturer.

I meant that, no matter hwat protocol they use, they should work worth a damn when controlled from outside, which is just all too often not the case, and that wouldn't necessarily change just because they used a common protocol. It's a bit of a pain to write a new driver for each device, but that's nowhere near as bad as writing a driver for a new device that seems to be designed to frustrate anyone who is trying to control it. And you'd be amazed how common that is. That's got nothing to do with whether it's serial or uses ASCII or binary or whatever. It's things like, won't respond to anything but power on when it's in standby mode. Or goes off into the ozone for like 20 seconds after power on. Or is documented in a way that boggles the mind that somone could write something so incoherent. Or has 200 data points and a baud rate of 2400. That kind of stuff.

If I had to pick between everyone using the same protocol and keeping their current design, and everyone using a different protocol but have a design that actually works well with the automation system, then I'd pick the latter in a heartbeat.


Anyway, if you looked around out there now, and asked what technology probably is the closest to providing a standard backbone for automation systems, much as I hate to say it, it's probably Firewire. It's fast, it's a network, it was designed to be much more user friendly than ethernet, and it reserves most of it's bandwidth for isochronous traffic but also has bandwidth for asynchronous traffic, which would serve both needs of automation systems that need ot include media management.

If you took that, and built on top of that a set of definitions for the values and functions that various classes of devices can expose, and a protocol to deal with them, which is not unlike what Zigbee/Z-Wave do, you could have something fairly interesting I think.

But, the chances of getting everyone to adopt such a thing, even if it was an open standard, is probably slim to none. There's enormous NIH type attitudes out there in the CE world, not to mention just old fashioned inertia. If you had a W3C type of organization that would define such a system, it might have some chance if you got the important players to sign on, assuming it didn't just become a huge bloated beauracratic mess that never went anywhere.

 

[huggy59]

And another issue is the way the industry looks at products in these market areas - they are tied to copyrights and patents that prohibit open use. It's like the record and film industries (but let's not go there).

Ronald, why don't we develop a DMX-based home control system? The network and protocol are already here and used professionally in places that are way more than most homes will EVER need... and it just needs extensions for the various types of devices used in the home.

And there's just a much common sense lacking in device design and integration as there is in software these days...

;-)

 

[FrankMc]

Hi Ron

Have a look at xPL ......

http://wiki.xplproject.org.uk/index.php/Main_Page

HTH
Frank