Homeseer vs. CQC?

[sic0048]

There is also a BIG difference between the two that isn't first apparent. As Steve pointed out, HomeSeer has many "plugins" where the author has long disappeared, and I suppose that is true for CQC as well, but there is a GIANT different between the two; HomeSeer plugins are locked code which only the original author can modify and make bug fixes to. If an author "disappears" and you have a bug in that plugin or you want to add a feature to that plugin, your basically out-of-luck. So not only does HomeSeer sell these plugins, but you may be buying something nobody supports.

On CQC, with a very few exceptions, CQC "drivers" are completely open, you can view and modify the code, add features, etc. with not that much work. And CQC drivers are quite a bit easier to write.

This may not seem important, but it really is. Equipment that the drivers connect to change all the time, so if a new XYZ DVD player comes out, but the driver only exists for the lower model, then its fairly easy in the CQC world to update that driver. On HomeSeer, you need to track down the author and just pray he will be motivated to support your new model.

Over the years I've modified several CQC drivers to add features or fix bugs and its not all that hard.

This is probably the most important difference between the two system. I agree that it is a huge difference. There is basically a "cottage industry" that has popped up around Homeseer were people make money designing plugins. The end result is there might be more plugins for Homeseer, but you are totally dependant on those plugin developers. If they drop off the face of the Earth, then the end user is stuck holding the bag and ends up having to buy yet another plugin with no promise that it won't happen again.

As far as I know, there is only one CQC driver that is locked down. One of the lighting control drivers. It is only locked down due to a non-disclosure agreement. The manufacture eventually ended up releasing the protocol to the public, so it probably wouldn't take much for Dean to get the NDA agreement dropped should that ever be needed.

EDIT - see Deans post below for a full disclosure of what is currently locked down.

 

[wuench]

To be fair on the open driver front. There are some drivers that are written by Dean and may or may not be modifiable. If they are written in CML, CQC's driver language then they are readable and modifiable even if Dean did them. So you can customize them for yourself. Some though do have a client component or may entirely be written in C by Dean and those are not viewable/modifiable. So there are some exceptions.

But if the driver writer drops off the face of the Earth for those, we've got bigger things to worry about...

 

[Dean Roddey]

The Z-Wave driver can't be exposed due to NDA from Zen-Sys. The C-Bus driver originally had that issue but they later exposed the protocol. So it could be updated. The Omni driver is C++ currently because it has some exceptional issues wrt to encryption, which couldn't have been done in CML at that time it was written, though I think it could be now but rewriting it is a low priority. Other than that, I think that they are all CML or PDL, though I may be forgetting one or two others which are just C++ because they date back to the days when there was no CML or PDL, which I believe Carbon 14 dating has placed in the reign of the Chen Dynasty.

 

[Michael McSharry]

You can think of your HA engine quest like a search for the perfect entertainment remote. The ones that you want are those that will learn IR codes so you will be able to control future equipment. Now you have a single remote that control all your equipment and through a series of button pushes you can toggle each piece of equipment so the desired video and audio source is routed to the desired display device. When a new device comes along you will learn its IR codes and with a different set of button pushes that add it into the mix.

You would really rather not push all these button, but have the remote do the sequencing for you such as with the Harmony remotes. What distinguishes the Harmony from prior generation learning remotes is its ability with very little user effort to provide a higher level of functionality than can be achieved by controlling equipment individually. The fact that it has "drivers" for Sony, Toshiba, Phillips etc. equipment is an entry criteria for a modern remote, but it is not the what discriminates it from other remotes. It is the prepackaged logic that makes the user experince easier that discriminates it.

There is a preponderance of "drivers" for various home automation packages that are available that do nothing more for the Home Automation experience than the learning IR did for the remote. A new widget can be controlled, but the benefit associated with that control still requires the heavy lifting to be done by the user. It is not an effortless experience such as was the case with the Harmony remote.

The ELK or HAI panels allow a user to define cause/effect rules to coordinate the bits and pieces that are attached to the panels. The same basic approach is used for the PC-based Home Automation packages. There are different looks and feels presented to the user to allow the coordination to be achieved, but it is the user's burden to implement all the logic. A platform that is intuitive to the user to glue the pieces together will result in a much more effective companion to achieve automation objectives. Any of the current HA engines will have sufficient drivers to satisfy the entry critera of the above IR analogy. Technology moves on and drivers will come and go to interface it, but the core logic engine as viewed by the user will be slow to change.

Another thing you see by frequenting these HA boards is that there is considerable reinvention of the same things. There are multiple way to have widget A do something, but very few offerings that package the use of widget A into a higher level solution. Part of this is due to the DIY nature of the crowd. Part is due to the common demoninator that all can share which is the lowest level of integration at the device level. Part of it is the effort and committment needed for higher level solutions that can be universally used. Part of it is a lack of vision of what could be vs. what is. What is available with your candidate HA engine that provides pre-packaged solutions so you can truely benefit from automation without needing to build the logic yourself?

I'm one of those referred to as being in the Homeseer Cottage Industry that builds upon the base platform provided by HS. I started out with the low level stuff and have contributed my share to the reinvention paradymn. I was very prolific with producing these add-on, but generally now try to add more value than a simple driver. I have also moved toward a network-focued solution rather than one that is tied to the SDK of a specifc platform. This helps my efforts retain value as the technology and SDK evolve.

The viewpoint alluded to in this thread that offerings from any source could disappear is true. This is especially true where looking at drivers since they are simple pieces of software for which the author has very little invested or incentive. HA packages that do not offer prepackaged integrated solutions will never have the problem of the package becoming unavailable or unsupported. Of course the user also then does not have the option of taking advantage of all the prepackaged logic that could be available.

 

[Dean Roddey]

The big problem is that, once you get beyond the 'happy clappy demo' stage of automation, you generally are going to want to implement what most folks seem to refer to as 'activity oriented' automation. It's really almost impossible to pre-generate that kind of automation, because it's so highly specific to the user and his desires. It's easy to generate a single screen for every device that just lets you change every function that the device/driver exposes. But that's not really automation, it's just control really.

Once you move beyond that and get into the 'press this button to turn on the theater, dim the lights slowly, run a few previews, play a fanfare, open the curtains, load a movie and play it' type stuff, that's just incredibly difficult to generalize, and that's one of the simpler and more obvious ones. It's just incredibly difficult to be very automagical when you get to that level of automation, and that's really what almost everyone is going to want once they get into it.

Not that you can't lend more of a helping hand along the way, but beyond that it's all but impossible unless you are going to heavily restrict flexibility. That's why there's a pretty strong inverse relationship between ease of setup of a system and the flexibility of that system. And by 'setup' I don't mean just a simple tabular list of values that you can see and change, but a real system. Every automation system has to kind of fit somewhere along that line.

You can certainly provide starter systems, and I'll be doing that for CQC more than in the past. But, in some cases it can be a problem because, if it's really nice and shows off the capabilities of the system, then it will be pretty completely incomprehensible to someone who doesn't already understand that system. So folks can end up with a system that they don't really understand the workings of, and their setup can be very 'fragile' because of that, and they can sometimes blame the product vendor for that fragility.

So there's somewhat of a tight line to walk. You do want to help them. But, OTOH, they ultimately must eventually understand the product if they really are doing to do it themselves, since DIY is doing it yourself. So the complexity has to be faced one way or another. And the complexity is going to be fairly in proportion to the flexibility of the product, and for most folks flexibility is very desirable. So you have to be careful not to misrepresent the product, and 'bait and switch' them into a system that they will not ever end up mastering.

 

[Ira]

The big problem is that, once you get beyond the 'happy clappy demo' stage of automation, you generally are going to want to implement what most folks seem to refer to as 'activity oriented' automation....

You are right, but don't underestimate the value of the "happy clappy demo" stage of automation. For most DIY'ers, acceptance is much more likely if they can expand outward from a few "happy clappy demos" instead of starting from what seems to be a clean slate. And there's a huge subjective value to having something useful running at the end of the installation process other than the framework.

As part of the installation process, why not give the customer that wants to integrate CQC and the ELK M1G the ability to easily implement the equivalent of Elk's RM software (i.e., not have to create/design anything)? Sure, it's just a software version of an Elk keypad for the most part, but it's a way for someone who is familiar with the M1G to become familiar with CQC. Elk obviously thinks there is value in having a Windows-based software emulation of their keypad since they charge for it. Build a framework so that the same can be done for some of the other more popular devices. Make it part of the installation such that when the installation is complete, I (optionally) have the skins/drivers for the M1G, Omni, a few TV's, a few lighting controls, Sage, etc. up and running with a minimum of effort. If necessary, I can go back and tweak them once I have played with them.

Ira

 

[Michael McSharry]

I can speak to what is available out of the box with Homeseer and I suspect it is pretty much the same with most HA software offered today. I will give some examples to try to clarify what I tried to indicate above.

A simple example is a control of moisture level in the bathroom. One has the abilty to control a fan and the ability to measure humidity levels and possibly even control an air conditioning unit. With Homeseer (or a smart security panel) a set of rules can be established that involves defining events with triggers and conditions. This can be done with an event editor or with a procedural script. The event editor is presented in the frame of reference of what Homseer expects such as Trigger event X when Humidity > 60 Then Turn Device A1 ON. Trigger event Y when Humidity < 50 and A1 ON then Turn A1 OFF. This works, but if someone was walk up and wanted to change the humidity threshold to be 70 or wanted to disable this automated control they would have to edit the event trigger which is one of many in the list of events setup to support the automation. There is not an intuitive feel that corresponds to a user's real-world environment.

If the was an "Activity" of humidity control available then there would be a few dials/setup parameters that the user would define and these would be intuitive in the context of controlling humidity. It would be easy to maintain or change it because what is presented to the user is equivalent to the activity being performed.

One could argue that this user presentation is the role of the UI. In this situation the same problem still exists the owner of the HA software would need to place graphic symbols on a page and define events that drive these symbols. It is the same problem in that the realization of the solution requires the user to build it from a kit and a kit that only becomes natural after a learning curve.

We have weatherstations that users install at there residence and we have "drivers" that make the weather station parameters visible to the HA software. We have presentation packages that show the weather in various forms to collect it for historical presentation and statistics. What is lacking is the application of the weatherstation in an "activity". An activity of room temperature management would have setup parameters the account for temperature gradients among heating spaces, effects of sun and other parameters that could be measured with a weatherstation, forecasts etc. The user would setup things that relate to temperature management and then the automation control achieved would be intuitive. It would not be a complex set of events and actions or equivalent procedural scripts.

mcsSprinklers deals with the "Irrigation Activity". It has considerable complexity and accomplishes things that would be very difficult to weave togehter with the generic capabiliteis provided by HA software. This complexity, however, is presented in the context of irrigation control. A user can understand an irrigation program that schedules cycles at 2AM, 3PM and 8PM and skips those cycles if it is raining or windy. The user does not need to setup three events to schedule them and then add conditions for wind and rain. There is considerably more than just basic scheduling such as managing a water budget or assuring a stuck valve is reported. The user is taken beyond what can be done with each component of the system to obtain a higer level value. They get calendar views, historical trends and other statistics to help them manage the irrigation activity.

 

[sic0048]

Michael,

I think I understand your idea, and the example of the sprinkler control is great. But I think to have this "activity" based setup, it has to be a very small specific set of parameters. That doesn't mean that the system cannot be complex, but rather it has to be very predictable and non-customizable. I think it becomes virtually impossible to accomplish this "activity" based scenerio when the system is very complex and NOT very predicable but instead allows for a lot of customization. The number of different variables that could be possible starts to get mind boggling.

So basically I think you can have one or the other. Either simlified "activity" based setup, but for some very specific scenerios, or you have a system that is very open and customizable, but you loose that simplified "activity" based setup.

Perhaps if we ever see the day where computers begin to make logical decisions on their own (basically some sort of AI), then this catch-22 might broken. But probably not until then.

Just my two cents....

 

[Dean Roddey]

One of the biggest problems is that so many devices are just completely ad hoc and incomprehensible. You come up with what you figure is the most incredibly obvious abstraction for a particular category of devices, then immediately discover that some device that's widely used has some completely funkey sort of characteristic that won't fit into that abstraction, and therefore anyone who uses it has to jump through more hoops to get it working than they would if they just dealt with it directly without the abstraction. It's easy to come up with abstractions that handle any device of a given category that was designed by non-aliens, but unfortunately there's a large alien contingent designing hardware.

And of course you immediately also run into combo devices that aren't any one thing, but won't really work either by trying to treat it like multiple separate devices, or maybe it would if you could forsee every possible type of combo device, but that's not really possible. And the ones that are the most fundamental, automation panels, are so complex and have so many disparate features that it's really tough to come up with any abstraction that wouldn't be considered overly limiting to everyone using every type of panel. Even drivers that are just ad hoc designed for a given panel have trouble exposing all of the functionality available.

Anyhoo, there are a lot of complicating factors that prevent you from doing the obvious thing. If you could afford to say, well any device that doesn't fit our abstractions we just won't support, the benefit is worth it, then you'd be fine. But you really can't. People aren't going to rip out all the stuff they have in order to use your automation product, unfortunately, the heathens. You should do what you can obviously, and there's definitely more we can do. But it's always very frustrating because there's are few standards in the hardware world.

 

[pete_c]

Personally I've evolved somewhat in the HA world.

In 1978 when I could put a timer to X10 light switches to automate while I was not present was a great thing for me. Today for me its not as important.

There are fundamental HA features that exists in my home today that I could just consider the "heartbeat" of the house. The lights go on, the HVAC works, etc. Utilizing the HAI OPII panel provides me with the basics; of which I am aware of but not concerned with. Dumb analogy but have a look at what the brain stem does in the human body (really just some basic maintainance - breathing for one).

I currently use the HA server to "override" these basic settings but not maintain them.

I have friends which I have introduced to HA specfically lighting control over the last few years. HA / Lighting control is something new to them. They are awed that they can control one light switch via a computer, a remote, VR or a touch gui.

Today the HA server provides TTS to various speakers in the home. I can do the same with the HAI OPII panel. In the 1980's I had an alarm panel in the house which also provided speech. The 1980's alarm panel voices were more "canned" and recorded in ROM words picked from a large vocabulary. Concurrently played with interactive but very primitive TTS/VR. It was nice to play with at the time (80's) but not ready for prime time. Sometime in the late 1980's started to play with touchscreens and light pens. I set up both while my children were very young (under 5 years old). I was amazed with how much they liked the interaction of the touchscreens versus keyboards (they each had computers that I had set up for them). Today two of my vehicles have BT, VR and TTS. I only use the BT and have the VR/TTS off. If the VR/TTS did more than telephone/navigation functions I would maybe leave it on.

In the mid 2000's remember discussions for deployments of touch screen kiosks and what and whom was going to have the largest logos / icons (hours of meetings for the LAS airport) - made the technology piece boring for me then....

Fast forward to today. I want to be aware that the house is "functioning" with it's basic heartbeat. I want the interaction but don't want to spend hours designing a GUI touchscreen to provide me with some basic HA features or to impress visitors that come to my home. Today via an API / plugin I get a set of varables from multiple hardware devices plugged into my HA box. Some of these devices are relatively primitive only providing a basic legacy serial interaction; some devices are not so primitive. I get those variables in a variety of ways into my HA box and am not concerned with that piece of it. The ability to have the HA box multitask with a combination of different methodologies using different means to get the data/variables in the box is what I like.

On the other hand a "newbee" today will want to be able to maybe just control his/her lighting with the least amount of effort as quickly as possible (we enter the world of sound/video bytes, instant gratification etc) or a more computer literate person won't mind spending a bit of time creating/modifying an interface for one piece of HW connected to his/her automation server.

A thin, light and portable touch pad is a nice means of a communications portal into my home automation system but it'll mostly stay in its docking cradle as I will not "walk" around the home with it. I remember playing with my CE wireless based Epod in the late 1990's and seeing what HA things I could do with it. Today I don't care to walk around in my home with my PDA phone tethered to me and don't. I do though check my sprinkler system zones by walking around outside with a remote turning each zone on to make sure the sprinkler heads are working right.

The DIY HA newbee today is a different "breed". I don't know the makeup of said person but mostly what I've seen is that that person can most likely interact with a computer; some more detailed relating to a niche of some particular aspect of its use and others just enough to get email.

I already know what functions and what my HA server is capable of doing and don't really care to know the how and why anymore but rather how much more can I do with it without breaking it.

For my HA amusement I would like a touchscreen interface with an animated interactive VR/TTS/ AI character that would just tell me that all is fine with the basic heartbeat of the home. This already is "old" technology as I played with AI in the automotive industry in the middle 1990's. (specifically Ford but GM/Chrylser were playing with it too).

Enough rambling.

 

[jwilson56]

I am surprised that there are not many more example skins for all home automation packages. An example is worth a thousand words of documentation as a starting point for their own skin. I have always supported Promixis by releasing many of my Netremote skins so people can use them to create their own. As a side note I am surprised that there are not more people that do share their skins for others.

 

[Michael McSharry]

That doesn't mean that the system cannot be complex, but rather it has to be very predictable and non-customizable. I think it becomes virtually impossible to accomplish this "activity" based scenerio when the system is very complex and NOT very predicable but instead allows for a lot of customization. The number of different variables that could be possible starts to get mind boggling.

Which each piece of smart electronics you buy today there is a setup or configuration phasse that you need to start with. If you setup of DVD it may be to select the Region. If you setup a TV it will have more menu choices such as sharpness, internal audio etc. The complexity of the setup will be a consistent with the number of paraameters that can effect the equipment's desired operation. You would not expect to setup your Router security key as part of the TV setup menu. The setup is only needed for those things related to the specific equipment.

When you setup a Home Automation "Activity" the same applies. You are provided a set of options upon which to select that affect the behavior of the activity. This customization may be the characteristics of hardware which the activity controls or from which it obtains stimuli. The selection does not need to be option 1 vs. option 2, but can be any appropriate way to identify a setup customization. There are many external things that can affect an irrigation schedule, there are many sources that measure these things and there are many pieces of different hardware that can be actuated to modulate water flow. These external influences include the user's lifesytle and preferences. While there are many parameters it is still a bounded set based upon the activity. It is true that there may be some influences that cannot be specifically considered, but 9x% can be and the remainder dealt with with provisions for external user logic that is integrated with a standard mechanism. In the mcsSprinkler's case there are 8 browser pages of setup parameters and 78 interview setup questions for the professional level version. Not everyone needs this level of configurabilty and many would actually prefer to not have these options as they want to get as quickly as possible from unpacking the box to watering their lawn. The setup for the other versions contain roughly 1/2 and 1/4 the setup options.

mcsSprinklers is over 60,000 source lines with about 5,000 that do the actual scheduling and monitoring logic. That means the majority of the software is used to provide the Irrigation Activity paradymn in the context that is intuitive to the user. It is a lot of effort to provide this capability and that is why you do not see much of it beyond trivial demos or uncustomizable solutions.

You will typically not see capabilities of this nature offerred by HA companies because the domain experties of the HA personnel is not in the "Actvity", but in the product that abstracts hardware interfaces into tool that allows user control and monitoring of this hardware. The "Activity" solution and the control tool do not need to be strangers. They can be complementary.

Because of my familiarity with Homeseer I have provided one of the setup options to be use of the Homseer abstraction of devices. This allows mcsSprinklers to accept irrigation parameters based upon the hardware abstraction already afforded by Homeseer. mcsSprinklers also uses the abstraction provided by xAP for interaction to be able to use the information flowing over the LAN that may have an effect on an irrigation decision.

My whole point in providing this input is to provide a vision as to the direction I believe Home Automation is heading. Today we have a middle-ware layer that provides an abstraction of hardware into a control and monitoring engine and the user is able to perform simple and effective selections tie the hardware together. We are moving up the food chain with higher levels of automated control. My belief is that these higher level components will actually be entities on the IP/LAN that interact as peers rather than what we have today as a general purpose computer that is needed to translate low level hardware protocols into some abstraction that can then be related via logic rules. On this road there will be opportunities with "Activity" solutions that can be build upon the existing middleware. Middleware that is positioned along this path will have an advantage.

 

[johnnynine]

I am surprised that there are not many more example skins for all home automation packages. An example is worth a thousand words of documentation as a starting point for their own skin. I have always supported Promixis by releasing many of my Netremote skins so people can use them to create their own. As a side note I am surprised that there are not more people that do share their skins for others.

...there's a huge subjective value to having something useful running at the end of the installation process other than the framework.

A system that just works after installing:

I couldn't agree more. The latest version of Elve (0.24 released last night) features a great post-installation user experience to get users up and running even quicker then before. First time users will see the system preconfigured with two working sample touch screen interfaces after installation. We've updated the iPhone and Steel Dashboard interfaces with newer up to date features including music search and more. If you are an existing user be sure to check the Sample Touchscreen Interface checkbox when installing since it will be unchecked for you.

Open Source Device Drivers:

With regards to some of the comments above about open source device drivers, the new version of Elve now supports Open Source Uncompiled device driver files. In future versions we will be looking into open-sourcing many of the existing device drivers. As many of you know we are giving away a free license to Elve Professional to users who create and share non-trivial device drivers.

Sharing Skins:

Although we haven't promoted it much, we are also giving away a free license to Elve Professional for users who create and share a completed touch screen interface.

 

[Deane Johnson]

I'm trying to evaluate the main stream players to decided on my first software system. I'm looking at Housebot, CQC, and Homeseer. Threads like this one are of tremendous value in my search.

Elve seems to be on a pretty good roll. My questions is will it support Ocelot?

Thanks.

 

[programmergeek]

I am in the same boat right now looking for a solution for my busness. I like Homeseer nice packaging nice hardware great for the Green houses we are doing. I think I could really resell this easly and intragrating looks simpler than CQC, speed means money to me. However it will not work 100% with HAI so that is a deal breaker for me. I think I am going to have to play with CQC. Both look like great products I just hope the programming is not to much with CQC to get interfaces the way users want. We sue to get beat up all the time with the philips products on that. Now the market is even more demanding wanting real time feeds email home control on one touchpad.