Frustrated with home automation software

[Dean Roddey]

You will find it a tough row to hoe if you don't allow for third party drivers. No company can really provide all of the drivers required for success, not even the most well financed ones. We've learned the hard way that you can do a thousand things well, but if you don't support some specific piece of gear, many to most customers will not commit. No matter how much you support it's never enough.
 
As far as shipped support, CQC ships with support for a couple hundred devices, which AFAIK is considerably more than CastleOS does. Some of those are third party, but they are shipped with the product and are as tightly integrated as any we provide ourselves. Since we have a very well defined driver architecture, a third party one is not really any different from one we write, other than that we can do C++ drivers where that's necessary and they cannot. But both types still work within the same standardized framework and work exactly the same, which is sort of part of my point above. We write very few C++ drivers, because it's just not justified in any way to do so except in very specific circumstances, such as the vendor won't allow an open source driver (e.g. Z-Wave.) CML works just as well and it's shipped as code so none of the issues with abandoned drivers comes up.
 
In CQC, very little 'scripting' is really ever done, in the coding sense. We support a very high level, point and click scheme that almost all user customization is done with. Only drivers, or web server plugins and the like, are usually ever written in CML. That is ultimately the fastest of all since there's no need to load up an external DLL into the process space. It's 'script' in that it's used for things that are often referred to as scripting but it's a very simple and compact scheme. So there's not a speed concern really. As has been discussed previously in this thread, it's very fast to react. If you want to write CML code for customization you can, and some folks do. But it's a very specialized language for the job, and it's designed to compile very quickly, unlike a general purpose language. Safety and speed of loading were key design goals for CML.
 
For a driver compile time is irrelevant, since drivers run forever, so even if it took five times longer than it does to load a CML driver it wouldn't make any difference. And speed of execution isn't much of an issue for drivers either, since they typically spend almost all of their time waiting for the device they control. CML certainly doesn't have any issue keeping up with devices. It's in the product infrastructure itself that efficiency is key.

 

[picta]

I have been HS2 user for a long time, and still using it as my software controller. The best thing about HS2 was/is that it supported custom scripting (VB, not the sexiest language, but it worked). The problems that HS server experienced were related to 3d party plug-ins, not custom scripting. The scripting API was relatively extensive, I could create devices and events from the script and receive callbacks. It is hard to imagine any HA software that would have native drivers for all possible devices, so some combination of the native ones and the 3d party plugins that could run in a "safe thread" would be ideal. But even then, the availability of custom scripting would define my decision on the software. Because then I can write my own drivers for whatever device I happen to have without depending on the others to do it. I have dozens of such drivers I use with HS2 and there is no way I'll move to HS3 or any other software unless I can replicate them.
 
@CrissChcc: I have checked your website, but could not find any documentation on your scripting API, would be interested to see the functionality.

 

[Dean Roddey]

The 'safe thread' thing is why we went with our own language. CML itself is the 'safe thread'. Drivers and plugins written in CML can't destabilize the rest of the system. We'll there are a couple things that any system can be whacked by, and CML can't stop those, like a driver going into an infinite loop or eating up memory very rapidly. Even if you moved every driver out to a separate process (expensive in terms or resources), it's still going to eat up CPU or memory if that happens and can make the system slow.
 
But in terms of actually destabilizing the system in the sense that's usually meant, i.e. not obvious stuff like the above but subtle errors caused by changing the system or some product process state in some undesirable way, CML drivers can't do that because they don't have the means to. They cannot get to the OS directly and they are limited as to where they can read/write files as well.
 
That also makes them nicer in terms of security as well. You don't have to worry that a CML driver is going to hack your system, and of course you can see the code as well. But even if you can't read the code you know it can't compromise your network/OS security because it's not in a position to do so because it doesn't have the means.
 
It could compromise your controlled hardware, if it was malicious. Device drivers are specifically there to access hardware, and if they chose to do something bad to the hardware they support, the automation system couldn't know that was happening since it couldn't define what constitutes good and bad access to that hardware. The automation system depends on the drivers to understand the hardware in the first place, so it's in no position to pass judgment on what the driver does to the hardware it controls.

 

[ChrisCicc]

You will find it a tough row to hoe if you don't allow for third party drivers. No company can really provide all of the drivers required for success, not even the most well financed ones. We've learned the hard way that you can do a thousand things well, but if you don't support some specific piece of gear, many to most customers will not commit. No matter how much you support it's never enough.
 
As far as shipped support, CQC ships with support for a couple hundred devices, which AFAIK is considerably more than CastleOS does. Some of those are third party, but they are shipped with the product and are as tightly integrated as any we provide ourselves. Since we have a very well defined driver architecture, a third party one is not really any different from one we write, other than that we can do C++ drivers where that's necessary and they cannot. But both types still work within the same standardized framework and work exactly the same, which is sort of part of my point above. We write very few C++ drivers, because it's just not justified in any way to do so except in very specific circumstances, such as the vendor won't allow an open source driver (e.g. Z-Wave.) CML works just as well and it's shipped as code so none of the issues with abandoned drivers comes up.
 
In CQC, very little 'scripting' is really ever done, in the coding sense. We support a very high level, point and click scheme that almost all user customization is done with. Only drivers, or web server plugins and the like, are usually ever written in CML. That is ultimately the fastest of all since there's no need to load up an external DLL into the process space. It's 'script' in that it's used for things that are often referred to as scripting but it's a very simple and compact scheme. So there's not a speed concern really. As has been discussed previously in this thread, it's very fast to react. If you want to write CML code for customization you can, and some folks do. But it's a very specialized language for the job, and it's designed to compile very quickly, unlike a general purpose language. Safety and speed of loading were key design goals for CML.
 
For a driver compile time is irrelevant, since drivers run forever, so even if it took five times longer than it does to load a CML driver it wouldn't make any difference. And speed of execution isn't much of an issue for drivers either, since they typically spend almost all of their time waiting for the device they control. CML certainly doesn't have any issue keeping up with devices. It's in the product infrastructure itself that efficiency is key.

 
Like I said we do allow 3rd parties to write their own virtual devices, though our goal is to integrate any "major" protocol internally. So if you have a one off device that needs to be supported (for instance a medical bed you want to voice controlled), you can easily do so. Major protocols will be internally supported. I'd have to count up the total devices we support, but it's more than a couple hundred (and I was comparing against CQC native only - you certainly support a lot more with your 3rd party drivers included). We currently support X10, INSTEON (save a handful coming soon), Z-Wave (save a handful coming soon), UPB, WeMo, LightwaveRF, Nest, Ecobee, Hue, Sonos, Plex, XMBC, MediaBrowser, DirecTV, and more coming soon. All devices in CastleOS can talk to each other, so an INSTEON motion sensor can trigger a Z-Wave light switch, etc. We don't use the same concept around drivers that you and HomeSeer do - we want our customers to take home a device and plug it in, and not have to think about making sure the driver is installed. Our support for 3rd party devices is for the user who's missing that one device to make their system complete, or wants to add more complex automation scripting, not for providing basic functionality. 
 
Regarding the native scripting, it depends on what you use the script for. I'm not referring to the time it takes to load the driver/script, but rather the time it takes to run it. Even with your driver example, something as simple as serial port communications is much faster with our method than with any other, including CQC and HS. You won't notice if you're sending a few bits here and there, but there speed difference is there. If you try to do something complex, for instance facial recognition, it runs natively on the system and is fully hardware accelerated, which others cannot do. But like with CQC, most users will never need to touch it, and instead use our GUI to build events and conditions. Also, the beauty of C# is it combines the power and (most of) the speed of C++, but is as simple to use/write as Java. 

 

[ChrisCicc]

@CrissChcc: I have checked your website, but could not find any documentation on your scripting API, would be interested to see the functionality.

 
Are you Italian or speak Italian? You're the first person I've ever seen know how the first four letters of my last name are pronounced when in the "cicc" form rather than the full name (for others: "cicc" is pronounced "chick" which picta typed as "chcc")
 
The full announcement is coming in early January, we're starting to put up the product pages for it now. There is a forum about it here: http://www.castleos.com/forum/forum6-scripting.aspx, though that forum is only about Scripting in our Kinect Service for voice control.

 

[pete_c]

This is a great discussion. 
 
Here mostly still using Homeseer 2 with two boxes today.  One box (heavy) has some 20 plus serial / usb interfaced pieces of hardware and the other box (light) has about 10 today.  Totals here relating to this and that are:
 
~ Devices ~700
~ Events (triggers) ~300 (thinking more than this).
 
I do not utilize the network for transport to any of these devices and both boxes are identical (VMs work fine) with one USB cable going to one Digi USB Hub to multiple devices (included 16 serial ports via Digi Edgeports).
 
Touchscreens are mostly all connected via POE / Gb (so using network transport for the consoles).
 
I have been able to connect around 25 Homeseer Touchscreens to my HS2 setup.  Really bugging wife though with 5 touchscreens in the master bedroom (well including Omnitouch screen).
 
Never utilized VR although had purchased equipment.  I have turned down much of the text to speech in the last few years. 
 
Actually to bug (maybe teach) my wife did configure one touchscreen to talk Homeseer only in Italian and Portuguese and French.  (been collecting voice fonts now for about 10 years).
 
I have tested running Microsoft SAPI in Wine and it runs well on Ubuntu LTS today (on another machine).
 
Purchased the Homeseer Zee because Homeseer ran on Linux.  Today running Homeseer 3 Pro on Ubuntu 14.04 (14.10).  Going very slow with it....baby steps only testing one or two plugins at a time (or scripts).

 

[Dean Roddey]

There's nothing about C++ or C# or CML that makes a difference with serial data read/write. The serial port is very slow and anything could keep up with without a problem. And you have to remember that not a lot actually executes as CML opcodes. The bulk of what a CML driver or macro does is to make calls to the CML runtime library, which is a very thin layer over the underlying C++ code. So there's not much overhead to CML code the majority of what a driver or event handler or web server plugin does. It spends the bulk of it's time in C++ code actually, though it doesn't know that directly. Since it's our own language, it was designed to very cleanly layer over our C++ object infrastructure. You wouldn't want to try to implement RSA in CML, but you wouldn't do it in C# either. But drivers pretty much exclusively are interested in sending and receiving data and responding to incoming calls from clients to cause outgoing commands to the device. 90% of the time most drivers are just blocked on I/O and doing nothing, just waiting for the device or waiting for an incoming command from a client.
 

 I'd have to count up the total devices we support, but it's more than a couple hundred (and I was comparing against CQC native only - you certainly support a lot more with your 3rd party drivers included). We currently support X10, INSTEON (save a handful coming soon), Z-Wave (save a handful coming soon), UPB, WeMo, LightwaveRF, Nest, Ecobee, Hue, Sonos, Plex, XMBC, MediaBrowser, DirecTV, and more coming soon

 
Maybe we are talking about different things, but judging from previous discussions I am surprised that you claim that many devices supported. The list above would be 15 devices. What are the other 185? I'm not counting each individual Z-Wave or Insteon, or X-10 module as a device. Z-Wave is one device supported, Insteon is one, etc... We support a couple hundred of devices at that level, in terms of actual shipped drivers, leaving aside others on that forum.
 
Removing any dups from our driver manifest list (where it's the same driver just for serial vs. IP or old V1 vs. newer V2 driver types), in terms of shipped drivers I get this list, and none of these are IR controlled, these are all serial or socket or database or whatever type drivers. This is 252 drivers. I may have missed a dup here or there, but basically it's this many:
 
ADASuiteX
adsSC4
AdvantageAir
Alcohol
Aprilaire8870_V2
AquaMeta
ArcSoftMCE
Arduino
AstrologyDotCom
AudioAuthority11x6
AutonomicMCE
AutoPatch
AV9Proc
BarcoCRT
BarixAudPl
BarixBarionet
BetaBrite
BnKCT.manifest
Boxee
Boxee_V2
Brultech_ECM12xx
Brultech_GEM
CallerID
Casablanca3
Centralite_LiteJet
CheaperRFID
Cinema11
CK1610_V2
CQCHostMon
CQCIntfViewer
CQCSimDrv
CQCSpeech
CQCTimers
CQSLAudPl_V2
CQSLLogicS
CQSLRepo_V2
CQSLSpeech
CS-2
DataLogDB
DataNab
Denon1912
Denon2807
Denon2808CI
Denon3800
Denon3803
Denon3805
Denon3806
Denon3808CI
Denon4311CI
Denon4806CI
DenonUniversalBR
DenonUniversalDVD
DenonX4000
DigitalLeeza
DirecTVSTB
DirecTVSTB2-0
DirecTV_IP
Dreadnaught
DSC-IT100_V2
DunePlayer_V2
DVDO-iScanVP30
DVDO-iScanVPnn
DVDProfiler_V2
DVILinkDS-41R
Dwin700
ElkM1IP_V2
ElkM1Serial_V2
Epson TW500
EpsonVP21
EscientFireball
EventGhost
Extron 200
Extron Crosspoint
ExtronS8P
ExtronVSW
FileTagRepo_V2
Foobar_V2
GC-100
GC-IRE
GC-IRL
GEInterlogixNetworxNX8E
GenericAppCtrl
GenericLTCPOut
GenericSerialOut
GenericTCPIPOut
GenHTTPTrig
GenLTrig
GenTrig-IP
Girder
HAIOmniProII
HAIOmniTCP_V2
HDLeeza
HitachiPlasma
HTIQ
InfocusIN76
Inline3808
InsteonPLM
IntegraDVD
IntegraRCVR_TCP
Ira-2
IRMan
iScanHD
ISYInsteon_V2
iTunesPlayerTM
iTunesRepoTM_V2
JandyAquaLinkRS
JRiverDiskRepo_V2
JVC RS1
JVC-DLA-HD2K
JVC-RSn
KDFlashSW4x1
Kramer2053
KramerProtocol2k
KramerVP88ETH
KrellDVDStandard
KrellHTS71
KrellKCT
LexiconAVProc
LexMC1
LGTV-IP
LGTV_50PB2DR
LGTV_Universal
LogitechSqueezeCenter_V2
Lumagen Vision Pro
LumagenRadiance
LutronGrafikEye
LutronHWIP
LutronRadioRA
LutronRadioRA2_IP_V2
MarantzAV8801_V2
MarantzSR5005
MarantzSR5008
MarantzSR7005
MarantzVP12S2
MaxentPlasma
MCEAppCtrl
MediaChMgr
Meridian 861-V4
MitsubishiXD400U
MonoPrice5704_V2
MonoPriceMZ6
MyHD
MyMoviesRepo_V2
MyroAir
NADT762
NanotechStepper
NeothingsAvalon
NeothingsUniversal
NetCallerID
NetGearNeoTV
Network_Monitor
NexusAudio-Ci
Nuvo Concerto
Nuvo Essentia
Nuvo Simplese
Nuvo T2Tuner
NuvoGrandConcertoIP
NuvoGrandConcertoSerial
NWSXMLFeed
OctavaHDMI_V2
OnQALCLightingIP
OppoDV983H
Optoma H79
Outlaw990
PanasonicAE900
PanasonicPlasma
Parasound7100
ParasoundHalo30
PCIIRO
PentairIntelliTouch
PhilipsHue_V2
PioneerVSX-84TSXi
PioneerVSX-xxTSX
PixelMagicCrystalioII
PolkXrt12
PolycomVSX
POP3Email
PowerLincSDM
PreconHS2000D
ProliphixNTXe
QuadScan
R2DI
RadiientSelect4
Rain8net
RCSSerialRS485
RCSThermoXBee
RedRat2
ReminderDB
RokuPlayer
RotelRSP1069
RotelRSP976
RotelRSX1057
RTIRP6
RuncoVX-1000
Run_Timer
RussoundRNet
SageTCP
SageTV
SensaTronics
SharpLCD85U
SharpZ9000
SherwoodP-965
SlimServer
SMS
SNMP
SomfyUniversalRTS
SonosZP
SonosZP_V2
SonyCX777ES
SonyQualia004
SonyVPLVW100
Suite-IP
SunfireTGPX
Syslog
TandbergMXP
TekmarGateway
TheaterTekIP_V2
TIVO
TopfieldPVRt
TotalMediaTheater-SA
TVOneTask_MX-3141
UPB
USB-UIRT
VantageQSeries
VarDriver
VidikronVision70-IP
VidikronVL4046-IP
VisualApexVAPEX9106TN
VLCMediaPlayer
VPL-VW10HT
WeatherCh
Winamp
WinDVD4
WinMediaPlayer9
Wunderground
XantechMRC88
XantechXDT
XantechZPR68-10
XMChannelInfo
YamahaAventage_A1000
YamahaRX-A3000_V2
YamahaRX-V1500
YamahaRX-V1900_V2
YamahaRX-Vx600
YamahaRX-Vx700
ZektorHDS42
ZoomPlayer
ZoomPlayer_V2
Zreo_ZeeBoxD250
ZWaveLevi_V2
ZWaveUSB

 

[ChrisCicc]

Interpreted (CML, VB Script) is always slower than Compiled Runtime (C#, VB.NET) is always slower than Compiled Native (C, C++). That's just a fact of programming, though how much faster/slower varies greatly depending on what you are doing. 

And yes, we are definitely counting differently Z-Wave is a protocol, not a device. I count the device types within Z-Wave, namely because to support a device type requires internal support for the particular properties of the device, and more importantly, a GUI that allows the person to interact with it. 

With your list, you also count versions of the same device (i.e. Denon receivers) as individual devices where I do not. Furthermore, if you take away your A/V components, how many pure automation devices are left? I don't see current stalwarts like Nest, Ecobee, WeMo, LightwaveRF, but you do have a couple big protocols we still have in development like C-BUS and RadioRa2. 

Actually, I think you are overselling your support and underselling it at the same time if you get what I mean  

Are all of those native? Which are native or 3rd party? For the 3rd party ones, do you (CQS) support them as their protocols evolve over time, or is it left up to the developer? 

 

[Dean Roddey]

Every Denon model has different options. Unless you have them all available all of the time to retest any time you make changes, it's more reliable to just have separate drivers. The Integra receiver driver, OTOH, does support about 40 models in one or something crazy like that. I wouldn't have gone that way, but that's the way it was done, so it's only in the list once above, not 40 times. Nest is supported but currently on the forum, not shipped since they only recently made the protocol openly available. We try not to ship any drivers for devices that aren't formally supported, for legal reasons.
 
Home theaters are a big opportunity for automation systems, a way to start small and build up from there, so supporting all of those media devices is sort of important, though keeping up with the ridiculous number of modules that receiver manufacturers seem to throw out constantly is a losing game sometimes.
 
On the Z-Wave thing, you don't ultimately need specific support for each module type. In our new V2 Z-Wave driver we use configuration files for each module type. The driver is generic and doesn't know anything about modules, it just uses the configuration files to tell it what capabilities a given module has, what configuration parameters, associations it needs and so forth. Our previous driver wasn't of that sort and there was no way to keep up. This way, assuming you can tease out the detailed information for a given module (something that's sometimes very difficult), you can just create the appropriate config file without any modifications to the driver.
 
Though, if we counted individual Z-Wave, Insteon, ISY, and other types of modules, by that criteria our count would be more in the 500 or 600 range or some such thing. But personally I don't think that's the best way to measure device support. We consider a 'device' to be something that required a driver connected to something. There's only one driver talking to one VRCOP for Z-Wave so that's a device by our standard, now matter how many specific Z-Wave modules it supports. And the same for all the other 'composite device' types out there, Elk, Omni, ISY, UPB, etc... Each is considered a single device supported.

 

[ChrisCicc]

We joined the Nest developer program so it's all fully legal, and honestly as far as API integration goes Nest was fairly painless. But like anything else, it's all about what you can do with the data. 
 
Some users find automation through home theater, others through security systems, and some through other needs. Really depends on the person. The current #1 driver in the industry is security systems. Thanks to the marketing of Nest and others, HVAC automation is the #2 gateway to general home automation. 
 
We use a similar setup with Z-Wave (we licensed the official SDK), but that doesn't help solve the user interface/user experience issue. That's where software can stand apart from each other, anyone can build the plumbing, but how usable is it? So each device type really needs a dedicated focus on what that device needs from a user perspective. The plumbing is secondary. 
 
Which protocols/drivers do you as a company support? That's where I define "integrated feature support". That's one thing we pride ourselves on - if we say CastleOS supports it, that means it will always support and we stand behind it. (Not saying that's an issue with yours or others, I honestly have little idea so I'm genuinely curious.) We own or have licensed all the code for those protocols as well. 

 

[Dean Roddey]

We do all of the big ones ourselves generally. Elk, Omni, Radio RA2, Z-Wave, ISY, Sonos, Hue, Aprilaire, Tekmar, Homeworks, Brultech, DSC, NX8, Proliphix, all of the media repositories (iTunes, DVD Profiler, J.River, FileTag, My Movies, and our own), Weather Underground, all the Global Cache stuff, almost all of the media renderers, all of the IR devices, etc... Probably around 80% or so of the drivers listed above were written by us. The UPB one is a third party driver still since we've not gotten around to V2'ing that one, and the Centralite.
 
As to the plumbing vs. interface, we have spent the last year and a half, maybe two, creating something not unlike the Z-Wave command classes (we call them device classes), though better defined since we didn't have to make all the mistakes they did (being able to build on the experience of Z-Wave and some others.) All of our V2 drivers are based on these device classes. So all of the Z-Wave modules are exposed via these device classes and so they are easily integrated into logic and interfaces just like any other devices of the same type. There is plenty of 'semantic information' about them to easily expose their functionality.
 
This has been a huge effort on our part to create standardized interfaces for device drivers and it's been paying off very well. We now have a very nice auto-generation system, which will get a lot nicer over time, which lets the user just define rooms and what hardware should be considered as in each room, and we can generate a nice set of tough screen interfaces for them. Since CQC is uber-customizable, and we didn't want to lose that, we have take the approach of creating a more simplified 'virtual system' that can sit on top of that customizable substrate. So we are trying to tackle both ends of the spectrum (and the middle), the easy to set up system for core functionality, the fully customized system, or starting with the generated easy setup stuff and customizing from there.

 

[swamiller]

Dean and Chris, I really appreciate the point of view of the software provider.  Both of you have very robust applications. CQC is closer to filling my needs because it contains drivers for my Omnipro controller and most of the other devices I use. It looks as though CastleOS has a nice product as well but seems more focused on pulling together several random home automation/entertainment devices (mostly wireless) into one interface to control them all.  The usage of the Kinect is very intriguing!  But no interface with my Omnipro or support of zigbee that I could see from the website.
 
The unfortunate part for both, and the primary frustration that started this thread to begin with, is neither can fill common gaps that most of us have with our systems...and none of them are the same gap, which from a software perspective appears to be the big challenge.  The other is evolution and keeping us with whats new and not abandoning the legacy users or worse, quitting the game all together leaving the users to fend for themselves.
 
I have tried Elve and I was able to make a pretty impressive interface using the provided templates with relative ease.  Elve unfortunately has an unknown future at this point, however,  because the primary developer stepped away from the project.  I have also tried the v4.5 trial of CQC and I was able to eventually make it work but I wasn't happy with the initial results (which was no doubt a user head-space issue). With my first attempt using CQC I had issues controlling my UPB devices via the Onmi and I ended up letting the trial expire before attempting to figure out how to get under the hood and resolve them.  Because I lean more toward using a central, non-computer controller (Omnipro II in my case) with software as an enhancement, CastOS doesn't seem like it would be suitable for my environment.  I also tend to lean toward wired devices when at all possible with exception of my zigbee door locks and thermostats which don't appear to be supported by CastleOS.
 
The missing links for me seems simple.  As Chris mentioned, entertainment systems are a large part of many home automation systems.  For me, it's not the distribution of audio that is a frustration, it's controlling my media and video library the way I want to control it.  I use Plex and Plex server for this task because it's easy, it's simple, and it controls everything I need it to control and not a bit more.  Most home automation software seems to lean toward XBMC or other semi complete media management applications.  I have dabbled in XBMC in the past but it doesn't "just work" like Plex does.  I can change, but I need a complete solution to push me over the edge.
 
Today I have resorted away from bringing in any new home automation software for the time being to let some of the war between vendors play out a little more. I currently use Haiku for my "always functional" home automation control software. I use iRule for a pseudo all in one remote because it will talk to my entertainment devices as well as the Omni, although performance is a bit to be desired. I am also playing with Roomie remote because it does more for me on the entertainment side by presenting my FIOS tv guide (and all metadata) on my iPad (vs. looking at the tv screen to select a show to watch) and does the same for my Plex Home Theater content.  All the movies are on the tablet device to be browsed and selected vs. looking on the tv screen and scrolling. On the down side, Roomie does not interface with my Omni at all and I'm not happy with the look and feel of the remote buttons. So the search continues...
 
Dean, CQC is very close to being a solution for me but I hesitate to invest in an application that won't tie the knot between my home and entertainment. I'm not married to the media manager I am using but I haven't seen another one that does what I want it to do. I also have had a hard time wrapping my head around how to manipulate and customize the software which might be part of my problem. I know it's a learning curve issue but that is an issue.

Chris, great product!  I just can't use it with MY house  
 
@lupinglade - I'm not sure if you are monitoring this thread, but I am in daily suspense waiting for the next generation of Haiku (called Space) to come out and I hope it can fill some of the gaps for me.  Haiku has been a solid solution for me although it too lacks integrations between my house and my entertainment needs.

 

[Dean Roddey]

Yeh, various folks have been banging on us about Plex. It's on the list. Once we get the core 4.7 features done, we'll have time to look at some new stuff and that'll be one of them. I've done some preliminary poking around and spoken with them about it some. I'm guessing though that it'll be quite a bit to bite off. Anything to do with media pretty much always is.

 

[NeverDie]

I've always wondered how the so-called Internet of Things would ever come to grips with this issue.  I'm curious how the driver aspect of home automation compares in magnitude to the more visible aspects like the conceptual design and user interface, as well as basics like event scheduling.   Is writing hundreds of drivers, say, 50% of a typical home automation software development?  Or is it more like 80%?  

 

[Dean Roddey]

BTW, your post pretty much demonstrates the point I was making above. You can do a thousand things, but if you don't do that one thing that any given customer wants, they will ignore the thousand things and not commit. Given that every customer may have a different one thing, you effectively can never really have enough device support.
 
[referring back up to swamiller's post I mean]