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