More about CQC

Dean Roddey

Senior Member
[This was split off from another thread, so if it seems to kind of start in the middle of a conversation, that's because it did. See the Egg that Homeseer Laid thread for the context. http://www.cocoontech.com/index.php?showtopic=2967]

Guys, if you are looking for an alternative, I think that CQC can provide that. With the 1.5 release (of which the first beta should be out this week or the weekend at the latest), we'll have the two big things that HS folks have so far complained about as being essential, i.e. the event system and a web interface.

CQC is rock solid, just ask any of our customers. And it's fully networked, which I think that most people just don't appreciate fully until they've really tried it. HS lets you one run small app remotely, but CQC is completely network distributed, so every machine can control devices or be an end user and/or administrative client. And with the media management stuff that's now in the product, and the big step forward that's going to happen on that front in 1.6, and our powerful graphical interface system that's already in place and growing steadily, I just don't see how HS is really ever going to catch up with that.

It may not support every device you need right now, but all the tools are there for anyone to create device drivers and we'll give you any help we can to get the missing device support in place. The thing is, adding new device support is trivial relative to creating a powerful and robust architecture. We've done the work to create that architecture and it's already out there and well proven in the real world. Our underlying code matured for over 10 years before the actual product was ever built on it. There's just no way anyone can catch up with that the way that HS had to do it (i.e. having to pull along an existing code base and maintain backwards compat and do it 'quickly'.) So we just have a code base at a level of maturity and power that they'll just never be able to compete with, and it does really make a difference.

So we just need to get more folks involved with device driver creation in order to get some of these devices in place that you guys want, and it's not a large number of devices really that are missing. As I said, we'll provide any help we can give you to get them done, including getting the basic driver in place which you can then just finish off and test. For instance, I have a basic Ocelot driver done now, but I don't really have a real system to actually test it against (I just have the Ocelot, but not any modules), so if someone could pick that up and just finish it off it wouldn't be nearly as hard as doing one from scratch. We also have the remote port server which will allow me to connect to your serial device (IP based devices are a given) to either get a basic driver done for you to start working with or to help you spelunk issues if you run into them.

Anyway, that's my pitch. There is an alternative, and one that's uber-robust, and which has features and capacilities that HS probably won't ever have. The only thing it's missing is the device support in order to get some of these devices that you guys are using but we don't currently support integrated into the system. I think that often people confuse basic architectural capabilities and device support, but they aren't the same. You can have broad device support and weak architecture (HS) or you can very strong architecture but not broad enough device support (CQC). Of the two, the latter is the better position to be in, because the missing part is fractionally as difficult as the part that's there, and because it doesn't matter how much device support you have if it's not based on a robust and scalable architecture.
 
For writing automation logic and drivers for more comlex devices we have our own lanuage called CML. It's a specialized OO language just for automation logic and drive development purposes. It's an extremely strict language, so it's very hard to do any anything bad in it. This, we believe, is a key requirement for creating a robust system that includes third party drivers and macros.

For simpler devices or even complex devices as long as they have a consistent, well designed protocol, we have PDL which is a purely declarative language for driver development. I.e. it doesn't have any code, it just describes the messages that go back and forth and how to pull data out of them for storage in the driver and so forth.

CML is very much in the C++/Java/C# family, so if you have any familiarity with those languages, you won't have any trouble picking it up.
 
There probably should a split in the thread somewhere around here... E?

also... what about VR and TTS? What about the ability to gather information from the internet?
 
NO VR currently, TTS is there both local and remote. 1.5 adds HTTP support to the CML language so you can do web queries and whatnot.

I'm certainly happy to work with someone who really knows this area to get VR support into CQC. If someone out there can spin me up so that I can do it without spending a month of learning and exploration, I'd be happy to do it. The big thing that was missing before, which would have made the VR not so useful, was the event system. Now, with the event systemin place, when you speak, there's a good way to have that reacted to via an event.
 
MOVED: I moved this from the HomeSeer is an EGG Head thread because it was in responce to deans thread which got moved or split.
-Squintz

I will agree after having used CQC for a while that it is a great competitor. It is worth the trial. However, Just like everything else in the world I am sure you will find its week points. I just need to be honest here and say that CQC is solid and probably the best program on the market. The only thing I have been turned off by was the lack of interest in adopting the Z-wave SDK by control think. I still think its a bad move on Deans part. If you are not using Z-wave then CQC is probably your best option right now. If you are using Z-wave and want to use CQC then you may find that CQC can not keep up with the support needed for new devices.
Here is my opinion about CQC. I have been using it for a while now and I LOVE the 100% network distribution features. Everything to date has been written in a way that make most programmers drool. It is well thought out and works perfectly. However, because CQC is growing to be such a great program the parts of it like Z-wave support which need constant attention are not getting the needed attention. If Dean could just figure out a way to adopt the ControlThink SDK then he would never need to worry about Z-wave support again because all he would have to do is upgrade to the latest SDK which ControlThink is bound by Zen-Sys to support for atleast a few years because its a z-wave certified software. He may have to make minor changes such as add widgets to display data in a certain fashion but that would be minor compared to having to write support for every new device that comes to market.
Dean has expressed his feelings and has provided his reasons for not wanting/being able to use this SDK. I for one think when there is a will there is a way.

CQC does offer Elk Support and Ocelot support
CQC does have a scripting language tho its a learning curve
CQC does have a built in interface designer which is awesome
CQC does have a friendly programmer behind it and offers great customer support
CQC is very easy to use once you read the documentation
CQC continues to grow
CQC does have bugs BUT and this is a BIG BUT. They do extensive testing to limit the bugs and the bugs that are found are found fast and corrected even faster.

I have a ton of good things to say about CQC and only one gripe and thats the z-wave support. It may not be Deans fault that the z-wave support is lacking. In fact I am willing to bet its the fact the ACT is putting out non-zwave compliance remote controls and USB controllers which are not meeting the standards of Z-wave. Deans, z-wave support was great until I attempted to upgrade my remote control and then his software would not transfer the data. Probably not his fault but I know that the ControlThink SDK doesnt have an problem with it and neither would Dean if he was using the SDK.

So to summarize.... Give CQC a shot and then Beg dean to adopt the SDK even if your not using Z-wave :)
 
Squintz,

Couldn't agree more. On my newest project the only reason I couldn't go with CQC was because of VR/Way2Call/Built in webserver.
 
I also asked for a complete voicemail type system for a near future release. With that, VR and easier configuration dialogs, CQC will certainly be hard to beat. I too have been beating on it for a while and it is certainly rock solid.
 
Back
Top